> 接著上一篇[文章](https://www.cnblogs.com/shenfeng/p/datawarehouse_intro_1.html)介紹了資料倉庫的發展歷史和基本概念，本文將著重介紹資料倉庫的主流建模方式——維度建模。 # 01 業務分析與維度建模 常見的業務分析過程，包含對分析物件的定性分析和定量分析。維度建模在確定一個主題後，會將資料儲存在事實表和維度表。對比下這兩個分類，非常巧合的，在維度模型裡面維度表存放的是分析**主題的屬性**，對應於**定性分析**；而事實表中存放的是屬性組合下的**數量度量**，對應於**定量分析**。 以分析銷售主題為例，對於銷售可量化的資料如銷售金額、銷售數量等可以量化的資料是存在事情表中。對銷售有影響的屬性如，地區、產品、時間等。 同時，每個主要的影響因子維度下，存在多種不同的粒度，比如地區可以按照省、市、區進行劃分；時間可以按照季度、月度甚至節假日等進行劃分。在分析業務時，可以使用魚骨圖將這些因子羅列起來。下圖為使用魚骨圖做的銷售主題的歸因或者相關分析。  # 02 事實表和維度表 上文中已經提到事實表中存放定量資料，按照Kimball在《The Data Warehouse Toolkit, 3rd Edition》的定義：在維度模型中，事實表存放業務事件的測度(perfromance measurement)結果。事件的測試，對於銷售事件來說，常規的如金額、商品件數等。在維度模型下，獲取的測度值需要在各個維度的最小粒度下獲取。例如在產品維度上，原始系統資料一個訂單上可能包含多個不同的產品，但因為若在產品維度上需要維持到SKU的粒度， 我們就需要對原始訂單進行SKU拆分之後接入到事實表。 事實表中的每一行資料必須保持在相同的粒度，否則就會重複資料。現實事件的每一次測度和事實表中的每一行記錄是一一對應的，如下圖所示。  從上圖的事實表中，可以看到其欄位主要分為3種類型，包括用於每行記錄的主鍵、關聯維度表的外來鍵以及測度結果值(如銷售任務)。 記錄的主鍵，在上圖中為單次交易的流水號，作為每條記錄的唯一標識。 事實表中的外來鍵，用於關聯維度表中的主鍵。通過外來鍵關聯，可以獲取每條事實記錄的維度在不同粒度下的值。並且，事實表的外來鍵數量肯定是大於等於兩個的。因為只有一個維度的情況下，在一行記錄上給出所有的維度粒度即可，不需要再進行2次關聯。 測度結果值(通常都為數字型別)，可以分成3種類型：可加總型(additive)，半加總型(semi-additive)和非加總型(non-additive)。其中，可加總型是指類似於銷售金額、銷售件數等可以在所有維度都進行累加的值。半加總型是指類似於賬戶餘額等可以在客戶維度累加，但是不能在時間維度上累加的值。非加總型是指如件單價等在任何維度上累加都不存在實際意義的值。 維度表中儲存的是與測度事件相關的文字描述資訊，用於說明每一條事件記錄的“who, what, where, when, how, and why“。與事實表相比，維度表的行數相對要少很多，但是欄位數量相對要多(與描述的屬性粒度相關)。 維度表中的每一個描述欄位或者說「屬性」是進行業務分析時作為查詢約束、分組和資料標籤的基礎。維度屬性值一般使用含義明確的文字方式表示，這樣受眾可以更好地理解資料處理的報表和分析結果。如果因為屬性文字過大等情況，採用數值編碼方式儲存的屬性在生成查詢結果或報表時需要對數值編碼進行解釋。 # 03 星型模型 在建立分析主題的事實表和維度表之後，通過外來鍵關係便可以將事實表和維度表關聯起來。關聯之後的ER圖，呈放射狀，稱之為「星型模型」，如下圖所示。  相對於關係資料庫中的正規化設計，維度設計中的星型模型不用考慮複雜的程式流程，是一種業務分析人員友好的資料組織方式。同時，在分組聚合時有更好的查詢效能，具有較好的擴充套件性——支援增加維度和事實測度結果值。 # 04 總結 本文從業務分析的歸因/相關性分析的方式，引入了維度建模，兩者具有相同分析路徑。然後介紹了維度建模的基礎——事實表和維度表，以及關聯之後得到星型模型。 **歡迎掃描二維碼關注公眾號** ![](https://img2018.cnblogs.com/blog/670593/201912/670593-20191201214002980-30853