SQL Server 2005線上即時分析新架構：統一維度模型

SQL Server 2005是微軟資料庫發展上的一大改版，影響所及，Analysis Services所提供的OLAP（On-Line Analytical Processing）查詢分析架構，也有革命性的改變。

微軟徹底改變過去OLAP由上而下的資料構築模式，推出全新的UDM（Unified Dimensional Model，統一維度模型）技術，以屬性（Attribute）為基礎，發展出由下而上的彈性維度架構，試圖提供更佳的存取效率和資料整合模式。

資料源與用戶端工具的橋樑
從最簡單的概念來說，UDM是銜接資料來源與用戶端工具之間的橋樑，它任務在於讓使用者更容易、快速地查詢、分析資料。而在建置資料模型時，必須兼顧日後使用者能夠從業務面向檢視與理解資料。

以屬性為基礎，維度架構更具彈性
OLAP通常是指的就是多維度分析，而在維度計設時，基本的概念可以區分為維度與量值，所謂的維度，指的就是企業用來分析的基本單位，例如地區、產品、時間、員工、客戶等這些具有分析意義的概念。而量值則是可以加總計算的資料，例如銷售額、銷售量等。

資料形塑更具商務導向
UDM在資料檢視階段可以設定「友善命名（Friendly Name）」屬性，另外指定新的欄位名稱，替換成讓使用者可以一看即知的產業術語，畢竟只有了解資料的意義才能進一步進行分析。在設定友善命名之後，後續的開發或使用人員的工具介面，都可以抓取友善命名作為顯示名稱。資料源與用戶端工具的橋樑

從最簡單的概念來說，UDM是銜接資料來源與用戶端工具之間的橋樑，它任務在於讓使用者更容易、快速地查詢、分析資料。

這個過程聽來容易，但是身處在企業真實情境中，資料來源有可能來自不同的資料庫或是ERP、CRM等應用程式，甚至散落在像Excel這類非結構化的文件資料中。

其次，查詢資料也會因為目的或呈現的方式不同，例如可能透過報表工具或專用的動態報表程式查詢，或者可能透過Excel，往往不同的程式便需要準備不同的存取資料來源或格式，因此企業就必須維護不同型態的資料來源，儘管這些資料有一定的比例的重複性。

面對這種複雜的情境，根本的解決之道是將不同的異質資料來源整合成一致性的資料型態，再提供統一的查詢通道，並且設法讓查詢速度在企業能接受的效率之內。

從另一個層面來說，分析、查詢的本質是業務導向，因此在建置資料模型時，必須兼顧日後使用者能夠從業務面向檢視與理解資料。綜上所述，便是SQL Server 2005導入UDM的目標。

目前專為查詢設計的資料結構類型
資料倉儲或是OLAP資料模型，都是以查詢目的所設計的資料儲存結構，而UDM在傳統的資料結構上提出更為彈性的資料存取方式。在深入UDM之前，首先我們檢視目前常見的資料儲存架構。

不管是資料倉儲或是OLAP系統，與一般交易型資料庫的差異所在，是因為查詢、分析這個目的而造成。OLTP（On-Line Transaction Processing）資料庫是以快速完成交易記錄為主，效能要求的重點在快速完成少量資料的新增、修改、刪除或查詢，通常是透過三階段正規化的手法將資料表拆解成一張張不重複的資料表，透過主鍵（Primary Key）和外鍵（Foreign Key）的關係將資料表串接起來，這也就所謂的E-R模型。

然而當資料庫查詢時，需要結合（join）不同資料表，效能就會下降，尤其查詢資料量大，結合的資料表多時，更形明顯。因此E-R模型這種透過不斷分割資料表以求取效能的方式，一旦遇上需要從過去資料中提取出大量的彙總資料，反而會造成牛步運轉的結果，這也是企業報表有時要等上好幾個小時，甚至幾天才能獲取結果的原因。

因此為了大量查詢的目的，就必須將分割出去的資料表再收攏回來，這樣的概念，就形成了所謂的星狀資料結構（Star Schema）或雪花資料結構（Snowflake Schema），由一個事實資料表（Fact Table）作為核心，當中的欄位是可用來彙總的資料，另外再結合一些具敘述性欄位的資料表，這種結構看來就像星星一樣，這也是星狀資料結構一詞的由來。

透過星狀結構方式儲存資料，如果是以關聯式資料庫的方式儲存，稱之為ROLAP（Relational On-Line Analytical Processing），而以多維度立方體（Cube）方式儲存的方式，稱之為MOLAP（Multi-dimensional On-Line Analytical Processing），在實務上兩者各有優缺點，ROLAP在維度的數量、資料細節上有較大優勢，而MOLAP則具備查詢速度快，而它們各自的優點，也就是對方的缺點。在實務上，商業智慧分析需要同時擁有這些優點，因此整合式的架構日受重視，UDM便具備整合MOLAP與ROLAP的架構。以屬性為基礎，維度架構更具彈性

OLAP通常是指的就是多維度分析，而在維度計設時，基本的概念可以區分為維度（Dimension）與量值（Measure），所謂的維度，指的就是企業用來分析的基本單位，例如地區、產品、時間、員工、客戶等這些具有分析意義的概念。而量值則是可以加總計算的資料，例如銷售額、銷售量等。而透過多種維度交錯結合，就可以分析像「去年同期在臺北總共有多少銷售額？」或是「上半年電器類產品有多少銷售量？」這類複雜的分析、查詢。

進行維度分析查詢時，SQL Server 2000的限制在於它的事實資料表只能有一個，因此對於較為複雜的查詢就顯得力有未逮。另外在維度數量上，一旦維度量增加，效能也會跟著下降，而且一旦分析需求調整時，往往必須新增維度或者採用虛擬維度的方式，造成Cube體積膨脹，維護也更為麻煩。

