Hãy tưởng tượng bạn phải làm việc với một cơ sở dữ liệu khổng lồ, không có cấu trúc, đầy rẫy thông tin lặp lại và dư thừa. Mỗi lần cập nhật hay xoá đều có thể trở thành thảm hoạ, dễ gây lỗi và thiếu nhất quán. Third normal form (3NF) là một phương pháp chuẩn hoá cơ sở dữ liệu đã được kiểm chứng để tránh tình trạng hỗn loạn này. Áp dụng 3NF sẽ làm gọn cấu trúc dữ liệu của bạn, đảm bảo tính hiệu quả, có tổ chức và loại bỏ các dư thừa không cần thiết.
Trong bài viết này, chúng ta sẽ khám phá cách 3NF hoạt động, vì sao nó hữu ích và cách bạn có thể áp dụng vào thực tế. Chúng ta cũng sẽ so sánh 3NF với các dạng chuẩn khác và tìm hiểu khi nào nên dùng mỗi dạng. Ai cũng có thể hưởng lợi từ việc hiểu rõ các cấu trúc này, nhưng kiến thức này đặc biệt giá trị nếu bạn là nhà thiết kế cơ sở dữ liệu hoặc nhà khoa học dữ liệu, vì nó có thể đơn giản hoá đáng kể công việc và giúp cơ sở dữ liệu của bạn đáng tin cậy hơn. Nếu bạn quan tâm đến thiết kế cơ sở dữ liệu tổng thể, hãy xem khoá học đầy đủ Database Design của chúng tôi.
Third normal form là một khái niệm then chốt trong chuẩn hoá cơ sở dữ liệu, giúp loại bỏ các phụ thuộc không mong muốn. 3NF được xây dựng dựa trên first normal form (1NF) và second normal form (2NF), tức là nó kế thừa các quy tắc của chúng: 1NF yêu cầu mỗi ô chứa giá trị nguyên tử (không thể chia nhỏ), và 2NF loại bỏ phụ thuộc bộ phận trên khoá chính tổng hợp. 3NF tiến xa hơn bằng cách loại bỏ phụ thuộc bắc cầu, tức là tình huống thuộc tính không khoá phụ thuộc gián tiếp vào khoá chính.
Với trọng tâm này, 3NF đảm bảo rằng mỗi cột không khoá trong một bảng phải gắn trực tiếp với khoá chính và không phụ thuộc vào thứ gì khác. Về mặt thực tiễn, 3NF giúp giảm thiểu dư thừa và tránh các bất thường khi chèn, cập nhật hoặc xoá dữ liệu.
Vào những năm 1970, Edgar F. Codd đã giới thiệu 3NF để chuẩn hoá các điều kiện đạt được cấu trúc cơ sở dữ liệu chuẩn hoá hoàn toàn. Một diễn giải lại của Carlo Zaniolo vài năm sau đó đã làm rõ hơn sự khác biệt giữa 3NF “kinh điển” và Boyce-Codd normal form (BCNF) mang tính ràng buộc chặt chẽ hơn. Đừng quá lo về BCNF lúc này, chúng ta sẽ quay lại vấn đề đó bên dưới.
Vậy, chính xác cần gì để đạt 3NF? Để một bảng đáp ứng, nó cần thoả các điều kiện sau:
- Ở dạng 2NF: Tức là dữ liệu đã nguyên tử, không có nhóm lặp và không có phụ thuộc bộ phận trên bất kỳ khoá tổng hợp nào.

