Kiến trúc dữ liệu Salesforce

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 3 của khóa học Data Architect. Hãy đọc mười 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ư.

Đây là chương nơi mô hình gặp nền tảng, và nó gánh một phần lớn của kỳ thi. Nó nuôi cả hai phần lớn nhất, Data Modeling and Database Design và Salesforce Data Management, mỗi phần chiếm một phần tư đề thi. Các con số của nền tảng thay đổi: danh sách kiểm tra đưa ra những con số mà các mô-đun trích dẫn, kèm ngày kiểm tra. Hãy học mỗi giới hạn dùng để làm gì, và kiểm tra con số hiện hành trước khi dựa vào nó.

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.

DM-1: thiết kế mô hình dữ liệu trên nền tảng

DM-2: một mô hình tôn trọng việc chia sẻ và mở rộng được

Tôi biết một bản ghi con chính-chi tiết không có chủ sở hữu và không có bảng chia sẻ riêng: quyền truy cập đi theo bản ghi chính. (Quyền sở hữu đi theo)
Tôi biết lệch dữ liệu cha-con: hướng dẫn của Salesforce là không quá khoảng 10.000 bản ghi con trên một bản ghi cha. (Câu hỏi 10.000 bản ghi con)
Tôi biết lệch dữ liệu sở hữu (một người dùng sở hữu hơn 10.000 bản ghi của một đối tượng) và hướng dẫn: phân tán quyền sở hữu, hoặc giữ người dùng đó ngoài phân cấp vai trò hay một mình ở trên cùng, và ngoài các nhóm công khai mà quy tắc chia sẻ dùng. (Quyền sở hữu có thể trở thành vấn đề quy mô)
Tôi biết bảng chia sẻ: đối tượng chia sẻ của một đối tượng tùy chỉnh là Object__Share; một đối tượng chi tiết không có bảng này, quyền truy cập của nó đến từ master; và việc đổi chủ sở hữu xóa các chia sẻ thủ công nhưng giữ chia sẻ bằng Apex có lý do riêng. (Bảng chia sẻ)
Tôi quyết định được ai sở hữu các bản ghi do tích hợp và tác tử tạo ra, dựa trên việc quyền sở hữu có quyết định chia sẻ hay không. (Ai sở hữu các bản ghi do hệ thống tạo ra?)

DM-4: đối tượng lớn so với đối tượng chuẩn và tùy chỉnh

Tôi biết ba ngôi nhà của dữ liệu: trên lõi (sObject, được dùng hằng ngày), tham chiếu (một hệ thống khác là nguồn sự thật: đối tượng bên ngoài của Salesforce Connect, __x, hoặc các lệnh gọi tùy chỉnh), và lưu trữ (trên lõi trong đối tượng lớn, __b, hoặc ngoài lõi trong một kho dữ liệu). (Trên lõi và ngoài lõi)
Tôi biết đối tượng bên ngoài tạo một lệnh gọi ra ngoài mỗi lần được chạm đến, nên độ trễ và tính sẵn sàng của hệ thống nguồn rất quan trọng. (Tham chiếu)
Tôi biết đối tượng lớn: khối lượng khổng lồ, truy vấn qua chỉ mục bằng khớp chính xác hoặc theo khoảng, không có giao diện hay báo cáo chuẩn, chỉ có quyền đối tượng và trường, không có tự động hóa. (Lưu trữ)
Tôi biết phần lớn bản ghi được tính khoảng 2 KB dung lượng dữ liệu bất kể số trường, và tệp được tính riêng trong dung lượng tệp. (Hai cột hay hai trăm cột, Tệp và tệp đính kèm)

SDM-1: giấy phép và các đối tượng người ta có thể dùng

