Liên kết không phải là quản lý
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)
Chương 6 của Data Architect, Phần 1: Trở thành kiến trúc sư dữ liệu. Trước: Chất lượng và quản trị dữ liệu.
“Chúng ta cần một nguồn sự thật duy nhất.” Đó là một trong những câu được lặp lại nhiều nhất trong kiến trúc, và là một trong những câu ít được xem xét kỹ nhất. Cho cái gì? Lấy một tài khoản. 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 của nó; Salesforce sở hữu giám đốc khách hàng và hạng hỗ trợ; một nền tảng đồng ý sở hữu các lựa chọn marketing. Ba bên có thẩm quyền trên một bản ghi, và đó là chuyện bình thường. Vì vậy khi ai đó nói “Salesforce là nguồn sự thật duy nhất của chúng tôi về khách hàng”, câu hỏi tiếp theo của tôi luôn là: sự thật nào?
Chương này nói về việc trả lời câu hỏi đó một cách có chủ ý. Thẩm quyền được giao theo từng thuộc tính. Liên kết các bản ghi không phải là quản lý chúng. Và Salesforce cho bạn những công cụ khác nhau cho những công việc khác nhau: quản lý trùng lặp và gộp bên trong một org; phân giải danh tính của Data 360 cho một cái nhìn qua nhiều nguồn; một nền tảng MDM chuyên dụng khi giá trị phải được quyết định một lần và đẩy ngược lại khắp nơi. Chương kết thúc với Điểm kiểm tra 1, nơi Phần 1 được ghép lại trên Steve Trucking.
Hình ảnh được tạo bằng AI.
Các lập trường trong chương này
Phần tiêu đề “Các lập trường trong chương này ”- Sự thật theo từng thuộc tính. Hãy hỏi mỗi mẩu dữ liệu được tạo, sửa và tham chiếu ở đâu, và nó thay đổi nhanh đến đâu. Thể hiện thẩm quyền bên ngoài trong lược đồ bằng một tiền tố hệ thống, như
sap_hayerp_. - Khách hàng tiềm năng thì khác. Họ sống trong Salesforce trước khi ERP biết đến họ; thẩm quyền của ERP áp dụng sau khi chuyển đổi.
- Registry là chuẩn mực trong các dự án Salesforce, rồi đến hợp nhất và cùng tồn tại; MDM tập trung thuần túy thì hiếm.
- Chỉ gộp khi có bên thắng rõ ràng. 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; việc gộp phá hủy lịch sử đó. Và hãy quyết định chuyện gì xảy ra với các bản ghi con: chuyển chúng đi, không nạp chúng, hoặc giữ chúng trên một bản ghi không hoạt động.
- Hồ sơ hợp nhất là một bản đồ; bản ghi vàng là một quyết định. Điều này có thể gây bối rối cho nhiều người: phân giải danh tính tạo ra một cá nhân hợp nhất, nhưng không tạo ra bản ghi vàng.
- Độ chặt của việc khớp là một quyết định về rủi ro. Ở nơi việc trộn lẫn tốn kém, hãy cố ý khớp ít.
- Ba công cụ cho ba công việc: gộp, phân giải danh tính, MDM.
- Phân cấp được quản lý chủ chia tách. Hãy quyết định thẩm quyền theo từng nhánh.
- “Thứ khó nhất là các luồng hai chiều.” Một tích hợp hai chiều không tạo ra hai bên quản lý chủ. Hãy quyết định những trường nào đi cùng nhau như một giao dịch trước lần xung đột đầu tiên.
- Làm cho dữ liệu chủ hiện rõ. Một trường nói rằng đây là dữ liệu chủ (khóa của ERP hoặc một cờ) đ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: một khách hàng trong hai ERP là 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, được quyết định bởi mức độ khách hàng giữ các ERP của mình đồng bộ tốt đến đâu.
Ba công cụ cho ba công việc
Phần tiêu đề “Ba công cụ cho ba công việc ”| Công việc | Công cụ | Nó làm gì với các nguồn |
|---|---|---|
| Bản trùng bên trong một org, với một bên thắng rõ ràng | Quản lý trùng lặp và gộp | Gộp tối đa ba bản ghi; các bản còn lại vào Thùng rác |
| Một danh tính và một cái nhìn duy nhất qua các nguồn | Phân giải danh tính của Data 360 | Liên kết chúng; không thay đổi bản nào (một registry) |
| Một giá trị được quản trị, đẩy ngược lại mọi hệ thống | Một nền tảng MDM chuyên dụng | Quyết định giá trị và phân phối nó (cùng tồn tại hoặc tập trung) |
Lộ trình qua chương này
Phần tiêu đề “Lộ trình qua chương này ”Sáu mô-đun và một thử thách, mỗi phần có thể đọc độc lập.
- Một nguồn sự thật cho mỗi thuộc tính. Bản đồ thẩm quyền, bản ghi vàng lai, và các tín hiệu tin cậy.
- Bốn cách quản lý dữ liệu chủ. Registry, hợp nhất, cùng tồn tại và tập trung, và vì sao một mô hình chung không phải là một sự thật chung.
- Khớp, gộp và giữ lại. Cái giá của một lần khớp sai, việc gộp trong Salesforce thực sự làm gì (và chuyện gì xảy ra với các bản ghi con), và quy tắc giữ lại như một tuyên bố về sự tin cậy.
- Bản đồ không phải là quyết định. Quy tắc khớp và phương thức khớp, quy tắc đối chiếu, và vì sao hồ sơ hợp nhất không phải là bản ghi vàng.
- Khi thẩm quyền được chia sẻ. Yêu cầu so với cập nhật, vòng lặp và xung đột, phân cấp được quản lý chủ chia tách, và một khách hàng trong hai ERP.
- Thử thách Điểm kiểm tra 1, rồi Điểm kiểm tra 1: Steve Trucking, tôi sẽ thiết kế thế nào. Hãy thử thách trước: vẽ và bảo vệ thiết kế của Phần 1, rồi so sánh với thiết kế của tôi, và xem điều gì thay đổi so với bản đồ hệ thống của chương 4.
Khi học xong, hãy tự kiểm tra với hướng dẫn ôn tập của chương: một danh sách kiểm tra cho kỳ thi, những thói quen vượt ra ngoài kỳ thi, các thuật ngữ cần biết và vài câu hỏi. Nó khép lại Phần 1; hướng dẫn ôn tập Phần 1 ghép cả sáu chương lại với nhau.
Kiến trúc sư quyết định gì ở đây
Phần tiêu đề “Kiến trúc sư quyết định gì ở đây ”- Hệ thống nào có thẩm quyền cho từng thuộc tính quan trọng, và điều đó thể hiện trong mô hình thế nào.
- Kiểu quản lý dữ liệu chủ nào phù hợp với từng miền dữ liệu, và tầng quản lý dữ liệu chủ được trao bao nhiêu thẩm quyền.
- Khi nào gộp, khi nào liên kết, và ai sở hữu từng quy tắc giữ lại.
- Việc khớp nên chặt đến đâu, dựa trên cái giá của một lần khớp sai.
- Ở đâu dữ liệu hai chiều và phân cấp dùng chung cần ranh giới rõ ràng.
Ngoài kỳ thi: tác tử cần một danh tính để hành động, và điều đó nâng mức rủi ro theo cả hai hướng. Khớp quá mức trở thành sự cố quyền riêng tư, và một tác tử “cập nhật khách hàng” phải ghi vào hệ thống gốc của từng thuộc tính, không phải vào hồ sơ hợp nhất. Mỗi mô-đun kết thúc bằng điều AI thay đổi.
Tìm hiểu thêm
Phần tiêu đề “Tìm hiểu thêm ”- Salesforce Architects, Data 360 Architecture (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.
- Salesforce Help, Considerations for Merging Duplicate Accounts (opens in a new tab), Identity Resolution Match Methods (opens in a new tab) và Identity Resolution Reconciliation Rules (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.
Tiếp theo: Phần 2 bắt đầu với Thiết kế cho quy mô lớn (coming soon).