構建邏輯模型
另有 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)
第 3 個模組，共 6 個，屬於 Data Architect 課程第 2 章為含義建模資料。每個模組都可以單獨閱讀。 上一篇：畫出關係 · 下一篇：把資料放在該放的地方
**本模組回答的問題：**如何把一個概念模型變成一個邏輯資料模型？
概念模型告訴了我們 Steve Trucking 有什麼，以及它們如何關聯：零售合作夥伴和它們的配送中心，裝貨清單和配送，收貨人，路線和停靠點，配送小組、卡車和配送小組分配。這足以和業務方進行一次非常有成效的對話。但最終我需要更多細節。關於一次配送，我們需要知道什麼？是什麼讓一個配送中心不同於另一個？我們如何識別一位收貨人？什麼屬於配送小組分配，而不屬於配送小組或卡車？這些問題把我們從概念模型推向邏輯資料模型，而我們仍然還沒有在構建 Salesforce。
坐下、別動、建模
Section titled “坐下、別動、建模 ”先回到狗。我們已經有了方框和連線。現在有兩個新問題：關於每個事物我們知道什麼，以及我們怎麼把它們一個個區分開？
**什麼在描述它？**一隻狗有名字和出生日期。一位主人有姓名、電話號碼和地址。一項技能有名稱和難度。每個事實都放在它所描述的方框上。
然後是聯接。Bella 坐下做得有多好，什麼時候學會的：這是在描述 Bella 嗎？不完全是；她有些技能做得比別的好。是在描述坐下嗎？不是；每隻狗坐下的樣子都不一樣。它描述的是 Bella 和坐下這一對，所以它屬於狗狗技能：熟練程度和學會日期。這就是聯接存在的原因：有些事實只屬於這一對。
哪隻狗是哪隻？先試試名字。叫 Max 的狗多得是，所以名字不唯一。主人的電話號碼？Marcus 的兩隻狗用的是同一個電話，人會換號碼，而且那是某個人的個人資料，會被複制到每一個指向狗的系統裡。晶片號看起來更好：它唯一，而且不會變。但一隻新來的小狗可能還沒植入晶片，而鍵不能是空的。所以晶片號保留下來，作為這隻狗的另一個已知標識，而狗有了自己的狗狗 ID（Dog ID）：一個只做一件無聊工作的編號，把一隻狗和另一隻區分開。
我們接下來要問 Steve Trucking 的，也是同樣的問題；而名字、電話和晶片號各自不夠格的理由，會變成我堅持多年的一條規則。
概念模型告訴我有什麼；邏輯模型告訴我它作為資料意味著什麼
Section titled “概念模型告訴我有什麼；邏輯模型告訴我它作為資料意味著什麼 ”拿卡車來說。關於一輛卡車，我需要知道什麼？也許是它的車輛編號、VIN、品牌、型號、年款、車牌、當前里程和狀態。這些是卡車的屬性。
再看配送。也許是零售合作夥伴的訂單號、配送日期、承諾的時間視窗、實際到達時間、狀態，以及是否包含安裝或拉走舊貨。同樣，這些是屬性。
概念模型告訴我們配送是存在的。邏輯模型開始告訴我們，一次配送作為資料意味著什麼。像卡車或配送這樣一個簡單的方框，背後可能代表一整組欄位。
即便如此，在我們大多數的圖裡，方框仍然保持簡單，原因有三。欄位的數量會增長。欄位很快會過時。而且每個欄位都有一些很難在物件模型裡展示的細節：它的 API 名稱、標籤、資料類型和長度。這些細節一定會被記錄下來，只是不在第一個資料模型裡。當展示幾個關鍵欄位確實有助於講清楚問題時，我會畫一個詳細資料模型：一個聚焦的切面，只包含與要點相關的欄位。
屬性應當描述實體
Section titled “屬性應當描述實體 ”看一個屬性時，我會問一個簡單的問題：**它描述的是什麼？**卡車品牌顯然描述的是卡車。但配送上的配送小組成員姓名呢？它們描述的是配送嗎？還是描述的是一個配送小組，這個小組有一項配送小組分配，這項分配覆蓋了這條路線，而這條路線包含了這個停靠點？
資料模型正是在這裡開始暴露那些在螢幕上看起來完全合理的東西。一位排程員說：「我想在配送上看到配送小組的姓名。」這是一項合理的使用者體驗需求。但它不一定是要把配送小組的姓名儲存在配送上的需求。這是兩回事，我們會在講規範化時再回到這一點。現在，先養成習慣，問一問**這個事實實際上描述的是哪樣東西。**這個問題會幫你省去很多麻煩。
然後我們得談談唯一 ID
Section titled “然後我們得談談唯一 ID ”屬性描述事物。但還有另一個問題要解決：我怎麼知道哪個是哪個？
兩位收貨人都叫 John Smith。他們是同一個人嗎？也許是，也許不是。名字不夠用。地址呢？人會搬家。電話號碼會變。郵箱地址會變。連零售合作夥伴的名字都可能變。
這就引出了鍵：讓我們在模型中唯一識別某樣東西的東西。多年來，我在這個領域形成了相當堅定的看法。對於一個識別符號，我要求四點：
唯一。不變。無含義。絕不是 PII。
**唯一。**一個識別符號必須恰好識別一樣東西。如果兩次配送可能有相同的值，它就不是一個可靠的配送識別符號。名字通常不唯一，地址不一定唯一，電話號碼會被共用。即使今天看起來唯一的值，一旦資料夠多，也可能不再唯一。所以要問：**這裡的兩個會不會有相同的值？**如果答案是會，就要非常小心，別把它用作記錄的唯一 ID。
**不變。**這一點常常被忽略。如果我們用名字來識別一個零售合作夥伴，而這個合作夥伴改了名，我們是得到了一個新合作夥伴嗎？不是。業務實體還是同一個；只是它的一個屬性變了。記錄的唯一 ID 應當在它所識別的東西發生變化後依然有效，這就排除了名字、郵箱地址、電話號碼、地址和使用者名稱，不管我們剛開始構建系統時它們看起來多麼方便。
**無含義。**第一次聽到這一點會覺得奇怪。我為什麼要讓識別符號沒有含義？因為含義會變。想像有人構建了一個配送 ID，把配送中心、零售合作夥伴、配送日期和序號編進去：PHX-KEY-20261002-0042。看起來很聰明。然後收貨人把時間改到了週五。我們要改識別符號嗎？如果不改，它就在對我們撒謊。如果改了，我們就因為配送的一個屬性變了而改了它的唯一 ID，而每個存過舊 ID 的系統都剛剛跟丟了它。這個識別符號想同時做兩份工作：識別這次配送，並且描述它。我寧願讓屬性去描述它，讓識別符號只做一份乏味的工作：**識別它。**乏味的識別符號才是好識別符號。
**絕不是 PII。**這一點很重要，所以我把它單獨列出來。不要因為個人身分資訊看起來唯一，就把它用作識別符號。在 Steve Trucking，人們很容易想用電話號碼來識別收貨人。但鍵會被複制到系統需要連線記錄的每一個地方：整合、匯出、日誌、回傳給零售合作夥伴的狀態檔案、資料倉儲、測試資料。把電話號碼當作鍵，你就把收貨人的個人資料散佈到了整個架構中。
鍵還必須對每一條記錄都存在：**絕不能為 null 或空白。**如果有些人不願意、也不應該被要求給你某個值，那麼這個值就不能當鍵。這就是為什麼系統要簽發自己的內部識別符號，而個人資料，如果確實需要的話，就成為一個受保護的屬性。
所以我的規則是：唯一、不變、無含義、絕不是 PII。
自然鍵和代理鍵
Section titled “自然鍵和代理鍵 ”做資料庫的人對其中一些概念有專門的叫法。自然鍵是業務資料中本來就存在的：卡車的 VIN 就是個好例子。它不是我們的應用發明的，而且本身已經有含義。代理鍵是專門為識別記錄而建立的；它不描述任何東西，只負責識別。
在大多數架構裡，我更喜歡用代理鍵作為內部記錄 ID，同時把重要的自然識別符號作為屬性保留下來。這並不是說自然識別符號不好；它們往往極其重要。我只是不會自動把它們當作記錄的唯一 ID。問一問：如果這個值被更正、重新格式化、替換、重複使用、缺失，或者來自不止一個源系統，會發生什麼。一個看似簡單的決定，正是在這裡變成了架構決定。
一樣東西可以有好幾個有用的識別符號
Section titled “一樣東西可以有好幾個有用的識別符號 ”內部記錄 ID 不一定是其他所有系統都使用的識別符號。Steve Trucking 內部可能用一個生成的 ID 來識別一次配送。每個零售合作夥伴則用自己的訂單號來識別同一次配送：Keystone 在它的 CSV 裝貨清單裡，Redrock 在它的 API 裡，Brightwave 在它的 EDI 報文裡。而遺留排程工具 RouteDesk 裡的八年曆史，用的是 RouteDesk 自己的配送 ID。
這些識別符號都很重要。我們需要保留它們並正確對映，因為狀態更新必須以每個合作夥伴自己的編號回傳給它。但它們不必都成為配送的唯一 ID。「它的 ID 是什麼？」可以有不止一個答案，而架構師必須知道在哪種情境下哪個 ID 是權威的。我們會在講主資料和整合時回到這一點。
關係依賴於唯一 ID
Section titled “關係依賴於唯一 ID ”現在回到我們畫的那些線。一份裝貨清單列出若干配送。一位收貨人接收若干配送。一個配送小組有若干配送小組分配。這些關係之所以成立，只是因為我們能可靠地識別兩端的東西。
在 Steve Trucking，問題會在這裡咬人。某個零售合作夥伴當天修改了裝貨清單：一個訂單取消了，一件商品換了，一個新地址。如果我們不能憑合作夥伴的訂單號，把修改後的那一行和已有的配送比對起來，我們就會為同一臺冰箱建立第二次配送，一個配送小組可能會上門兩次。方框、屬性、鍵和關係不是各自獨立的概念，它們都是同一個模型的組成部分。
這時你可能會想：「Salesforce 會給每條記錄一個 ID。」沒錯，我們會講到。如果資料存在 Salesforce 裡，每條記錄都會得到一個 Salesforce 生成的 ID。它晦澀難讀，所以我們通常還會提供一個人們能用的 ID 欄位，比如配送編號 D-000184227，一個自動編號欄位。人們常以為這個編號就是記錄的 ID，但它不是：Salesforce ID 仍然在底層。外部系統或資料庫，比如 Oracle 或 SQL Server，也有自己的唯一 ID。但架構最終可能包含 Salesforce、財務 ERP、Snowflake、Data 360、合作夥伴的系統，以及尚不存在的系統。邏輯模型描述的是業務資料，而不讓每個決定都依賴於某一種技術。Salesforce 如何在物理上實現它，是後面的步驟。
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”在把概念模型變成邏輯模型時，我要決定的是：
- 哪些屬性真正描述了每個實體。
- 每個實體如何被唯一識別，以及這個識別符號是否穩定到足以成為它的唯一 ID。
- 哪些業務識別符號（合作夥伴訂單號、遺留 ID）需要被保留和對映。
- 是否有敏感資訊被用作了鍵。
- 關係是否通過可靠的唯一 ID 連線實體。
現在我們有了實體、關係、屬性和唯一 ID：一個真正的邏輯資料模型的雛形。但仍然有一個問題。把完全有效的資料放錯地方是非常容易的。這就是規範化登場的地方。
- Custom Field Types (opens in a new tab)，Salesforce Help（英文，查閱日期 2026-10-09）：自動編號為每條記錄分配一個唯一編號，可設定顯示格式，如字首和前導零；它不是記錄的 Salesforce ID。另見 Auto-Number Fields Are Not Always Sequential (opens in a new tab)（英文，查閱日期 2026-10-09）。