我想了解在实时DWH环境中如何利用代理键。我得到的是，他们添加了不依赖于源生成的数据来存储每个维度密钥的好处，并且还避免了从事实中的维度构建自然密钥的复合密钥，例如，（prod id + cust id + time id）
但是，当我们将数据加载到事实中时，它不会增加必须维护（自然键，代理键）的查找的复杂性。我在BI / DW团队工作了3年，我们的系统中没有维护任何代理键。我们利用自然键来构建我们的数据集市。一个示例用例是存储在事务系统中的收入数据，该事务系统使用来自源的相同自然密钥以客户，产品，时间段粒度加载到仓库中。我们使用相同的方法连接相应的维度来构建STAR模式。
我认为在我们的案例中有意义的主要原因是企业使用EDW数据对帐户级别的数据进行微观分析，而不仅仅是趋势分析。在我们使用自然键实现的情况下，我们需要保持数据完整性。我想了解其他DW环境的工作原理。如何利用系统中的代理键或自然键。
谢谢！
答案 0 :(得分：3)
一个原因是维持并能够比较历史变化。
示例，如果您的某个产品属性发生更改，并且您希望查看并比较属性更改之前和之后的收入，那么如果不使用代理产品密钥，您将如何做到这一点？使用自然键只会在ETL时覆盖旧值。
查找不一定非常复杂。大多数ETL工具都支持此功能，并且通常内置一些缓存机制来缓存查找值。
另外，当您说“实时”数据仓库时，您的意思是什么？您使用的是ROLAP，DirectQuery还是类似的东西？如果是这样，您可能直接在OLTP系统上构建marts并在某些语义模型中进行反规范化。然后您可以使用自然键，因为没有传统的ETL /数据仓库来执行查找和存储您的代理键。
最后，粒度与您使用的密钥类型无关。
答案 1 :(得分：2)
如果您的业务稳定并且在一个应用程序的基础上运行，那么自然键可以正常工作，正如您的经验告诉您的那样。
大多数企业长期不处于这样的状态。合并发生，新的应用程序被引入，遗留的东西拒绝死亡。新业务线开始或分拆，需要批量重新命名现有的自然密钥方案。
当您拥有大量独立的新旧应用程序时，代理键提供了很大的好处，可以使报表维度在整个企业中保持稳定和可用，这些应用程序都拥有自己的客户和产品版本，并定期针对类似系统进行迁移或交换使用新的自然键定义。主要工作是将客户/产品的各种自然键连接起来，分配代理键只是一个简单而有用的步骤。
即使在您的场景中，我也会使用代理键为您准备未来的更改，并且对于类型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％的销售增长被证明是一个错误时，有点痛苦。
答案 2 :(得分：2)
尚未提及的另一个原因是性能。有时（根据我的经验），自然键是字符串，有时是长字符串。
使用10,20或30字节的字符串而不是4字节的整数似乎不是什么大不了的事，但是当你有10个维度和数亿个行时，它会加快速度。
答案 3 :(得分：1)
请您发布样本设计。
我很想知道如何使用自然键的Dimension Keys加载事实表。 Kimball设计永远不会推荐它。
我站在DWH的代理键上。
然而，我不是在这里排队，在专业或反对你的立场之前会等你的设计。
干杯 尼西