Từ điển, dòng dõi và phân loại
Cũng có bằng 28 ngôn ngữ khác
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Mô-đun 3 trong 6 của chương Chất lượng và quản trị dữ liệu, chương 5 của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Ngăn dữ liệu xấu · Tiếp theo: Luật quyền riêng tư định hình thiết kế
Câu hỏi mô-đun này trả lời: Làm sao ghi lại dữ liệu có nghĩa là gì, nó đến từ đâu, và nó nhạy cảm đến mức nào?
Bạn thừa kế một org. Tài khoản có 900 trường, trong đó có Customer_Type__c, Customer_Class__c, Customer_Category__c, Customer_Status__c, ERP_Status__c và Account_Status__c. Trường nào cho bạn biết một người có thực sự là khách hàng không? Bạn mở phần mô tả. Ba trường để trống. Một trường ghi “Customer Type”. Cảm ơn nhé. Một trường nói nó đến từ ERP; một trường khác được tạo sáu năm trước bởi một người đã rời đi từ lâu. Giờ hãy tưởng tượng bạn không phải kiến trúc sư mà là một tích hợp, một đội báo cáo, hay một tác tử. Tổ chức có rất nhiều dữ liệu. Điều đó không có nghĩa là nó biết dữ liệu có nghĩa là gì.
Đó là nơi siêu dữ liệu trở thành kiến trúc, qua ba câu hỏi liên quan đến nhau nhưng không giống nhau:
- Từ điển: dữ liệu này có nghĩa là gì?
- Dòng dõi: nó đến từ đâu?
- Phân loại: nó phải được đối xử thế nào?
Hai loại siêu dữ liệu
Phần tiêu đề “Hai loại siêu dữ liệu ”Siêu dữ liệu có hai loại, và bạn cần cả hai. Siêu dữ liệu nghiệp vụ là ý nghĩa của dữ liệu đối với doanh nghiệp: định nghĩa, chủ sở hữu, các quy tắc sử dụng, mức độ nhạy cảm. Siêu dữ liệu kỹ thuật là cách dữ liệu được xây dựng và di chuyển: đối tượng và trường, kiểu và độ dài, tên API, lược đồ, ánh xạ từ hệ thống này sang hệ thống khác, dòng dõi dữ liệu từ nguồn đến đích. Tên API và kiểu của một trường cho nhà phát triển biết cách dùng nó; định nghĩa và chủ sở hữu của nó cho mọi người khác biết có nên dùng hay không. Khi hai thứ này mâu thuẫn, hoặc thiếu một trong hai, đó là chỗ tích hợp và báo cáo đi sai.
Kiến thức hay ra thi. Hãy phân biệt siêu dữ liệu nghiệp vụ (ý nghĩa, định nghĩa, chủ sở hữu, quy tắc, mức độ nhạy cảm: từ điển nghiệp vụ và phân loại) với siêu dữ liệu kỹ thuật (đối tượng, trường, kiểu, tên API, lược đồ, ánh xạ và dòng dõi dữ liệu).
Bắt đầu từ ý nghĩa
Phần tiêu đề “Bắt đầu từ ý nghĩa ”Chương 3 đã đặt quy tắc: mỗi trường đều có mô tả. Không phải “Customer Status” cho một trường tên là Customer Status, mà là thứ gì đó như “Quan hệ thương mại hiện tại của đối tác với Steve Trucking. Được đặt từ ERP sau khi kích hoạt. Không dùng để đánh giá khách hàng tiềm năng.” Giờ tôi biết nó có nghĩa là gì, nó đến từ đâu và không nên dùng nó vào việc gì. Đó là khởi đầu của một từ điển nghiệp vụ: các định nghĩa chung cho những dữ liệu quan trọng. Khách hàng là gì? Khách hàng đang hoạt động là gì? Delivered có nghĩa là gì? Thế nào là đúng hẹn? Những câu này nghe hiển nhiên cho đến khi bạn đưa năm phòng ban vào một phòng: Tài chính có một định nghĩa, Kinh doanh có định nghĩa khác, Vận hành có định nghĩa thứ ba, kho dữ liệu có định nghĩa thứ tư, và ai đó đã xây một bảng điều khiển dựa trên định nghĩa thứ năm. Vấn đề không phải là không ai nói cùng một ngôn ngữ. Mà là doanh nghiệp chưa thống nhất về ý nghĩa.
Một từ điển có thể nằm trong một bảng tính hay một công cụ tài liệu, nhưng các định nghĩa quan trọng của nó cần nằm gần nơi người ta dùng dữ liệu. Trên nền tảng, đó là mô tả trường, văn bản trợ giúp và siêu dữ liệu phân loại. Trong phân tích, nó còn quan trọng hơn: “doanh thu” không thể có nghĩa này trên bảng điều khiển của lãnh đạo và nghĩa khác trong truy vấn của một nhà phân tích. Đó là việc của một tầng ngữ nghĩa, và các mô hình ngữ nghĩa của Data 360 giữ những định nghĩa được quản trị như chỉ số, chiều và quan hệ phía trên dữ liệu vật lý (Create a Semantic Model in Data 360 (opens in a new tab), tiếng Anh). Công nghệ thay đổi; yêu cầu thì không: dữ liệu quan trọng cần một ý nghĩa được thống nhất.
Và hãy bắt đầu từ ý nghĩa, không phải công nghệ. Một từ điển bắt đầu với đối tượng, trường, kiểu và tên API là tài liệu về phần hiện thực. Một từ điển bắt đầu với thuật ngữ nghiệp vụ là tài liệu về doanh nghiệp:
| Thuật ngữ nghiệp vụ | Ý nghĩa | Được biểu diễn ở đâu |
|---|---|---|
| Đối tác bán lẻ | Một nhà bán lẻ mà Steve Trucking giao hàng cho, theo hợp đồng | Tài khoản Salesforce; khách hàng trong ERP tài chính |
| Giao hàng | Một lần giao cho một Người nhận, tại một địa chỉ, trong một ngày | RouteDesk hiện nay; một lệnh công việc khi việc giao hàng chuyển vào Salesforce |
| Người nhận | Người nhận một lần giao hàng | Thông tin Người nhận trên lần giao hàng |
| Delivered | Hoàn tất theo định nghĩa vận hành đã thống nhất | Trạng thái giao hàng |
| Giao đúng hẹn | Hoàn tất trong khung giờ giao hàng đã thống nhất | Chỉ số suy ra |
Một ý nghĩa, nhiều cách biểu diễn kỹ thuật.
Rồi hỏi nó đến từ đâu
Phần tiêu đề “Rồi hỏi nó đến từ đâu ”Một khi biết một giá trị có nghĩa là gì, tôi muốn biết nó đến từ đâu. Đó là dòng dõi dữ liệu. Tên pháp lý của một đối tác trong Salesforce: một nhân viên kinh doanh gõ vào, ERP gửi đến, một tích hợp chuyển đổi nó, Data 360 hợp nhất nó, nó được tính toán, hay AI tạo ra nó? Những điều đó ảnh hưởng đến việc tôi tin nó đến đâu và được làm gì với nó. Hãy nhớ các bản ghi tạm thời của mô-đun 2: hai tài khoản có thể cùng ghi “Keystone”, một do nhân viên kinh doanh tạo hôm qua, một đến từ ERP với mã định danh có thẩm quyền. Cùng văn bản, khác dòng dõi, khác cách đối xử.
Dòng dõi dữ liệu không chỉ là sơ đồ một nghìn bảng của kỹ sư dữ liệu. Với dữ liệu quan trọng, tôi muốn trả lời những câu hỏi thực tế: nó bắt đầu từ đâu, hệ thống nào có thẩm quyền, cái gì đã chuyển đổi nó, hệ thống nào nhận bản sao, cái gì thay đổi nó lần cuối, và tôi có truy ngược được một giá trị suy ra về các nguồn của nó không? Bản đồ hệ thống của chương 4 cho biết các hệ thống được kết nối. Dòng dõi dữ liệu cho biết điều gì đã xảy ra với dữ liệu trên đường đi.
Một số dòng dõi có sẵn miễn phí: ID ERP trên tài khoản, Created By và Last Modified By, nhật ký tích hợp, tài liệu ánh xạ. Data 360 thêm các trường dòng dõi vào các đối tượng dữ liệu của nó để ghi lại nguồn dữ liệu và đối tượng nguồn cho mỗi bản ghi (Data Lineage Fields (opens in a new tab), tiếng Anh). Nhưng đừng giả định dòng dõi tự xuất hiện chỉ vì các hệ thống được tích hợp. Đôi khi dòng dõi hữu ích nhất là một trường: Source System = Keystone. Và nếu nguồn quan trọng với quản trị, hãy làm cho nó đáng tin cậy một cách máy móc, do tích hợp đặt, không phải do con người gõ.
Dữ liệu suy ra cần dòng dõi hơn cả. Giả sử Steve Trucking tính một rủi ro giao trễ từ vị trí xe tải, khung giờ giao hàng và lịch sử tuyến, và bộ phận điều phối dùng nó để ưu tiên. Mức “cao” đến từ đâu? Thêm một tác tử nói với Người nhận “lần giao hàng của bạn đang bị trễ”, và bạn cần biết điều gì đã làm cơ sở cho câu đó, và nó mới đến đâu. Càng đi xa khỏi giá trị được lưu để đến giá trị được tính toán, hợp nhất, dự đoán và tạo ra, dòng dõi dữ liệu càng quan trọng.
Phân loại trả lời một câu hỏi khác
Phần tiêu đề “Phân loại trả lời một câu hỏi khác ”Giờ đến: nó nên được đối xử thế nào? Tên Người nhận, địa chỉ giao hàng, số điện thoại, ghi chú giao hàng, trạng thái giao hàng, số xe tải, trung tâm phân phối, Đối tác bán lẻ, ảnh: chúng không nhạy cảm như nhau. “Đang đi giao” không phải là số điện thoại, và mã DC không phải là ảnh bên trong nhà của ai đó. Salesforce cho phép bạn ghi lại điều này trên mỗi trường, chuẩn hay tùy chỉnh: Data Owner, Field Usage, Data Sensitivity Level và Compliance Categorization (Data Classification Metadata Fields (opens in a new tab), tiếng Anh). Chương 3 gọi chúng là các trường phân loại, và đã nói vì sao chúng quan trọng: đánh dấu một trường là PII hay GDPR thì các quy trình có thể tìm thấy nó, từ công cụ che dữ liệu đến tầng tin cậy AI của Salesforce, vốn có thể ngăn các giá trị được đánh dấu đến được một mô hình ngôn ngữ lớn. Một lưu ý từ chương 3: Salesforce hiện tắt tính năng che dữ liệu cho LLM đó đối với các tác tử, vì nó có thể tước mất ngữ cảnh mà một tác tử cần (Phân loại những gì quan trọng: các trường phân loại). Vì vậy, việc phân loại vẫn phải điều khiển các biện pháp kiểm soát khác.
Lập trường của tôi ở đây là có chủ ý: phân loại các trường nhạy cảm, không phải mọi trường. Tôi không muốn ba tháng bỏ ra để phân loại hàng nghìn trường chỉ để ai đó báo cáo “100% đã phân loại” mà không ai dùng đến. Số điện thoại của Người nhận: có. Địa chỉ nhà: có. Ghi chú giao hàng có thể chứa mã cổng và “có chó trong sân”: có. Ảnh có thể cho thấy con người hay một ngôi nhà: chắc chắn rồi. Một nhãn hiển thị nội bộ? Không phải nơi nên dồn sức quản trị. Điều đó không có nghĩa các trường không có tài liệu là chấp nhận được. Hai công việc khác nhau: tài liệu hóa thì rộng; phân loại thì có chủ ý. Đó là điều giữ cho việc phân loại có ý nghĩa.
Một hệ phân loại người ta dùng được
Phần tiêu đề “Một hệ phân loại người ta dùng được ”Phân loại cần một bộ từ vựng, một hệ phân loại (taxonomy). Mặc định của Salesforce là Public, Internal, Confidential, Restricted và MissionCritical; tổ chức của bạn có thể muốn nhãn riêng. Tôi không quy định chúng. Hãy giữ chúng dễ hiểu: nếu có 47 hạng mục và không ai ngoài đội quyền riêng tư phân biệt được hạng mục 31 với 32, nó chẳng giúp được gì. Một hệ phân loại tốt nối một nhãn với hành vi. Nếu một trường là dữ liệu cá nhân nhạy cảm, ai được thấy nó, nó có được đưa vào sandbox không, có được rời khỏi vùng không, có xuất hiện trong phân tích không, nó được giữ bao lâu, tác tử có được dùng nó không? Giờ thì việc phân loại đang làm việc.
Phân loại mà không thực thi chỉ là trang trí
Phần tiêu đề “Phân loại mà không thực thi chỉ là trang trí ”Đánh dấu số điện thoại của Người nhận là nhạy cảm mà không thay đổi gì khác, và bạn đã viết tài liệu. Có ích, nhưng quản trị đi xa hơn: phân loại nên điều khiển quyền, che dữ liệu, mã hóa, lưu giữ, sự đồng ý, di chuyển dữ liệu, sử dụng sandbox, kiểm toán và quyền truy cập của AI. Một phần trong đó là quyết định thiết kế của kiến trúc sư; một số nền tảng giờ áp dụng thẻ và phân loại trực tiếp trong chính sách, như cơ chế quản trị của Data 360 (Data Governance in Data 360 (opens in a new tab), tiếng Anh). Và đánh dấu một trường là Restricted không ngăn được ai đọc nó. Phân loại nói một trường nên được đối xử thế nào; bảo mật làm cho điều đó thành sự thật. Trình tự là: xác định dữ liệu, hiểu nó, phân loại những gì quan trọng, rồi áp dụng các biện pháp kiểm soát mà phân loại đó đòi hỏi.
Ba câu hỏi về dữ liệu của bạn, và câu thứ ba phải điều khiển một điều gì đó.
Dữ liệu tham chiếu cũng cần siêu dữ liệu
Phần tiêu đề “Dữ liệu tham chiếu cũng cần siêu dữ liệu ”Mã quốc gia, trạng thái giao hàng, mã DC, mã định danh đối tác, lý do hủy: chúng trông đơn giản cho đến khi hai hệ thống bất đồng. Một hệ thống nói CANCELLED, hệ thống khác CANCELED, hệ thống thứ ba CNCL, hệ thống thứ tư 9. Dữ liệu tham chiếu cần định nghĩa, chủ sở hữu, nguồn, vòng đời khi giá trị thay đổi, và ánh xạ khi các hệ thống biểu diễn nó khác nhau. Những giá trị nhỏ có thể điều khiển những quy trình rất lớn. Chương 6 đi xa hơn.
Cả ba cùng nhau
Phần tiêu đề “Cả ba cùng nhau ”Lấy số điện thoại Người nhận. Từ điển: số dùng để liên lạc với người nhận một lần giao hàng cụ thể. Dòng dõi: từ bảng kê hàng của Đối tác bán lẻ. Phân loại: dữ liệu cá nhân. Giờ các câu hỏi kiến trúc trở nên khả thi: tổ giao hàng có được thấy nó không, và trong bao lâu (bản mô tả nói chỉ cho các điểm dừng của chính họ, chỉ trong ngày); nó có được đưa vào sandbox không; Snowflake có cần nó không; tác tử có được dùng nó không; chuyện gì xảy ra khi lần giao hàng hoàn tất?
Giờ lấy trạng thái giao hàng. Từ điển: trạng thái vận hành hiện tại của lần giao hàng. Dòng dõi: được đặt bởi quy trình giao hàng của Steve Trucking và gửi lại cho từng đối tác qua tích hợp riêng. Phân loại: vận hành, không nhạy cảm. Dữ liệu khác, cách đối xử khác. Đó chính là điểm mấu chốt.
Tôi không coi siêu dữ liệu là tài liệu được tạo ra sau khi kiến trúc thực sự đã xong. Nếu tôi không nói được một trường có nghĩa là gì, tôi không hiểu mô hình dữ liệu. Nếu tôi không biết một giá trị đến từ đâu, tôi không hiểu các tích hợp. Nếu tôi không biết nó có nhạy cảm không, tôi không hiểu bảo mật. Siêu dữ liệu mô tả kiến trúc, và đôi khi điều khiển nó.
Ngoài kỳ thi: AI thay đổi điều gì. Phân loại đang trở thành công tắc cho những gì một tác tử được truy xuất hay nhắc lại, và dòng dõi dữ liệu phải vươn tới tận câu trả lời hay hành động của tác tử. Nếu một tác tử nói với Người nhận rằng lần giao hàng bị trễ, kiến trúc phải nói được điều gì làm cơ sở cho câu đó, nó đến từ đâu, và tác tử có được phép dùng nó không. “Đâu đó trong Salesforce” không phải là dòng dõi, và “dữ liệu khách hàng” không phải là một phân loại.
Kiến trúc sư quyết định gì ở đây
Phần tiêu đề “Kiến trúc sư quyết định gì ở đây ”- Những thuật ngữ nghiệp vụ nào cần định nghĩa được quản trị, để các hệ thống và đội ngũ không gán cho một từ nhiều nghĩa khác nhau.
- Các giá trị quan trọng giữ đủ dòng dõi thế nào để cho thấy nguồn, thẩm quyền và các phép chuyển đổi của chúng.
- Những trường nào mang ý nghĩa về độ nhạy cảm hay tuân thủ và vì thế được phân loại rõ ràng.
- Tổ chức dùng hệ phân loại nào, và người ta có áp dụng nó nhất quán được không.
- Phân loại điều khiển các biện pháp kiểm soát thực sự thế nào thay vì nằm yên không dùng đến.
Trước khi quản trị dữ liệu, hãy biết bạn có gì: nó có nghĩa là gì, nó đến từ đâu, nó phải được đối xử thế nào. Tài liệu hóa rộng rãi, phân loại có chủ ý, giữ dòng dõi ở nơi quan trọng. Nếu không, bạn không quản trị dữ liệu. Bạn chỉ đang có nó.
Tìm hiểu thêm
Phần tiêu đề “Tìm hiểu thêm ”- Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (tiếng Anh), kiểm tra ngày 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) và Create a Semantic Model in Data 360 (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.