我的任务表有 4 列来存储created_time、created_date、completed_time、completed_date。
当我将该表转换为 OLAP 时，我是否要将它们存储在日期时间维度下，还是可以将它们保留在事实表中。
有人可以解释一下吗？谢谢。
最佳答案
假设您使用星型架构，日期维度通常不仅仅是一个查找表。它通常包含大量描述事实表中特定日期的列，例如是否是假期、是哪个季度、哪个会计季度等。
通过这种方式构建，企业可以提出诸如第一季度完成了多少任务之类的问题(无需输入该第一季度的确切开始和结束日期)。
您的问题的答案取决于您希望用户问您的查询类型。如果可能出现类似上述的查询，那么可以，创建一个综合日期维度来存储日期信息。
当然，这会使您的查询使用 FK(或指向日期维度的指针列)，并使您使用联接。对于非常大的表，连接可能会稍微降低性能。然而，星型模式就是基于这个概念。
日期维度必须使用一些数据行进行初始化，这些数据行通常涵盖除当前年份之外的 1 或 2 年(或可能更多)。
现在，我们讨论时间列。不建议在日期维度中构建时间(请参阅链接)。如果您在日期维度中构建时间，则日期维度将变得不必要的巨大。
我建议您仅将时间列放置在事实表中，无论您是否使用时间维度。我还建议您在事实中包含计算列，例如事实表中的总持续时间(以天、月、年和小时为单位)(假设此信息提供查询，例如有多少任务需要 5 小时才能完成)。您需要在 ETL 期间进行计算。您不能在没有日期的情况下仅从开始时间减去结束时间。您也不希望在查询期间进行此类计算，否则查询会很复杂。
这种类型的非规范化可能被星型模式模型中的许多人所接受，并且有一个小缺点，即使事实变得更长。有多种方法可以使计算列虚拟化，但您可能决定保留计算列。在这种情况下，如果您的事实很长并且有大量的事实表，您可能会决定创建一个与主要事实以 1-1 关系关联的特殊事实表，以加快处理速度，该新事实将是更小，加载速度更快。然而，在许多应用程序中情况可能并非如此，即 1 fact 就可以很好地完成工作。
关于database - 数据仓库 - 如何存储created_time、created_date、complete_time、complete_date，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39706142/