1、维度建模相关概念
1.1、度量和环境
维度建模支持对因为过程的支持，这是通过对业务过程度量进行建模来实现的。
那么，什么是度量呢？实际上，通过和业务方、需求方交谈、或者阅读报表、图表等，可以很容易地识别度量。
考虑如下因为需求：
a、店铺上个月的销售额如何？
b、店铺库存趋势如何？
c、店铺的访问情况如何（pv page view 访问量, 即页面浏览量或点击量，衡量网站用户访问的网页数量；在一定统计周期内用户每打开或刷新一个页面就记录1次，
多次打开或刷新同一页面则浏览量累计。uv: Unique Visitor）独立访客，统计1天内访问某站点的用户数(以cookie为依据);访问网站的一台电脑客户端为一个访客。
可以理解成访问某网站的电脑的数量）。
d、店铺访问的熟客占比多少？
这里的销售额、库存、访问量、熟客量就是度量。缺乏上下文和环境来谈论度量是没有意义的。
度量和环境这两个概念构成了维度建模的基础。而所有维度建模都是通过对度量和其上下文和环境的详细设计来实现的。
1.2、事实和维度
通常来说，事实通常数值形式出现，而且一般都被大量的文本形式的上下文包围。这些文本形式的上下文描述了事实的5个W（when、where，what、who、why）信息，
通常可被直观地分隔为独立的逻辑块，每一个独立的逻辑块即为一个维度，比如一个订单可以非常直观地分为商品、买家、卖家等多个维度。
在维度建模和设计过程中，可以根据需求描述或基于现有报表，很容易将信息和分析需求分类到事实和度量中。比如业务人员需求为“按照一级类目，统计本店铺上月的销售额情况”，
“按照一级类目”这个描述，很清楚说需求方希望对一级类目的销售额进行统计分析，这里的一级类目即为一个维度。类似的是，“上月”为另一个维度，而销售额明显是一个事实。
2、事实表
事实表是维度模型中的基本表，或者说核心表。事实上，业务过程的所有度量在维度建模中都是存储在事实表中的，除此之外，事实表还存储了引用的维度。
事实表通常和一个企业的业务过程紧密相关，由于一个企业的业务过程数据构成了其数据的绝大部分，因此事实表也通常占用了数据仓库存储的绝大部分。比如对于某个超市来说，
其销售的明细数据通常占其拥有数据绝大部分且每天还在不断的累计和增长，而商品，门店、员工、设备等其他数据相对来说固定且变化不大。
事实表的一行对应一个度量事件，事实上，每行对应的度量事件可粗可细。维度建模认为事实表应该包含最底层的、最原子性的细节，因为这样会带来最大灵活性。维度建模中，
细节的级别称为事实表的粒度。
事实表中最常用的度量一般是数值型和可加类型的。除了存储事实外，事实表都会包含多个相关的外键，用于关联和连接对应的维度表。正是通过这些外键，才能进行各个角度、
各个维度的分析。
在进行事实表的设计时，一定要注意一个事实表只能有一个粒度，不能将不同粒度的事实建立在同一张事实表中。
3、维度表
维度表是维度建模的灵魂，通常来说，维度表设计的好坏直接决定了维度建模的好坏。
维度表包含了事实表所记录的业务过程度量的上下文和环境，它们除了记录“5个W”等信息外，通常还包含了很多描述字段和标签字段等。
维度表通常由多列或说多个属性。实际应用中，包含几十甚至上百属性的维度并不少见。维度表应该尽可能地包括一些有意义的文字性描述，以方便下游用户使用。
维度属性是查询约束条件（SQL where条件）,分组（SQL group语句）与报表标签生成的基本来源。
维度属性在数据仓库中承担这一个重要的角色。由于它们实际上所有令人感兴趣的约束条件和报表标签的来源，因此是数据仓库易学易用的关键。在许多方面，
数据仓库不过是维度属性的体现而已。数据仓库的能力直接与维度属性的质量和深度成正比。在提供详细的业务用语属性方面所花的时间越多，数据仓库就越好；在属性列值给定方面所花的时间越多，
数据仓库就越好；在保证属性列值的质量方面花的时间越多，数据仓库就越好。
维度表是进入事实表的入口。丰富的维度属性给出了丰富的分析切割能力。维度给用户提供了使用数据仓库的接口。最好的属性是文本的和离散的。属性应该是真正的文字而不应是
一些编码简写符号。应该通过更为详细的文本属性取代编码，力求最大限度的减少编码在维度表中的使用。
有时候在设计数据库时，并不能确定从数据源分析取出的一个数字型数据字段到底应该作为事实还是维度属性看待。通常可以这样做出决定，
即看字段是一个含有许多取值并参与运算的度量值（当事实看待），还是一个变化不多并做为约束条件的 离散取值的描述（当作维度属性看待）。
参考资料：《离线和实时大数据开发实战》