事实表结构

事实表对应一个度量事件，除数字度量外，事实表总是包含外键，用于关联与之相关的维度，也包含可选的退化维度和日期/时间戳。主要目标是对事实表开展计算和聚集操作。一个事实表的示例结构如下：

图1-零售销售事实表

可加、半可加、不可加事实

可加事实如图1-零售销售事实表的销售数量，可以对其进行求和操作得出总的销售数量。

半可加事实如银行账号的余额，可以在当前时间进行累加，不能跨时间累加。如当前时点所有存款账号总余额为有意义，将昨日及今日余额进行相加作为余额则会引起歧义，算年日均存款时可以累加然后除以对应天数。

不可加事实如毛利率，不能直接进行累加，应该分别算出分子、分母后计算得出。

事实表空值

事实表的度量字段可以使用空值，聚集函数如MAX、SUM等可正常处理。但是事实表的外键不可以为空值，维度表的空值必须用默认的值填充，如UNKNOWN。

一致性事实

些度量出现在不同的事实表中，如果计算和比较计算不同事实表中的事实，应保证事实的技术定义是相同的。如果事实是一致的，则必须使用相同的命名，否则必须有不同的命名。

事务事实表

事务事实表的一行对应空间或时间上某点的度量事件。尽量存储最细原子粒度的事实，是维度变化及可表达的事实，可最大化分片和分块。事实表可以是稀疏或者稠密的，只有存在度量时才会建立行。度量数字必须于事务粒度保持一致。事务事实表示例如下图：

图2-客户事务事实表

周期快照事实表

周期快照事实表：每行汇总了发生在某一标准周期，如某一天、某周、某月的多个度量事件。粒度是周期性的，而不是个体的事务。周期快照事实表通常包含***许多事实***，任何与事实表粒度相同的度量都可放在一起。事实表及其外键的密度是均匀的，即使周期内没有活动发生，也会在事实表中为每个事实插入包含0或者空值的行。周期快照事实表示例如下：

图3-商店库存快照事实表

累计快照事实表

累计快照事实表：汇总了发生在过程开始和结束之间可预测步骤内的度量事件。在事实表中针对过程的关键步骤都包含日期外键。累积快照事实表的一行对应某一具体订单，当订单产生时会插入一行，当管道过程发生时，累积快照事实表行被访问并修改。累积快照事实表也可包含其他维度和可选退化维度的外键。

一个累积快照事实表结构如下：

图4-订单履行累积快照事实表

如上图，累积快照事实表有以下特征：

1. 多个日期角色视图表示不同里程碑节点的日期；
2. 除了订单本身的事实外，还带上各个里程碑节点的事实，前提是粒度保持一致；
3. 具有多个预计算的里程碑时间差，如下单到生产时长、生产到入库时长、入库到发货时长。如果不预计算也可以在后面使用时根据里程碑时间进行计算，但是预计算的话可以节省后面处理复杂度，并且有一个统一的计算口径，不会导致后面计算方法不同导致的业务理解偏差。

无事实的事实表

些事件仅仅记录一系列某一时刻发生的多维实体。例如某一天中发生的学生参加课程的事件，可能没有可记录的数字化事实，但该事实行带有一个包含日历天、学生、教师、地点、课程等定义良好的外键：

图5-学生上课事实

聚集事实表或OLAP多维数据库

聚集事实表时对原子粒度事实表数据进行简单的数字化上卷操作（类似DWS层）。OLAP的聚集可以直接被商业用户访问。

合并事实表

将来自多个过程的，以相同粒度表示的事实合并为一个单一的合并事实表，可带来方便。如现货销售和销售预测合并为一张事实表，与针对多个不同的事实表采用下钻比较会比简单快捷。合并事实表特别适合经常需要共同分析的多过程度量。

比如比较实际与预算差异，可以假设年度预算与/或预测通过会计周期来划分，下方事实表显示了实际与预算额，以及通过公共维度获得的差异：

图6-预算差异事实

高级事实表技术

事实表代理键

代理健可用作所有维度表的主键。另外也可以使用单列代理事实键，通过ETL加载过程中顺次分配的，可以做事实表的1-主键列，2-事实表直接标识符，不用查询多个维度，3-将事实表的更新操作分解为风险更小的插入和删除操作。

蜈蚣事实表

一些设计者为多对一层次的每层建立不同的规范化维度。例如日期维度、月份维度、季维度和年维度等，并将所有外键包含在一个事实表中，这将产生蜈蚣事实表。正确做法是关联的维度都回到他们最细节的粒度上。当将所有外键嵌入到单一低粒度维表而不是建立杂项维度，也会产生蜈蚣事实表。

如下POS零售销售事务事实表例子，日期维度在事实表中衍生多个维度外键包括周、月、季等；商店维度衍生多个维度外键。事实表不应该出现这种同一个维度不同属性的多个外键，考虑放入一个维度中。

图7-POS零售销售事务事实表

