AdventureworksDW 的 FactInternetSales 是累积快照表吗？

Posted 2023-03-29

【中文标题】AdventureworksDW 的 FactInternetSales 是累积快照表吗？

【英文标题】：Is AdventureworksDW's FactInternetSales an accumulating snapshot table?

【发布时间】：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所做的那样，严格分离事物），因为我觉得这非常耗时并且没有用。事务事实表通常只是对订单执行的操作（例如：发货）。

你怎么看？

【参考方案1】：

不，它不是一个累积快照事实表

【讨论】：

你能解释一下为什么吗？我刚刚再次阅读了微软的描述，并且该表中似乎只有“已发货”订单。如果是这样，则意味着数据只有达到“cool state”才会上表，并且只写入一个，从不更新，所以它应该是一个事务事实表。只是它包含一些重要里程碑的日期。但在现实中，组织倾向于要求尽可能快的数据，因此里程碑日期不会立即可用，但需要稍后更新，我认为这是积累快照事实的行为

AdventureWorksDW 不是针对实际业务的真实世界实现，它是演示 MS 特性/功能的构造示例。你好像想多了