在星型模式中,事实和维度之间是否需要外键约束?

大多数数据仓库(DW)没有将外键实现为约束,因为:

• 通常,外键约束将触发:插入事实数据表、任何键更新以及从维度表中删除。

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

• 一旦加载了表,dw本质上是只读的——约束不会在读取时触发。

• 任何必需的索引都将在加载后重新构建。

• 在DW中删除是一个受控制的过程。在从维度中删除行之前,将查询事实数据表中要删除的行的键——仅当这些键在任何事实数据表中都不存在时,才允许删除。

为了以防万一,经常定期运行查询来检测事实表中的孤立记录。

我们使用它们,我们对此很满意。

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

有开销,但是您可以在加载期间禁用约束,然后重新启用它。

设置约束可以捕获ETL错误和建模缺陷。

我认为理论上,你需要这个。但这取决于如何在数据库上分离数据。如果它们都在同一个数据库中,则外键可以帮助您,因为设置外键将有助于数据库根据索引更快地进行选择。如果在多个数据库上共享表,则需要在应用程序级别对其进行检查。

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

我不知道是否有必要,但我认为出于数据完整性的原因,它们是好的。要确保事实数据表始终指向维度表中的有效记录。即使您确定会发生这种情况,为什么不让数据库验证您的需求呢?

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

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

希望此线程仍处于活动状态。 我的想法是:对于具有许多维度和记录的大型事实数据表,外键将减慢插入和更新速度,从而使事实数据表的加载速度变得太慢,特别是当它的大小增加时。索引用于在加载表后进行查询,因此可以在插入/更新期间禁用索引,然后重新生成索引。外键关系很重要,而不是外键本身:这实际上是ETL过程中的隐式关系。我发现在现实世界的数据仓库中,外键会使事情变得太慢。您需要使用虚拟外键:关系是它们的,但不是约束。如果损坏了数据仓库中的外键关系,则说明您做错了什么。 如果您在插入过程中禁用它们,并且存在不匹配或孤立的情况,您将无法重新启用它们,那么重点是什么呢? DW的关键是快速访问和查询。外国钥匙使这成为不可能。 有趣的辩论:不容易在网上找到这个问题 千电子伏