資料倉庫知識點梳理(2)
本文從業務分析的歸因/相關性分析的方式，引入了次元模組化，兩者具有相同分析路徑。然後介紹了次元模組化的基礎——事實表和次元表，它們關聯之後的産物即星型模型。
接着上一篇文章介紹了資料倉庫的發展曆史和基本概念，本文将着重介紹資料倉庫的主流模組化方式——次元模組化。
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 總結
本文從業務分析的歸因/相關性分析的方式，引入了次元模組化，兩者具有相同分析路徑。然後介紹了次元模組化的基礎——事實表和次元表，以及關聯之後得到星型模型。
歡迎掃描二維碼關注公衆号