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

一、選擇業務過程

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

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

數據倉庫人員不僅要詳細了解業務過程，還要充分理解用戶需求（特別是他們的KPI），因為用戶一般很難回答：“你對哪些業務過程感興趣”，而是使用BI分析來自業務過程的性能度量

我們即需要理解上面的什麽是業務過程，也需要理解如下的什麽不是業務過程。比如部分功能劃分就不是業務過程，我們應該將註意力放在業務過程而不是不同的部門，這樣才能避免重復的獲取數據。

二、聲明粒度

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

三、確定維度

如果粒度合適，維度很容易確定，因為維度是用來描述：“誰、何時何地、為何、如何”。比如常用的維度是：日期、產品、景區

四、確定事實

回答：“業務的度量是什麽”來思考事實。屬於不同粒度的事實要放在不同的事實表中。

總結

強烈抵制僅僅考慮數據來源建模的方案，比如訂單類數據，是從tts獲取的，那麽就將這些數據放在一起。這樣雖然比了解業務過程方便很多，但數據不能代替用戶的輸入，這樣做基本註定會失敗！

需要綜合考慮業務用戶徐妞和數據來源的實際情況，並與四步聯系起來，如下圖所示的建模方案。

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