Tôi biết ba giấy phép nội bộ, Sales Cloud, Service Cloud và Platform, và mỗi giấy phép dùng được những gì. (Ba giấy phép nội bộ)
Tôi biết giấy phép là một phần của mô hình dữ liệu: người dùng Salesforce Platform không có Khách hàng tiềm năng, Chiến dịch, Cơ hội hay Dự báo, và người dùng Customer Community không dùng được Cơ hội. (Giờ để tôi làm mọi thứ phức tạp lên: giấy phép)
Tôi biết các hạng giấy phép bên ngoài: Customer Community, Customer Community Plus (báo cáo, bảng điều khiển, chia sẻ chuẩn), Partner Community (đối tượng bán hàng); và rằng Partner Community không dùng được với tài khoản cá nhân. (Sân vận động)
Tôi biết cấp phép theo thành viên so với theo lượt đăng nhập, và mỗi cách hợp với nhóm người dùng nào. (Cách họ trả tiền làm thay đổi thiết kế)
Tôi biết một số giấy phép nền tảng giới hạn người dùng trong một ứng dụng với tối đa mười đối tượng tùy chỉnh, và mẫu dùng loại bản ghi để làm việc trong giới hạn đó. (Khi giấy phép định hình mô hình)
Tôi biết giấy phép Salesforce Integration dành cho người dùng giữa các hệ thống, chỉ API. (Con người không còn là người dùng duy nhất)
Tôi biết báo cáo SLA cần entitlement và milestone, mà chúng cần giấy phép Service. (Giờ để tôi làm mọi thứ phức tạp lên: giấy phép)

SDM-2: giữ dữ liệu nhất quán

Tôi đặt được một quy tắc vào đúng nấc trên nấc thang nhất quán: kiểu trường và bộ từ vựng, bắt buộc và duy nhất, quy tắc xác thực, quy tắc trùng lặp, tự động hóa. (Giữ dữ liệu nhất quán)
Tôi biết một danh sách chọn hạn chế từ chối giá trị không có trong danh sách, kể cả qua API, và một bộ giá trị toàn cục chia sẻ một danh sách giữa các trường (tối đa 1.000 giá trị). (Nấc một)
Tôi biết yêu cầu trên bố cục trang chỉ bảo vệ màn hình đó, không phải dữ liệu, và quy tắc xác thực chạy ở mọi lần lưu. (Xác thực trên giao diện không phải là xác thực dữ liệu, Nấc ba)
Tôi giới hạn được quy tắc xác thực bằng ISNEW() và ISCHANGED(), một quyền tùy chỉnh hay một ngày bắt đầu có hiệu lực, và biết mỗi lựa chọn vẫn kiểm tra những lần lưu nào (kể cả những lần tôi không kiểm soát, như một lần đổi chủ sở hữu hàng loạt hay một trường tổng hợp). (Vấn đề bản ghi cũ)
Tôi biết quy tắc khớp và quy tắc trùng lặp, các giới hạn mà mô-đun trích dẫn (năm quy tắc trùng lặp đang hoạt động mỗi đối tượng, mỗi quy tắc ba quy tắc khớp), và rằng chúng không giải quyết danh tính giữa các hệ thống. (Nấc bốn: quy tắc trùng lặp)
Tôi biết quy tắc trùng lặp không so sánh các bản ghi được lưu cùng một lúc, rằng lần lưu qua API và công cụ nhập bị chặn mà không có cảnh báo, và rằng một lần lưu cùng mọi thứ nó kích hoạt được hoàn tác như một giao dịch. (Nấc bốn, Tất cả hoặc không gì cả)
Tôi biết Workflow Rules và Process Builder đã hết hỗ trợ; tự động hóa nghĩa là Flow hoặc Apex. (Nấc năm: tự động hóa)

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.

