Database design EDW中的代理键和引用完整性

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

实际问题
因为每个国家都有自己的“本地”PK，所以在将冲突整合到EDW中时，我需要一个处理冲突的策略。在这种情况下，简单地创建复合键是最常见的吗？e、 g.源代码id+源代码国家/地区，还是在此处生成代理密钥更好

例如：

A.foobar
id
说明

B.foobar
id
说明

将成为：

EDW.foobar
id
foobar_id
来源国
说明

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

如果有人有这个问题的经验，我会感谢你的建议，因为我认为我目前的方法行不通。还有几个必然的主题，例如版本控制和历史化，以及EDW 3NF和数据集市之间的cdc，这些主题也在这里发挥作用，但我稍后将回到这些主题

N.B.

---

我进行的大部分研究都是专门针对Kimball风格的数据集市，而不是Inmon的3NF企业数据模型。此外，在整合分布式数据库这一主题上，我一直在努力寻找任何有用的东西，因为基础架构是相同的。

生成代理键是处理这种情况的最常用方法。因此，您将拥有代理密钥（它为您提供了密钥稳定性和通常更好的DB性能），但仍然保持您的业务密钥（因为这是您将在业务层上展示的）

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

不应该有。当然，如果这是一个现有的仓库，并且您要引入一个代理密钥，那么您必须进行重构以在整个仓库中传播代理密钥，但这应该是一次性的。仓库内的所有内容都应引用代理密钥

---

这里有一个关于代理与业务密钥主题的老讨论，非常值得一读：

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

不要养成在创建的每个表上都使用代理键的习惯。即使大多数表以代理键结束，这样做的习惯也会自动导致设计的惰性，并隐藏代理键不是最佳选项的时间