主控数据的四种方式
另有 28 种语言版本
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
第 2 个模块，共 6 个，属于 Data Architect 课程第 6 章主数据与身份。每个模块都可以单独阅读。 上一篇：每个属性一个可信来源 · 下一篇：匹配、合并与存活规则
**本模块回答的问题：**组织如何主控数据，哪种方式合适？
模块 1 说过，权威是逐个属性分配的。现在的问题是：当这些属性同时存在于好几个系统中时，我们该怎么办？客户信息在 Salesforce、ERP、计费系统、支持系统里，也许还在 Data 360、某个数据仓库里，每个都有自己的版本。这正是**主数据管理（MDM）**试图解决的问题，而 MDM 不是一种架构。你会听到四种模式：**注册式、整合式、共存式和集中式。**它们不是产品设置，而是对同一个问题的四种回答：主控层拥有多大的权威？
从问题开始，而不是从产品开始
Section titled “从问题开始，而不是从产品开始 ”人们一听到 MDM，就开始去选购 MDM 产品。我会从问题开始。我们只是需要知道好几条记录是同一个客户吗？我们需要一个用于分析的合并视图吗？我们需要决定哪些值是权威的，并把它们推回其他系统吗？还是我们希望由一个中心系统为所有人创建主数据？截然不同的需求，截然不同的架构。
注册式：告诉我谁是谁
Section titled “注册式：告诉我谁是谁 ”最轻量的模式。注册式不取代各个来源。ERP 保留它的客户，Salesforce 保留它的客户记录，计费系统保留它的客户，而注册中心弄清楚这些记录代表的是同一个实体：Salesforce 客户 001…、ERP 客户 SAP-43821 和计费客户 BILL-9127 属于同一个客户。来源留在原处，不会被覆盖。现在，“给我看我们关于这个客户知道的一切”就有了答案。
但注意注册式回答不了什么。Salesforce 说是 123 Main Street，ERP 说是 125，计费系统说是“123 Main St., Suite 200”。注册中心知道它们属于同一个客户。它并不决定应该改哪一个。关联不等于主控。
根据我的经验，**在 Salesforce 项目中，注册式是常态，**其次是整合式和共存式；纯粹的集中式 MDM 很少见。注册式之所以常见，是因为它侵入性低。你不需要先重新设计每一个运营系统才能获得价值。Salesforce 继续做它做的事，ERP 继续做它做的事，你只是加了一个身份层。这比告诉每个系统“你不再控制客户数据了，这个新的中心系统来控制”要小得多的变化。
注册式回答的是：哪些记录属于同一个实体？
整合式：把数据汇集到一起
Section titled “整合式：把数据汇集到一起 ”整合式从多个来源获取数据，并把它们合并成一个中心表示，用于报表、分析、细分、客户洞察。数据仓库是大家熟悉的例子：Salesforce 发来客户，ERP 发来财务数据，计费系统发来付款数据，业务方终于可以跨系统分析客户了。来源仍然存在，而且可能仍然是权威的。方向很重要：数据流进整合系统，而整合系统通常不会把主控后的变更推回去。对客户有了更好的了解，但并没有成为它的运营权威。
注册式和整合式很容易混淆。区别在于集中的是什么：注册式集中的是身份（“这些属于一起”）；整合式集中的是更多的数据（“把属性汇集起来，以便我们使用”）。两者都没有说“这个中心系统现在是主控方，每个应用都必须接受它的值”。
整合式把数据汇集到一起，但并不从来源那里拿走所有权。
共存式：做出决定，再把它送回去
Section titled “共存式：做出决定，再把它送回去 ”在共存式中，主控层获得了真正的权威。数据仍然存在于好几个运营系统中，但 MDM 流程决定主控的值，并把它发布回去。Salesforce、ERP 和计费系统各有一个不同的法定名称；MDM 流程确定受治理的那一个，并把它分发给这三个系统。各个系统共存，但它们会收敛到主控的值上。
这是一种强得多的 MDM 形式。它说的不是“这些属于一起”，而是**“对于这个属性，这就是企业使用的值”。**这需要的不只是匹配：业务规则、所有权、存活规则、双向集成、错误处理和治理，因为总得有人决定为什么某个值胜出。
共存式不只是关联记录。它决定主控的值，并把它们送回去。
集中式：由主控方创造真相
Section titled “集中式：由主控方创造真相 ”最强的模式。在集中式 MDM 中，受治理的主数据在中心主控系统中创建和维护，再分发给其他所有系统。不是每个系统各自创建自己的客户、再由 MDM 事后协调，而是在主控系统中创建受治理的客户，再把它发送给 Salesforce、ERP 和计费系统。治理非常强，而变化也非常大：现有的流程会创建它们自己的客户，用户有他们的工作流程，集成假定在本地创建，而各业务部门甚至可能对什么是客户都没有共识。这就是为什么在我看到的 Salesforce 全景中，它很少见。它可能是对的，但这是一个比安装一个工具大得多的决定。
集中式 MDM 把创建和权威都移进了主控系统。
四种方式并排比较
Section titled “四种方式并排比较 ”| 方式 | 集中的是什么 | 来源是否保留？ | 是否把受治理的值推回去？ |
|---|---|---|---|
| 注册式 | 身份和关联 | 是 | 通常否 |
| 整合式 | 身份加合并的数据 | 是 | 通常否 |
| 共存式 | 身份、数据和主控决定 | 是 | 是 |
| 集中式 | 创建和权威 | 是，作为消费者 | 是 |
沿着表格往下，主控层获得的权威越来越多，组织通常也要做更多的改变。
考点。掌握四种 MDM 实施方式：注册式（关联身份；来源保留各自的数据）、整合式（把数据汇集到一起，通常用于分析）、共存式（决定主控的值，并把它们发布回各个来源）和集中式（由主控系统创建数据；来源消费它）。
所以并不存在“集中式最成熟，所以每个人都应该走到那一步”这回事。**选择能解决问题的最轻量的模式。**只需要知道记录属于一起？考虑注册式。需要一个用于分析的合并视图？整合式。需要把受治理的值同步回好几个运营系统？共存式。需要一个流程为所有人创建和控制主数据？集中式。
Data 360 处于什么位置？
Section titled “Data 360 处于什么位置？ ”Data 360 跨许多来源构建统一档案，这听起来很像 MDM，它也确实解决了问题的一部分。它的身份解析把源档案匹配成一个统一身份，并保留指向源记录的关联（Data 360 Architecture (opens in a new tab)，英文）。这让它最接近注册式。它还可以在统一档案上显示协调后的值。但这并不让它成为一个会改写来源的集中式黄金记录系统。**统一视图并不自动等于一条主控的企业记录。**模块 4 讲的全是这个区别。
共同的模型不等于共同的真相
Section titled “共同的模型不等于共同的真相 ”你还会听到规范数据模型（canonical data model）。Salesforce 的客户、ERP 的业务伙伴和计费系统的客户都映射到一个达成一致的企业概念，即 Customer，带有一致的标识符和属性，这样每个集成就不必去理解其他每个系统的结构。Data 360 的数据模型就是把多个来源协调成共同概念的一个例子。但规范模型回答的是**我们如何一致地表示它？MDM 回答的是我们如何跨系统识别、治理和主控它？**把三个系统完美地映射到同一个 Customer 结构中，Salesforce 仍然说 123 Main Street，而 ERP 说 125。你解决的是结构，而不是权威。协调和主控不能互换。
一个业务，好几种模式
Section titled “一个业务，好几种模式 ”所以“Steve Trucking 需要 MDM”不是一项需求。为了什么？零售合作伙伴、配送中心、配送小组、卡车、收货人是不同的领域，有不同的权威：零售合作伙伴在 Salesforce 和财务 ERP 中受治理，卡车身份来自 FleetLink，每位收货人都是由某个合作伙伴为每次配送提供的。不同的领域可以采用不同的模式，而在一个领域内，不同的属性也可以有不同的权威。所以不要在图的中间画一个标着 MDM 的方框，就说问题解决了。要问这个方框做什么。
方式也会改变集成。注册式需要身份关联；整合式需要可靠的入站数据流；共存式需要双向的数据；集中式需要从主控系统分发，再加上阻止其他系统制造竞争性真相的控制措施。随着权威的增加，协调也随之增加，故障处理也一样：如果 MDM 修改了法定名称而 ERP 拒绝了它，会怎样？这就是为什么共存式和集中式不是“功能更多的注册式”。它们承担的是不同的运营职责。
MDM 是一个业务决定
Section titled “MDM 是一个业务决定 ”最重要的一点：MDM 从根本上不是一个技术决定，而是一个关于权威的决定。谁创建客户，谁可以修改它，谁决定哪个值胜出，哪些系统必须接受它，它们不一致时怎么办。工具可以实现这些决定；但它无法让组织在这些决定上达成一致。这就是为什么一个 MDM 项目可以拥有出色的技术，却仍然失败：技术团队解决了匹配，而业务方从来没有解决所有权。
我吃过亏才学到的一般教训是：当好几个系统主控同一份数据时，它们自己都没有达成一致的东西，Salesforce 是协调不了的。当一家公司运行两套 ERP 时，我会问他们如何让两者保持同步。如果他们做不到，Salesforce 也做不到。模块 5 讲了这个故事（一个客户，两套 ERP）。
架构师在这里决定什么
Section titled “架构师在这里决定什么 ”- 问题需要的是身份关联、合并的数据、推回去的主控值，还是集中创建。
- 哪种模式适合每一个数据领域，而不是整个企业只用一种模式。
- 主控层获得多大的权威，以及哪些系统必须接受它的决定。
- 是否需要一个规范模型，同时不把协调和权威混为一谈。
- 所选的模式如何改变集成的方向、所有权和故障处理。
当有人在图上放一个 MDM 方框时，问它做什么。它知道哪些记录属于一起吗？它合并它们的数据吗？它决定哪些值胜出吗？它把这些决定推回去吗？它从一开始就创建数据吗？这些答案告诉你，你真正拥有的是哪种架构，以及权威在哪里。
- Salesforce Architects，Data 360 Architecture (opens in a new tab)（英文），查阅日期 2026-10-14。