事实表设计注意事项

概述

在设计事实表的时候，和设计普通的数据库有一些差异，有以下一些注意事项：

graph LR
B(包含完整业务事实)---A(事实表设计)
C(去除多余业务事实)---A
D(分解不可加事实)---A
E(先声明粒度)---A
A---F(避免不同粒度)
A---G(保持单位一致)
A---H(处理null 值)
A---I(退化维度)

原则 1：尽可能包含所有与业务过程相关的事实

分析哪些事实与业务过程相关，是设计过程中非常重要的关注点；在事实表中，尽量包含所有与业务过程相关的事实，即使存在冗余，由于事实通常是数字型，存储开销不会太大；

原则 2：只选择与业务过程相关的事实

订单的下单这个业务过程，事实表中不应该存在支付金额这个表示支付业务过程的事实；

原则 3：分解不可加性事实为可加的组件

如，订单的优惠率，应分解为订单原价金额与订单优惠金额两个事实存储在事实表中；

原则 4：在选择维度和事实之前必须先声明粒度

粒度用于确定事实表中一行所表示业务的细节层次，决定了维度模型的扩展性；
每个维度和事实必须与所定义的粒度保持一致；
设计事实表时，粒度定义越细越好，一般从最低级别的原子粒度开始；
因为原子粒度提供了最大限度的灵活性，可以支持无法预期的各种细节层次的用户需求；

原则 5：在同一个事实表中不能有多种不同粒度的事实

疑问：怎么判断不同事实的粒度是否相同？
粒度为票一级；（实际业务中，一个订单可以同时支付多张票）
票支付金额和票折扣金额，两个事实的粒度为 “票级”，与定义的粒度一致；
订单支付金额和订单票数，两个事实的粒度为 “订单级”，属于上一层订单级数据，与 “票级” 事实表的粒度不一致，且不能进行汇总；
如果，以订单金额和订单票数这两个维度汇总总金额和总票数，会造成大量的重复计算；

原则 6：事实的单位要保持一致

如，订单金额、订单优惠金额、订单运费这 3 个事实，应该采用统一的计量单位，统一为元或者分，以方便使用；

原则 7：对事实的 null 值要处理

原因：在数据库中，null 值对常用数字型字段的 SQL 过滤条件都不生效；如，大于、小于、等于、大于或等于、小于或等于；
处理：用 0 代替 null ；

原则 8：使用退化维度提高事实表的易用性

事实表中存储各种类型的常用维度信息，较少下游用户使用时关联多个表的操作；通过退化维度，可以实现对事实表的过滤查询、控制聚合层次、排序数据、定义主从关系等；