線上分析處理、 資料採礦與 Analysis Services 第 15 章 線上分析處理、 資料採礦與 Analysis Services

本章提要 15-1 資料倉儲：從交易性資料到分析用資料 15-2 線上分析處理 15-3 資料採礦 15-4 應用簡例之一：建立 Cube 進行線上分析 15-5 應用簡例之二：使用資料採礦分析 Cube 內容

前言 SQL Server 2005 中的 Analysis Services (SSAS) 元件, 加上前兩章介紹的 SSIS (SQL Server Intergration Services) 及 SSRS (SQL Server Reporting Services), 是微軟公司商業智慧 (Business Intelligence) 解決方案組合中的三大要件。 本章將簡介 Analysis Services 中, 線上分析處理與資料採礦的概念。

前言 Analysis Services 提供線上分析處理及資料採礦這兩項在決策支援系統 (DSS,Decission Support System) 中的重要應用, 本章將簡介這兩項應用的概念。 由於 Analysis Services 通常用於需對大量資料進行分析的商業應用或研究, 本章將不會介紹完整的實作方式及步驟, 有興趣的讀者, 可自行依線上叢書中的教學指引, 來熟悉 Analysis Services 的使用方式。

15-1 資料倉儲： 從交易性資料到分析用資料 線上分析處理與資料採礦的用途就是『分析資料』, 要分析資料, 當然得先有資料給它們分析, 而線上分析處理與資料採礦最常見的分析資料來源, 就是資料倉儲 (Data Warehouse), 因此本節先簡介何謂資料倉儲, 稍後再介紹線上分析處理與資料採礦。

資料倉儲： 從交易性資料到分析用資料 分析資料與交易資料的差別 資料倉儲 資料倉儲架構 雪花式架構

分析資料與交易資料的差別 隨著企業應用資料庫管理系統的範圍擴大、使用的時日增長, 企業的資料庫中往往累積相當大量的資料, 這時候人們就開始思考如何能利用這些歷史性的資料, 以輔助決策的分析。 例如 Analysis Services 所提供的線上分析處理與資料採礦, 就是這類決策支援的應用之一。 資料庫雖然讓企業能集中大量資料做有效的管理, 要查詢交易資訊也還算方便,但若要利用資料庫中的資料做更進一步的分析就有所不足了。

分析資料與交易資料的差別 這是因為資料存放的方式、資料表的欄位結構等都是為方便處理交易作業而設計。 例如訂單處理、進銷存系統, 這類以交易 (Transaction) 為基礎的系統就稱為 OLTP (On-Line Transaction Processing) 系統。 OLTP 系統都是使用關聯式資料庫管理系統 (例如 SQL Server) 來存放資料, 因此在規劃資料庫時, 即會依照關聯式資料庫的設計原則, 進行『正規化』將各種資料欄位切割。

分析資料與交易資料的差別 此時要從眾多資料表中, 任意取出必要的資料來進行線上分析處理或資料採礦等分析動作, 不但要對資料表結構、參考關係相當熟悉, 也要對 SQL 語法游刃有餘。 舉例來說, 要用 SQL 語法從某個 OLTP 資料庫中查出甲客戶在什麼時候買了乙產品, 可能並不困難；但如果要查的是甲客戶最近兩季的購買的各種產品趨勢、或甚至是每一項產品在哪些地區賣得最好等資訊, 就不是這麼容易了。

分析資料與交易資料的差別 就算熟悉查詢語法的程式設計人員可能都要花費一番工夫, 更不用說那些需要經常取得這些資訊來分析市場, 但對資料表結構、SQL 語法認識不多的中、高層主管, 要他們能自己設計一個查詢來取得所需的資訊幾乎是不可能的任務。 就算讓決策者能順利取得他們所需的資訊, 這種讓決策者直接存取作業資料進行分析的方案仍有其缺點。

