每個屬性一個可信來源
另有 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。