播面

在数据仓库建模（通常基于 Kimball 维度建模理论）中，事实表（Fact Table）用于存储业务过程中的度量（Measures）和指向各个维度的外键。

根据数据记录的方式、更新频率以及业务需求的不同，事实表主要分为以下三种核心类型。此外，还有一种特殊的“无事实事实表”。

以下是详细的分类解析：

---

1. 事务事实表 (Transaction Fact Table)

这是最常见、最基础的事实表类型。

• 定义：用于记录业务过程中的每一个原子事件（Atomic Event）。
• 记录时机：当业务动作发生时记录一行数据（例如：用户点击了一次、下了一个订单、进行了一次支付）。
• 数据特征：
  • 粒度（Granularity）：通常是最低级别的原子粒度（如：订单中的每一个商品条目）。
  • 更新方式：只增不改（Append Only）。一旦写入，通常不会修改。
  • 稀疏性：如果某天没有业务发生，就没有记录。
• 日期维度：通常只有一个日期维度外键，即事务发生的日期。
• 适用场景：需要分析具体的业务细节，进行任意维度的聚合。
• 例子：
  • 电商交易流水表（每一行是一个订单明细）。
  • 银行转账记录表。
  • 网站日志访问表。

2. 周期快照事实表 (Periodic Snapshot Fact Table)

用于记录业务在固定时间间隔内的状态或累积量。

• 定义：不管业务是否发生，都会按照预定的时间周期（如每天、每月）对业务状态进行“拍照”记录。
• 记录时机：周期结束时（如每天午夜、月底）。
• 数据特征：
  • 粒度：周期 + 维度组合（如：每天 + 每个仓库 + 每个商品）。
  • 更新方式：定期插入。通常是全量快照或增量快照，一般不更新旧快照。
  • 稠密性：即使某天该商品没有销售，也可能需要记录其库存为X（或者0），记录是连续的。
• 日期维度：代表快照周期的结束日期。
• 适用场景：分析存量、状态、余额以及长期的趋势。
• 例子：
  • 每日库存快照表（每天记录每个商品的库存数量）。
  • 每月银行账户余额表。
  • 每日股票收盘价表。

3. 累积快照事实表 (Accumulating Snapshot Fact Table)

用于记录具有明确开始和结束以及中间多个关键里程碑节点的业务过程（工作流）。

• 定义：一行记录代表一个完整的业务流程生命周期，随着流程的推进，这行记录会被不断更新。
• 记录时机：业务流程开始时插入，后续每个关键节点发生时更新该行数据。
• 数据特征：
  • 结构：包含多个日期字段（如：下单时间、支付时间、发货时间、收货时间）。
  • 更新方式：频繁更新（Update）。这是数仓中少数允许 Update 操作的场景。
  • 生命周期：当流程结束（如订单完成或取消）后，该行数据通常不再更新。
• 适用场景：分析业务流程的时效性（Lag）、各阶段的耗时、流程进度。
• 例子：
  • 订单履约表（从下单 -> 支付 -> 发货 -> 签收，一行数据涵盖全过程）。
  • 保险理赔申请流程表。
  • 贷款审批流程表。

---

三种事实表的对比总结

---

4. 补充：无事实事实表 (Factless Fact Table)

除了上述三种，还有一种特殊类型值得了解：

• 定义：表中只有维度外键，没有度量值（或者度量值仅为虚拟的“1”）。
• 用途：
  1. 事件跟踪：记录事件的发生（如学生出勤表：学生ID+课程ID+日期ID，只要有记录就代表出席，不需要具体数字）。
  2. 覆盖范围/促销范围：记录维度之间的多对多关系（如某天哪些商品在促销，即使没卖出去也要记录这种关系）。

总结建议

在实际数仓建设中，通常会组合使用：

1. 先建设事务事实表，保留最原始、最细粒度的数据。
2. 为了提高查询性能（看趋势、看库存），基于事务表生成周期快照表。
3. 为了分析业务流转效率，基于事务表生成累积快照表。