维度建模主要是4个主要决策:
1、选择业务过程
- 业务过程是通常表示的是业务执行的活动,与之相关的维度描述和每个业务过程事件关联的描述性环境。
- 通常由某个操作型系统支持,例如:订单系统。
- 业务过程建立或获取关键性能度量。
- 一系列过程产生一系列事实表。
2、声明粒度
- 粒度传递的是与事实表度量有关的细节级别。
- 精确定义某个事实表的每一行表示什么。
- 对事实表的粒度要达成共识。
3、确认维度
- 健壮的维度集合来粉饰事实表。
- 维度表示承担每个度量环境中所有可能的单值描述符。
4、确认事实
- 不同粒度的事实必须放在不同的事实表中。
- 事实表的设计完全依赖物理活动,不受最终报表的影响。
- 事实表通过外健关联与之相关的维度。
- 查询操作主要是基于事实表开展计算和聚合。
其中粒度是非常重要的,粒度用于确定事实表的行表示什么,建议从关注原子级别的粒度数据开始设计,因为原子粒度能够承受无法预估的用户查询,而且原子数据可以以各种可能的方式进行上卷,而一旦选择了高粒度,则无法满足用户下钻细节的需求。
事实是整个维度建模的核心,其中雪花模型或者星型模型都是基于一张事实表通过外健关联维表进行扩展,生成一份能够支撑可预知查询需求的模型宽表,而且最后的查询也是落在事实表中进行。
目前常见的维度模型:
星型模型
每一个维表都与都与事实表相关联。数据冗余量较大
雪花模型
有些维表可能不与事实表直接关联,而是通过其他维表关联到事实表。数据冗余量较小
星座模型
由多个事实表相组合,维表是公共的。企业中一般都是星座模型
注意:
- 维度表的唯一主键应该是代理健而不是来自系统的标示符,也就是所谓的自然健,因为自然键通常具有一定的业务含义,但日久天长,这些信息是有可能发生变化的,而代理健可以提高关联效率并将关系数据库设计和业务的解耦。
- 维度表和事实表关联的每个连接应该基于无含义的整数代理健。
- 固定深度层次在维度表中应该扁平化,规范化的雪花模型不利于多属性浏览,而且大量的表和连接操作会影响性能。
- 非完全独立的维度应该合并为一个维度,将同一层次的元素标示为事实表中不同维度是错误的,会增加查询和存储负担,最后变成蜈蚣表,例如:日维度、周维度、月维度等可以合并为一个周期维度。