Raw Data Vault中退化键/维度及静态表的处理实践与实现咨询

一、退化键（Degenerate Keys）/维度（Degenerate Dimensions）的最佳实践 #

退化键是本身作为业务标识符，但无对应独立属性集合的字段（比如交易流水号、发票号），处理时遵循以下实践：

• 无属性的退化键直接嵌入Link或Satellite：如果退化键仅用于标识事务或关联实体，没有额外描述属性，无需单独创建Hub，直接将其作为Link的关联字段（用于连接多个Hub），或Satellite的属性存储。Raw Data Vault的核心是保留原始数据结构，不强制为每个业务键建Hub。
• 预留扩展性：如果退化键未来可能新增属性，可先创建仅包含核心键的空Hub，后续通过新增Satellite补充属性，避免后期大规模重构。
• 保留原始痕迹：对于重复出现的退化键，不要在Raw层做去重操作，完整保留其在每个事务中的原始记录，去重和聚合放在后续Business Vault层处理。

二、Xref、Lookup及一次性加载静态表的归类 #

Xref表 #

Xref表用于记录多实体间的关联关系（如产品与类别的多对多映射），应归类为Link。Link的核心作用就是存储业务实体间的关联，若Xref表带有关联属性（如关联生效日期），将这些属性放在对应Link的Satellite中存储。

Lookup表 #

• 静态代码转译类Lookup表（如状态码、性别代码映射）：归类为Reference Table（参考表），这类数据属于静态参考信息，无需跟踪实体变化；若后续有变更需求，可通过添加时间戳或版本号维护历史。
• 对应业务实体的Lookup表（如职位列表、部门列表）：归类为Hub，将职位/部门的业务键存入Hub，属性信息存入对应的Satellite，Lookup表数据作为初始加载源。

一次性加载的静态表 #

• 存储业务实体核心标识的静态表（如国家列表）：归类为Hub，一次性加载后，若有实体属性变更，通过Satellite记录历史版本。
• 纯参考映射类静态表（如货币代码与名称映射）：归类为Reference Table，一次性完成加载即可，无需复杂的历史跟踪。

内容的提问来源于stack exchange，提问作者user25574832