原文：

為何要引入資料倉庫？

企業建立資料倉庫是為了填補現有資料儲存形式已經不能滿足資訊分析的需要。資料倉庫理論中的一個核心理念就是：事務型資料和決策支援型資料的處理效能不同。

企業在它們的事務操作收集資料。在企業運作過程中：隨著定貨、銷售記錄的進行，這些事務型資料也連續的產生。為了引入資料，我們必須優化事務型資料庫。

處理決策支援型資料時，一些問題經常會被提出：哪類客戶會購買哪類產品？促銷後銷售額會變化多少？價格變化後或者商店地址變化後銷售額又會變化多少呢？在某一段時間內，相對其他產品來說哪類產品特別容易賣呢？哪些客戶增加了他們的購買額？哪些客戶又削減了他們的購買額呢？

事務型資料庫

資料倉庫的解決方法包括：將決策支援型資料處理從事務型資料處理中分離出來。資料按照一定的週期（通常在每晚或者每週末），從事務型資料庫中匯入決策支援型資料庫——既“資料倉庫”。資料倉庫是按回答企業某方面的問題來分“主題”組織資料的，這是最有效的資料組織方式。

另外，企業日常運作的資訊系統一般是由多個傳統系統、不相容資料來源、資料庫與應用所共同構成的複雜資料集合，各個部分之間不能彼此交流。從這個層面看：目前執行的應用系統是使用者花費了很大精力和財力構建的、不可替代的系統，特別是系統的資料。而建立資料倉庫的目的就是要把這些不同來源的資料整合組織起來統一管理，從而做到資料的一致性與整合化，提供一個全面的，單一入口的解決方案。這個讓我聯想到SOA的理念，不過前者是資料層面的整合優化，後者是應用服務層面的整合優化。

主題（Subject）

主題就是指我們所要分析的具體方面。例如：某年某月某地區某機型某款App的安裝情況。主題有兩個元素：一是各個分析角度（維度），如時間位置；二是要分析的具體量度，該量度一般通過數值體現，如App安裝量。

維（Dimension）

維是用於從不同角度描述事物特徵的，一般維都會有多層（Level：級別），每個Level都會包含一些共有的或特有的屬性（Attribute），可以用下圖來展示下維的結構和組成：

以時間維為例，時間維一般會包含年、季、月、日這幾個Level，每個Level一般都會有ID、NAME、DESCRIPTION這幾個公共屬性，這幾個公共屬性不僅適用於時間維，也同樣表現在其它各種不同型別的維。

分層（Hierarchy）

OLAP需要基於有層級的自上而下的鑽取，或者自下而上地聚合。所以我們一般會在維的基礎上再次進行分層，維、分層、層級的關係如下圖：

每一級之間可能是附屬關係（如市屬於省、省屬於國家），也可能是順序關係（如天週年），如下圖所示：

量度

量度就是我們要分析的具體的技術指標，諸如年銷售額之類。它們一般為數值型資料。我們或者將該資料彙總，或者將該資料取次數、獨立次數或取最大最小值等，這樣的資料稱為量度。

粒度 
資料的細分層度，例如按天分按小時分。

事實表和維表

事實表是用來記錄分析的內容的全量資訊的，包含了每個事件的具體要素，以及具體發生的事情。事實表中儲存數字型ID以及度量資訊。

維表則是對事實表中事件的要素的描述資訊，就是你觀察該事務的角度，是從哪個角度去觀察這個內容的。

事實表和維表通過ID相關聯，如圖所示：

星形(star schema)/雪花形(snowflake schema)/事實星座(Fact Constellation)這三者就是資料倉庫多維資料模型建模的模式.

上圖所示就是一個標準的星形模型。

雪花形就是在維度下面又細分出維度，這樣切分是為了使表結構更加規範化。雪花模式可以減少冗餘，但是減少的那點空間和事實表的容量相比實在是微不足道，而且多個表聯結操作會降低效能，所以一般不用雪花模式設計資料倉庫。

事實星座模式就是星形模式的集合，包含星形模式，也就包含多個事實表。

企業級資料倉庫/資料集市

企業級資料倉庫：突出大而全，不論是細緻資料和聚合資料它全都有，設計時使用事實星座模式。

資料集市：可以看做是企業級資料倉庫的一個子集，它是針對某一方面的資料設計的資料倉庫，例如為公司的支付業務設計一個單獨的資料集市。由於資料集市沒有進行企業級的設計和規劃，所以長期來看，它本身的整合將會極其複雜。其資料來源有兩種，一種是直接從原生資料來源得到，另一種是從企業資料倉庫得到。設計時使用星形模型。