在我的星型模式中，我有一个项目维度，其中包含 start_date，finish_date，service_date，onhold_date，resume_date 等列。
我应该为事实表中的所有日期引入外键并将它们连接到日期维度，还是应该使用 date_dimension 雪花 project_dimension ？并非所有日期都可用于给定项目，因此将所有这些列保留在fact_table中可能会导致在fact_table中使用null键。
在这种情况下处理日期的最佳方法是什么？
答案 0 :(得分：1)
在数据仓库中，我总是喜欢一般的星型模式，尽可能少雪花，虽然这显然是个人偏好，并且可能取决于您使用的环境。对于Oracle（我最常使用的环境），它支持物理上的雪花，但最佳实践表示不会使业务模型（逻辑）层雪花。
个人而言，出于某些原因，我会推动将FK放在事实上。一个，维持一个明星，一般表现更好，因为雪花引入更多的连接，星星处理聚合更快。第二，如果你有用户将这些数据与来自其他事实的数据相结合，那么具有一致的日期维度才有意义，可以帮助查询性能，并且更加健壮。最后，明星可能是最常见的，因此将来让其他人在这个领域工作应该更容易/未来其他应用程序的数据可能会更好。对于null FK，我会默认为系统的默认日期，对于我们，我们未指定的记录是01/01/1901。我不会将它们保留为空，除非希望业务用户不要看到1901，即便如此，我可能会使用case语句将它们清空，但仍然会将字段填入表中。
这是一篇很好的文章，描述了每种类型的优点/缺点。就像我说的那样，也不是完全正确或错误。
http://www.dataonfocus.com/star-schema-and-snowflake-schema/