Thiết kế theo dạng chuẩn thứ ba, rồi lùi lại

🌐 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 5 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: Đặt dữ liệu vào đúng chỗ · Tiếp theo: Chuyển mô hình vào Salesforce

Câu hỏi mô-đun này trả lời: Khi nào tôi nên cố ý rời khỏi một mô hình đã chuẩn hóa gọn gàng?

Ở mô-đun trước, tôi bảo bạn thiết kế theo Dạng chuẩn thứ ba.

Giờ tôi sẽ bảo bạn phá vỡ nó.

Đôi khi.

Đó là một phân biệt quan trọng. Có khác biệt lớn giữa vô tình xây một mô hình dữ liệu lộn xộn và cố ý phi chuẩn hóa một mô hình gọn gàng. Nếu ngay từ đầu bạn không hiểu dữ liệu thuộc về đâu, sao chép nó sang chỗ khác không phải là kiến trúc. Đó chỉ là trùng lặp.

Nhưng khi đã hiểu mô hình logic gọn gàng, tôi có thể đưa ra quyết định có ý thức để định hình dữ liệu khác đi cho những người và hệ thống sử dụng nó.

Thiết kế theo dạng chuẩn thứ ba khi khả thi. Rồi lùi lại khi cần thiết.

Hãy để ý điều câu đó không nói. Nó không nói dạng chuẩn thứ ba dễ hiểu hơn. Đôi khi nó khó hơn: một mô hình chuẩn hóa hoàn toàn có thể rải một ý tưởng nghiệp vụ ra năm đối tượng, và người dùng phải tự ráp nó lại trong đầu. Chuẩn hóa cho tôi biết mỗi dữ kiện thuộc về đâu. Nó không hứa đó là hình dạng dễ đọc, dễ dùng hay dễ báo cáo nhất. Đó chính là lý do lùi lại là một kỹ năng thiết kế chứ không phải một thất bại.

Hãy bắt đầu bằng việc mô hình hóa sự thật. Rồi quyết định sự thật đó cần được đưa đến như thế nào.

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

Quay lại những chú chó, và lần này chúng ta đưa ra vài lựa chọn có chủ ý.

Giống: một danh sách chọn, hay một bảng riêng? Hãy cho nó đi qua những câu hỏi tôi sẽ đưa ra ở phần sau mô-đun này. Có nhiều hơn một cột thông tin không? Có: ít nhất là kích thước. Bao nhiêu giá trị? Các câu lạc bộ chó giống công nhận vài trăm giống (riêng American Kennel Club đã liệt kê 205), vượt xa quy tắc kinh nghiệm khoảng 20 của tôi. Vì vậy Giống xứng đáng có bảng riêng, và mỗi con chó trỏ đến giống của nó. Điều đó giải quyết câu hỏi chúng ta mang theo từ mô-đun 1: Giống là một hộp riêng.

Mức kỹ năng (Skill Level): một danh sách chọn. Đang học, Tốt, Thành thạo. Ba nhãn, không có gì khác để nói về chúng, và chúng sẽ không thay đổi. Đó chính là việc danh sách chọn sinh ra để làm.

Mỗi con chó biết bao nhiêu trò? Câu trả lời đã có sẵn trong mô hình: đếm các bản ghi Trò của chó của con chó đó. Nhưng người huấn luyện muốn con số đó trên mọi báo cáo, để sắp xếp và lọc theo nó, mà không phải dựng một báo cáo trải qua hai bảng. Vì vậy tôi lùi lại, và giữ một con số Số trò đã biết (Tricks Known) ngay trên con chó. Đó là một bản sao. Sự thật vẫn nằm ở Trò của chó; con số chỉ là một cách thể hiện nó, và nó phải luôn khớp. Salesforce cho chúng ta một cách gọn gàng để làm đúng việc đó, và chúng ta sẽ thấy ở mô-đun 6.

