4、主数据模型设计：实体识别、属性定义、关系建模、主数据模型与数据目录的映射

好，咱们进入正题。主数据模型设计，说白了就是回答三个问题：管什么？管哪些信息？信息之间怎么串？ 我做了这么多年数据治理，发现很多项目一开始就栽在模型设计上——要么实体没找全，要么属性定义打架，最后数据目录里一堆垃圾字段。

这一节，我带你一步步把模型搭起来，再把它稳稳地映射到数据目录里。

4.1 实体识别：先搞清楚「谁」是主角

实体识别，就是找出业务中那些独立存在、需要被管理的核心对象。比如客户、产品、供应商、组织、资产。我习惯用一个方法：业务事件倒推法。

你想想看，业务系统里每天在发生什么事件？

• 下了订单 → 涉及「客户」和「产品」
• 采购入库 → 涉及「供应商」和「物料」
• 员工入职 → 涉及「员工」和「组织」

把这些事件里的名词拎出来，去重、合并，就是候选实体。我在项目中遇到过，一个集团客户系统，光「客户」就拆成了「法人客户」「个人客户」「潜在客户」三个实体。后来发现，其实只需要一个「客户」实体，加一个「客户类型」属性就够了。过度拆分，数据目录会变得臃肿不堪。

4.2 属性定义：别让字段变成「垃圾桶」

实体定好了，接下来就是给每个实体加属性。属性定义最容易出问题的地方是：同名不同义、同义不同名。

举个例子，「客户名称」这个属性，在 CRM 系统里叫 cust_name，在 ERP 里叫 customer_full_name，在数据仓库里叫 client_nm。映射到数据目录时，如果不统一，查询结果就会乱套。

我建议，每个属性必须明确以下内容：

嗯，这里要注意：属性定义不要超过 20 个。我曾经见过一个「客户」实体，定义了 80 多个属性，结果一半是冗余的。数据目录里字段太多，查询性能会直线下降。

4.3 关系建模：把「孤岛」连成「网络」

实体之间不是孤立的。客户下了订单，订单关联了产品，产品由供应商提供……这些关系，必须在主数据模型里显式建模。

关系建模有三种常见类型：

• 1:1（一对一）：一个员工对应一个工号。很少见，但存在。
• 1:N（一对多）：一个客户可以有多个订单。最常见。
• M:N（多对多）：一个产品可以由多个供应商提供，一个供应商也可以提供多个产品。需要拆成关联表。

我习惯用一张关系矩阵图来梳理。横轴和纵轴都是实体，交叉点填上关系类型。这样一目了然。

下面这张 SVG 图，展示了主数据模型的核心实体及它们之间的关系：

你看，这张图里，客户、产品、订单、供应商、组织五个实体，通过关系线连成了一个网络。数据目录里，每个关系都要对应一张关联表或外键字段。这样查询时才能跨实体关联。

4.4 主数据模型与数据目录的映射：从「设计图」到「施工图」

模型设计好了，怎么把它落地到数据目录里？说白了，就是把模型里的每个元素，对应到数据目录的元数据对象上。

我总结了一个映射对照表，你直接拿去用：

举个例子，假设「客户」实体有一个属性叫「客户等级」，值域是 [普通、银卡、金卡、钻石]。在数据目录里，你会看到：

-- 数据目录中的字段定义
表名：mdm_customer
字段名：customer_grade
数据类型：VARCHAR(20)
描述：客户等级，枚举值：普通、银卡、金卡、钻石
来源系统：CRM
关联代码表：code_customer_grade

这样，任何人查数据目录，都能一眼看懂这个字段的含义和来源。

4.5 映射过程中的常见坑

最后，分享几个我踩过的坑，你遇到了可以绕开走。

• 坑一：模型和目录「两张皮」。模型团队用 Excel 维护，目录团队用工具维护，两边不同步。结果模型改了，目录没更新，查询结果还是老数据。我的建议：模型变更必须触发目录更新，最好用自动化工具打通。
• 坑二：属性定义太「技术化」。比如字段名叫 cust_lvl_cd，业务人员根本看不懂。数据目录里一定要保留业务名称和业务定义，让非技术人员也能查。
• 坑三：关系映射遗漏。模型里画了关系线，但目录里没建外键或关联表。查询时只能靠人工拼 SQL，效率极低。我曾经在一个项目里，因为漏了「客户-订单」的关系映射，导致数据目录的「客户360视图」功能延迟上线两周。

嗯，模型设计这块，说到底就是把业务语言翻译成数据语言。翻译得好，数据目录就是一把利器；翻译得差，它就是一堆没人看的文档。你想想看，是不是这个道理？