詞典、血緣與分類
另有 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 課程第 5 章資料品質與治理。每個模組都可以單獨閱讀。 上一篇：把壞資料擋在門外 · 下一篇：隱私法塑造設計
**本模組回答的問題：**如何記錄資料意味著什麼、從哪裡來、有多敏感？
你接手了一個 org。客戶物件有 900 個欄位，其中有 Customer_Type__c、Customer_Class__c、Customer_Category__c、Customer_Status__c、ERP_Status__c 和 Account_Status__c。哪一個能告訴你某人是否真的是客戶？你開啟描述。三個是空的。一個寫著「Customer Type」。謝謝。一個說它來自 ERP；另一個是六年前由一個早已離開的人建立的。現在想像你不是架構師，而是一個整合、一個報表團隊，或者一個代理程式。組織擁有大量資料，但這並不意味著它知道這些資料意味著什麼。
這就是後設資料變成架構的地方，通過三個相關但不相同的問題：
- **詞典：**這份資料意味著什麼？
- **血緣：**它從哪裡來？
- **分類：**必須如何對待它？
兩種後設資料
Section titled “兩種後設資料 ”後設資料分兩種，兩種你都需要。業務後設資料是資料對業務意味著什麼：定義、所有者、使用規則、敏感程度。技術後設資料是資料如何構建、如何流動：物件和欄位、類型和長度、API 名稱、模式（schema）、從一個系統到另一個系統的對映、從來源到目標的血緣。一個欄位的 API 名稱和類型告訴開發人員如何使用它；它的定義和所有者告訴其他所有人是否應該使用它。當兩者不一致，或者缺了其中一個，整合和報表就會在那裡出錯。
考點。區分業務後設資料（含義、定義、所有者、規則、敏感性：即業務詞典和分類）和技術後設資料（物件、欄位、類型、API 名稱、模式、對映和血緣）。
從含義開始
Section titled “從含義開始 ”第 3 章定下了規則：每個欄位都要有描述。不是給一個叫 Customer Status 的欄位寫「Customer Status」，而是寫成類似這樣：*「合作夥伴與 Steve Trucking 當前的商業關係。啟用後由 ERP 設定。不要用於潛在客戶的資格認定。」*現在我知道了它的含義、它從哪裡來，以及不應該把它用於什麼。這就是業務詞典的開端：對重要資料的共同定義。什麼是客戶？什麼是活躍客戶？已送達是什麼意思？什麼算準時？這些聽起來理所當然，直到你把五個部門放進一個會議室：財務有一個定義，銷售有另一個，運營有第三個，資料倉儲有第四個，而有人在第五個定義上建了一個儀表板。問題不是沒人會說英語，而是企業還沒有就含義達成一致。
詞典可以放在電子表格或文件工具裡，但其中重要的定義需要貼近人們使用資料的地方。在平台上，那就是欄位描述、幫助文字和分類後設資料。在分析中這一點更為重要：「收入」不能在高管儀表板上是一個意思，在分析師的查詢裡又是另一個意思。這正是語義層的用途，而 Data 360 的語義模型在物理資料之上儲存受治理的定義，比如指標、維度和關係（Create a Semantic Model in Data 360 (opens in a new tab)，英文）。技術會變；需求不變：重要的資料需要一個達成一致的含義。
而且要從含義開始，而不是從技術開始。一份從物件、欄位、類型和 API 名稱開始的詞典，記錄的是實現。一份從業務術語開始的詞典，記錄的是企業：
| 業務術語 | 含義 | 在哪裡體現 |
|---|---|---|
| 零售合作夥伴 | Steve Trucking 根據合同為之配送的零售商 | Salesforce 客戶；財務 ERP 客戶 |
| 配送 | 在某一天、向某一個地址的某一位收貨人進行的一次配送 | 目前在 RouteDesk 中；配送遷入 Salesforce 後為工作訂單 |
| 收貨人 | 接收配送的人 | 配送上的收貨人詳情 |
| 已送達 | 按照約定的運營定義完成 | 配送狀態 |
| 準時配送 | 在約定的配送時間視窗內完成 | 推匯出來的指標 |
一個含義，多種技術表示。
然後問它從哪裡來
Section titled “然後問它從哪裡來 ”一旦知道了一個值的含義，我就想知道**它從哪裡來。**這就是血緣。Salesforce 中一個合作夥伴的法定名稱：是銷售代表輸入的，是 ERP 發來的，是某個整合轉換過的，是 Data 360 統一過的，是計算出來的，還是 AI 生成的？這些會影響我有多信任它，以及我可以用它做什麼。還記得模組 2 的臨時記錄嗎：兩個客戶可能都叫「Keystone」，一個是銷售代表昨天建立的，另一個來自 ERP，帶有權威識別符號。同樣的文字，不同的血緣，不同的對待方式。
血緣不只是資料工程師畫的一張上千張表的圖。對於重要的資料，我想回答一些實際的問題：它從哪裡開始，哪個系統是權威的，什麼轉換了它，哪些系統拿到了副本，最後是什麼修改了它，以及我能否把一個推匯出來的值追溯到它的來源？第 4 章的全景圖說明系統是相連的。血緣說明資料在途中經歷了什麼。
有些血緣是免費得來的：客戶上的 ERP ID，建立人和上次修改人，整合日誌，對映文件。Data 360 會在它的資料物件上加上血緣欄位，記錄每條記錄的資料來源和源物件（Data Lineage Fields (opens in a new tab)，英文）。但不要以為系統集成了，血緣就會自動出現。有時最有用的血緣就是一個欄位：**來源系統 = Keystone。**而如果來源對治理很重要，就讓它在機制上可靠，由整合來設定，而不是由人來輸入。
推匯出來的資料最需要血緣。假設 Steve Trucking 根據卡車位置、配送時間視窗和路線歷史算出一個延誤風險，排程用它來排定優先順序。「高」是從哪裡來的？再加上一個告訴收貨人「您的配送將會延誤」的代理程式，你就需要知道是什麼為這句話提供了依據，以及它有多新。你離儲存的值越遠，越走向計算的、統一的、預測的和生成的值，血緣就越重要。
分類回答的是另一個問題
Section titled “分類回答的是另一個問題 ”現在是：**應該如何對待它？**收貨人姓名、配送地址、電話號碼、配送備註、配送狀態、卡車編號、配送中心、零售合作夥伴、照片：它們的敏感程度並不相同。「配送中」不是一個電話號碼，一個配送中心程式碼也不是一張某人家裡的照片。Salesforce 讓你在每個欄位上記錄這些，無論是標準欄位還是自訂欄位：Data Owner、Field Usage、Data Sensitivity Level 和 Compliance Categorization（Data Classification Metadata Fields (opens in a new tab)，英文）。第 3 章把它們叫作分類欄位，也講了它們為什麼重要：把一個欄位標記為 PII 或 GDPR，各種流程就能找到它，從遮罩工具到 Salesforce 的 AI 信任層（trust layer），後者可以阻止被標記的值到達大語言模型。第 3 章還有一個提醒：Salesforce 現在對代理程式停用了這種 LLM 遮罩，因為它可能會去掉代理程式需要的上下文（給重要的東西分類：分類欄位）。所以分類仍然必須驅動其他控制措施。
我在這裡的立場是有意為之的：**給敏感欄位分類，而不是每個欄位。**我不希望花三個月時間給成千上萬個欄位分類，只為了讓某人報告「100% 已分類」，然後沒人用它。收貨人的電話號碼：是。家庭住址：是。可能包含門禁密碼和「院子裡有狗」的配送備註：是。可能拍到人或住宅的照片：絕對是。一個內部顯示標籤？那不是治理精力應該花的地方。這並不意味著沒有文件的欄位就可以接受。這是兩份不同的工作：**文件要廣泛；分類要有選擇。**正是這一點讓分類保持有意義。
一套人們用得起來的分類體系
Section titled “一套人們用得起來的分類體系 ”分類需要一套詞彙，即分類體系。Salesforce 的預設值依次是 Public、Internal、Confidential、Restricted 和 MissionCritical；你的組織也許想要自己的標籤。我不做規定。只要讓它們容易理解：如果有 47 個類別，而隱私團隊之外沒人能分清第 31 類和第 32 類，它就幫不上忙。一套好的分類體系會把一個標籤和行為聯絡起來。如果一個欄位是敏感的個人資料，誰能看到它，它能否進入沙箱，能否離開所在區域，能否出現在分析中，保留多久，代理程式能否使用它？這時，分類就在發揮作用了。
沒有執行的分類只是裝飾
Section titled “沒有執行的分類只是裝飾 ”把收貨人的電話號碼標記為敏感，別的什麼都不改，你寫的就只是文件。有用，但治理要走得更遠：分類應該驅動權限、遮罩、加密、保留、同意、資料流動、沙箱使用、稽核和 AI 存取。其中有些是架構師的設計決定；有些平台現在會直接在策略中應用標籤和分類，Data 360 的治理就是這樣（Data Governance in Data 360 (opens in a new tab)，英文）。而把一個欄位標記為 Restricted，並不會阻止任何人讀取它。分類說明一個欄位應該如何被對待；安全讓它成真。順序是：識別資料，理解資料，給重要的東西分類，然後施加分類所要求的控制。
關於你的資料的三個問題，而第三個必須驅動點什麼。
參考資料也需要後設資料
Section titled “參考資料也需要後設資料 ”國家程式碼、配送狀態、配送中心程式碼、合作夥伴識別符號、取消原因：它們看起來很簡單，直到兩個系統意見不一。一個說 CANCELLED，另一個說 CANCELED，第三個說 CNCL，第四個說 9。參考資料需要定義、一個所有者、一個來源、值會變化時的生命週期，以及系統表示方式不同時的對映。小小的值可以驅動非常大的流程。第 6 章會更進一步。
三者合在一起
Section titled “三者合在一起 ”拿收貨人電話號碼來說。詞典：用來聯絡某次配送的收貨人的號碼。血緣：來自零售合作夥伴的裝貨清單。分類：個人資料。現在，架構問題就可以問了：配送小組可以看到它嗎，能看多久（簡介裡說只能在當天、只為自己的停靠點）；它能進入沙箱嗎；Snowflake 需要它嗎；代理程式可以使用它嗎；配送完成後會怎樣？
再看**配送狀態。**詞典：配送當前的運營狀態。血緣：由 Steve Trucking 的配送流程設定，並通過各自的整合回傳給每個合作夥伴。分類：運營資料，不敏感。不同的資料，不同的對待方式。這就是重點。
我不把後設資料當作在真正的架構完成之後才產出的文件。如果我說不出一個欄位的含義，我就不理解資料模型。如果我不知道一個值從哪裡來，我就不理解整合。如果我不知道它是否敏感，我就不理解安全。後設資料描述架構，有時還驅動架構。
**考試之外：AI 改變了什麼。**分類正在變成決定代理程式可以檢索或複述什麼的開關，而血緣必須一直延伸到代理程式的回答或行動。如果一個代理程式告訴收貨人配送會延誤，架構應該能說出是什麼為它提供了依據，它從哪裡來，以及代理程式是否被允許使用它。「Salesforce 裡的某個地方」不是血緣，「客戶資料」也不是一種分類。
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”- 哪些業務術語需要受治理的定義，這樣各個系統和團隊就不會給同一個詞賦予不同的含義。
- 重要的值如何保留足夠的血緣，以顯示它們的來源、權威性和轉換過程。
- 哪些欄位帶有敏感性或合規含義，因此需要明確的分類。
- 組織使用哪套分類體系，以及人們能否一致地應用它。
- 分類如何驅動真正的控制措施，而不是被閒置在那裡。
在治理資料之前，先知道你擁有什麼：它意味著什麼，從哪裡來，必須如何對待。廣泛地寫文件，有選擇地分類，在重要的地方保留血緣。否則你並沒有在治理資料。你只是擁有它。
- Salesforce Help，Data Classification Metadata Fields (opens in a new tab)（英文），查閱日期 2026-10-14。
- Salesforce Help，Data 360：Data Lineage Fields (opens in a new tab)、Data Governance in Data 360 (opens in a new tab) 和 Create a Semantic Model in Data 360 (opens in a new tab)（英文），查閱日期 2026-10-14。