4

我了解在数据仓库维度中使用代理键有充分的理由。不过，我不明白如何将它们链接到我的事实表的外键。在事实表中，我只有自然键，在 ETL 期间提取。原始数据库表中不存在代理键。对此有什么建议吗？谢谢

4

3 回答 3

5

下面有几个“参见”参考。这是我在 Stack Overflow 上的第一个答案，所以我还没有足够的声望点来向您提供链接。如果您在 Wikipedia 上查找这些术语，它们对这些事物的描述比我所能提供的更雄辩。

在我使用过的数据仓库中，我们通常存储引用事实表中各种维度的代理键。事实上，我避免将来自源系统的自然键存储在事实表中，除非在特殊情况下（例如，退化维度）。这有几个原因：

  • 连接效率——一些源系统可能不使用简单的整数键；使用代理键可以降低这种复杂性，从而使您的数据仓库查询性能更好，因为它只需要处理单列整数连接。
    • 从源系统中抽象出事实表；您的事实表可能比特定源系统（或源系统的版本）的寿命更长，或者事实可能来自具有不同自然键的不同源系统。无论自然键设计如何，事实表和维度表之间的关系保持不变。
    • 准确有效的时间点事实 - 如果维度中的属性历史很重要，您可以使用代理键来存储维度行的历史副本并将更正版本附加到事实表行（请参阅慢慢改变尺寸；尤其是类型 2)
    • 该维度可以被来自多个源系统的多个事实表使用，或者可以从多个源系统合并，在这种情况下，源系统自然键和维度代理键之间不会存在简单的关系（请参阅一致维度）
    • 未知数 - 有时您可能会发现自然键为 NULL、无效值或某些怪异的事实。您可以通过在维度表中使用更特殊的行之一来表示该条件并仍然保持数据库中的引用完整性，以表示未知、无效、尚未发生或任何适当的情况。（从技术上讲，NULL 的值不能成为键，但是一些数据库引擎会让您以数据仓库的性能和可用性为代价来摆脱它）
    • 我确定我忘记了一些非常重要的...

通常，在加载事实表的转换阶段，我会查找来自源系统的自然键的代理键，然后将代理键而不是自然键存储在事实表中。我不知道您在哪个平台上，您可以在大多数数据库平台上使用 JOIN 来执行此操作。我经常在 Microsoft SQL Server 平台上使用 SSIS 查找。

于 2015-12-14T16:05:59.003 回答
2

要严格回答“我如何将它们链接到我的事实表的外键”这个问题，您应该首先通过分配代理键来加载您的维度，然后通过按业务键查找维度来加载您的事实并找到代理键并使用它来存储事实。或者，在迟到维度的情况下，如果在事实加载时无法通过业务键找到维度成员，则使用业务键创建维度成员并使用分配的代理键。稍后，当维度成员到达 DWH 时，只需更新其中的其他属性。

从实际的角度来看，如果不需要近乎实时的 DWH，或者如果您每天只更新两次 DWH，例如每晚和午餐时间，并且从头开始重新加载它只需几分钟，并且如果您的主要事实表只有几百万条记录，那么不要使用代理键。在实践中，如果您的工作量非常大并且有数百万个事实，这很好。您可以通过阅读这篇文章获得一些见解https://technet.microsoft.com/en-us/magazine/2008.04.dwperformance.aspx

如果您想使用真正大的 DWH，例如大规模并行 DWH 或 Hadoop 技术，那么您应该将代理键更改为散列键，以最大限度地减少数据移动、避免数据倾斜并提供平衡的执行。

于 2015-12-14T22:13:02.910 回答
2

代理键分配是在加载事实表的 ETL 过程中实现的。

自然键（例如产品代码 ABSFG-QXYX-12673726）使用专用映射表映射到代理键，通常为整数，例如 1238。

代理键很有用，应该在以下场景中部署：

  • 自然键是可变的，即尽管自然键发生变化，您仍需要使用相同的代理键进行报告

  • 自然键可以重复使用，即你得到相同的自然键，但它必须被报告为一个新的实体

  • 自然键不方便，例如极长的哈希码，这可能对存储、连接或排序有问题

在某些用例中，代理键的使用应该受到严格质疑：

  • 自然键（例如从源系统中提取的键）已经是代理（例如序列生成的键）

  • 源系统不能提供有关自然键的附加信息（例如更改或重用信息）；即代理键实际上是自然键的 1:1 映射。

  • 切勿将代理键用于时间维度，尤其是当事实表按时间进行范围分区时（因为代理键会禁用范围分区修剪）。

代理键也有它的缺点

  • 它需要ETL过程中的映射（性能）

  • 最终报告可能需要反向映射到自然键（性能）

  • 一致性——如果出现“未知”自然键，您必须处理代理键映射失败的情况。您应该拒绝事实记录还是（不完整）映射表的问题？

  • 当然，代理键映射中的 ETL 错误会导致问题……</p>

所以总结一下，我会说是的，使用代理键有很好的理由，但不使用代理键也有很好的理由。您应该始终仔细检查源系统的接口，并为每个维度键检查使用代理键的利润是否高于成本。

于 2015-12-14T17:22:16.620 回答