主控資料的四種方式
另有 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)
第 2 個模組，共 6 個，屬於 Data Architect 課程第 6 章主資料與身分。每個模組都可以單獨閱讀。 上一篇：每個屬性一個可信來源 · 下一篇：比對、合併與存續規則
**本模組回答的問題：**組織如何主控資料，哪種方式合適？
模組 1 說過，權威是逐個屬性分配的。現在的問題是：當這些屬性同時存在於好幾個系統中時，我們該怎麼辦？客戶資訊在 Salesforce、ERP、計費系統、支援系統裡，也許還在 Data 360、某個資料倉儲裡，每個都有自己的版本。這正是**主資料管理（MDM）**試圖解決的問題，而 MDM 不是一種架構。你會聽到四種模式：**註冊式、整合式、共存式和集中式。**它們不是產品設定，而是對同一個問題的四種回答：主控層擁有多大的權威？
從問題開始，而不是從產品開始
Section titled “從問題開始，而不是從產品開始 ”人們一聽到 MDM，就開始去選購 MDM 產品。我會從問題開始。我們只是需要知道好幾條記錄是同一個客戶嗎？我們需要一個用於分析的合併檢視嗎？我們需要決定哪些值是權威的，並把它們推回其他系統嗎？還是我們希望由一箇中心繫統為所有人建立主資料？截然不同的需求，截然不同的架構。
註冊式：告訴我誰是誰
Section titled “註冊式：告訴我誰是誰 ”最輕量的模式。註冊式不取代各個來源。ERP 保留它的客戶，Salesforce 保留它的客戶記錄，計費系統保留它的客戶，而註冊中心弄清楚這些記錄代表的是同一個實體：Salesforce 客戶 001…、ERP 客戶 SAP-43821 和計費客戶 BILL-9127 屬於同一個客戶。來源留在原處，不會被覆蓋。現在，「給我看我們關於這個客戶知道的一切」就有了答案。
但注意註冊式回答不了什麼。Salesforce 說是 123 Main Street，ERP 說是 125，計費系統說是「123 Main St., Suite 200」。註冊中心知道它們屬於同一個客戶。它並不決定應該改哪一個。關聯不等於主控。
根據我的經驗，**在 Salesforce 專案中，註冊式是常態，**其次是整合式和共存式；純粹的集中式 MDM 很少見。註冊式之所以常見，是因為它侵入性低。你不需要先重新設計每一個運營系統才能獲得價值。Salesforce 繼續做它做的事，ERP 繼續做它做的事，你只是加了一個身分層。這比告訴每個系統「你不再控制客戶資料了，這個新的中心繫統來控制」要小得多的變化。
註冊式回答的是：哪些記錄屬於同一個實體？
整合式：把資料彙集到一起
Section titled “整合式：把資料彙集到一起 ”整合式從多個來源獲取資料，並把它們合併成一箇中心表示，用於報表、分析、細分、客戶洞察。資料倉儲是大家熟悉的例子：Salesforce 發來客戶，ERP 發來財務資料，計費系統發來付款資料，業務方終於可以跨系統分析客戶了。來源仍然存在，而且可能仍然是權威的。方向很重要：資料流進整合系統，而整合系統通常不會把主控後的變更推回去。對客戶有了更好的瞭解，但並沒有成為它的運營權威。
註冊式和整合式很容易混淆。區別在於集中的是什麼：註冊式集中的是身分（「這些屬於一起」）；整合式集中的是更多的資料（「把屬性彙集起來，以便我們使用」）。兩者都沒有說「這個中心繫統現在是主控方，每個應用都必須接受它的值」。
整合式把資料彙集到一起，但並不從來源那裡拿走所有權。
共存式：做出決定，再把它送回去
Section titled “共存式：做出決定，再把它送回去 ”在共存式中，主控層獲得了真正的權威。資料仍然存在於好幾個運營系統中，但 MDM 流程決定主控的值，並把它釋出回去。Salesforce、ERP 和計費系統各有一個不同的法定名稱；MDM 流程確定受治理的那一個，並把它分發給這三個系統。各個系統共存，但它們會收斂到主控的值上。
這是一種強得多的 MDM 形式。它說的不是「這些屬於一起」，而是**「對於這個屬性，這就是企業使用的值」。**這需要的不只是比對：業務規則、所有權、存續規則、雙向整合、錯誤處理和治理，因為總得有人決定為什麼某個值勝出。
共存式不只是關聯記錄。它決定主控的值，並把它們送回去。
集中式：由主控方創造真相
Section titled “集中式：由主控方創造真相 ”最強的模式。在集中式 MDM 中，受治理的主資料在中心主控系統中建立和維護，再分發給其他所有系統。不是每個系統各自建立自己的客戶、再由 MDM 事後協調，而是在主控系統中建立受治理的客戶，再把它傳送給 Salesforce、ERP 和計費系統。治理非常強，而變化也非常大：現有的流程會建立它們自己的客戶，使用者有他們的工作流程，整合假定在本地建立，而各業務部門甚至可能對什麼是客戶都沒有共識。這就是為什麼在我看到的 Salesforce 全景中，它很少見。它可能是對的，但這是一個比安裝一個工具大得多的決定。
集中式 MDM 把建立和權威都移進了主控系統。
四種方式並排比較
Section titled “四種方式並排比較 ”| 方式 | 集中的是什麼 | 來源是否保留？ | 是否把受治理的值推回去？ |
|---|---|---|---|
| 註冊式 | 身分和關聯 | 是 | 通常否 |
| 整合式 | 身分加合併的資料 | 是 | 通常否 |
| 共存式 | 身分、資料和主控決定 | 是 | 是 |
| 集中式 | 建立和權威 | 是，作為消費者 | 是 |
沿著表格往下，主控層獲得的權威越來越多，組織通常也要做更多的改變。
考點。掌握四種 MDM 實施方式：註冊式（關聯身分；來源保留各自的資料）、整合式（把資料彙集到一起，通常用於分析）、共存式（決定主控的值，並把它們釋出回各個來源）和集中式（由主控系統建立資料；來源消費它）。
所以並不存在「集中式最成熟，所以每個人都應該走到那一步」這回事。**選擇能解決問題的最輕量的模式。**只需要知道記錄屬於一起？考慮註冊式。需要一個用於分析的合併檢視？整合式。需要把受治理的值同步回好幾個運營系統？共存式。需要一個流程為所有人建立和控制主資料？集中式。
Data 360 處於什麼位置？
Section titled “Data 360 處於什麼位置？ ”Data 360 跨許多來源構建統一檔案，這聽起來很像 MDM，它也確實解決了問題的一部分。它的身分解析把源檔案比對成一個統一身分，並保留指向源記錄的關聯（Data 360 Architecture (opens in a new tab)，英文）。這讓它最接近註冊式。它還可以在統一檔案上顯示協調後的值。但這並不讓它成為一個會改寫來源的集中式黃金記錄系統。**統一檢視並不自動等於一條主控的企業記錄。**模組 4 講的全是這個區別。
共同的模型不等於共同的真相
Section titled “共同的模型不等於共同的真相 ”你還會聽到規範資料模型（canonical data model）。Salesforce 的客戶、ERP 的業務夥伴和計費系統的客戶都對映到一個達成一致的企業概念，即 Customer，帶有一致的識別符號和屬性，這樣每個整合就不必去理解其他每個系統的結構。Data 360 的資料模型就是把多個來源協調成共同概念的一個例子。但規範模型回答的是**我們如何一致地表示它？MDM 回答的是我們如何跨系統識別、治理和主控它？**把三個系統完美地對映到同一個 Customer 結構中，Salesforce 仍然說 123 Main Street，而 ERP 說 125。你解決的是結構，而不是權威。協調和主控不能互換。
一個業務，好幾種模式
Section titled “一個業務，好幾種模式 ”所以「Steve Trucking 需要 MDM」不是一項需求。為了什麼？零售合作夥伴、配送中心、配送小組、卡車、收貨人是不同的領域，有不同的權威：零售合作夥伴在 Salesforce 和財務 ERP 中受治理，卡車身分來自 FleetLink，每位收貨人都是由某個合作夥伴為每次配送提供的。不同的領域可以採用不同的模式，而在一個領域內，不同的屬性也可以有不同的權威。所以不要在圖的中間畫一個標著 MDM 的方框，就說問題解決了。要問這個方框做什麼。
方式也會改變整合。註冊式需要身分關聯；整合式需要可靠的入站資料流；共存式需要雙向的資料；集中式需要從主控系統分發，再加上阻止其他系統製造競爭性真相的控制措施。隨著權威的增加，協調也隨之增加，故障處理也一樣：如果 MDM 修改了法定名稱而 ERP 拒絕了它，會怎樣？這就是為什麼共存式和集中式不是「功能更多的註冊式」。它們承擔的是不同的運營職責。
MDM 是一個業務決定
Section titled “MDM 是一個業務決定 ”最重要的一點：MDM 從根本上不是一個技術決定，而是一個關於權威的決定。誰建立客戶，誰可以修改它，誰決定哪個值勝出，哪些系統必須接受它，它們不一致時怎麼辦。工具可以實現這些決定；但它無法讓組織在這些決定上達成一致。這就是為什麼一個 MDM 專案可以擁有出色的技術，卻仍然失敗：技術團隊解決了比對，而業務方從來沒有解決所有權。
我吃過虧才學到的一般教訓是：當好幾個系統主控同一份資料時，它們自己都沒有達成一致的東西，Salesforce 是協調不了的。當一家公司執行兩套 ERP 時，我會問他們如何讓兩者保持同步。如果他們做不到，Salesforce 也做不到。模組 5 講了這個故事（一個客戶，兩套 ERP）。
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”- 問題需要的是身分關聯、合併的資料、推回去的主控值，還是集中建立。
- 哪種模式適合每一個數據領域，而不是整個企業只用一種模式。
- 主控層獲得多大的權威，以及哪些系統必須接受它的決定。
- 是否需要一個規範模型，同時不把協調和權威混為一談。
- 所選的模式如何改變整合的方向、所有權和故障處理。
當有人在圖上放一個 MDM 方框時，問它做什麼。它知道哪些記錄屬於一起嗎？它合併它們的資料嗎？它決定哪些值勝出嗎？它把這些決定推回去嗎？它從一開始就建立資料嗎？這些答案告訴你，你真正擁有的是哪種架構，以及權威在哪裡。
- Salesforce Architects，Data 360 Architecture (opens in a new tab)（英文），查閱日期 2026-10-14。