作为SQL新手，疑惑为什么不用自然键直接关联事实表和维度表是很正常的，代理键在维度建模里的核心价值体现在以下几个方面：

1. 彻底隔离业务系统的变更风险 #

自然键（比如你代码里的cst_id、sls_prd_key）是业务系统生成的，一旦业务规则调整（比如客户ID升级为带前缀的格式、合并多系统导致ID冲突重复），直接依赖自然键的关联逻辑会全部失效。而代理键是数据仓库层独立生成的（比如你用row_number()生成的customer_key、product_key），和业务系统完全解耦，业务端怎么变，仓库的关联逻辑都不需要修改。

2. 支持缓慢变化维（SCD）的处理 #

维度表经常需要保留历史数据，比如客户地址变更、产品版本迭代，要记录每个时间点的维度状态。自然键无法区分同一个业务实体的不同版本，代理键可以给每个维度版本分配唯一值，让事实表能精准关联到对应时间的维度信息。比如你代码里dim_products过滤了prd_end_dt is null的当前数据，如果后续要保留历史产品版本，代理键就能帮你区分每个版本的产品，确保事实数据关联的准确性。

3. 简化关联逻辑，提升性能 #

有些自然键是多字段组合的唯一键（比如部分业务中产品需要prd_id+prd_version才能唯一标识），关联时需要写多字段匹配条件，代码冗余且性能差。代理键是单字段的唯一值，像你代码里fact_sales只用product_key、customer_key就能关联维度表，代码更简洁，同时单字段索引的查询效率远高于复合索引。

4. 避免自然键的不稳定性 #

业务系统里的自然键可能存在重复、空值或者非唯一的情况（比如数据录入错误导致客户ID重复），代理键在生成时可以保证绝对唯一性，从根源上避免关联错误。

结合你的示例代码看 #

在黄金层的维度视图dim_customers和dim_products中，通过row_number()生成代理键，然后事实表fact_sales用这些代理键关联维度表，而不是直接使用业务系统的sls_prd_key、sls_cust_id。这种设计就是为了最大化利用代理键的优势：比如未来CRM系统的cst_id格式变更，你只需要调整dim_customers的生成逻辑，fact_sales的关联代码完全不用动；如果产品有版本更新，代理键能帮你区分不同版本的产品，让销售事实数据关联到正确的产品维度信息。

内容的提问来源于stack exchange，提问作者Wonder101