Mô hình hóa dữ liệu vì ý nghĩa
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 2 của khóa học Data Architect. Hãy đọc sáu 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ư.
Chương này là nền móng cho phần Data Modeling and Database Design của kỳ thi, chiếm một phần tư đề thi. Nó bao quát cách tư duy; chương tiếp theo, Kiến trúc dữ liệu Salesforce, bao quát cách nền tảng xây nó. Vì vậy phần lớn những gì được kiểm tra về đối tượng, trường và quan hệ cần đến cả hai chương.
Cho kỳ thi
Phần tiêu đề “Cho kỳ thi ”Những điểm từ chương này có khả năng quan trọng nhất trong kỳ thi. Mỗi điểm gắn với mục tiêu thi của nó và liên kết đến nơi được giảng dạy. Hãy đánh dấu khi bạn đi qua.
DM-1: so sánh các kỹ thuật thiết kế mô hình dữ liệu Salesforce
- Tôi có thể giải thích khác biệt giữa mô hình dữ liệu khái niệm, logic và vật lý, và mỗi loại dùng để làm gì. (Chuyển mô hình vào Salesforce)
- Tôi có thể tìm các thực thể ứng viên trong một yêu cầu, và phân biệt một người đang làm một công việc với một mẩu dữ liệu. (Danh từ cho bạn các thực thể ứng viên)
- Tôi có thể đọc và vẽ ký hiệu chân quạ: một, nhiều, và ký hiệu thứ hai cho tùy chọn hay bắt buộc. (Đọc các đường nối, Tính tùy chọn cũng quan trọng)
- Tôi có thể gọi tên lực lượng của một quan hệ: một-một, một-nhiều, nhiều-nhiều. (Hãy hỏi “Một hay nhiều?”)
- Tôi biết một quan hệ nhiều-nhiều trở thành một thực thể riêng, và trong Salesforce thường là một đối tượng nối có hai cha. (Quan hệ có thể trở thành một thứ)
- Tôi biết khi nào một quan hệ cần lịch sử (một bản ghi có ngày bắt đầu và kết thúc) thay vì một trường bị ghi đè. (Thời gian làm thay đổi quan hệ)
- Tôi có thể chọn một ID duy nhất tốt, và tôi biết vì sao một khóa tự nhiên hay bất cứ thứ gì chứa thông tin cá nhân là một lựa chọn rủi ro. (Rồi chúng ta phải nói về ID duy nhất)
- Tôi biết khác biệt giữa khóa tự nhiên và khóa thay thế, và một bản ghi có thể mang nhiều mã định danh bên ngoài. (Khóa tự nhiên và khóa thay thế)
- Tôi biết một trường Số tự động là một con số dễ đọc, không phải ID Salesforce của bản ghi. (Quan hệ phụ thuộc vào ID duy nhất)
- Tôi có thể áp dụng dạng chuẩn thứ nhất, thứ hai và thứ ba, và nhận ra một trường chứa nhiều giá trị hay lặp lại một dữ kiện về thứ khác. (Một cách đơn giản để nghĩ về 1NF, 2NF và 3NF)
- Tôi có thể giải thích khi nào nên phi chuẩn hóa có chủ đích (người dùng, báo cáo, quy mô), và cái giá của nó. (Thiết kế theo dạng chuẩn thứ ba, rồi lùi lại)
- Tôi có thể quyết định giữa một danh sách chọn và một quan hệ tra cứu đến một đối tượng cho một danh sách giá trị. (Quan hệ tra cứu hay danh sách chọn?)
- Tôi biết một loại báo cáo tùy chỉnh cho phép tối đa bốn quan hệ đối tượng, và vì sao điều đó quan trọng với các mô hình sâu. (Quan hệ tra cứu hay danh sách chọn?)
- Tôi biết khi nào chính-chi tiết phù hợp (bản ghi con không bao giờ đổi cha) và khi nào một quan hệ tra cứu an toàn hơn, bao gồm khuyến nghị của Salesforce về không quá 10.000 bản ghi con trên một bản ghi cha. (Quan hệ trở thành quyết định nền tảng)
- Tôi biết vì sao nên tránh quan hệ đa hình khi có thể. (Quan hệ trở thành quyết định nền tảng)
- Tôi biết một thực thể nghiệp vụ không tự động là một đối tượng tùy chỉnh: nó có thể là một đối tượng chuẩn, một trường, cấu hình, hoặc dữ liệu nằm ngoài Salesforce. (Một thực thể nghiệp vụ không tự động là một đối tượng tùy chỉnh)
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.
- Hãy quên Salesforce đi một chút. Mô hình hóa việc kinh doanh trước khi ánh xạ nó vào Tài khoản và Liên hệ.
- Hãy lắng nghe từ ẩn chứa hai thứ. Ở Steve Trucking, “khách hàng” vừa là một Đối tác bán lẻ vừa là một Người nhận.
- Mô hình là một phần của cuộc trò chuyện. Mô hình đầu tiên của bạn không cần đúng; nó cần cho bạn thấy mình sai ở đâu.
- Hãy đặt tên cho các đường nối. Hai mô hình có cùng các hộp có thể mang ý nghĩa khác nhau.
- Với mọi quan hệ, hãy hỏi “hiện tại, hay theo thời gian?”
- Duy nhất, bất biến, không mang ý nghĩa, không bao giờ là dữ liệu cá nhân.
- Hãy đặt một dữ kiện vào đúng chỗ của nó, rồi lùi lại có chủ đích, và ghi lại lý do.
- Phi chuẩn hóa không loại bỏ độ phức tạp; nó dịch chuyển độ phức tạp. Hãy biết ai sở hữu sự thật.
- Một nguồn sự thật, nhiều hình dạng: màn hình, báo cáo, kho dữ liệu và AI.
- Đừng thiết kế từ Thiết lập. Hãy vẽ mô hình trước khi nhấp Đối tượng tùy chỉnh mới.
- Hãy lần ngược mọi quyết định vật lý về đến một điều việc kinh doanh cần.
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 |
|---|---|
| Thực thể | Một thứ mà việc kinh doanh quan tâm và lưu dữ liệu về nó |
| Thực thể ứng viên | Một danh từ có thể trở thành thực thể, sau khi bạn đã hỏi về nó |
| Thuộc tính | Một dữ kiện mô tả một thực thể |
| Quan hệ | Hai thực thể được nối với nhau thế nào, được đặt tên bằng ngôn ngữ nghiệp vụ |
| Lực lượng | Bao nhiêu cái này liên quan đến bao nhiêu cái kia |
| Tính tùy chọn | Quan hệ là bắt buộc, hay có thể bằng không |
| Chân quạ | Ký hiệu “nhiều” ở đầu một đường nối |
| Đối tượng nối | Cách Salesforce xây một quan hệ nhiều-nhiều: một bản ghi con của cả hai cha |
| Mô hình khái niệm | Những gì tồn tại trong việc kinh doanh và chúng liên quan thế nào; không có Salesforce |
| Mô hình logic | Dữ liệu: thuộc tính, ID duy nhất và quan hệ, vẫn chưa gắn với một nền tảng |
| Mô hình vật lý | Nền tảng sẽ xây nó thế nào: đối tượng, trường và kiểu quan hệ |
| Khóa tự nhiên | Một mã định danh đã tồn tại trong việc kinh doanh, như số VIN của một xe tải |
| Khóa thay thế | Một mã định danh được tạo ra chỉ để nhận diện bản ghi |
| Mã định danh bên ngoài | ID của một hệ thống khác cho cùng bản ghi, được giữ và ánh xạ |
| Chuẩn hóa (1NF, 2NF, 3NF) | Đặt mỗi dữ kiện vào đúng chỗ: một giá trị cho mỗi trường, dữ kiện về toàn bộ khóa, không có dữ kiện về dữ kiện khác |
| Phi chuẩn hóa | Sao chép hoặc làm phẳng dữ liệu có chủ đích, vì một lý do bạn gọi tên được |
| Dị thường cập nhật | Cùng một dữ kiện được lưu ở nhiều nơi, nên một thay đổi để lại vài bản sao bị sai |
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. Một doanh nghiệp cho bạn biết một tổ giao hàng lái một xe tải. Sáu tuần sau, ai đó hỏi vào một ngày cụ thể tổ nào đã dùng xe tải 117. Lẽ ra mô hình phải có gì?
Một Phân công tổ: quan hệ giữa tổ và xe tải dưới dạng một bản ghi riêng, với ngày bắt đầu, ngày kết thúc và tuyến. Tổ và xe tải có quan hệ nhiều-nhiều theo thời gian, và việc kinh doanh quan tâm đến lịch sử. Một trường trên xe tải sẽ bị ghi đè. Đọc lại Thời gian làm thay đổi quan hệ.
2. Một nhóm đề xuất dùng số điện thoại của mỗi Người nhận làm ID duy nhất, “vì nó duy nhất”. Bạn nói gì?
Nó trượt các phép thử: số điện thoại thay đổi và được dùng chung, nên nó không bất biến cũng không duy nhất một cách đáng tin cậy, và đó là thông tin cá nhân sẽ bị sao chép vào mọi hệ thống liên kết với bản ghi. Hãy dùng một ID được sinh ra không mang ý nghĩa và giữ số điện thoại làm thuộc tính. Đọc lại Rồi chúng ta phải nói về ID duy nhất.
3. Một Giao hàng có các trường Item 1, Item 2 và Item 3. Một lần giao có bốn mặt hàng đến. Vấn đề thực sự là gì, và cách sửa ra sao?
Mô hình đã giấu một cấu trúc lặp bên trong các trường (một vấn đề của dạng chuẩn thứ nhất). Cách sửa không phải là thêm trường Item 4; mà là một thực thể Mặt hàng giao, con của Giao hàng, để mỗi mặt hàng là một bản ghi. Đọc lại Dạng chuẩn thứ nhất.
4. Mỗi lần giao lưu tên của quản lý trung tâm phân phối. Người quản lý thay đổi. Điều gì đã sai?
Một dữ kiện về một thứ khác (trung tâm phân phối) đã được lưu trên lần giao: một vấn đề của dạng chuẩn thứ ba, và giờ là một dị thường cập nhật trên hàng trăm bản ghi. Người quản lý thuộc về trung tâm phân phối; lần giao trỏ đến trung tâm phân phối. Đọc lại Dạng chuẩn thứ ba.
5. Loại điểm dừng (chỉ giao hàng, kèm lắp đặt, kèm chở máy cũ đi) cần thời lượng, kỹ năng của tổ và một danh sách kiểm tra. Danh sách chọn hay đối tượng?
Một đối tượng. Nó có nhiều hơn một cột thông tin, được phía nghiệp vụ quản lý và thay đổi theo lịch riêng. Trạng thái của một lần giao, một danh sách nhãn ngắn và ổn định, vẫn là danh sách chọn. Đọc lại Quan hệ tra cứu hay danh sách chọn?.
6. Các đối tác muốn một bảng điểm giao đúng hẹn theo khu vực, và khu vực nằm trên trung tâm phân phối. Bạn sao chép khu vực lên từng lần giao. Bạn phải quyết định điều gì?
Ai sở hữu sự thật, bản sao được giữ đồng bộ thế nào, và các lần giao cũ nên giữ khu vực đúng vào lúc chúng diễn ra hay đi theo trung tâm phân phối nếu nó chuyển đi. Phi chuẩn hóa đã dịch chuyển độ phức tạp; nó không loại bỏ độ phức tạp. Đọc lại Đôi khi báo cáo thắng.
7. Một trò như Ngồi có thể liên kết với hàng trăm nghìn thú cưng. Từ Trò của thú cưng đến Trò nên là chính-chi tiết hay tra cứu?
Tra cứu. Khuyến nghị của Salesforce là không quá 10.000 bản ghi con trên một bản ghi cha, và một trò phổ biến sẽ vượt qua con số đó. Chính-chi tiết phù hợp cho Trò của thú cưng đến Thú cưng, vì trò của một thú cưng không bao giờ đổi cha và một thú cưng chỉ biết vài trò; đó cũng là điều cho phép thú cưng cuộn lên con số Số trò đã biết của nó. Đọc lại Ngồi, Đứng yên, Mô hình hóa.
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.