分析資料與交易資料的差別 由於 OLTP 資料庫系統仍要供日常的作業使用, 若再加進決策人員為取得參考資訊所需使用的複雜查詢, 將會大幅影響系統的效能。 一來可能使得日常的交易作業執行速度變慢, 二來決策人員也必須等待較長的時間才能取得所需的資訊, 再者也可能引起安全管理的問題; 這些都是資料庫管理人員所不樂見的。

分析資料與交易資料的差別 除此之外, 可供決策者參考的資料可能是散布於各不同的系統中, 例如公司可能有個集中式的大型主機存放整體性的資料、而各部門則有個資料庫伺服器存放該部門的資料, 而資料除了存於資料庫伺服器, 也可能是以 Access 資料庫、Excel 試算表、或一般純文字格式存在。如此一來, 更造成決策人員取得資訊上的困難。

分析資料與交易資料的差別

分析資料與交易資料的差別 因此在進行決策分析之前, 首先要做的工作就是將所需的資料從不同的資料來源加以整理、過濾、整合, 然後將整理過的資料匯入資料倉儲集中存放, 以便進行後續的分析。

資料倉儲 資料倉儲 (Data Warehouse) 從字面上的意思來看, 就是個存放許多資料的大倉庫, 所以資料倉儲其實也是個資料庫, 但它具有幾項特性和一般所用的資料庫有些不同。 由資料倉儲之父 Bill Inmon 所提出的定義可瞭解資料倉儲的特性：『資料倉儲是個整合的、主題導向、長期累積的、且內容不需更改 (但可加入新資料)的資料集合, 以輔助管理者進行決策的思考』。 從資料的角度來看, 資料倉儲特性有：

資料倉儲 整合的資料：將不同來源的資料以一致的命名規範、度量、以及格式, 整合後合併起來存放, 以利使用者的存取。例如將所有的日期資料都轉成使用單一的格式,而各類意義相同的資料, 在不同的資料來源也可能使用不同的名稱、度量, 在集合到資料倉儲時就需加以統一。

資料倉儲 主題導向的資料：在企業各部門所使用的作業性資料都是與該部門業務範圍相關的, 像是產品和客戶資料等等, 不過其中有些資訊雖然是日常作業所需的, 但對決策者在進行分析時卻可能是沒必要的, 像是客戶的聯絡電話等。因此在將 OLTP資料轉移至資料倉儲時, 就需將不需要的資料過濾掉, 使資料倉儲只存有與分析主題相關的企業資訊, 而不存放無關的作業資料。

資料倉儲 歷史性資料：資料倉儲主要是讓我們得知組織在過去某個時期的運作狀態, 例如過去五年、十年, 或是最近三個月的業績等資訊, 藉此來分析、決定組織應採取的策略。而一般的 OLTP 系統則是提供近期的作業需求, 例如二年內的進貨、出貨的商品和數量等資料。

資料倉儲 唯讀資料：當我們將作業性資料轉移到資料倉儲後, 理應就不需再做什麼變動了,除非因匯入資料有誤而需做的修正。由於存放的是歷史性的資料, 所以也不需更新, 只需定期加入新資料, 但原有的資料則不會變動。所以資料倉儲對使用者僅需提供單純的資料查詢功能, 不需讓使用者修改和插入資料。

資料倉儲 當我們建好資料倉儲後, 由於它也是個資料庫, 當然可使用 T-SQL 敘述來查詢,或是用一般決策者較熟悉的工具, 諸如 Microsoft Excel 的樞鈕分析表工具來查看。 但使用 Analysis Services 的線上分析處理或資料採礦的功能則更容易由其從中擷取出所需的資訊或知識。以下進一步說明資料倉儲的基本架構。

