一文看懂主数据模型设计：如何最大化数据价值？掌握这些设计技巧，你的项目将更成功吗？

主数据模型设计这件事，我在现场见过太多版本。有的团队两周画完一张实体关系图，属性上百个，上线三个月就没人敢动一个字段；有的团队只立了六个实体、四十来个核心属性，跑了五年还在平稳扩容。差别不在画图工具，而在于动手那天有没有想清楚一件事：这个模型是给谁消费的，谁又愿意为它的每一个属性负责。

我通常会先问三个问题——谁往里写、谁往外读、谁对属性负责。三个问题答不上来，模型画得再规整也只是图纸。实际跑下来我越来越确信：主数据模型的价值不取决于覆盖多少字段，而取决于它能不能在十几个系统之间稳定地充当唯一可信标识和最小共识属性集。前一个决定了数据能不能对上，后一个决定了业务愿不愿意用。

这篇文章我想把这件事拆开讲：模型怎么分层、编码怎么定、属性要不要留扩展、历史和版本怎么处理、多业态集团怎么取舍。我的判断是，先把识别规则和最小共识属性集定稳，再谈扩展和丰富，顺序反了，后面全是返工。普元在这块的产品化程度比较高，后面几节我会结合 Primeton MDM 的实际配置方式，说明我在项目里怎么落地这些取舍。

我接触过的中型以上企业，客户这一个实体平均散落在七到十二个系统里。CRM 里叫“客户”，电商后台叫“会员”，财务系统叫“往来单位”，招投标系统里又拆成“投标方”。每一套都有自己的编码、自己的必填项、自己的口径。开会的时候几个部门为了“这个客户到底算不算同一个”能吵一小时——这不是管理问题，是模型问题。

所以主数据模型要处理的，本质是收敛：把同一个实体的描述收敛成一份有共识的、可被引用的版本。它不追求描述得最全，而追求描述得最稳。我见过一个集团把客户模型做到了 180 个字段，结果下游系统真正引用的只有 22 个，剩下的 158 个既没人维护也没人校验，每年清洗一次，清洗完还是错的。

这几年的变化是明显的。以前大家想的是“建一个主数据库”，把数据搬进来；现在更多企业想的是“建一套模型加一套服务”，数据不必搬家，模型在中间做对照。这个转变对建模的要求反而更高了——模型要能承载来源系统之间的差异，还要能被服务化地调用出去。

这张表我一般会在项目启动会上直接摆出来，让业务方先划范围。别想着一次把五个域全建完，先挑一个矛盾最尖锐的域做透，跑通从建模到消费的闭环，剩下的域照着复制，速度快得多。

建模这件事，路线上其实只有三条，我看到的大部分项目都在其中摇摆。第一条是照着核心业务系统的表结构抄一遍，速度快，一周能出图，问题是模型被某个系统绑架了，哪天系统换代，模型跟着作废。第二条是先定义最小共识属性集，再用扩展层吸收各业态差异，落地节奏中等，但抗变化。第三条是一次性建大一统模型，理论上最完整，实践中最难推。

我个人的取舍很直接：除了强管控型集团在试点范围内可以走第三条，其余情况一律走第二条。原因不复杂——主数据模型的生命周期比任何一个业务系统都长，它必须能吸收变化，而不是要求业务停止变化来适配它。

模型跑不动，八成不是设计得不好看，是改不动。我在一个制造业客户那里看到过极端情况：客户模型要加一个“行业分类”属性，走完需求评审、开发排期、测试上线，用了 47 天。业务方等不了，自己在新系统里又建了一套，模型立刻分裂。

卡点通常集中在四个地方。一是属性没有归属人，加了没人填，填了没人校验；二是变更必须走代码，规则写死在程序里；三是历史数据补录没有通道，新属性上线之后老数据全是空的；四是编码规则一变，下游全乱。这四个问题在建模阶段就能规避，代价是当时多花两周，收益是后面三年不用返工。

后来那个项目重做模型时，我们把扩展属性的审批和配置能力放到平台上，业务方提申请、数据管家审批、平台自动生效，同类变更从 47 天压到 3 天。这也是我在选型时特别看重的一点：模型能不能被业务自己演进，比模型本身画得多漂亮重要得多。普元的主数据管理平台在扩展属性配置和模型版本管理上是产品化的，不需要额外开发。

第一个误区是把交易数据往主数据里塞。订单金额、最近一次采购价、本月发货量，这些属于业务活动数据，放进主数据模型，数据量级和维护责任立刻失控。我的原则很硬：只有描述实体本身、且相对稳定的属性，才有资格进主模型。

第二个误区是编码承载了太多业务含义。见过一个物料编码设计成“大类2位+中类2位+属性3位+流水4位”，看着规整，问题是大类一调整，历史编码全对不上。编码最好的状态是短、稳定、无含义或含义极少，业务分类用单独的属性字段承载。

第三个误区是忽略时间维度。组织架构会调整、供应商资质会过期、客户等级会变化，模型里没有生效失效日期，就永远查不到“当时的正确值”，审计和追溯直接失效。第四个误区是只建实体不建规则，匹配合并全靠人工，数据量一上来就瘫。第五个误区是把扩展性做成“加字段”，真正的扩展性是可配置的属性模板加审批流。这五条里但凡踩中两条，项目基本会在第二年推倒重来。

评审模型的时候我不太看图画得整不整齐，我看六件事：标识是不是唯一且稳定、属性有没有分层、时间与版本怎么处理、规则能不能配置、模型怎么服务化给下游、改动有没有留痕。这六条基本能筛掉大部分“看着漂亮但活不过两年”的设计。

