Snowflaking日期维度

在我的星型模式，我有有这样的列起始日期，finish_date，service_date，onhold_date，RESUME_DATE等一个项目尺寸Snowflaking日期维度

我应该规定所有的日期外键事实表并将它们连接到日期维度，或者我应该将project_dimension与date_dimension雪花？并非所有日期都可用于给定项目，因此将所有这些列保存在fact_table中可能会导致fact_table中具有空键。

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

来源

2016-06-13 SRK

有没有其他事实表需要使用这些日期的机会？我所问的是你认为他们应该与其他事实一致吗？还是更像是一个？ –

截至目前只有没有其他事实有任何相关的日期。我们只有一个具有日期的project_dimension。所以建议创建一个日期维度并将所有这些日期放在事实表中并使用datekey进行引用？我该如何处理不可用的日期（我应该创建不可用的日期“19000101”？雪花日期的缺点是什么？谢谢 – SRK

在数据仓库中，我总是喜欢一个普通的星型模式，尽可能少地使用雪花，尽管这显然有点个人喜好，并且可能取决于您使用的环境。对于Oracle（我习惯的环境）来说，它支持物理上的雪花，但最佳实践并不意味着雪花商业模式（逻辑）层。

就我个人而言，我会推动FKs的事实有几个原因。其中之一就是保持一颗星星，它通常表现更好，因为雪花引入了更多的连接，星星更快地处理聚集。二，如果你有用户将这些数据与其他事实的数据结合起来，那么使用一致的日期维度是有意义的，可以帮助查询性能，并且更加健壮。最后，明星可能是最常见的，所以未来其他人在这方面的工作应该更容易/未来其他应用程序的数据可能会更好地工作。

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

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

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

来源

2016-06-13 18:36:52

谢谢......这有帮助。 – SRK

Snowflaking日期维度

回答

相关问题