数据仓库中的时间和日期维度

Posted 2023-03-25

【中文标题】数据仓库中的时间和日期维度

【英文标题】：Time and date dimension in data warehouse

【发布时间】：2010-03-24 11:44:02

【问题描述】：

我正在构建一个数据仓库。每个事实都有它的timestamp。我需要按天、月、季度但也按小时创建报告。查看示例，我发现日期倾向于保存在维度表中。 _{（来源：etl-tools.info）}

但我认为，时间没有意义。维度表会不断增长。另一方面，使用日期维度表 JOIN 比在 SQL 中使用日期/时间函数更有效。

您有什么意见/解决方案？

（我正在使用 Infobright）

【问题讨论】：

每小时报告对于数据仓库来说似乎是一种高分辨率。真的需要/合适吗？

【参考方案1】：

Kimball 建议使用单独的时间和日期维度：

design-tip-51-latest-thinking-on-time-dimension-tables

在之前的 Toolkit 书籍中，我们有 推荐建造这样一个维度 带有分钟或秒组件 时间作为从午夜的偏移量 每一天，但我们已经开始意识到 最终用户 申请变得太难了， 尤其是在尝试计算时间时 跨越。此外，与日历日不同 维度，很少 的描述性属性 特定分钟或秒内 天。如果企业有好 时间片的定义属性 一天之内，例如班次名称，或 广告时段，额外的 时间维度可以添加到 这个维度所在的设计 定义为分钟数（或 甚至几秒钟）午夜过后。因此这 时间维度要么有 1440 条记录，如果谷物是分钟 或 86,400 条记录，如果谷物是 秒。

【讨论】：

Kimball 网站的链接现已失效。这是一个新的有效link。

链接又被破坏了...这是新链接：kimballgroup.com/2004/02/01/…

看起来，Kimball 的数据仓库创意并没有在 Internet 上占据一席之地。

@davek 是否有必要在事实表中保留一个日期时间列作为另一个 answer 状态？因为像between '2010-03-22 23:30' and '2010-03-23 11:15' 这样的过滤时间窗口真的不好操作两个连接表。

【参考方案2】：

我的猜测是，这取决于您的报告要求。 如果你需要类似的东西

WHERE "Hour" = 10

意思是每天 10:00:00 到 10:59:59 之间，那么我会使用时间维度，因为它比时间维度要快

WHERE date_part('hour', TimeStamp) = 10  

因为 date_part() 函数将针对每一行进行评估。 您仍应将 TimeStamp 保留在事实表中，以便在天数范围内进行聚合，例如：

WHERE TimeStamp between '2010-03-22 23:30' and '2010-03-23 11:15' 

使用维度字段时会变得很尴尬。

通常，时间维度的分辨率为分钟，因此为 1440 行。

【讨论】：

明确地说，您建议使用两个单独的维度，一种是天（365*10 = 3,650 条记录），另一种是分钟（1,440 条记录）？我想了解拆分的好处；单个 DateTime 维度会更大（365*10*24 = 每小时 87,600 条记录）但仍然不是很大，并且会使时区计算更加容易。

@JonofAllTrades 通过拆分每个维度都有一个合理的 PK。有些事实将是日期粒度（即没有时间戳），而有些事实将是时间粒度。将日期粒度的事实表连接到时间粒度的维度会导致重复，然后您需要投入更多资源才能删除。

@jackohug：当然，这就是为什么我总是有一个Dates 表和一个Times 表。但是，当您确实有日期时间值时，为什么要使用两个键和双连接而不是单个四字节 FK 到 DateTimes 表？对我来说效果很好，但有些人似乎对它过敏，原因不明。

【参考方案3】：

时间应该是数据仓库的一个维度，因为您经常需要对它进行汇总。您可以使用snowflake-Schema 来减少开销。总的来说，正如我在评论中指出的那样，小时数似乎是一个异常高的分辨率。如果您坚持这样做，将一天中的时间设置为单独的维度可能会有所帮助，但我无法告诉您这是否是好的设计。

【讨论】：

如果日期是 10 年的维度，它只有大约 3650 条记录。每小时的报告在这里非常有用 - 我们需要比较日期：周一到周一、周二到周二以及周一 11:00-12:00 到周二 11:00-12:00 的小时数。你觉得雪花比星星更有用/更有效吗？

Snowflake 可以帮助减少维度表中的冗余，但如果这有助于您在特定情况下的性能或内存方面，我不能说。

10 年和小时的日期维度仍然很小：87,660 行。此外，您可以汇总旧数据以降低时间分辨率。 10 年后，星期四上午 10 点实际上有多大的相关性？

完全取决于领域，例如，如果我是一家大型连锁超市，我想知道高峰时段的历史。但是，如果我是一家每天进行 10 到 20 笔销售的公司，我可能对日常活动不太感兴趣，更不用说每小时了

你如何建议在这里使用雪花？使用主要的DateTime 维度，它会扩展为Date 维度？这些似乎比单独的 Date 和 Time 维度更麻烦，但我对你看到的优势很感兴趣。

【参考方案4】：

我建议为日期和时间设置单独的维度。日期维度将有每个日期的 1 条记录作为已识别的有效日期范围的一部分。例如：1980 年 1 月 1 日至 2025 年 12 月 31 日。

还有一个单独的时间维度，有 86400 条记录，每秒有一条由时间键标识的记录。

在您需要日期和时间的事实记录中，添加具有对这些一致维度的引用的两个键。