資料倉儲架構 OLTP 系統是以便於進行交易處理為目標, 來設計和安排資料庫、資料表和資料的存放和排列方式, 而資料倉儲是為了方便查詢決策支援的資訊而設, 因此資料庫的設計方式會和傳統的作法不同。 用來建立關聯式資料庫的模型為一般學習資料庫者所熟知的實體-關聯模型 (E-R Model), 而建立資料倉儲所用的則是維度模型 (Dimensional Model), 所以資料倉儲也稱為維度式資料庫 (Dimensional Database)。

資料倉儲架構 在維度模型中可將資料分成維度 (Dimension) 和量值 (Measure) 兩類, 在原本 OLTP 資料庫中可用以描述某筆交易的屬性之欄位即可歸於維度資料, 例如訂單資料中的交易日期、產品名稱、客戶名稱...等；而交易中的數字或文字性資料即為量值, 例如銷售金額。 維度資料依其屬性分存於各維度資料表中, 而量值資料則統一存於事實資料表 (Fact Table), 事實資料表除了量值資料外, 也另有參考至各維度資料表主鍵的外部鍵 (Foreign Key) 欄位。

資料倉儲架構 下圖即示範一 OLTP 資料庫中的資料表, 重新整理轉存至資料倉儲的情形：

資料倉儲架構 由上圖可發現資料倉儲資料表的架構彷彿是個星芒的圖樣, 所以此種架構稱為星狀架構 (Star Schema)。 讀者或許會發現, 此種資料表結構不像平時做關聯式資料庫設計時會做正規化,使得資料庫中會有許多重複出現的資料：

資料倉儲架構 例如時間維度中存放的是所有交易的日期, 及該日期所屬的年、月、季等資料, 可以想見, 資料表中會有多筆同年、同月、同季的記錄；同理, 客戶維度中的客戶所在城市也可能有許多重複的, 在 OLTP 資料庫中就會將地區資料存於另一個資料表中。 這種重複情形使得對資料倉儲進行查詢時, 不必使用到 JOIN 等複雜的查詢方式, 此外免於參考多個資料表才能得到分析資料, 也可提昇查詢資料倉儲時的效率, 減少決策者分析時讀取資料的等待時間。

雪花式架構 雖然星狀架構中的維度資料表未做正規化, 但若有必要仍是可做正規化將維度分成多個資料表存放。 例如前例中的客戶維度, 可將客戶所在地的資料分離出來成為另一個地區資料表, 此種將維度內容分成多個資料表的方式, 稱為雪花式架構 (Snowflake Schema)。

雪花式架構

15-2 線上分析處理 線上分析處理 (OLAP, On-line Analytical Processing) 是目前眾多決策支援系統之中, 發展成熟的解決方案之一。相對於 OLTP 是為了因應日常商業運作的交易處理而設的, OLAP 則是提供決策者能『方便且快速』取得商業資訊以進行決策分析。

線上分析處理 OLAP 之所以能讓決策者快速取得所需的資訊以進行分析, 就在於它採用了和資料倉儲類似的維度模型來儲存資料。 所以當決策者要查某年某季某地區的產品銷售情況、或是某年某月所有業務專員的業績時, 都不必像使用 OLTP 時要做複雜的查詢, 只需從維度模型中抽出要瞭解的時間 (某年某季)、產品、和地區等三個維度, 再指定要查看的『事實』是產品銷售量就可以了, 這些資料經過 OLAP 的呈現,就成為能輔助決策的資訊了。

線上分析處理 雖然和資料倉儲一樣採用維度模型來儲存要分析的資料, 但在 OLAP 中並非以關聯式資料庫、資料表來儲存資料, 而是用稱為 Cube 結構的多維式資料庫來存放資料。

線上分析處理 雖然 Cube 的字面意思是方塊, 但 Cube 並不像立體的方塊只能有 3 個維度, 它可以和資料倉儲一樣有多個維度, SQL Server 2005 的 Analysis Services 甚至還支援在一個 Cube 中可以有記錄不同量值的多個事實資料表。 在 Analysis Services中, 可直接由預先建好的資料倉儲來建立 Cube, 也可從其它資料來源建立 Cube, 建好的 Cube 是以 XML 的格式儲存於系統中。

