Chuyển mô hình vào 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)

Hình ảnh được tạo bằng AI

Được dịch bằng AI. Cộng đồng chưa xem xét. Đọc bằng tiếng Anh

Mô-đun 6 trong 6 của chương Mô hình hóa dữ liệu vì ý nghĩa, chương 2 của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Thiết kế theo dạng chuẩn thứ ba, rồi lùi lại · Tiếp theo: hướng dẫn ôn tập của chương, rồi chương tiếp theo: Kiến trúc dữ liệu Salesforce

Câu hỏi mô-đun này trả lời: Một mô hình dữ liệu logic trở thành một mô hình dữ liệu vật lý trên Salesforce như thế nào?

Cuối cùng chúng ta cũng nói về Salesforce. Nếu bạn đã cố kìm ham muốn biến mọi cái hộp thành một đối tượng, giờ thì bạn được làm rồi. Nhưng hãy để ý thứ tự chúng ta đã đi: chúng ta hiểu việc kinh doanh, mô tả dữ liệu, đặt mỗi dữ kiện vào đúng chỗ, và quyết định chỗ nào sẽ cố ý bẻ cong điều đó. Chỉ đến bây giờ tôi mới hỏi Salesforce nên triển khai nó thế nào. Đó là trình tự tôi muốn bạn nhớ: khái niệm → logic → vật lý. Mô hình khái niệm mô tả việc kinh doanh. Mô hình logic mô tả dữ liệu. Mô hình vật lý mô tả cách chúng ta thực sự sẽ xây nó.

Ngồi, Đứng yên, Mô hình hóa

Bước vật lý dễ thấy nhất trên một thứ nhỏ, nên thú cưng đi trước.

Đâu là doanh nghiệp và đâu là con người? Người nhân giống là một doanh nghiệp, nên trở thành một Tài khoản với loại bản ghi Người nhân giống (Breeder). Chủ nuôi cũng là một Tài khoản, hoặc một tài khoản cá nhân, với loại bản ghi Chủ nuôi (Owner). Hai loại của cùng một đối tượng chuẩn, đứng cạnh nhau ở đầu sơ đồ, đúng chỗ chúng đã ở từ mô-đun 1.

Cái gì không có chỗ chuẩn? Thú cưng, Giống, Trò, Trò của thú cưng và Đánh giá trò trở thành các đối tượng tùy chỉnh. Và bạn còn nhớ loài mà chúng ta đã sao chép lên thú cưng ở mô-đun 5? Ở đây nó có công việc của mình: nó trở thành loại bản ghi của Thú cưng, Chó hoặc Mèo. Một đối tượng với hai loại bản ghi, mỗi loại có bố cục trang và giá trị danh sách chọn riêng, thay vì một đối tượng Chó và một đối tượng Mèo.

Quan hệ nào là chính-chi tiết? Tôi dùng chính-chi tiết chỉ khi bản ghi con sẽ không bao giờ đổi cha. Một Trò của thú cưng thuộc về thú cưng của nó suốt đời, và mỗi Đánh giá trò thuộc về Trò của thú cưng của nó, nên cả hai đều là chính-chi tiết. Điều đó được đền đáp ngay: chính-chi tiết là thứ cho phép thú cưng giữ một trường tổng hợp cuộn lên (roll-up summary) các Trò của thú cưng, nên con số Số trò đã biết từ mô-đun 5 tự động luôn khớp. Tuy vậy, thú cưng có thể đổi nhà, nên Chủ nuôi là một quan hệ tra cứu.

Quan hệ nào là tra cứu? Salesforce khuyến nghị không quá 10.000 bản ghi con trên một bản ghi cha. Một trò phổ biến như Ngồi, một giống phổ biến hay một người nhân giống lớn có thể dễ dàng vượt qua con số đó, nên Trò của thú cưng trỏ đến Trò của nó bằng một quan hệ tra cứu, và thú cưng trỏ đến Giống và Người nhân giống của nó cũng theo cách đó. Và hãy tránh quan hệ đa hình (polymorphic) khi có thể, loại quan hệ mà một trường có thể trỏ đến nhiều loại đối tượng. Chúng tiện lợi vào ngày đầu và khó khăn hơn cho mọi thứ phải đọc chúng về sau: báo cáo, tích hợp, và giờ là cả các tác tử (agent).