而UDM以屬性基礎（Attribute-based）的特色，對於上述的問題提出解答。屬性相當於SQL Server 2000中的層級（Level）和屬性（Property）的組成概念，它是維度的最小組成單位，例如時間中的「天」，產品中的「產品型號」，而維度中如果需要區分階層，則可以由屬性的排列組合來構成，這和過去由上而下先定義資料階層，再定義各層級成員的方式相反，轉變成由下而上，層層堆疊的方式。如此一來，不但維度的階層組合不但變得更為彈性，增加維度時也不會因此大量增加資料，使得多維度立方體立方體能增加大量的維度，也能保留細節資料。

這種抽象架構的設計，讓過去的事實資料表轉變成量值群組（Measure Group），所以一個Cube可以擁有多個事實資料表，因此超越過去的星狀結構與雪花狀結構，成為星座結構（Constellation Schema）。UDM導入量值群組與維度／量值關聯性等抽象架構，讓E-R模型與OLAP之間的界限更形模糊，而能兼擅兩者之間的優點，讓分析的面向可以更為彈性與多元。

將異質資料整合在OLE DB之下
UDM既然作為資料與使用者工具之間的橋樑，就必須要有整合與簡化溝通的方式。就整合異質來源的作法上，UDM透過OLE DB Provider作為介面連結不同的資料來源。將異質資料來源都轉成OLE DB資料，可以讓資料留在原來的資料庫或應用程式上，而不需將異質資料源匯整到同一個平臺之後才能進行後續的存取工作，不但降低了資料倉儲的負擔，也讓轉換維護工作降低，而且可以進行跨資料源的連結，例如結合SQL Server與Oracle的資料表，進行彙總分析。利用SQL Server 2005新工具BI Management Studio的「資料來源檢視」功能，使用者就能定義異質資料表之間的關連性，只要在單一介面就可以整合資料存取。

在前端存取工具上，過去是透過OLE DB for OLAP的方式存取Analysis Services 2000，因此前端工具必須有支援或者另行安裝樞紐服務（Pivot Table Services），而現在則透過XML/L的Web Services存取介面，因此前端工具只需透過Web Services的方式，就能存取OLAP資料，讓傳統靜態報表和動態式報表的存取資料來源差異，隨之消除。資料形塑更具商務導向

在分析資料時，使用者看到的資料，就是他可以分析的物件。而我們知道採用E-R模型的交易型資料庫，資料表會有許多與商務無關的欄位，用來存放像主鍵、最後更新日期或資料記錄版號等資訊。此外，就設計者而言，欄位名稱通常採用資料庫設計思維來命名，而非商務思維，例如說某些具有業務意義必須是結合數個欄位才有結果，或者最常見的，採用英文的欄位名稱等。

UDM在資料檢視階段可以設定「友善命名（Friendly Name）」屬性，另外指定新的欄位名稱，替換成讓使用者可以一看即知的產業術語，畢竟只有了解資料的意義才能進一步進行分析。在設定友善命名之後，後續的開發或使用人員的工具介面，都可以抓取友善命名作為顯示名稱。

另外，UDM也提供多國語系功能，可以依據使用者的電腦語系自動切換，對於跨國型企業可以藉由單一資料模型，進行一致的商業分析。

主動式快取機制提升存取速度
UDM在資料結構方面消除了ROLAP和MOLAP的界限，不過以MOLAP的Cube方式進行查詢時，仍免不了會遇到Cube的資料不是最新的情況，這也是過去MOLAP為人詬病之處。

SQL Server 2005事實上是採用主動式快取（Proactive Caching）的方式突破這個限制，一旦原始資料更新時，系統通知UDM，這時UDM就會採用ROLAP的方式，透過SQL語法查詢新增資料，放置到快取區中，等待下次進行Cube更新時，再將這些新資料放回Cube。利用這種方式，不但保持MOLAP的查詢速度，也能保有ROLAP的即時性。

升級將會帶來挑戰
整體而言，UDM這個全新的資料架構，翻寫過去SQL Server 2000在Analysis Services對資料的處理方式，而且在維度物件的組成與架構全然不同，對於開發人員而言，不論是觀念的調整或實際操作使用上，必然形成新的挑戰。即使系統提供不少精靈式的對話式引導，不過這種方式通常也只適合簡單的資料架構，經常還是需要手動調整，如果企業寄望按個按鈕就可以將Cube建立起來，目前看來這還是個太遙遠的夢想，開發人員還是得從理解UDM這個新架構著手，才能妥善應用新系統。

此外，UDM帶來許多效益，例如可以使用多個事實資料表，維度可使用的資料量也大幅增加，支援KPI（Key Performance Indicators）等功能，對於SQL Server 2000的Analysis Services用戶帶來相當大的吸引力，但是由於物件架構的改變，在升級上也會帶來問題。

像是UDM改採OLE DB作為資料源的介面，如果在2000版本採用ODBC介接資料源，就必須重作設定。另外如不支援隱藏、停用維度內的層級，或是對舊版父子式維度的一些作法不再支援，MDX函數的支援度調整、自訂函數的停用等，都會影響到舊有的Analysis Services設計，造成升級之後必須要再手動調整、設定。

由於差異性頗大，冒然升級的失敗率必然大增，因此微軟建議如果有升級的打算，最好能使用「Microsoft SQL Server Upgrade Advisor」程式，對現行架構進行分析，找出升級會遇到的議題。這個程式在SQL Server 2005的光碟中就有提供，維護資料庫人員可以根據分析的結果，再仔細評估升級的可行性。文⊙黃天賜