管理数据仓库中的代理键

Question

我想建立一个数据仓库，并且我想使用代理键作为我的事实表的主键。但问题是，在我的情况下，事实表应该更新。

第一个问题是如何在源系统中为自然键找到对应的自动生成的代理键？我看到一些答案提到了存储自然键和代理键之间对应关系的查找表，但我不明白它们是如何实现的。该表应该存储在哪里：数据仓库本身还是其他地方？

还有第二个问题。源系统已经包含事实的代理键，但它们具有 16 字节的 UUID 数据类型。而且事实的数量不太可能超过最大整数值（4 个字节）。我应该使用源系统提供的 UUID 来简化 ETL，还是应该执行更复杂的 ETL 并实现自己的整数代理键以获得更好的性能？

Answer 1

我认为其余的已经回答了。关于管理和维护代理键，我会给你 2 美分。

在 Teradata 工作期间，我经常使用代理键。以下是我多年来学到的一些关于代理键的最佳实践。

1. 您只能从批准的主源（在 你的情况是一个特定的API。不应允许太多 API 生成相同的域值。选择一个作为主人的 为您的域值。例如客户编号通常来自 CRM 系统，不太可能从计费系统作为主系统）
2. 您生成并将这些存储在一个查找表中（我们称之为 客户_SGK）。通常，这些代理键表不属于 您最终采用 inmon 或 kimbal 方法的 LDM/PDM。这些 驻留在同一数据库服务器中，而不是在技术 元数据模式。我们称该架构为“My_Tec_Schema”
3. 在这样的查找表中，您将拥有代理键​​列（例如 Customer_ID)，每个主源的源自然键列 (source1_customerNO, source2_customerNO) 和一个时间戳来保存 生成此密钥的时间。
4. 您的 PK 是 Customer_ID，它在此列中可能不是唯一的，因此根据所使用的数据存储技术，您可能必须将其分类为唯一或非唯一主索引/键（例如，在 Teradata 中它将是 NUPI）。李>

5. 有时您必须允许这样做以简化 ETL 流程，同时 为来自的两个不同的自然键加载相同的客户 ID 2 个不同的源系统，但它们都意味着同一个客户。

6. 有了这个查找表，你会想要加载它（生成键） 从您的阶段表/来源中，您的 ETL 中的第一件事 过程。然后你从你的舞台加载左外部加入查找 表来获取您的代理键并将其加载到您的事实表中 希望还有你的天然钥匙。 （你总是想拥有它们 因为大多数情况下，您的事实表中会出现一些孤儿，并且 恢复这种情况的唯一快速可靠的方法是 事实表中的自然键并使用 PK 或 PI 或索引 基于更新操作，非常快而不是全表 扫描）

7. 您始终可以通过以下方式在事实表中隐藏您的自然键 表示层视图（消费层使用的视图 应用程序和用户，同时保留您的表以用于 ETL 目的 / 仅限技术人员）
8. 由于您使用自动编号生成技术；在将数据从一个环境迁移到另一个环境时以及在主要版本期间迁移生产数据时，您必须特别注意。 （你不想拥有 碰撞）

我可以继续使用代理键。请在阅读此高级概述后提出任何具体问题。我很乐意提供帮助。

Answer 2

看来您的问题是： 如果我在我的数据仓库中在行的初始加载时生成代理键，我如何确定是否已经在后续加载时生成了键？是否应该创建一个查找表，如果需要，它将位于何处？

注意：如果可能，请在您的数据仓库目标表中包含来自源系统的密钥，即使您认为不需要它。它将证明对于解决 ETL 问题非常宝贵。

两个简单的选项：

1。直接针对目标表执行查找（性能可能是大型表的问题）。

2。创建一个“etl staging lookup”表，该表仅由您的 ETL 流程使用（但存储在您的数据仓库中）。这是更灵活的选项，但为您的 ETL 添加了额外的步骤。