Bỏ qua để đến nội dung
SteveTechArcSteveTechArc Courses

Các mô hình dữ liệu chuẩn

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 aisle of a builders' supply warehouse, its racks stacked with ready-made standard doors, windows and stair parts, a cart waiting in the aisle.
Hình ảnh được tạo bằng AI

Mô-đun 2 trong 10 của chương Kiến trúc dữ liệu Salesforce, chương 3 của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Nền tảng dữ liệu Salesforce: Hơn cả một cơ sở dữ liệu · Tiếp theo: Tự xây dựng: các đối tượng tùy chỉnh

Câu hỏi mô-đun này trả lời: Salesforce đã mô hình hóa sẵn những gì cho bạn, và chúng được ghép lại với nhau thế nào?

Ở mô-đun 1 tôi đã bảo bạn hãy nhìn về phi thuyền mẹ: trước khi phát minh ra thứ gì đó, hãy xem chính Salesforce làm điều đó thế nào. Mô-đun này là lúc chúng ta thực sự nhìn. Salesforce đã mô hình hóa sẵn rất nhiều nghiệp vụ cho bạn, trong các đối tượng chuẩn của nó, và hai trong số các mô hình đó gánh phần lớn công việc trong hầu hết các org tôi bước vào: mô hình Sales và mô hình Service. Trước khi có thể quyết định một thứ gì đó có xứng đáng là một đối tượng tùy chỉnh hay không, bạn cần biết những gì đã có sẵn. Đó là nội dung của hai mô-đun tiếp theo.

Điều gì làm nên một đối tượng chuẩn

Phần tiêu đề “Điều gì làm nên một đối tượng chuẩn ”

Một đối tượng chuẩn có sẵn ngay khi bạn bắt đầu. Salesforce đã xây nó, nó có một mục đích xác định, và nó đi kèm các trường và quan hệ của riêng nó. Bạn có thể thêm trường vào nó, xây tự động hóa quanh nó và thay đổi bố cục của nó, nhưng bạn không thể thiết kế lại nó: các trường và quan hệ chuẩn là của Salesforce.

Hãy nhìn vào các cái tên. Account, Contact, Case. Không có tiền tố, không có hậu tố. Đó là Salesforce giữ khoảng không gian đó cho riêng mình. Mọi thứ chúng ta xây đều kết thúc bằng __c, nên Salesforce có thể thêm đối tượng chuẩn mới bất cứ lúc nào mà không bao giờ xung đột với bất cứ thứ gì trong org của bạn. Và nó làm vậy thật, ở mỗi bản phát hành.

Ở một thời điểm nào đó, ai đó đã xây một đối tượng sản phẩm không thành công và phải bỏ lại phía sau. Đó là lý do tên API là Product2. Đó là phép thử đầu tiên của tôi khi ai đó nói với tôi họ biết Salesforce.

Mô hình Sales

Phần tiêu đề “Mô hình Sales ”

Bắt đầu từ bên trái, với Khách hàng tiềm năng (Lead): một người có thể trở thành khách hàng. Một khách hàng tiềm năng chưa thực sự là một phần của mô hình. Nó là một khu vực chờ. Khi bạn chuyển đổi nó, Salesforce tạo ra các bản ghi thật: một Tài khoản, một Liên hệ, và, nếu có một thương vụ, một Cơ hội. Đó là lý do tôi vẽ Khách hàng tiềm năng tách ra một bên.

Tài khoản là công ty. Các Liên hệ của nó là những người làm ở đó. Một Cơ hội là một thương vụ với tài khoản đó. Đến đây, chưa có gì nằm ngoài dự đoán của bạn.

Rồi mọi thứ bắt đầu thú vị. Trong thương vụ có gì? Mỗi dòng là một Sản phẩm cơ hội (Opportunity Product), và một Sản phẩm cơ hội không trỏ thẳng tới một Sản phẩm. Nó trỏ tới một Mục sổ giá (Price Book Entry): sản phẩm này, với giá này, trong sổ giá này. Mục sổ giá nằm giữa Sản phẩm và Sổ giá (Price Book), nên cùng một sản phẩm có thể có một giá trong sổ giá chuẩn và một giá khác trong sổ giá dành cho đối tác của bạn.

