数据建模相当新，并且下面的场景并不确定如何继续设计
我有一个源表，其中包含自然键和名为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字段（Name，Description Class Lvl 1/2）进行连接时，我可能会遇到一个缓慢的处理时间。我不确定将MED_Key用作＆＃34;自然键＆＃34;在DIM表中，有没有关于不这样做的规则？ 任何人都可以帮助解决这个问题吗？
答案 0 :(得分：4)
以下是Kimball Group在维度中使用代理键的一个很好的引用：
维度表的设计使用一列作为唯一主键。此主键不能是操作系统的自然键，因为随着时间的推移跟踪更改时，该自然键将有多个维度行。另外，维度的自然键可以由多于一个源系统创建，并且这些自然键可能是不兼容的或管理不善。 DW / BI系统需要声明对所有维度的主键的控制;您应该为每个维度创建匿名整数主键，而不是使用带有附加日期的显式自然键或自然键。这些维度代理键是简单的整数，按顺序分配，每次需要新密钥时，从值1开始。日期维度不受代理键规则的约束;这种高度可预测且稳定的维度可以使用更有意义的主键。
从这里带走的关键事项。第一个不是管理不善的部分，而是你需要如何控制所有维度的主键。虽然您没有具体谈论自然键，但您也在谈论源系统代理键。我相信这仍然适用，因为自然键的规则是因为源系统正在控制它。因此，如果他们也向您发送代理键，则适用相同的规则。
真实世界问题我进入
我使用来自我信任的源系统的代理键遇到的一个问题是源系统在客户端重用代理键。在意义上，后来为了扩展目的而创建了另一个源系统，并且将X个客户端数据推送到该系统中。因此，所有密钥仅针对那些客户端重置。我有两个单独的客户进入统一数据集的冲突代理键（即：数据仓库）......
但是，如果您相信代理密钥仍然存在，您也可以将其留给最佳判断。但是，在它没有变化的那一刻，它将打破ETL过程，你可能会遇到问题。 因此，我的建议（或答案）是始终声明对主键的控制，并为每个维度生成自己的代理键，作为Kimball建议的顺序分配的简单整数。
数据应该流向临时表，应该使用系统生成/管理的代理键填充维度，然后使用典型的UPDATE JOIN方法将其附加回FACT。加入将会发生，并且不要像我们所有人那样烦恼这部分过程。
希望有所帮助