Three design paradigms of database
-
First Normal Form (1NF): Ensure that each column in the data table is atomic, that is, each column contains data items that cannot be subdivided. This means that there cannot be duplicate data in each column, nor can it contain multiple values. Each data item should be independent so that it can be sorted, searched and filtered efficiently.
-
Second Normal Form (2NF): On the basis of satisfying the first normal form, non-primary key columns are required to be completely dependent on the primary key, not a part of the primary key. Simply put, it is to ensure that the relationship between non-primary key columns and primary keys is one-to-one, not one-to-many. This eliminates data redundancy and reduces update exceptions.
-
Third Normal Form (3NF): On the basis of satisfying the second normal form, there is no transitive dependency between non-primary key columns. In other words, non-primary key columns cannot depend on each other, but are associated through the primary key. This can further eliminate data redundancy, reduce update exceptions, and improve data consistency and integrity.
Following these three design paradigms can help design a well-structured, efficient, and maintainable database model. However, sometimes depending on the specific situation, it may be necessary to design flexibly according to actual needs, or even violate certain paradigms.
BCNF
BCNF (Boyce-Codd Normal Form, Boyce-Codd Normal Form) is a more advanced paradigm in database design, which further eliminates functional dependencies on the basis of the third normal form (3NF).
BCNF requires a relational schema R to satisfy the following two conditions:
- R must satisfy third normal form (3NF).
- For every nontrivial functional dependency X → Y in relational schema R, X must be a superkey of R.
Among them, non-trivial functional dependence refers to the case where Y does not contain X, that is, Y cannot be completely dependent on a proper subset of X. A superkey is a collection of attributes that can uniquely identify each tuple in a relational schema.
The goal of BCNF is to eliminate the non-trivial functional dependencies between all the main attributes in the relational schema and ensure the integrity and consistency of the data. Following BCNF can avoid data redundancy and update exceptions, and improve database performance and maintainability.
It should be noted that BCNF is not the highest normal form in database design. In some cases, it may be necessary to further optimize the design, such as using fourth normal form (4NF) or other extended normal forms.
for example
An example that satisfies the three design paradigms:
Suppose we have a database table called "Orders" that records customer order information. The table contains the following columns: Order Number (OrderID), Customer ID (CustomerID), Customer Name (CustomerName), Product ID (ProductID), Product Name (ProductName), Order Date (OrderDate), Order Quantity (Quantity), Order Total Price (TotalPrice).
| OrderID | CustomerID | CustomerName | ProductID | ProductName | OrderDate | Quantity | TotalPrice |
|---|---|---|---|---|---|---|---|
| 1 | 101 | Alice | 201 | Widget A | 2023-05-01 | 2 | 20.00 |
| 2 | 102 | Bob | 202 | Widget B | 2023-05-02 | 3 | 30.00 |
| 3 | 101 | Alice | 203 | Widget C | 2023-05-03 | 1 | 15.00 |
In this example, each column is atomic, there is no repeated data or multiple values, and satisfies the first normal form; the
non-primary key column is completely dependent on the primary key (OrderID), not on a part of the primary key, and satisfies the second normal form;
There is no transitive dependency between non-primary key columns, which satisfies the third normal form.
Examples that do not satisfy the three design paradigms:
Suppose we have a database table named "Student_Course", which records the information of courses taken by students. The table contains the following columns: Student ID (StudentID), Student Name (StudentName), Course List (Courses).
| StudentID | StudentName | Courses |
|---|---|---|
| 1 | Alice | Math, Science |
| 2 | Bob | Math, History |
| 3 | Charlie | Science, Geography |
In this example, although each column is atomic and satisfies first normal form, the column of courses (Courses) contains multiple values, which violates the requirements of first normal form. In addition, the design also violates the second and third normal forms, because the non-primary key column (course list) is partially dependent on the primary key (student ID), and there is a transitive dependency (for example, the relationship between courses depends on student ID ). Therefore, the design does not satisfy the three design paradigms.
Example that satisfies BCNF:
Suppose we have a database table called "Book Author" (Book_Author), which records the relationship between books and authors. The table contains the following columns: Book ID (BookID), Book Name (BookName), Author ID (AuthorID), Author Name (AuthorName).
| BookID | BookName | AuthorID | AuthorName |
|---|---|---|---|
| 1 | Book A | 101 | Author X |
| 2 | Book B | 102 | Author Y |
| 3 | Book C | 101 | Author X |
| 4 | Book D | 103 | Author Z |
In this example, each column is atomic, there is no repeated data or multiple values, and satisfies the first normal form; the non-primary key column is completely dependent on the primary key (BookID), not on a part of the primary key, and satisfies the second normal form; And there is no transitive dependency between non-primary keys, satisfying the third normal form. Also, for any non-trivial functional dependency (e.g., BookID → AuthorName), the left-hand side is a superkey, thus satisfying BCNF.
Example that does not satisfy BCNF:
Suppose we have a database table named "Student_Course_Grade" (Student_Course_Grade), which records the courses taken by students and their grade information. The table contains the following columns: Student ID (StudentID), Student Name (StudentName), Course ID (CourseID), Course Name (CourseName), Grade (Grade).
| StudentID | StudentName | CourseID | CourseName | Grade |
|---|---|---|---|---|
| 1 | Alice | 101 | Math | A |
| 1 | Alice | 102 | Science | B |
| 2 | Bob | 101 | Math | B+ |
| 2 | Bob | 103 | History | A- |
| 3 | Charlie | 102 | Science | A |
In this example, each column is atomic, there is no repeated data or multiple values, and satisfies the first normal form; the non-primary key columns are completely dependent on the primary key (StudentID, CourseID), rather than relying on part of the primary key, satisfying the second Normal form; there is no transitive dependency between non-primary key columns, satisfying the third normal form.
However, this design does not satisfy BCNF because of non-trivial functional dependencies. For example, for (StudentID, CourseID) as the primary key, we can infer (StudentID, CourseName) as a non-trivial functional dependency. This means that the non-primary key column (CourseName) is dependent on part of the primary key (StudentID), rather than completely dependent on the entire primary key. Therefore, this design violates BCNF. To satisfy BCNF, the table can be decomposed into two relations, one containing (StudentID, CourseID, Grade) and the other containing (CourseID, CourseName) to eliminate dependencies.