Khi làm việc với cơ sở dữ liệu, bạn thường gặp các vấn đề như dữ liệu dư thừa và cập nhật thiếu nhất quán. Dạng chuẩn thứ hai là một bước chuẩn hoá cơ sở dữ liệu xây dựng trên dạng chuẩn thứ nhất (1NF) để tạo ra các bảng gọn gàng và hiệu quả hơn.
Hiểu 2NF là điều then chốt với bất kỳ ai làm thiết kế cơ sở dữ liệu hoặc quản lý dữ liệu, và nó đặt nền tảng cho các dạng chuẩn cao hơn như dạng chuẩn thứ ba (3NF). Trong bài viết này, chúng ta sẽ khám phá cách 2NF hoạt động và cách biến đổi bảng để đáp ứng yêu cầu 2NF, kèm các ví dụ thực tế. Chúng ta cũng sẽ bàn về lợi ích và hạn chế của 2NF, cùng những trường hợp sử dụng phù hợp nhất.
Tìm hiểu về Dạng chuẩn thứ hai
Dạng chuẩn thứ hai là một bước chuẩn hoá cơ sở dữ liệu tập trung vào việc loại bỏ các phụ thuộc từng phần. Nó được giới thiệu bởi Edgar F. Codd, người tiên phong của cơ sở dữ liệu quan hệ, như một phần trong công trình về chuẩn hoá của ông.
Trước khi một bảng đạt 2NF, nó phải thoả mãn các quy tắc của dạng chuẩn thứ nhất:
- Tính nguyên tử: Mỗi ô chỉ chứa một giá trị (không có nhóm lặp hay mảng).
- Hàng là duy nhất: Bảng phải có một khoá chính rõ ràng.
2NF tiến thêm một bước với quy tắc bổ sung: loại bỏ các phụ thuộc từng phần.
Phụ thuộc từng phần xảy ra khi một thuộc tính không khoá (cột không nằm trong bất kỳ khoá ứng viên nào) phụ thuộc chỉ vào một phần của khoá tổng hợp thay vì toàn bộ khoá. Quy tắc 2NF đảm bảo mọi thuộc tính không khoá đều phụ thuộc vào toàn bộ khoá chính, không chỉ một phần của nó. Để phụ thuộc từng phần tồn tại trong bảng sẽ khiến dữ liệu dư thừa len lỏi vào cơ sở dữ liệu, dẫn đến kém hiệu quả và có thể phát sinh thiếu nhất quán khi cập nhật hoặc xoá.
Lý thuyết thôi có thể hơi khô khan, nên hãy xem một ví dụ thực tế.
Dưới đây là bảng Ghi danh khoá học của học viên Datacamp.
Ở đây, khoá chính là sự kết hợp của Student ID và Course ID. Tuy nhiên, các thuộc tính không khoá Course Name và Course Fee chỉ phụ thuộc vào Course ID, không phải toàn bộ khoá. Điều này vi phạm 2NF.
Các bước phân rã bảng để đạt 2NF
Để đảm bảo một bảng tuân theo 2NF, bạn cần:
- Xác định tất cả khoá ứng viên: Xác định các tập thuộc tính tối thiểu định danh duy nhất từng hàng trong bảng. Đây là các khoá ứng viên của bạn.
- Xác định các phụ thuộc hàm: Xác định tất cả phụ thuộc hàm trong bảng. Cụ thể, tìm các phụ thuộc nơi thuộc tính không khoá (không nằm trong bất kỳ khoá ứng viên nào) chỉ phụ thuộc vào một phần của khoá tổng hợp.
- Loại bỏ phụ thuộc từng phần: Với mỗi phụ thuộc từng phần:
- Di chuyển các thuộc tính phụ thuộc sang một bảng mới cùng với phần khoá mà chúng phụ thuộc vào.
- Đảm bảo bảng mới có khoá chính duy nhất.
- Lặp lại cho đến khi không còn phụ thuộc từng phần: Xác nhận rằng mọi thuộc tính không khoá ở tất cả các bảng đều phụ thuộc hoàn toàn vào khoá chính tương ứng.
Ví dụ về Dạng chuẩn thứ hai trong thực tế
Giờ hãy xem hai ví dụ.
Ví dụ 1: Bảng ghi danh khoá học
Trước đó, chúng ta đã thấy bảng ghi danh khoá học sau:
Hãy làm theo các bước đã nêu ở phần trước.
1. Xác định khoá ứng viên.
Trong trường hợp này, khoá ứng viên là khoá tổng hợp của Student ID và Course ID. Tổ hợp duy nhất này định danh mỗi hàng trong bảng.
2. Xác định các phụ thuộc hàm
Course Name và Instructor Name phụ thuộc vào Course ID, không phải toàn bộ khoá tổng hợp (Student ID, Course ID). Đây là phụ thuộc từng phần vì các thuộc tính này chỉ phụ thuộc vào một phần của khoá tổng hợp.
3. Loại bỏ phụ thuộc từng phần
Chúng ta cần chuyển các thuộc tính chỉ phụ thuộc vào một phần khoá (Course Name và Instructor Name) sang một bảng mới chỉ dựa trên Course ID.
Sau khi phân rã, các bảng mới của chúng ta như sau:
Bảng ghi danh khoá học
| Student ID | Course ID |
|---|
| 1001 | 201 |
| 1002 | 202 |
| 1001 | 202 |
Bảng chi tiết khoá học
Nếu bạn muốn tự tay tạo cơ sở dữ liệu, hãy xem khoá học PostgresQL của chúng tôi. Nếu bạn đã ở mức nâng cao hơn một chút, bạn có thể thử Introduction to Data Modeling in Snowflake, trong đó đề cập đến các ý tưởng như mô hình hoá thực thể - quan hệ và mô hình hoá hướng chiều.
Ví dụ 2: Bảng đơn hàng
Chúng ta sẽ bắt đầu với bảng Đơn hàng sau. Hãy thử làm theo các bước đã nêu ở trên và tự phân rã bảng này!
| Order ID | Product ID | Order Date | Product Name | Supplier Name |
|---|
| 1 | 201 | 2024-11-01 | Laptop | TechSupply |
| 1 | 202 | 2024-11-01 | Mouse | TechSupply |
| 2 | 201 | 2024-11-02 | Laptop | TechSupply |
| 3 | 203 | 2024-11-03 | Keyboard | KeyMasters |
1. Xác định khoá ứng viên
Tổ hợp Order ID và Product ID định danh duy nhất mỗi hàng, biến (Order ID, Product ID) thành khoá ứng viên tổng hợp. Không cột đơn lẻ nào có thể định danh duy nhất các hàng vì:
- Order ID riêng lẻ không là duy nhất, vì một đơn hàng có thể gồm nhiều sản phẩm.
- Product ID riêng lẻ không là duy nhất, vì cùng một sản phẩm có thể xuất hiện trong các đơn hàng khác nhau.
Điều này có nghĩa (Order ID, Product ID) cũng là khoá chính của chúng ta.
2. Xác định các phụ thuộc hàm
Order Date phụ thuộc vào Order ID (không phải toàn bộ khoá tổng hợp). Đây là một phụ thuộc từng phần.
Product Name và Supplier Name phụ thuộc vào Product ID (không phải toàn bộ khoá tổng hợp). Đây cũng là các phụ thuộc từng phần.
3. Loại bỏ phụ thuộc từng phần
Chúng ta cần tách bảng thành các bảng nhỏ hơn, mỗi bảng xử lý một phụ thuộc logic.
Đầu tiên, chúng ta sẽ tạo một bảng cho thông tin đơn hàng, chứa thông tin đặc thù theo Order ID.
Bảng Orders
| Order ID | Order Date |
|---|
| 1 | 2024-11-01 |
| 2 | 2024-11-02 |
| 3 | 2024-11-03 |
Sau đó, chúng ta tạo một bảng chứa thông tin đặc thù theo Product ID.
Bảng Orders
| Product ID | Product Name | Supplier Name |
|---|
| 201 | Laptop | TechSupply |
| 202 | Mouse | TechSupply |
| 203 | Keyboard | KeyMasters |
Bảng gốc giờ chỉ còn lại khoá tổng hợp và mối quan hệ giữa đơn hàng và sản phẩm.
| Order ID | Product ID |
|---|
| 1 | 201 |
| 1 | 202 |
| 2 | 201 |
| 3 | 203 |
Giờ đây, cơ sở dữ liệu của chúng ta ở 2NF vì 1) tất cả phụ thuộc từng phần đã được loại bỏ, và 2) các thuộc tính không khoá phụ thuộc hoàn toàn vào khoá chính tương ứng.
Khi nào nên triển khai Dạng chuẩn thứ hai
Vậy tại sao bạn nên tái cấu trúc cơ sở dữ liệu theo 2NF? Nó đã đủ hay bạn nên tiến thêm một bước để đạt 3NF?
Lợi ích và hạn chế của dạng chuẩn thứ hai
Dạng chuẩn thứ hai mang lại một số lợi thế, khiến nó trở thành bước hữu ích trong quá trình chuẩn hoá cơ sở dữ liệu:
- Tăng cường tính toàn vẹn dữ liệu: Bằng cách loại bỏ phụ thuộc từng phần, 2NF giảm thiểu các bất thường khi chèn, cập nhật và xoá, giúp cơ sở dữ liệu đáng tin cậy hơn.
- Giảm dư thừa: 2NF giảm lặp lại dữ liệu, tối ưu hoá dung lượng lưu trữ và đơn giản hoá việc bảo trì dữ liệu.
- Cải thiện cấu trúc dữ liệu: Nó đặt nền tảng cho các bước chuẩn hoá tiếp theo, như tiến tới dạng chuẩn thứ ba, bằng cách tạo thiết kế cơ sở dữ liệu gọn gàng và hiệu quả hơn.
Nhưng cũng có một số hạn chế:
- Tăng độ phức tạp: Phân rã bảng để đáp ứng 2NF có thể làm quá trình thiết kế phức tạp hơn, đặc biệt khi làm việc với khoá tổng hợp và các phụ thuộc.
- Nhiều phép nối hơn: Việc tách bảng có thể đòi hỏi nhiều phép nối hơn trong truy vấn, có thể ảnh hưởng hiệu năng ở các hệ thống với bộ dữ liệu lớn hoặc truy vấn phức tạp - chi tiết hơn bên dưới.
- Dư thừa còn sót: Trong khi 2NF giảm phụ thuộc từng phần, nó không xử lý phụ thuộc bắc cầu, để lại một số dư thừa cho đến khi được giải quyết ở 3NF.
Cân nhắc hiệu năng với dạng chuẩn thứ hai
Phân rã bảng để loại bỏ phụ thuộc từng phần có thể tác động trực tiếp đến hiệu năng cơ sở dữ liệu. Một mặt, đạt 2NF giảm dư thừa dữ liệu và cải thiện tính nhất quán, dẫn đến ít bất thường hơn khi chèn, cập nhật hoặc xoá. Mặt khác, chuẩn hoá có thể tăng số lượng bảng, đồng nghĩa cần nhiều phép nối hơn khi truy xuất dữ liệu liên quan. Điều này có thể ảnh hưởng hiệu năng truy vấn với bộ dữ liệu lớn.
Để đảm bảo cơ sở dữ liệu đã chuẩn hoá vẫn đạt hiệu năng, hãy tuân theo các thực tiễn tốt sau:
- Đánh chỉ mục: Sử dụng chỉ mục để tăng tốc các phép nối giữa các bảng đã phân rã.
- Tối ưu truy vấn: Tối ưu câu lệnh truy vấn để giảm chi phí của các phép nối bổ sung.
- Cách tiếp cận lai: Kết hợp chuẩn hoá với phi chuẩn hoá ở những khu vực yêu cầu hiệu năng, chẳng hạn các bảng báo cáo.
- Giám sát thường xuyên: Liên tục đánh giá hiệu năng cơ sở dữ liệu bằng các công cụ profiling để phát hiện sớm vấn đề tiềm ẩn.
2NF chỉ là bước trung gian để đạt dạng chuẩn thứ ba?
Trong hầu hết trường hợp, các nhà thiết kế cơ sở dữ liệu hướng tới dạng chuẩn thứ ba do khả năng giảm dư thừa sâu hơn và cải thiện tính toàn vẹn dữ liệu tổng thể. Tuy nhiên, đạt 3NF thường đòi hỏi thêm công việc, như tạo nhiều bảng và quan hệ hơn, có thể đưa đến đánh đổi về độ phức tạp và hiệu năng khi thực thi truy vấn.
Có những trường hợp chỉ dùng dạng chuẩn thứ hai là đủ. Nếu ưu tiên là sự đơn giản và triển khai nhanh, như trong các dự án nhỏ, nguyên mẫu, hoặc khi dữ liệu dư thừa tối thiểu, 2NF có thể đáp ứng. Ví dụ, trong các hệ thống mà mọi thuộc tính đã phụ thuộc hoàn toàn vào một khoá chính đơn giản, đạt 2NF có thể hoàn thành mục tiêu chính là giảm phụ thuộc từng phần mà không cần chuẩn hoá thêm.
Vượt xa dạng chuẩn thứ hai: hướng tới dạng chuẩn thứ ba
Nếu bạn muốn chuẩn hoá cơ sở dữ liệu sâu hơn, bạn có thể tiếp tục tái cấu trúc các bảng để đạt dạng chuẩn thứ ba.
3NF xây dựng trên 2NF bằng cách xử lý phụ thuộc bắc cầu – các tình huống mà thuộc tính không khoá phụ thuộc vào các thuộc tính không khoá khác thay vì khoá chính. Tiến trình này đảm bảo mỗi thuộc tính phụ thuộc trực tiếp vào khoá chính và không phụ thuộc vào thứ gì khác.
Ví dụ, trong một bảng theo dõi ghi danh khoá học:
- 2NF: Đảm bảo các thuộc tính như tên khoá học và tên học viên phụ thuộc hoàn toàn vào khoá chính tương ứng (ví dụ Student ID và Course ID). Điều này loại bỏ phụ thuộc từng phần, nơi thuộc tính không khoá chỉ phụ thuộc vào một phần của khoá tổng hợp.
- 3NF: Đảm bảo các thuộc tính như chi tiết giảng viên hoặc thông tin khoa/bộ môn được lưu ở các bảng riêng, loại bỏ phụ thuộc bắc cầu.
3NF lý tưởng cho các hệ thống phức tạp hơn, nơi tính toàn vẹn và hiệu quả dữ liệu là tối quan trọng, đặc biệt khi dữ liệu tăng trưởng. Hãy xem bài viết Dạng chuẩn thứ ba là gì? nếu bạn muốn tìm hiểu thêm về 3NF và dạng hạn chế hơn của nó, BCNF.
Kết luận
Dạng chuẩn thứ hai là một bước thiết yếu trong chuẩn hoá cơ sở dữ liệu, bắc cầu giữa 1NF và các dạng cao hơn như 3NF. Bằng cách loại bỏ phụ thuộc từng phần, 2NF giảm dư thừa và cải thiện độ tin cậy của dữ liệu. Mặc dù có thể làm tăng độ phức tạp, lợi ích về tính toàn vẹn dữ liệu và bảo trì đơn giản hơn khiến nó trở thành phần quan trọng của thiết kế cơ sở dữ liệu hiệu quả.
Nếu bạn sẵn sàng nâng cao kỹ năng, hãy khám phá khoá học Database Design để đào sâu hiểu biết về các kỹ thuật chuẩn hoá và ứng dụng thực tiễn. Bạn cũng có thể xác nhận kỹ năng SQL và quản trị cơ sở dữ liệu, đồng thời thể hiện chuyên môn với nhà tuyển dụng tiềm năng qua SQL Associate Certification!
Cuối cùng, tôi muốn nói rằng nếu bạn là người ra quyết định trong doanh nghiệp và biết rằng bạn cần làm việc để tạo ra các cơ sở dữ liệu gọn gàng và hiệu quả hơn, hãy cân nhắc gửi yêu cầu demo DataCamp for Business. Chúng tôi có thể giúp nâng tầm năng lực đội ngũ của bạn để bạn tạo ra các hệ thống cơ sở dữ liệu có thể mở rộng, thúc đẩy hiệu quả và đổi mới cho doanh nghiệp. Chúng tôi thậm chí có thể xây dựng lộ trình học tập và track tuỳ chỉnh.
Khi làm việc với cơ sở dữ liệu, bạn thường gặp các vấn đề như dữ liệu dư thừa và cập nhật thiếu nhất quán. Dạng chuẩn thứ hai là một bước chuẩn hoá cơ sở dữ liệu xây dựng trên dạng chuẩn thứ nhất (1NF) để tạo ra các bảng gọn gàng và hiệu quả hơn.
Hiểu 2NF là điều then chốt với bất kỳ ai làm thiết kế cơ sở dữ liệu hoặc quản lý dữ liệu, và nó đặt nền tảng cho các dạng chuẩn cao hơn như dạng chuẩn thứ ba (3NF). Trong bài viết này, chúng ta sẽ khám phá cách 2NF hoạt động và cách biến đổi bảng để đáp ứng yêu cầu 2NF, kèm các ví dụ thực tế. Chúng ta cũng sẽ bàn về lợi ích và hạn chế của 2NF, cùng những trường hợp sử dụng phù hợp nhất.
Tìm hiểu về Dạng chuẩn thứ hai
Dạng chuẩn thứ hai là một bước chuẩn hoá cơ sở dữ liệu tập trung vào việc loại bỏ các phụ thuộc từng phần. Nó được giới thiệu bởi Edgar F. Codd, người tiên phong của cơ sở dữ liệu quan hệ, như một phần trong công trình về chuẩn hoá của ông.
Trước khi một bảng đạt 2NF, nó phải thoả mãn các quy tắc của dạng chuẩn thứ nhất:
2NF tiến thêm một bước với quy tắc bổ sung: loại bỏ các phụ thuộc từng phần.
Phụ thuộc từng phần xảy ra khi một thuộc tính không khoá (cột không nằm trong bất kỳ khoá ứng viên nào) phụ thuộc chỉ vào một phần của khoá tổng hợp thay vì toàn bộ khoá. Quy tắc 2NF đảm bảo mọi thuộc tính không khoá đều phụ thuộc vào toàn bộ khoá chính, không chỉ một phần của nó. Để phụ thuộc từng phần tồn tại trong bảng sẽ khiến dữ liệu dư thừa len lỏi vào cơ sở dữ liệu, dẫn đến kém hiệu quả và có thể phát sinh thiếu nhất quán khi cập nhật hoặc xoá.
Lý thuyết thôi có thể hơi khô khan, nên hãy xem một ví dụ thực tế.
Dưới đây là bảng Ghi danh khoá học của học viên Datacamp.
Ở đây, khoá chính là sự kết hợp của Student ID và Course ID. Tuy nhiên, các thuộc tính không khoá Course Name và Course Fee chỉ phụ thuộc vào Course ID, không phải toàn bộ khoá. Điều này vi phạm 2NF.
Các bước phân rã bảng để đạt 2NF
Để đảm bảo một bảng tuân theo 2NF, bạn cần:
Ví dụ về Dạng chuẩn thứ hai trong thực tế
Giờ hãy xem hai ví dụ.
Ví dụ 1: Bảng ghi danh khoá học
Trước đó, chúng ta đã thấy bảng ghi danh khoá học sau:
Hãy làm theo các bước đã nêu ở phần trước.
1. Xác định khoá ứng viên.
Trong trường hợp này, khoá ứng viên là khoá tổng hợp của Student ID và Course ID. Tổ hợp duy nhất này định danh mỗi hàng trong bảng.
2. Xác định các phụ thuộc hàm
Course Name và Instructor Name phụ thuộc vào Course ID, không phải toàn bộ khoá tổng hợp (Student ID, Course ID). Đây là phụ thuộc từng phần vì các thuộc tính này chỉ phụ thuộc vào một phần của khoá tổng hợp.
3. Loại bỏ phụ thuộc từng phần
Chúng ta cần chuyển các thuộc tính chỉ phụ thuộc vào một phần khoá (Course Name và Instructor Name) sang một bảng mới chỉ dựa trên Course ID.
Sau khi phân rã, các bảng mới của chúng ta như sau:
Bảng ghi danh khoá học
Bảng chi tiết khoá học
Nếu bạn muốn tự tay tạo cơ sở dữ liệu, hãy xem khoá học PostgresQL của chúng tôi. Nếu bạn đã ở mức nâng cao hơn một chút, bạn có thể thử Introduction to Data Modeling in Snowflake, trong đó đề cập đến các ý tưởng như mô hình hoá thực thể - quan hệ và mô hình hoá hướng chiều.
Ví dụ 2: Bảng đơn hàng
Chúng ta sẽ bắt đầu với bảng Đơn hàng sau. Hãy thử làm theo các bước đã nêu ở trên và tự phân rã bảng này!
1. Xác định khoá ứng viên
Tổ hợp Order ID và Product ID định danh duy nhất mỗi hàng, biến (Order ID, Product ID) thành khoá ứng viên tổng hợp. Không cột đơn lẻ nào có thể định danh duy nhất các hàng vì:
Điều này có nghĩa (Order ID, Product ID) cũng là khoá chính của chúng ta.
2. Xác định các phụ thuộc hàm
Order Date phụ thuộc vào Order ID (không phải toàn bộ khoá tổng hợp). Đây là một phụ thuộc từng phần.
Product Name và Supplier Name phụ thuộc vào Product ID (không phải toàn bộ khoá tổng hợp). Đây cũng là các phụ thuộc từng phần.
3. Loại bỏ phụ thuộc từng phần
Chúng ta cần tách bảng thành các bảng nhỏ hơn, mỗi bảng xử lý một phụ thuộc logic.
Đầu tiên, chúng ta sẽ tạo một bảng cho thông tin đơn hàng, chứa thông tin đặc thù theo Order ID.
Bảng Orders
Sau đó, chúng ta tạo một bảng chứa thông tin đặc thù theo Product ID.
Bảng Orders
Bảng gốc giờ chỉ còn lại khoá tổng hợp và mối quan hệ giữa đơn hàng và sản phẩm.
Giờ đây, cơ sở dữ liệu của chúng ta ở 2NF vì 1) tất cả phụ thuộc từng phần đã được loại bỏ, và 2) các thuộc tính không khoá phụ thuộc hoàn toàn vào khoá chính tương ứng.
Khi nào nên triển khai Dạng chuẩn thứ hai
Vậy tại sao bạn nên tái cấu trúc cơ sở dữ liệu theo 2NF? Nó đã đủ hay bạn nên tiến thêm một bước để đạt 3NF?
Lợi ích và hạn chế của dạng chuẩn thứ hai
Dạng chuẩn thứ hai mang lại một số lợi thế, khiến nó trở thành bước hữu ích trong quá trình chuẩn hoá cơ sở dữ liệu:
Nhưng cũng có một số hạn chế:
Cân nhắc hiệu năng với dạng chuẩn thứ hai
Phân rã bảng để loại bỏ phụ thuộc từng phần có thể tác động trực tiếp đến hiệu năng cơ sở dữ liệu. Một mặt, đạt 2NF giảm dư thừa dữ liệu và cải thiện tính nhất quán, dẫn đến ít bất thường hơn khi chèn, cập nhật hoặc xoá. Mặt khác, chuẩn hoá có thể tăng số lượng bảng, đồng nghĩa cần nhiều phép nối hơn khi truy xuất dữ liệu liên quan. Điều này có thể ảnh hưởng hiệu năng truy vấn với bộ dữ liệu lớn.
Để đảm bảo cơ sở dữ liệu đã chuẩn hoá vẫn đạt hiệu năng, hãy tuân theo các thực tiễn tốt sau:
2NF chỉ là bước trung gian để đạt dạng chuẩn thứ ba?
Trong hầu hết trường hợp, các nhà thiết kế cơ sở dữ liệu hướng tới dạng chuẩn thứ ba do khả năng giảm dư thừa sâu hơn và cải thiện tính toàn vẹn dữ liệu tổng thể. Tuy nhiên, đạt 3NF thường đòi hỏi thêm công việc, như tạo nhiều bảng và quan hệ hơn, có thể đưa đến đánh đổi về độ phức tạp và hiệu năng khi thực thi truy vấn.
Có những trường hợp chỉ dùng dạng chuẩn thứ hai là đủ. Nếu ưu tiên là sự đơn giản và triển khai nhanh, như trong các dự án nhỏ, nguyên mẫu, hoặc khi dữ liệu dư thừa tối thiểu, 2NF có thể đáp ứng. Ví dụ, trong các hệ thống mà mọi thuộc tính đã phụ thuộc hoàn toàn vào một khoá chính đơn giản, đạt 2NF có thể hoàn thành mục tiêu chính là giảm phụ thuộc từng phần mà không cần chuẩn hoá thêm.
Vượt xa dạng chuẩn thứ hai: hướng tới dạng chuẩn thứ ba
Nếu bạn muốn chuẩn hoá cơ sở dữ liệu sâu hơn, bạn có thể tiếp tục tái cấu trúc các bảng để đạt dạng chuẩn thứ ba.
3NF xây dựng trên 2NF bằng cách xử lý phụ thuộc bắc cầu – các tình huống mà thuộc tính không khoá phụ thuộc vào các thuộc tính không khoá khác thay vì khoá chính. Tiến trình này đảm bảo mỗi thuộc tính phụ thuộc trực tiếp vào khoá chính và không phụ thuộc vào thứ gì khác.
Ví dụ, trong một bảng theo dõi ghi danh khoá học:
3NF lý tưởng cho các hệ thống phức tạp hơn, nơi tính toàn vẹn và hiệu quả dữ liệu là tối quan trọng, đặc biệt khi dữ liệu tăng trưởng. Hãy xem bài viết Dạng chuẩn thứ ba là gì? nếu bạn muốn tìm hiểu thêm về 3NF và dạng hạn chế hơn của nó, BCNF.
Kết luận
Dạng chuẩn thứ hai là một bước thiết yếu trong chuẩn hoá cơ sở dữ liệu, bắc cầu giữa 1NF và các dạng cao hơn như 3NF. Bằng cách loại bỏ phụ thuộc từng phần, 2NF giảm dư thừa và cải thiện độ tin cậy của dữ liệu. Mặc dù có thể làm tăng độ phức tạp, lợi ích về tính toàn vẹn dữ liệu và bảo trì đơn giản hơn khiến nó trở thành phần quan trọng của thiết kế cơ sở dữ liệu hiệu quả.
Nếu bạn sẵn sàng nâng cao kỹ năng, hãy khám phá khoá học Database Design để đào sâu hiểu biết về các kỹ thuật chuẩn hoá và ứng dụng thực tiễn. Bạn cũng có thể xác nhận kỹ năng SQL và quản trị cơ sở dữ liệu, đồng thời thể hiện chuyên môn với nhà tuyển dụng tiềm năng qua SQL Associate Certification!
Cuối cùng, tôi muốn nói rằng nếu bạn là người ra quyết định trong doanh nghiệp và biết rằng bạn cần làm việc để tạo ra các cơ sở dữ liệu gọn gàng và hiệu quả hơn, hãy cân nhắc gửi yêu cầu demo DataCamp for Business. Chúng tôi có thể giúp nâng tầm năng lực đội ngũ của bạn để bạn tạo ra các hệ thống cơ sở dữ liệu có thể mở rộng, thúc đẩy hiệu quả và đổi mới cho doanh nghiệp. Chúng tôi thậm chí có thể xây dựng lộ trình học tập và track tuỳ chỉnh.