标签：核心部分 完成 步骤 输入 哪些 分享 支付 失败 生成
Kimball建模方法的精髓，就是简单、使用，建模这四步骤是它的核心部分。用术语表达是：始终一致的四步设计维度模型。
业务过程是由组织完成的一系列微观活动，例如：完成下单、完成支付、发放代金券、上线产品等等。充分理解它们，有助于辨别组织中的不同业务过程，它一般具有这些特性：
数据仓库人员不仅要详细了解业务过程，还要充分理解用户需求（特别是他们的KPI），因为用户一般很难回答：“你对哪些业务过程感兴趣”，而是使用BI分析来自业务过程的性能度量
我们即需要理解上面的什么是业务过程，也需要理解如下的什么不是业务过程。比如部分功能划分就不是业务过程，我们应该将注意力放在业务过程而不是不同的部门，这样才能避免重复的获取数据。
粒度说命名事实表的每一行表示什么。比如：用户下单的内容放倒订单事实表的每一行中。这里的关键是粒度的描述，不能讲维度列出来，而代替粒度声明。这一步特别容易被忽略，粒度声明需要达成共识，否则极有可能到下面三四步之后返工回来
如果粒度合适，维度很容易确定，因为维度是用来描述：“谁、何时何地、为何、如何”。比如常用的维度是：日期、产品、景区
回答：“业务的度量是什么”来思考事实。属于不同粒度的事实要放在不同的事实表中。
强烈抵制仅仅考虑数据来源建模的方案，比如订单类数据，是从tts获取的，那么就将这些数据放在一起。这样虽然比了解业务过程方便很多，但数据不能代替用户的输入，这样做基本注定会失败！
需要综合考虑业务用户徐妞和数据来源的实际情况，并与四步联系起来，如下图所示的建模方案。
标签：核心部分 完成 步骤 输入 哪些 分享 支付 失败 生成
原文地址：http://www.cnblogs.com/liqiu/p/7223964.html
