DV2.0中支付1:1转账、转账1:多尝试的Data Vault建模方法

你当前搭建的初步模型参考如下：

首先明确DV 2.0的核心建模底线：原始数据层（Raw Data Vault）只做数据保真落地，不硬编码任何业务规则约束，所有基数、映射类业务规则统一在业务数据层（Business Vault）或数据集市层实现，针对你提到的支付-转账1:1、转账-转账尝试1:N的流程触发场景，合规建模结构如下：

• 拆分3个独立事件类Hub，承载三个核心业务对象的唯一标识
  • HUB_PAYMENT：主键为支付全局唯一业务键（如payment_id），仅存储支付事件的业务键、数据加载时间、记录源信息，不存任何属性或关系
  • HUB_TRANSFER：主键为转账全局唯一业务键（如transfer_id），仅存储转账事件的业务键、数据加载时间、记录源信息
  • HUB_TRANSFER_ATTEMPT：主键为转账尝试全局唯一业务键（如attempt_id），仅存储每次转账尝试的业务键、数据加载时间、记录源信息

  注意：哪怕当前业务规则明确支付和转账是1:1关系，也绝对不能将两个业务键合并到同一个Hub。业务规则存在调整可能，Raw DV层必须保留所有独立业务事件的粒度，才能支撑后续规则变更的可追溯，不需要重构底层模型。

• 构建2个无基数约束的Link，承载事件间的触发关联关系
  • LNK_PAYMENT_TRANSFER：同时关联HUB_PAYMENT和HUB_TRANSFER的主键，存储两类事件的关联映射、加载时间、记录源。不要在该表加唯一约束强制1:1关系，如果需要落地1:1的业务校验规则，可以在Business Vault层基于该Link构建校验视图，或者给Link挂载Satellite存储关系校验结果即可。
  • LNK_TRANSFER_ATTEMPT：同时关联HUB_TRANSFER和HUB_TRANSFER_ATTEMPT的主键，天然支持1:N的映射关系——同一个transfer_id可关联多条不同attempt_id的记录，完全匹配单条转账对应多次尝试的业务场景。
• 按需挂载Satellite存储所有描述属性
  • 每个Hub挂载独立的Satellite表，存储对应事件的属性信息：比如支付的金额、渠道、状态；转账的转出账户、转入账户、转账金额；转账尝试的请求时间、接口返回码、失败原因等，所有属性按变更频率拆分不同Satellite即可。
  • 如果Link本身存在属性（比如支付触发转账的触发时间、关联关系的失效标记），单独给Link挂载Satellite存储，不要把Link属性放到Hub的Satellite里。

常见建模误区规避 #

如果你的初步模型存在以下设计，属于不符合DV2.0规范的情况，需要调整：

• 将支付和转账合并为同一个Hub：会丢失两个独立业务事件的粒度，后续如果业务调整为1个支付对应多笔转账（比如组合支付拆分转账），底层模型需要完全重构
• 将转账尝试作为转账Hub的Satellite存储：Satellite仅能存储所属父对象的描述属性，不能承载拥有独立业务键的业务事件，否则会丢失转账尝试的独立生命周期追溯能力，后续如果需要给转账尝试关联风控记录、渠道回调记录等对象时无法扩展
• 在Link层加外键或者唯一索引强制1:1/1:N的基数约束：违反Raw DV层数据保真的原则，一旦上游源系统出现脏数据（比如重复的支付-转账关联记录），会直接导致数据加载失败，无法保留原始数据全貌。

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