Giờ đến khúc ngoặt: trường huấn luyện chó bắt đầu nhận cả mèo. Chúng ta làm gì? Một lựa chọn: thêm một bảng Mèo bên cạnh bảng Chó, và một Trò của mèo bên cạnh Trò của chó. Mọi thứ nhân đôi: mỗi màn hình hai bản, mỗi báo cáo hai bản, và vào ngày họ nhận thỏ, ba bản. Lựa chọn còn lại: lùi lại và để ý rằng một con mèo có chủ nuôi, có thể có người nhân giống, có giống, ngày sinh và, nếu đủ kiên nhẫn, một hai trò. Cùng những sự thật và cùng những quan hệ như một con chó. Vì vậy chúng ta tổng quát hóa: một Thú cưng, với một Loài, chó hoặc mèo. Mỗi giống cũng thuộc về một loài, và đó là nơi loài thực sự nằm: một con Labrador là một con chó. Thú cưng mang một bản sao, một cách có chủ ý, để mọi màn hình và báo cáo có thể bắt đầu bằng câu “chó hay mèo?” mà không phải tra giống. Thêm một bản sao có chủ ý nữa, và ở mô-đun 6 nó có một công việc riêng.

Đó là thiết kế cho sự thay đổi, và đó là một đánh đổi. Tổng quát hóa quá sớm thì mọi thứ trở thành một “Thứ” mơ hồ với một trường loại mà không ai hiểu. Tôi tổng quát hóa khi doanh nghiệp thực sự mang đến cho tôi loại thứ hai, và hai loại giống nhau gần như mọi thứ, như chó và mèo ở đây. Nếu mèo cần những sự thật rất khác, tôi sẽ cân nhắc lại.

Click to enlarge

Giờ là cùng những kiểu lựa chọn đó ở Steve Trucking, nơi được mất lớn hơn.

Mô hình gọn gàng nhất không phải lúc nào cũng là hệ thống tốt nhất

Hãy hình dung một tổ giao hàng tại một điểm dừng. Lần giao có các mặt hàng. Việc lắp đặt có danh sách kiểm tra. Mỗi bước cần ảnh chụp. Người nhận ký nhận.

Mô hình chuẩn hóa thật đẹp: Giao hàng → Mặt hàng giao → Danh sách kiểm tra lắp đặt → Ảnh, mỗi thứ ở đúng chỗ của nó.

Rồi tôi ngồi với những người thực sự dùng nó. Một tổ đóng khoảng mười điểm dừng mỗi ngày, ngay trước cổng nhà, thường không có sóng điện thoại. Nếu mô hình đẹp đẽ của tôi bắt họ đi qua một mê cung màn hình và danh sách liên quan để hoàn tất một điểm dừng, tôi có một vấn đề kiến trúc.

Mô hình dữ liệu không phải là thứ duy nhất chúng ta đang thiết kế.

Chúng ta đang thiết kế một hệ thống.

Đôi khi trải nghiệm người dùng thắng

Đây là một trong những lý do đôi khi tôi lùi khỏi một mô hình chuẩn hóa hoàn hảo: trải nghiệm người dùng.

Có thể về mặt kỹ thuật một khái niệm có thể là một thực thể riêng, nhưng tách nó ra lại thêm độ phức tạp mà mang lại rất ít giá trị. Có thể một bản ghi cha với vài tầng bản ghi con thì gọn gàng về mặt học thuật nhưng khổ sở khi nhập và duy trì. Có thể khái niệm đó nhỏ, ổn định và chủ yếu được dùng như một lựa chọn.

Đây là lúc tôi thôi chỉ hỏi “Về lý thuyết dữ kiện này thuộc về đâu?” và bắt đầu hỏi “Hệ thống này thực sự sẽ được dùng thế nào?”

Điều đó không có nghĩa là mọi lời phàn nàn về một cú nhấp chuột thừa đều làm phẳng mô hình. Nó có nghĩa là tính khả dụng là một đầu vào kiến trúc chính đáng.

Đôi khi báo cáo thắng

Báo cáo là một lý do phổ biến khác.

Mỗi Đối tác bán lẻ muốn một bảng điểm: tỷ lệ giao đúng hẹn theo khu vực, theo tháng. Trong mô hình gọn gàng, một lần giao biết trung tâm phân phối của nó, và DC biết khu vực của nó. Về mặt kỹ thuật, chúng ta có thể đi theo đường đó.

Nhưng công cụ báo cáo có làm được không? Những người tự xây báo cáo của mình có làm được không? Họ có trả lời được câu hỏi mà không cần một kiến trúc báo cáo phức tạp hơn chính câu hỏi không?

