我们不管是基于 Hadoop 的数据仓库（如 Hive ），还是基于传统 MPP 架构的数据仓库（如 Teradata ），抑或是基于传统 Oracle 、MySQL 、SQL Server 关系型数据库的数据仓库，其实都面临如下问题：
怎么组织数据仓库中的数据？
怎么组织才能使得数据的使用最为方便和便捷？
怎么组织才能使得数据仓库具有良好的可扩展性和可维护性？
Kimball 维度建模理论很好地回答和解决了上述问题。
维度建模理论和技术也是目前在数据仓库领域中使用最为广泛的、也最得到认可和接纳的一项技术。今天我们就来深入探讨 Ralph Kimball 维度建模的各项技术，涵盖其基本理论、一般过程、维度表设计和事实表设计等各个方面，也为我们后面讲Hadoop 数据仓库实战打下基础。
度量和环境
维度建模是支持对业务过程的分析，所以它是通过对业务过程度量进行建模来实现的。
那么，什么是度量呢？
实际上，我们通过和业务方、需求方交谈，或者阅读报表、图表等，可以很容易地识别度量。
考虑如下业务需求：
- 店铺上个月的销售额如何？
- 店铺库存趋势如何？
- 店铺的访问情况如何（ pv，uv) ?
- 店铺访问的熟客占比多少？
“ 这里的销售额、库存、访问量、熟客量就是度量。”
“ 但是，单单谈论度量，是没有意义的。”
度量和环境这两个概念构成了维度建模的基础。而所有维度建模也正是通过对度量和及其上下文和环境的详细设计来实现的。
事实和维度
在 Kimball 的维度建模理论中，“ 度量称为事实，上下文和环境则称为维度。”
通常来说，事实常以数值形式出现，而且一般都被大量文本形式的上下文包围着。
这些文本形式的上下文描述了事实的“ 5个W ”（ When 、 Where 、 What 、 Who 、 Why ）信息，通常可被直观地分割为独立的逻辑块，每一个独立的逻辑块即为一个维度，比如一个订单可以非常直观地分为商品 、买家、卖家等多个维度。
在维度建模和设计过程中，可以根据需求描述或者基于现有报表，很容易地将信息和分析需求分类到事实和度量中。
比如业务人员需求为“按照一级类目，统计本店铺上月的销售额情况”，“按照一级类自”这个描述，很清楚地说明需求方希望对一级类目的销售额进行统计分析，这里的一级类目即为一个维度 。类似的是，“上月”为另一个维度，而销售额明显是事实。
事实表
事实表是维度模型中的基本表，或者说核心表。
事实上，业务过程的所有度量在维度建模中都是存储在事实表中的，除此之外，事实表还存储了引用的维度。
事实表通常和一个 企业的业务过程 紧密相关，由于一个企业的业务过程数据构成了其所有数据的绝大部分，因此事实表也通常占用了数据仓库存储的绝大部分。
比如对于某个超市来说，其 销售的明细数据 通常占其拥有数据的绝大部分且每天还在不断地累计和增长，而商品、门店、员工、设备等其他数据相对来说固定且变化不大。
事实表的一行对应一个度量事件
事实上，每行对应的度量事件可粗可细，比如对某个超市来说，在设计其维度模型时，表示顾客购买事件的事实表的一行即可以记录一张顾客的小票，也可以记录顾客小票的一个子项。
那么我们究竟应该到何种级别呢？
维度建模认为事实表应该包含 最底层的、最原子性 的细节，因为这样会带来最大的灵活性。维度建模中，细节的级别称为事实表的粒度，比如上文顾客购买行为事实表的粒度就应该是小票子项，而非小票。
事实表中最常用的度量一般是数值型和可加类型的
比如小票子项的销售数量、销售金额等，可加性对于数据分析来说至关重要，因为数据应用一般不仅检索事实表的单行数据，而往往一次性检索数百、数千乃至百万行的事实，并且处理这么多行的最有用的和最常见的事就是将它们加起来，而且是从各个角度和维度加起来。
但事实表中的度量并不都是可加的，有些是半可加性质的，另一些则是非可加性质的
半加性事实是指仅仅某些维度可加，例如库存，可以把各个地方仓库的库存加起来，或者把一个仓库不同的商品加起来，但是很明显不能把一个仓库同一商品在不同时期的库存加起来。
银行的账户余额也是半可加事实的例子，可以把不同分行的账户余额加起来或者不同账户人的账户余额加起来，但是不能把不同月份的账户余额加起来。
非可加性事实则根本就不能相加的事实，比如商品的价格以及订单的状态等。
除了存储的事实外，事实表都会包含多个相关的外键。
用于关联和连接相应的维度表。
例如，订单事实表会包含连接到商品表的商品外键、连接到会员表的买家外键、或者连接到门店表的门店外键等。
正是通过这些外键，才能进行各个角度的、各个维度的分析。
事实表根据粒度的角色划分不同，可分为事务事实表、周期快照事实表和累积快照事实表。
- 事务事实表用于承载事务数据，通常粒度比较低，例如产品交易事务事实、 ATM交易事务事实。
- 周期快照事实表用于记录有规律的、固定时间间隔的业务累计数据，通常粒度比较大，例如账户月平均余额事实表。
- 累积快照事实表用于记录具有时间跨度的业务处理过程的整个信息，通常这类事实表相对比较少见。
这里需要值得注意的是，在进行事实表的设计时，一定要注意 一个事实表只能有一个粒度，不能将不同粒度的事实建立在同一张事实表中。
维度表
维度表是维度建模的灵魂，通常来说，维度表设计得好坏直接决定了维度建模的好坏。
维度表包含了 实表所记录的业务过程度量的上下文和环境，它们除了记录“5 个 W”等信息外，通常还包含了很多的描述字段和标签字段等。
维度表通常有多列或者说多个属性。
实际应用中，包含几十甚至上百属性的维度表并不少见。维度表应该尽可能多地包括 些有意义的文字性描述，以方便下游用户使用。
维度属性是查询约柬条件（ SQL where 条件）、分组（ SQL group 语句）与报表标签生成的基本来源在查询与报表需求中， 属性用 by （按）这个单词进行标识。
维度属性在数据仓库中承担着一个重要的角色。
由于它们实际上是所有令人感兴趣的约束条件与报表标签的来源，因此是数据仓库易学易用的关键。在许多方面，数据仓库不过是维度属性的体现而已。
数据仓库的能力直接与维度属性的质量和深度成正比 。
- 在提供详细的业务用语属性方面所花的时间越多，数据仓库就越好；
- 在属性列值的给定方面所花的时间越多，数据仓库就越好；
- 在保证属性列值的质量方面所花的时间越多，数据仓库就越好。
维度表是进入事实表的入口。
丰富的维度属性给出了丰富的分析切割能力。维度给用户提供了使用数据仓库的接口， 最好的属性是文本的和离散的， 属性应该是真正的文字而不应是一些编码简写符号。
我们应该通过更详细的文本属性取代编码，力求最大限度地减少编码在维度表中的使用。
有时候在设计数据库时，并不能很确定从数据源析取出的一个数字型数据字段到底应该作为事实还是维度属性看待 ，通常可以这样来做出决定，即看字段是一个含有许多取值并参与运算的度量值（当事实看待），还是一个变化不多并作为约束条件的离散取值的描述（当维度属性看待）。
