代理键的复合键答案

【问题标题】：Composite key to surrogate key代理键的复合键
【发布时间】：2014-07-12 00:30:03
【问题描述】：

我从获取的数据中获得了一个复合自然键。使用 composite_key=ID-PRODUCT_ID-CLIENT_ID-OFFICE_ID ，我想将此键转换为一个代理键。

例子：

composite_key = 55-001-234-01 到 surrogate_key = 123；这是正常情况，有时办公室代码可以更改，但我想将记录标识为相同例如：composite_key = 55-001-234-02 to surrogate_key = 123.

【问题讨论】：

您将拥有一个将自然键映射到代理键的表。不过，通常情况下，您只会在数据表中拥有带有唯一约束的自然键以及代理键。
好的，但是我如何理解复合键的变化，例如办公室会导致相同的代理键。在这种情况下，如果我认为这些记录是相同的，因为只有办公室发生了变化并且从业务角度来看是可以的。
您必须编写一些规则，用户定义的函数似乎是一个不错的方法。
如果办公室 ID 可以更改而不意味着它应该映射到不同的代理键，那么我不认为它真的是您的目标结构的自然键的一部分。无论该“自然键”的哪个标记可以更改但不意味着它应该映射到的目标记录中的更改，都将它们剥离。例如，如果 ID、PRODUCT_ID 或 CLIENT_ID 中的任何一个更改应该意味着不同的记录，但 OFFICE_ID 无关紧要，那么您的“真实”自然键将变为 ID-PRODUCT_ID-CLIENT_ID。将其用作比较的基础，您的预期匹配就会发生。
我讨厌对你说“所有哲学”，但如果复合键是可变的，它真的是一个标识符吗？在某种程度上，代理键不仅应标识表中的一行，而且还应标识主题中的实体或关系的实例。复合自然键几乎总是识别关系。如果其中一个组件键发生变化，那么它就不再是关系的同一个实例了。

【解决方案1】：

如果两个具有不同 OfficeID 的成员应该映射到同一个代理键，那么这意味着 OfficeID 根本不是复合键的一部分，而只是具有类型 2（替换行为）的标准属性。

如果您的维度不是太大，我建议您使用 ETL 工具中提供的简单的渐变维度组件。如果您没有这样的组件，只需通过查找来检查您维度中的成员是否存在。如果存在，则应用更新以（最终）更改 OfficeID，如果不应用插入。

如果您有较大的维度和性能问题，那么通过计算属性集类型 2 的校验和来提高性能可能很有用。您的查找应返回此校验和并将其与当前行的校验和进行比较.如果它们相同，则不需要执行更新语句。

【讨论】：