Đó là lúc tôi có thể sao chép hoặc suy ra khu vực đặt lên lần giao, gần hơn với nơi nó được sử dụng.

Giờ tôi đã đưa vào sự trùng lặp. Vì vậy tôi cần thêm một câu hỏi: ai sở hữu sự thật?

Nếu giá trị gốc thay đổi, bản sao của tôi sẽ ra sao? Nó có nên thay đổi theo không? Hay nó nên giữ giá trị đúng vào lúc lần giao diễn ra? Đó là những yêu cầu khác nhau.

Phi chuẩn hóa không loại bỏ độ phức tạp.

Nó dịch chuyển độ phức tạp.

Quan hệ tra cứu hay danh sách chọn?

Đây là một ví dụ nhỏ hơn mà các quản trị viên Salesforce gặp suốt. Người dùng cần chọn từ một tập giá trị. Tôi tạo một thực thể khác và liên kết tới nó, hay dùng một danh sách chọn?

Hãy lấy trạng thái của một lần giao: đã lên lịch, đã lên xe, đang giao, sắp đến, đã giao, đã lắp đặt, ngoại lệ, đã hoàn trả. Một danh sách nhãn ngắn và ổn định. Danh sách chọn chính là thứ tôi muốn.

Giờ hãy lấy loại điểm dừng: chỉ giao hàng, giao kèm lắp đặt, giao kèm chở máy cũ đi. Cái này mang thông tin riêng: điểm dừng mất bao lâu, tổ cần kỹ năng gì, danh sách kiểm tra lắp đặt nào áp dụng. Nó thay đổi độc lập, và phía nghiệp vụ quản lý nó. Đó là một thực thể, không phải một nhãn.

Nếu tôi tạo một đối tượng cho mọi khái niệm về lý thuyết có thể chuẩn hóa, tôi có thể xây một hệ thống đẹp về kỹ thuật mà không ai thích dùng. Nếu tôi biến mọi khái niệm thành danh sách chọn vì nó dễ, tôi có thể tự dồn mình vào góc rất nhanh.

Vì vậy tôi hỏi: nó có thông tin riêng không? Có quan hệ không? Nó có thay đổi độc lập không? Nó có cần được quản lý như dữ liệu không? Phía nghiệp vụ cuối cùng có thể cần ở nó nhiều hơn một cái nhãn không?

Đây là những câu tôi thực sự hỏi trong một buổi thiết kế.

Có nhiều hơn một cột thông tin không? Nếu giá trị cần mô tả, thời lượng, danh sách kỹ năng, người phụ trách, thì nó không còn là một cái nhãn nữa.

Bao nhiêu giá trị? Quy tắc kinh nghiệm của tôi là khoảng 20. Quá 20 giá trị, một danh sách chọn bắt đầu đuối, và đã đến lúc nghĩ đến một đối tượng. Các bang của Mỹ, với năm mươi giá trị, là ngoại lệ chúng ta chấp nhận sống cùng, còn danh sách quốc gia thì tệ hơn; thật lòng mà nói, có ai thích danh sách chọn quốc gia không? Tôi thấy chúng phiền phức.

Các giá trị có được tạo ra theo thời gian không, và bởi ai? Thêm một giá trị danh sách chọn là một thay đổi cấu hình, nghĩa là cần một quản trị viên. Nếu phía nghiệp vụ thêm giá trị mỗi tuần, và người thêm không phải quản trị viên, danh sách chọn sẽ đặt một phiếu yêu cầu trước mỗi giá trị mới.

Người ta có cần lọc và báo cáo theo nó không? Danh sách chọn rất tốt cho việc đó. Quan hệ tra cứu không gọn bằng. Mỗi quan hệ tra cứu thêm một bước nhảy: một loại báo cáo chỉ đi theo một chuỗi ngắn các đối tượng liên quan (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), màn hình biến thành danh sách liên quan nằm trong danh sách liên quan, và mã trở nên phức tạp hơn.

Một danh sách giá trị thường khởi đầu là một danh sách chọn và, theo thời gian, tự giành được quyền có một đối tượng riêng. Hãy để nó giành lấy điều đó.

Click to enlarge

Đôi khi quy mô làm thay đổi câu trả lời

