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

Question

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

当我将该表转换为OLAP时，我是否希望将它们存储在日期时间维下，或者可以将它们保留在事实表中。

有人可以请解释。谢谢。

Answer 1

假设您使用星型模式，日期维度通常不仅仅是查找表。它通常包含很多描述事实表中特定日期的栏目，例如是假期，哪个季度是关闭的，哪个财政季度是关闭的等。

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

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

当然这会使您的查询使用FK（或指向日期维度的指针列），并且会使您使用连接。对于非常大的表格，连接可能会使性能略微下降。然而，星型模式是基于这个概念。

日期维度必须用一些数据行进行初始化，这些数据行除了当前年份（或者更多）之外通常会覆盖1或2年。

现在我们来谈谈时间专栏。不建议在日期维度中创建时间（请参阅链接）。如果您在日期维度中构建时间，那么日期维度将不必要地巨大。

我建议您只将时间列放在事实表中，无论您是否使用时间维度。我还建议您在事实表中包含计算列，例如事实表中以天，月，年和小时计的总持续时间（假设此信息用于查询，例如完成5个小时需要多少个任务）。您需要在ETL期间进行计算。你不能只从开始时间中减去结束时间而没有日期。在查询期间，您也不希望进行这种计算，否则查询将变得复杂。

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

这也有助于：Kimball-Latest Thinking On Time Dimension Tables。