代理密钥是一种在我们的书中存在多年的机制，我不想再讨论它。每个人都在谈论使用代理密钥而不是业务密钥的好处。甚至Microsoft Analysis Services表格模型和Microsoft PowerBI表格模型也在使用代理密钥。上述两个平台都允许您使用一列连接维度和事实，因此是一个代理密钥，因为在现实生活中很难有一个单一的业务密钥。
最近几年，作为BI架构师，我在AnalysisServices多维和表格中工作，我有多维项目，每晚在DataWarehouse中管理高达500GB。我面对的事实来自5-6个工会，8-10个加入了有数百万记录的表格。
问题来了，使用代理密钥，为了能够知道维度密钥，我们需要进行额外的Join。因此，如果我们希望能够"；Relate"；N个维度(尚未与构造表达式中的一个事实连接(与一个事实，我们需要在DataWarehouse中添加N个Joins。
让我们举前面的例子，所以对于这个特定的事实，我们需要5-6个并集+(8-10+N(连接，这增加了复杂性，一旦我们需要将这个事实与10-15个维度联系起来以获得代理密钥，就会发生什么。
这些年来，我一直在尝试用我早期的咖啡来阅读我的事实表达式，就像读报纸一样，删除未使用的列、联合、联接，并尽一切努力降低复杂性以节省ETL过程时间。
它完全理解我们将节省查询数据仓库和语义层的时间，但ETL呢，我缺少了一些东西？
关于您的问题的一些想法。。。
- 如果您不使用SKU，那么您将如何处理SCD2维度，因为源系统中的自然/业务密钥(即使它们是单列(不会是唯一的
- DW的目的是使查询数据更加简单快捷。如果您认为任何问题都需要付出一定的努力才能解决，那么您可以选择在产生解决方案所需的活动链中应用这些努力。如果你想减少查询的工作量，那么你需要增加数据准备的工作量，即ETL