Xây dựng mô hình logic
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)
Mô-đun 3 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: Vẽ các mối quan hệ · Tiếp theo: Đặt dữ liệu vào đúng chỗ
Câu hỏi mô-đun này trả lời: Làm sao biến một mô hình khái niệm thành một mô hình dữ liệu logic?
Mô hình khái niệm cho chúng ta biết những gì tồn tại ở Steve Trucking và chúng liên quan với nhau thế nào: các Đối tác bán lẻ và trung tâm phân phối của họ, bảng kê hàng và các lần giao, Người nhận, tuyến và điểm dừng, tổ giao hàng, xe tải và phân công tổ. Như vậy đủ cho một cuộc trò chuyện rất hiệu quả với phía nghiệp vụ. Nhưng cuối cùng tôi cần chi tiết hơn. Chúng ta cần biết gì về một lần giao? Điều gì làm một trung tâm phân phối khác với trung tâm khác? Chúng ta nhận diện một Người nhận thế nào? Điều gì thuộc về một phân công tổ chứ không thuộc về tổ hay xe tải? Những câu hỏi đó đưa chúng ta từ mô hình khái niệm đến một mô hình dữ liệu logic, và chúng ta vẫn chưa xây gì trên Salesforce.
Ngồi, Đứng yên, Mô hình hóa
Phần tiêu đề “Ngồi, Đứng yên, Mô hình hóa ”Trước tiên, quay lại những chú chó. Chúng ta đã có các hộp và các đường nối. Giờ là hai câu hỏi mới: chúng ta biết gì về mỗi thứ, và làm sao phân biệt thứ này với thứ khác?
Điều gì mô tả nó? Một con chó có tên và ngày sinh. Một chủ nuôi có tên, số điện thoại và địa chỉ. Một trò có tên và độ khó. Mỗi sự thật nằm trên hộp mà nó mô tả.
Rồi đến đối tượng nối. Bella làm trò Ngồi giỏi đến đâu, và học được khi nào: điều đó có mô tả Bella không? Không hẳn; cô ấy giỏi trò này hơn trò khác. Nó có mô tả trò Ngồi không? Không; mỗi con chó làm trò Ngồi một kiểu. Nó mô tả Bella và trò Ngồi cùng nhau, nên nó thuộc về Trò của chó: mức kỹ năng và ngày học được. Đó là lý do đối tượng nối tồn tại: có những sự thật chỉ thuộc về cặp đôi.
Con chó nào là con nào? Hãy thử cái tên trước. Có rất nhiều con chó tên Max, nên cái tên không duy nhất. Số điện thoại của chủ nuôi? Marcus có hai con chó dùng cùng một số điện thoại, người ta đổi số, và đó là dữ liệu cá nhân của ai đó, sẽ bị sao chép vào mọi hệ thống từng trỏ đến một con chó. Số vi mạch (microchip) trông khá hơn: nó duy nhất, và không thay đổi. Nhưng một chú chó con mới có thể chưa được gắn chip, và một khóa không thể để trống. Vì vậy số vi mạch vẫn được giữ, như một thứ con chó còn được biết đến qua, và con chó có Dog ID của riêng nó: một con số làm một việc nhàm chán duy nhất, phân biệt con chó này với con chó khác.
Đó cũng là những câu hỏi chúng ta giờ sẽ đặt cho Steve Trucking, và những lý do khiến cái tên, số điện thoại và số vi mạch đều không đạt sẽ trở thành một quy tắc tôi đã giữ nhiều năm.
Mô hình khái niệm cho biết cái gì tồn tại; mô hình logic cho biết nó có nghĩa gì dưới dạng dữ liệu
Phần tiêu đề “Mô hình khái niệm cho biết cái gì tồn tại; mô hình logic cho biết nó có nghĩa gì dưới dạng dữ liệu ”Hãy lấy Xe tải. Tôi cần biết gì về một chiếc xe tải? Có thể là số hiệu xe, số VIN, hãng, mẫu xe, năm sản xuất, biển số, số dặm hiện tại và trạng thái. Đó là các thuộc tính của Xe tải.
Giờ hãy lấy Giao hàng. Có thể là số đơn hàng của Đối tác bán lẻ, ngày giao, khung giờ đã hẹn, giờ đến thực tế, trạng thái, và lần giao có bao gồm lắp đặt hay chở máy cũ đi không. Một lần nữa, đó là các thuộc tính.
Mô hình khái niệm cho chúng ta biết Giao hàng tồn tại. Mô hình logic bắt đầu cho chúng ta biết một lần giao có nghĩa gì dưới dạng dữ liệu. Một cái hộp đơn giản như Xe tải hay Giao hàng có thể đại diện cho cả một tập trường.
Dù vậy, trong hầu hết sơ đồ của chúng ta các hộp vẫn đơn giản, vì ba lý do. Số lượng trường tăng lên. Trường nhanh chóng lỗi thời. Và mỗi trường có những chi tiết khó thể hiện trong một mô hình đối tượng: tên API, nhãn, kiểu dữ liệu và độ dài. Những chi tiết đó chắc chắn sẽ được ghi lại, chỉ là không trong mô hình dữ liệu đầu tiên. Khi thể hiện vài trường then chốt thực sự giúp kể câu chuyện, tôi sẽ vẽ một mô hình dữ liệu chi tiết: một lát cắt tập trung, chỉ với những trường quan trọng cho điểm cần nói.
Thuộc tính nên mô tả thực thể
Phần tiêu đề “Thuộc tính nên mô tả thực thể ”Đây là một câu hỏi đơn giản tôi dùng khi nhìn một thuộc tính: nó mô tả cái gì? Hãng xe rõ ràng mô tả chiếc xe tải. Nhưng tên các thành viên tổ trên một lần giao thì sao? Chúng mô tả lần giao? Hay chúng mô tả một tổ, tổ đó có một phân công, phân công đó phụ trách tuyến, và tuyến đó bao gồm điểm dừng này?
Đây là chỗ một mô hình dữ liệu bắt đầu phơi bày những thứ trông hoàn toàn hợp lý trên màn hình. Một điều phối viên nói: “Tôi muốn thấy tên của tổ trên lần giao.” Đó là một yêu cầu trải nghiệm người dùng hợp lệ. Nó không nhất thiết là yêu cầu lưu tên của tổ trên lần giao. Đó là hai việc khác nhau, và chúng ta sẽ quay lại điều này khi nói về chuẩn hóa. Bây giờ, hãy tập thói quen hỏi dữ kiện này thực sự mô tả thứ gì. Câu hỏi đó sẽ giúp bạn tránh được rất nhiều rắc rối.
Rồi chúng ta phải nói về ID duy nhất
Phần tiêu đề “Rồi chúng ta phải nói về ID duy nhất ”Thuộc tính mô tả các thứ. Nhưng còn một vấn đề khác cần giải: làm sao tôi biết cái nào là cái nào?
Hai Người nhận tên là John Smith. Họ có phải cùng một người không? Có thể; có thể không. Một cái tên là chưa đủ. Địa chỉ? Người ta chuyển nhà. Số điện thoại thay đổi. Địa chỉ email thay đổi. Ngay cả tên của một Đối tác bán lẻ cũng có thể thay đổi.
Điều này đưa chúng ta đến khóa: thứ cho phép chúng ta nhận diện duy nhất một thứ trong mô hình. Đây là lĩnh vực tôi đã hình thành một quan điểm khá mạnh qua nhiều năm. Với một mã định danh, tôi muốn bốn điều:
Duy nhất. Bất biến. Không mang ý nghĩa. Không bao giờ là dữ liệu cá nhân (PII).
Duy nhất. Một mã định danh phải nhận diện đúng một thứ. Nếu hai lần giao có thể có cùng giá trị, đó không phải là mã định danh lần giao đáng tin cậy. Tên thường không duy nhất, địa chỉ không nhất thiết duy nhất, và số điện thoại được dùng chung. Ngay cả những giá trị hôm nay trông duy nhất cũng có thể không còn khi bạn có đủ dữ liệu. Vậy hãy hỏi: hai cái này có bao giờ có cùng giá trị không? Nếu câu trả lời là có, hãy rất cẩn thận khi dùng nó làm ID duy nhất của bản ghi.
Bất biến. Điều này hay bị bỏ qua. Nếu chúng ta nhận diện một Đối tác bán lẻ bằng tên và đối tác đó đổi tên, chúng ta có thêm một đối tác mới không? Không. Thực thể kinh doanh vẫn vậy; một trong các thuộc tính của nó đã thay đổi. ID duy nhất của một bản ghi phải tồn tại qua những thay đổi của thứ nó nhận diện, điều đó loại bỏ tên, địa chỉ email, số điện thoại, địa chỉ và tên đăng nhập, dù chúng trông tiện lợi đến đâu khi chúng ta mới xây hệ thống.
Không mang ý nghĩa. Lần đầu nghe điều này thấy lạ. Tại sao tôi lại muốn một mã định danh không mang ý nghĩa? Vì ý nghĩa thay đổi. Hãy tưởng tượng ai đó tạo một mã lần giao mã hóa DC, Đối tác bán lẻ, ngày giao và số thứ tự: PHX-KEY-20261002-0042. Trông thật khéo. Rồi Người nhận dời lịch sang thứ Sáu. Chúng ta có đổi mã định danh không? Nếu không, nó đang nói dối chúng ta. Nếu có, chúng ta đã đổi ID duy nhất của lần giao chỉ vì một thuộc tính của nó thay đổi, và mọi hệ thống đã lưu ID cũ vừa mất dấu nó. Mã định danh đã cố làm hai việc: nhận diện lần giao và mô tả nó. Tôi thà để các thuộc tính mô tả nó và để mã định danh làm một việc nhàm chán duy nhất: nhận diện nó. Mã định danh nhàm chán là mã định danh tốt.
Không bao giờ là dữ liệu cá nhân. Điều này quan trọng đến mức tôi tách riêng. Đừng dùng thông tin nhận dạng cá nhân làm mã định danh chỉ vì nó trông duy nhất. Ở Steve Trucking, rất dễ bị cám dỗ nhận diện một Người nhận bằng số điện thoại. Nhưng một khóa được sao chép đến mọi nơi các hệ thống cần nối bản ghi: tích hợp, tệp xuất, nhật ký, tệp trạng thái gửi lại cho các Đối tác bán lẻ, kho dữ liệu, dữ liệu kiểm thử. Lấy số điện thoại làm khóa, và bạn đã rải dữ liệu cá nhân của một Người nhận khắp toàn bộ kiến trúc.
Một khóa cũng phải có mặt cho mọi bản ghi: không bao giờ null hay để trống. Nếu có người sẽ không, hoặc không nên phải, đưa cho bạn một giá trị, thì giá trị đó không thể là khóa. Đó là lý do các hệ thống tự cấp mã định danh nội bộ, và dữ liệu cá nhân, nếu bạn thực sự cần, trở thành một thuộc tính được bảo vệ.
Vậy quy tắc của tôi là: duy nhất, bất biến, không mang ý nghĩa, không bao giờ là dữ liệu cá nhân.
Khóa tự nhiên và khóa thay thế
Phần tiêu đề “Khóa tự nhiên và khóa thay thế ”Giới làm cơ sở dữ liệu có tên gọi cho một số điều này. Một khóa tự nhiên đã tồn tại sẵn trong dữ liệu nghiệp vụ: số VIN của một chiếc xe tải là một ví dụ tốt. Ứng dụng của chúng ta không phát minh ra nó, và nó đã mang ý nghĩa. Một khóa thay thế được tạo ra riêng để nhận diện bản ghi; nó không mô tả gì cả, nó chỉ nhận diện.
Trong hầu hết kiến trúc, tôi ưu tiên dùng khóa thay thế làm ID bản ghi nội bộ và giữ các mã định danh tự nhiên quan trọng làm thuộc tính. Điều đó không làm mã định danh tự nhiên trở nên xấu; chúng thường cực kỳ quan trọng. Chỉ là tôi không tự động biến chúng thành ID duy nhất của bản ghi. Hãy hỏi điều gì xảy ra nếu giá trị được sửa, định dạng lại, thay thế, dùng lại, bị thiếu, hoặc đến từ nhiều hệ thống nguồn. Đó là chỗ một quyết định trông đơn giản trở thành một quyết định kiến trúc.
Một thứ có thể có nhiều mã định danh hữu ích
Phần tiêu đề “Một thứ có thể có nhiều mã định danh hữu ích ”ID bản ghi nội bộ không nhất thiết là mã định danh mà mọi hệ thống khác dùng. Steve Trucking có thể nhận diện một lần giao trong nội bộ bằng một ID được sinh ra. Mỗi Đối tác bán lẻ biết cùng lần giao đó bằng số đơn hàng riêng của họ: Keystone trong bảng kê hàng CSV, Redrock trong API, Brightwave trong các thông điệp EDI. Và tám năm lịch sử trong RouteDesk, công cụ điều phối cũ, dùng ID lần giao riêng của RouteDesk.
Những mã định danh đó quan trọng. Chúng ta cần giữ chúng và ánh xạ chúng chính xác, vì một bản cập nhật trạng thái phải quay về mỗi đối tác theo số của chính họ. Nhưng không phải tất cả đều cần trở thành ID duy nhất của lần giao. “ID của nó là gì?” có thể có nhiều hơn một câu trả lời, và kiến trúc sư phải biết ID nào có thẩm quyền trong bối cảnh nào. Chúng ta sẽ quay lại điều này khi nói về dữ liệu chủ và tích hợp.
Quan hệ phụ thuộc vào ID duy nhất
Phần tiêu đề “Quan hệ phụ thuộc vào ID duy nhất ”Giờ hãy quay lại những đường nối chúng ta đã vẽ. Một bảng kê hàng liệt kê các lần giao. Một Người nhận nhận các lần giao. Một tổ có các phân công tổ. Những quan hệ đó chỉ hoạt động được vì chúng ta có thể nhận diện đáng tin cậy những thứ ở cả hai đầu.
Đây là chỗ nó gây hậu quả ở Steve Trucking. Một Đối tác bán lẻ sửa bảng kê hàng ngay trong ngày: một đơn hàng bị hủy, một mặt hàng được đổi, một địa chỉ mới. Nếu chúng ta không khớp được dòng đã sửa với lần giao đang có, theo số đơn hàng của đối tác, chúng ta sẽ tạo một lần giao thứ hai cho cùng một chiếc tủ lạnh, và một tổ có thể xuất hiện hai lần. Hộp, thuộc tính, khóa và quan hệ không phải là những ý tưởng tách rời. Chúng đều là các phần của cùng một mô hình.
Ở thời điểm này có thể bạn nghĩ: “Salesforce cấp cho mỗi bản ghi một ID.” Đúng, và chúng ta sẽ đến đó. Nếu dữ liệu nằm trong Salesforce, mỗi bản ghi nhận một ID do Salesforce sinh ra. Nó khó hiểu và khó đọc, nên chúng ta thường cũng cung cấp một trường ID mà con người dùng được, như số lần giao D-000184227, một trường Số tự động. Người ta thường nghĩ con số đó là ID của bản ghi, nhưng không phải: ID Salesforce vẫn nằm bên dưới. Một hệ thống hay cơ sở dữ liệu bên ngoài, Oracle hay SQL Server, cũng có ID duy nhất riêng. Nhưng kiến trúc cuối cùng có thể bao gồm Salesforce, ERP tài chính, Snowflake, Data 360, hệ thống của các đối tác và những hệ thống chưa tồn tại. Mô hình logic mô tả dữ liệu nghiệp vụ mà không khiến mọi quyết định phụ thuộc vào một công nghệ. Salesforce triển khai nó về mặt vật lý thế nào là một bước sau.
Kiến trúc sư quyết định gì ở đây
Phần tiêu đề “Kiến trúc sư quyết định gì ở đây ”Khi biến một mô hình khái niệm thành mô hình logic, tôi đang quyết định:
- Thuộc tính nào thực sự mô tả từng thực thể.
- Mỗi thực thể được nhận diện duy nhất thế nào, và mã định danh đó có đủ ổn định để làm ID duy nhất của nó không.
- Những mã định danh nghiệp vụ nào (số đơn hàng của đối tác, ID của hệ thống cũ) cần được giữ và ánh xạ.
- Thông tin nhạy cảm có đang bị dùng làm khóa không.
- Các quan hệ có nối các thực thể qua những ID duy nhất đáng tin cậy không.
Giờ chúng ta có thực thể, quan hệ, thuộc tính và ID duy nhất: những mầm mống của một mô hình dữ liệu logic thực sự. Nhưng vẫn còn một vấn đề. Rất dễ đặt dữ liệu hoàn toàn hợp lệ vào sai chỗ. Đó là lúc chuẩn hóa xuất hiện.
Tìm hiểu thêm
Phần tiêu đề “Tìm hiểu thêm ”- Custom Field Types (opens in a new tab), Salesforce Help (tiếng Anh, kiểm tra ngày 2026-10-09): Số tự động gán cho mỗi bản ghi một số duy nhất với định dạng hiển thị như tiền tố và các số 0 ở đầu; đó không phải là ID Salesforce của bản ghi. Xem thêm Auto-Number Fields Are Not Always Sequential (opens in a new tab) (tiếng Anh, kiểm tra ngày 2026-10-09).