Đó là hai quan hệ đã trở thành sự vật, cái này nối tiếp cái kia. Bạn còn nhớ Mặt hàng giao ở chương 2, nằm giữa Giao hàng và Sản phẩm, và Trò của chó nằm giữa Chó và Trò không? Salesforce đã làm đúng điều đó ở đây, hai lần: Sản phẩm cơ hội nằm giữa Cơ hội và Mục sổ giá, và Mục sổ giá nằm giữa Sản phẩm và Sổ giá. Khi bạn đọc được điều đó, bạn đọc được phần lớn mô hình dữ liệu chuẩn.

Mô hình Sales Mô hình Sales. Một Khách hàng tiềm năng, ở phía bên trái, được chuyển đổi thành một Tài khoản. Một Tài khoản có các Liên hệ và Cơ hội. Một Cơ hội dùng một Sổ giá và chứa các Sản phẩm cơ hội. Mỗi Sản phẩm cơ hội được định giá bởi một Mục sổ giá. Một Sổ giá liệt kê các Mục sổ giá, và một Sản phẩm xuất hiện trong các Mục sổ giá, nên mỗi Mục sổ giá nối một Sản phẩm với một Sổ giá. chuyển đổi thành có có dùng chứa được định giá bởi liệt kê xuất hiện trong Khách hàng tiềm năng Tài khoản Liên hệ Cơ hội Sổ giá Sản phẩm cơ hội Mục sổ giá Sản phẩm đúng một không hoặc một một hoặc nhiều không hoặc nhiều © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Đây là chuỗi đó nhìn cận cảnh, với các trường giữ nó lại với nhau:

Chuỗi định giá nhìn cận cảnh Chuỗi định giá dưới dạng mô hình dữ liệu chi tiết. Một Sản phẩm cơ hội mang ID cơ hội, ID mục sổ giá, một số lượng và một giá bán, và được định giá bởi một Mục sổ giá. Mục sổ giá mang ID sổ giá, ID sản phẩm, một giá niêm yết và một cờ Dùng giá chuẩn (Use Standard Price). Một Sổ giá có một tên và một cờ Là sổ giá chuẩn (Is Standard); một Sản phẩm có một tên và một mã sản phẩm. được định giá bởi liệt kê xuất hiện trong Sổ giá ID sổ giá ID BẢN GHI Tên Là sổ giá chuẩn Sản phẩm cơ hội ID sản phẩm cơ hội ID BẢN GHI ID cơ hội ID mục sổ giá Số lượng Giá bán Mục sổ giá ID mục sổ giá ID BẢN GHI ID sổ giá ID sản phẩm Giá niêm yết Dùng giá chuẩn Sản phẩm ID sản phẩm ID BẢN GHI Tên Mã sản phẩm đúng một không hoặc một một hoặc nhiều không hoặc nhiều © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Một quy tắc khiến nhiều người vấp: có một sổ giá chuẩn, và một Mục sổ giá trong bất kỳ sổ giá nào khác có thể đơn giản dùng giá chuẩn của sản phẩm. Hãy biết một cơ hội dùng sổ giá nào trước khi bạn nạp sản phẩm cho nó.

Mô hình Service

Phần tiêu đề “Mô hình Service ”

Giờ sang phía bên kia của ngôi nhà. Cùng Tài khoản, cùng Liên hệ. Khi có điều gì trục trặc, khách hàng mở một Trường hợp (Case).

Trường hợp thường liên quan đến một thứ khách hàng đang có, và Salesforce có một đối tượng cho việc đó: Tài sản (Asset). Ở mô-đun 5 tôi sẽ gọi nó là đối tượng chuẩn mà người ta hay bỏ qua. Đó là một thứ khách hàng có, dù họ mua nó từ bạn hay không.

Và khách hàng được hưởng gì? Đó là Quyền lợi (Entitlement): mức hỗ trợ mà một tài khoản đủ điều kiện nhận, thường gắn với một tài sản, một sản phẩm hoặc một hợp đồng dịch vụ. Gắn một quyền lợi vào một trường hợp, và giờ trường hợp biết nó phải nhận mức hỗ trợ nào.