Cái gì nằm ngoài nền tảng? Nếu thú cưng đeo một vòng cổ GPS báo vị trí của nó, vị trí đó hoàn toàn không cần được sao chép vào. Nó có thể là một đối tượng bên ngoài, được đọc trực tiếp từ hệ thống định vị của vòng cổ.

Click to enlarge

Mọi quyết định trên sơ đồ đó đều truy ngược về một điều chúng ta đã quyết định trước đó, và đó chính là mục đích. Giờ là cùng bước ấy cho Steve Trucking.

Bắt đầu từ mô hình logic

Mô hình logic Steve Trucking của chúng ta giờ chứa Đối tác bán lẻ, Trung tâm phân phối, Bảng kê hàng, Giao hàng, Mặt hàng giao, Người nhận, Tuyến, Điểm dừng, Tổ giao hàng, Xe tải và Phân công tổ. Đó là các khái niệm nghiệp vụ, và giờ tôi có thể bắt đầu ánh xạ chúng vào Salesforce.

Một Đối tác bán lẻ có thể là một Tài khoản. Một lần giao có thể ánh xạ vào thứ Salesforce đã có cho công việc được lên lịch ngoài hiện trường, hoặc có thể trở thành một đối tượng tùy chỉnh. Bảng kê hàng không có gì chuẩn phù hợp, nên có lẽ sẽ là tùy chỉnh. Còn Người nhận là một câu hỏi thực sự khó: một Tài khoản cá nhân, một Liên hệ, hay chỉ là thông tin trên lần giao? Chúng ta sẽ trả lời câu đó cho thấu đáo ở chương tiếp theo.

Từ quan trọng vẫn là có thể. Đừng mặc định cách triển khai chỉ vì một khái niệm nghiệp vụ nghe giống một đối tượng Salesforce. Đó là lý do chúng ta xây mô hình logic trước: nó cho chúng ta một thứ để kiểm tra thiết kế Salesforce.

Một thực thể nghiệp vụ không tự động là một đối tượng tùy chỉnh

Đây là một cái bẫy tôi muốn các quản trị viên tránh: “Chúng ta đã xác định mười một thực thể, vậy cần mười một đối tượng tùy chỉnh.” Không. Một thực thể logic cho chúng ta biết khái niệm nghiệp vụ đó quan trọng. Nó không áp đặt Salesforce phải lưu nó thế nào. Một khái niệm có thể trở thành một đối tượng chuẩn, một đối tượng tùy chỉnh, một quan hệ giữa các đối tượng, một trường hay vài trường, một giá trị được quản lý trong cấu hình, hoặc dữ liệu hoàn toàn nằm ngoài Salesforce (ảnh giao hàng của Steve Trucking là một ứng viên tốt cho điều đó). Mô hình vật lý là nơi những lựa chọn đó được đưa ra, và đó chính là lý do chúng ta không đưa ra chúng trong cuộc gọi đầu tiên.

Thuộc tính trở thành trường vật lý

Cùng sự chuyển đổi đó xảy ra với các thuộc tính. Xe tải logic của chúng ta có số hiệu xe, số VIN, hãng, mẫu, năm sản xuất, biển số và trạng thái. Giờ chúng ta quyết định chúng tồn tại về mặt vật lý thế nào: đối tượng nào sở hữu chúng, chúng dùng kiểu trường nào, trường nào bắt buộc, trường nào phải duy nhất, trường nào là mã định danh bên ngoài, trường nào cần xác thực, trường nào được suy ra thay vì lưu, và trường nào nhạy cảm. Ở mức logic, chúng ta hỏi Xe tải có nghĩa là gì. Ở mức vật lý, chúng ta hỏi Salesforce sẽ biểu diễn Xe tải thế nào. Những câu hỏi khác nhau.

Click to enlarge

Quan hệ trở thành quyết định nền tảng

Tất cả thời gian chúng ta dành cho các quan hệ được đền đáp ở đây. Chúng ta đã biết mỗi quan hệ là một-một, một-nhiều hay nhiều-nhiều, bắt buộc hay tùy chọn, và lịch sử của nó có quan trọng không. Giờ chúng ta quyết định Salesforce triển khai nó thế nào: một quan hệ tra cứu, một quan hệ chính-chi tiết, hay một đối tượng nối của Salesforce, và có thể là một đối tượng nối có thuộc tính riêng, vì như chúng ta đã thấy, bản thân quan hệ có thể mang ý nghĩa nghiệp vụ.

