事实表设计的八大原则

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

事实表设计的目的是为了度量业务过程，所以分析哪些事实与业务过程有关是设计中非常重要的关注点。在事实表 中应该尽量包含所有与业务过程相关的事实，即使存在冗余，但是因为事实通常为数字型，带来的存储开销也不会很大。

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

在选择事实时，应该注意只选择与业务过程有关的事实。比如在订单的下单这个业务过程的事实表设计中 ，不应该存在支付金额这个表示支付业务过程的事实。

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

对于不具备可加性条件的事实，需要分解为可加的组件。比如订单的优惠率，应该分解为订单原价金额与订单优惠金额两个事实存储在事实表中。

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

粒度的声明是事实表设计中不可忽视的重要一步，粒度用于确定实表中一行所表示业务的细节层次，决定了维度模型的扩展性，在选择维度和事实之前必须先声明粒度，且每个维度和事实必须与所定义的粒度保持一致。在设计事实表的过程中，粒度定义得越细越好，建议从最低级别的原子粒度开始，因为原子粒度提供了最大限度的灵活性，可以支持无法预期的各种细节层次的用户需求。在事实表中，通常通过业务描述来表述粒度，但对于聚集性事实表的粒度描述，可采用维度或维度属性组合的方式。

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

事实表中的所有事实需要与表定义的粒度保持一致，在同 个事表中不能有多种不同粒度的事实。如表 1.1 所示为机票支付成功事务事实表，粒度为票一级的，而在实际业务中，一个订单可以同时支付多张票，如 ID 100901 的订单包含三张机票， ID 100902 的订单包含两张机票， ID 100903 的订单包含一张机票。在该事实表的设计中，票支付金额和票折扣金额两个事实与表定义的粒度一致，并且支持按表的任意维度汇总，可以添加进该事实表中。而订单支付金额和订单票数作为上 层粒度的订单级事实，与该票级事实表的粒度不一致，且不能进行汇总。比如订单 ID100901 的订单支付金额为 3700 元，订单票数为 张，如果这两个度量在该表进行汇总计算总订单金额和总票数，则会造成重复计算的问题所以不能作为该表的度量选人。

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

对于同个事实表中事实的单位，应该保持一致。比如原订单金额、订单优惠金额、订单运费金额这三个事实，应该采用一致的计量单位，为元或分，以方便使用。

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

对于事实表中事实度量为 null 值的处理，因为在数据库中 null对常用数字型字段的 SQL 过滤条件都不生效，比如大于、小于、等于、大于或等于、小于或等于，建议用零值填充。

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

Kimbal 维度建模中，通常按照星形模型的方式来设计，对于维度的获取采用的是通过事实表的外键关联专门的维表的方式，谨慎使用退化维度。而在大数据领域的事实表设计中，则大量采用退化维度的方式，在事实表中存储各种类型的常用维度信息。这样设计的目的主要是为了减少下游用户使用时关联多个表的操作，直接通过退化维度实现对事实表的过滤查询、控制聚合层次、排序数据以及定义主从关系等。通过增加冗余存储的方式减少计算开销，提高使用效率。