[EDW] Enterprise Data warehouse - Star Schema

Enterprise Data Warehouse的架構中，Star schema是最常使用的Schema設計概念, 又稱為Dimensional Modeling. 它的精神就是將商業流程用一個一個星星（STAR）去代表，舉例而言，STAR像是營收，但看營收又會根據月份，產品別等維度來看. 維度就是Dimension. 所以Star Schema的設計就是透過分析商業流程將ERP, MES等前端系統的資料將其轉置為Fact和Dimension Table. 後續在做資料呈現時，不論是WEB或其他報表工具，透過Star transformation從ORACLE擷取資料，這也是ORACLE官方建議的作法. 這裡就談一下Star Schema這個概念，主要是從以下書籍(data warehouse design solution)和WIKI而來.

定義

Star schema 由 WIKI-fact tables (通常只有一個) 和其引用到的多個 WIKI-dimension tables所組成.

運作模式

談Data warehouse常常會和OLTP系統相比較. 所謂OLTP就是由一系列的Event和Transactions所組成配合OLTP正規化的基本設計精神. OLTP正規化的目的是確保資料的一致性和減少資料重複儲存. 但是在這個架構之下，當要回答前述如二月份某產品的營收有多少時？OLTP系統通常無法快速提供答案，原因也正如前所述，因為正規化，一個如上簡單的問題對OLTP系統可能要下一個SQL連接五六個Table. 正因為這樣的問題，Star Schema孕育而生.

以上為例，營收資料在Star Schema中就叫Measure, Measure可能包含營收金額，出貨數量，毛利率，發票號碼等，而擺放Measure的Table就叫Fact Table. 而這些Measure如何被商業人員查詢，查詢的進入點就叫Dimension. Dimension可能包含出口國家，產品別，銷售客戶，銷售日期等等.

EDW設計人員在將商業流程分析後，產生所謂的Measure和Dimension後，進入Table設計階段. 如以下的一個STAR範例.

Fact Table除了包含主要Measure資料外，還會有包含連接到Dimension Table的Foreign Key. 而Dimension Table則由Dimension key(Primary Key)和屬性(Attribute)所組成.

如這個例子，Fact是 由Measure-Unit_Sold和三個Dimension Key(Store_ID,Product_ID,Date_ID)所組成. 而每個dimension table都有一個 primary key和相關的屬性，如日期，週別，商店州別等等屬性. 所以當要查詢某品牌某商店的賣出數量時，使用以下SQL可以得到答案.

        =================================================
       SELECT P.Brand,S.Country, SUM (F.Units_Sold)
          FROM Fact_Sales F INNER JOIN Dim_Date D ON F.Date_Id = D.Id
               INNER JOIN Dim_Store S ON F.Store_Id = S.Id
               INNER JOIN Dim_Product P ON F.Product_Id = P.Id
         WHERE D.Year = 1997
               AND P.Product_Category = 'tv'
         GROUP BY P.Brand, S.Country;
      ===================================================

Fact Table
在設計Fact Table時要特別注意的是所謂的細度(Grain)，所謂細度就是Fact Table中的每一筆
記錄，都擁有一樣的細度. 以上面的例子而言，Fact Table的每一筆資料都屬於同一張發票項目
（Item). 這個意義代表前端ERP系統的發票項目一定是同一Store,Date和Product，如此資料才能
被正確從ERP轉換至EDW，EDW也才能正確呈現資料.

Dimension Table
如前所述，Dimension Table由Dimension Key和 Dimension Attributes所組成. 作者特別強調在
這裡要儘量避免將Table作正規化，因為一旦做正規化，查詢效能會大受影響.

MDB
Star Schema通常發生在關連式資料庫中，但也有像Business Object, Hyperion, Teradata等廠
商有他們自己專用的多維度資料庫(MultiDimensional Database），又稱為Cube. 這些Cube搭配
這些廠商專用的資料呈現軟體， 通常可以很快速的將資料呈現出來，而且還可以做類似EXCEL的
樞紐分析. 但是也有限制，就是資料量的大小有限制. 這也是將Star Schema推導在關連式資料
庫的目的去移除資料量的限制.

下文再看看更多Fact/Dimension Table設計的技巧.