【发布时间】:2016-03-19 21:24:51
【问题描述】:
我了解在数据仓库维度中使用代理键有充分的理由。 不过,我不明白如何将它们链接到我的事实表的外键。 在事实表中,我只有自然键,在 ETL 期间提取。原始数据库表中不存在代理键。 对此有何建议?谢谢
【问题讨论】:
-
你能发布你的事实/维度的 ERD 来帮助解释吗?
标签: data-warehouse dimensional-modeling surrogate-key
我了解在数据仓库维度中使用代理键有充分的理由。 不过,我不明白如何将它们链接到我的事实表的外键。 在事实表中,我只有自然键,在 ETL 期间提取。原始数据库表中不存在代理键。 对此有何建议?谢谢
【问题讨论】:
标签: data-warehouse dimensional-modeling surrogate-key
要严格回答“我如何将它们链接到我的事实表的外键”这个问题,您应该首先通过分配代理键来加载您的维度,然后通过按业务键查找维度来加载您的事实并找到代理键和用它来存储事实。或者,在迟到维度的情况下,如果在事实加载时无法通过业务键找到维度成员,则使用业务键创建维度成员并使用分配的代理键。稍后,当维度成员到达 DWH 时,只需更新其中的其他属性。
从实际的角度来看,如果不需要近乎实时的 DWH,或者如果您每天仅更新两次 DWH,例如在晚上和午餐时间,并且只需几分钟即可从从头开始,如果您的主要事实表只有几百万条记录,那么不要打扰代理键。在实践中,如果您的工作量非常大并且有数百万个事实,这很好。你可以通过阅读这篇文章获得一些见解https://technet.microsoft.com/en-us/magazine/2008.04.dwperformance.aspx
如果您想使用非常大的 DWH,例如大规模并行 DWH 或 Hadoop 技术,那么您应该将代理键更改为哈希键,以最大程度地减少数据移动,避免数据倾斜并提供平衡的执行。
【讨论】:
下面有几个“见”参考。这是我在 Stack Overflow 上的第一个答案,所以我还没有足够的声誉点来向您提供链接。如果您在 Wikipedia 上查找这些术语,它们对这些事物的描述比我能提供的更雄辩。
在我使用过的数据仓库中,我们通常将引用不同维度的代理键存储在事实表中。事实上,我避免将来自源系统的自然键存储在事实表中,除非在特殊情况下(例如,degenerate dimensions)。这有几个原因:
一般来说,在加载事实表的转换阶段,我会查找来自源系统的自然键的代理键,然后将代理键而不是自然键存储在事实表中。我不知道您在哪个平台上,您可以在大多数数据库平台上使用 JOIN 来执行此操作。我经常在 Microsoft SQL Server 平台上使用 SSIS 查找。
【讨论】:
代理键分配是在加载事实表的 ETL 过程中实现的。
自然键,例如产品代码 ABSFG-QXYX-12673726 使用专用映射表映射到通常为整数的代理键,例如 1238。
代理键很有用,应在以下情况下部署:
自然键是可变的,即尽管自然键发生变化,您仍需要使用相同的代理键进行报告
自然键可以重复使用,即您获得相同的自然键,但必须将其报告为新实体
自然键不方便,例如极长的哈希码,可能对存储、连接或排序造成问题
在某些用例中,代理键的使用应该受到严格质疑:
自然键(例如从源系统中提取的键)已经是代理项(例如序列生成的键)
源系统无法提供有关自然键的附加信息(例如更改或重用信息);即代理键实际上是自然键的 1:1 映射。
切勿将代理键用于时间维度,尤其是在事实表按时间进行范围分区时(因为代理键会禁用范围分区修剪)。
李>代理键也有其缺点
需要ETL过程中的映射(性能)
最终报告可能需要反向映射到自然键(性能)
一致性 - 如果出现“未知”自然键,您必须处理代理键映射失败的情况。是拒绝事实记录还是(不完整)映射表的问题?
当然,代理键映射中的 ETL 错误会导致问题……
所以总结一下,我会说是的,使用代理键有充分的理由,但也有不使用代理键的充分理由。您应该始终仔细检查源系统的接口,并检查每个维度键是否使用代理键的利润更高成本。
【讨论】: