把模型落到 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)
第 6 個模組，共 6 個，屬於 Data Architect 課程第 2 章為含義建模資料。每個模組都可以單獨閱讀。 上一篇：設計到第三範式，然後適度回退 · 下一篇：本章學習指南，然後是下一章：Salesforce 資料架構
**本模組回答的問題：**一個邏輯資料模型如何變成一個物理的 Salesforce 資料模型？
我們終於要談 Salesforce 了。如果你一直在忍著不把每個方框都變成物件，現在可以了。但請注意我們是按什麼順序走過來的：我們理解了業務，描述了資料，把每個事實放在該放的地方，並決定了在哪裡有意變通。直到現在，我才問 **Salesforce 應該如何實現它。**這就是我希望你記住的推進過程：**概念 → 邏輯 → 物理。**概念模型描述業務。邏輯模型描述資料。物理模型描述我們實際上要如何構建它。
坐下、別動、建模
Section titled “坐下、別動、建模 ”物理建模這一步，在小東西上最容易看清，所以先從寵物開始。
誰是企業，誰是人？繁育者是一家企業，所以它成為一個客戶（Account），記錄類型為 Breeder。主人也是一個客戶，或者是個人帳戶，記錄類型為 Owner。同一個標準物件的兩種類型，並排位於圖的頂部，正是它們從模組 1 起一直所在的位置。
什麼沒有標準的歸宿？寵物、品種、技能、寵物技能（Pet Trick）和技能評估成為自訂物件。還記得我們在模組 5 複製到寵物上的物種嗎？它在這裡有了用處：它成為寵物的記錄類型，Dog 或 Cat。一個物件帶兩個記錄類型，各有自己的頁面配置和挑選清單值，而不是一個狗物件加一個貓物件。
哪些關係是主要-詳細資料關係？我只在子記錄永遠不會更換父記錄時才用主要-詳細資料關係。一條寵物技能終生屬於它的寵物，而每條技能評估屬於它的寵物技能，所以兩者都是主要-詳細資料關係。這馬上就有回報：正是主要-詳細資料關係讓寵物能對它的寵物技能做彙總，這樣模組 5 的已會技能數就能自動保持同步。不過寵物是會換主人的，所以主人用的是查閱關係。
哪些是查閱關係？Salesforce 不建議單個父記錄下有超過 10,000 條子記錄。像坐下這樣熱門的技能、一個常見品種或一家大型繁育者，很容易就超過這個數，所以寵物技能用查閱關係指向它的技能，寵物也用同樣的方式指向它的品種和繁育者。還有，儘可能避免多型關係，也就是一個欄位可以指向多種物件類型的那種。它們在第一天很方便，但對之後所有需要讀取它們的東西都更難：報表、整合，現在還有 agent。
**什麼留在平台之外？**如果寵物戴著一個會報告位置的 GPS 項圈，這個位置根本不需要複製進來。它可以是一個外部物件，從項圈的追蹤系統即時讀取。
那張圖上的每一個決定，都能追溯到我們之前做過的某個決定，這正是重點所在。現在對 Steve Trucking 做同樣的一步。
從邏輯模型開始
Section titled “從邏輯模型開始 ”我們的 Steve Trucking 邏輯模型現在包含零售合作夥伴、配送中心、裝貨清單、配送、配送項目、收貨人、路線、停靠點、配送小組、卡車和配送小組分配。這些是業務概念，現在我可以開始把它們對映到 Salesforce 了。
零售合作夥伴可能是一個客戶（Account）。配送可能對映到 Salesforce 中已有的、用於現場排期工作的某樣東西，也可能成為一個自訂物件。裝貨清單沒有合適的標準物件，所以很可能成為自訂物件。而收貨人是一個真正的難題：個人帳戶、連絡人，還是乾脆只是配送上的資訊？我們會在下一章好好回答這個問題。
重要的詞仍然是可能。不要因為一個業務概念聽起來像某個 Salesforce 物件，就認定它的實現。這就是我們先構建邏輯模型的原因：它給了我們一個用來檢驗 Salesforce 設計的參照。
一個業務實體並不自動意味著一個自訂物件
Section titled “一個業務實體並不自動意味著一個自訂物件 ”有一個陷阱我希望管理員避開：「我們識別出了十一個實體，所以需要十一個自訂物件。」不對。一個邏輯實體告訴我們這個業務概念很重要。它並不規定 Salesforce 必須如何儲存它。一個概念可能成為一個標準物件、一個自訂物件、物件之間的一個關係、一個或幾個欄位、一個在配置中管理的值，或者完全存在於 Salesforce 之外的資料（Steve Trucking 的配送照片就是這方面的好候選）。這些選擇是在物理模型中做出的，這也正是我們沒有在第一次通話時就做這些選擇的原因。
屬性變成物理欄位
Section titled “屬性變成物理欄位 ”屬性也會經歷同樣的轉變。我們邏輯上的卡車有車輛編號、VIN、品牌、型號、年款、車牌和狀態。現在我們來決定它們在物理上如何存在：哪個物件擁有它們，用什麼欄位類型，哪些必填，哪些必須唯一，哪些是外部識別符號，哪些需要驗證，哪些是推匯出來而不是儲存的，哪些是敏感的。在邏輯層面，我們問的是**卡車意味著什麼。**在物理層面，我們問的是 **Salesforce 將如何表示卡車。**不同的問題。
關係變成平台層面的決定
Section titled “關係變成平台層面的決定 ”我們在關係上花的所有時間，在這裡都有了回報。我們已經知道每個關係是一對一、一對多還是多對多，是必需還是可選，以及它的歷史是否重要。現在我們決定 Salesforce 如何實現它：查閱關係、主要-詳細資料關係，還是 Salesforce 交叉物件（Junction Object），也許是一個帶有自己屬性的交叉物件，因為正如我們發現的，關係本身可以有業務含義。
回想一下配送小組分配。我們本可以在本章一開始就說：「我們在配送小組和卡車之間建一個 Salesforce 交叉物件吧。」看看我們會跳過什麼：這個關係為什麼存在，它是否需要一個日期和一條路線，它是否有狀態，幾週後的一起貨損索賠是否需要它的歷史。這些業務問題告訴我們配送小組分配是什麼。只有在那之後，我們才應該決定 Salesforce 如何構建它，以及 Salesforce 是否已經有能勝任這項工作的東西。
現在畫出物理模型
Section titled “現在畫出物理模型 ”圖又變了。概念模型展示的是業務概念和簡單的連線。邏輯模型加上了屬性、鍵、基數，以及藏在關係裡的實體。現在，物理模型開始看起來像 Salesforce 了：標準物件、自訂物件、欄位、關係類型，以及放在平台之外的東西。
我希望你能把這三張圖並排放在一起，看到其中的推進：不是三張互不相關的圖，而是同一個業務在三個層次上的樣子。
說一下我是怎麼畫這些圖的，因為佈局本身就是資訊的一部分。我把主物件放在中間偏下的位置。如果它有父物件，我就把它們放在略高一點的地方，這樣你讀模型的順序就是從上到下、從左到右，和業務思考它的方式一致。參考資料放在一邊。顏色也有含義：我總是把 Salesforce 畫成藍色，再為公司自己的系統選一種顏色，通常是綠色，因為綠色是一種友好的顏色。我不用紅色，黃色也有點刺眼。當一個模型這樣佈局時，它在我眼裡就會唱起歌來。你能找到的很多圖其實都是在做空間管理：我怎麼把所有車停進我擁擠的車庫裡？我寧願畫一幅頭腦能把握的、有邏輯的圖景。
物理模型必須尊重平台
Section titled “物理模型必須尊重平台 ”Salesforce 不是一個通用的關聯式資料庫。它在關係、所有權、安全和報表方面有自己的主張。它有限制、查詢行為和自動化，還有一套會影響模型在規模下如何表現的架構。所以一個在白板上看起來完美的邏輯模型，在變成物理模型時可能需要改變。這不是 Salesforce 在礙事，而是說明平台有它自己的形狀，好的架構師理解這個形狀。下一章講的正是這個。
有時，物理模型也會因為我們在模組 5 中做出的反規範化決定，而有意不同於乾淨的邏輯模型。這沒問題，只要我們能解釋原因。
不要從設定介面開始設計
Section titled “不要從設定介面開始設計 ”有一個習慣，如果你有，我希望你改掉：從設定 → 物件管理員 → 新建自訂物件開始你的資料架構，邊做邊摸索模型。Salesforce 讓建立東西變得極其容易；這是它的優勢之一，也是薄弱的資料模型出現得如此之快的原因之一。點幾下就有了一個物件，再點幾下就有了欄位和一個關係。然後資料進來了，Flow 建起來了，報表做出來了，整合依賴上它了，而你五分鐘建立的物件改起來就非常昂貴了。這就是第 1 章的可逆性測試。所以在點選新建自訂物件之前，先把模型畫出來。
物理不等於永久
Section titled “物理不等於永久 ”我把三個模型分開還有另一個原因：技術會變。今天，Steve Trucking 的一部分資料在 Salesforce 核心平台上。明天，其中一部分可能在 Data 360、某個資料倉儲，或者一個我們還沒選定的系統裡，而 AI 助手需要它自己的表示。物理架構可以變，而業務概念卻出奇地穩定：零售合作夥伴、配送和收貨人仍然存在。這正是邏輯模型的價值所在。它是對業務的一份持久的描述，不與今天的實現繫結。
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”在把邏輯模型變成物理的 Salesforce 模型時，我要決定的是：
- 哪些業務實體對映到 Salesforce 的標準能力，哪些需要自訂物件或其他表示方式。
- 邏輯屬性如何變成物理欄位，關係如何在平台上實現。
- 有意的反規範化在物理設計中放在哪裡。
- 哪些資料屬於 Salesforce，哪些屬於別處。
- 平台的哪些特性要求物理模型不同於邏輯模型。
最重要的是，我希望能把每個決定往回追溯。如果你指著我物理模型裡的某樣東西問**「為什麼它在那裡？」**，我應該能帶你沿著邏輯模型和概念模型一路回溯，找到業務真正需要的某樣東西：業務 → 概念 → 邏輯 → 物理。
**考試之外：AI 改變了什麼。**AI 現在可以一步就把一份需求文件變成 Salesforce 的物件和欄位。這讓這個順序變得更重要，而不是更不重要：如果它從需求直接跳到了配置，就讓它展示中間發生了什麼：它把什麼認定為實體，選了哪些鍵，假定了哪些關係，在哪裡做了反規範化。這些都是架構決定，架構師仍然需要看到它們。
本章我們從第一次通話、聆聽名詞開始，以一個能追溯回業務的物理模型結束。既然我們已經選擇在 Salesforce 上構建，下一個問題會更深入：我們實際上是在一個什麼樣的資料平台上構建？
- Designing Record Access for Enterprise Scale: Parent-Child Data Skew (opens in a new tab)，Salesforce Developers，Winter ‘27（英文，查閱日期 2026-10-02）：「父子關係中，一條父記錄下的子記錄不要超過 10,000 條。」這是關於資料傾斜的指導原則，不是硬性限制；第 7 章會更深入。
- Roll-Up Summary Field (opens in a new tab)，Salesforce Help（英文，查閱日期 2026-10-12）：彙總摘要欄位通過主要-詳細資料關係對從記錄進行計數或求和。