3NF bao hàm 2NF và 1NF. Hình minh hoạ của tác giả
- Không có phụ thuộc bắc cầu: Quy tắc này là mấu chốt. Trong một bảng 3NF, mọi cột không phải khoá chính phải chỉ phụ thuộc vào khoá chính, không phụ thuộc gián tiếp qua một cột không khoá khác.
Hãy xem điều đó có ý nghĩa thực tế ra sao.
Phân rã bảng để đạt 3NF
Hãy cùng đi qua quy trình phân rã bảng để đạt 3NF. Chúng ta sẽ dùng một số dữ liệu mẫu từ các khoá học DataCamp để minh hoạ từng bước.
Bước 1: Xác định phụ thuộc bắc cầu
Đầu tiên, chúng ta sẽ tìm các thuộc tính trong bảng phụ thuộc gián tiếp vào khoá chính. Theo kinh nghiệm, nếu một thuộc tính phụ thuộc vào thứ gì khác ngoài khoá chính, điều đó cho thấy có phụ thuộc bắc cầu. Đó là dấu hiệu có thể đã đến lúc tách bảng của bạn.
Hãy xem ba bảng dưới đây. Bảng nào có phụ thuộc bắc cầu?
Bảng 1: Course
Bảng 2: Instructor
| Instructor ID | Instructor Name | Expertise |
|---|
| 1 | Sarah Johnson | Data Science |
| 2 | Tom Williams | Machine Learning |
| 3 | Emily Brown | Python |
Bảng 3: Enrollments
Câu trả lời là… Bảng 3!
Trong bảng này, Course Name phụ thuộc vào Course ID, nhưng không phụ thuộc trực tiếp vào Enrollment ID (khoá chính). Sự phụ thuộc gián tiếp này khiến Course Name trở thành một phụ thuộc bắc cầu.
Bước 2: Tách dữ liệu thành các bảng mới
Để xử lý phụ thuộc bắc cầu, chúng ta sẽ tách Bảng 1 thành hai bảng. Mỗi bảng sẽ tập trung vào dữ liệu phụ thuộc trực tiếp.
Bảng enrollments đã chỉnh sửa
| Enrollment ID | Student Name | Course ID |
|---|
| 1001 | Alice Smith | 201 |
| 1002 | Bob Green | 202 |
| 1003 | Charlie Blue | 201 |
Bảng Courses
Giờ đây, mỗi bảng chỉ chứa thông tin phụ thuộc trực tiếp vào khoá chính của nó: Course ID giờ là khoá chính cho Course Name trong bảng Courses, và Enrollment ID là khoá chính trong bảng Enrollments.
Với sự phân rã này, các bảng hiện đáp ứng yêu cầu 3NF, loại bỏ dư thừa và đảm bảo mỗi bảng chỉ lưu trữ thông tin liên quan trực tiếp.
Nếu bạn muốn thực hành và tự tạo cơ sở dữ liệu, hãy xem khoá học Creating PostgreSQL Databases của chúng tôi. Nếu đã ở mức nâng cao hơn một chút, bạn có thể thử Introduction to Data Modeling in Snowflake, bao gồm các ý tưởng như mô hình thực thể - quan hệ và mô hình hoá chiều.
Vậy tại sao phải nỗ lực để đạt 3NF? Dưới đây là những lợi ích chính:
- Tăng tính toàn vẹn dữ liệu: Bằng cách loại bỏ phụ thuộc bắc cầu, 3NF giúp đảm bảo việc cập nhật và xoá không dẫn đến dữ liệu mâu thuẫn hoặc lỗi thời giữa các bảng.
- Giảm dư thừa: Ít dư thừa hơn giúp cơ sở dữ liệu dễ bảo trì hơn và giảm mức sử dụng lưu trữ.
- Dễ bảo trì dữ liệu: Giữ thông tin cùng loại trong các bảng chuyên biệt giúp việc cập nhật bản ghi dễ dàng hơn mà không phải lần theo các mục trùng lặp.
Tuy vậy, dù cấu trúc 3NF hỗ trợ độ chính xác dữ liệu, nó cũng có thể dẫn đến dữ liệu bị phân mảnh hơn, đôi khi khiến các truy vấn phức tạp chậm hơn do phải nối nhiều bảng. Trong những trường hợp tốc độ quan trọng hơn chuẩn hoá, BCNF hoặc 4NF có thể là lựa chọn thực tế hơn.
Hãy xem các điểm khác nhau giữa các dạng.
Dưới đây là bảng so sánh để giúp bạn hiểu yêu cầu của 1NF, 2NF và 3NF.
| Tính năng | 1NF | 2NF | 3NF |
|---|
| Dữ liệu nguyên tử | ✅ | ✅ | ✅ |
| Không có phụ thuộc bộ phận | ❌ | ✅ | ✅ |
| Không có phụ thuộc bắc cầu | ❌ | ❌ | ✅ |
BCNF là một dạng “nghiêm ngặt” hơn của 3NF, loại bỏ thêm các bất thường phát sinh khi có các khoá ứng viên chồng chéo. Nó đặc biệt hữu ích trong các trường hợp phức tạp mà 3NF chưa loại bỏ hoàn toàn các phụ thuộc. BCNF áp dụng khi một thuộc tính không nguyên tố phụ thuộc vào một thuộc tính là thành phần của khoá ứng viên tổng hợp. Nghe có vẻ phức tạp, nên hãy cùng minh hoạ bằng ví dụ.
Cấu trúc hiện tại (ở 3NF)
Sau khi phân rã để đạt 3NF, chúng ta có hai bảng sau:
Bảng Enrollments
| Enrollment ID | Student Name | Course ID |
|---|
| 1001 | Alice Smith | 201 |
| 1002 | Bob Green | 202 |
| 1003 | Charlie Blue | 201 |
Bảng Courses
Trong cấu trúc này, mỗi bảng đều ở 3NF, không có phụ thuộc bắc cầu và dữ liệu được chuẩn hoá phù hợp.
Giới thiệu một yêu cầu mới
Bây giờ, hãy thêm một thuộc tính mới vào Courses: Classroom nơi mỗi khoá học được tổ chức. Thuộc tính mới này có thể dẫn đến một kịch bản cần BCNF.
Bảng courses cập nhật (3NF)
Ở đây, Course ID vẫn là khoá chính, và mọi thuộc tính khác phụ thuộc trực tiếp vào nó. Nhưng giả sử có một quy tắc mới rằng mỗi phòng học chỉ có thể tổ chức một môn tại một thời điểm. Cũng giả sử Course Name "SQL Fundamentals" có thể được mở dưới các Course ID khác nhau (như 201, 204, v.v.) nếu lịch khác nhau. Khi đó, mỗi lớp "SQL Fundamentals" vẫn sẽ diễn ra ở "Room 101", bất kể Course ID cụ thể. Kết quả là, Course Name cũng xác định duy nhất Classroom.
Điều này có nghĩa là chúng ta hiện có hai khoá ứng viên:
- Course ID
- Course Name
Với cả hai khoá ứng viên, chúng ta có một vấn đề mà 3NF không xử lý: Classroom phụ thuộc vào Course Name thay vì chỉ Course ID.
Áp dụng BCNF
Để loại bỏ vấn đề phụ thuộc này, chúng ta cần tiếp tục phân rã bảng Courses thành hai bảng riêng biệt phù hợp hơn với BCNF:
- Một bảng Courses mới, chỉ gồm Course ID và Course Name.
- Một bảng CourseDetails, lưu trữ mối liên hệ giữa Course Name và Classroom.
Cụ thể như sau:
Bảng courses đã chỉnh sửa (BCNF)
Bảng CourseDetails (BCNF)
Với cấu trúc mới này, mỗi bảng đều thoả điều kiện của BCNF:
- Trong bảng Courses, Course ID là khoá chính và mọi thuộc tính chỉ phụ thuộc vào nó.
- Trong bảng CourseDetails, Course Name là khoá chính, và Classroom chỉ phụ thuộc vào Course Name.
Thiết lập này loại bỏ mọi vấn đề phụ thuộc do các khoá ứng viên chồng chéo gây ra, đảm bảo cấu trúc được chuẩn hoá nghiêm ngặt.
Kết luận
Third normal form là một công cụ giá trị cho các nhà thiết kế cơ sở dữ liệu nhằm giữ cho dữ liệu sạch, nhất quán và không có các phụ thuộc gây rắc rối. Với 3NF, tính toàn vẹn dữ liệu được tăng cường, việc quản lý mượt mà hơn và giảm thiểu dư thừa. Hãy nhớ rằng, dù 3NF hoạt động tốt trong hầu hết tình huống, các cơ sở dữ liệu phức tạp hơn có thể hưởng lợi từ các dạng bổ sung như BCNF hoặc 4NF.
Nếu bạn thấy bài viết này hữu ích, hãy cân nhắc bước tiếp theo với SQL Associate Certification của chúng tôi. Đây là cách tuyệt vời để xác nhận kỹ năng SQL và quản trị cơ sở dữ liệu của bạn, đồng thời thể hiện chuyên môn trước các nhà tuyển dụng tiềm năng!
Hãy tưởng tượng bạn phải làm việc với một cơ sở dữ liệu khổng lồ, không có cấu trúc, đầy rẫy thông tin lặp lại và dư thừa. Mỗi lần cập nhật hay xoá đều có thể trở thành thảm hoạ, dễ gây lỗi và thiếu nhất quán. Third normal form (3NF) là một phương pháp chuẩn hoá cơ sở dữ liệu đã được kiểm chứng để tránh tình trạng hỗn loạn này. Áp dụng 3NF sẽ làm gọn cấu trúc dữ liệu của bạn, đảm bảo tính hiệu quả, có tổ chức và loại bỏ các dư thừa không cần thiết.
Trong bài viết này, chúng ta sẽ khám phá cách 3NF hoạt động, vì sao nó hữu ích và cách bạn có thể áp dụng vào thực tế. Chúng ta cũng sẽ so sánh 3NF với các dạng chuẩn khác và tìm hiểu khi nào nên dùng mỗi dạng. Ai cũng có thể hưởng lợi từ việc hiểu rõ các cấu trúc này, nhưng kiến thức này đặc biệt giá trị nếu bạn là nhà thiết kế cơ sở dữ liệu hoặc nhà khoa học dữ liệu, vì nó có thể đơn giản hoá đáng kể công việc và giúp cơ sở dữ liệu của bạn đáng tin cậy hơn. Nếu bạn quan tâm đến thiết kế cơ sở dữ liệu tổng thể, hãy xem khoá học đầy đủ Database Design của chúng tôi.
Định nghĩa Third Normal Form (3NF)
Third normal form là một khái niệm then chốt trong chuẩn hoá cơ sở dữ liệu, giúp loại bỏ các phụ thuộc không mong muốn. 3NF được xây dựng dựa trên first normal form (1NF) và second normal form (2NF), tức là nó kế thừa các quy tắc của chúng: 1NF yêu cầu mỗi ô chứa giá trị nguyên tử (không thể chia nhỏ), và 2NF loại bỏ phụ thuộc bộ phận trên khoá chính tổng hợp. 3NF tiến xa hơn bằng cách loại bỏ phụ thuộc bắc cầu, tức là tình huống thuộc tính không khoá phụ thuộc gián tiếp vào khoá chính.
Với trọng tâm này, 3NF đảm bảo rằng mỗi cột không khoá trong một bảng phải gắn trực tiếp với khoá chính và không phụ thuộc vào thứ gì khác. Về mặt thực tiễn, 3NF giúp giảm thiểu dư thừa và tránh các bất thường khi chèn, cập nhật hoặc xoá dữ liệu.
Vào những năm 1970, Edgar F. Codd đã giới thiệu 3NF để chuẩn hoá các điều kiện đạt được cấu trúc cơ sở dữ liệu chuẩn hoá hoàn toàn. Một diễn giải lại của Carlo Zaniolo vài năm sau đó đã làm rõ hơn sự khác biệt giữa 3NF “kinh điển” và Boyce-Codd normal form (BCNF) mang tính ràng buộc chặt chẽ hơn. Đừng quá lo về BCNF lúc này, chúng ta sẽ quay lại vấn đề đó bên dưới.
Hiểu các điều kiện để đạt Third Normal Form
Vậy, chính xác cần gì để đạt 3NF? Để một bảng đáp ứng, nó cần thoả các điều kiện sau:
3NF bao hàm 2NF và 1NF. Hình minh hoạ của tác giả
Hãy xem điều đó có ý nghĩa thực tế ra sao.
Phân rã bảng để đạt 3NF
Hãy cùng đi qua quy trình phân rã bảng để đạt 3NF. Chúng ta sẽ dùng một số dữ liệu mẫu từ các khoá học DataCamp để minh hoạ từng bước.
Bước 1: Xác định phụ thuộc bắc cầu
Đầu tiên, chúng ta sẽ tìm các thuộc tính trong bảng phụ thuộc gián tiếp vào khoá chính. Theo kinh nghiệm, nếu một thuộc tính phụ thuộc vào thứ gì khác ngoài khoá chính, điều đó cho thấy có phụ thuộc bắc cầu. Đó là dấu hiệu có thể đã đến lúc tách bảng của bạn.
Hãy xem ba bảng dưới đây. Bảng nào có phụ thuộc bắc cầu?
Bảng 1: Course
Bảng 2: Instructor
Bảng 3: Enrollments
Câu trả lời là… Bảng 3!
Trong bảng này, Course Name phụ thuộc vào Course ID, nhưng không phụ thuộc trực tiếp vào Enrollment ID (khoá chính). Sự phụ thuộc gián tiếp này khiến Course Name trở thành một phụ thuộc bắc cầu.
Bước 2: Tách dữ liệu thành các bảng mới
Để xử lý phụ thuộc bắc cầu, chúng ta sẽ tách Bảng 1 thành hai bảng. Mỗi bảng sẽ tập trung vào dữ liệu phụ thuộc trực tiếp.
Bảng enrollments đã chỉnh sửa
Bảng Courses
Giờ đây, mỗi bảng chỉ chứa thông tin phụ thuộc trực tiếp vào khoá chính của nó: Course ID giờ là khoá chính cho Course Name trong bảng Courses, và Enrollment ID là khoá chính trong bảng Enrollments.
Với sự phân rã này, các bảng hiện đáp ứng yêu cầu 3NF, loại bỏ dư thừa và đảm bảo mỗi bảng chỉ lưu trữ thông tin liên quan trực tiếp.
Nếu bạn muốn thực hành và tự tạo cơ sở dữ liệu, hãy xem khoá học Creating PostgreSQL Databases của chúng tôi. Nếu đã ở mức nâng cao hơn một chút, bạn có thể thử Introduction to Data Modeling in Snowflake, bao gồm các ý tưởng như mô hình thực thể - quan hệ và mô hình hoá chiều.
Lợi ích và hạn chế khi dùng Third Normal Form
Vậy tại sao phải nỗ lực để đạt 3NF? Dưới đây là những lợi ích chính:
Tuy vậy, dù cấu trúc 3NF hỗ trợ độ chính xác dữ liệu, nó cũng có thể dẫn đến dữ liệu bị phân mảnh hơn, đôi khi khiến các truy vấn phức tạp chậm hơn do phải nối nhiều bảng. Trong những trường hợp tốc độ quan trọng hơn chuẩn hoá, BCNF hoặc 4NF có thể là lựa chọn thực tế hơn.
So sánh: First, Second, Third và Boyce-Codd Normal Forms
Hãy xem các điểm khác nhau giữa các dạng.
Bảng so sánh: first, second và third normal forms
Dưới đây là bảng so sánh để giúp bạn hiểu yêu cầu của 1NF, 2NF và 3NF.
BCNF là một dạng “nghiêm ngặt” hơn của 3NF, loại bỏ thêm các bất thường phát sinh khi có các khoá ứng viên chồng chéo. Nó đặc biệt hữu ích trong các trường hợp phức tạp mà 3NF chưa loại bỏ hoàn toàn các phụ thuộc. BCNF áp dụng khi một thuộc tính không nguyên tố phụ thuộc vào một thuộc tính là thành phần của khoá ứng viên tổng hợp. Nghe có vẻ phức tạp, nên hãy cùng minh hoạ bằng ví dụ.
Cấu trúc hiện tại (ở 3NF)
Sau khi phân rã để đạt 3NF, chúng ta có hai bảng sau:
Bảng Enrollments
Bảng Courses
Trong cấu trúc này, mỗi bảng đều ở 3NF, không có phụ thuộc bắc cầu và dữ liệu được chuẩn hoá phù hợp.
Giới thiệu một yêu cầu mới
Bây giờ, hãy thêm một thuộc tính mới vào Courses: Classroom nơi mỗi khoá học được tổ chức. Thuộc tính mới này có thể dẫn đến một kịch bản cần BCNF.
Bảng courses cập nhật (3NF)
Ở đây, Course ID vẫn là khoá chính, và mọi thuộc tính khác phụ thuộc trực tiếp vào nó. Nhưng giả sử có một quy tắc mới rằng mỗi phòng học chỉ có thể tổ chức một môn tại một thời điểm. Cũng giả sử Course Name "SQL Fundamentals" có thể được mở dưới các Course ID khác nhau (như 201, 204, v.v.) nếu lịch khác nhau. Khi đó, mỗi lớp "SQL Fundamentals" vẫn sẽ diễn ra ở "Room 101", bất kể Course ID cụ thể. Kết quả là, Course Name cũng xác định duy nhất Classroom.
Điều này có nghĩa là chúng ta hiện có hai khoá ứng viên:
Với cả hai khoá ứng viên, chúng ta có một vấn đề mà 3NF không xử lý: Classroom phụ thuộc vào Course Name thay vì chỉ Course ID.
Áp dụng BCNF
Để loại bỏ vấn đề phụ thuộc này, chúng ta cần tiếp tục phân rã bảng Courses thành hai bảng riêng biệt phù hợp hơn với BCNF:
Cụ thể như sau:
Bảng courses đã chỉnh sửa (BCNF)
Bảng CourseDetails (BCNF)
Thiết lập này loại bỏ mọi vấn đề phụ thuộc do các khoá ứng viên chồng chéo gây ra, đảm bảo cấu trúc được chuẩn hoá nghiêm ngặt.
Kết luận
Third normal form là một công cụ giá trị cho các nhà thiết kế cơ sở dữ liệu nhằm giữ cho dữ liệu sạch, nhất quán và không có các phụ thuộc gây rắc rối. Với 3NF, tính toàn vẹn dữ liệu được tăng cường, việc quản lý mượt mà hơn và giảm thiểu dư thừa. Hãy nhớ rằng, dù 3NF hoạt động tốt trong hầu hết tình huống, các cơ sở dữ liệu phức tạp hơn có thể hưởng lợi từ các dạng bổ sung như BCNF hoặc 4NF.
Nếu bạn thấy bài viết này hữu ích, hãy cân nhắc bước tiếp theo với SQL Associate Certification của chúng tôi. Đây là cách tuyệt vời để xác nhận kỹ năng SQL và quản trị cơ sở dữ liệu của bạn, đồng thời thể hiện chuyên môn trước các nhà tuyển dụng tiềm năng!