我一直想知道 AdventureworksDW 的 FactInternetSale 表是不是一个累积快照表。它里面有一个 ShipDateKey。
根据 AdventureWorks OLTP 文档，它说 SalesOrderHeader 的 ShipDate 是“订单被运送给客户”的日期。我将这一行解释为，当订单发货时，发货日期将被更新。
这也意味着 DW FactInternetSale 中的行也需要更新。发货日期标志着订单的一个重要里程碑，这显然是累积快照事实表的行为。
那么这个表是否应该被认为是一个累积快照事实表呢？如果是这样，那么没有真正的事务事实表有什么问题吗？
在 Kimball 的数据仓库工具包书中，在这类问题中，他将 Order 事务事实表和 Shipping Fact 表严格分开，而 Order Transaction Fact 表只包含下单时记录的信息，而不会更新。Order Transaction Fact 表中的日期始终是预期日期，而不是实际日期。运输事实表包含物品的真实运输日期。之后有一个累积的快照事实表，其中包含订单的所有重要里程碑。不仅是发货日期，还有其他重要的里程碑……通过重要里程碑的日期，我们当然可以知道订单的当前状态。
在我个人看来，我认为不包含当前状态的订单事实表是完全没用的。知道订单总量但不知道有多少来自已履行（已发货）的订单以及有多少来自未履行的订单有什么意义？根据我的经验，用户（数据分析师）总是会一直使用累积快照表来完成他们的工作，因为“当前状态”的搜索谓词在他们的查询中永远不会缺席。
在我的现实世界中，我通常将这个Order（信息）事实表设计为一个累加的快照，跳过事务事实表（就像Kimball所做的那样，严格分离事物），因为我觉得这很耗时，没有用. 事务事实表通常只是对订单执行的操作（例如：运输）。
你怎么看？