Nền tảng có hình dáng của nó. Hãy thiết kế cho nền tảng bạn đang dùng, không phải một cơ sở dữ liệu chung chung.
Hãy nhìn về phi thuyền mẹ. Xem Salesforce mô hình hóa một khái niệm thế nào trước khi bạn tự phát minh.
Mỗi đối tượng là một cam kết: dung lượng lưu trữ, giới hạn, mô hình chia sẻ, giấy phép và các phụ thuộc.
Hãy hỏi dữ liệu nằm ở đâu trước khi chọn đối tượng: trên lõi, tham chiếu hay lưu trữ.
Đọc bất kỳ tên API nào là bạn biết ai đã tạo ra nó, và bạn được thay đổi những gì.
Nếu hôm nay bạn không lưu trữ, liệu bạn có bao giờ lưu trữ không?
Hãy làm thử nguyên mẫu đối tượng lớn trước khi đề xuất chúng.
Những tên gọi nghiệp vụ khác nhau không tự động có nghĩa là những đối tượng khác nhau.
Hãy hỏi danh tính nào cần dữ liệu: con người, khách hàng, đối tác, tích hợp và tác tử.
Mỗi trường đều có mô tả, và phân loại ở nơi quan trọng.
Hãy mô tả hành vi của quan hệ trước; cấu hình hiện thực nó. Đừng bóp méo mô hình để có một tính năng.
Câu hỏi về việc xóa: chuyện gì nên xảy ra với các bản ghi con nếu ai đó xóa bản ghi cha?
Hãy chọn mắt xích nào ngắt chuỗi: đặt quan hệ tra cứu ở nơi bản ghi con thực sự có cuộc đời riêng.
Quyền sở hữu từ master chính, quyền truy cập từ cả hai: mức hạn chế nhất sẽ thắng.
Hãy tách không hoạt động khỏi đã biến mất, và biến việc lưu giữ thành một quy tắc nghiệp vụ.
Hãy đẩy quy tắc xuống thấp đến đúng chỗ nó thuộc về, và cho lịch sử hợp lệ một lối miễn trừ thay vì viết lại nó.
Sơ đồ không phải là kiến trúc. Hãy truy ngược được mọi cấu trúc về một lý do nghiệp vụ.

Thuật ngữ cần biết

Thuật ngữ	Trong một dòng
Hướng siêu dữ liệu	Đối tượng và trường là các định nghĩa nền tảng đọc lúc chạy, không phải các bảng vật lý mới
Đa thuê bao	Nhiều org dùng chung hạ tầng, mỗi org được cô lập, như các căn hộ trong một tòa nhà
Giới hạn điều tiết (governor limits)	Các giới hạn giữ cho một bên thuê không độc chiếm tài nguyên dùng chung
Đối tượng bên ngoài	Dữ liệu hiển thị trong Salesforce qua Salesforce Connect, được lấy từ nguồn mỗi lần chạm đến
Đối tượng lớn	Nơi lưu dữ liệu rất lớn, ít dùng, truy vấn qua chỉ mục của nó
Tài khoản cá nhân	Một cá nhân được biểu diễn như một tài khoản, cho các mô hình kinh doanh với người tiêu dùng
Phù hợp trọn vẹn	Một khái niệm nghiệp vụ khớp với mục đích dự định của một đối tượng chuẩn
ID bên ngoài	Một trường chứa mã định danh của hệ thống khác, dùng cho upsert và so khớp
Upsert	Cập nhật bản ghi nếu đã có, tạo mới nếu chưa có
Quan hệ tra cứu	Quan hệ mà bản ghi con giữ chủ sở hữu và cuộc đời riêng
Chính-chi tiết	Quan hệ mà bản ghi con thuộc về bản ghi cha: thừa hưởng chủ sở hữu và chia sẻ, xóa lan truyền, trường tổng hợp
Đối tượng nối logic	Ý tưởng mô hình hóa: một đối tượng nối hai đối tượng khác trong quan hệ nhiều-nhiều và mang thuộc tính riêng, dù được xây theo cách nào
Đối tượng nối của Salesforce (Salesforce Junction Object)	Điều Salesforce muốn nói khi dùng từ “junction object”: một đối tượng tùy chỉnh có hai quan hệ chính-chi tiết
Master chính và master phụ (primary / secondary master)	Quan hệ chính-chi tiết được tạo trước của một đối tượng nối của Salesforce (chủ sở hữu, giao diện, bộ phận) và quan hệ thứ hai (phạm vi báo cáo; trở thành master chính nếu cái đầu tiên bị gỡ bỏ)
Quan hệ phân cấp	Một quan hệ tra cứu đặc biệt chỉ có trên đối tượng User, như Manager, không thể vòng về chính người dùng đó
Tiền tố không gian tên	Tiền tố của nhà cung cấp trên các đối tượng và trường của một gói được quản lý, như `abc__Inspection__c`
Bảng chia sẻ	Đối tượng chia sẻ (`AccountShare`, `Truck__Share`) chứa phần lớn việc chia sẻ của một bản ghi, mỗi dòng cho một người dùng hay một nhóm, kèm lý do của nó
Trường tổng hợp cuộn lên	Một trường trên bản ghi chính để đếm, cộng tổng hoặc tìm giá trị nhỏ nhất hay lớn nhất của các bản ghi chi tiết
Lệch dữ liệu	Quá nhiều bản ghi dưới một bản ghi cha hay một chủ sở hữu, gây khóa và tính lại chia sẻ kéo dài
Theo thành viên / theo lượt đăng nhập	Trả tiền theo mỗi người dùng bên ngoài, hoặc theo mỗi lượt đăng nhập hằng tháng
Nấc thang nhất quán	Các tầng thực thi quy tắc dữ liệu, từ kiểu trường lên đến tự động hóa
Danh sách chọn hạn chế	Một danh sách chọn từ chối mọi giá trị không có trong danh sách, từ bất kỳ nguồn nào
Phân loại dữ liệu	Siêu dữ liệu của trường về chủ sở hữu, mức sử dụng, mức độ nhạy cảm và loại tuân thủ

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. Người dùng cần xem chi tiết đơn hàng mà ERP sở hữu và cập nhật suốt cả ngày. Họ không sửa chúng trong Salesforce. Sao chép vào, hay không?

