AdventureworksDW的FactInternetSales是否属于累积快照事实表？

1. FactInternetSale是否属于累积快照事实表 #

你判断的没错，它确实属于简化版的累积快照事实表。核心依据就是它的ShipDateKey字段会随订单发货的业务里程碑更新，覆盖原有的空值/旧值，这完全符合累积快照事实表「一行对应一个业务实体（此处为订单）、随业务过程推进更新对应里程碑字段」的核心特征，只是官方样例没有补全订单全链路的其他里程碑字段（比如支付日期、出库日期、签收日期等），属于简化实现。

2. 缺失事务事实表的潜在问题 #

你提到的「分析师基本只用累积快照表」是非常普遍的情况，90%以上的日常运营、业务分析需求都是基于订单最新状态统计，直接查累积快照表的查询效率、开发效率都高很多，但缺失事务事实表确实会在几个特定场景下遇到问题：

• 无法支撑业务操作轨迹分析：比如要统计某周仓储端发起的发货操作总次数、不同操作岗的处理效率，这类针对单个操作动作的统计，累积快照只保留了最后一次更新的发货时间，历史操作记录全部被覆盖，完全无法实现
• 数据排查难度大：如果出现DW数据和业务系统数据对账不一致的情况，没有事务事实表留存的每一次操作流水，根本没法定位是同步漏了数据、还是有取消发货再重发的特殊业务场景导致的差异
• 无法回溯历史时点状态：比如要回溯去年618当天结束时的待发货订单总金额，累积快照只存最新状态，没有事务流水你完全查不到当时的真实数据，除非额外做了每日全量快照，又会大幅提升存储成本

3. 直接用累积快照表省去事务事实表的设计思路评估 #

这个思路在业务规模小、需求明确的场景下是非常务实的选择，不用死守Kimball的理论规范，毕竟所有建模都是为了业务需求服务，没必要为了符合规范做很多没用的冗余开发。但如果要这么做建议提前做好两个准备：

• 提前和所有数据使用方对齐边界：明确当前设计不支持操作轨迹分析、历史时点状态回溯类需求，避免后续出现预期外的需求无法支撑
• 在累积快照表中补充基础的变化痕迹字段：比如增加首次发货时间、最后更新时间两个冗余字段，至少留最基础的排查线索，遇到数据问题不用完全抓瞎
  如果是中大型企业，业务链路复杂、有财务/合规类的严格数据需求，还是建议保留事务事实表，后续补历史数据的成本远高于前期开发的成本。

内容的提问来源于stack exchange，提问作者Pblade