雪花日期维度答案

【问题标题】：Snowflaking Date dimension雪花日期维度
【发布时间】：2016-10-14 03:42:27
【问题描述】：

在我的星型架构中，我有一个 项目维度，其中包含 start_date、finish_date、service_date、onhold_date、resume_date 等列。

我应该为事实表中的所有日期引入外键并将它们连接到日期维度，还是应该使用 date_dimension 将 project_dimension 雪花化？并非所有日期都可用于给定项目，因此将所有这些列保留在 fact_table 中可能会导致 fact_table 中的键为空。

在这种情况下处理日期的最佳方式是什么？

【问题讨论】：

是否有任何其他事实表需要使用这些日期？我要问的是，您认为它们应该与其他事实保持一致，还是更像是一回事？
到目前为止，只有没有其他事实与任何日期相关联。我们只有一个 project_dimension 有日期。那么是否建议创建一个日期维度并将所有这些日期放在事实表中并使用 datekeys 进行参考？在这种情况下我该如何处理不可用的日期（我应该创建不可用的日期“19000101”吗？雪花日期的缺点是什么？谢谢

标签： data-warehouse obiee star-schema snowflake-schema

【解决方案1】：

在数据仓库中，我总是更喜欢一般的星型模式，尽可能少的雪花，虽然这显然有点个人偏好，并且可能取决于您使用的环境。对于 Oracle（我最习惯的环境），它支持物理上的雪花化，但最佳实践表示不要对业务模型（逻辑）层进行雪花化。

就个人而言，出于几个原因，我会推动将 FK 置于事实之上。一，维护一个星，随着雪花引入更多的连接，它通常表现更好，并且星更快地处理聚合。第二，如果您让用户将此数据与来自其他事实的数据相结合，那么具有一致的日期维度就很有意义，可以提高查询性能，并且更加健壮。最后，星号可能是最常见的，因此将来让其他人在这个领域工作应该会更容易/将来数据可能会更好地与其他应用程序一起使用。

对于空 FK，我将默认为您的系统具有的任何默认日期，对我们来说，我们未指定的记录是 01/01/1901。我不会让它们为空，除非业务用户不希望看到 1901，即使那样，我也可能会使用 case 语句将它们清空，但仍将字段填写在表格上。

这是一篇很好的文章，描述了每种类型的优点/缺点。就像我说的，两者都不是完全正确或错误的。

http://www.dataonfocus.com/star-schema-and-snowflake-schema/

【讨论】：

谢谢...这有帮助。