[EDW] Oracle 購併 SUN 對商業智慧&資料倉儲的影響

SUN的購併案在確定由Oracle接收而非IBM後, 市場一片譁然. 多數人還不清楚Oracle為何選擇出手, 因為以硬體而言, 多數的Oracle平台都在HP或IBM的機器，低階的也許是Linux，但是SUN的主力卻是Solaris（Sparc). 既然硬體機會不大，比較可能的著眼點應該就是SUN的Java技術，大家可別忘了SUN才是Java的原創者，雖然目前市場上的Java應用反而以IBM，Oracle或其他應用為主.

Oracle的商業智慧應用有像純以Java開發的Discoverer, 部分應用是用C++和.Net，甚或Hyperion的一些技術. 所以可以想見未來的Oracle商業智慧會越來越往Java平台靠攏和Oracle的WebLogic整合. 還有一個可能是，別忘了，SUN才剛將MySQL納入其麾下，在併入Oracle後，也許一些低階的商業智慧需求，Oracle可以透過MySQL來攻打市場. MySQL的市佔率可不容小覷，因為一堆個人網站因為成本考量，採用MySQL的比率很高.

原文引用： http://www.rittmanmead.com/2009/04/20/oracle-buys-sun-what-does-it-mean-for-oracle-bidw/

[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設計的技巧. 

[EDW] Oracle 的硬體夢 - HP Oracle Database Machine

連著兩期的ORACLE雜誌都在介紹Oracle和HP聯手推出專門針對Data Warehouse市場的主機. 這一期還是放在封面故事，可見Oracle對此產品的重視. 到底這台主機有什麼魔力，對Data Warehouse又有啥幫助呢？

現在的商業環境越行複雜，決策人員要作分析時所需要的資料維度也比以往更多元，導致資料庫的資料量是以倍數的成長. 這時候，商業智慧軟體如何確定使用者在作分析查詢時的效能不受資料量倍增的影響呢？調整程式SQL當然是一個作法，但參考http://oracle-wei.blogspot.com/search/label/Performance%20Tune, 從底層硬體著手才是王道.

而對資料倉儲而言，效能的瓶頸會在哪裡呢？CPU，MEMORY還是IO？多數人會回答IO，沒錯，資料倉儲的特性就是AD-HDC QUERY一堆，FULL TABLE SCAN更是屢見不鮮，個個都是IO殺手. 對此，Oracle和HP聯手推出一款用八台配備Intel CPU的Database server架構成的Database Grid加上Linux OS還有由14台HP Oracle Exadata組成的Storage Grid. 號稱可提供168 terabyte和14GB per second的資料存取頻寬. 資料存取的改善又來自於InfibiBand的光纖技術大幅加快了Database和Storage之間得存取速度. 看看Oracle怎麼介紹這個產品呢？





那到底Oracle和HP還用了啥麼伎倆呢？ 因為硬體誰都會做，上述的硬體花錢不就解決了嗎？ Oracle的說法是透過減少資料的傳遞量, 也就是資料在 Database和Storage之間的傳遞. 這個硬體可以將SQL的運算盡可能做在 Storage端， 而非傳統的Database端，也就是說回傳給Database端的不是Data Block而是查詢結果. 如此一來，資料的傳遞量自然大幅下降.

最後一提的是這些設定都是 Pre-Configured也就是客戶不用花太多功夫再做設定，即可享用這些好處. 兩個資訊界的巨人現在打破藩籬，試著提供給客戶更好的服務，大家拭目以待吧！