《數據倉庫工具箱》——建模四步驟

Kimball建模方法的精髓，就是簡單、使用，建模這四步驟是它的核心部分。用術語表達是：始終一致的四步設計維度模型，分別以下：

1、選擇業務過程

業務過程是由組織完成的一系列微觀活動，例如：完成下單、完成支付、發放代金券、上線產品等等。充分理解它們，有助於辨別組織中的不一樣業務過程，它通常具備這些特性：

• 用行爲動詞表示：它們一般表示業務過程的活動，好比下單、支付、退款等
• 通常由某個操做系統支持：好比下單由交易系統支持、產品上架由產品中心支持等
• 生成度量：度量通常由操做過程直接生成，好比用戶支付金額，由用戶支付過程直接產生。分析人員通常工做事件分析度量結果。一句話總結：一系列過程產生一系列事實表

數據倉庫人員不只要詳細瞭解業務過程，還要充分理解用戶需求（特別是他們的KPI），由於用戶通常很難回答：「你對哪些業務過程感興趣」，而是使用BI分析來自業務過程的性能度量

咱們即須要理解上面的什麼是業務過程，也須要理解以下的什麼不是業務過程，這樣才能取捨。好比不一樣部門的功能劃分就不是業務過程，咱們應該將注意力放在業務過程而不是不一樣的部門，這樣才能避免重複的獲取數據。

2、聲明粒度

粒度是說明事實表的每一行表示什麼。好比：用戶下單的內容放倒訂單事實表的每一行中。這裏的關鍵是粒度的描述，不能講維度列出來，而代替粒度聲明。這一步特別容易被忽略，粒度聲明須要達成共識，不然極有可能到下面三四步以後返工重來

3、肯定維度

若是粒度合適，維度很容易肯定，由於維度是用來描述：「誰、什麼時候何地、爲什麼、如何」。好比訂單經常使用的維度是：日期、產品、供應商、訂單狀態、退款狀態等

4、肯定事實

用「業務的度量是什麼」來思考事實。屬於不一樣粒度的事實要放在不一樣的事實表中。

有人可能疑惑粒度和事實的區別是啥，粒度說明了事實的每一行表明什麼意思，而事實是裏面包含哪些列，好比成交金額、退款金額、購買份數等等

總結

強烈抵制僅僅考慮數據來源作爲建模的方案，好比訂單類數據，是從交易系統獲取的，那麼就將這些數據放在一塊兒。這樣雖然比了解業務過程方便不少，但數據不能代替用戶的輸入，這樣作基本註定會失敗！

須要綜合考慮業務用戶需求和數據來源的實際狀況，並與上面四步聯繫起來，以下圖所示的建模方案：

5、冗餘維度

在現實應用中，事實表是須要作適度冗餘的，kimball之因此減小冗餘，目的是減小存儲消耗。而在實際中，須要考慮下游用戶的使用效率，下降獲取數據的複雜性，減小關聯表的數量，因此冗餘好比產品名稱、品類名稱等，這樣就提高過濾查詢、統計聚合的效率