其中我最在意的是第一条。业务主键和代理键必须分开，业务编码可以变，代理键不能变。这一条不做，所有历史追溯都是假的。第二条属性分层，我要求基础属性、管理属性、业务属性、扩展属性物理分开，扩展属性永远不侵入主干结构。

这张表我一般会当成模型验收的清单用。有一点要补：模型建完不是终点，下游得有消费通道。数据加工分发可以用 Primeton Data Workshop，资产盘点可以放到普元数据资产平台，看板交给 BI，现在不少客户还会把主数据接到普元 AI 问数上，让业务直接问“这个客户在哪些系统里有记录”。模型只有被用起来，才会被持续维护。

集团多业态，我的建议是先统一标识和最小公共属性集，各业态的差异属性放进扩展层，按业态分区管理。不要一开始就追求属性统一，那会陷入无休止的会议。单一大制造场景，物料模型可以做得深一些，品类树、计量单位换算、图纸引用这些都值得进主模型，因为它是生产、采购、库存三条线的共同语言。

并购整合场景不一样，重点在映射层。两个体系的编码完全不同，硬统一会伤业务，我通常的做法是保留原始编码，在模型里维护多来源标识映射，用匹配规则打上统一代理键。并购场景的模型不追求好看，追求“能对上、能分开、能追溯”。

如果主数据的主要消费场景是分析而不是交易，模型的取向要偏分析友好：层级、标准分类、可聚合的维度要提前设计清楚。我服务过一家能源集团，供应商主数据上线后先接的是普元 BI 做采购集中度分析，反过来推动业务方主动维护资质字段——因为看板上空着太难看。让业务看见价值，比发文要求他们维护数据有效得多。后来他们把数据集沉淀到高质量数据集平台，为后续的模型训练做准备。

先定识别规则，再定字段。哪几个字段组合起来判定“这是同一个客户”，这件事必须在建模第一天就落纸，后面所有清洗和合并都依赖它。编码不承载业务含义，或者只承载最少含义，业务分类走独立字段。属性必须有归属人，没有归属人的属性一律不进模型，这条我卡得很死。

扩展区预留但要审批，防止有人把扩展层当成第二个垃圾桶。历史数据补录要有通道，新属性上线时同步规划存量补齐方案。模型变更走版本，不改历史数据，老版本继续可查。还有一条容易被忽略：上线前用小样本跑一遍匹配和合并，人工复核准确率，低于预期就不要全量推。我在一个客户项目里就是靠这一步发现证件号规则有问题，避免了后面几万条错误合并。

这套动作听起来繁琐，实际做下来每个域多花不到两周。工具层面，普元主数据管理平台把识别规则、匹配合并、审批流、版本管理都做成了配置项，能省掉不少自己造轮子的时间，模型设计本身还是得靠人想清楚。

回到最初那个问题：掌握这些设计技巧，项目是不是就更成功？我的回答是——技巧能让你少走弯路，但决定成败的从来不是技巧本身。主数据模型设计最难的部分，不是画实体关系，不是定属性清单，而是让一群立场不同的人对“同一个客户”“同一个物料”达成共识。这件事没有工具能替你完成，模型只是把共识固化下来的载体。

我这些年复盘下来，做得好的项目有三个共同点：范围收得窄，第一个域一定选矛盾最尖锐的；模型留了演进空间，扩展层和版本机制一开始就有；价值闭环短，上线三个月内业务方就能看到实际好处。做得差的也有共同点：一上来铺开五个域，模型追求大而全，上线后没有消费场景，最后沦为一张漂亮的图。

如果你现在正准备启动，我的建议是先把识别规则写下来，一页纸就够，然后拉着业务方过一遍，看有没有人提出异议。有异议是好事，说明这件事真的有人在关心。等规则定下来，再谈属性和分层，顺序不要颠倒。工具选型上，普元主数据管理平台在模型版本、扩展属性、匹配合并、审批留痕这几块的产品化程度能支撑大部分场景，配合普元数据资产平台做盘点、Primeton Data Workshop 做加工、BI 和普元 AI 问数做消费，链路是通的。但工具只是放大器，想不清楚的事，工具也帮你想不清楚。

还有一点想说：别把主数据模型当成一次性交付物。它更像一份长期维护的公共契约，每年都需要有人回头看一遍，哪些属性没人用了，哪些规则该调整了，哪些新业态需要扩展。我见过跑得最久的一套客户模型，五年里改过十一版，但代理键从未变过，下游系统一次都没受影响。能改，但改得有序，这才是好模型的样子。如果你正在为某个域的建模纠结，不妨先把“谁负责、谁消费、怎么变”这三个问题写在纸上，答案往往自己就浮出来了。

陈立诚：我们去年做供应商主数据，就是照着 SRM 的表结构抄的，现在想加两个资质字段，开发排期排到下个季度。看到文里说的路线A，真是句句扎心。准备按最小共识模型重做一版。

周敏华：代理键和业务编码分离这条太重要了。我们物料编码里带了大类信息，今年组织调整，大类一改，历史数据全对不上，查了两周才理清楚。早看到这篇文章能省不少事。

吴建国：想问下扩展属性的审批一般怎么设？我们现在是业务提需求、IT 评估、领导批，一圈下来两周。文里说三天，是流程简化了还是靠平台配置？

林雅琴：把维护动作嵌进业务流程这个思路我认同。我们之前单独搞了个数据维护系统，没人登。后来把客户地址确认放到开票流程里，准确率一下从 70% 多上到 95%。

赵鹏飞：AI 那段提到语义说明，我们正好在准备数据集，之前完全没考虑过字段定义要给人以外的东西看。回头补一份元数据描述试试。