關聯不等於主控
另有 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 部分：成為資料架構師。上一章：資料品質與治理。
「我們需要一個唯一的真相來源。」這是架構中被重複得最多、也被審視得最少的說法之一。關於什麼的真相？拿一個客戶來說。ERP 可能擁有它的法定名稱、賬單地址和信用額度；Salesforce 擁有它的客戶經理和支援等級；一個同意管理平台擁有它的營銷偏好。一條記錄上有三個權威來源，而這很正常。所以當有人說「Salesforce 是我們關於客戶的唯一真相來源」時，我接下來的問題總是：哪個真相？
本章講的是有意識地回答這個問題。權威是逐個屬性分配的。把記錄關聯起來並不等於主控它們。而 Salesforce 為不同的工作提供了不同的工具：一個 org 內部的重複管理和合並；跨來源提供統一檢視的 Data 360 身分解析；當值必須只決定一次、再推回到每個地方時，用一個專門的 MDM 平台。本章以檢查點 1 結束，第 1 部分在 Steve Trucking 上匯聚到一起。
圖片由 AI 生成。
本章的立場
Section titled “本章的立場 ”- **每個屬性一個真相。**問一問每一份資料在哪裡建立、編輯和引用，以及它變化得多快。用一個系統字首，比如
sap_或erp_，在結構中顯示外部權威。 - **潛在客戶不一樣。**在 ERP 知道它們之前，它們存在於 Salesforce 中；轉換之後，ERP 的權威才適用。
- **在 Salesforce 專案中，註冊式是常態，**其次是整合式和共存式；純粹的集中式 MDM 很少見。
- **只有在有明確勝出者時才合併。**當你可能需要回溯時，保留來自外部載入的重複記錄；合併會毀掉那份歷史。還要決定子記錄怎麼辦：移過去、不載入，還是留在一條不活躍的記錄上。
- **統一檔案是一張地圖；黃金記錄是一個決定。**這一點可能會讓人困惑：身分解析建立的是一個統一的個人，而不是黃金記錄。
- **比對的嚴格程度是一個風險決定。**在混合代價高昂的地方，有意少比對。
- **三種工具，三份工作：**合併、身分解析、MDM。
- **層級是分頭主控的。**逐個分支地決定權威。
- **「最難的是雙向同步。」**一個雙向整合並不會產生兩個主控方。在第一次衝突之前，就決定哪些欄位要作為一個事務一起傳遞。
- **讓主資料看得見。**用一個說明「這是主資料」的欄位（ERP 的鍵或一個標誌）來驅動可編輯性，而不是用記錄類型。
- **我們控制不了 ERP。**我們能控制的是如何在 Salesforce 中表示它們：兩套 ERP 中的同一個客戶，用層級、平級客戶，還是一個客戶、每套 ERP 一個子記錄，取決於客戶讓其各套 ERP 保持同步的能力。
三種工具，三份工作
Section titled “三種工具，三份工作 ”| 工作 | 工具 | 它對來源做了什麼 |
|---|---|---|
| 一個 org 內部有明確勝出者的重複記錄 | 重複管理與合併 | 最多合併三條記錄；其他的進入資源回收筒 |
| 跨來源的一個身分和統一檢視 | Data 360 身分解析 | 把它們關聯起來；一個都不修改（註冊式） |
| 一個受治理的值，推回到每個系統 | 專門的 MDM 平台 | 決定這個值並分發它（共存式或集中式） |
本章的路線
Section titled “本章的路線 ”六個模組加一個挑戰，每個都可以單獨閱讀。
- **每個屬性一個可信來源。**權威系統圖、混合式黃金記錄，以及信任訊號。
- **主控資料的四種方式。**註冊式、整合式、共存式和集中式，以及為什麼共同的模型不等於共同的真相。
- **比對、合併與存續規則。**錯誤比對的代價，Salesforce 合併真正做了什麼（以及子記錄會怎樣），以及作為一種信任宣告的存續規則。
- **地圖不是決定。**比對規則與比對方法、協調規則，以及為什麼統一檔案不是黃金記錄。
- **當權威被共用：層級與雙向資料。**請求與更新，迴圈與衝突，分頭主控的層級，以及兩套 ERP 中的同一個客戶。
- **檢查點 1 挑戰，然後是檢查點 1：Steve Trucking，如果由我來設計。**先嚐試挑戰：畫出並論證第 1 部分的設計，再和我的進行比較，看看與第 4 章的全景圖相比有哪些變化。
讀完之後，用本章學習指南檢查一下自己：一份備考清單、考試之外的習慣、必知術語，還有幾道題。它為第 1 部分收尾；第 1 部分學習指南把全部六章串在一起。
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”- **哪個系統對每一個重要的屬性是權威的，**以及這如何在模型中體現出來。
- **哪種主控方式適合每一個數據領域，**以及主控層獲得多大的權威。
- **什麼時候合併，什麼時候關聯，**以及誰擁有每一條存續規則。
- **比對應該多嚴格，**依據錯誤比對的代價來決定。
- 雙向資料和共用的層級需要在哪裡設定明確的邊界。
**考試之外：**代理程式需要一個可以據此行動的身分，而這在兩個方向上都提高了風險。過度比對會變成一起隱私事件，而一個「更新客戶」的代理程式必須寫入每個屬性的記錄系統，而不是統一檔案。每個模組的結尾都會講 AI 帶來了什麼改變。
- Salesforce Architects，Data 360 Architecture (opens in a new tab)（英文），查閱日期 2026-10-14。
- Salesforce Help，Considerations for Merging Duplicate Accounts (opens in a new tab)、Identity Resolution Match Methods (opens in a new tab) 和 Identity Resolution Reconciliation Rules (opens in a new tab)（英文），查閱日期 2026-10-14。
**下一章：**第 2 部分從Designing for Scale *(coming soon)*開始。