Chất lượng và quản trị dữ liệu

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)

An open sketchbook on a drafting table at dawn, a building sketched on one page and a data model on the other, with a pencil, an eraser, a cup and a lamp. — Hình ảnh được tạo bằng AI

Hướng dẫn ôn tập cho chương 5 của khóa học Data Architect. Hãy đọc sáu mô-đun trước; trang này giúp bạn kiểm tra những gì đã đọng lại.

Về hướng dẫn ôn tập này. Nó chỉ được xây dựng từ nội dung của chính khóa học này và danh sách mục tiêu trong hướng dẫn thi đã công bố của Salesforce. Nó không bao giờ dựa trên câu hỏi thi thật, và không tự nhận biết trong đề thi có gì. Nếu bạn đã thi, xin đừng gửi cho tôi câu hỏi trong đề: thỏa thuận chứng chỉ cấm chia sẻ chúng, và dù sao học thuộc đáp án cũng là cách sai để trở thành kiến trúc sư.

Chương này gánh phần Data Governance của kỳ thi (10%) cùng một phần của Data Modeling (siêu dữ liệu) và Salesforce Data Management (nhất quán). Đây cũng là nơi luật quyền riêng tư gặp mô hình dữ liệu. Đây là kiến trúc, không phải tư vấn pháp lý: Pháp chế quyết định điều gì áp dụng, và kiến trúc sư làm cho nó thực thi được. Các con số của nền tảng thay đổi, nên hãy kiểm tra con số hiện hành trước khi dựa vào chúng.

Cho kỳ thi

Hãy đánh dấu khi bạn đi qua. Mỗi điểm liên kết đến nơi được giảng dạy.

GOV-2: thiết kế một chương trình quản trị

Tôi biết chủ sở hữu bản ghi (một cơ chế truy cập của nền tảng) không phải là chủ sở hữu dữ liệu (chịu trách nhiệm giải trình về dữ liệu như một tài sản nghiệp vụ), và mỗi trường có thể ghi lại một Data Owner. (Chủ sở hữu bản ghi không phải là chủ sở hữu dữ liệu)
Tôi phân biệt được chủ sở hữu dữ liệu (đặt chính sách), người quản lý dữ liệu (giữ cho nó vận hành) và người vận hành (chạy hệ thống). (Chủ sở hữu, người quản lý dữ liệu, người vận hành)
Kiến thức hay ra thi: Tôi biết ba cách vận hành một chương trình quản trị, tập trung, liên kết (phi tập trung) và kết hợp, và mỗi cách có ý nghĩa gì với việc ai đặt chính sách và các định nghĩa dùng chung nằm ở đâu. (Chương trình vận hành ra sao)
Tôi dùng được một RACI để trả lời dữ liệu được tạo, sửa và tham chiếu ở đâu. (Hãy để RACI xứng đáng với chỗ của nó)
Tôi nêu được một điểm thực thi cho một chính sách quản trị (quyền, quy tắc xác thực, trường chỉ tích hợp ghi, lịch sử trường), không chỉ là đào tạo. (Quản trị phải trở nên máy móc)
Tôi biết những tín hiệu chất lượng đáng đo là những tín hiệu có người sẽ hành động. (Đo những gì có người sẽ hành động)

SDM-2 và MDM-4: ngăn dữ liệu xấu

