日期/时间维度

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 - 使用rw_ValidFrom, (rw_ValidTo) , rw_IsCurrent
键入2维
4. 将DateKey角色扮演到ProductionDateKey
5. 将TimeKey角色扮演到ProductionTimeKey和ShiftTimeKey。
6. 也将TimeOfProduction (datetime)保留在事实表中。
7. 在ETL过程中，应用当前的班次逻辑将ProductionDateKey, ProductionTimeKey, ShiftKey, ShiftTimeKey附加到factPart表的每一行。

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

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

Answer 2

我的0.02英镑是值得的：

假设考虑转变没有其他问题（@Andriy M的问题）：

我倾向于对选项2进行折扣，除非您从采用它可以看到特定的好处（性能，简化一类查询等）。你没有描述任何这样的好处，所以你似乎正在增加复杂性。

我个人倾向于选项1 - 概念上最简单，最直接，最适合数据仓库方法的（IMO）。

选项3具有你提到的优势，但我有一种唠叨的怀疑，它涵盖了两种选择：日历维度就像你描述的那样，但时间维度的选择是175k行，或者24。我不能目前为这两种选择中的任何一种提供了论据，只有一种直觉，即有两种这样的选择。如果转移问题与此相关，则可能会影响这些替代方案之间的选择（如果它们是真正的替代方案）。

如果您希望进一步采取备选方案2，则为备选方案3规定的备选方案也是相关的。

Answer 3

我会选择选项3. - 单独的尺寸。优点：

• 简单 - 两个相对较小的表 - 时间维度只加载一次，因为一天中有固定的分钟数。

• 重用 - 两个separete维度更有可能与其他只能包含日期或时间维度的事实表共享

• 通过在事实表中为日期维度设置单独的属性来轻松进行分区

• 可扩展性 - 在报告需求增长时，考虑可以添加到日期和时间维度的属性。对于日期维度，这可能是（以避免每次从日期提取此信息）：年，季度，月，日，星期，日期标签（如“2011年9月12日”），月份名称，工作日名称，各种指标（假日）指标，季末，月末等）。对于时间维度（可以 - 为了准确 - 包含每天的每一秒），这可以是：小时，分钟，秒，日部分标签（如“早上”，“晚上”），工作时间指示器（从8开始的秒数： 00:00到17:00:00等等，但只需要一个维度，就意味着很多冗余。

与日期开始/结束不一致的转换在我看来是每个班次单独的事实寓言记录开始和结束时间戳的一个很好的候选者 - 我的意思是（无事实的）具有以下外键的事实表：id_date_start，id_time_start ，id_date_end，id_time_end。然后，您可以从事件事实表“钻取”到班次表，以获得每个班次的汇总结果。

编辑：或模型转换就像另一个维度一样 - 这取决于您是否转移是一个重要的业务流程，您希望通过其属性独立跟踪（但目前我可以想想任何其他属性，然后是Date＆amp; Time ... Location，也许？）或者它只是一个事件的上下文（因此应该只是一个维度）。