Đặt dữ liệu vào đúng chỗ
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 4 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: Xây dựng mô hình logic · Tiếp theo: Thiết kế theo dạng chuẩn thứ ba, rồi lùi lại
Câu hỏi mô-đun này trả lời: Chuẩn hóa giúp tôi tìm ra dữ liệu thực sự thuộc về đâu như thế nào?
Chúng ta đã có một mô hình logic: thực thể, quan hệ, thuộc tính và khóa. Giờ tôi muốn đặt một trong những câu hỏi quan trọng nhất của mô hình hóa dữ liệu: dữ liệu này có thực sự thuộc về chỗ này không?
Nghe thì đơn giản. Nhưng không phải vậy. Tôi đã thấy rất nhiều hệ thống mà mỗi trường đều hợp lý vào lúc ai đó tạo ra nó. Vấn đề không phải là các trường vô lý; mà là các dữ kiện được lưu sai chỗ. Một lần giao chứa thông tin thực ra mô tả một trung tâm phân phối. Cùng một địa chỉ xuất hiện trên hàng trăm bản ghi. Một trường chứa ba giá trị cách nhau bằng dấu phẩy. Thay đổi một dữ kiện nghiệp vụ nghĩa là phải cập nhật 10.000 bản ghi. Đó là vấn đề mà chuẩn hóa giúp chúng ta giải quyết, và trước khi chìm vào thuật ngữ cơ sở dữ liệu, đây là toàn bộ ý tưởng: đặt một dữ kiện vào đúng chỗ của nó. Mọi thứ khác trong mô-đun này giúp chúng ta làm điều đó một cách có hệ thống hơn.
Chuẩn hóa là gì?
Phần tiêu đề “Chuẩn hóa là gì? ”Chuẩn hóa là tổ chức dữ liệu sao cho mỗi dữ kiện được lưu một lần, ở đúng chỗ của nó. Khi một bảng đang làm quá nhiều việc, chúng ta tách nó thành những bảng mà mỗi bảng mô tả một thứ, và nối chúng với nhau bằng khóa.
Sao phải bận tâm? Vì một dữ kiện được lưu một lần là một dữ kiện chúng ta chỉ thay đổi một lần. Chuẩn hóa ngăn sự dư thừa, cùng một dữ kiện bị sao chép qua nhiều bản ghi, và cùng với nó là những điểm không nhất quán len vào khi một bản sao được cập nhật còn các bản kia thì không. Đó là lý do nó phù hợp với các hệ thống giao dịch như Salesforce, nơi bản ghi được tạo và cập nhật suốt cả ngày.
Chúng ta chuẩn hóa theo từng bước gọi là dạng chuẩn, và mỗi bước đặt một câu hỏi duy nhất:
- Dạng chuẩn thứ nhất (1NF): mỗi trường một giá trị, và có thứ gì đó nhận dạng duy nhất mỗi dòng.
- Dạng chuẩn thứ hai (2NF): mỗi dữ kiện mô tả toàn bộ thứ nhận dạng dòng đó, chứ không chỉ một phần của nó.
- Dạng chuẩn thứ ba (3NF): mỗi dữ kiện mô tả chính thứ này, chứ không phải một thứ khác có liên quan đến nó.
Sau dạng thứ ba còn những dạng khác nữa. Tôi sẽ nói đôi chút về chúng ở phần sau, và về lý do chúng ta thường dừng ở dạng thứ ba. Trước tiên, hãy xem ba bước ấy diễn ra.
Vì sao chúng ta chuẩn hóa?
Phần tiêu đề “Vì sao chúng ta chuẩn hóa? ”Khi dạy phần này trực tiếp, tôi không bắt đầu với các lần giao hàng. Tôi bắt đầu với những chú chó. Ai cũng hiểu về chó, nên không ai bị việc kinh doanh làm phân tâm, và chúng ta có thể quan sát dữ liệu tự tìm về nhà của nó. Rồi chúng ta đưa cùng những bước đi đó sang Steve Trucking.
Ngồi, Đứng yên, Mô hình hóa
Phần tiêu đề “Ngồi, Đứng yên, Mô hình hóa ”Bắt đầu: bảng tính thô. Tôi đưa vài con chó lên màn hình, rồi cả lớp thêm chó của họ vào. Chỉ trong vài phút chúng ta có một danh sách lớn: con chó, năm sinh, ai nuôi nó, chủ nuôi sống ở đâu, giống, ai nhân giống nó, và các trò nó biết.
| Chó | Năm sinh | Chủ nuôi | ZIP | Thành phố | Giống | Người nhân giống | Trò |
|---|---|---|---|---|---|---|---|
| Bella | 2017 | Marcus | 80202 | Denver | Labrador | Maple Ridge | Ngồi, Đứng yên, Bắt tay |
| Milo | 2019 | Marcus | 80202 | Denver | Poodle | Golden Meadow | Ngồi, Lăn tròn |
| Max | 2022 | Ana | 64105 | Kansas City | Lai | Ngồi, Giả chết | |
| Luna | 2020 | Kenji | 98101 | Seattle | Husky | Cascade | Ngồi, Đứng yên, Xoay vòng |
| Rocky | 2024 | Priya | 30301 | Atlanta | Beagle | Maple Ridge | Ngồi |
| Coco | 2014 | Ana | 64105 | Kansas City | Chihuahua | Little Paws | Bắt tay, Xoay vòng |
Nó chạy được. Bảng tính nào cũng chạy được vào ngày đầu. Nhưng hãy nhìn những gì đã sai. Làm sao tôi tìm mọi con chó biết Bắt tay? Mã ZIP của Ana nằm trên hai dòng, của Marcus cũng vậy: chuyện gì xảy ra nếu ai đó cập nhật một dòng mà không cập nhật dòng kia? Maple Ridge xuất hiện hai lần, Kansas City cũng vậy. Và Max được nhận về từ trại chó hoang, nên hoàn toàn không có người nhân giống.
Bước 1: dạng chuẩn thứ nhất. Hai quy tắc. Mỗi trường chứa một giá trị duy nhất, nên danh sách trò cách nhau bằng dấu phẩy phải bỏ đi. Và mỗi dòng cần có thứ gì đó nhận dạng duy nhất nó. Không phải tên con chó; có rất nhiều con chó tên Max. Một ID: một ID tự sinh hoặc một GUID. Các trò được tách ra thành những dòng riêng, mỗi dòng cho một con chó và một trò. Và khi một trò đã có dòng riêng, sẽ có chỗ cho điều chúng ta không bao giờ nói được trong một danh sách cách nhau bằng dấu phẩy: trò đó khó đến đâu, con chó này làm nó giỏi đến đâu, và nó học được khi nào.
Chó (nhận dạng bằng Dog ID)
| Dog ID | Tên | Năm sinh | Chủ nuôi | ZIP | Thành phố | Giống | Người nhân giống |
|---|---|---|---|---|---|---|---|
| D-001 | Bella | 2017 | Marcus | 80202 | Denver | Labrador | Maple Ridge |
| D-002 | Milo | 2019 | Marcus | 80202 | Denver | Poodle | Golden Meadow |
| D-003 | Max | 2022 | Ana | 64105 | Kansas City | Lai | |
| D-004 | Luna | 2020 | Kenji | 98101 | Seattle | Husky | Cascade |
| D-005 | Rocky | 2024 | Priya | 30301 | Atlanta | Beagle | Maple Ridge |
| D-006 | Coco | 2014 | Ana | 64105 | Kansas City | Chihuahua | Little Paws |
Trò của chó (nhận dạng bằng Dog ID + Trò)
| Dog ID | Trò | Độ khó | Mức kỹ năng | Học được |
|---|---|---|---|---|
| D-001 | Ngồi | Dễ | Thành thạo | 2017-11 |
| D-001 | Đứng yên | Dễ | Thành thạo | 2018-01 |
| D-001 | Bắt tay | Trung bình | Tốt | 2018-06 |
| D-002 | Ngồi | Dễ | Thành thạo | 2020-02 |
| D-002 | Lăn tròn | Khó | Đang học | 2023-05 |
| D-003 | Ngồi | Dễ | Tốt | 2022-06 |
| D-003 | Giả chết | Khó | Đang học | 2024-03 |
| D-004 | Ngồi | Dễ | Thành thạo | 2020-11 |
| D-004 | Đứng yên | Dễ | Tốt | 2021-01 |
| D-004 | Xoay vòng | Trung bình | Thành thạo | 2021-06 |
| D-005 | Ngồi | Dễ | Đang học | 2025-02 |
| D-006 | Bắt tay | Trung bình | Thành thạo | 2015-06 |
| D-006 | Xoay vòng | Trung bình | Đang học | 2025-04 |
Giờ “mọi con chó biết Bắt tay” là một câu hỏi đơn giản. Nhưng hãy để ý Trò của chó được nhận dạng bằng gì: không phải một thứ, mà hai thứ cùng nhau, con chó và trò. Hãy giữ điều đó trong đầu.
Bước 2: dạng chuẩn thứ hai. Dạng chuẩn thứ hai chỉ có ý nghĩa khi một dòng được nhận dạng bằng một tổ hợp, và Trò của chó là như vậy. Vì thế tôi hỏi từng cột: nó mô tả toàn bộ tổ hợp, hay chỉ một phần? Mức kỹ năng mô tả con chó này làm trò này: Bella thành thạo trò Ngồi, Rocky vẫn đang học. Học được cũng vậy. Nhưng Độ khó thì sao? Ngồi là trò dễ, bất kể con chó nào làm. Nó mô tả trò, chỉ một phần của khóa, và đó là lý do “Dễ” lặp lại trên mọi dòng Ngồi. Vì vậy trò có bảng riêng, và những gì còn lại là cặp đôi.
Trò
| Trick ID | Trò | Độ khó |
|---|---|---|
| T-01 | Ngồi | Dễ |
| T-02 | Đứng yên | Dễ |
| T-03 | Bắt tay | Trung bình |
| T-04 | Lăn tròn | Khó |
| T-05 | Giả chết | Khó |
| T-06 | Xoay vòng | Trung bình |
Trò của chó (Dog ID + Trick ID)
| Dog ID | Trick ID | Mức kỹ năng | Học được |
|---|---|---|---|
| D-001 | T-01 | Thành thạo | 2017-11 |
| D-001 | T-02 | Thành thạo | 2018-01 |
| D-001 | T-03 | Tốt | 2018-06 |
| D-002 | T-01 | Thành thạo | 2020-02 |
| D-002 | T-04 | Đang học | 2023-05 |
| D-003 | T-01 | Tốt | 2022-06 |
| D-003 | T-05 | Đang học | 2024-03 |
| D-004 | T-01 | Thành thạo | 2020-11 |
| D-004 | T-02 | Tốt | 2021-01 |
| D-004 | T-06 | Thành thạo | 2021-06 |
| D-005 | T-01 | Đang học | 2025-02 |
| D-006 | T-03 | Thành thạo | 2015-06 |
| D-006 | T-06 | Đang học | 2025-04 |
Bảng Trò của chó đó chính là thứ chúng ta đã tìm ra ở mô-đun 2, và nó có một cái tên trong mô hình hóa dữ liệu: một bảng nối, hay như tôi gọi, một đối tượng nối logic. Một con chó biết nhiều trò; một trò được nhiều con chó biết. Bảng nối nằm giữa chúng, và nó không phải đường ống rỗng: nó chứa những dữ kiện thuộc về chính quan hệ đó, mức kỹ năng và ngày học được. Chúng ta sẽ gặp lại nó ở mô-đun 6, và ở chương 3 chúng ta sẽ thấy Salesforce dùng chữ “đối tượng nối” theo nghĩa hẹp hơn: một đối tượng nối của Salesforce (Salesforce Junction Object) là một đối tượng tùy chỉnh có hai quan hệ chính-chi tiết (chương 3, mô-đun 7).
Bước 3: dạng chuẩn thứ ba. Giờ quay lại bảng Chó. Mọi thứ trên đó được nhận dạng bằng Dog ID, nên dạng chuẩn thứ hai không có gì để nói. Dạng chuẩn thứ ba đặt một câu hỏi khác: dữ kiện này mô tả con chó, hay một thứ khác mà con chó có liên quan? Giống là một thứ riêng: một con Labrador là Labrador bất kể đó là con chó nào, và các dữ kiện về nó, như kích thước, thuộc về giống, không thuộc về Bella. Mã ZIP và thành phố mô tả chủ nuôi, không phải con chó: đó là nơi Ana sống, dù chúng ta đang xem con chó nào của cô ấy. Thông tin về người nhân giống mô tả người nhân giống. Mỗi thứ đó là một dữ kiện về một dữ kiện khác, nên mỗi thứ chuyển sang bảng riêng của nó, và con chó trỏ đến nó bằng một khóa ngoại:
- Chó: Dog ID, Tên, Năm sinh, Owner ID, Breed ID, Breeder ID
- Chủ nuôi: Owner ID, Tên, ZIP, Thành phố
- Giống: Breed ID, Giống, Kích thước
- Người nhân giống: Breeder ID, Tên, Thành phố
- Trò và Trò của chó, từ bước 2
Giờ Ana chỉ được lưu một lần, và cả hai con chó của cô ấy đều trỏ đến cô ấy. Maple Ridge được lưu một lần, và bảng Giống cho chúng ta một chỗ cho các dữ kiện về từng giống, như kích thước, mà bảng tính không có chỗ nào để đặt. Một khóa ngoại có thể để trống: Max không có Breeder ID, và đó là một câu trả lời trung thực, không phải một lỗ hổng. Rồi tôi ném cho cả lớp một câu hỏi mẹo: ngày chủ nuôi nhận con chó thì đặt ở đâu? Trên con chó. Trong mô hình này, mỗi lúc một con chó chỉ có một chủ nuôi, nên ngày đó mô tả quan hệ của con chó với chủ nuôi của nó.
Bạn có thể đi thêm một bước nữa và tách thành phố ra khỏi mã ZIP; sách giáo khoa làm vậy. Trên thực tế một địa chỉ đi cùng nhau, và dù sao thì Kansas City cũng nằm ở hai bang, một lời nhắc dễ thương rằng thế giới thực không đọc sách giáo khoa của chúng ta.
Đó là tiến trình: một bảng tính, rồi ba câu hỏi, và mọi dữ kiện đều nằm ở một chỗ. Hãy lùi lại và nhìn những gì chúng ta đã xây. Một danh sách lộn xộn đã trở thành sáu bảng, mỗi bảng mô tả một thứ, nối với nhau bằng khóa:
Không ai cần đến một từ Salesforce nào để theo kịp phần đó. Chỉ là những chú chó, những người quanh chúng, và những gì chúng biết.
Giờ hãy áp dụng cho Steve Trucking
Phần tiêu đề “Giờ hãy áp dụng cho Steve Trucking ”Những chú chó giúp các bước đi dễ thấy. Một doanh nghiệp thật khiến chúng trở nên quan trọng, vì cùng những sai lầm ấy tốn tiền thật khi ở quy mô lớn. Vậy hãy đưa cùng ba câu hỏi đó đến Steve Trucking. Hãy tưởng tượng họ lưu các lần giao hàng như thế này:
| Giao hàng | Đối tác bán lẻ | Trung tâm phân phối | Thành phố của DC | Tổ giao hàng | Xe tải |
|---|---|---|---|---|---|
| 1001 | Keystone | Keystone Phoenix DC | Phoenix | Tổ 12 | 117 |
| 1002 | Keystone | Keystone Phoenix DC | Phoenix | Tổ 8 | 122 |
| 1003 | Keystone | Keystone Phoenix DC | Phoenix | Tổ 12 | 117 |
Thoạt nhìn chẳng có gì phức tạp ở đây. Nhưng hãy nhìn trung tâm phân phối. Chúng ta lặp lại “Keystone Phoenix DC, Phoenix” trên mọi lần giao xuất phát từ đó: Steve Trucking thực hiện khoảng 3.300 lần giao mỗi ngày qua chín DC, vậy là vài trăm lần mỗi ngày từ mỗi DC. Chuyện gì xảy ra nếu DC đó chuyển chỗ? Chúng ta phải thay đổi bao nhiêu bản ghi, và chuyện gì xảy ra nếu sót một bản ghi? Giờ dữ liệu nói rằng DC nằm ở hai thành phố cùng lúc. Đó là một dị thường cập nhật. Nếu chúng ta muốn thiết lập một DC mới trước lần giao đầu tiên của nó thì sao? Nếu chúng ta xóa lần giao cuối cùng của một DC: có phải chúng ta vừa xóa nơi duy nhất lưu bất cứ thông tin gì về nó?
Đó là những triệu chứng khác nhau của cùng một vấn đề: chúng ta đã trộn lẫn các dữ kiện về những thứ khác nhau. Dữ kiện về trung tâm phân phối thuộc về trung tâm phân phối. Dữ kiện về lần giao thuộc về lần giao. Dữ kiện về tổ giao hàng thuộc về tổ giao hàng. Đó là chuẩn hóa nói theo cách thực tế.
Dạng chuẩn thứ nhất: đừng giấu cấu trúc lặp
Phần tiêu đề “Dạng chuẩn thứ nhất: đừng giấu cấu trúc lặp ”Hãy bắt đầu với Dạng chuẩn thứ nhất, hay 1NF, nơi người ta đôi khi làm cho chuẩn hóa khó hơn mức cần thiết.
Giả sử một lần giao có một trường tên là Items: “Tủ lạnh, bộ làm đá, chở máy cũ đi.” Chúng ta đã nhét ba mẩu thông tin vào một trường. Có vẻ tiện, cho đến khi có người hỏi: “Tháng trước chúng ta đã chở máy cũ đi bao nhiêu lần?” Hoặc hãy tưởng tượng các trường tên là Item 1, Item 2 và Item 3. Cách đó chạy được, cho đến lần giao có bốn mặt hàng. Vấn đề không phải là chúng ta chọn sai số lượng trường Item. Vấn đề là chúng ta đã không nhận ra cấu trúc lặp. Một lần giao có thể có nhiều mặt hàng. Đó là dữ liệu chúng ta nên mô hình hóa: Mặt hàng giao mà chúng ta đã tìm ra ở mô-đun 2.
Bài học thực tế của 1NF: đừng giấu cấu trúc lặp bên trong các trường. Nếu doanh nghiệp nói với bạn rằng điều gì đó có thể xảy ra nhiều lần, hãy lắng nghe. Có thể có một thực thể khác đang muốn thoát ra.
Bạn sẽ thấy điều này trong các org thực tế suốt. Ai đó cần mô tả bằng nhiều ngôn ngữ, nên họ tạo một trường tên là Description_English, rồi Description_French, rồi Description_German. Hoặc một phê duyệt cần vài người, nên chúng ta có Approver 1, Approver 2, Approver 3. Khi tôi thấy điều đó trong một buổi rà soát, đó là lúc khẽ tay nhắc nhở: hãy sửa mô hình dữ liệu của bạn. Một hay hai, có thể được, nếu doanh nghiệp thực sự chỉ bao giờ có một hay hai. Nhiều hơn thế thì nên là một đối tượng con: một Bản dịch với một ngôn ngữ, một Bước phê duyệt với một người phê duyệt. Ngôn ngữ tiếp theo, hay người phê duyệt thứ tư, trở thành một bản ghi mới, không phải một trường mới và một lần triển khai.
Dạng chuẩn thứ hai: mô tả toàn bộ
Phần tiêu đề “Dạng chuẩn thứ hai: mô tả toàn bộ ”Dạng chuẩn thứ hai, hay 2NF, có ý nghĩa khi một bản ghi được nhận dạng bằng một tổ hợp nhiều thứ. Hãy lấy Mặt hàng giao. Nó có ID bản ghi riêng, nhưng mỗi mặt hàng là duy nhất theo Giao hàng + Sản phẩm. Giả sử chúng ta lưu lần giao, sản phẩm, số lượng và mô tả của sản phẩm.
Số lượng hợp lý ở đây: nó mô tả sản phẩm này trên lần giao này. Nhưng mô tả sản phẩm không mô tả tổ hợp; nó mô tả sản phẩm. Đặt nó trên mọi Mặt hàng giao và chúng ta sẽ lặp lại nó mỗi lần mẫu tủ lạnh đó lên một chuyến xe khác. Đó là dấu hiệu cho thấy dữ kiện thuộc về chỗ khác.
Vậy câu hỏi của 2NF là: thuộc tính này mô tả toàn bộ thứ tôi đang nhận dạng, hay chỉ một phần của nó? Nếu nó chỉ mô tả sản phẩm, nó đi cùng Sản phẩm. Nếu nó mô tả vị trí của sản phẩm trên lần giao cụ thể này (số lượng, có lắp đặt hay không), nó thuộc về Mặt hàng giao. Nhiều quản trị viên sẽ không bao giờ có ý thức nói: “Giờ tôi đang áp dụng Dạng chuẩn thứ hai.” Không sao cả. Tôi quan tâm hơn nhiều đến việc bạn học cách hỏi: dữ kiện này thực sự mô tả điều gì?
Dạng chuẩn thứ ba: đừng lưu dữ kiện về dữ kiện khác
Phần tiêu đề “Dạng chuẩn thứ ba: đừng lưu dữ kiện về dữ kiện khác ”Giờ là dạng tôi quan tâm nhất cho việc mô hình hóa hằng ngày: Dạng chuẩn thứ ba, hay 3NF.
Mỗi trung tâm phân phối có một người quản lý phía Đối tác bán lẻ, người dùng cổng đối tác. Giả sử chúng ta đặt tên người quản lý DC trực tiếp trên mọi lần giao. Chuyện gì xảy ra khi DC có người quản lý mới? Chúng ta cập nhật mọi lần giao từ DC đó. Lại là mùi ấy: chúng ta đang lặp lại một dữ kiện thuộc về chỗ khác. Lần giao xuất phát từ một DC; DC có một người quản lý. Đó là hai quan hệ, và tên người quản lý thuộc về DC.
Phiên bản sách giáo khoa kinh điển là địa chỉ: mã ZIP, thành phố và bang được lưu cùng nhau trên mọi bản ghi, trong khi thành phố và bang thường suy ra được từ mã ZIP. Cùng hình dạng, cùng câu hỏi.
Câu hỏi thực tế của 3NF là: dữ kiện này mô tả chính thứ này, hay một thứ khác mà thứ này có liên quan? Tôi muốn bạn hỏi câu đó liên tục.
Giờ hãy lùi lại, như chúng ta đã làm với những chú chó. Bảng giao hàng ban đầu đã trở thành năm thứ, mỗi thứ giữ dữ kiện của riêng mình: Mặt hàng giao tách ra ở dạng chuẩn thứ nhất, Sản phẩm ở dạng thứ hai, còn thành phố và người quản lý của Trung tâm phân phối chuyển sang Trung tâm phân phối ở dạng thứ ba.
Cùng ba câu hỏi, cùng kết quả: mọi dữ kiện nằm ở một chỗ.
Một cách đơn giản để nghĩ về 1NF, 2NF và 3NF
Phần tiêu đề “Một cách đơn giản để nghĩ về 1NF, 2NF và 3NF ”Bạn có thể dành cả một khóa học cơ sở dữ liệu cho chuẩn hóa. Chúng ta sẽ không làm vậy. Với khóa học này, tôi muốn bạn có cách hiểu của một kiến trúc sư đang làm việc thực tế:
- 1NF: tôi có đang giấu nhiều giá trị hay cấu trúc lặp bên trong một trường hay một bản ghi không?
- 2NF: dữ kiện này có mô tả toàn bộ thứ tôi đang nhận dạng không?
- 3NF: dữ kiện này thực sự mô tả thực thể này, hay một thứ có liên quan đến nó?
Đó không phải là định nghĩa cho sách giáo khoa cơ sở dữ liệu. Đó là những câu hỏi tôi thực sự dùng được trong lúc thiết kế.
Đúng vậy, chuẩn hóa còn đi xa hơn: Dạng chuẩn Boyce-Codd (BCNF) siết chặt các quy tắc quanh 3NF cho những mô hình có khóa phức tạp hơn, và còn có Dạng chuẩn thứ tư, thứ năm và thậm chí thứ sáu. Chúng xử lý những kiểu lặp hiếm gặp hơn, loại đến từ cấu trúc khóa bất thường nhiều hơn là từ các bản ghi nghiệp vụ hằng ngày. Rất nhiều lý thuyết, và theo kinh nghiệm của tôi không đáng để đau đầu cho loại hệ thống chúng ta xây trên Salesforce. Trong các hệ thống nghiệp vụ, áp lực thường đi theo chiều ngược lại: chúng ta có khả năng lùi khỏi dạng chuẩn thứ ba, vì người dùng, báo cáo và hiệu năng, cao hơn nhiều so với vượt qua nó. Đó là mô-đun tiếp theo. Hãy biết rằng các dạng xa hơn tồn tại, nhưng với phần lớn những gì chúng ta làm, 1NF đến 3NF cho chúng ta những công cụ tư duy cần thiết.
Thiết kế theo dạng chuẩn thứ ba
Phần tiêu đề “Thiết kế theo dạng chuẩn thứ ba ”Đây là quan điểm của tôi. Khi tôi đang cố hiểu một doanh nghiệp và thiết kế mô hình logic của nó, tôi muốn bắt đầu gọn gàng: dữ kiện về lần giao đi với lần giao, dữ kiện về trung tâm phân phối đi với DC, dữ kiện về xe tải đi với xe tải, các khái niệm lặp được mô hình hóa thành khái niệm. Tôi không muốn một dữ kiện nghiệp vụ bị sao chép khắp mô hình chỉ vì nó có thể làm một màn hình hay một báo cáo dễ hơn. Chưa phải lúc.
Nhưng chuẩn hóa không phải là một tôn giáo. Mục tiêu không phải là mô hình thuần khiết nhất về mặt học thuật. Tôi đã thấy những kiến trúc sư quá tập trung vào sự thuần khiết đến mức mô hình trở thành nỗi khổ cho mọi người phải dùng nó. Chúng ta không cố thắng một cuộc thi chuẩn hóa; chúng ta đang xây một hệ thống, và hệ thống đó có người dùng, báo cáo, tích hợp, nhu cầu hiệu năng, quy mô và, ngày càng nhiều, AI đọc dữ liệu. Những thứ đó có thể muốn dữ liệu ở những hình dạng khác nhau.
Vì vậy điểm xuất phát của tôi là thiết kế theo Dạng chuẩn thứ ba khi khả thi, rồi lùi lại khi cần thiết: trước hết hiểu mỗi dữ kiện thuộc về đâu. Sau đó, nếu chúng ta định rời khỏi nó, tôi muốn biết vì sao. Nếu câu trả lời là “vì tôi không biết đặt trường đó ở đâu khác”, thì chưa đủ tốt. Nếu câu trả lời là “chúng tôi cố ý sao chép giá trị này vì nó làm bảng điểm đối tác trở nên đơn giản, và chúng tôi có cách đáng tin cậy để giữ nó đồng bộ”, thì giờ chúng ta đang có một cuộc trò chuyện về kiến trúc.
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 chuẩn hóa một mô hình logic, tôi tìm kiếm:
- Những giá trị hay cấu trúc lặp nên được mô hình hóa riêng.
- Những thuộc tính mô tả một thực thể khác với thực thể mà chúng đang được lưu trên đó.
- Những dữ kiện bị sao chép không cần thiết qua nhiều bản ghi, và những sự phụ thuộc khiến chúng trở nên không nhất quán.
- Những khái niệm nghiệp vụ bị giấu bên trong các trường.
- Một mô hình gọn gàng thể hiện sự thật trước bất kỳ thỏa hiệp triển khai nào.
Không phải vì mọi hệ thống vật lý đều phải được chuẩn hóa hoàn hảo. Hoàn toàn ngược lại. Ở mô-đun tiếp theo chúng ta sẽ cố ý rời khỏi mô hình gọn gàng, vì người dùng, báo cáo, quy mô, phân tích và AI, và chúng ta sẽ làm điều đó khi biết chính xác mình đang đánh đổi điều gì.