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