在维度表中使用源代理键

Question

对数据建模相当陌生，有以下场景，不确定如何进行设计

我有一个源表，其中包含自然键和称为 MED_key 的代理键的组合，下面是一个简单的示例：

--Table_Medications

MED_Key | Medication Name | Medication Desc | Class Lvl One | Class Lvl Two
-----------------------------------------------------------------------------
759456123 | Med_ABC1 | Medication for ABC 1 - Long Descriptive Text Here | Calcium | Calcium Type A
781456113 | Med_ABC1 | Medication for ABC 1 - Long Descriptive Text Here | Calcium | Calcium Type B
689476143 | Med_ABC1 | Medication for ABC 1 - Long Descriptive Text Here| Calcium Extra | Calcium Type C
709456129 | Med_ABC1 | Medication for ABC 1 - Long Descriptive Text Here| Calcium Extra | Calcium Type D
989476125 | Med_ABC2 | Medication for ABC 2 - Long Descriptive Text Here| Vit A | Vit A
009456199 | Med_ABC3 | Medication for ABC 3 - Long Descriptive Text Here| Aspirin | Aspirin


--Table_Medication_Prescribed

Trx No | Qty | Amt | MED_Key
-----------------------------
1 | 5 | 23.45 | 781456113 
2 | 3 | 5.10 | 989476125 
3 | 9 | 87.12 | 759456123 

Table_Medication_Prescribed 将是 FACT 表。

Table_Medications 将是 DIM 表。在使用 Dimension Key 填充 FACT 表时，我觉得当我使用四个 VARCHAR 字段（名称、描述类 Lvl 1/2）进行连接时，处理时间可能会很慢。我不确定将 MED_Key 用作 DIM 表中的“自然键”，是否有任何不这样做的规则？ 任何人都可以提供最好的解决方法吗？

Answer 1

以下是 Kimball 集团关于在维度中使用代理键的好引述：

维度表设计有一个列作为唯一的主键。此主键不能是操作系统的自然键，因为随着时间的推移跟踪更改时，该自然键将有多个维度行。此外，一个维度的自然键可能由多个源系统创建，并且这些自然键可能不兼容或管理不善。 DW/BI系统需要声称控制所有维度的主键；您应该为每个维度创建匿名整数主键，而不是使用显式自然键或带有附加日期的自然键。这些维度代理键是简单的整数，按顺序分配，从值 1 开始，每次需要新键时。日期维度不受代理键规则的约束；这个高度可预测且稳定的维度可以使用更有意义的主键。

从这里带走的关键东西。第一个不是管理不善的部分，而是您需要如何控制所有维度的主键。虽然您不是专门谈论自然键，但您也在谈论源系统代理键。我确实相信这仍然适用，因为自然键的规则是因为源系统正在控制它。因此，如果他们也向您发送代理键，则同样的规则也适用。

我遇到的现实问题

我在使用来自我信任的源系统的代理键时遇到的一个问题是源系统在客户端之间重用代理键时。实际上，后来为了扩展目的而创建了另一个源系统，并将 X 数量的客户端数据推送到该系统中。因此，仅为这些客户端重置了所有密钥。对于进入统一数据集（即：数据仓库）的两个独立客户端，我有冲突的代理键...

但是，如果您相信代理键将保持正确，您也可以将其留给您的最佳判断。但是，一旦它没有改变或发生某些变化，它就会破坏 ETL 过程，并且您可能会遇到问题。 因此，我的建议（或回答）是始终要求控制主键并为每个维度生成您自己的代理键，如 Kimball 建议的那样按顺序分配的简单整数。

数据应流向临时表，维度应使用系统生成/管理的代理键填充，然后使用典型的 UPDATE JOIN 方法附加回 FACT。加入会发生，不要像我们一样担心这部分过程。

希望有帮助