2

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

当我将该表转换为 OLAP 时,我想将它们存储在日期时间维度下还是可以将它们保存在事实表中。

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

4

1 回答 1

3

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

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

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

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

日期维度必须使用一些数据行进行初始化,这些数据行通常覆盖当前年份(或更多)之外的 1 年或 2 年。

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

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

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

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

于 2016-09-26T16:31:53.003 回答