Tôi quyết định được việc tạo tài khoản nên mở hay khóa, và tôi biết con đường loại bản ghi tạm thời cho tài khoản được quản lý chủ trong ERP. (Mở hay khóa?, Con đường ở giữa)
Tôi bảo vệ được các thuộc tính được quản trị (một ID ERP, một tên pháp lý) trong khi vẫn để các trường riêng của Salesforce sửa được: một bản ghi vàng kết hợp. Và tôi biết một trường chỉ đọc trên một trang Dynamic Forms không phải là sự thực thi; bảo mật cấp trường hoặc một quy tắc xác thực mới là. (Bảo vệ bản ghi được quản trị, Mỗi luồng một loại bản ghi)
Tôi biết các luồng hai chiều là khó nhất: nếu ERP quản lý chủ một trường, Salesforce đang yêu cầu thay đổi nó, và một xung đột cần có quy tắc (ERP thắng, từ chối nếu đã thay đổi, hoặc một người giải quyết). (Bảo vệ bản ghi được quản trị)
Tôi biết trường bắt buộc có thể tạo ra dữ liệu giả (N/A, 999999), và các giải pháp thay thế. (Đừng để trường bắt buộc tạo ra dữ liệu giả)
Tôi quyết định được chuyện gì xảy ra với dữ liệu đầu vào không qua được kiểm tra: chấp nhận, từ chối hay cách ly, và ai sở hữu ngoại lệ. (Mỗi ranh giới dữ liệu cần một quyết định chất lượng)
Tôi biết dữ liệu tham chiếu cũng cần siêu dữ liệu: định nghĩa, chủ sở hữu, nguồn và ánh xạ giữa các hệ thống. (Dữ liệu tham chiếu cũng cần siêu dữ liệu)

DM-3: siêu dữ liệu nghiệp vụ và kỹ thuật

Kiến thức hay ra thi: Tôi phân biệt được 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) với siêu dữ liệu kỹ thuật (đối tượng, trường, kiểu, tên API, lược đồ, ánh xạ, dòng dõi dữ liệu). (Hai loại siêu dữ liệu)
Tôi biết sự khác biệt giữa từ điển nghiệp vụ (nó có nghĩa là gì), dòng dõi dữ liệu (nó đến từ đâu) và phân loại (nó phải được đối xử thế nào). (Hiểu dữ liệu của bạn)
Tôi biết các trường phân loại của Salesforce: Data Owner, Field Usage, Data Sensitivity Level, Compliance Categorization, trên trường chuẩn và tùy chỉnh. (Phân loại trả lời một câu hỏi khác)
Tôi biết nên phân loại các trường nhạy cảm, không phải mọi trường, và phân loại mà không thực thi chỉ là trang trí. (Phân loại mà không thực thi chỉ là trang trí)

GOV-1: dữ liệu cá nhân và nhạy cảm

Ngoài kỳ thi

Kỳ thi là sàn, không phải trần. Đây là những thói quen từ chương này mà một kiến trúc sư cần, dù có câu hỏi nào hỏi về chúng hay không.

Một chính sách không có điểm thực thi phần lớn chỉ là một mong ước.
Chủ sở hữu đặt chính sách; kiến trúc sư thực thi nó. Đừng tự bịa ra chính sách, và đừng đóng vai luật sư.
Quản trị không bao giờ kết thúc. Nó lúc lên lúc xuống; hãy thiết kế cơ chế phản hồi.
Đừng dựa vào hành vi tốt. Hãy xây biện pháp kiểm soát: con người, tích hợp và tác tử đều mắc lỗi.
Quản trị vừa đủ, không phải mọi thứ.
Ngăn những lỗi đắt giá trước. Một bản trùng có hai năm lịch sử là một vấn đề lớn.
Phân biệt những gì con người đọc với những gì máy móc dựa vào để quyết định.
Tài liệu hóa rộng rãi; phân loại có chủ ý.
Dữ liệu nhạy cảm rẻ nhất để quản trị là dữ liệu bạn chưa bao giờ sao chép.
Sự đồng ý là dữ liệu, và sự cho phép dùng dữ liệu phải biểu diễn được dưới dạng dữ liệu.
Hãy kiểm soát dữ liệu cá nhân đi đâu trước, vì việc xóa hiếm và khó.
Tuân thủ không phải là một sản phẩm.
Thu nhận → Phân loại → Bảo vệ → Sử dụng → Lưu giữ → Xóa → Kiểm toán.
Hãy thu thập bằng chứng trước khi có ai yêu cầu.

Thuật ngữ cần biết