Tham chiếu chúng: đối tượng bên ngoài qua Salesforce Connect giữ ERP làm nguồn sự thật mà không có bản sao nào phải đồng bộ. Chấp nhận rằng mỗi lần xem tạo một lệnh gọi ra ngoài, nên độ trễ và tính sẵn sàng của ERP rất quan trọng, và cách này hợp với truy cập đọc hơn là sửa hay báo cáo nhiều. Đọc lại Tham chiếu.

2. Nghiệp vụ muốn theo dõi nhà phân phối, nhà cung cấp và đối tác bán lẻ. Ba đối tượng tùy chỉnh?

Không. Tất cả đều là công ty, nên Tài khoản phù hợp trọn vẹn; các tên gọi khác nhau là vai trò, được thể hiện bằng một loại, một loại bản ghi hay một quan hệ. Đọc lại Phép thử phù hợp trọn vẹn.

3. Một thiết kế dùng Cơ hội, nhưng phần lớn những người cần dữ liệu có giấy phép Salesforce Platform hoặc Customer Community. Giờ thì sao?

Những giấy phép đó không dùng được Cơ hội, nên giấy phép là một ràng buộc kiến trúc: mua giấy phép khác, chuyển trải nghiệm đi nơi khác, hoặc thiết kế lại, thường là hướng về một đối tượng tùy chỉnh. Đọc lại Giờ để tôi làm mọi thứ phức tạp lên: giấy phép.

4. ERP gửi bản cập nhật tài khoản hằng đêm. Tích hợp nên tìm đúng bản ghi thế nào mà không phải truy vấn ID Salesforce?

Lưu mã khách hàng của ERP trong một trường ID bên ngoài và upsert dựa trên nó: cập nhật nếu tìm thấy, tạo mới nếu không. Bản ghi con cũng có thể trỏ đến bản ghi cha bằng ID bên ngoài của nó. Đọc lại ID bên ngoài.

5. Một Mặt hàng giao không thể tồn tại nếu không có lần giao hàng của nó, không bao giờ di chuyển, và không cần chủ sở hữu riêng. Một Giao hàng tồn tại trước khi được xếp tuyến và có thể chuyển sang tuyến khác. Mỗi cái dùng quan hệ nào?

