AdventureworksDW 的 FactInternetSales 是一个累积快照表吗？

Question

我一直想知道AdventureworksDW的FactInternetSale表是不是一个累积快照表。它里面有一个 ShipDateKey。

根据 AdventureWorks OLTP 文档，它说 SalesOrderHeader 的 ShipDate 是“订单运送给客户”的日期。我将这一行解释为，当订单发货时，发货日期将被更新。

这也意味着 DW FactInternetSale 中的行也需要更新。发货日期标志着订单的一个重要里程碑，这显然是累积快照事实表的行为。

那么这张表应该被视为累积快照事实表吗？如果是的话，是否存在没有真实交易事实表的问题？

在Kimball的数据仓库工具包书中，在这类问题中，他非常严格地将Order transaction Fact表和Shipping Fact表分开，Order Transaction Fact表只包含下订单时记录的信息，并且不会更新。订单交易事实表中的日期始终是预期日期，而不是实际日期。发货事实表包含商品的真实发货日期。之后有一个累积快照事实表，其中包含订单的所有重要里程碑。不仅是发货日期，还有其他重要里程碑...通过重要里程碑的日期，我们当然可以知道订单的当前状态。

以我个人的观点，我认为不包含当前状态的订单事实表是完全没有用的。知道订单总量但无法知道有多少订单来自已履行（已发货）订单以及多少订单来自未履行订单，这有什么意义呢？根据我的经验，用户（数据分析师）始终只会使用累积快照表来完成他们的工作，因为“当前状态”的搜索谓词在他们的查询中永远不会缺失。

在我的现实世界中，我通常将这个订单（信息）事实表直接设计为一个累积快照，跳过交易事实表（就像 Kimball 所做的那样，严格分离事物），因为我觉得这非常耗时并且没有使用。交易事实表通常只是对订单执行的操作（例如：发货）。

您对此有何看法？

Answer 1

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

Answer 2

不，这不是累积事实表。
说明：
累积事实表有大量的字段日期，例如：请求的数据、预计发货日期、实际发货日期等。最初，这些字段可能为 NULL，一段时间后会更新。 FactInternetSales 中的表只有一个字段日期，并且在工作流程中似乎不可更新。

更多信息：https://www.holistics.io/blog/the- Three-types-of-fact-tables/

事实表应该有日期。许多日期和滞后信息的附加信息使其不断积累。