我知道在数据仓库维度中使用代理键是有充分理由的。 不过,我不明白如何将它们链接到我的事实表的外键。 在事实表中,我只有在ETL期间提取的自然键。原始数据库表中不存在代理键。 有什么建议吗?谢谢
答案 0 :(得分:4)
有几个"见"以下参考。这是我在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技术,您应该将代理键更改为哈希键,以最大限度地减少数据移动,避免数据偏斜并提供平衡执行。