每个属性一个可信来源
另有 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)
第 1 个模块，共 6 个，属于 Data Architect 课程第 6 章主数据与身份。每个模块都可以单独阅读。 下一篇：主控数据的四种方式
本模块回答的问题：“唯一真相来源”到底是什么意思？
有一句话我经常听到：**“我们需要一个唯一的真相来源。”**好的。关于什么的？客户？这还不够具体。拿一个客户来说。谁拥有客户的名称、账单地址、信用额度、客户经理、支持等级、营销偏好？这些答案并不指向同一个系统。ERP 可能控制法定名称、账单地址和信用状态；Salesforce 控制关系负责人和销售属性；另一个平台控制同意。所以当有人告诉我“Salesforce 是我们关于客户的唯一真相来源”时，我接下来的问题是：哪个真相？
真相属于某个属性
Section titled “真相属于某个属性 ”主数据的第一条原则是：**权威是按属性分配的，而不是按记录。**一个客户可以存在于 Salesforce 中，而 Salesforce 并不对它的每个字段都是权威的。一条记录上的七个字段，两个权威来源：
| 属性 | 权威系统 |
|---|---|
| 法定名称、账单地址、ERP 客户 ID、信用额度 | ERP |
| 客户经理、战略客户标志、成功等级 | Salesforce |
一条记录；真相是分散的。这很正常。“记录系统 = Salesforce”描述不了它。一个权威模型才能。
在哪里创建、编辑、引用，变化多快？
Section titled “在哪里创建、编辑、引用，变化多快？ ”我讲授主数据时，对每一份重要的数据都会一再回到同样的问题：**它在哪里创建，在哪里编辑，在哪里被引用，它的变化延迟是多少？**这些问题能很快暴露出架构。（前三个问题你在第 4 章给数据种类分类时已经见过；在这里，它们才真正发挥作用。）
拿一项资产来说。一位客户订购了三辆自行车。Salesforce 中有业务机会及其行项目，订单被发送到 ERP。ERP 完成履约，资产也正是在那里被创建的：三辆自行车，三个序列号，再发回 Salesforce。几个月后，客户就其中一辆打来电话，支持人员在个案中引用了这项资产。现在有人需要更正一个属性。哪些属性 Salesforce 可以编辑，哪些属于创建它们的 ERP？当 ERP 修改其中一个时，Salesforce 需要多快知道？一项资产，四个问题，而且每个字段的答案并不相同。
假设法定名称在 ERP 中创建、在 Salesforce 中被引用，而一位销售代表发现它错了。他们应该在 Salesforce 里修正它吗？如果 ERP 拥有这个字段，修改副本什么也修正不了。最好的情况是下一次同步把它覆盖掉；最坏的情况是两个系统从此不一致，没人知道该信哪个。如果业务方希望销售代表发起更正，那就不同了：Salesforce 提供体验，向 ERP 发送一个请求，ERP 进行或批准这次修改，然后权威的值再回来。这和让 Salesforce 自行编辑这个字段是截然不同的架构。
延迟也是真相的一部分。ERP 在上午 10 点修改了一个客户的信用状态；Salesforce 每晚同步一次；下午 3 点，一位销售代表看了 Salesforce。这个值是错的吗？它是过时的。如果这个值一年才变一次，延迟一天没有任何代价，每晚同步就没问题。如果它决定了你今天是否接受一笔百万美元的订单，那就不行。权威说的是真相从哪里来；延迟说的是**其他系统必须多快得知它变了。**这是两个独立的决定。
记录系统、互动系统、参考系统
Section titled “记录系统、互动系统、参考系统 ”第 4 章的词汇在这里很有帮助。记录系统维护权威版本。互动系统是人们使用它的地方。参考系统提供另一个系统使用但并不拥有的数据。Salesforce 可以是客户关系的互动系统，而 ERP 仍然是其法律和财务属性的记录系统。这不是架构的弱点；它就是架构。错误在于为了让图看起来更简单，就假装必须由一个系统拥有一切。
混合式黄金记录
Section titled “混合式黄金记录 ”这就改变了“黄金记录”的含义。第 5 章在讲如何把坏数据挡在外面时引入了这个概念；在这里，它是设计的核心。人们想象的是一条神奇的记录，每个字段都在一个地方主控。有时设计确实如此。但在 Salesforce 上，我更常看到的是一种混合式：客户记录的一部分在别处主控并被复制进来（法定名称、ERP 客户编号、账单地址、信用状态），另一部分只因为 Salesforce 需要它而存在（客户经理、业务机会策略、成功等级、关系备注）。ERP 的字段被复制进来，是为了让人们能使用它们。Salesforce 的字段永远不会回传，因为 ERP 不关心它们。这完全合理，只要每个人都知道哪个是哪个。
让权威看得见
Section titled “让权威看得见 ”所以我会让外部权威在结构中一目了然。如果 SAP 控制某个字段，它就带一个前缀：sap_Customer_Number、sap_Credit_Status、sap_Legal_Name。这和第 4 章的 erp_ 前缀是同一个思路。当这种权威具体而稳定时，就用系统的名字；当含义比今天的供应商更重要时，就用一个通用前缀。重点是，六个月后，阅读模型的人能看出：**这不只是又一个 Salesforce 字段；这个值由另一个系统拥有。**不要让人们通过逆向分析集成来重新发现权威。
建立一张权威系统图
Section titled “建立一张权威系统图 ”对于重要的主数据，我想要一张权威系统图：对每一个关键属性，**谁创建它，谁拥有业务决定，哪个系统是权威的，以及谁或什么可以修改它。**四个不同的问题：
| 属性 | 由谁创建 | 业务所有者 | 权威系统 | 可以修改它的是 |
|---|---|---|---|---|
| 法定名称 | 财务 | 财务 | ERP | 财务流程 |
| 信用额度 | 财务 | 财务 | ERP | 信用团队 |
| 客户经理 | 销售运营 | 销售 | Salesforce | 销售管理层 |
| 支持等级 | 服务运营 | 服务 | Salesforce | 服务管理层 |
| 同意 | 客户本人 | 隐私 | 同意管理平台 | 客户本人、经批准的流程 |
注意，**业务所有者和权威系统不是一回事。**系统不拥有策略；人拥有。系统存储并执行结果。这又是第 5 章：所有者制定策略；架构师负责执行。
一位客户。多个属性。每个属性一个权威来源。
权威会在生命周期中变化
Section titled “权威会在生命周期中变化 ”一位销售代表遇到一个 ERP 从未听说过的潜在客户，在 Salesforce 中创建了客户记录。此时，Salesforce 对名称、地址、联系人和资格认定是权威的。潜在客户变成了客户；ERP 创建了正式的客户，并分配客户编号、法定名称、账单地址和信用额度。权威转移了。Salesforce 之前并没有错；是生命周期变了。这就是第 5 章从临时到受治理的模式：转换之前，Salesforce 拥有潜在客户；转换之后，ERP 拥有受治理的属性，而 Salesforce 继续拥有它自己的那些属性。所以“哪个系统拥有这个客户？”是一个不够好的问题。要问：在生命周期的这个阶段，哪个系统拥有这个属性？
副本不是权威
Section titled “副本不是权威 ”我们把 ERP 的数据复制到 Salesforce，是因为人们一直需要它。这让 Salesforce 成为一份方便的本地副本，而不是主控方，架构也应该相应地表现：对用户只读，由集成刷新，标明来源，只能通过请求修改，当副本出现偏差时由对账来检查。副本是有用的，但权威并没有转移。
信任需要的不只是一个值
Section titled “信任需要的不只是一个值 ”“账单地址：123 Main Street。”你应该信任它吗？我想要信任信号：它从哪里来，上次确认是什么时候，哪个系统提供了它，以及谁或什么最后修改了它：一个人、一个集成、一个智能体？现在 ERP 说是 123 Main Street，Salesforce 说是 125，而一个合作伙伴文件说是“123 Main St., Suite 200”。哪个是对的？不要回答“用最新的那个”。也许是。但“最新”本身就是一条规则，它假设最后修改的那一方就该胜出。这可能是对的，也可能很糟糕。模块 3 会讨论这个问题。信任来自权威和来源，而不是找到一个有值的字段。
Steve Trucking：这是谁的真相？
Section titled “Steve Trucking：这是谁的真相？ ”一个零售合作伙伴发来一次配送，而这一笔交易里藏着好几个真相。合作伙伴的订单编号是合作伙伴的；Steve Trucking 保留它用来匹配更新，但并不因此成为它的主控方。配送状态（已到达、已送达、已安装、异常）是 Steve Trucking 的；合作伙伴会收到它，但收到一个状态并不让合作伙伴对卡车上发生的事情拥有权威。而收货人是合作伙伴的客户。合作伙伴提供姓名、地址、电话和配送备注，是因为 Steve Trucking 需要它们来完成配送。这并不让 Steve Trucking 成为这个人身份的主控方，而这个区别决定了检查点中收货人的设计。
一次配送，两个权威来源。
数据放在哪里和谁拥有它的真相，是两个不同的问题。Salesforce 可以持有 ERP 客户编号而不拥有它；Snowflake 可以持有配送状态而不是它的运营主控方；客户数据平台可以统一身份而不拥有每一个属性。一个智能体可以读取这三者，但这当然不意味着由智能体来决定哪个是真的。
**考试之外：AI 改变了什么。**智能体把属性权威变成了一条执行规则。一个人看到错误的账单地址，会知道“这个来自 SAP；我不应该在这里改”。一个被告知“更新客户的账单地址”的智能体则不会知道，除非我们为此做了设计。它需要和架构师一样的权威系统图：能访问一个字段，并不意味着那个字段就是正确的写入位置。
架构师在这里决定什么
Section titled “架构师在这里决定什么 ”- 哪个系统对每一个重要的属性是权威的，而不是由一个系统负责整条记录。
- 每个属性在哪里创建、编辑和引用，以及它的变化必须多快传播出去。
- 谁为每个属性制定策略，以及哪些人、集成或智能体可以修改它。
- 外部权威如何在模型中体现：命名前缀、权限、集成行为。
- 权威如何在生命周期中转移，比如一个潜在客户变成受 ERP 治理的客户。
唯一真相来源并不意味着一个 org、一个 ERP、一个 MDM 平台或一条巨大的记录。它意味着对于每一份受治理的信息，架构都能说出权威的值在哪里，而其他每个系统都因此知道该如何表现。这不是一个唯一真相来源，而是一套关于真相的架构。
- Salesforce Architects，Data 360 Architecture (opens in a new tab)（英文），查阅日期 2026-10-14。