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

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

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

我不是数据仓库专家。我知道每个事实的单一时间维度是一个原则。我的问题是，违反这一原则的后果是什么？换句话说，反对这样做的理由是什么？在这样做的过程中，我将来可能会面临哪些问题？在我看来，为每一个事实设定开始和结束时间确实能更好地表示数据，但我承认我知道的还不够充分，无法充分评估这种设计选择的含义。也许有人能提供一些前瞻性的建议吗

编辑：

---

我很欣赏这些答案。他们至少告诉我，这并不像我所认为的那样糟糕。关于日期，我将澄清一点：它们并不代表有效期，而是一个聚合期。因此，事实记录可能代表某一成分在任意月份内使用的平均磅数。不知道这是否有什么区别，但确实如此。

记录开始和结束日期的优点是，您可以更容易地表示非统一的时间段。这意味着您可以更轻松地联接、聚合和比较以不同粒度记录的数据。从你的描述来看，你的提议似乎没有什么根本上的“错误”。我以前也做过类似的事情

---

我发现表中时间段的最佳模型是使用半开放区间。即：间隔是由StartDate>=x也许是时候抓到一本好的数据仓库书籍了，我向Kimball Group推荐一些东西，Ralph Kimball几乎是快速开始数据仓库的后起之秀。如果有帮助，我可以进一步阐述，但我将从两点开始，这两点可能有助于你扭转局面并取得进展

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

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

---

每个事实表都有一个粒度。事实表的粒度指定表中每一行表示的内容——一个事务或某种聚合（每日、每周、每月..）

我假设您当前的表是聚合表，聚合表中的每条记录都有一个指向日期维度的外键，该维度指向时段结束。例如，每周汇总表中的每条记录每周有一行，并指向一周的最后一天（周六或周日）。请注意，在这段时间的开始使用另一个键是多余的

现在，如果您希望允许周期报告的灵活性，那么您应该考虑一个事务的表<强>粒度< /强>，换言之，表中的一行应该是一个事务，并且任何日期/时间FK指向实际事务的时间。< /P> 错误的方法是在同一张表中混合谷物。考虑下面的

FromDateKey ToDateKey   Amount
20110327     20110402   700.0
20110329     20110330   200.0     

任何包含两行的

sum（）

，都会对已经包含在第一行中的第二个条目进行双重计数

---

总而言之，如果您的月度、季度和年度汇总不够好，只需引入一个粒度更细的事实表，即一天汇总或一笔交易。

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

例如，从上面

EventDateKey金额记录类型

20110327 700.0来源

20110329-500.0 DW调整

---

因此，如果需要聚合（求和）数据，可以使用EventDateKey并通过相同的日期维度处理任何期间。这很复杂，因为您正在模拟对事实表的调整，但它提供了您所需的所有灵活性，同时又不丢失任何信息。

我同意：获取这本书。谢谢你的回复。达米尔，看我的编辑。这些记录实际上是聚合的。我确实理解您关于维护粒度的说法。问题是，一个给定数字的粒度实际上可能是两个月，因为源系统允许用户定义他们的报告，而报告是事实的来源。我想这就是为什么他们要求提供有开始和结束日期的事实。是的，任何总和都会包括上面两行，除非总和是开始和结束期间的特定组合，这对我们来说永远都是如此。@Henry--呃，呃，也一样