数据仓库中每个事实的开始和结束期间

Question

有人要求我向我们的数据仓库添加一个新表。目前，我们将事实分为月度、季度和年度表，每个表都有时间维度。每个事实记录都有一个时间值。数据在源系统中按开始和结束期间生成，结束日期成为事实记录的时间维度值。事实流向月、季度或年事实表的过程告诉人们如何理解记录中的日期以及如何使用它们。

我被要求让新表在每条记录中包含开始日期和结束日期。有人告诉我，这违反了数据仓库原则，但它更好地代表了数据的生成方式，并允许更灵活地查询数据，例如滚动周期等。

我不是数据仓库专家。我知道每个事实的单一时间维度是一个原则。我的问题是，违反该原则的后果是什么？换句话说，反对这样做的理由是什么？将来我这样做可能会遇到什么问题？在我看来，每个事实的开始和结束时间段确实可以更好地代表数据，但我承认我的知识不足以全面评估这种设计选择的含义。谁能提供一些先见之明？

编辑： 我很欣赏这些答案。他们至少告诉我，这并不像我被引导相信的那样糟糕。我将澄清有关日期的一件事：它们不代表有效期，而是汇总的时期。因此，事实记录可以代表在任意月份计算的某种成分的平均使用磅数。不知道这是否有什么不同，但确实有。

Answer 1

也许是时候买一本好的数据仓库书了，我推荐 Kimball Group 的东西，Ralph Kimball 几乎是快速开始数据仓库的首选。如果有帮助，我可以进一步详细说明，但我将从两点开始，这可能有助于您转身并取得进展。

1. 每个事实有多个时间维度是很常见的。有人在告诉您违反公认的正常做法时，向您提供了不正确的信息。作为“订单”事实的示例，您通常会有订单日期、发货日期、交货日期、期间等。

2. 如果您使用开始日期和结束日期，通常表明您正在使用所谓的类型 2 维度或缓慢变化的维度。情况可能并非如此，但请确保您在做出决定之前了解缓慢变化的维度。

Answer 2

同时记录开始日期和结束日期的优点是您可以更轻松地表示不统一的时间段。这意味着您可以更轻松地加入、聚合和比较以不同粒度记录的数据。从您的描述来看，您的提议似乎没有任何根本“错误”。我以前也实现过类似的东西。

我发现表中时间段的最佳模型是使用半开区间。即：间隔是由 StartDate >= x

Answer 3

每个事实表都有一个grain。事实表的grain指定了表的每一行代表什么——一个事务或某种聚合（每日、每周、每月..）。

我想您当前的表是聚合表，并且 - 在这些情况下很常见 - 聚合表中的每条记录都有一个指向期末的日期维度的外键。因此，例如，每周聚合表中的每条记录每周都有一行，并指向一周的最后一天（星期六或星期日）。请注意，在此期间开始时使用另一个密钥将是多余的。

现在，如果您希望允许期间报告的灵活性，那么您应该考虑一个事务的表 grain，换句话说，表中的一行应该是一个事务，并且任何日期/时间 FK 指向实际交易的时间。

错误的做法是在同一张桌子上混合谷物。考虑以下

FromDateKey ToDateKey   Amount
20110327     20110402   700.0
20110329     20110330   200.0     

任何包含两行的sum() 都会重复计算已包含在第一个条目中的第二个条目。

总而言之，如果您的月度、季度和年度聚合不够精细，只需引入一个细粒度的事实表——一天聚合或单次交易。

Answer 4

好的。这是我处理（将是）相同要求的方式。我使用记录事件日期的新日期字段模拟对事实表的调整。

例如，从上面

EventDateKey 金额记录类型

20110327 700.0 来源

20110329 -500.0 DW调整

因此，如果您需要汇总（合计金额）您的数据可以使用 EventDateKey 并通过相同的日期维度处理任何时期。这很复杂，因为您正在模拟事实表上的调整，但它提供了您所寻找的所有灵活性，而不会丢失信息的粒度。