我正在建立一个数据仓库。每个事实都有它的timestamp。我需要按天、月、季度但也按小时创建报告。查看示例，我发现日期倾向于保存在维度表中。（来源：etl-tools.info）
但我认为，这对于时间来说是没有意义的。维度表会不断增长。另一方面，使用日期维度表 JOIN 比使用日期/时间函数更有效SQL。
您的意见/解决方案是什么？
（我正在使用 Infobright）
问问题
39568 次
4 回答
33
Kimball 建议使用单独的时间和日期维度：
在以前的 Toolkit 书籍中，我们建议使用时间的分钟或秒分量作为每天午夜的偏移量来构建这样的维度，但我们已经意识到最终用户应用程序变得过于困难，尤其是在尝试计算时时间跨度。此外，与日历日维度不同，一天中特定分钟或秒的描述性属性非常少。如果企业在一天内具有明确定义的时间片属性，例如班次名称或广告时间段，则可以在设计中添加额外的时间维度，该维度定义为分钟数（或甚至几秒钟）午夜过后。因此，如果粒度为分钟或 86，则此时间维度将具有 1440 条记录，
于 2010-03-24T20:41:59.357 回答
10
我的猜测是，这取决于您的报告要求。如果您需要类似的东西
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 行。
于 2010-03-25T15:53:23.523 回答
5
时间应该是数据仓库的一个维度，因为您经常需要对其进行汇总。您可以使用雪花模式来减少开销。总的来说，正如我在评论中指出的那样，小时数似乎是一个异常高的分辨率。如果你坚持他们，将一天中的时间单独设置一个维度可能会有所帮助，但我不能告诉你这是否是好的设计。
于 2010-03-24T12:00:03.567 回答
3
我建议为日期和时间设置单独的维度。日期维度将有每个日期的 1 条记录作为已识别的有效日期范围的一部分。例如：1980 年 1 月 1 日至 2025 年 12 月 31 日。
还有一个单独的时间维度，有 86400 条记录，每秒有一条由时间键标识的记录。
在您需要日期和时间的事实记录中，添加具有对这些一致维度的引用的两个键。
于 2011-09-21T20:56:11.167 回答