日期/时间维度

Question

我正在设计一个数据仓库,我有一个棘手的时间问题.我需要的谷物是每小时(计算每小时事件的总计数),我还必须适应24小时内不方便拟合的换档模式(实际上'蓝色'换档可能不会覆盖相同几天的时间).

考虑到这一点,我正在考虑三种方法之一

1. 一个时间维度,其中包含175K行.
2. 雪花时间维度,日历维度中包含7300行,时间维度包含175k行
3. 单独的维度,以便事实表具有事件日期和事件时间的外键.

我倾向于方法3,因为它允许在连接中单独引用小日历维度,但我会感激任何想法.

Answer 1

是的,制造业转变是棘手的,并且会随着时间的推移而发生变化,通常是一天前的一个班次,等

请记住,这里有两个日历.一个是标准日历,另一个是生产日历 - 班次属于生产日历.通常,生产日历中的一天可能比24小时更多(或更少).

例如:

部分产生于2011-02-07 23:45周一可能看起来像

TimeOfProduction = '2011-02-07 23:45'
DateKey = 20110207
TimeKey = 2345
ProductionDateKey = 20110208 (the first shift of the next day started at 22:00)
ProductionTimeKey = 145 (1 hour and 45 minutes of the current production date)     
ShiftKey = 1
ShiftTimeKey = 145 (1 hour and 45 minutes of the current shift)

所以,我的建议是:

1. 平原Date Dimension(每个日期一行)
2. 平原Time Dimension(24小时每分钟一排= 1440行+见下面的注释)
3. Shift Dimension - 类型2维度 rw_ValidFrom, (rw_ValidTo) , rw_IsCurrent
4. 角色扮演的DateKey成ProductionDateKey
5. 角色扮演TimeKey一个ProductionTimeKey和一个ShiftTimeKey.
6. 保留TimeOfProduction (datetime)在事实表中.
7. 在ETL过程中,应用当前的移位逻辑以附加ProductionDateKey, ProductionTimeKey, ShiftKey, ShiftTimeKey到factPart表的每一行.

请注意,Time Dimension如果生产日可能持续超过24小时,则可能需要添加额外的行.通常情况下,如果使用当地时间并且有夏令时跳跃.

所以,明星可能看起来像这样

Answer 2

我的 \xc2\xa30.02 的价值：

\n\n

假设考虑转变不会产生其他问题（@Andriy M 的问题）：

\n\n

我倾向于对选项 2 打折扣，除非您可以通过采用它看到特定的好处（性能、一类查询的简化等）。您没有描述任何此类好处，因此您似乎是为了本身而增加了复杂性。

\n\n

我个人更喜欢选项 1——概念上最简单、最直接并且 (IMO) 最适合数据仓库方法。

\n\n

选项 3 具有您提到的优点，但我一直怀疑它涵盖了两种选择：日历维度正如您所描述的那样，但时间维度的选择是 175k 行或 24。我目前无法提供对于这两种选择中的任何一种的争论，只是一种直觉，认为有两种这样的选择。如果转变问题与此相关，它可能会影响这些替代方案之间的选择（如果它们是真正的替代方案）。

\n\n

如果您希望进一步采用选项 2，选项 3 中列出的替代方案也适用。

\n