Một thiết kế chạy tuyệt vời với vài nghìn bản ghi có thể hoạt động rất khác với hàng triệu bản ghi.

Vì vậy đừng chỉ nhìn sơ đồ. Hãy biết các con số.

Steve Trucking thực hiện khoảng một triệu lần giao mỗi năm, tăng 30 phần trăm mỗi năm. Mỗi lần giao thu thập khoảng tám cập nhật trạng thái. Đó là tám triệu bản ghi trạng thái năm nay, và khoảng 13,5 triệu mỗi năm vào năm thứ ba. Cộng thêm bốn hay năm triệu ảnh mỗi năm.

Cùng mô hình. Một kiến trúc rất khác.

Chúng ta sẽ đi sâu hơn nhiều trong Architecting at Scale. Bây giờ, hãy nhớ: khối lượng có thể thay đổi một quyết định mô hình hóa dữ liệu. Một quan hệ đúng về mặt logic không tự động là thiết kế vật lý tốt nhất ở mọi quy mô.

Những bên tiêu thụ khác nhau muốn những hình dạng khác nhau

Đến giờ chúng ta đã nghĩ về hệ thống vận hành. Điều phối viên xếp tuyến cho các lần giao. Các tổ đóng điểm dừng. Hệ thống thay đổi khi việc kinh doanh vận hành.

Nhưng phía nghiệp vụ cũng muốn phân tích nhiều năm lịch sử. Đối tác và khu vực nào hay trễ? Thời gian giao đã thay đổi thế nào? Việc lắp đặt thường xuyên cần đến lần thứ hai đến mức nào?

Một hệ thống phân tích có thể muốn cùng thông tin đó được tổ chức khác đi. Bạn sẽ nghe những thuật ngữ như kho dữ liệu, bảng sự kiện (fact), chiều (dimension) và lược đồ hình sao. Chúng ta không mở ra ở đây; ở Steve Trucking đó là kho Snowflake, và chúng ta sẽ quay lại nó ở phần sau của khóa học.

Bây giờ: những bên tiêu thụ khác nhau có thể cần những hình dạng khác nhau của cùng một sự thật.

AI thêm một bên tiêu thụ nữa

Và giờ có thêm một bên tiêu thụ nữa: AI.

Một Người nhận nhắn tin: “Hàng của tôi đâu rồi?” Một trợ lý AI có thể tra được thế này:

Giao hàng 10427, Tuyến 3312, Điểm dừng 7, Xe tải 117, Khung giờ 13:00–15:00.

Một ứng dụng truyền thống hoàn toàn ổn khi đi theo những quan hệ đó. Nhưng để trả lời Người nhận, trợ lý cần ngữ cảnh được ráp từ nhiều nơi:

Chiếc máy rửa bát Redrock của bạn là điểm dừng thứ bảy trên tuyến hôm nay từ trung tâm phân phối Phoenix. Xe tải còn cách ba điểm dừng, và bạn vẫn trong khung giờ 13:00–15:00.

Chúng ta đã lấy thông tin từ vài thực thể liên quan và ráp thành một biểu diễn phẳng hơn, giàu ngữ cảnh hơn cho một bên tiêu thụ cụ thể.

Điều đó không có nghĩa là tôi phá bỏ mô hình chuẩn hóa của mình. Và chắc chắn không có nghĩa là “AI thích dữ liệu phẳng, vậy hãy dồn mọi thứ vào một đối tượng khổng lồ”. Đừng làm vậy.

Nguồn sự thật vẫn gọn gàng. AI nhận một biểu diễn được xây cho công việc nó đang làm. Đó là cùng ý tưởng chúng ta vừa thấy với phân tích:

Một nguồn sự thật có thể hỗ trợ nhiều hình dạng để sử dụng.

Chúng ta sẽ đi sâu hơn nhiều vào neo dữ liệu (grounding) và truy xuất ở phần sau của khóa học.

Đừng tạo ra nhiều sự thật

Ở đây có một mối nguy.

Nếu tôi sao chép khu vực lên lần giao để báo cáo, gửi một phiên bản đã làm phẳng sang Snowflake, và xây một phiên bản giàu ngữ cảnh cho trợ lý AI, thì cái nào đúng?

Câu hỏi đó cần một câu trả lời. Tôi muốn biết giá trị có thẩm quyền nằm ở đâu. Mọi thứ khác là một biểu diễn của sự thật đó cho một mục đích.

