主資料與身分
另有 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 文件，並註明了查閱日期。