在星型模式中，事实和维度之间的外键约束是否必要？

Question

我第一次接触到数据仓库，我想知道是否有必要在事实和维度之间设置外键约束。没有它们有任何重大缺点吗？我目前正在使用关系星型模式。在传统的应用程序中，我习惯使用它们，但我开始怀疑在这种情况下是否需要它们。我目前正在使用SQL Server 2005环境。

更新：对于有兴趣的人，我遇到了poll提出同样的问题。

Answer 1

大多数数据仓库（DW）没有将外键实现为约束，因为：

• 通常，外键约束将触发：插入事实表，任何键更新以及从维表中删除。

• 在加载过程中，会删除索引和约束以加快加载过程，ETL应用程序会强制执行数据完整性。

• 加载表后，DW基本上是只读的 - 读取时不会触发约束。

• 加载后会重新构建所需的索引。

• 在DW中删除是一个受控制的过程。在从维度中删除行之前，会查询事实表以查找要删除的行的键 - 只有在任何事实表中不存在这些键时才允许删除。

以防万一，通常会定期运行查询来检测事实表中的孤立记录。

Answer 2

我们使用它们，我们对它感到满意。

Is it good practice to have foreign keys in a datawarehouse (relationships)?

存在开销，但您可以在加载期间始终禁用约束，然后重新启用它。

具有约束可以捕获ETL错误和建模缺陷。

Answer 3

我认为从理论上讲，你需要这样做。但这取决于您如何通过数据库分离数据。如果所有这些都在同一个数据库中，外键可以帮助您，因为设置外键将有助于数据库根据索引进行更快的选择。如果您在多个数据库上共享表，则需要在应用程序级别上进行检查

您可以让数据库为您检查，但速度很慢。通常，在数据仓库中，我们不关心冗余或完整性。我们已经有很多数据，一些完整性和冗余不会影响一般的聚合数据

Answer 4

我不知道有必要，但我觉得它们对数据完整性有好处。您希望确保事实表始终指向维度表中的有效记录。即使您确定会发生这种情况，为什么不让数据库验证您的要求呢？

Answer 5

在数据仓库中使用完整性约束的原因与任何其他数据库完全相同：保证数据的完整性。假设您和您的用户关心数据是否准确，那么您需要一些方法来确保数据保持正确并且正确应用业务规则。

Answer 6

据我所知，FK可加快查询速度。此外，许多BI解决方案在其集成层中利用它们。所以对我来说，他们是DW中必须的。

Answer 7

希望这个帖子仍然有效。 我的想法是：对于具有许多维度和记录的大型事实表，外键会减慢插入和更新，因此事实表变得太慢而无法加载，特别是当它增加大小时。索引用于在加载表后查询，因此可以在插入/更新期间禁用它们，然后重建它们。外键RELATION很重要，而不是外键本身：这在ETL过程中是非常隐含的。我发现在现实世界的Datawarehouse中，外键会让事情变得太慢。您需要使用VIRTUAL外键：关系是他们的但不是约束。如果您损坏了Datawarehouse中的外键关系，那么您做错了什么。 如果你在插入期间禁用它们并且存在不匹配或孤立，那么你将无法重新启用它们，所以重点是什么。 DW的重点是快速访问和查询。外键使这不可能。 有趣的辩论：在网上不容易找到这个问题 千电子伏