数据仓库 - 如何存储created_time,created_date,complete_time,complete_date

时间:2016-09-26 14:59:18

标签: database data-warehouse fact-table

我的任务表有4列用于存储created_time, created_date, completed_time, completed_date

当我将该表转换为OLAP时,是否要将它们存储在“日期时间”维度下,或者可以将它们保存在“事实”表中。

有人可以解释一下。谢谢。

1 个答案:

答案 0 :(得分:3)

假设您使用的是星型模式,日期维度通常不仅仅是查找表。它通常包含大量描述事实表中特定日期的列,例如它是一个假日,它是哪个季度,是哪个财政季度等等。

通过这种方式构建,企业可以提出问题,例如第一季度完成了多少任务(无需输入第一季度的确切开始和结束日期)。

您的问题的答案取决于您希望用户询问您的查询类型。如果可能出现上述查询,则为是,创建一个综合日期维度来存储日期信息。

当然这会使您的查询使用FK(或指针列到日期维度)并使您使用联接。对于非常大的表,连接可能会略微降低性能。但是,星型模式基于这个概念。

日期维度必须初始化,一些数据行通常包括当前年份(或更多)的1年或2年。

现在,我们讨论时间列。建议不要在日期维度中构建时间(请参阅链接)。如果您在日期维度中构建时间,那么日期维度将是不必要的巨大。

我建议您只将时间列放在事实表中,无论您是否使用时间维度。我还建议您在事实表中包含事实中的计算列,例如天,月,年和小时的总持续时间(假设此信息提供诸如完成了多少任务需要5小时完成的查询)。您需要在ETL期间进行计算。您不能在没有日期的情况下从开始时间中减去结束时间。您也不希望在查询时间内进行此类计算,否则查询将很复杂。

这种类型的非规范化可能在星型模式模型中被许多人接受,并且具有使事实更长的一个小缺点。有一些方法可以使计算列成为虚拟列,但您可以决定保留计算列。在这种情况下,如果你的事实很长并且你有大量的事实表,你可能决定创建一个特殊的事实表,该事实表与主要事实的1-1关系相关联,以使处理更快,新的事实将是更小,更快地加载。然而,在许多应用程序中可能并非如此,即1个事实可以很好地完成工作。

这也可能有所帮助:Kimball-Latest Thinking On Time Dimension Tables