Dữ liệu chủ và danh tính
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)
Hướng dẫn ôn tập cho chương 6 của khóa học Data Architect. Hãy đọc sáu mô-đun trước, bao gồm phần hướng dẫn giải Điểm kiểm tra 1; 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 Master Data Management của kỳ thi (5%) và cái nhìn duy nhất về khách hàng từ phần Salesforce Data Management. Xét theo trọng số thì đây là một phần nhỏ, nhưng các ý tưởng của nó (thẩm quyền, khớp, quy tắc giữ lại) xuất hiện bên trong rất nhiều tình huống khá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
Phần tiêu đề “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.
MDM-2: bản ghi vàng và hệ thống sự thật
- Tôi biết thẩm quyền được giao theo từng thuộc tính, không theo từng bản ghi: một tài khoản có thể có các trường được quản lý chủ trong ERP và các trường được quản lý chủ trong Salesforce. (Sự thật thuộc về một thuộc tính)
- Tôi hỏi mỗi thuộc tính được tạo, sửa và tham chiếu ở đâu, và độ trễ thay đổi của nó. (Được tạo, được sửa, được tham chiếu, và nhanh đến đâu?)
- Tôi xây được một bản đồ thẩm quyền, và tôi biết chủ sở hữu nghiệp vụ và hệ thống có thẩm quyền không phải là một. (Xây một bản đồ thẩm quyền)
- Tôi biết thẩm quyền có thể thay đổi theo vòng đời (một khách hàng tiềm năng trong Salesforce trở thành khách hàng được ERP quản trị), và một bản sao không phải là thẩm quyền. (Thẩm quyền thay đổi theo vòng đời, Một bản sao không phải là thẩm quyền)
MDM-1: các kỹ thuật MDM
- Kiến thức hay ra thi: Tôi biết bốn kiểu triển khai MDM, registry, hợp nhất, cùng tồn tại và tập trung: mỗi kiểu tập trung cái gì và có đẩy giá trị ngược lại hay không. (Bốn kiểu đặt cạnh nhau)
- Tôi phân biệt được bốn kiểu MDM: registry, hợp nhất, cùng tồn tại và tập trung, và chọn kiểu nhẹ nhất giải quyết được bài toán. (Bốn kiểu đặt cạnh nhau)
- Tôi biết một mô hình dữ liệu chuẩn tắc hài hòa hóa cấu trúc, nhưng không quyết định thẩm quyền. (Một mô hình chung không phải là một sự thật chung)
- Tôi biết thứ tự: hài hòa hóa, rồi khớp, rồi hợp nhất. (Hài hòa hóa, rồi khớp, rồi hợp nhất)
- Tôi biết ngưỡng phản ánh mức chịu đựng sai sót, và làm giàu dữ liệu cần nguồn gốc. (Ngưỡng, xem xét và làm giàu dữ liệu)
- Kiến thức hay ra thi: Tôi biết quản lý phân cấp: Parent Account xây dựng phân cấp (giao diện Lightning hiển thị tối đa 2.000 tài khoản, không có tài khoản cá nhân), phân cấp thường được quản lý chủ chia tách, và một công ty có thể có nhiều phân cấp hợp lệ. (Phân cấp cũng là dữ liệu chủ, Một phân cấp, nhiều bên quản lý chủ)
MDM-3: chọn các thuộc tính thắng
- Tôi tách bạch khớp, gộp và giữ lại. (Khớp, gộp và giữ lại)
- Tôi biết các quy tắc giữ lại: mới nhất, phổ biến nhất, ưu tiên nguồn, và mỗi quy tắc cần một chủ sở hữu. (Giữ lại: giá trị nào thắng?)
- Tôi biết khớp không đòi hỏi phải gộp, và tôi chỉ gộp khi có bên thắng rõ ràng, sau khi đã quyết định trước chuyện gì xảy ra với các bản ghi con. (Khớp không đòi hỏi phải gộp, Quy tắc gộp của tôi: một bên thắng rõ ràng)
- Kiến thức hay ra thi: Tôi biết việc gộp tài khoản trong Salesforce làm gì: tối đa ba bản ghi, một bản ghi chính, giữ Created By và Created Date cũ nhất, các bản còn lại vào Thùng rác, và các đối tượng contact point không được gộp với tài khoản cá nhân. (Việc gộp trong Salesforce thực sự làm gì)
SDM-3: cái nhìn duy nhất về khách hàng
- Tôi biết phân giải danh tính của Data 360 liên kết các hồ sơ nguồn thành một hồ sơ hợp nhất và giữ liên kết ngược lại: gần nhất với một registry. (Phân giải danh tính trả lời câu hỏi “Ai?”)
- Kiến thức hay ra thi: Tôi biết quy tắc khớp của Data 360: mọi tiêu chí trong một quy tắc phải khớp, bất kỳ quy tắc nào cũng có thể khớp; nhiều tiêu chí hơn để chính xác, ít tiêu chí hơn để hợp nhất nhiều. (Quy tắc khớp)
- Tôi biết các phương thức khớp (Exact, Exact Normalized, Fuzzy với ba mức độ chính xác): một phương thức kém chính xác hơn làm tăng mức hợp nhất, và cả rủi ro khớp sai. (Quy tắc khớp)
- Kiến thức hay ra thi: Tôi biết quy tắc đối chiếu (Last Updated, Most Frequent, Source Priority) quyết định những gì hồ sơ hợp nhất hiển thị, nhưng không thay đổi các nguồn; các điểm liên lạc không được đối chiếu. (Đối chiếu vẫn không phải là quản lý dữ liệu chủ)
- Tôi chọn được giữa quản lý trùng lặp, phân giải danh tính và một nền tảng MDM chuyên dụng cho công việc. (Ba công cụ cho ba công việc)
MDM-4 và dữ liệu hai chiều
- Tôi biết dữ liệu hai chiều không có nghĩa là hai bên quản lý chủ: một lần sửa trong Salesforce đối với trường do ERP sở hữu là một yêu cầu, nên hãy thiết kế yêu cầu → xác thực → chấp nhận → phát hành, với một trạng thái chờ. (Dữ liệu hai chiều không có nghĩa là hai bên quản lý chủ, Khi bên quản lý chủ nói không)
- Tôi biết cách tránh vòng lặp và xung đột: phân biệt một thay đổi gốc với tiếng vọng của nó, và quyết định những trường nào đi cùng nhau như một giao dịch. (Vòng lặp và xung đột)
- Với một khách hàng trong hai ERP, tôi chọn được giữa một phân cấp, các tài khoản ngang hàng hoặc một tài khoản với một bản ghi con cho mỗi ERP, dựa trên mức độ khách hàng giữ các ERP của mình đồng bộ tốt đến đâu. (Một khách hàng, hai ERP, Hãy hỏi họ giữ các ERP đồng bộ như thế nào)
Điểm kiểm tra 1: ghép Phần 1 lại với nhau
- Kiến thức hay ra thi: Tôi biết những giấy phép bên ngoài nào có chia sẻ chuẩn: Customer Community Plus và Partner Community, vốn cần vai trò cho người dùng bên ngoài; Customer Community dùng sharing set. (Ai thấy gì, và ai cần giấy phép)
Ngoài kỳ thi
Phần tiêu đề “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.
- “Nguồn sự thật duy nhất”: sự thật nào? Đó là một kiến trúc của sự thật, không phải một bản ghi.
- Làm cho thẩm quyền hiện rõ trong lược đồ: một tiền tố cho các trường mà hệ thống khác sở hữu.
- Sự tin cậy cần nhiều hơn một giá trị: nguồn, lần xác nhận cuối, ai đã thay đổi nó.
- Bắt đầu từ bài toán, không phải sản phẩm MDM. MDM là một quyết định nghiệp vụ về thẩm quyền.
- Liên kết không phải là quản lý.
- Ở nơi khớp sai tốn kém, hãy cố ý khớp ít.
- Hãy giữ các bản trùng từ những lần nạp bên ngoài khi bạn có thể cần truy ngược.
- Hồ sơ hợp nhất là một bản đồ. Bản ghi vàng là một quyết định.
- Hiển thị không phải là thẩm quyền.
- Hợp nhất danh tính không xóa bỏ ranh giới bảo mật.
- Thứ khó nhất là các luồng hai chiều. Thẩm quyền được chia sẻ không phải là vấn đề; thẩm quyền mơ hồ mới là vấn đề.
- Đừng bao giờ để một yêu cầu bị từ chối biến thành sự thật cạnh tranh.
- Một trường nói rằng đây là dữ liệu chủ điều khiển khả năng sửa, chứ không phải một loại bản ghi.
- Chúng ta không kiểm soát các ERP. Chúng ta kiểm soát cách thể hiện chúng trong Salesforce.
Thuật ngữ cần biết
Phần tiêu đề “Thuật ngữ cần biết ”| Thuật ngữ | Trong một dòng |
|---|---|
| Quản lý dữ liệu chủ (MDM) | Thiết lập và quản trị danh tính và giá trị có thẩm quyền của dữ liệu then chốt qua các hệ thống |
| Bản đồ thẩm quyền | Với mỗi thuộc tính: ai tạo ra nó, ai sở hữu quyết định, hệ thống nào có thẩm quyền, ai được thay đổi nó |
| Bản ghi vàng | Một quyết định được quản trị về những giá trị nào có thẩm quyền |
| Bản ghi vàng lai | Một bản ghi có một số thuộc tính được quản lý chủ ở nơi khác và sao chép vào, và một số được sở hữu tại chỗ |
| Registry | MDM liên kết các bản ghi như cùng một thực thể mà không thay đổi các nguồn |
| Hợp nhất | MDM kết hợp dữ liệu ở trung tâm, thường cho phân tích, mà không đẩy ngược lại |
| Cùng tồn tại | MDM quyết định giá trị được quản lý chủ và phát hành nó ngược lại các nguồn |
| MDM tập trung | MDM nơi dữ liệu được quản trị được tạo trong bên quản lý chủ rồi phân phối |
| Mô hình dữ liệu chuẩn tắc | Một hình dạng doanh nghiệp đã thống nhất cho một khái niệm, dùng để ánh xạ các hệ thống với nhau |
| Hài hòa hóa | Làm cho các giá trị so sánh được: định dạng, mã và chữ viết tắt chuẩn |
| Khớp | Quyết định các bản ghi có đại diện cho cùng một thứ không |
| Quy tắc giữ lại | Các quy tắc chọn giá trị nào thắng khi các nguồn bất đồng |
| Bản ghi chính (principal) | Trong một lần gộp của Salesforce, bản ghi được giữ lại và giữ các trường ẩn và chỉ-đọc của nó |
| Phương thức khớp | Cách một tiêu chí khớp của Data 360 so sánh giá trị: khớp chính xác, khớp chính xác sau chuẩn hóa hoặc khớp mờ |
| Phân giải danh tính | Việc Data 360 khớp các hồ sơ nguồn thành hồ sơ hợp nhất |
| Hồ sơ hợp nhất | Một tập hợp khóa liên kết các bản ghi nguồn đại diện cho một người hay một công ty |
| Quy tắc đối chiếu | Các quy tắc của Data 360 về giá trị nào hồ sơ hợp nhất hiển thị |
| Phân cấp quản lý chủ chia tách | Một phân cấp có các nhánh do những hệ thống khác nhau sở hữu |
Tự kiểm tra
Phần tiêu đề “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. “Salesforce là nguồn sự thật duy nhất của chúng tôi về khách hàng.” Bạn hỏi gì?
Sự thật nào? Thẩm quyền được giao theo từng thuộc tính: ERP có thể sở hữu tên pháp lý, địa chỉ thanh toán và hạn mức tín dụng trong khi Salesforce sở hữu giám đốc khách hàng và hạng thành công. Hãy xây một bản đồ thẩm quyền. Đọc lại Sự thật thuộc về một thuộc tính.
2. Nhân viên dịch vụ cần thấy rằng một liên hệ Salesforce là cùng một người đã mua hàng trực tuyến. Không ai cần các hệ thống thay đổi. Kiểu MDM nào?
Một registry: liên kết các bản ghi thành một danh tính mà không thay đổi các nguồn, đó chính là việc phân giải danh tính của Data 360 làm. Hãy chọn khuôn mẫu nhẹ nhất giải quyết được bài toán. Đọc lại Registry: cho tôi biết ai là ai.
3. Quy tắc giữ lại được đặt là “mới nhất thắng” cho mọi trường. Ai đó thay đổi bản sao trong Salesforce của tên pháp lý do ERP sở hữu. Chuyện gì xảy ra, và điều gì sai?
Giá trị mới nhất thắng, và bản sao ghi đè lên thẩm quyền. “Mới nhất” là một tuyên bố về sự tin cậy, phù hợp với một số thuộc tính (một số di động) mà không phù hợp với những thuộc tính khác. Ở nơi bản đồ thẩm quyền nói ERP sở hữu trường, ERP thắng. Đọc lại Giữ lại: giá trị nào thắng?.
4. Các bản ghi khách hàng cũ được nhập vào và khớp với các tài khoản hiện có. Gộp chúng?
Hãy thận trọng. Khớp không đòi hỏi phải gộp, và việc gộp phá hủy các ID cũ và giá trị cũ hơn mà bạn có thể cần để truy vết. Hãy liên kết chúng, trừ khi có một bên thắng rõ ràng và bản trùng không mang thêm gì bạn cần. Đọc lại Quy tắc gộp của tôi: một bên thắng rõ ràng.
5. Hồ sơ hợp nhất trong Data 360 hiển thị Dallas. Đội nói Dallas giờ là giá trị vàng cho mọi hệ thống. Đúng không?
Không. Việc đối chiếu quyết định những gì hồ sơ hợp nhất hiển thị; nó không thay đổi các nguồn hay đưa ra quyết định quản lý dữ liệu chủ. Nếu mọi hệ thống phải dùng một giá trị được quản trị, đó là MDM cùng tồn tại hoặc tập trung, với một chủ sở hữu. Đọc lại Đối chiếu vẫn không phải là quản lý dữ liệu chủ.
6. Khớp hồ sơ y tế so với hồ sơ marketing: cùng quy tắc?
Không. Một lần khớp sai trong marketing gửi nhầm một ưu đãi; trong dữ liệu y tế nó trộn lịch sử của hai người. Hãy đặt độ chặt theo cái giá của việc sai, và khớp ít ở nơi việc trộn lẫn tốn kém. Đọc lại Cái giá của việc sai.
7. Nhân viên kinh doanh muốn cập nhật địa chỉ thanh toán do ERP sở hữu từ Salesforce. Bạn thiết kế thế nào?
Như một yêu cầu, không phải một lần sửa: Salesforce gửi giá trị đề xuất, ERP xác thực và chấp nhận nó, rồi phát hành giá trị có thẩm quyền trở lại. Giữ một trạng thái chờ cho đến lúc đó, và xử lý việc từ chối, xung đột và tiếng vọng. Đọc lại Dữ liệu hai chiều không có nghĩa là hai bên quản lý chủ.
8. Ở Steve Trucking, cùng một John Smith xuất hiện trong bảng kê hàng của hai Đối tác bán lẻ. Hợp nhất anh ấy?
Không, một cách có chủ ý. Mỗi đối tác không bao giờ được thấy Người nhận của đối tác khác, và một danh tính hợp nhất là cây cầu làm rò rỉ. Hãy khớp ít ở nơi việc trộn lẫn tốn kém; nếu một đối tác muốn nhận ra người quay lại, hãy giới hạn nó chỉ trong đối tác đó. Đọc lại Tôi có hợp nhất Người nhận giữa các đối tác không?.
9. Một nhân viên kinh doanh gửi tên đường mới cho một địa chỉ do ERP sở hữu, trong khi cùng phút đó, ai đó trong ERP đổi thành phố. Bạn quyết định gì?
Địa chỉ có đi như một giao dịch hay không. Nếu có, các trường cùng đi với nhau hoặc không trường nào đi, và yêu cầu bị từ chối vì địa chỉ đã thay đổi trong lúc đó. Hãy quyết định điều đó trước lần xung đột đầu tiên, và nhớ rằng yêu cầu là đề nghị thay đổi giá trị của ERP, chứ không phải thay đổi nó. Đọc lại Vòng lặp và xung đột.
10. Một doanh nghiệp khách hàng có cùng một khách hàng nằm trong hai ERP, và không ai giữ hai bản ghi đó đồng bộ. Đội kinh doanh muốn một tài khoản. Bạn khuyên gì?
Không phải một tài khoản. Nếu họ không giữ được các bản ghi đồng bộ trong chính các ERP của mình, Salesforce không thể làm thay họ: hãy thể hiện chúng thành các tài khoản ngang hàng hoặc một phân cấp, và cho thấy cấu trúc mà đội kinh doanh vốn đã biết. Một tài khoản với một bản ghi con cho mỗi ERP cần một khách hàng biết giữ các giá trị dùng chung đồng bộ. Đọc lại Hãy hỏi họ giữ các ERP đồng bộ như thế nào.
Tìm hiểu thêm
Phần tiêu đề “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 đứng sau các sự thật của nó, kèm ngày kiểm tra.