Mô hình Service Mô hình Service. Một Tài khoản có các Liên hệ, Trường hợp và Tài sản. Một Liên hệ báo cáo các Trường hợp. Một Trường hợp có thể liên quan đến một Tài sản, và một Quyền lợi, thuộc về một Tài khoản, bao phủ các Trường hợp. Một đường từ Trường hợp vòng qua góc của nó quay lại chính nó là Trường hợp cha (Parent Case): một trường hợp là cha của không hoặc nhiều trường hợp, và mỗi trường hợp có không hoặc một trường hợp cha. có có báo cáo sở hữu liên quan đến bao phủ là cha của Tài khoản Liên hệ Tài sản Trường hợp Quyền lợi đúng một không hoặc một một hoặc nhiều không hoặc nhiều © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Hãy nhìn đường chạy từ Trường hợp quay về chính nó. Mỗi trường hợp có một trường Trường hợp cha (Parent Case), và nó trỏ tới một trường hợp khác. Đó là một quan hệ tự tra cứu (self-lookup): một quan hệ từ một đối tượng tới chính nó. Nhiều người bối rối lần đầu thấy nó, nên đây là hai lý do tôi dùng nó.

Thứ nhất: một sự cố lớn được tách thành các sự cố nhỏ hơn. Khách hàng báo rằng toàn bộ hệ thống lắp đặt đã ngừng hoạt động. Chúng ta mở các trường hợp con cho mạng, phần cứng và cấu hình, mỗi cái được xử lý riêng, và tất cả đều được giải quyết dồn lên trên: trường hợp cha chưa xong cho đến khi tất cả chúng xong.

Thứ hai: lịch sử. Một trường hợp đã đóng tháng trước, và giờ cùng vấn đề đó quay lại. Trường hợp mới trỏ về trường hợp ban đầu, nên bất kỳ ai mở nó đều thấy chuyện này đã xảy ra trước đây, và khi đó người ta đã làm gì.

Chúng ta sẽ quay lại quan hệ tự tra cứu khi đến phần quan hệ ở mô-đun 7.

Hãy để ý rằng Tài khoản và Liên hệ nằm ở cùng một vị trí trong cả hai sơ đồ. Chúng là cùng những bản ghi. Một nhân viên kinh doanh và một nhân viên dịch vụ đang nhìn vào cùng một khách hàng, từ hai phía khác nhau của ngôi nhà. Đó là một trong những lập luận mạnh nhất để gắn với đối tượng chuẩn: các mô hình được xây ra để gặp nhau.

Tệp và tệp đính kèm

Phần tiêu đề “Tệp và tệp đính kèm ”

Không phải mọi thứ trên một bản ghi đều là một trường. Hợp đồng, ảnh, PDF và bảng tính là tệp, và chúng thuộc về Salesforce Files, không phải mô hình Attachments cũ, vốn là kế thừa. Nếu tài liệu đã nằm trong SharePoint Online, OneDrive, Google Drive hoặc Box, Files Connect cho phép người dùng truy cập nó từ Salesforce mà không cần sao chép vào.

Tệp được tính khác với bản ghi. Salesforce chia dung lượng lưu trữ làm hai: dung lượng lưu trữ tệp chứa tệp đính kèm, Files, Salesforce CRM Content, tệp Chatter và những thứ tương tự, còn dung lượng lưu trữ dữ liệu chứa các bản ghi của bạn. Dung lượng lưu trữ tệp tăng rất nhanh khi bản ghi nào cũng có ảnh hay bản quét, nên khối lượng lớn hình ảnh, như ảnh từ một ứng dụng hiện trường, thường nên nằm hoàn toàn bên ngoài Salesforce, với Salesforce chỉ giữ một liên kết. Mô-đun 4 sẽ quay lại chuyện đó.

Hai cột hay hai trăm cột

Phần tiêu đề “Hai cột hay hai trăm cột ”

Dung lượng lưu trữ dữ liệu cũng được tính khác với một cơ sở dữ liệu. Trong một cơ sở dữ liệu thông thường, một bảng có hai cột và một triệu dòng là nhỏ, còn một bảng có một trăm cột và một triệu dòng là một con voi. Salesforce cân chúng như nhau: phần lớn bản ghi được tính khoảng 2 KB, bất kể chúng có bao nhiêu trường. Có những ngoại lệ. Một chiến dịch được tính nhiều hơn, một thư email được tính theo kích thước thật của nó, và một tài khoản cá nhân được tính khoảng 4 KB, vì nó vừa là tài khoản vừa là liên hệ.

