数据仓库中每个事实的开始和结束周期-Java 学习之路

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

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

我不是数据仓库专家 . 我知道每个事实的单个时间维度是一个原则 . 我的问题是，打破这一原则的后果是什么？换句话说，反对这样做的理由是什么？这样做我将来会遇到什么问题？在我看来，每个事实的开始和结束时段都能更好地代表数据，但我承认我还不足以全面评估这种设计选择的含义 . 任何人都可以提供一些预期吗？

编辑：我很欣赏这些答案 . 他们至少告诉我，这并不像我所认为的那样糟糕 . 我将澄清关于日期的一件事：它们不代表有效期，而是一段聚合期 . 因此，事实记录可以表示对于任意几个月的时间计算的某种成分使用的磅的平均值 . 不知道这是否有任何区别，但确实如此 .

4 回答

1

记录开始日期和结束日期的优势在于您可以更轻松地表示非均匀的时间段 . 这意味着您可以更轻松地加入，聚合和比较以不同粒度记录的数据 . 根据您的描述，似乎没有任何根本与您提议的内容“错误” . 我以前实施过类似的事情 .

我发现表中时间段的最佳模型是使用半开间隔 . 即：间隔是由StartDate> = x <EndDate表示的周期 . 半开间隔使连接和比较更容易 .

回复于 2024-05-03T07:15:05+08:00
0
可能是时候 grab 一本好的数据仓库书了，我推荐一些来自Kimball Group的东西，Ralph Kimball几乎是快速入门数据仓库的转变 . 我可以进一步详细说明它是否有用，但我会从两点开始，这可能有助于让你转身并取得进展 .
- 每个事实都有多个时间维度是非常常见的 . 当告诉您违反公认的正常做法时，有人向您提供了错误的信息 . 作为“订单”事实的一个例子，您通常会有订单日期，发货日期，交货日期，期间等 .
- 如果您使用的是开始日期和结束日期，则通常表示您正在使用所谓的类型2维度或缓慢变化的维度 . 情况可能并非如此，但在做出决定之前，请确保了解缓慢变化的尺寸 .
回复于 2024-05-03T07:15:05+08:00
0
每个 fact table 都有 grain . 事实表的 grain 指定表的每一行代表的内容 - 一个事务或某种聚合（每日，每周，每月......） .

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

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

wrong approach 将在同一张 table 上混合谷物 . 考虑以下
```
FromDateKey ToDateKey   Amount
20110327     20110402   700.0
20110329     20110330   200.0
```
任何包含两行的 sum() 都会重复计算第一个已包含在第一个条目中的条目 .

总而言之，如果您的月度，季度和年度汇总不够好，只需引入一个带有 finer grain 的事实表 - 一天聚合或单个交易 .
回复于 2024-05-03T07:15:05+08:00
5

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

例如，从上面

EventDateKey Amount RecordType

20110327 700.0来源

20110329 -500.0 DW调整

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

回复于 2024-05-03T07:15:05+08:00

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

4 回答

相关问题