我想了解在实时 DWH 环境中如何利用代理键。我知道他们增加了不依赖源生成的数据来存储每个维度键的好处，并且实际上还避免了由维度中的自然键构建的复合键，例如，（prod id + cust id+ time id）
但是，当我们将数据加载到事实中时，它是否不会增加必须维护（自然键、代理键）查找的复杂性。过去 3 年我一直在 BI/DW 团队工作，我们的系统中没有任何代理键。我们利用自然键来构建我们的数据集市。一个示例用例是存储在交易系统中的收入数据，该数据使用来自源的相同自然键以客户、产品、时间段粒度加载到仓库中。我们使用相同的方法加入相应的维度来构建 STAR 模式。
我认为在我们的案例中有意义的主要原因是企业使用 EDW 数据在帐户级别对数据进行微观分析，而不仅仅是趋势分析。在这种情况下，我们需要使用自然键来维护数据完整性。我想了解其他 DW 环境是如何工作的。您如何在系统中利用代理键或自然键。
谢谢！
一个原因是保持并能够比较历史变化。
例如，如果您的产品属性之一发生更改，并且您想查看和比较属性更改前后的收入，您将如何在不使用替代产品密钥的情况下做到这一点？ETL 时使用自然键只会覆盖旧值。
查找不必非常复杂即可维护。大多数 ETL 工具都支持这一点，并且通常有一些内置的缓存机制来缓存查找值。
另外，当您说“实时”数据仓库时，您是什么意思？你在使用 ROLAP、DirectQuery 还是类似的东西？如果是这样，您可能会直接在您的 OLTP 系统上构建您的集市，并在某些语义模型中进行反规范化。然后您可以使用您的自然键，因为没有传统的 ETL/数据仓库来进行查找和存储您的代理键。
最后，粒度与您使用的密钥类型无关。
如果您的业务是稳定的，并且在单个应用程序之上运行所有内容，那么自然键就可以正常工作，正如您的经验所告诉您的那样。
大多数企业都没有处于这种状态或不会持续很长时间。合并发生，新的应用程序被引入，遗留的东西拒绝消亡。新的业务线开始或分离，需要对现有的自然密钥方案进行大规模重命名。
当您拥有一堆独立的新旧应用程序，这些应用程序都有自己的客户和产品版本并定期迁移或换成具有新自然功能的类似系统时，代理键在保持报告维度在整个业务中稳定和可用方面提供了巨大的好处关键定义。主要工作是链接客户/产品/任何东西的各种自然键，分配代理键只是其中一个简单且非常有用的步骤。
即使在您的场景中，我也会使用代理键，因为它们为您准备未来的更改，并且对类型 2 维度中的历史数据（正如 NITHIN B 也回答）非常有帮助。
通过向维度表和事实表添加版本字段来使用自然键进行版本控制是很可能的，但它会使连接更难编写用于报告，并且如果业务或应用程序更改导致自然键更改，您的整个系统仍然会变得混乱。
为了显示：
Select bla
from Fact F
inner join Dim_Customer DC
on F.Surrogate_key = DC.Surrogate_Key
几乎是万无一失的。如果你把它搞砸了，它会在你的报告中立即显现出来。
Select bla
from Fact F
inner join Dim_Customer DC
on F.Natural_key = DC.Natural_Key
and F.Version = DC.Version
做同样的工作，但如果你忘记了最后一行，一切看起来都很正常，但你的数字会根据平均有多少版本而被夸大。当 25% 的销售额增长被证明是一个错误时，有点痛苦。
另一个尚未提及的原因是性能。有时（根据我的经验经常）自然键是字符串，有时是长字符串。
使用 10、20 或 30 字节的字符串而不是 4 字节的整数似乎没什么大不了的，但是当你有 10 维和数亿行时，它加起来很快。
您能否发布一个示例设计。
我很想知道如何使用自然键的维度键加载事实表。Kimball 设计从不推荐它。
我对 DWH 中代理键的立场。
但是，我不会在这里插队，会等待你的设计，然后再去支持或反对你的立场。
干杯尼廷