我正在构建一个数据仓库。每个事实都有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条记录的时间单独维度,每秒记录时间密钥标识一条记录。
在事实记录中,你需要日期和时间两者,添加两个引用这些一致维度的键。