資料模型是骨架
另有 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 個模組，共 7 個，屬於 Data Architect 課程的第一章像資料架構師一樣思考。每個模組都可以單獨閱讀。 上一篇：像架構師一樣思考 · 下一篇：可逆性測試
**本模組回答的問題：**為什麼資料模型比建在它之上的任何東西都重要？又該如何評判一個數據模型？
我教資料架構時，有一句話會一再提起：資料模型是骨架。
資料模型是系統的骨架。其他一切都圍繞它構建，正是它把身體的其餘部分撐在一起。你看一個人時看不到骨頭，但骨頭決定了這個人站得多高、怎麼活動、能扛多重。
想想我們在 Salesforce 實施中構建的所有東西。我們圍繞資料模型構建自動化。我們針對它編寫 Apex，編寫讀取和更新它的 Flow。我們構建整合，把資料送進去、拉出來。我們在它之上做報表和分析，圍繞它設計安全。而且越來越多地，我們構建需要理解這些資料並據此行動的 AI 代理程式。所有這些都依賴於底層的結構。
這就是為什麼儘早把資料模型做對如此重要。骨架以後可以改，但多半會很痛。
從業務開始
Section titled “從業務開始 ”好的資料模型始於一個簡單的問題：**業務真正需要表示的是什麼？**不是「我們有哪些 Salesforce 物件？」，更不是「我能快速構建什麼？」
我們要先理解業務。這個業務裡重要的東西是什麼？它們之間是什麼關係？誰擁有它們？它們如何隨時間變化？什麼需要被記住，什麼在各個業務流程之間共用？只有理解了這些，我們才應該開始把它們轉化成物件、欄位和關係。
這聽起來理所當然，但實際上很容易本末倒置。有人認出某個東西看起來像商機、案例或資產，就立刻開始圍繞它設計。有時這完全正確。有時我們是在把方釘往圓孔裡塞，而一旦圍繞這個決定構建了足夠多的東西，再把釘子拔出來就會代價高昂。
有個問題我經常聽到。一個客戶的業務可能有很多個送貨地點。每個地點應該是一個客戶，還是一個自訂物件？回答之前，先注意你需要先知道什麼：地點對這個業務意味著什麼，它會經歷什麼。這就是先給業務建模，再談物件。（我會在第 3 章給出我的答案。）
支撐。成長。效能。
Section titled “支撐。成長。效能。 ”審視一個數據模型時，我希望它通過三項檢驗：支撐業務，隨業務成長，並且效能過關。
**支撐。**模型必須支撐業務真正想要達成的目標。一個技術上能存下資料的模型，和一個真正把業務表示好的模型，差別很大。如果因為模型不太合適，我不斷新增奇怪的欄位、特殊的標誌、複雜的自動化和例外，我就會開始懷疑問題是否真的出在自動化上。也許是模型錯了。好的模型應該讓業務更容易理解，而不是更難。
成長。我說的成長，不只是指記錄更多。資料量確實重要：一萬條記錄和一億條記錄帶來的問題截然不同。但業務也會在複雜度上成長。它們會增加產品、進入新市場、收購公司、改變流程、增加渠道、連線新系統。它們會發現，原以為是一樣東西的，其實是五樣不同的東西。一個今天執行得很漂亮的模型，如果沒有給明天留出空間，就可能變成陷阱。這就是為什麼我更喜歡通過新增來成長的設計，而不是不斷修改已有部分的設計。新增新東西，通常比重新定義幾十樣東西都依賴的東西要容易。
效能。資料不會只是靜靜地待在那裡。我們寫入它、查閱它、查詢它、共用它、對它做報表、整合它，而且越來越多的 AI 系統會在行動前把它作為上下文檢索出來。一個模型在圖上可能很漂亮，執行起來卻很糟糕。所以我們既要為資料如何儲存而設計，也要為資料將如何被使用而設計。
而且它必須持續保持效能。它必須在規模下保持效能：使用者數增加時，資料量增加時，在真實條件下和高峰時段，在一年中最忙的那一天而不是平均的一天。當意外發生時，它也必須繼續保持效能。
支撐。成長。效能。整門課裡我們會一再回到這三項檢驗。
過於扁平、過於複雜，或者乾脆錯了
Section titled “過於扁平、過於複雜，或者乾脆錯了 ”我見過資料模型以三種方式出錯。
第一種是一開始就選錯了東西。我們因為某個標準物件看起來夠接近就用了它，然後花好幾年不斷新增例外，因為它從來就不合適。這就是方釘。
第二種是把模型做得過於扁平。所有東西都放進一個物件裡，一開始這顯得簡單極了。然後業務成長，我們發現其中有些東西有自己的生命週期，可能有多個執行個體，需要自己的安全設定，或者有自己的關係。突然之間，我們只能用欄位 1、欄位 2、欄位 3，或者越來越複雜的標誌和自動化，來表示一對多關係。模型沒有給我們留下任何成長的空間。
第三種是相反的錯誤：我們過度規範化。我們畫出一張優雅的圖，物件一個接一個，每個概念都分得清清楚楚。技術上很漂亮，用起來很痛苦。使用者很難理解它，頁面配置和 Lightning 頁面上一個接一個的相關清單，會讓人感覺深不見底。查詢變得更復雜，自動化要跨越更多關係，報表更難做，平台為了回答普通的業務問題也要做更多工作。
那麼扁平和規範化，哪個正確？沒有公式。你在腦子裡裝著一個最優模型的樣子，並在偏離它時理解其中的權衡。這就是架構的藝術，我們會在模組 4以及下一章學習如何建模時再回到這個話題。現在，先認識到：結構本身就是一個架構決定。
改動骨架要小心
Section titled “改動骨架要小心 ”系統一旦執行起來，我對資料模型的根本性改動就會非常謹慎。
假設一個文字欄位已經存在多年，有人說：「我們現在其實不那麼用它了，把它改成數字吧。」這聽起來只是改個欄位。但有什麼依賴這個欄位？Flow、Apex、報表、整合、資料管道、外部應用、AI 代理程式。歷史資料又會怎樣？只要還有程式碼或 Flow 引用某個欄位，平台本身就不允許你修改它的類型，這就說明了這個改動波及得有多遠。
有時正確的做法是不去修改已有的東西。視改動的嚴重程度而定，我寧願新建一個，刻意地遷移，再棄用舊結構：
寧可新增，不要修改。寧可棄用，不要突襲。
Salesforce 甚至讓你可以在後設資料裡把這句話說出來：欄位的 Field Usage 可以設為 DeprecateCandidate，即「計劃棄用，不再使用」。這會給每個閱讀該物件的人標出這個欄位；它不會隱藏欄位，所以讓它退役仍然是你要去執行的一個決定。
因為一旦架構的其他部分依賴於某樣東西，改變它的含義可能比改變它的名字危險得多。最糟糕的情況是欄位名不變而內容變了：下游的一切仍然信任這個名字。
即使是勾選欄位上的必填核取方塊這樣簡單的事，也可能變成一顆定時炸彈。如果你已經收集了資料，有些記錄就不會填寫這個欄位。然後幾天、幾週或幾個月後，有人更新其中一條記錄，儲存卻因為必填欄位而失敗，而且誰都沒有那個值。把欄位設為必填這樣簡單的改動，可能帶來意想不到的、延遲出現的後果。我們會在第 3 章再談必填，以及一個值什麼時候才真正為人所知。
考試之外：AI 也建在骨架之上。讓 AI 工具構建一個應用，它會在幾分鐘內生成物件、欄位、Flow、Apex、元件和測試。如果最初的資料模型是錯的，我們並沒有避免壞決定的後果，而是加速了它們，因為生成的每一層都多了一樣依賴那個結構的東西。這就是為什麼我希望由人類架構師來評審 AI 生成的資料模型，理解它併為它負責。模組 7 會進一步討論這一點。
在這門課裡，我們會談到很多技術：物件和關係、大數據量、查詢、整合、遷移、事務、安全、Data 360 和 AI。在這一切之下，是資料模型。
如果模型能支撐業務，能隨業務成長，並且在我們使用資料的各種方式下效能過關，我們就打下了堅實的基礎。如果基礎錯了，之後的一切都會更難。
**資料模型是骨架。**架構師在設計骨架時應當非常小心。改動現有結構，可能引發連鎖反應。
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”- 模型是否能支撐業務、隨業務成長，並在資料的各種使用方式下效能過關。
- 一個概念是適合某個標準物件，還是一枚方釘。
- 模型要做得多扁平或多規範化，以及為什麼。
- 對骨架的改動應該是一次新增、一次遷移還是一次棄用，而不是原地修改。
- Considerations for Converting the Field Type of a Custom Field (opens in a new tab)，Salesforce Help（英文，查閱日期 2026-10-02；再次查閱 2026-10-12）：哪些類型轉換會丟失資料，以及為什麼不能修改被 Apex、Flow 或流程引用的欄位的類型。
- Data Classification Metadata Fields (opens in a new tab)，Salesforce Help（英文，查閱日期 2026-10-02；再次查閱 2026-10-12）：Field Usage 的取值（Active、DeprecateCandidate、Hidden）以及其他分類欄位。