線上分析處理 建好 Cube 後, 使用者可使用 Microsoft Excel 或企業自行開發的用戶端工具來瀏覽、檢視其內容以進行分析。

Cube 不只是資料庫 在資料倉儲中, 存於事實資料表的量值 (業績、銷售量、和銷售金額...等) 只是單純存成一筆筆的記錄, 如果要依時間維度查某年某產品的總銷售量, 則需透過查詢語法將量值加總。 由於資料倉儲中事實資料表內的記錄動輒上百萬筆, 做這樣的計算將花費不少時間；而為了能快速提供資訊給決策者, Cube 中會將一些量值的加總值預先計算出來, 所以使用 OLAP 查詢時, 都能很快即得到所需的數據。

Cube 不只是資料庫 然而要預先計算出各種可能的加總值並儲存起來, 連同原本的單筆資料, 有時會使 Cube 消耗過多的儲存空間。因此為了彈性調控 Cube 的儲存空間, OLAP 提供三種基本的資料儲存方式： MOLAP (Multidimensional OLAP)：資料和計算結果都存放在 Cube 中, 存取的速度會最快, 對使用者來說, 會覺得存取效率最好, 但也會耗用較多的儲存空間。

Cube 不只是資料庫 ROLAP (Relational OLAP)：和前一項相反, 所有資料都直接由原來的資料庫取得, 而加總計算的資料亦存於關聯式的資料表中, 因此這種形式的 Cube 會佔用最少的儲存空間, 但其存取效能較差。 HOLAP (Hybrid OLAP)：前兩種的折衷, 資料仍留於資料庫中, 但對於查詢時所需用到的各項統計數據, 則是存於 Cube 中, 換言之使用這種方式會比 MOLAP還節省儲存空間, 系統回應查詢的速度也會比 ROLAP 還快。

Cube 不只是資料庫 視 Cube 的使用情形可選擇合適的儲存方式, 例如有個 Cube 提供的是 10 年前的歷史性資料, 且使用的頻率不高, 此時可考慮選用 ROLAP 以節省儲存空間。而存放近 3 年資料的 Cube, 則可能因為會是常被決策者查詢, 則應選用 MOLAP 以加快存取效率。

15-3 資料採礦 經由前面的介紹, 讀者應該瞭解：資料倉儲是用來存放大量的歷史性資料, 而OLAP 系統則是用來幫助決策者分析資料、取得可輔助決策的資訊。 在 1990 年代這兩項技術和應用快速地起飛、成長, 使其應用範圍日益擴大。但隨著商業收集到的資料範圍擴大 (相信大家都曾有在商場填寫許多個人資料的經驗), 使可分析的資料量鉅增, 要決策者用人工的方式從 OLAP 發掘出有價值的資訊也非易事；另一方面決策分析的需求也成長到另一層次：

資料採礦 如何利用現有資訊預估未來的趨勢以採行合適的決策, 因此資料採礦 (Data Mining) 這項技術也流行起來。 資料採礦又稱為知識發掘 (KDD, Knowledge Discovery in Database), 由此可知資料採礦的目的不僅是要從資料倉儲或 Cube 中找出可輔助決策的資訊而已, 而是要發掘出對組織有價值的知識。

資料採礦 簡單地說, 資料採礦是以特定的演算法, 將資料倉儲或 OLAP 系統中的資料再做進一步的統計和推演, 以找出特定的模式 (Pattern), 讓決策者可據以訂定相關策略。所以資料採礦就是利用現有的 (已知的)資料, 依所要分析的方向, 建構出模型來預測未知事物的方法。

資料採礦 資料採礦模型 資料採礦演算法 資料採礦的應用