Thuật ngữ	Trong một dòng
Quản trị dữ liệu	Các chính sách về dữ liệu, và kiến trúc làm cho chúng thành sự thật
Chủ sở hữu dữ liệu	Người hay bộ phận chịu trách nhiệm giải trình về một loại dữ liệu
Người quản lý dữ liệu	Người giữ cho dữ liệu khỏe mạnh hằng ngày
Người vận hành (custodian)	Đội vận hành các hệ thống chứa dữ liệu
RACI	Thực hiện, Chịu trách nhiệm giải trình, Được tham vấn, Được thông báo
Bản ghi tạm thời	Một bản ghi được tạo trước khi hệ thống có thẩm quyền chấp nhận nó
Từ điển nghiệp vụ	Các định nghĩa đã thống nhất về những thuật ngữ quan trọng của doanh nghiệp
Dòng dõi dữ liệu	Một giá trị đến từ đâu và điều gì đã xảy ra với nó trên đường đi
Phân loại dữ liệu	Gắn nhãn dữ liệu theo độ nhạy cảm và loại tuân thủ để nó nhận đúng biện pháp kiểm soát
Hệ phân loại	Bộ nhãn mà một tổ chức dùng để phân loại dữ liệu
Dữ liệu cá nhân	Thông tin nhận diện một người, hoặc có thể liên kết ngược về một người
Giả danh hóa	Thay thế mã định danh trong khi vẫn còn đường quay lại; vẫn là dữ liệu cá nhân
Ẩn danh hóa	Xóa bỏ khả năng hợp lý để nhận diện người đó
Mô hình dữ liệu đồng ý	Các đối tượng của Salesforce cho sự đồng ý theo người, kênh, điểm liên lạc và mục đích
Quyền được lãng quên	Quyền của một người, nơi luật quy định, được xóa dữ liệu cá nhân của mình
Bản ghi vàng kết hợp	Một bản ghi chứa các trường của hệ thống chủ và các trường riêng của Salesforce, mỗi loại có một nguồn
Siêu dữ liệu nghiệp vụ / kỹ thuật	Dữ liệu có nghĩa là gì và ai sở hữu nó / nó được xây dựng và di chuyển thế nào
Field Audit Trail	Lịch sử trường dài hơn: tối đa 200 trường mỗi đối tượng, giữ cho đến khi bị xóa
Event Monitoring	Nhật ký đăng nhập, xuất dữ liệu, lệnh gọi API và lượt xem, giữ trong thời gian giới hạn
SIEM	Một kho bảo mật nơi nhật ký sự kiện được lưu giữ và phân tích

Tự kiểm tra

Những tình huống ngắn theo phong cách của khóa học. Hãy quyết định câu trả lời trước khi mở ra.

1. Chính sách nói chỉ bộ phận Tài chính được thay đổi tên pháp lý của khách hàng. Đội dự định xử lý bằng đào tạo. Thiếu gì?

Một điểm thực thi. Đào tạo không phải là biện pháp kiểm soát: hãy dùng quyền truy cập cấp trường, một trường chỉ tích hợp được ghi, một quy tắc xác thực, hoặc một quy trình có kiểm soát. Chủ sở hữu đặt chính sách; kiến trúc sư làm cho nó đúng một cách máy móc. Đọc lại Quản trị phải trở nên máy móc.

2. Khách hàng được quản lý chủ trong ERP. Nhân viên kinh doanh cần bắt đầu bán cho khách hàng tiềm năng mới ngay. Làm sao để họ làm được, mà không có hai hệ thống cùng tạo bản ghi chủ?

Cho nhân viên kinh doanh tạo tài khoản dưới loại bản ghi tạm thời, rồi chuyển đổi nó qua một quy trình có kiểm soát: Tài chính phê duyệt, hoặc tích hợp gửi nó đến ERP, nơi khớp hoặc tạo khách hàng và gửi lại ID có thẩm quyền. Đọc lại Con đường ở giữa.

3. Một trường bắt buộc mới đầy “N/A” và “999999”. Chuyện gì đã xảy ra, và bạn sẽ làm gì thay thế?

Người dùng bị buộc phải trả lời trước khi họ biết. Hãy bắt buộc nó muộn hơn trong quy trình, để một hệ thống khác cung cấp nó, dùng trạng thái tạm thời, hoặc cho phép một giá trị Unknown rõ ràng khi đó là một câu trả lời thật. Đọc lại Đừng để trường bắt buộc tạo ra dữ liệu giả.

