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

Question

我正在建造一个数据仓库。每个事实都有 timestamp. 。我需要按白天，月，季度创建报告，但也需要数小时。查看示例，我看到日期往往保存在尺寸表中。
_{（资源： etl-tools.info)}

但是我认为，时间没有意义。尺寸表将增长和增长。另一方面，与日期维度表相比，与使用日期/时间函数相比 SQL.

您的意见/解决方案是什么？

（我正在使用Infobright）

Answer 1

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

WHERE "Hour" = 10

意思是每天10:00:00至10:59:59，然后我会使用时间维度，因为它比

WHERE date_part('hour', TimeStamp) = 10  

因为将对每行评估date_part（）函数。您仍然应该将时间戳保留在事实表中，以便在几天的界限上汇总：

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

使用尺寸字段时会变得尴尬。

通常，时间维度有一个微小的分辨率，因此1440行。

Answer 2

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

Design-tip-51-latest-latt-time-time-dimension-dimension-tables

在以前的工具包中，我们建议使用时间的分钟或几秒钟组成部分来构建这样的维度，以作为每天午夜的抵消，但是我们已经意识到，最终用户的应用程序变得太困难了，尤其是在试图计算时时间跨度。另外，与日历日维度不同，特定分钟或一天之内的描述性属性很少。如果企业在一天之内有时间切片的定义明确定义属性，例如班次名称或广告时间插槽，则可以将额外的时间尺寸添加到设计中，在该设计中，将此维度定义为分钟数（或甚至几秒钟）午夜。因此，如果谷物为分钟分钟，则这个时间尺寸将具有1440个记录，如果谷物为秒为秒，则具有86,400条记录。

Answer 3

时间应该是数据仓库的尺寸，因为您经常想汇总它。您可以使用 雪花施加 减少开销。总的来说，正如我在评论中指出的那样，工作时间似乎异常高。如果您坚持他们，将一天中的一个小时设置为单独的维度可能会有所帮助，但是我不能告诉您这是否是好的设计。

Answer 4

我建议在日期和时间上拥有单独的尺寸。日期维度将对每个日期有1个记录，作为确定的有效日期范围的一部分。例如：01/01/1980至12/31/2025。

并具有86400记录的时间分开，每个第二个具有时间密钥标识的记录。

在您需要日期和时间两者的事实记录中，添加两个密钥，对这些符合的维度有参考。