資料採礦模型 資料採礦技術是利用 Data Mining Model (資料採礦模型) 來幫助使用者分析。 所謂模型, 就是可用來描述分析對象的資料結構, 而我們要將已建立好的資料倉儲或 Cube 中的資料放到這個模型中 (此動作稱為『訓練』), 透過資料採礦演算法找出特定的模式, 並依其內容來進行決策。

資料採礦模型 資料採礦模型的觀念並不新鮮, 早在資料採礦這個名詞出現之前, 人們就已經在用了。 舉個簡單的例子, 就是守株待兔的寓言故事：有位仁兄在樹下撿到兔子, 就每天在樹下等另一隻兔子, 這位仁兄所用的資料採礦結構是『位置』-『收獲』, 用來訓練模型的資料就是『某顆樹下』→『兔子』, 因此得到去樹下等就可撿到兔子的結論。 可惜他所用的資料量太少, 造成判斷錯誤, 否則他可能會發現去蘋果樹下撿蘋果, 日子會比撿兔子好過一點。

資料採礦模型 再舉個例子, 有經驗的漁夫空手而回的機會比新手少, 就是因為根據他們的經驗,知道要在何處、何時、用何方法可補到較多的魚, 或是某種特別的魚。 在他們的資料採礦模型中, 可能就有潮水、位置、時間、天氣、魚的習性等多種欄位, 而他們的經驗和知識就是訓練資料採礦模型的資料。

資料採礦演算法 對資料採礦來說, 演算法 (Algorithm) 可說是建立採礦模型的方法, 演算法決定了如何分析資料, 以及尋找樣式和趨勢的方式。 不同的資料屬性, 以及不同的分析目的, 各有其合適的演算法 (SQL Server 2005 即提供了 9 種適合不同分析目的的演算法)。 資料採礦演算法大致可分為以下幾類：

資料採礦演算法 分類性演算法：用於找出資料中不同屬性間的關係 (例如是否中年男性較會買休旅車或高級房車), 例如 Analysis Services 提供的Microsoft 決策樹演算法、Microsoft 貝氏機率分類演算法。 迴歸演算法：依據現有資料預測某項趨勢, 例如 Analysis Services 提供的 Microsoft 時間序列演算法、Microsoft 線性迴歸演算法、Microsoft 羅吉斯迴歸演算法即屬此類。

資料採礦演算法 群集演算法：用以將資料分成不同的群集, 例如 Microsoft 群集演算法。 關聯性演算法：可用以找出資料各項屬性的關聯性 (例如找出購買甲商品的消費者通常也會購買的乙商品), Analysis Services 提供的相關演算法為 Microsoft 關聯規則演算法。 順序性分析演算法：用以分析連續性的資料, 並將之分類 (例如分析上網者瀏覽網頁的順序性), Analysis Services 提供的相關演算法為 Microsoft 時序群集演算法。

資料採礦的應用 目前在商業領域資料採礦已使用得相當廣泛, 舉例來說, 消費者至賣場購物時,收銀台即會記錄每位客戶所購買的貨品種類、數量等, 將這些資料整理、集合存入資料倉儲中, 再用資料採礦技術分析, 或許會『發現』原來買啤酒的消費者通常也會買尿布。 這就成為一項企業知識, 因為日後賣場要針對尿布做促銷, 就可選擇在啤酒的貨架旁邊放置尿布廣告以吸引顧客注意, 甚至也可能舉辦買尿布送啤酒的活動。

資料採礦的應用 除了商業的應用外, 在科學界乃至國家安全, 都可以看到資料採礦的應用, 據稱早在 911 事件前 1 年, 美國國防部的情報單位就已使用資料採礦技術發現參與該事件的恐怖份子在美國活動。

15-4 應用簡例之一： 建立 Cube 進行線上分析 本節將簡單示範使用 Analysis Services 由資料倉儲建立 Cube 並進行分析的過程, 但將不會深入探討細節, 有興趣者請自行參閱 SQL Server 2005 線上叢書。

