Kimball建模方法的精髓，就是简单、使用，建模这四步骤是它的核心部分。用术语表达是：始终一致的四步设计维度模型，分别如下：
一、选择业务过程
业务过程是由组织完成的一系列微观活动，例如：完成下单、完成支付、发放代金券、上线产品等等。充分理解它们，有助于辨别组织中的不同业务过程，它一般具有这些特性：
- 用行为动词表示：它们通常表示业务过程的活动，比如下单、支付、退款等
- 一般由某个操作系统支持：比如下单由交易系统支持、产品上架由产品中心支持等
- 生成度量：度量一般由操作过程直接生成，比如用户支付金额，由用户支付过程直接产生。分析人员一般工作事件分析度量结果。一句话总结：一系列过程产生一系列事实表
数据仓库人员不仅要详细了解业务过程，还要充分理解用户需求（特别是他们的KPI），因为用户一般很难回答：“你对哪些业务过程感兴趣”，而是使用BI分析来自业务过程的性能度量
我们即需要理解上面的什么是业务过程，也需要理解如下的什么不是业务过程，这样才能取舍。比如不同部门的功能划分就不是业务过程，我们应该将注意力放在业务过程而不是不同的部门，这样才能避免重复的获取数据。
二、声明粒度
粒度是说明事实表的每一行表示什么。比如：用户下单的内容放倒订单事实表的每一行中。这里的关键是粒度的描述，不能讲维度列出来，而代替粒度声明。这一步特别容易被忽略，粒度声明需要达成共识，否则极有可能到下面三四步之后返工重来
三、确定维度
如果粒度合适，维度很容易确定，因为维度是用来描述：“谁、何时何地、为何、如何”。比如订单常用的维度是：日期、产品、供应商、订单状态、退款状态等
四、确定事实
用“业务的度量是什么”来思考事实。属于不同粒度的事实要放在不同的事实表中。
有人可能疑惑粒度和事实的区别是啥，粒度说明了事实的每一行代表什么意思，而事实是里面包含哪些列，比如成交金额、退款金额、购买份数等等
总结
强烈抵制仅仅考虑数据来源做为建模的方案，比如订单类数据，是从交易系统获取的，那么就将这些数据放在一起。这样虽然比了解业务过程方便很多，但数据不能代替用户的输入，这样做基本注定会失败！
需要综合考虑业务用户需求和数据来源的实际情况，并与上面四步联系起来，如下图所示的建模方案：
五、冗余维度
在现实应用中，事实表是需要做适度冗余的，kimball之所以减少冗余，目的是减少存储消耗。而在实际中，需要考虑下游用户的使用效率，降低获取数据的复杂性，减少关联表的数量，所以冗余比如产品名称、品类名称等，这样就提升过滤查询、统计聚合的效率