Mặt hàng giao với Giao hàng: chính-chi tiết (nó thuộc về bản ghi cha suốt đời, thừa hưởng quyền truy cập, bị xóa lan truyền). Giao hàng với Tuyến: quan hệ tra cứu (cuộc đời riêng, ban đầu là tùy chọn, có thể chuyển, và xóa một tuyến không bao giờ được xóa các lần giao hàng). Đọc lại Bắt đầu từ quan hệ nghiệp vụ.

6. Một tích hợp tạo 3.300 lần giao hàng mỗi ngày, tất cả thuộc sở hữu của người dùng tích hợp, vốn có một vai trò ở giữa phân cấp. Rủi ro là gì, và cách khắc phục?

Lệch dữ liệu sở hữu: vượt quá 10.000 bản ghi, việc di chuyển người dùng đó hay thay đổi nhóm của nó sẽ kích hoạt những lần tính lại chia sẻ kéo dài. Hãy phân tán quyền sở hữu nếu nó quan trọng cho quyền truy cập; nếu không, giữ người dùng tích hợp ngoài phân cấp vai trò, hoặc một mình trong một vai trò ở trên cùng, và ngoài các nhóm mà quy tắc chia sẻ dùng. Đọc lại Quyền sở hữu có thể trở thành vấn đề quy mô.

7. Bạn thêm một quy tắc xác thực, và 20.000 bản ghi cũ vi phạm nó. Một người dùng sửa số điện thoại trên một bản ghi và việc lưu thất bại. Lẽ ra quy tắc phải làm gì?

Nói rõ khi nào thực thi, không chỉ điều gì phải đúng: giới hạn nó bằng ISNEW() hoặc ISCHANGED() trên các trường liên quan, và cho các bản ghi có trước quy tắc một lối miễn trừ có chủ ý thay vì viết lại lịch sử của chúng. Đọc lại Vấn đề bản ghi cũ.

8. Nghiệp vụ muốn mọi ảnh giao hàng “trong Salesforce”: bốn đến năm triệu ảnh mỗi năm, tăng 30 phần trăm. Bạn đề xuất gì?

Tách quyền truy cập khỏi nơi lưu trữ. Giữ các tệp trong bộ lưu trữ được xây cho khối lượng đó, bên ngoài org lõi, và giữ một tham chiếu, một số đếm hoặc một bản ghi chỉ mục trong Salesforce để người dùng tìm và xem được chúng. Đọc lại Ảnh.

9. Một Phân công tổ (Crew Assignment) có quan hệ chính-chi tiết với Tổ giao hàng (được tạo trước) và Xe tải. Một điều phối viên thấy được tổ giao hàng nhưng không thấy được xe tải. Họ có thấy được Phân công tổ không?

Không. Tổ giao hàng là master chính, nên nó cho bản phân công chủ sở hữu và giao diện, nhưng quyền truy cập cần cả hai bản ghi cha: điều phối viên cần quyền truy cập vào tổ giao hàng và xe tải, ở mức mà thiết lập Sharing Setting của mỗi trường chính-chi tiết yêu cầu. Mức hạn chế nhất sẽ thắng. Đọc lại Rộng hai bản ghi cha.

10. Một đối tác gửi lại một tệp bảng kê hàng, và cùng một khách hàng xuất hiện hai lần trong đó. Bạn có một quy tắc trùng lặp trên Tài khoản đặt ở chế độ chặn. Bạn có an toàn không?

Không, nếu chỉ dựa vào quy tắc trùng lặp. Các bản ghi được lưu cùng một lúc không được so sánh với nhau, chỉ với các bản ghi đã có trong Salesforce, nên cả hai dòng đều có thể lọt qua. Hãy đẩy tính duy nhất xuống tận trường: một ID bên ngoài duy nhất, được nền tảng kiểm tra ở mọi lần lưu, nên chỉ một dòng thắng. Đọc lại Nấc bốn: quy tắc trùng lặp và Tất cả hoặc không gì cả.

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 về nền tảng của nó, kèm ngày kiểm tra.