在对事实表进行聚集时，若数据量大幅度减少，在表中加多几个维度的外键有时又能达到容易使用的效果，之所以不建议在事务事实表增加过多外键是因为事实表的数量巨大，增加多字段会导致存储直线上升。

多数业务过程可以用不超过20个维度的事实表示，如果某个设计有25个或更多维度，应该考虑采取措施合并管理的维度，如层次级别以及具有统计相关性的属性都应该放入一个维度中。

属性或事实的数字值

遇到数值时，不知道是分类到事实还是维度，典型的是产品的标准价格。如果该数值主要用于计算目的，则可能属于事实，如果适用于确定分组或过滤，则应将其定义为维度属性，高离散数字值用值范围进行补充，例如$5-50。某些情况下数字值既建模为维度又建模为属性是非常有益的，如下保险项目维表和保单事实表中的实际保额，既作为了事实表的事实，同时其最低、最高值也作为保险项目维表的2个属性，也可以把保额的分段作为维表的属性（如1到10万，如果是业务使用BI，也可以放到case when语句中判断，具体看实际使用场景。）：

图8-保额作为事实及作为维表属性

日志/持续事件事实

累积快照事实表获取多个过程里程碑，每个都包含日期外键并可能包含日志/时间戳，商业用户希望分析这些里程碑之间滞后及延迟时间，可计算每一个步骤到第一个步骤的延迟时间。需要计算中间2个任意步骤的时间间隔可通过各自到第一个步骤的时间进行计算。

这种做法是简化累积快照事实表中里程碑节点时间差的计算。

头/行事实表

作型交易系统通常包含事务头指针行，与多个事务行关联。采用头/行模式（父子模式），所有头指针级别维度外键与退化维度应该被包含在行级别事实表。

一个事务头指针包含多个行，每一行就是一个业务操作，因此粒度为每一行而不是每个事务。

分配的事实

头指针/行事务数据与对应的事实具有不同粒度这样的情况经常发生，例如头表示货运费用。应该尽量分配头指针事实，使其基于业务所提供的规则划分为行级别，分配的事实可以按照所有维度进行分片并上钻。多数情况可避免建立头指针级别的事实，除非这样的聚集能够获得查询性能的改善。

也就是一个事务头指针表示的事实应该想办法分配给更细粒度的事务行中，通常是由业务决定分配规则。

利用分配建立利润与损失事实表

事实表揭示利润等价方程：收入-开销=利润。理想的把实现利润方程的事实表应为原子收入实务粒度并包含许多开销项。因为这些表处于原子粒度才能实现数字化的上卷，包括客户利润、产品利润、促销利润、渠道利润等。然而建立这些事实表存在一定难度，因为开销项必须从其原始来源划分到事实表粒度，是一个与业务相关的步骤，需要高层经理的支持。利润与损失相关事实表通常在早期的实现阶段不会被处理。

多货币事实

多货币单位记录财务事务的事实表行应该包含本币、标准币的一对列。该事实表也必须有一个货币维度用于区分事务的真正货币。各货币的汇率可以通过建立货币维表实现。如下多币种订单明细事务事实表：

图9-多币种订单明细事务事实表

多种度量事实单位

某些业务过程需要事实间以多种度量单位表示，例如按照业务用户的观点，供应链可能需要对相同事实以平台、船运、零售以及单个扫描单元构建报表。最好的方法是将事实以工人的标准度量单位存储，同时存储标准度量与其他度量的转换系数。这种事实表可按照不同用户的观点部署，转换系数必须存储在事实表行中以确保计算简单正确，并尽量降低查询复杂度。

假设国际货运公司需要跟踪货物运输过程中的重量和体积信息，由于不同国家和客户使用不同的度量单位，业务过程需要以多种单位表示这些事实。多币种事实也可采用类似方法。

图10-货运事实表

年-日事实

商业用户在事实表中通常需要年-日值（YTD）。YTP很容易转换为“财务周期结束时的YTD”或者“财务周期日”。更可靠、可扩展的处理方法是在BI或者OLAP中计算YTD矩阵，而不是在事实表中查出YTD事实。

多遍SQL以避免事实表间的连接

不应该跨事实表的外键处理2个事实表的连接操作。在如果2个事实表包含客户产品的出货和返回，则这两个表不能按照客户和产品外键直接连接。要采用跨钻方式方式使用2个事实表，并对结果按照公共行头指针属性值进行排序-融合操作以产生正确的结果。

针对事实表的时间跟踪

个别情况在事实表中增加行有效时期、行截止日期和当前行标识是非常有用的，与采用类型2缓慢变化维类似。这种设计在需要跟踪随时间变化的维度或事实时非常有用，常见于SCD类型2维度表或需要历史跟踪的事实表，如价格变化、汇率变化、员工职位变动等场景。

图11-产品价格历史事实表

迟到的事实

新事实无法与维度匹配，当迟到度量事件出现时，必须搜索相关维度以发现有效的维度键。