包含来自多个源表的数据的维度中自然键的最佳实践

Posted 2023-03-29

【中文标题】包含来自多个源表的数据的维度中自然键的最佳实践

【英文标题】：Best practice for natural keys in a dimension that includes data from multiple source table

【发布时间】：2015-06-02 19:22:37

【问题描述】：

我正在为一个数据仓库设计一个维度，其中包含来自不同表的多个相关属性。在加载事实表时，我通常喜欢根据来自源系统的键而不是各种属性的文本匹配来从维度表中查找代理键。对于像我所面临的情况，最好在维度表中有几个源系统键列（每个相关表中的一个）来进行查找，或者通过使用某种类型来创建单个查找列散列还是串联？

如果您需要更多信息，请告诉我。

【问题讨论】：

你能举个例子吗？我需要对“几个源键列”进行一些说明。

Nick：在这种情况下，维度存储有关肿瘤的数据，特别是存储肿瘤部位、肿瘤谱系和肿瘤亚谱系。这些数据点中的每一个都来自不同的表，但它们以属于同一维度的方式相关。例如，肿瘤部位表中有一个tumorSiteId，沿袭表中有一个lneageId，subLineage 表中有一个subLineageId。这有帮助吗？

@wshato 我建议创建可重现的示例：创建表 sql 脚本和 2+ csv 源数据示例。有这样的问题，你可以更容易得到准确的答案。

【参考方案1】：

最佳做法是一列相当于“源系统”和一个（或多个）统一类型的列，以容纳这些源系统的本机键（可能留有一点空间供将来校对）。

当您无法控制数据模型时，应始终将用于识别源的哈希或串联视为一种解决方法。

“来源”列有助于谱系。

因此，假设您有三个源系统，它们的“产品代码”格式各不相同，分别为 char 8、10 和 15。 添加列：

SourceID CHAR(5) - e.g. or a further surrogate look-up to a 'Source' table.
ProductCode CHAR(15)

15 = MAX(8,10,15)。

甚至VCHAR(20)，这取决于您是否可以期待未来的资源获取。 20 个字符对于任何源标识符来说都是相当大的。但请考虑相关问题领域的实践。

从不

SourceID CHAR(5)
ProductCode1 CHAR(8)
ProductCode2 CHAR(10)
ProductCode3 CHAR(15)

如果只是因为如果 Source 4 出现，您正在添加列。 也因为没有报告会像那样有用地显示。 很难加入您可能必须处理的任何通用“通用”表。 通过选择VCHAR，您可能会发现浪费了存储空间和膨胀索引，浪费空间会损害性能。