Nơi đó là hệ thống gốc. Các bản sao phi chuẩn hóa có thể tốt: màn hình điểm dừng, bảng điểm, Snowflake và ngữ cảnh AI mỗi thứ làm việc của mình tốt hơn với một hình dạng được xây cho nó, và tham chiếu đến chúng là ổn. Nhưng khi có gì thay đổi, thay đổi bắt đầu ở hệ thống gốc, thường là mô hình quan hệ, và chảy ra ngoài đến mọi bản sao. Không ai sửa khu vực trong Snowflake, hay sửa tay ngữ cảnh của AI. Hãy sửa ở nguồn, và để thay đổi tự chảy đi.

Click to enlarge

Và điều đó quan trọng nhất khi dữ liệu thay đổi. Nếu hôm nay một trung tâm phân phối chuyển sang khu vực khác, các lần giao tháng trước có nên hiển thị khu vực mới không? Có thể. Có thể không. Với lịch sử, tôi có thể cần khu vực đúng vào lúc lần giao diễn ra. Đó không còn là vấn đề đồng bộ nữa. Đó là một quyết định nghiệp vụ.

Đó là lý do phi chuẩn hóa không bao giờ nên xảy ra một cách tình cờ. Mỗi dữ kiện bị sao chép đặt ra câu hỏi về quyền sở hữu, đồng bộ, lịch sử và độ tin cậy. Đó là tư duy đánh đổi từ chương 1: hãy biết mình đang mua gì (một màn hình dễ hơn, một báo cáo đơn giản hơn, ngữ cảnh tốt hơn cho AI) và mình đang trả giá gì (dữ liệu trùng lặp, đồng bộ, quyền sở hữu sự thật phức tạp hơn). Và vì chúng ta bắt đầu từ một mô hình logic gọn gàng, chúng ta có thể chỉ vào từng bản sao và nói: “Tôi biết cái này thuộc về đằng kia. Tôi đặt một biểu diễn của nó ở đây vì yêu cầu này.” Đó là một quyết định chúng ta có thể xem xét, chất vấn và ghi lại, để kiến trúc sư tiếp theo biết lý do.

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

Khi cân nhắc phi chuẩn hóa, tôi đang quyết định:

• Nguồn có thẩm quyền của mỗi dữ kiện nghiệp vụ nằm ở đâu.
• Mô hình gọn gàng có tạo ra vấn đề thực sự cho người dùng, báo cáo, quy mô hay hiệu năng không.
• Một biểu diễn đơn giản hơn có đáng với sự trùng lặp không, và bản sao giữ được độ tin cậy bằng cách nào.
• Các giá trị lịch sử có nên thay đổi khi nguồn hiện tại thay đổi không.
• Phân tích hay AI có cần một hình dạng dữ liệu khác với hệ thống vận hành không.

Điểm xuất phát không bao giờ thay đổi: hãy biết sự thật thuộc về đâu. Rồi, khi các yêu cầu biện minh được, hãy định hình nó để đưa đến nơi cần.

Tiếp theo, Salesforce quay lại bức tranh. Chúng ta sẽ biến những gì đã thiết kế thành một mô hình dữ liệu vật lý.

Tìm hiểu thêm

• Build Powerful Reports with Custom Report Types (opens in a new tab), Salesforce Admins, 24 tháng 6 năm 2019 (tiếng Anh, kiểm tra ngày 2026-10-12): một loại báo cáo tùy chỉnh “có thể trải qua tối đa 4 quan hệ đối tượng”.
• Unleash the hounds, terriers and lapdogs: American Kennel Club recognizes 3 more breeds (opens in a new tab), PBS NewsHour, 2 tháng 1 năm 2026 (tiếng Anh, kiểm tra ngày 2026-10-12): “AKC công nhận 205 giống, bao gồm ba giống mới này.”
• Cho vui: FCI Breeds Nomenclature (opens in a new tab), Fédération Cynologique Internationale (tiếng Anh, kiểm tra ngày 2026-10-12): danh sách giống của liên đoàn quốc tế, chia thành mười nhóm. Hãy cuộn qua nó và bạn sẽ thấy vì sao Giống xứng đáng có bảng riêng.