4. Đội đã thay tên bằng các mã token và nói dữ liệu đã được ẩn danh hóa, nên yêu cầu xóa đã xong. Đúng không?

Không, nếu các token có thể được liên kết ngược về người đó: đó là giả danh hóa, và dữ liệu vẫn là dữ liệu cá nhân. Hãy nói chính xác hệ thống làm gì, bảng ánh xạ nằm ở đâu, và để Pháp chế quyết định nó có thỏa mãn yêu cầu không. Đọc lại Ẩn danh hóa, giả danh hóa, mã hóa, che dữ liệu.

5. Một Người nhận đồng ý nhận tin nhắn về giao hàng nhưng không nhận marketing. Mô hình nên giữ điều đó thế nào?

Bằng mô hình dữ liệu đồng ý, không phải một ô đánh dấu: người đó, kênh (SMS), số điện thoại cụ thể, và mục đích sử dụng dữ liệu (thông báo giao hàng, không phải marketing). Và quyết định hệ thống nào có thẩm quyền đối với sự đồng ý để việc rút lại đến được mọi hệ thống hành động dựa trên nó. Đọc lại Dùng mô hình Salesforce đã xây sẵn.

6. Bộ phận tuân thủ cần lọc báo cáo theo một trường số An sinh xã hội được mã hóa. Trường đó dùng cơ chế mã hóa mặc định. Vấn đề là gì?

Mã hóa xác suất không cho phép lọc trong mệnh đề SOQL WHERE hay bộ lọc quản lý dữ liệu. Mã hóa tất định cho phép lọc với một chút hy sinh về độ mạnh. Mã hóa là một quyết định thiết kế có đánh đổi, không phải một ô đánh dấu ở cuối cùng. Đọc lại Mã hóa là một biện pháp kiểm soát, không phải là tuân thủ.

7. Sáu tháng sau một sự cố, ai đó hỏi ai đã xuất một tập bản ghi. Không ai thiết lập nơi lưu trữ cho Event Monitoring. Bạn có thể nói gì với họ?

Có lẽ không gì cả: nhật ký sự kiện được giữ trong thời gian giới hạn (tối đa một năm, kể cả khi kéo dài), nên bất cứ thứ gì cũ hơn đều đã mất trừ khi đã được xuất ra. Hãy thiết lập Event Monitoring và gửi sự kiện đến một SIEM trước khi bạn cần. Đọc lại Kiểm toán và giám sát không giống nhau.

8. Một nhân viên kinh doanh yêu cầu Salesforce đổi tên pháp lý của một khách hàng, trường mà ERP quản lý chủ. Trong cùng mấy phút đó, có người đổi nó trong ERP. Thiết kế nên nói gì?

Rằng Salesforce đang yêu cầu, không phải đang thay đổi: ERP quản lý chủ trường đó. Hãy quyết định trước quy tắc xử lý xung đột (ERP thắng, từ chối nếu giá trị đã thay đổi, hoặc một người giải quyết) và liệu các trường liên quan có đi cùng nhau không. Đọc lại Bảo vệ bản ghi được quản trị.

9. Yêu cầu xóa dữ liệu của một người đến. Đội dự định bắt đầu lập bản đồ nơi dữ liệu của họ nằm. Vấn đề là gì?

Đồng hồ đã bắt đầu chạy: theo GDPR là một tháng, có thể gia hạn thêm hai tháng cho các yêu cầu phức tạp. Bản đồ các bản sao phải có sẵn trước khi yêu cầu đến. Đọc lại Đồng hồ đang chạy.

Tìm hiểu thêm

Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (tiếng Anh, kiểm tra ngày 2026-09-25): danh sách chính thức các mục tiêu và trọng số của chúng. Luôn kiểm tra phiên bản hiện hành trước khi đăng ký thi.
Phần Tìm hiểu thêm của mỗi mô-đun liệt kê tài liệu Salesforce và các luật đứng sau các sự thật của nó, kèm ngày kiểm tra.