EDW 中的代理键和参照完整性

Question

问题概述
采用 Inmon 风格的 3NF 企业数据模型时，处理代理键和参照完整性的常用技术有哪些？在我的情况下，我必须填充一个 3NF 数据模型，该模型提供多个事务系统的“企业视图”。此外，每个 OLTP 都是分布式的，因此每个国家/地区都有一个实例。因此，我目前面临的挑战是将每个源系统整合到一个统一的数据模型中。

实际问题
因为每个国家/地区都有自己的“本地”PK，所以在将这些冲突整合到 EDW 时，我需要一种处理冲突的策略。在这种情况下，最常见的是简单地创建一个复合键吗？例如source_id + source_country 还是在这里生成代理键更好？

例如：

A.foobar
身份证
说明
...

B.foobar
身份证
说明
...

会变成：

EDW.foobar
身份证
foob​​ar_id
来源国
说明

因此，在合并数据模型中，我们最终会得到一个新的代理键 (id)，它唯一地标识每个源记录 (foobar_id + source_country)。这似乎合乎逻辑，但由于某种原因感觉不对。此外，因此我的问题是，这将对处理 EDW 中的参照完整性产生什么影响？也就是说，如果我们在源 3NF 和 EDW 3NF 之间生成新的代理键，那么在整个 EDW 模式中引用这些新键就会增加复杂性。在 ETL 实现方面，这意味着必须通过现有的 FK（源系统）查找新生成的代理键，然后将其替换为新的 FK。这意味着在 EDW 中维护多个 FK（一个用于查找新代理键和新代理键本身），这似乎很牵强。

如果有人遇到过这个问题，我会很感激你的建议，因为我认为我目前的方法行不通。还有一些推论的主题，例如版本控制和历史记录，以及 EDW 3NF 和数据集市之间的 cdc，这些也在这里发挥作用，但我稍后会回到这些方面。

注意
我进行的大部分研究都专门针对填充 Kimball 样式的数据集市，而不是 Inmon 的 3NF 企业数据模型。此外，我一直在努力寻找有关整合分布式数据库的任何有用信息，其中底层架构是相同的。

Answer 1

生成代理键是处理这种情况的最常用方法。因此，您将拥有代理密钥（它为您提供密钥稳定性和通常更好的数据库性能），但仍保留您的业务密钥（因为这就是您将在业务层上呈现的内容）。

这将对处理 EDW 中的引用完整性产生什么影响？

它不应该有。当然，如果这是一个现有的仓库并且您要引入代理键，您将不得不重构以在整个仓库中传播代理键，但这应该是一次性的。在仓库中，所有内容都应引用代理键。

这是关于代理与业务密钥主题的旧讨论，非常值得一读：Surrogate vs. natural/business keys

Answer 2

如果您的国家/地区表有一个非常好的 PK，并且您有另一个与国家/地区形成 1-1 关系的实体，那么请务必使用国家/地区 PK 作为该实体的 PK。它还将作为国家/地区表的 FK 参考。这形成了一种身份关系。也就是一个国家和这个另一个实体的关系这么强，这个国家的身份也形成了这个实体的身份。

不要养成在您创建的每张表上都使用代理键的习惯。即使大多数表最终都有一个代理键，这样做的习惯会自动导致设计的懒惰，并在代理键不是最佳选择时隐藏那些时间。