Đây là một mẹo. Mỗi khi bước vào một org mới, một trong những nơi đầu tiên tôi đến là Thiết lập → Mức sử dụng dung lượng lưu trữ (Setup → Storage Usage). Tôi thậm chí còn xin khách hàng một ảnh chụp màn hình ngay trong cuộc gọi đầu tiên. Màn hình đó không nói dối. Nó cho bạn biết đối tượng nào đang tăng, và đối tượng nào đã là những con voi.

Tài khoản cá nhân: khi khách hàng là một người

Phần tiêu đề “Tài khoản cá nhân: khi khách hàng là một người ”

Mô hình Tài khoản và Liên hệ hoạt động tuyệt vời cho một công ty và những người làm ở đó. Nhưng nếu khách hàng của bạn không phải là một công ty thì sao? Nếu đó là một người thì sao?

Đó là tài khoản cá nhân: một tài khoản và một liên hệ gộp vào một bản ghi duy nhất, dành cho các cá nhân. Các trường liên hệ của họ đi kèm theo, và các trường tùy chỉnh xuất hiện với hậu tố riêng, __pc. Mỗi bản ghi được tính vào cả dung lượng lưu trữ của tài khoản lẫn liên hệ, vì bên dưới nó là cả hai.

Một lời cảnh báo trước khi bạn bật chúng: một khi tài khoản cá nhân đã được bật, chúng không thể bị tắt. Đó là Phép thử khả năng đảo ngược từ chương 1 ở dạng thuần túy nhất. Mô-đun 5 cho bạn quan điểm của tôi về khi nào chúng đáng dùng.

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

Phần tiêu đề “Kiến trúc sư quyết định gì ở đây ”
  • Những phần nào của nghiệp vụ Salesforce đã mô hình hóa sẵn, trước khi thiết kế bất cứ thứ gì mới.
  • Một khái niệm thuộc về mô hình Sales, mô hình Service hay cả hai, biết rằng chúng dùng chung Tài khoản và Liên hệ.
  • Tài liệu và hình ảnh nằm ở đâu: Salesforce Files, một hệ thống tệp được kết nối, hay bên ngoài nền tảng với một liên kết.
  • Dữ liệu sẽ tốn bao nhiêu dung lượng lưu trữ, tính theo cách Salesforce tính: theo bản ghi, không theo cột.
  • Khách hàng là một công ty hay một người, trước khi bật một thứ không thể tắt.

Còn khi Salesforce không có thứ bạn cần? Bạn tự xây nó. Đó là phần tiếp theo.

Tìm hiểu thêm

Phần tiêu đề “Tìm hiểu thêm ”
  • OpportunityLineItem (opens in a new tab), Object Reference for the Salesforce Platform (tiếng Anh, kiểm tra ngày 2026-10-12): “một thành viên trong danh sách các sản phẩm Product2 gắn với một Opportunity”; Mục sổ giá là bắt buộc.
  • PricebookEntry (opens in a new tab), Object Reference (tiếng Anh, kiểm tra ngày 2026-10-12): “một liên kết giữa một Pricebook2 và Product2”; một mục có thể dùng giá chuẩn.
  • Case (opens in a new tab), Object Reference (tiếng Anh, kiểm tra ngày 2026-10-12): ParentId, “ID của trường hợp cha trong phân cấp. Nhãn là Parent Case”; một quan hệ tra cứu tới Case.
  • Entitlement (opens in a new tab), Object Reference (tiếng Anh, kiểm tra ngày 2026-10-12): “mức hỗ trợ khách hàng mà một tài khoản hoặc liên hệ đủ điều kiện nhận”, có thể dựa trên một tài sản, sản phẩm hoặc hợp đồng dịch vụ.
  • Data and Storage Resources (opens in a new tab), Salesforce Help (tiếng Anh, kiểm tra ngày 2026-10-12): dung lượng lưu trữ tệp và dung lượng lưu trữ dữ liệu bao gồm những gì.
  • Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Salesforce Help (tiếng Anh, kiểm tra ngày 2026-10-12): “Phần lớn bản ghi Salesforce chiếm khoảng 2 KB dung lượng lưu trữ dữ liệu”; tài khoản cá nhân khoảng 4 KB.
  • Enable Person Accounts (opens in a new tab), Salesforce Help (tiếng Anh, kiểm tra ngày 2026-10-12): “Sau khi Person Accounts được bật, không thể tắt nó.”
  • Files Connect FAQ (opens in a new tab), Salesforce Help (tiếng Anh, kiểm tra ngày 2026-09-25).