3. 银行账户与产品数据概览

在银行数据迁移项目中，迁移团队最先要建立的能力不是写脚本，而是“看懂数据”。账户、产品、客户、合约四类对象构成了银行核心业务数据的主干，它们之间的引用关系决定了迁移顺序、映射规则和校验策略。本节从主数据视角出发，梳理这四类对象的边界、关键字段与模型基础，为后续迁移方案设计打下认知底座。

一、核心原理：四类主数据的定位与边界

银行数据可粗略分为主数据、交易数据与关系数据。主数据描述“谁、什么、怎样约定”，交易数据描述“发生了什么”，关系数据描述“谁与谁关联”。迁移治理中，主数据是迁移的骨架，交易数据是迁移的血肉，关系数据是迁移的关节。

• 客户信息（Customer）：自然人、法人、同业等主体的身份与属性，是账户与合约的归属方。关键字段包括客户号、证件类型与号码、客户类型、风险等级、状态。
• 产品主数据（Product）：银行可售或可持有的产品定义，如活期存款、定期存款、理财、贷款产品。关键字段包括产品码、产品类别、币种、期限、利率规则、计息方式。
• 账户主数据（Account）：客户持有资金或信用的载体，如存款账户、贷款账户、内部账户。关键字段包括账号、账户类型、开户机构、币种、余额、状态。
• 合约关系（Contract）：客户与银行之间就某产品达成的具体约定，如定期存单、贷款合同、理财协议。合约通常关联客户、产品与账户，是三者之间的“粘合剂”。

二、数据模型基础：从实体关系到迁移映射

银行核心系统通常采用关系模型表达上述对象。典型结构为：客户表（CIF）为主表，账户表通过客户号外键关联客户；合约表同时引用客户号与产品码；账户表通过产品码关联产品定义。迁移时，源系统与目标系统的模型差异往往体现在字段粒度、编码体系与关系表达方式上。

例如，源系统可能将“定期存单”同时存放在账户表和合约表中，而目标系统要求合约独立建表并只保留账户引用。此时迁移映射必须明确：哪些字段进入账户，哪些进入合约，哪些需要拆分或合并。

-- 典型迁移映射片段（示意）
源：ACCT_MASTER(acct_no, cust_no, prod_code, balance, status)
目标：ACCOUNT(account_id, customer_id, product_id, balance, status)
目标：CONTRACT(contract_id, customer_id, product_id, account_id, start_date)
映射规则：
  ACCOUNT.account_id   <- ACCT_MASTER.acct_no
  ACCOUNT.customer_id  <- CUST_MAP[ACCT_MASTER.cust_no]
  ACCOUNT.product_id   <- PROD_MAP[ACCT_MASTER.prod_code]
  CONTRACT             <- 由定期/贷款类账户派生

三、方法流程：主数据梳理与迁移准备

1. 对象盘点：列出源系统所有客户、产品、账户、合约表，标注数据量、更新频率与责任人。
2. 字段级剖析：对每张表提取关键字段、码值、空值率与唯一性约束，识别主键与外键。
3. 关系验证：抽样验证客户—账户、账户—产品、合约—账户的引用完整性，统计孤儿记录。
4. 映射设计：建立源字段到目标字段的映射表，明确转换规则、默认值与异常处理策略。
5. 迁移排序：按“客户→产品→合约→账户”或“客户→产品→账户→合约”的顺序迁移，确保外键可解析。

四、案例与场景：一次账户迁移的引用断裂复盘

某银行在迁移定期存款账户时，先将账户表迁入目标系统，再迁合约表。结果发现部分账户在目标系统中“无合约”，导致利息计算失败。复盘发现：源系统中定期存单的合约信息存放在账户表的扩展字段中，迁移团队未将其拆分到目标合约表。修复方案是补充合约派生规则，并在账户迁移后立即执行合约补录，再运行引用完整性校验。

该案例说明：主数据迁移不是“搬表”，而是“重建关系”。账户、产品、客户、合约四类对象在源系统与目标系统中的表达方式可能完全不同，迁移团队必须先在模型层面完成对齐。

五、误区与复盘：主数据迁移的常见陷阱

• 只迁数据不迁关系：账户迁过去了，但客户号、产品码未同步映射，导致账户成为“孤岛”。
• 忽略码值差异：源系统用“01”表示活期，目标系统用“CUR”，未做码值转换则产品识别失败。
• 低估合约派生复杂度：定期、贷款、理财等合约往往由账户属性派生，规则不清晰会导致大量人工补录。
• 校验滞后：迁移完成后才做完整性校验，修复成本远高于迁移前预检。