Hãy nhớ lại Phân công tổ. Chúng ta đã có thể bắt đầu chương này bằng câu: “Hãy tạo một đối tượng nối của Salesforce giữa tổ và xe tải.” Hãy nhìn những gì chúng ta sẽ bỏ qua: vì sao quan hệ tồn tại, nó có cần ngày và tuyến không, nó có trạng thái không, và một khiếu nại hư hỏng vài tuần sau có cần lịch sử của nó không. Những câu hỏi nghiệp vụ đó cho chúng ta biết một Phân công tổ là gì. Chỉ sau đó chúng ta mới nên quyết định Salesforce xây nó thế nào, và liệu Salesforce đã có sẵn thứ gì làm được việc đó chưa.

Giờ hãy vẽ mô hình vật lý

Sơ đồ lại thay đổi. Mô hình khái niệm thể hiện các khái niệm nghiệp vụ và những đường nối đơn giản. Mô hình logic thêm thuộc tính, khóa, lực lượng và các thực thể ẩn trong quan hệ. Giờ mô hình vật lý bắt đầu trông giống Salesforce: đối tượng chuẩn, đối tượng tùy chỉnh, trường, kiểu quan hệ, và những gì nằm ngoài nền tảng.

Click to enlarge

Tôi muốn bạn có thể đặt ba sơ đồ đó cạnh nhau và thấy trình tự: không phải ba sơ đồ chẳng liên quan gì, mà là cùng một việc kinh doanh ở ba mức.

Đôi lời về cách tôi vẽ chúng, vì bố cục là một phần của thông điệp. Tôi đặt đối tượng chính ở giữa, hơi thấp xuống. Nếu nó có các đối tượng cha, tôi đặt chúng hơi cao lên, để bạn đọc mô hình từ trên xuống, từ trái sang phải, theo cách việc kinh doanh nghĩ về nó. Dữ liệu tham chiếu đặt sang một bên. Màu sắc cũng có ý nghĩa: tôi luôn tô Salesforce màu xanh dương, và chọn một màu cho các hệ thống riêng của công ty, thường là xanh lá, vì xanh lá là một màu dễ chịu, thân thiện. Tôi không dùng màu đỏ, và màu vàng hơi chói. Khi một mô hình được bố trí như vậy, nó như đang cất tiếng hát với tôi. Rất nhiều sơ đồ bạn sẽ gặp thực ra là chuyện quản lý không gian: làm sao đỗ hết xe của tôi vào cái gara chật chội? Tôi thà vẽ một bức tranh logic mà tâm trí nắm bắt được.

Mô hình vật lý phải tôn trọng nền tảng

Salesforce không phải là một cơ sở dữ liệu quan hệ chung chung. Nó có quan điểm riêng về quan hệ, quyền sở hữu, bảo mật và báo cáo. Nó có giới hạn, hành vi truy vấn và tự động hóa, và một kiến trúc ảnh hưởng đến cách mô hình hoạt động ở quy mô lớn. Vì vậy một mô hình logic trông hoàn hảo trên bảng trắng có thể cần thay đổi khi trở thành vật lý. Đó không phải là Salesforce cản đường. Nó có nghĩa là nền tảng có hình dạng của nó, và kiến trúc sư giỏi hiểu hình dạng đó. Chương tiếp theo nói chính về điều đó.

Đôi khi, mô hình vật lý cũng sẽ cố ý khác với mô hình logic gọn gàng vì những quyết định phi chuẩn hóa chúng ta đã đưa ra ở mô-đun 5. Điều đó ổn, miễn là chúng ta giải thích được lý do.

Đừng thiết kế từ Thiết lập

Có một thói quen tôi muốn bạn bỏ nếu bạn có: bắt đầu kiến trúc dữ liệu tại Thiết lập → Trình quản lý đối tượng → Đối tượng tùy chỉnh mới và vừa làm vừa nghĩ ra mô hình. Salesforce làm cho việc tạo mọi thứ dễ đến khó tin; đó là một điểm mạnh của nó, và là một trong những lý do mô hình dữ liệu yếu xuất hiện nhanh đến vậy. Vài cú nhấp và bạn có một đối tượng, thêm vài cú nữa và bạn có trường và một quan hệ. Rồi dữ liệu đến, flow được xây, báo cáo được tạo, tích hợp phụ thuộc vào nó, và đối tượng bạn tạo trong năm phút giờ rất tốn kém để thay đổi. Đó là Phép thử khả năng đảo ngược từ chương 1. Vì vậy trước khi nhấp Đối tượng tùy chỉnh mới, hãy vẽ mô hình.

