《数据仓库工具箱》——建模四步骤

Kimball建模方法的精髓，就是简单、使用，建模这四步骤是它的核心部分。用术语表达是：始终一致的四步设计维度模型。

一、选择业务过程

业务过程是由组织完成的一系列微观活动，例如：完成下单、完成支付、发放代金券、上线产品等等。充分理解它们，有助于辨别组织中的不同业务过程，它一般具有这些特性：

• 用行为动词表示：它们通常表示业务过程的活动，比如用户下单、用户支付、商家退款等
• 一般由某个操作系统支持：比如下单由tts支持、产品上架由产品中心支持等
• 生成度量：度量一般由操作过程直接生成，比如用户支付金额，由用户支付过程直接产生。分析人员一般工作事件分析度量结果。一句话总结：一系列过程产生一系列事实表

数据仓库人员不仅要详细了解业务过程，还要充分理解用户需求（特别是他们的KPI），因为用户一般很难回答：“你对哪些业务过程感兴趣”，而是使用BI分析来自业务过程的性能度量

我们即需要理解上面的什么是业务过程，也需要理解如下的什么不是业务过程。比如部分功能划分就不是业务过程，我们应该将注意力放在业务过程而不是不同的部门，这样才能避免重复的获取数据。

二、声明粒度

粒度说命名事实表的每一行表示什么。比如：用户下单的内容放倒订单事实表的每一行中。这里的关键是粒度的描述，不能讲维度列出来，而代替粒度声明。这一步特别容易被忽略，粒度声明需要达成共识，否则极有可能到下面三四步之后返工回来

三、确定维度

如果粒度合适，维度很容易确定，因为维度是用来描述：“谁、何时何地、为何、如何”。比如常用的维度是：日期、产品、景区

四、确定事实

回答：“业务的度量是什么”来思考事实。属于不同粒度的事实要放在不同的事实表中。

总结

强烈抵制仅仅考虑数据来源建模的方案，比如订单类数据，是从tts获取的，那么就将这些数据放在一起。这样虽然比了解业务过程方便很多，但数据不能代替用户的输入，这样做基本注定会失败！

需要综合考虑业务用户徐妞和数据来源的实际情况，并与四步联系起来，如下图所示的建模方案。