Chuyển đến nội dung chính

Third Normal Form (3NF) là gì?

Tìm hiểu cách third normal form (3NF) giúp bạn tổ chức cơ sở dữ liệu hiệu quả hơn bằng cách loại bỏ dư thừa và giảm thiểu các vấn đề phụ thuộc. Xem cách phân rã bảng có thể đơn giản hoá quản lý dữ liệu.
Đã cập nhật 5 thg 6, 2026  · 9 phút đọc

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:

  • Ở 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.

1NF, 2NF, and 3NF requirements

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

Course ID Course Name Difficulty
201 SQL Fundamentals Beginner
202 Introduction to Python Beginner
203 Understanding Data Science Intermediate

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

Enrollment ID Student Name Course ID Course Name
1001 Alice Smith 201 SQL Fundamentals
1002 Bob Green 202 Introduction to Python
1003 Charlie Blue 201 SQL Fundamentals

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

Course ID Course Name
201 SQL Fundamentals
202 Introduction to Python

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:

  • 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.

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.

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

Third normal form so với Boyce-Codd normal form (BCNF)

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

Course ID Course Name
201 SQL Fundamentals
202 Introduction to Python

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)

Course ID Course Name Classroom
201 SQL Fundamentals Room 101
202 Introduction to Python Room 102
203 Understanding Data Science Room 101

Ở đâ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:

  1. Course ID
  2. 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:

  1. Một bảng Courses mới, chỉ gồm Course IDCourse Name.
  2. Một bảng CourseDetails, lưu trữ mối liên hệ giữa Course NameClassroom.

Cụ thể như sau:

Bảng courses đã chỉnh sửa (BCNF)

Bảng CourseDetails (BCNF)

Course Name Classroom
SQL Fundamentals Room 101
Introduction to Python Room 102
Understanding Data Science Room 101

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!


Marie Fayard's photo
Author
Marie Fayard

Tôi là một trưởng nhóm kỹ thuật định hướng sản phẩm, chuyên giúp các startup giai đoạn đầu phát triển từ nguyên mẫu đầu tiên đến khi đạt được sự phù hợp sản phẩm - thị trường và xa hơn nữa. Tôi luôn tò mò về cách con người sử dụng công nghệ, và tôi thích làm việc sát sao với nhà sáng lập và các nhóm liên chức năng để biến những ý tưởng táo bạo thành hiện thực. Khi không xây dựng sản phẩm, tôi tìm cảm hứng ở những miền đất mới hoặc xả căng thẳng tại phòng tập yoga.

Câu hỏi thường gặp về Third Normal Form

3NF có thể áp dụng cho mọi loại cơ sở dữ liệu không?

Mặc dù 3NF hiệu quả trong cơ sở dữ liệu quan hệ, nó không phải lúc nào cũng cần thiết cho cơ sở dữ liệu NoSQL, vốn thường ưu tiên tính linh hoạt và khả năng mở rộng hơn là chuẩn hoá nghiêm ngặt. Trong một số trường hợp, sơ đồ phi chuẩn hoá có thể được ưu tiên vì hiệu năng, đặc biệt khi cần truy vấn lượng dữ liệu lớn với tốc độ cao.

Nhược điểm của việc tuân thủ chặt chẽ 3NF là gì?

Tuân thủ nghiêm ngặt 3NF đôi khi dẫn đến sơ đồ phức tạp với nhiều bảng, có thể yêu cầu nhiều phép nối trong truy vấn. Điều này có thể ảnh hưởng tiêu cực đến hiệu năng, đặc biệt trong các cơ sở dữ liệu lớn hoặc hệ thống có lưu lượng giao dịch cao. Trong những trường hợp như vậy, các cách tiếp cận thay thế như phi chuẩn hoá hoặc sử dụng BCNF có thể thực tế hơn.

Có thể áp dụng 3NF cho cơ sở dữ liệu đã tồn tại không, hay cần thiết kế lại?

Chắc chắn có thể áp dụng 3NF cho các cơ sở dữ liệu hiện có, dù có thể cần tái cấu trúc đáng kể. Quy trình này, gọi là tái cấu trúc cơ sở dữ liệu (database refactoring), liên quan đến việc phân rã bảng để loại bỏ dư thừa và phụ thuộc. Tuỳ vào quy mô và độ phức tạp, bạn cần lập kế hoạch và kiểm thử để đảm bảo tính toàn vẹn dữ liệu và hiệu năng hệ thống.

Những công cụ hoặc kỹ thuật nào có thể giúp tự động hoá quá trình đạt 3NF?

Có nhiều công cụ thiết kế cơ sở dữ liệu như MySQL Workbench, Oracle SQL Developer và ER/Studio giúp trực quan hoá sơ đồ và xác định vấn đề chuẩn hoá. Một số công cụ có thể gợi ý hoặc tự động hoá các bước để đạt 3NF, dù vẫn cần con người giám sát để đảm bảo tính toàn vẹn và nhất quán dữ liệu.

Sự khác nhau giữa candidate key và primary key là gì?

Candidate key là một tập thuộc tính tối thiểu có thể nhận dạng duy nhất mỗi hàng trong một bảng. Một bảng có thể có nhiều candidate key. Trong khi đó, primary key là candidate key cụ thể được nhà thiết kế chọn để nhận dạng duy nhất các hàng. Mỗi bảng chỉ có một primary key và nó không được phép có giá trị NULL.

Tại sao cần Boyce-Codd normal form (BCNF) nếu một bảng đã ở third normal form (3NF)?

BCNF nghiêm ngặt hơn 3NF và xử lý các trường hợp tồn tại phụ thuộc trên các khoá ứng viên. Trong khi 3NF loại bỏ phụ thuộc bắc cầu, nó vẫn có thể cho phép dư thừa nếu một phụ thuộc hàm có vế trái không phải là siêu khoá. BCNF loại bỏ điều này bằng cách đảm bảo mọi phụ thuộc hàm đều có siêu khoá ở vế trái.

Một bảng có thể có nhiều candidate key không?

Có. Một bảng có thể có nhiều candidate key. Mỗi candidate key là một tập thuộc tính duy nhất và tối thiểu để nhận dạng các hàng.

Chủ đề

Học với DataCamp

Tracks

Kỹ sư Trợ lý Trí tuệ Nhân tạo (AI) cho Lập trình viên

26 giờ
Học cách tích hợp trí tuệ nhân tạo (AI) vào các ứng dụng phần mềm thông qua việc sử dụng các giao diện lập trình ứng dụng (API) và các thư viện mã nguồn mở. Hãy bắt đầu hành trình trở thành Kỹ sư Trí tuệ Nhân tạo ngay hôm nay!
Xem chi tiếtRight Arrow
Bắt đầu khóa học
Xem thêmRight Arrow