Vật lý không có nghĩa là vĩnh viễn

Còn một lý do nữa để tôi giữ ba mô hình tách biệt: công nghệ thay đổi. Hôm nay một phần dữ liệu của Steve Trucking nằm trên lõi Salesforce. Ngày mai một phần có thể nằm trong Data 360, một kho dữ liệu hay một hệ thống chúng ta chưa chọn, và trợ lý AI cần biểu diễn riêng của nó. Kiến trúc vật lý có thể thay đổi, trong khi các khái niệm nghiệp vụ vẫn ổn định đáng kể: Đối tác bán lẻ, các lần giao và Người nhận vẫn tồn tại. Đó là điều làm cho mô hình logic có giá trị. Nó là một mô tả bền vững về việc kinh doanh, không gắn với cách triển khai hôm nay.

Kiến trúc sư quyết định gì ở đây

Khi biến một mô hình logic thành mô hình vật lý trên Salesforce, tôi đang quyết định:

• Thực thể nghiệp vụ nào ánh xạ vào các khả năng chuẩn của Salesforce, và thực thể nào cần đối tượng tùy chỉnh hay một cách biểu diễn khác.
• Các thuộc tính logic trở thành trường vật lý thế nào, và các quan hệ được triển khai trên nền tảng ra sao.
• Phi chuẩn hóa có chủ đích thuộc về đâu trong thiết kế vật lý.
• Dữ liệu nào thuộc về Salesforce, và dữ liệu nào thuộc về nơi khác.
• Những đặc điểm nào của nền tảng buộc mô hình vật lý phải khác mô hình logic.

Quan trọng nhất, tôi muốn có thể lần ngược từng quyết định. Nếu bạn chỉ vào thứ gì đó trong mô hình vật lý của tôi và hỏi “Cái này ở đó để làm gì?”, tôi phải có thể dẫn bạn ngược qua mô hình logic và mô hình khái niệm về đến một điều mà việc kinh doanh thực sự cần: nghiệp vụ → khái niệm → logic → vật lý.

Ngoài kỳ thi: AI thay đổi điều gì. AI giờ có thể đưa một tài liệu yêu cầu đi thẳng đến các đối tượng và trường Salesforce chỉ trong một bước nhảy. Điều đó làm cho trình tự trở nên quan trọng hơn, chứ không kém đi: nếu nó nhảy từ yêu cầu đến cấu hình, hãy yêu cầu nó cho thấy điều gì đã diễn ra ở giữa: nó quyết định cái gì là thực thể, chọn khóa nào, giả định quan hệ nào, và phi chuẩn hóa ở đâu. Đó là những quyết định kiến trúc, và kiến trúc sư vẫn cần nhìn thấy chúng.

Chúng ta bắt đầu chương này trong một cuộc gọi đầu tiên, lắng nghe các danh từ, và kết thúc với một mô hình vật lý chúng ta có thể lần ngược về việc kinh doanh. Giờ khi đã chọn xây trên Salesforce, câu hỏi tiếp theo đi sâu hơn: chúng ta thực sự đang xây trên loại nền tảng dữ liệu nào?

Tìm hiểu thêm

• Designing Record Access for Enterprise Scale: Parent-Child Data Skew (opens in a new tab), Salesforce Developers, Winter ‘27 (tiếng Anh, kiểm tra ngày 2026-10-02): “cấu hình quan hệ cha-con với không quá 10.000 bản ghi con cho một bản ghi cha.” Đây là một hướng dẫn về lệch dữ liệu (data skew), không phải giới hạn cứng; chương 7 đi sâu hơn.
• Roll-Up Summary Field (opens in a new tab), Salesforce Help (tiếng Anh, kiểm tra ngày 2026-10-12): một trường tổng hợp cuộn lên đếm hoặc cộng các bản ghi chi tiết thông qua một quan hệ chính-chi tiết.