我知道在数据仓库维度中使用代理键是有充分理由的。 不过，我不明白如何将它们链接到我的事实表的外键。 在事实表中，我只有在ETL期间提取的自然键。原始数据库表中不存在代理键。 有什么建议吗？谢谢
答案 0 :(得分：4)
有几个＆＃34;见＆＃34;以下参考。这是我在Stack Overflow上的第一个答案，所以我没有足够的声誉点来提供给你的链接。如果你在维基百科上查找这些术语，它们会提供比我更能说明这些术语的详细描述。
在我使用的数据仓库中，我们通常存储引用事实表中各个维度的代理键。实际上，除了在特殊情况下（例如degenerate dimensions），我避免在事实表中存储来自源系统的自然键。这有几个原因：
通常，在加载事实表的转换阶段，我查找来自源系统的自然键的代理键，然后将代理键存储在事实表而不是自然键中。我不知道你在哪个平台上，你可以在大多数数据库平台上使用JOIN来做到这一点。我经常在Microsoft SQL Server平台上使用SSIS查找。
答案 1 :(得分：2)
在加载事实表的ETL过程中实现代理键分配。
自然键，例如产品代码ABSFG-QXYX-12673726使用专用映射表映射到代理键，通常为整数，例如1238。
代理键非常有用，应该在以下情况下部署：
自然键是可更改的，即尽管更改了自然键，您仍需要使用相同的代理键进行报告
自然密钥可以重复使用，即您获得相同的自然密钥，但必须将其报告为新实体
自然键是不方便的，例如极长的哈希码，对于存储，加入或排序可能有问题
在某些使用案例中，代理键的使用应受到严厉质疑：
自然密钥（例如从源系统提取的密钥）已经代理（例如序列生成密钥）
源系统无法提供有关自然密钥的其他信息（例如更改或重用信息）;即代理键实际上是自然键的1：1映射。
永远不要将代理键用于时间维度，尤其是如果事实表按时间范围分区（因为代理键将禁用范围分区修剪）。
代理键也有其缺点
它需要ETL过程中的映射（性能）
最终报告可能需要反向映射到自然键（性能）
一致性 - 如果出现“未知”自然键，则必须处理代理键映射失败的情况。你应该拒绝事实记录还是（不完整的）映射表的问题？
当然，代理键映射中的ETL错误可能会导致问题......
因此，为了得出摘要，我会说是，使用代理键有充分的理由，但是还有很好的理由不使用代理键。您应该始终仔细检查来自源系统的界面，并使用检查每个维度密钥，检查使用代理键的利润是否高于成本。
答案 2 :(得分：1)
要严格回答“如何将它们链接到我的事实表的外键”这一问题，您应首先通过分配代理键来加载您的维度，然后通过按业务键查找维度并找到代理键和用它来存储事实。或者，如果延迟到达维度，如果在事实加载时无法通过业务键找到维度成员，则使用业务键创建维度成员并使用指定的代理键。稍后，当维度成员到达DWH时，只需更新其中的其他属性。
从实际角度来看，如果不需要近乎实时的DWH，或者每天只更新DWH两次，例如每晚和午餐时间，只需几分钟即可重新加载如果您的主要事实表只有几百万条记录，那么请不要使用代理键。在实践中，如果你有非常大的工作量和数百万的事实，这是很好的。通过阅读本文https://technet.microsoft.com/en-us/magazine/2008.04.dwperformance.aspx
，您可以获得一些见解如果你想利用非常大的DWH，例如大规模并行DWH或Hadoop技术，您应该将代理键更改为哈希键，以最大限度地减少数据移动，避免数据偏斜并提供平衡执行。