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

Question

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

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

例如：

A.foobar
ID
说明
...

B.foobar
ID
说明
...

会变成：

EDW.foobar
ID
foob​​ar_id
source_country
描述

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

如果有人遇到过这个问题的经验，那么我很感激你的意见，因为我认为我目前的方法不会起作用。还有几个必然的主题，例如：版本和历史记录，以及EDW 3NF和数据集市之间的cdc，也在这里发挥作用，但我稍后会再回过头来看。

N.B。
我所进行的大多数研究都专门用于填充Kimball风格的数据集市，而不是Inmon的3NF企业数据模型。此外，我一直在努力找到有关合并分布式数据库主题的任何有用的东西，其中底层架构是相同的。

Answer 1

生成代理键是处理此方案的最常用方法。因此，您将获得代理密钥（它为您提供密钥稳定性和通常更好的数据库性能），但仍然维护您的业务密钥（因为这是您在业务层上的内容）。

  

这会对EDW中的参照完整性产生什么影响？

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

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

Answer 2

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

不要养成在你创建的每张桌子上拍一个代理键的习惯。即使大多数表格都以代理键结束，这样做的习惯会自动导致设计的懒惰，并且当代理键不是最佳选择时隐藏这些时间。