参考数据和主数据

参考数据和主数据都是需要跨业务领域、跨流程、跨系统共享的数据。它们为交易数据提供上下文：没有统一的客户标识，就无法确定「所有客户」的范围；没有统一的代码，报表之间就无法对账。主数据管理最常见的驱动因素是统一数据需求、管理质量、降低集成成本和降低风险。

• 参考数据：代码表与描述表，用于分类其他数据或连接外部信息
• 企业结构数据：如会计科目表，按业务职责描述活动
• 交易结构数据：如客户标识符，描述交易中必须出现的对象
• 主数据通常被视为参考数据、企业结构数据与交易结构数据的聚合
• 主数据挑战的核心是实体解析：同一现实对象在不同系统中有不同表示

参考数据可以是简单代码表，也可以包含映射、层次结构和多语言描述。它存在于几乎每个数据存储中，来源可能是行业标准机构、监管要求、供应商，也可能是组织内部维护。

• 三种常见结构：列表（代码 + 描述）、交叉引用（源值到目标值）、分类（层次或面）
• 代码值要平衡标准遵从性与实用性，如英国国家代码用 GB 而非 UK
• 定义是参考数据的核心元数据：仅靠标签无法说明代码在具体语境中的含义
• 要明确每个参考数据集的维护者、来源、更新频率、历史版本是否保留
• 参考数据变更要沟通、审批、可追溯；驱动逻辑的代码变更前要评估影响

实体解析（Entity Resolution）是判断两条记录是否指向同一现实对象的过程，包括匹配、合并与标识符管理。匹配可用确定性规则（模式、权重、可预测）或或然式算法（基于训练数据与统计相似度，可随数据优化）。

• 全局标识符应只由一个授权方案生成，避免重复值
• 交叉引用管理（X-Ref）维护源 ID 与全局 ID 的映射历史，支持反合并与再合并
• 匹配决策可能出错，必须保留匹配历史，以便撤销
• 匹配率指标用于监测匹配规则的影响与有效性
• 主数据项目通常一次只做一个主题域、少量属性，再逐步扩展

主数据架构要匹配组织规模、系统数量、治理成熟度与对延迟的要求。三种基础模式各有取舍，很多组织会采用混合方案。

1. 01识别驱动因素与需求：明确业务收益、障碍与优先级，通常从一个主题域开始
2. 02评估数据源：理解结构、内容、采集过程、属性语义与质量，找出差异根因
3. 03定义架构方法：根据系统数量、治理成熟度、延迟要求选择注册表/交易中心/混合
4. 04建模主数据：在主题域内建立逻辑或规范模型，形成企业级定义
5. 05定义职责与维护流程：匹配、合并、修复、反馈源系统、调优算法
6. 06建立治理制度并推动使用：路线图、系统接入、闭环反馈、共享协议

主数据项目失败最常见的原因不是技术，而是缺乏治理：没有人对定义、匹配规则、冲突裁决和质量负责。治理要决定整合哪些源、执行哪些质量规则、如何监控、优先级如何、信息如何呈现。

• 主数据所有权属于组织，不属于某个应用或部门
• 主数据值应只从记录系统复制；跨组织共享可能需要参考数据管理系统
• 任何合并或拆分都必须可追溯，匹配规则变更要在监督下谨慎进行
• 治理要有接收新规则、修订旧规则的能力，而不是一次定死