2. 主数据建模与标识体系

主数据同步的成败，往往在建模阶段就已决定。如果实体边界模糊、属性口径不一、标识规则缺失，后续无论用多强的同步工具，都会陷入“同名不同物、同物不同码”的泥潭。本节围绕四件事展开：识别主数据实体、定义属性、设计编码规则、建立全局唯一标识，并最终落到跨系统映射关系的管理上。

一、主数据实体识别：先划清“谁值得被统一管理”

主数据实体是跨系统共享、相对稳定、被多个业务流程引用的核心对象。识别时可用三个判据同时过滤：跨系统引用度（是否被两个以上系统作为外键或业务依据）、变更频率（是否低频变更、一旦变更影响面大）、业务唯一性要求（是否必须全局唯一）。以制造企业为例，客户、供应商、物料、工厂、员工、科目通常满足这三条；而订单、工单、发票属于交易数据，库存余额属于动态数据，一般不纳入主数据实体。

识别结果应形成实体清单，并明确每个实体的权威源系统（System of Record，SoR）。例如客户以 CRM 为权威源，物料以 PLM 或 ERP 为权威源。权威源决定了当多系统数据冲突时以谁为准，这是后续同步方向与冲突消解的前提。

二、属性定义：区分标识属性、业务属性与治理属性

一个主数据实体的属性不宜平铺罗列，而应按用途分层：

• 标识属性：用于唯一区分实例，如物料编码、客户统一社会信用代码。
• 业务属性：描述业务特征，如物料名称、规格、计量单位、客户行业分类。
• 治理属性：支撑数据管理，如创建系统、创建时间、数据状态、版本号、最后修改来源。

每个属性还需定义元数据：数据类型、长度、是否必填、是否可枚举、是否参与同步、变更是否触发下游。以物料为例，“计量单位”应定义为枚举值（如 PCS、KG、M），并规定不允许下游系统自行扩展；“物料组”作为分类属性，需与分类体系绑定。属性定义不清，最常见的后果是同一物料在 ERP 中单位为“个”，在 MES 中为“PCS”，同步后无法换算。

三、编码规则与全局唯一标识：业务主键与 UUID 分工

编码规则解决“人可读、可分类、可校验”，全局唯一标识解决“机器可辨、跨系统不冲突”。两者不是二选一，而是配合使用。

业务主键（Business Key）通常采用分段编码。例如物料编码规则可设计为：大类(2位) + 中类(2位) + 流水号(6位) + 校验位(1位)，如 01020000457。其中校验位可用模 10 或模 11 算法生成，防止手工录入错误。编码规则必须满足：唯一性、稳定性（不因属性变更而改码）、可扩展性（预留号段）、无含义依赖（避免把组织、年份等易变信息编进主键）。

UUID（如 UUID v4 或雪花算法 ID）则作为系统间不可变的全局标识，不承载业务含义，用于跨系统引用、消息传递和映射表主键。推荐做法是：UUID 作为技术主键，业务编码作为业务主键，两者并存。当业务编码因并购、重组需要变更时，UUID 不变，映射关系仍可追溯。

四、跨系统映射关系管理：让“同一实体”在各系统中可追溯

映射关系是主数据同步的“翻译层”。每个下游系统都有自己的本地主键，例如 ERP 中物料号是 M-1001，MES 中是 MAT-88，WMS 中是 W-2024。映射表的核心字段应包括：全局 UUID、系统标识、本地 ID、映射状态、生效时间、失效时间。映射状态建议至少区分“有效、待确认、已失效”三种，避免同步时误用历史映射。

映射关系的建立有三种典型方式：权威源推送（SoR 创建实体后主动注册映射）、下游回写（下游系统创建本地记录后回传本地 ID）、人工匹配（历史数据清洗时按业务编码或名称匹配）。实际项目中，历史数据迁移往往需要人工匹配加规则匹配结合，例如先按“统一社会信用代码”精确匹配客户，再按“名称+地址”模糊匹配剩余记录，最后人工复核。

五、一个可执行的建模检查清单

在进入同步实施前，建议用以下清单逐项确认，避免把建模缺陷带入后续环节：

完成上述设计后，主数据同步才有了可靠的“骨架”：实体知道管什么，属性知道传什么，编码知道怎么读，UUID 知道怎么认，映射表知道怎么找。后续的同步策略、冲突消解与一致性校验，都建立在这套标识体系之上。