為含義建模資料
另有 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 課程第 2 章的學習指南。請先閱讀六個模組；這一頁幫你檢查自己記住了什麼。
**關於本學習指南。**它只依據本課程自己的內容，以及 Salesforce 公開發布的考試指南中的目標清單編寫。它從不基於真實的考試題目，也不聲稱知道考試會考什麼。如果你參加過考試，請不要把考題發給我：認證協議禁止分享考題，而且死記答案本來就不是成為架構師的正確方式。
本章是考試中「資料建模與資料庫設計」部分的基礎，這部分佔整個考試的四分之一。本章講的是思考方式；下一章Salesforce 資料架構講的是平台如何構建它。所以關於物件、欄位和關係的大部分考點，都需要結合這兩章。
本章中最可能在考試中用到的要點。每一條都對應一個考試目標，並連結到講授它的地方。邊學邊打勾。
DM-1：比較設計 Salesforce 資料模型的技術
- 我能解釋概念、邏輯和物理資料模型之間的區別，以及每一種的用途。（把模型落到 Salesforce 中）
- 我能在一項需求中找出候選實體，並區分在做某項工作的人和一份資料。（名詞給你候選實體）
- 我能讀懂並畫出鴉爪表示法：一、多，以及表示可選或必需的第二個標記。（讀懂連線，可選性同樣重要）
- 我能說出一個關係的基數：一對一、一對多、多對多。（問「一個還是多個？」）
- 我知道多對多關係會變成一個獨立的實體，在 Salesforce 裡通常是一個有兩個父物件的交叉物件。（關係可以變成事物）
- 我知道一個關係什麼時候需要歷史（一條帶開始和結束日期的記錄），而不是一個會被覆蓋的欄位。（時間會改變關係）
- 我能選出一個好的唯一 ID，也知道為什麼自然鍵或任何帶有個人資訊的東西是有風險的選擇。（然後我們得談談唯一 ID）
- 我知道自然鍵和代理鍵的區別，也知道一條記錄可以帶有好幾個外部識別符號。（自然鍵和代理鍵）
- 我知道自動編號欄位是一個可讀的編號，而不是記錄的 Salesforce ID。（關係依賴於唯一 ID）
- 我能運用第一、第二和第三範式，並識別出存放了多個值或者重複了關於別的東西的事實的欄位。（理解 1NF、2NF 和 3NF 的簡單方法）
- 我能解釋什麼時候應該有意反規範化（使用者、報表、規模），以及它的代價。（設計到第三範式，然後適度回退）
- 對於一份值清單，我能在挑選清單和指向物件的查閱關係之間做出選擇。（查閱關係還是挑選清單？）
- 我知道自訂報表類型最多允許四層物件關係，以及這為什麼對層次很深的模型很重要。（查閱關係還是挑選清單？）
- 我知道什麼時候適合用主要-詳細資料關係（子記錄永遠不會更換父記錄），什麼時候查閱關係更安全，包括 Salesforce 關於單個父記錄下不超過 10,000 條子記錄的建議。（關係變成平台層面的決定）
- 我知道為什麼能避免就要避免多型關係。（關係變成平台層面的決定）
- 我知道一個業務實體並不自動意味著一個自訂物件：它可以是一個標準物件、一個欄位、一項配置，或者存在於 Salesforce 之外的資料。（一個業務實體並不自動意味著一個自訂物件）
考試是底線，不是天花板。下面這些是本章中架構師需要的習慣，不管有沒有考題問到它們。
- **暫時忘掉 Salesforce。**先為業務建模，再把它對映到客戶和連絡人。
- **留意背後藏著兩樣東西的那個詞。**在 Steve Trucking，「客戶」既是零售合作夥伴，也是收貨人。
- **模型是對話的一部分。**你的第一個模型不是為了正確，而是為了讓你看到自己哪裡錯了。
- **給連線起名字。**方框相同的兩個模型，含義可能不同。
- 對每一個關係都問一問**「現在，還是隨時間變化？」**
- 唯一、不變、無含義、絕不是 PII。
- **把事實放在它該在的地方，**然後有意地適度回退，並把原因寫下來。
- **反規範化不會消除複雜度，只會轉移它。**要知道誰擁有真相。
- **一個真相來源，多種形狀：**介面、報表、資料倉儲和 AI。
- **不要從設定介面開始設計。**在點選「新建自訂物件」之前先畫出模型。
- 把每一個物理層面的決定都追溯到業務需要的某樣東西。
| 術語 | 一句話解釋 |
|---|---|
| 實體 | 業務在意併為之儲存資料的一樣東西 |
| 候選實體 | 一個在你問過之後可能成為實體的名詞 |
| 屬性 | 描述一個實體的事實 |
| 關係 | 兩個實體如何連線，用業務語言命名 |
| 基數 | 這邊的多少個與那邊的多少個相關 |
| 可選性 | 關係是必需的，還是可以為零 |
| 鴉爪 | 線末端表示「多」的標記 |
| 交叉物件 | Salesforce 構建多對多關係的方式：同時是兩個父物件的子物件 |
| 概念模型 | 業務中有什麼以及它們如何關聯；不涉及 Salesforce |
| 邏輯模型 | 資料：屬性、唯一 ID 和關係，仍不與某個平台繫結 |
| 物理模型 | 平台將如何構建它：物件、欄位和關係類型 |
| 自然鍵 | 業務中本來就存在的識別符號，比如卡車的 VIN |
| 代理鍵 | 只為識別記錄而建立的識別符號 |
| 外部識別符號 | 另一個系統為同一條記錄所用的 ID，需要保留和對映 |
| 規範化（1NF、2NF、3NF） | 把每個事實放在它該在的地方：每個欄位一個值，事實關於整個鍵，不存關於其他事實的事實 |
| 反規範化 | 出於一個你能說出來的原因，有意地複製或扁平化資料 |
| 更新異常 | 同一個事實存放在很多地方，於是一次修改會讓一些副本出錯 |
按課程風格編寫的簡短情景題。開啟答案之前，先想好你的答案。
1. 業務方告訴你一個配送小組駕駛一輛卡車。六週後，有人問某一天是哪個小組開的 117 號卡車。模型本應該有什麼？
一個配送小組分配：把配送小組和卡車之間的關係作為一條獨立的記錄，帶有開始日期、結束日期和路線。隨著時間推移，配送小組和卡車是多對多關係，而業務在意其歷史。卡車上的一個欄位會被覆蓋掉。重讀時間會改變關係。
2. 一個團隊提議用每位收貨人的電話號碼作為唯一 ID，「因為它是唯一的」。你怎麼說？
它通不過檢驗：電話號碼會變，也會被共用，所以它既不是不變的，也不是可靠唯一的，而且它是個人資訊，會被複制到每一個連結到這條記錄的系統裡。使用一個無含義的生成 ID，把電話號碼作為屬性保留。重讀然後我們得談談唯一 ID。
3. 一個配送物件有項目 1、項目 2 和項目 3 三個欄位。來了一次有四個項目的配送。真正的問題是什麼，怎麼修？
模型把一個重複的結構藏在了欄位裡（一個第一範式問題）。修法不是加一個項目 4 欄位，而是建一個配送項目實體，作為配送的子實體，讓每個項目都是一條記錄。重讀第一範式。
4. 每次配送都存了配送中心經理的名字。經理換人了。哪裡出了問題？
一個關於別的東西（配送中心）的事實被存在了配送上：這是一個第三範式問題，而現在它成了橫跨幾百條記錄的更新異常。經理屬於配送中心；配送指向配送中心。重讀第三範式。
5. 停靠點類型（僅配送、加安裝、加拉走舊貨）需要一個時長、配送小組技能和一份檢查清單。用挑選清單還是物件？
用物件。它的資訊不止一列，由業務方管理，而且按自己的節奏變化。配送的狀態是一份短小穩定的標籤清單，保持為挑選清單。重讀查閱關係還是挑選清單？。
6. 合作夥伴想要一份按區域統計的準時率記分卡，而區域存在配送中心上。你把區域複製到了每次配送上。你必須決定什麼？
誰擁有真相，副本如何保持同步，以及舊的配送應該保留它們發生時為真的區域，還是在配送中心劃到別的區域時跟著變。反規範化轉移了複雜度，並沒有消除它。重讀有時報表勝出。
7. 像坐下這樣的技能可能會關聯幾十萬只寵物。從寵物技能到技能，用主要-詳細資料關係還是查閱關係？
用查閱關係。Salesforce 的建議是單個父記錄下不超過 10,000 條子記錄，而一項熱門技能會超過這個數。主要-詳細資料關係適合從寵物技能到寵物，因為一隻寵物的技能永遠不會更換父記錄，而且一隻寵物只會少數幾項技能；也正是主要-詳細資料關係讓寵物能彙總它的已會技能數。重讀坐下、別動、建模。
- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab)，Salesforce Help（英文，查閱日期 2026-09-25）：官方的考試目標清單及其權重。預約考試前，務必檢視最新版本。