應用簡例之一： 建立 Cube 進行線上分析 建立專案 建立資料來源 建立資料來源檢視 建立 Cube 部署 Cube 測試 Cube

建立專案 Analysis Services 的 OLAP 功能和前一章介紹的 Reporting Services 提供的報表功能類似, 我們必須先用 Business Intel ligence Development Studio 建立 Analysis Services 的專案, 然後在其中設定資料來源、設計所需用到的 Cube, 再將之部署到 Analysis Services 之中, 之後使用者 (決策者) 才能透過用戶端程式 (例如 Excel) 來存取 Analysis Services 服務所提供的 Cube, 並進行分析。

建立專案 以下我們用 SQL Server 2005 所提供的範例資料倉儲 Adventure WorksDW 資料庫為資料來源, 來建立一個簡單的 Cube, 讓讀者體會 Analysis Services 所提供的功能。 請先啟動 Business Intelligence Development Studio, 然後建立 Analysis Services 專案：

建立專案

建立專案

建立專案

建立資料來源 建好專案後首先要做的就是建立 『資料來源』 (通常就是預先建好的資料倉儲),之後才能自資料來源中取得資料建立 Cube, 我們可依如下方式啟動精靈來建立資料來源：

建立資料來源

建立資料來源

建立資料來源

建立資料來源

建立資料來源

建立資料來源

建立資料來源檢視 我們可以把資料來源檢視和資料來源的關係, 類比為 SQL Server 資料庫中『檢視表』與『資料表』的關係：利用檢視表, 可將資料表中儲存的記錄以自訂的查詢方式呈現出來, 甚至可將來自多個資料表的內容整合至同一檢視表中, 以方便我們查閱。 同理, 透過資料來源檢視可將來自不同資料來源的資料整合在一起, 以供後續建立 Cube 時使用。限於篇幅本節不介紹如何整合多個資料來源, 只透過資料來源檢視從資料來源中篩選出建立 Cube 所要用的維度和事實資料表。

建立資料來源檢視

建立資料來源檢視

建立資料來源檢視

建立資料來源檢視

建立資料來源檢視

建立 Cube Cube 可說是 OLAP 的核心, Cube 除了單純從資料來源檢視或其它資料來源匯入所需的資料外, 也可由既有的資料產生新的資料欄位以供分析。 以下將示範建立 Cube 的方式, 進階的設定方式則請參閱線上叢書：

建立 Cube

建立 Cube

建立 Cube

建立 Cube

建立 Cube

建立 Cube

建立 Cube

建立 Cube

建立 Cube

建立 Cube

建立 Cube

建立 Cube

部署 Cube 在 Business Intelligence Development Studio 中建立好的 Cube, 必須『建置』、『部署』到 Analysis Services 伺服器上才能使用：

部署 Cube

部署 Cube

測試 Cube 部署完成後, 使用者即可使用 OLAP 相關的用戶端程式 (例如 Excel), 連上Analysis Services 並存取 Cube 以進行分析。 而在 Business Intelligence Development Studio 中也提供 Cube 瀏覽器, 讓我們可存取 Cube 的內容：

測試 Cube

測試 Cube 如果讀者用過 Excel 的樞紐分析表應會對此畫面感到熟悉。Cube 瀏覽器最簡易的用法, 就是將想要檢視的維度欄位由右邊的清單拉曳到畫面中灰色字體請將篩選欄位拖曳到這裏等 3 個位置, 而將要檢視的量值欄位拉曳到中下方的部分。 舉例來說, 我們要檢視各產品在各國家於各年中的銷售數字, 可如下操作：

測試 Cube 從左邊的窗格, 將 Dim Sales Territory 維度的 Sales Territory Country 欄位拉曳到請將篩選欄位拖曳到這裏。 將 Order Date 維度的 CalendardYear 和 CalendardQuarter 欄位拉曳到將欄欄位拖曳到這裏。 將 Dim Product 維度的 Model Name 欄位拉曳到將列欄位拖曳到這裏。 將 Measure 中的 Sales Amount 欄位拉曳到請將總和欄位或詳細資料欄位拖曳到這裏。

