主数据与身份
另有 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)
Data Architect 课程第 6 章的学习指南。请先阅读六个模块，包括检查点 1 的讲解；这一页帮你检查自己记住了什么。
**关于本学习指南。**它只依据本课程自己的内容，以及 Salesforce 公开发布的考试指南中的目标清单编写。它从不基于真实的考试题目，也不声称知道考试会考什么。如果你参加过考试，请不要把考题发给我：认证协议禁止分享考题，而且死记答案本来就不是成为架构师的正确方式。
本章承载了考试的“主数据管理”部分（5%），以及“Salesforce 数据管理”中关于客户单一视图的内容。按权重它是一个小部分，但它的思想（权威、匹配、存活规则）会出现在许多其他情景中。平台的数字会变，所以在依赖它们之前先查看当前的数字。
边学边打勾。每一条都链接到讲授它的地方。
MDM-2：黄金记录与真相系统
- 我知道权威是按属性分配的，而不是按记录：一个客户可以有在 ERP 中主控的字段，也有在 Salesforce 中主控的字段。（真相属于某个属性）
- 我会问每个属性在哪里创建、编辑和引用，以及它的变化延迟。（在哪里创建、编辑、引用，变化多快？）
- 我能建立一张权威系统图，也知道业务所有者和权威系统不是一回事。（建立一张权威系统图）
- 我知道权威可能在生命周期中变化（Salesforce 中的一个潜在客户变成受 ERP 治理的客户），也知道副本不是权威。（权威会在生命周期中变化，副本不是权威）
MDM-1：MDM 技术
- **考点：**我了解四种 MDM 实施方式：注册式、整合式、共存式和集中式，知道每一种集中的是什么，以及它是否把值推回去。（四种方式并排比较）
- 我能区分四种 MDM 方式：注册式、整合式、共存式和集中式，并选择能解决问题的最轻量的那一种。（四种方式并排比较）
- 我知道规范数据模型协调的是结构，但它不决定权威。（共同的模型不等于共同的真相）
- 我知道顺序是：先协调，再匹配，然后整合。（先协调，再匹配，然后整合）
- 我知道阈值反映的是对错误的容忍度，而数据丰富需要来源信息。（阈值、审核与数据丰富）
- 考点：我了解层级管理：上级客户构建层级（Lightning 视图最多显示 2,000 个客户，不包括个人客户），层级往往是分头主控的，一家公司可以有好几个合理的层级。（层级也是主数据，一个层级，好几个主控方）
MDM-3：选择胜出的属性
- 我能把匹配、合并和存活规则分开。（匹配、合并与存活规则）
- 我了解存活规则：最新、最常见、来源优先级，也知道每一条规则都需要一个所有者。（存活规则：哪个值胜出？）
- 我知道匹配不要求合并，我只在有明确的胜出者时才合并，并先决定子记录怎么办。（匹配不要求合并，我的合并规则：有明确的胜出者）
- **考点：**我知道 Salesforce 客户合并做了什么：最多三条记录，一条主记录，保留最早的创建人和创建日期，其他记录进入回收站，而个人客户的联系点对象不会被合并。（Salesforce 合并实际上做了什么）
SDM-3：客户单一视图
- 我知道 Data 360 身份解析把源档案关联成一个统一档案并保留指回的关联：最接近注册式。（身份解析回答“是谁？”）
- 考点：我了解 Data 360 的匹配规则：一条规则中的所有条件都必须匹配，任意一条规则都可以匹配；条件多一些是为了准确，少一些是为了整合。（匹配规则：严格程度是一个风险决定）
- 我了解匹配方法（Exact、Exact Normalized，以及三种精度的 Fuzzy）：精度较低的方法会提高整合率，也会提高错误匹配的风险。（匹配规则：严格程度是一个风险决定）
- 考点：我知道协调规则（Last Updated、Most Frequent、Source Priority）决定统一档案显示什么，但不修改来源；联系点不会被协调。（协调仍然不等于主控）
- 我能为一项工作在重复管理、身份解析和专门的 MDM 平台之间做出选择。（三种工具，三份工作）
MDM-4 与双向数据
- 我知道双向数据不意味着两个主控方：在 Salesforce 中编辑一个 ERP 拥有的字段是一个请求，所以要设计请求 → 验证 → 接受 → 发布，并带有一个待处理状态。（双向数据不意味着两个主控方，当主控方说不）
- 我知道如何避免循环与冲突：把发起的变更和它的回声区分开，并决定哪些字段要作为一个事务一起传递。（循环与冲突）
- 对于两套 ERP 中的同一个客户，我能根据客户让其各套 ERP 保持同步的能力，在层级、平级客户，或一个客户、每套 ERP 一个子记录之间做出选择。（一个客户，两套 ERP，问他们如何让各套 ERP 保持同步）
检查点 1：把第 1 部分串起来
- 考点：我知道哪些外部许可支持标准共享：Customer Community Plus 和 Partner Community，它们需要为外部用户设置角色；Customer Community 使用共享集。（谁看到什么，谁需要许可）
考试是底线，不是天花板。下面这些是本章中架构师需要的习惯，不管有没有考题问到它们。
- **“唯一真相来源”：哪个真相？**它是一套关于真相的架构，而不是一条记录。
- **让权威在结构中看得见：**给另一个系统拥有的字段加一个前缀。
- **信任需要的不只是一个值：**来源、上次确认时间、谁修改过它。
- **从问题开始，而不是从 MDM 产品开始。**MDM 是一个关于权威的业务决定。
- 关联不等于主控。
- 在错误匹配代价高昂的地方，有意少匹配。
- 当你可能需要回溯时，保留来自外部加载的重复记录。
- 统一档案是一张地图。黄金记录是一个决定。
- 展示不等于权威。
- 统一身份并不会抹掉安全边界。
- **最难的是双向同步。**共享的权威不是问题；模糊的权威才是。
- 永远不要让一个被拒绝的请求变成相互竞争的真相。
- 用一个说明“这是主数据”的字段来驱动可编辑性，而不是用记录类型。
- 我们控制不了 ERP。我们能控制的是如何在 Salesforce 中表示它们。
| 术语 | 一句话解释 |
|---|---|
| 主数据管理（MDM） | 在各个系统之间建立并治理关键数据的权威身份和权威值 |
| 权威系统图 | 对每个属性：谁创建它，谁拥有决定权，哪个系统是权威的，谁可以修改它 |
| 黄金记录 | 一个关于哪些值是权威的、受治理的决定 |
| 混合式黄金记录 | 一条记录中，有些属性在别处主控并被复制进来，有些属性归本地所有 |
| 注册式 | 把记录关联为同一个实体、但不修改来源的 MDM |
| 整合式 | 在中心合并数据、通常用于分析、不回推的 MDM |
| 共存式 | 决定主控的值并把它发布回各个来源的 MDM |
| 集中式 MDM | 受治理的数据在主控系统中创建并分发出去的 MDM |
| 规范数据模型 | 一个概念在企业中达成一致的结构，用来把各个系统相互映射 |
| 协调 | 让值变得可以比较：标准格式、代码和缩写 |
| 匹配 | 判断记录是否代表同一样东西 |
| 存活规则 | 来源之间不一致时决定哪个值胜出的规则 |
| 主记录（principal） | 在 Salesforce 合并中，存活下来并保留其隐藏字段和只读字段的那条记录 |
| 匹配方法 | Data 360 的匹配条件如何比较值：exact、exact normalized 或 fuzzy |
| 身份解析 | Data 360 把源档案匹配成统一档案 |
| 统一档案 | 把代表同一个人或同一家公司的源记录关联起来的一组键 |
| 协调规则 | Data 360 中决定统一档案显示哪个值的规则 |
| 分头主控的层级 | 各个分支由不同系统拥有的层级 |
按课程风格编写的简短情景题。打开答案之前，先想好你的答案。
1. “Salesforce 是我们关于客户的唯一真相来源。”你会问什么？
哪个真相？权威是按属性分配的：ERP 可能拥有法定名称、账单地址和信用额度，而 Salesforce 拥有客户经理和成功等级。建立一张权威系统图。重读真相属于某个属性。
2. 服务人员需要看出一个 Salesforce 联系人就是在网上购物的那个人。没人需要各个系统做出改变。用哪种 MDM 方式？
注册式：把记录关联为一个身份，而不修改来源，这正是 Data 360 身份解析做的事。选择能解决问题的最轻量的模式。重读注册式：告诉我谁是谁。
3. 存活规则对每个字段都设为“最新的胜出”。有人修改了 Salesforce 中 ERP 拥有的法定名称的副本。会发生什么，错在哪里？
最新的值胜出，副本压过了权威。“最新”是一个关于信任的声明，它适合某些属性（手机号码），不适合另一些。在权威系统图说明 ERP 拥有这个字段的地方，ERP 胜出。重读存活规则：哪个值胜出？。
4. 导入的遗留客户记录与已有的客户匹配上了。要合并吗？
要谨慎。匹配不要求合并，而合并会毁掉你可能需要回溯的遗留 ID 和较旧的值。把它们关联起来，除非有明确的胜出者，而且重复记录里没有任何你需要的东西。重读我的合并规则：有明确的胜出者。
5. Data 360 中的统一档案显示达拉斯。团队说达拉斯现在就是每个系统的黄金值。是这样吗？
不是。协调决定的是统一档案显示什么；它不修改来源，也不做主控决定。如果每个系统都必须使用一个受治理的值，那就是共存式或集中式 MDM，并且要有一个所有者。重读协调仍然不等于主控。
6. 匹配医疗记录和匹配营销记录：用同样的规则吗？
不。营销中的一次错误匹配会发出错误的优惠；在医疗数据中，它会把两个人的病史合并在一起。按出错的代价来设定严格程度，在混合代价高昂的地方少匹配。重读出错的代价。
7. 销售代表想在 Salesforce 中更新一个由 ERP 拥有的账单地址。你怎么设计？
作为一个请求，而不是一次编辑：Salesforce 发送提议的值，ERP 验证并接受它，再把权威的值发布回来。在此之前保持一个待处理状态，并处理拒绝、冲突和回声。重读双向数据不意味着两个主控方。
8. 在 Steve Trucking，同一个 John Smith 出现在两个零售合作伙伴的装货清单中。要统一他吗？
不，有意不统一。每个合作伙伴都绝不能看到另一个合作伙伴的收货人，而一个统一的身份就是那座会泄露信息的桥。在混合代价高昂的地方少匹配；如果某个合作伙伴想识别重复的收货人，就只把范围限定在那个合作伙伴之内。重读我会跨合作伙伴统一收货人吗？。
9. 一位销售代表为一个 ERP 拥有的地址发送了一个新的街道，而就在同一分钟，ERP 里有人修改了城市。你怎么决定？
地址是否作为一个事务传递。如果是，这些字段要么一起通过，要么都不通过，而这个请求会因为地址在此期间被修改而被拒绝。在第一次冲突之前就做出这个决定，并记住这个请求是在请求修改 ERP 的值，而不是直接修改它。重读循环与冲突。
10. 一个客户在两套 ERP 中各有一条记录，而没有人让这两条记录保持同步。销售希望只有一个客户。你会建议什么？
不要只用一个客户。如果他们在自己的 ERP 中都无法让这些记录保持同步，Salesforce 也无法替他们做到：把它们表示为平级客户或层级，并展示销售已经熟悉的结构。一个客户、每套 ERP 一个子记录，需要客户能够让共享的值保持同步。重读问他们如何让各套 ERP 保持同步。
- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab)，Salesforce Help（英文，查阅日期 2026-09-25）：官方的考试目标清单及其权重。预约考试前，务必查看最新版本。
- 每个模块自己的“延伸探索”部分列出了其事实所依据的 Salesforce 文档，并注明了查阅日期。