Data warehouse 数据仓库中的代理密钥

我想了解在实时DWH环境中如何利用代理密钥。我发现，它们增加了不依赖源代码生成的数据来存储每个维度键的好处，也避免了使用维度中的自然键构建复合键，例如，（prod id+cust id+time id）

但是，当我们将数据加载到facts中时，它不会增加必须维护查找（自然键、代理键）的复杂性。我在BI/DW团队工作了3年，我们在系统中没有维护任何代理密钥。我们利用自然密钥构建数据集市。一个示例用例是存储在事务系统中的收入数据，它使用源中相同的自然密钥以客户、产品、时间段粒度加载到仓库中。我们使用相同的方法与相应的维度连接以构建星型模式

我认为这在我们的案例中有意义的主要原因是，业务部门使用EDW数据在账户级别对数据进行微观分析，而不仅仅是趋势分析。在这种情况下，我们需要保持数据完整性，这是我们使用自然密钥实现的。我想了解其他DW环境是如何工作的。如何在系统中利用代理密钥或自然密钥

---

谢谢

一个原因是保持并能够比较历史变化

例如，如果您的一个产品属性发生更改，并且您希望查看和比较属性更改前后的收入，那么在不使用代理产品密钥的情况下，您将如何做到这一点？使用自然键只会在ETL时覆盖旧值

查找不需要非常复杂才能维护。大多数ETL工具都支持这一点，并且通常内置一些缓存机制来缓存查找值

还有，你说的“实时”数据仓库是什么意思？您使用的是ROLAP、DirectQuery还是类似的工具？如果是这样，您可能直接在OLTP系统上构建MART，并在某些语义模型中进行反规范化。然后您可以使用自然密钥，因为没有传统的ETL/数据仓库来查找和存储代理密钥

---

最后，粒度与您使用的密钥类型无关

你能发布一个设计样本吗

我很想知道如何用维度键加载事实表，维度键是自然键。金宝设计从不推荐它

我在DWH中的代理密钥上的立场。

代理项键为您提供了很多灵活性，可用于类型2标注， 如果你有2类尺寸。例如：您可以跟踪客户的变化 如果他或她改变了她的第二个名字。您可以使用旧值和 新的价值观

事实表通常包含作为代理键的键。它使你成为明星 模式整洁、健壮

然而，我不是在这里插队，我会等待你的设计，然后再去专业或反对你的立场

干杯

---

Nithin

如果您的业务是稳定的，并且运行在一个应用程序之上，那么自然密钥将很好地工作，正如您的经验所告诉您的那样

大多数企业不是处于这种状态，也不是很长时间。合并发生，新的应用程序被引入，遗留的东西不会消亡。新的业务线开始或分离，需要对现有的自然密钥方案进行大规模重命名

当您有一组独立的新应用程序和旧应用程序，它们都有自己的客户和产品版本，并且定期迁移或替换为具有新的自然密钥定义的类似系统时，代理密钥在保持报告维度在整个业务中的稳定性和可用性方面提供了巨大的好处。主要工作是链接客户/产品/任何东西的各种自然密钥，分配代理密钥只是其中一个简单且非常有用的步骤

即使在您的场景中，我也会使用代理键，因为它们为您将来的更改做好准备，并且对类型2维度中的历史数据（如NITHIN B所回答的）非常有帮助

通过向维度表和事实表添加一个版本字段，可以使用自然键进行版本控制，但这会使连接更难编写报告，如果业务或应用程序更改导致自然键更改，则整个系统仍然会变得混乱

举例说明：

选择bla
根据事实F
内部连接DIMU客户DC
在F.subrogate_key=DC.subrogate_key上

这几乎是万无一失的。如果你把这件事搞砸了，它会立即在你的报告中显现出来

选择bla
根据事实F
内部连接DIMU客户DC
关于F.Natural\u key=DC.Natural\u key
F.版本=DC.版本

---

做同样的工作，但是如果你忘记了最后一行，一切看起来都正常，但是你的数字会根据平均版本的多少而膨胀。当25%的销售额增长被证明是一个错误时，这有点痛苦。

另一个原因是性能，这一点尚未提及。有时（在我的经验中）自然键是字符串，有时是长字符串

---

使用10、20或30字节的字符串而不是4字节的整数似乎没什么大不了的，但是当您有10维和数亿行时，它加起来很快。

输入很好…每当出现性能问题时，我都会练习代理键。谢谢根据我的经验，我没有遇到过合并等带来的数据问题，但我们确实有订单数据集，这些数据集经过修订，其中每个修订都有一个从源代码生成的id，该修订id（我们称之为订单id）用于识别最新版本。这本质上是我们从源代码中获得的代理密钥。谢谢在某些情况下，使用自然键处理集成实际上更容易，因为这通常是标准。复制自然钥匙是一种非常常见的方法