測試 Cube 結果就如下圖所示：

15-5 應用簡例之二： 使用資料採礦分析 Cube 內容 本節同樣以一段簡短的操作示範資料採礦的應用, 這個例子只是讓讀者更具體認識資料採礦的應用。 但若要建立實用的資料採礦結構, 請進一步參閱 SQL Server 2005 線上叢書及其它相關專書。

應用簡例之二： 使用資料採礦分析 Cube 內容 以精靈建立資料採礦結構及採礦模型 部署及檢視結果

以精靈建立資料採礦結構　　　　　　　　　及採礦模型 在 Analysis Services 中, 採礦模型是放在採礦結構 (Data Mining Structure) 中。資料採礦結構定義了所要分析資料的範圍, 且每個結構中可含有多個採礦模型。 要建立資料採礦結構, 同樣需在 Business Intelligence Development Studio 的 Analysis Services 專案中建立, 建立資料採礦結構的專案並不需先建立 OLAP 的 Cube, 而可直接由 SQL Server 2005 的資料倉儲取得資料來進行分析, 不過此處仍直接用上一節的 Cube 為資料採礦結構的資料來源。

以精靈建立資料採礦結構　　　　　　　　　及採礦模型 假設現在有一組社會人士的教育程度、家中子女數、自有車輛數、年數入、有無自購住宅的資料樣本, 而我們想瞭解什麼樣的人自購住宅的比例較高, 此時就可建立資料採礦結構來進行分析。 本例就以 Dim.Customer 客戶維度當成資料樣本來進行分析, 而分析的演算法就選用 Microsoft Decision Tree (決策樹)：

以精靈建立資料採礦結構　　　　　　　　　及採礦模型

以精靈建立資料採礦結構　　　　　　　　　及採礦模型

以精靈建立資料採礦結構　　　　　　　　　及採礦模型

以精靈建立資料採礦結構　　　　　　　　　及採礦模型

以精靈建立資料採礦結構　　　　　　　　　及採礦模型

以精靈建立資料採礦結構　　　　　　　　　及採礦模型

以精靈建立資料採礦結構　　　　　　　　　及採礦模型

以精靈建立資料採礦結構　　　　　　　　　及採礦模型

以精靈建立資料採礦結構　　　 　　　　 及採礦模型

以精靈建立資料採礦結構　　　　　　　　　及採礦模型

部署及檢視結果 建立好的採礦結構同樣要部署到 Analysis Services 後才能使用：

部署及檢視結果 和 Cube 一樣, Business Intelligence Development Studio 也提供一個可讓我們檢視採礦模型及採礦結果的檢視器：

部署及檢視結果

部署及檢視結果 由於前面選用決策樹的演算法, 所以看到的就是將樣本資料依各種屬性分成樹狀結構的情形：

部署及檢視結果

部署及檢視結果 除了直接檢視整個決策樹的內容, 我們也可查看經過分析後, 決定是否購屋較重要的影響因素為何：

部署及檢視結果

部署及檢視結果 當我們將左側的滑桿向關聯性最強的連結移動時, 會發現圖中 Yearly Income指向 House Owner Flag 的箭頭消失, 表示『年收入』與是否有房子的關連性不大；若將滑桿再向下移一格, 連 Numbers Cars Owned 指向 House Owner Flag 的箭頭也消失, 表示『家中有無子女』與是否有房子的關連性比較大。

部署及檢視結果 本章只是用最陽春的方式示範使用 Business Intelligence Development Studio建立 OLAP Cube 及採礦結構/ 採礦模型的情形, 旨在讓讀者對 Analysis Services 的應用有基本的概念。 至於 Analysis Services 各項進階功能, 有興趣的讀者可自行參閱線上叢書中的說明及教學課程。