Mô hình dữ liệu là bộ xương
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 2 trong 7 của chương Tư duy như một kiến trúc sư dữ liệu, chương đầu tiên của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Tư duy như một kiến trúc sư · Tiếp theo: Phép thử khả năng đảo ngược
Câu hỏi mô-đun này trả lời: Vì sao mô hình dữ liệu quan trọng hơn bất cứ thứ gì được xây trên nó, và bạn đánh giá một mô hình thế nào?
Khi dạy kiến trúc dữ liệu, có một câu tôi cứ quay lại mãi: mô hình dữ liệu là bộ xương.
Mô hình dữ liệu là bộ xương của hệ thống. Mọi thứ khác được xây quanh nó, và nó là thứ giữ phần còn lại của cơ thể gắn kết với nhau. Bạn không nhìn thấy bộ xương khi nhìn một người, nhưng nó quyết định người đó cao bao nhiêu, di chuyển ra sao và mang vác được gì.
Hãy nghĩ về mọi thứ chúng ta xây trong một dự án triển khai Salesforce. Chúng ta xây tự động hóa quanh mô hình dữ liệu. Chúng ta viết Apex dựa trên nó, và các Flow đọc và cập nhật nó. Chúng ta xây các tích hợp đưa dữ liệu vào và lấy dữ liệu ra khỏi nó. Chúng ta tạo báo cáo và phân tích trên nó, và thiết kế bảo mật quanh nó. Và ngày càng nhiều, chúng ta xây các tác tử AI cần hiểu và hành động dựa trên dữ liệu đó. Tất cả đều phụ thuộc vào cấu trúc bên dưới.
Đó là lý do làm đúng mô hình dữ liệu từ sớm lại quan trọng đến vậy. Bạn có thể thay bộ xương sau này. Nhưng có lẽ sẽ đau đấy.
Bắt đầu từ việc kinh doanh
Phần tiêu đề “Bắt đầu từ việc kinh doanh ”Một mô hình dữ liệu tốt bắt đầu bằng một câu hỏi đơn giản: việc kinh doanh thực sự cần biểu diễn điều gì? Không phải “chúng ta có những đối tượng Salesforce nào?” Và chắc chắn không phải “tôi có thể xây nhanh cái gì?”
Chúng ta đang cố hiểu việc kinh doanh trước. Những thứ quan trọng trong doanh nghiệp này là gì? Chúng liên quan với nhau thế nào? Ai sở hữu chúng? Chúng thay đổi theo thời gian ra sao? Điều gì cần được ghi nhớ, và điều gì được dùng chung giữa các quy trình nghiệp vụ? Chỉ sau khi hiểu những điều đó, chúng ta mới nên bắt đầu chuyển chúng thành đối tượng, trường và quan hệ.
Nghe thì hiển nhiên. Trên thực tế, rất dễ làm ngược. Ai đó nhận ra một thứ trông giống Cơ hội, Trường hợp hay Tài sản và lập tức bắt đầu thiết kế quanh nó. Đôi khi như vậy là hoàn toàn đúng. Đôi khi chúng ta đang cố nhét cái chốt vuông vào lỗ tròn, và khi đã có đủ thứ được xây quanh quyết định đó, rút cái chốt ra sẽ rất tốn kém.
Đây là một câu hỏi tôi nghe suốt. Doanh nghiệp của một khách hàng có thể có nhiều địa điểm giao hàng. Mỗi địa điểm nên là một Tài khoản hay một đối tượng tùy chỉnh? Trước khi trả lời, hãy để ý những gì bạn cần biết trước: một địa điểm có ý nghĩa gì với doanh nghiệp này, và điều gì xảy ra với nó. Đó là mô hình hóa việc kinh doanh trước khi nghĩ đến đối tượng. (Tôi sẽ cho bạn câu trả lời của tôi ở chương 3.)
Hỗ trợ. Phát triển. Vận hành tốt.
Phần tiêu đề “Hỗ trợ. Phát triển. Vận hành tốt. ”Khi xem xét một mô hình dữ liệu, tôi muốn nó vượt qua ba phép thử: hỗ trợ việc kinh doanh, phát triển cùng việc kinh doanh, và vận hành tốt.
Hỗ trợ. Mô hình phải hỗ trợ điều doanh nghiệp thực sự đang cố đạt được. Có một khác biệt lớn giữa một mô hình về mặt kỹ thuật có thể lưu dữ liệu và một mô hình thực sự biểu diễn tốt việc kinh doanh. Nếu tôi liên tục phải thêm những trường kỳ lạ, những cờ đặc biệt, tự động hóa phức tạp và các ngoại lệ vì mô hình không hoàn toàn khớp, tôi bắt đầu tự hỏi liệu vấn đề có thực sự nằm ở tự động hóa không. Có thể mô hình sai. Một mô hình tốt nên làm cho việc kinh doanh dễ hiểu hơn, chứ không khó hơn.
Phát triển. Khi nói phát triển, tôi không chỉ nói đến nhiều bản ghi hơn. Khối lượng có quan trọng: mười nghìn bản ghi và một trăm triệu bản ghi tạo ra những vấn đề rất khác nhau. Nhưng doanh nghiệp cũng tăng trưởng về độ phức tạp. Họ thêm sản phẩm, vào thị trường mới, mua lại công ty, thay đổi quy trình, thêm kênh và kết nối hệ thống mới. Họ phát hiện ra một thứ họ tưởng là một hóa ra lại là năm thứ khác nhau. Một mô hình chạy tuyệt vời cho hôm nay có thể thành cái bẫy nếu không có chỗ cho ngày mai. Đó là lý do tôi thích những thiết kế phát triển bằng cách bổ sung hơn là những thiết kế cứ thay đổi những gì đã có. Thêm thứ mới thường dễ hơn định nghĩa lại một thứ mà hàng chục thứ khác phụ thuộc vào.
Vận hành tốt. Dữ liệu không chỉ nằm yên đó. Chúng ta ghi nó, tìm nó, truy vấn nó, chia sẻ nó, báo cáo trên nó và tích hợp nó, và ngày càng nhiều hệ thống AI truy xuất nó làm ngữ cảnh trước khi hành động. Một mô hình có thể trông đẹp trên sơ đồ mà vẫn rất tệ khi vận hành. Vì vậy chúng ta thiết kế cho cả cách dữ liệu được lưu trữ và cách dữ liệu sẽ được sử dụng.
Và nó phải tiếp tục vận hành tốt. Nó phải vận hành tốt ở quy mô lớn: khi số người dùng tăng, khi khối lượng dữ liệu tăng, trong điều kiện thực tế và vào lúc cao điểm, vào ngày bận rộn nhất trong năm chứ không phải ngày trung bình. Và nó phải tiếp tục vận hành tốt khi có chuyện bất ngờ xảy ra.
Hỗ trợ. Phát triển. Vận hành tốt. Chúng ta sẽ còn quay lại ba phép thử này suốt khóa học.
Quá phẳng, quá phức tạp, hay đơn giản là sai
Phần tiêu đề “Quá phẳng, quá phức tạp, hay đơn giản là sai ”Tôi đã thấy mô hình dữ liệu đi sai theo ba cách.
Cách thứ nhất là chọn sai thứ ngay từ đầu. Chúng ta dùng một đối tượng chuẩn vì nó trông đủ gần, rồi dành nhiều năm thêm ngoại lệ vì nó chưa bao giờ thực sự phù hợp. Đó là cái chốt vuông.
Cách thứ hai là làm mô hình quá phẳng. Mọi thứ dồn vào một đối tượng, và lúc đầu điều đó có vẻ đơn giản tuyệt vời. Rồi doanh nghiệp phát triển, và chúng ta phát hiện một số thứ trong đó có vòng đời riêng, có thể có nhiều thực thể, cần bảo mật riêng hoặc có quan hệ riêng. Bỗng nhiên chúng ta biểu diễn một quan hệ một-nhiều bằng Field 1, Field 2 và Field 3, hoặc bằng những cờ và tự động hóa ngày càng phức tạp. Mô hình không chừa cho chúng ta chỗ nào để phát triển.
Cách thứ ba là sai lầm ngược lại: chúng ta chuẩn hóa quá mức. Chúng ta tạo một sơ đồ thanh lịch với hết đối tượng này đến đối tượng khác, mọi khái niệm được tách bạch hoàn hảo. Đẹp về kỹ thuật, khổ sở trong thực tế. Người dùng khó hiểu nó, và các bố cục trang và trang Lightning, với hết danh sách liên quan này đến danh sách liên quan khác, có thể bắt đầu sâu hun hút. Truy vấn phức tạp hơn, tự động hóa đi qua nhiều quan hệ hơn, báo cáo khó hơn, và nền tảng phải làm nhiều việc hơn để trả lời những câu hỏi nghiệp vụ bình thường.
Vậy cái nào đúng, phẳng hay chuẩn hóa? Không có công thức nào cả. Bạn giữ trong đầu hình ảnh của mô hình tối ưu và hiểu những đánh đổi khi bạn rời xa nó. Đó là nghệ thuật của kiến trúc, và chúng ta sẽ quay lại điều này ở mô-đun 4 và ở chương tiếp theo, nơi chúng ta học cách mô hình hóa. Bây giờ, hãy nhận ra rằng bản thân cấu trúc đã là một quyết định kiến trúc.
Hãy cẩn thận khi thay đổi bộ xương
Phần tiêu đề “Hãy cẩn thận khi thay đổi bộ xương ”Khi một hệ thống đã chạy, tôi trở nên rất thận trọng với những thay đổi nền tảng trong mô hình dữ liệu.
Giả sử một trường văn bản đã tồn tại nhiều năm, và ai đó nói: “Thực ra chúng ta không còn dùng nó theo cách đó nữa. Đổi nó thành số đi.” Nghe như một thay đổi trường. Nhưng cái gì phụ thuộc vào trường đó? Các Flow, Apex, báo cáo, tích hợp, đường ống dữ liệu, ứng dụng bên ngoài, tác tử AI. Và dữ liệu lịch sử sẽ ra sao? Chính nền tảng cũng không cho bạn đổi kiểu của một trường khi mã hoặc flow vẫn tham chiếu đến nó, điều đó cho bạn thấy thay đổi lan xa đến đâu.
Đôi khi câu trả lời đúng là không biến đổi những gì đã có. Tùy theo mức độ nghiêm trọng của thay đổi, tôi thà tạo một thứ mới, di chuyển dữ liệu có chủ đích, rồi ngừng dùng cấu trúc cũ:
Bổ sung thay vì biến đổi. Ngừng dùng có báo trước thay vì gây bất ngờ.
Salesforce thậm chí cho bạn cách nói điều đó trong siêu dữ liệu: Field Usage của một trường có thể đặt là DeprecateCandidate, “dự kiến ngừng dùng và không còn được sử dụng”. Điều đó đánh dấu trường cho tất cả những ai đọc đối tượng; nó không ẩn trường đi, nên việc cho trường nghỉ hưu vẫn là một quyết định bạn phải thực hiện.
Bởi vì khi các phần khác của kiến trúc đã phụ thuộc vào một thứ, thay đổi ý nghĩa của nó có thể nguy hiểm hơn nhiều so với đổi tên nó. Trường hợp tệ nhất là trường giữ nguyên tên trong khi nội dung thay đổi: mọi thứ phía sau vẫn tin vào cái tên.
Ngay cả việc đơn giản như đánh dấu ô Bắt buộc trên một trường cũng có thể thành quả bom hẹn giờ. Nếu bạn đã thu thập dữ liệu, một số bản ghi sẽ không có giá trị ở trường đó. Rồi vài ngày, vài tuần hay vài tháng sau, ai đó cập nhật một trong những bản ghi ấy, và lệnh lưu thất bại vì trường bắt buộc, mà không ai có giá trị đó. Một thay đổi đơn giản như đánh dấu một trường là bắt buộc có thể gây ra hệ quả ngoài ý muốn và đến muộn. Chúng ta sẽ quay lại chuyện Bắt buộc, và khi nào một giá trị thực sự được biết, ở chương 3.
Ngoài kỳ thi: AI cũng xây trên bộ xương. Hãy nhờ một công cụ AI xây một ứng dụng và nó sẽ sinh ra các đối tượng, trường, Flow, Apex, thành phần và bài kiểm thử trong vài phút. Nếu mô hình dữ liệu ban đầu sai, chúng ta không tránh được hệ quả của một quyết định tồi; chúng ta đẩy nhanh nó, vì mỗi lớp được sinh ra lại là thêm một thứ phụ thuộc vào cấu trúc đó. Đó là lý do tôi muốn một kiến trúc sư con người xem xét mô hình dữ liệu do AI sinh ra, hiểu nó và chịu trách nhiệm về nó. Mô-đun 7 đi xa hơn về điều này.
Bộ xương đi trước
Phần tiêu đề “Bộ xương đi trước ”Trong suốt khóa học này, chúng ta sẽ nói về rất nhiều công nghệ: đối tượng và quan hệ, khối lượng dữ liệu lớn, truy vấn, tích hợp, di chuyển dữ liệu, giao dịch, bảo mật, Data 360 và AI. Bên dưới tất cả là mô hình dữ liệu.
Nếu mô hình hỗ trợ việc kinh doanh, có thể phát triển cùng việc kinh doanh và vận hành tốt cho những cách chúng ta sẽ dùng dữ liệu, chúng ta đã xây một nền móng vững chắc. Nếu làm sai nền móng, mọi thứ sau đó đều khó hơn.
Mô hình dữ liệu là bộ xương. Kiến trúc sư nên hết sức cẩn thận khi thiết kế bộ xương. Thay đổi những cấu trúc đã có có thể gây ra hệ quả dây chuyền.
Kiến trúc sư quyết định gì ở đây
Phần tiêu đề “Kiến trúc sư quyết định gì ở đây ”- Mô hình có hỗ trợ việc kinh doanh, có phát triển cùng nó và có vận hành tốt cho những cách dữ liệu sẽ được dùng hay không.
- Một khái niệm phù hợp với một đối tượng chuẩn hay là một cái chốt vuông.
- Làm mô hình phẳng đến mức nào hay chuẩn hóa đến mức nào, và tại sao.
- Một thay đổi ở bộ xương nên là một sự bổ sung, một lần di chuyển dữ liệu hay một lần ngừng dùng, thay vì thay đổi tại chỗ.
Tìm hiểu thêm
Phần tiêu đề “Tìm hiểu thêm ”- Considerations for Converting the Field Type of a Custom Field (opens in a new tab), Salesforce Help (tiếng Anh, kiểm tra ngày 2026-10-02; kiểm tra lại ngày 2026-10-12): những thay đổi kiểu nào có thể làm mất dữ liệu, và vì sao bạn không thể đổi kiểu của một trường mà Apex, flow hay process đang tham chiếu.
- Data Classification Metadata Fields (opens in a new tab), Salesforce Help (tiếng Anh, kiểm tra ngày 2026-10-02; kiểm tra lại ngày 2026-10-12): các giá trị Field Usage (Active, DeprecateCandidate, Hidden) và các trường phân loại khác.