Salesforce 資料架構
另有 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 課程第 3 章的學習指南。請先閱讀十個模組；這一頁幫你檢查自己記住了什麼。
**關於本學習指南。**它只依據本課程自己的內容，以及 Salesforce 公開發布的考試指南中的目標清單編寫。它從不基於真實的考試題目，也不聲稱知道考試會考什麼。如果你參加過考試，請不要把考題發給我：認證協議禁止分享考題，而且死記答案本來就不是成為架構師的正確方式。
這是模型與平台相遇的一章，承載了考試的很大一部分。它同時支撐考試中最大的兩個部分：「資料建模與資料庫設計」和「Salesforce 資料管理」，各佔考試的四分之一。平台的數字會變：清單裡給出的是各模組所引用的數字，並註明了查閱日期。要了解每項限制的用途，並在依賴它之前檢視當前的數字。
邊學邊打勾。每一條都連結到講授它的地方。
DM-1：在平台上設計資料模型
- 我知道 Salesforce 是一個後設資料驅動的多租戶平台：物件是後設資料，而不是一張新表，而且每個物件一存在就有了它的 API。（後設資料就是藍圖，你的 API 隨物件一起到來）
- 我知道控管限制的存在，是為了讓一個租戶不能霸佔共用資源。（你不能霸佔電梯）
- 我能讀懂標準資料模型：潛在客戶轉換為客戶、連絡人和商機；商機產品指向一個價格手冊條目，價格手冊條目再指向 Product2；服務一側則有案例、資產和權利（Entitlement）。（Sales 模型，Service 模型）
- 我知道 New Custom Object（新建自訂物件）介面決定了什麼：記錄名稱用文字還是自動編號；Object Classification（物件分類）（開啟共用、Bulk API 和 Streaming API，就是 Enterprise Application 物件；關閉它們，就是 Light Application 物件）；以及 Allow Search（允許搜尋），預設關閉。（New Custom Object 介面）
- 我能讀懂 API 名稱：標準物件和欄位沒有字首或字尾；自訂物件和欄位以
__c結尾；託管軟體包會加上它的名稱空間字首（abc__）；而你在軟體包的物件上新增的欄位會帶__c，但絕不會帶供應商的字首。（字首和字尾） - 我能對標準物件運用乾淨契合測試，也知道什麼時候含義或分量指向自訂物件。（乾淨契合測試）
- 我知道資產和個人帳戶的用途，知道一個個人帳戶佔用的儲存大約是企業客戶的兩倍，也知道個人帳戶一旦啟用就無法停用。（資產是個好例子，個人帳戶，個人帳戶：這個人什麼時候就是客戶？）
- 我按需要的行為來選擇欄位類型（車隊編號不是數字），也知道日期/時間以 GMT 儲存，並按每個讀者的時區顯示，所以要用範圍來比較，而不是用等於。（數字不一定是數字，日期、日期/時間和時間）
- 我知道文字有兩類：記錄上最多 255 個字元的文字（可建索引，可用作唯一值或外部 ID），以及超過這個長度的長文字或富文字，它們沒有索引，不能用
WHERE篩選，也不能用在公式裡。（文字家族） - 我知道什麼時候用自動編號作為 Name，也知道它不是記錄的 ID。（需要人來識別它嗎？）
- 我知道外部 ID 如何讓整合做 upsert，以及如何通過父記錄的外部 ID 載入子記錄。（外部 ID）
- 我知道一個值什麼時候應該由公式推導，什麼時候它是必須儲存的歷史事實。（儲存還是推導？）
- 我知道邏輯交叉物件（建模概念：一個在多對多關係中連線另外兩個物件、並帶有自己屬性的物件）和 Salesforce 交叉物件（Junction Object）（一個有兩個主要-詳細資料關係的自訂物件）之間的區別，也知道 Salesforce 說的是後者。（寬兩個父物件）
- 我知道層級關係（Hierarchical）：一種只存在於使用者物件上的特殊查閱關係，例如標準的 Manager 欄位，它不能直接或間接地繞回同一個使用者，而且它不是角色階層。（層級關係）
- 我知道查閱關係和主要-詳細資料關係的區別：所有權、共用、必需的父記錄、級聯刪除、彙總摘要欄位。（查閱關係，主要-詳細資料關係）
- 我知道不能在一個已經有資料的物件上建立主要-詳細資料關係（先建立查閱關係，填好值，再轉換），只有當主記錄上沒有彙總摘要欄位時才能改回查閱關係，而移動子記錄需要允許重設父級。（子記錄能更換父記錄嗎？）
- 我知道主要-詳細資料關係在平台上的形狀：最深三層自訂從物件（查閱關係可以在任何地方斷開這條鏈），最寬兩個主要-詳細資料關係父物件。在 Salesforce 交叉物件中，先建立的主要-詳細資料關係是主要父物件（決定所有者、外觀和部門），第二個是次要父物件，而存取需要兩個父物件都滿足：最嚴格的那個說了算。（深三層，寬兩個父物件）
- 我知道父記錄被刪除時，查閱關係的三種選擇：清空欄位（預設）、阻止刪除，或者級聯刪除；級聯刪除在 Salesforce 啟用之前是關閉的，而且會繞過共用。（查閱關係）
- 我知道自關係必須是查閱關係，也知道內建的兩個：客戶的上級客戶（Parent Account）和案例的父案例（Parent Case）。（自關係）
- 我知道彙總摘要欄位的重新計算可能需要時間，知道彙總摘要欄位不能使用帶有
NOW()、TODAY()或跨物件引用的公式，也知道不要只為了得到彙總摘要欄位就選擇主要-詳細資料關係：替代方案是一個由 Flow 或觸發器保持最新的儲存欄位。（彙總摘要欄位很有用，但不是免費的） - 我知道模組中引用的關係限制：每個物件兩個主要-詳細資料關係；預設 40 個關係欄位（最多 50 個）；預設 25 個彙總摘要欄位（最多 40 個）。（關係也有限制）
DM-2：尊重共用並能擴充套件的模型
- 我知道主要-詳細資料關係中的子記錄沒有自己的所有者，也沒有自己的共用表：存取權限跟隨主記錄。（所有權會隨之而來）
- 我知道父子資料傾斜：Salesforce 的建議是單個父記錄下的子記錄不超過大約 10,000 條。（一萬條子記錄的問題）
- 我知道所有權資料傾斜（一個使用者擁有某個物件超過 10,000 條記錄）以及相關建議：分散所有權，或者讓這個使用者不在角色階層中、或單獨位於頂部，並且不進入共用規則所用的公用組。（所有權可能變成規模問題）
- 我瞭解共用表：自訂物件的共用物件是
Object__Share；從物件沒有共用物件，它的存取權限來自主記錄；而更換所有者會刪除手動共用，但會保留帶有自己原因的 Apex 共用。（共用表） - 我能根據所有權是否決定共用，來決定整合和代理程式建立的記錄歸誰所有。（系統建立的記錄歸誰所有？）
DM-4：大物件與標準物件和自訂物件的比較
- 我知道資料的三個歸宿：核心之上（sObject，每天都在用）、引用的（另一個系統是真相的來源：Salesforce Connect 的外部物件
__x，或自訂呼叫），以及歸檔的（核心之上的大物件__b，或核心之外的資料倉儲）。（核心之上與核心之外） - 我知道外部物件每次被存取都會發起一次外部呼叫，所以延遲和源系統的可用性很重要。（引用）
- 我瞭解大物件：海量資料，通過索引按精確比對或範圍查詢，沒有標準介面或報表，只有物件和欄位權限，沒有自動化。（歸檔）
- 我知道大多數記錄不管有多少欄位，都按大約 2 KB 的資料儲存計算，而檔案在檔案儲存中單獨計量。（兩列還是兩百列，檔案與附件）
SDM-1：許可以及人們能使用的物件
- 我知道三種內部許可：Sales Cloud、Service Cloud 和 Platform，以及每種許可能使用什麼。（三種內部許可）
- 我知道許可是資料模型的一部分：Salesforce Platform 使用者不能使用潛在客戶、市場活動、商機或預測，Customer Community 使用者不能使用商機。（現在讓我把一切都複雜化：許可）
- 我知道外部許可的等級：Customer Community、Customer Community Plus（報表、儀表板、標準共用）、Partner Community（銷售物件）；也知道 Partner Community 不能與個人帳戶一起使用。（體育場）
- 我知道按成員計費與按登入計費的許可方式，以及各自適合哪類人群。（付費方式會改變設計）
- 我知道有些平台許可把使用者限制在一個應用、最多十個自訂物件，也知道在此限制下工作的記錄類型模式。（當許可塑造模型時）
- 我知道 Salesforce Integration 許可是給系統間的、只用 API 的使用者的。（使用者不再只是人）
- 我知道 SLA 報表需要權利和里程碑，而它們需要 Service 許可。（現在讓我把一切都複雜化：許可）
SDM-2：保持資料一致
- 我能把一條規則放到一致性階梯的正確一級上：欄位類型和詞彙、必填和唯一、驗證規則、重複規則、自動化。（保持資料一致）
- 我知道受限制的挑選清單會拒絕不在清單上的值，即使是通過 API；而全域值集讓多個欄位共用一份清單（最多 1,000 個值）。（第一級）
- 我知道頁面配置上的必填要求只保護那個介面，而不是資料，而驗證規則在每次儲存時都會執行。（介面驗證不等於資料驗證，第三級）
- 我能用 ISNEW() 和 ISCHANGED()、一個自訂權限或一個上線日期來限定驗證規則的範圍，並且知道每種選擇仍然會檢查哪些儲存（包括我控制不了的儲存，比如批次更換所有者或彙總摘要欄位的更新）。（舊記錄問題）
- 我瞭解比對規則和重複規則、模組中引用的限制（每個物件五條有效的重複規則，每條三條比對規則），也知道它們解決不了跨系統的身分問題。（第四級：重複規則）
- 我知道重複規則不會比較同一時刻儲存的記錄，知道通過 API 和匯入的儲存會被直接阻止，沒有提醒，也知道一次儲存以及它引發的一切作為一個事務一起回滾。（第四級，全有或全無）
- 我知道工作流規則和 Process Builder 已不再受支援；自動化意味著 Flow 或 Apex。（第五級：自動化）
考試是底線，不是天花板。下面這些是本章中架構師需要的習慣，不管有沒有考題問到它們。
- **平台有它的形狀。**為你所在的平台做設計，而不是為一個通用資料庫。
- **看向母艦。**在發明一個概念之前，先看看 Salesforce 是如何為它建模的。
- **每個物件都是一份承諾：**儲存、限制、共用模型、許可和依賴。
- 在選擇物件之前，先問資料放在哪裡：核心之上、引用還是歸檔。
- **讀懂任何一個 API 名稱，你就知道它是誰做的，**以及你能改什麼。
- 如果你今天不歸檔，你還會有歸檔的那一天嗎？
- 在建議使用大物件之前，先做個原型。
- 不同的業務名稱並不自動意味著不同的物件。
- **問一問哪些身分需要這些資料：**人、客戶、合作夥伴、整合和代理程式。
- **每個欄位都要有描述，**在重要的地方還要有分類。
- **先描述關係的行為；**配置只是去實現它。不要為了得到一個功能而扭曲模型。
- **刪除問題：**如果有人刪除了父記錄，子記錄應該怎樣？
- **選擇由哪一環斷開這條鏈：**在子記錄真正有自己生命的地方使用查閱關係。
- **所有權來自主要父物件，存取來自兩個父物件：**最嚴格的那個說了算。
- **把不活躍和消失分開，**讓保留成為一條業務規則。
- **把規則放到它正確所屬的最低一層，**並給合法的歷史資料一個繞過機制，而不是改寫它。
- **圖不等於架構。**要能把每個結構追溯到一個業務理由。
| 術語 | 一句話解釋 |
|---|---|
| 後設資料驅動 | 物件和欄位是平台在執行時讀取的定義，而不是新的物理表 |
| 多租戶 | 許多 org 共用基礎設施，彼此隔離，就像一棟樓裡的公寓 |
| 控管限制 | 防止一個租戶獨佔共用資源的限制 |
| 外部物件 | 通過 Salesforce Connect 在 Salesforce 中顯示的資料，每次存取都從來源獲取 |
| 大物件 | 用於存放極大量、很少使用的資料的儲存，通過索引查詢 |
| 個人帳戶 | 把一個個人表示為一個客戶，用於企業對消費者的模式 |
| 乾淨契合 | 與某個標準物件的本來用途相吻合的業務概念 |
| 外部 ID | 存放另一個系統識別符號的欄位，用於 upsert 和比對 |
| Upsert（更新插入） | 記錄存在就更新，不存在就建立 |
| 查閱關係 | 子記錄保留自己的所有人和生命的關係 |
| 主要-詳細資料關係 | 子記錄屬於父記錄的關係：繼承所有人和共用，級聯刪除，彙總摘要欄位 |
| 邏輯交叉物件 | 建模概念：一個在多對多關係中連線另外兩個物件、並帶有自己屬性的物件，無論它是如何構建的 |
| Salesforce 交叉物件（Junction Object） | Salesforce 所說的「交叉物件」：一個有兩個主要-詳細資料關係的自訂物件 |
| 主要主物件和次要主物件 | Salesforce 交叉物件上先建立的主要-詳細資料關係（決定所有者、外觀和部門）和第二個主要-詳細資料關係（決定報表範圍；如果第一個被移除，它就成為主要的） |
| 層級關係 | 一種只存在於使用者物件上的特殊查閱關係，例如 Manager，不能繞回同一個使用者 |
| 名稱空間字首 | 供應商在託管軟體包的物件和欄位上加的字首，例如 abc__Inspection__c |
| 共用表 | 存放一條記錄大部分共用資訊的共用物件（AccountShare、Truck__Share），每個使用者或組一行，並帶有原因 |
| 彙總摘要欄位 | 主記錄上對其從記錄計數、求和或求最小值、最大值的欄位 |
| 資料傾斜 | 一個父記錄或一個所有人名下的記錄太多，導致鎖定和長時間的共用重新計算 |
| 按成員計費 / 按登入計費 | 按外部使用者付費，或按每月的登入次數付費 |
| 一致性階梯 | 執行資料規則的各個層，從欄位類型一直到自動化 |
| 受限制的挑選清單 | 無論來自哪裡，都拒絕不在清單上的值的挑選清單 |
| 資料分類 | 關於所有者、用途、敏感性和合規類別的欄位後設資料 |
按課程風格編寫的簡短情景題。開啟答案之前，先想好你的答案。
1. 使用者需要檢視由 ERP 擁有並整天更新的訂單詳情。他們不在 Salesforce 中編輯這些資料。要複製進來嗎？
引用它們：通過 Salesforce Connect 使用外部物件，讓 ERP 繼續作為真相的來源，不需要同步任何副本。要接受每次檢視都會發起一次外部呼叫，所以延遲和 ERP 的可用性很重要，而且它更適合讀取存取，而不是大量編輯或報表。重讀引用。
2. 業務方想追蹤經銷商、供應商和零售合作夥伴。建三個自訂物件嗎？
不。它們都是公司，所以客戶是乾淨契合的；不同的名字是角色，由一個類型、一個記錄類型或一個關係來承載。重讀乾淨契合測試。
3. 一個設計用了商機，但需要這些資料的大多數人用的是 Salesforce Platform 或 Customer Community 許可。現在怎麼辦？
這些許可不能使用商機，所以許可是一個架構約束：購買不同的許可，把體驗挪個地方，或者重新設計，通常是轉向自訂物件。重讀現在讓我把一切都複雜化：許可。
4. ERP 每晚向客戶傳送更新。整合應該如何在不查詢 Salesforce ID 的情況下找到正確的記錄？
把 ERP 的客戶編號存在一個外部 ID 欄位裡，基於它做 upsert：找到就更新，找不到就建立。子記錄也可以通過父記錄的外部 ID 來指向它。重讀外部 ID。
5. 配送項目不能脫離它的配送而存在，從不移動，也不需要自己的所有人。配送在排上路線之前就存在，並且可以移到另一條路線上。各用什麼關係？
配送項目到配送：主要-詳細資料關係（它終生屬於父記錄，繼承存取權限，刪除時級聯）。配送到路線：查閱關係（有自己的生命，一開始是可選的，可以移動，而刪除路線絕不能刪除配送）。重讀從業務關係開始。
6. 一個整合每天建立 3,300 次配送，全部歸整合使用者所有，而這個使用者在層級中間有一個角色。風險是什麼，怎麼修？
所有權資料傾斜：超過 10,000 條記錄後，移動這個使用者或改變它的組會觸發長時間的共用重新計算。如果所有權對存取很重要，就分散所有權；否則就讓整合使用者不在角色階層中，或者單獨位於頂部的一個角色裡，並且不進入共用規則所用的組。重讀所有權可能變成規模問題。
7. 你加了一條驗證規則，有 20,000 條舊記錄違反了它。一個使用者在其中一條上編輯了電話號碼，儲存失敗了。這條規則本該怎麼做？
不僅說明什麼必須為真，還要說明什麼時候執行：用相關欄位上的 ISNEW() 或 ISCHANGED() 來限定它的範圍，並給在這條規則之前就存在的記錄一個有意的繞過機制，而不是改寫它們的歷史。重讀舊記錄問題。
8. 業務方希望每張配送照片都「放在 Salesforce 裡」：每年四五百萬張，每年增長 30%。你會提出什麼方案？
把存取和儲存分開。把檔案放在為這種資料量而構建的儲存中，在核心 org 之外，在 Salesforce 中保留一個引用、一個數量或一條索引記錄，讓使用者能找到並檢視它們。重讀照片。
9. 一條配送小組分配記錄（Crew Assignment）與配送小組（先建立）和卡車都有主要-詳細資料關係。一個排程員能看到配送小組，但看不到卡車。他能看到這條配送小組分配記錄嗎？
不能。配送小組是主要父物件，所以它決定了這條分配記錄的所有者和外觀，但存取需要兩個父物件都滿足：排程員需要同時有配送小組和卡車的存取權限，並且達到每個主要-詳細資料關係欄位的共用設定（Sharing Setting）所要求的級別。最嚴格的那個說了算。重讀寬兩個父物件。
10. 一個合作夥伴重發了一份裝貨清單檔案，同一個客戶在其中出現了兩次。你在客戶上有一條設為阻止的重複規則。你安全了嗎？
僅靠重複規則是不夠的。同一時刻儲存的記錄不會彼此比較，只會和 Salesforce 中已有的記錄比較，所以兩行都可能通過。把唯一性下推到欄位上：一個唯一的外部 ID，平台在每次儲存時都會檢查它，所以只有一條能成功。重讀第四級：重複規則和全有或全無。
- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab)，Salesforce Help（英文，查閱日期 2026-09-25）：官方的考試目標清單及其權重。預約考試前，務必檢視最新版本。
- 每個模組自己的「延伸探索」部分列出了其平台事實所依據的 Salesforce 文件，並註明了查閱日期。