我正在构建一个数据仓库。每个事实都有timestamp。我需要按日，月，季度创建报告，但也需要按小时创建。看一下这些例子，我看到日期往往会保存在维度表中。 alt starexample http://etl-tools.info/images/dw_star_schema.jpg
但我认为，时间没有意义。维度表将增长和增长。另一方面，使用日期维度表的JOIN比使用SQL中的日期/时间函数更有效。
您的意见/解决方案是什么？
（我正在使用Infobright）
答案 0 :(得分：30)
Kimball建议有不同的时间和日期维度：
design-tip-51-latest-thinking-on-time-dimension-tables
在以前的工具包书中，我们有 建议建立这样一个维度 与分钟或秒组件 时间作为从午夜的偏移 每一天，但我们已经意识到 由此产生的最终用户 应用程序变得太难了 特别是在试图计算时间时 跨越。此外，与日历日不同 维度，很少 的描述性属性 一个特定的分钟或秒 天。如果企业做得好 定义时间片的属性 在一天内，如轮班名称，或 广告时段，另外一个 可以添加时间维度 这个维度的设计 定义为分钟数（或 过了午夜。这样 时间维度要么具有 1440记录谷物是否是分钟 如果谷物是，则有86,400条记录 秒。
答案 1 :(得分：7)
我的猜测是，这取决于您的报告要求。 如果你需要像
这样的东西
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行。
答案 2 :(得分：3)
时间应该是数据仓库的一个维度，因为您经常需要聚合它。您可以使用snowflake-Schema来减少开销。总的来说，正如我在评论中指出的那样，小时看起来像是一个异乎寻常的高分辨率。如果你坚持使用它们，那么将一天中的小时作为一个单独的维度可能会有所帮助，但我不能告诉你这是不是很好的设计。
答案 3 :(得分：3)
我建议为日期和时间分别设置维度。作为已确定的有效日期范围的一部分，日期维度将为每个日期创建1条记录。例如：01/01/1980到12/31/2025。
具有86400条记录的时间单独维度，每秒记录时间密钥标识一条记录。
在事实记录中，你需要日期和时间两者，添加两个引用这些一致维度的键。