将外键放在数据仓库（关系）中是一种好习惯吗？

Question

我认为问题很清楚。我的datawarehouse表中的某些列可能与主键有关系。但这是好的做法吗？它是非规范化的，所以永远不要再删除它（datawarehouse中的数据）。希望问题有点清楚。

Answer 1

我认为你在事实表中引用了FK。在DW加载期间，会删除索引和任何外键以加速加载 - ETL过程会处理密钥。

外插键约束在插入和更新期间“激活”（这是在需要检查父表中是否存在键值时）以及在删除父表中的主键期间。它在读取过程中不起作用。删除DW中的记录（应该）是一个受控进程，在从维度表中删除之前会扫描任何现有关系。

因此，大多数DW没有将外键实现为约束。

Answer 2

FK约束在SQL Server上的Kimball维模型中运行良好。

通常，您的ETL需要查找维度表（通常在业务键上以处理缓慢变化的维度）以确定维度代理ID，维度代理ID通常是标识，维度上的PK是通常是维度代理id，它已经是一个索引（可能是聚集的）。

此时使用RI并不是写入的大量开销，因为它还可以帮助在开发期间捕获ETL缺陷。此外，将事实表的PK作为所有FK的组合也可以帮助捕获潜在的数据建模问题和双重加载。

如果您想制作星型模型的通用平面视图或表值函数，它实际上可以减少选择的开销。因为维度的额外内部连接保证只生成一行，所以优化器可以非常有效地使用这些约束来消除查找表的需要。如果没有FK约束，可能必须执行这些查找以消除维度不存在的事实。

Answer 3

问题很明确，但“良好做法”似乎是错误的问题。

“能否拥有FK的”？

外键是一种在数据库修改期间保留完整性约束的机制。

如果您的DW是只读的（累积数据源而不回写），则不需要FK。

如果您的DW支持写入，则ETL通常需要在参与的数据源之间协调完整性保护（而不是它的Store等效项）。此过程可能依赖于也可能不依赖于数据库中的FK。

所以正确的问题是：你需要他们。

（我能想到的唯一其他原因是关系文件 - 但是，这也可以在纸上/单独的文件中完成。）

Answer 4

我不知道。但是没有人回答，所以我用谷歌搜索，发现a best practises paper似乎说“非常有帮助”： - ）

  

虽然外键约束有助于数据完整性，但它们在所有insert，update和delete语句上都有相关的成本。当您希望确保数据完整性和验证时，请特别注意仓库或ODS中约束的使用

Answer 5

在数据仓库中使用外键约束的原因与任何其他数据库相同：确保数据完整性。

查询性能也有可能受益，因为外键允许某些类型的查询重写，如果没有它们通常是不可能的。但是，数据完整性仍然是使用外键的主要原因。

Answer 6

在DW中使用FK约束就像戴自行车头盔一样。如果ETL设计正确，您技术上不需要它们。也就是说，如果每次我看到无错误的ETL我都有一百万美元，我就会有零美元。

直到你处于FK约束导致性能问题的地步，我说离开了。清理参照完整性问题比从一开始就添加它们要困难得多; - ）

Answer 7

是的，作为最佳实践，在事实表上实现FK约束。在SQL Server中，使用NOCHECK。在ORACLE中始终使用RELY DISABLE NOVALIDATE。这允许仓库或市场了解关系，但不在INSERT，UPDATE或DELETE操作上检查它。星形转换，优化等可能不依赖于FK约束来改进查询，但是人们永远不知道在正面或仓库或集市上将使用哪些BI或OLAP工具。其中一些工具可以利用知道定义的关系。另外，您在很少或没有外部文档的情况下看到了多少丑陋的仓库，并且不得不尝试对它们进行逆向工程？定义FK总是有帮助的。

作为设计师，我们似乎从未像现在这样将我们的数据仓库或集市作为自我记录。定义FK肯定有助于此。现在，已经说过，如果在没有定义FK的情况下正确设计星型模式，那么无论如何都很容易阅读和理解它们。

对于ORACLE事实表，始终在每个FK上为一个维度定义一个LOCAL BITMAP索引。去做就对了。索引实际上比定义的FK更重要。

Answer 8

即使只读DW / DM也有很好的理由来创建FK约束。 是的，如果您的ETL是防弹等等，它们并非真正需要从只读DW本身的角度来看，等等。但是猜猜是什么 - 生活并没有停止在DW中的加载数据。大多数BI分析/报告工具都使用有关DW关系的信息来自动构建其模型（例如SSAS表格模型）。 在我的拙见中，仅这一点就超过了在ETL过程中丢弃和重新创建FK约束的小开销。