Paradigm: The English name is Normal Form, which is summed up by the British EFCodd (the ancestor of the relational database) after proposing the relational database model in the 1970s. rules and guidelines to follow. There are currently 8 paradigms that can be found, in order: 1NF, 2NF, 3NF, BCNF, 4NF, 5NF, DKNF, 6NF. Usually only the first three normal forms are used, namely: first normal form (1NF), second normal form (2NF), and third normal form (3NF). These three paradigms are briefly described below.
◆ First Normal Form (1NF): Emphasizes the atomicity of the column, that is, the column cannot be divided into other columns.
Consider such a table: [Contacts] (name, gender, phone)
If in the actual scenario, a contact has a home phone and a business phone, then this table structure design does not reach 1NF. To conform to 1NF we just need to split the column (phone), ie: [contact] (name, gender, home phone, business phone). 1NF is easy to distinguish, but 2NF and 3NF are easily confused.
◆ Second Normal Form (2NF): First is 1NF, and it contains two parts. One is that the table must have a primary key; the other is that the columns that are not included in the primary key must completely depend on the primary key, not only a part of the primary key.
Consider an order detail table: [OrderDetail] (OrderID, ProductID, UnitPrice, Discount, Quantity, ProductName).
Because we know that multiple products can be ordered in one order, so a single OrderID is not enough to become the primary key, the primary key should be (OrderID, ProductID). Obviously Discount (discount), Quantity (quantity) completely depends on (depends on) the primary key (OderID, ProductID), while UnitPrice, ProductName only depends on ProductID. So the OrderDetail table does not conform to 2NF. Designs that do not conform to 2NF are prone to redundant data.
The [OrderDetail] table can be split into [OrderDetail] (OrderID, ProductID, Discount, Quantity) and [Product] (ProductID, UnitPrice, ProductName) to eliminate the repeated repetition of UnitPrice and ProductName in the original order table.
◆ Third Normal Form (3NF): The first is 2NF, and the non-primary key columns must directly depend on the primary key, and there cannot be transitive dependencies. That is, it cannot exist: the non-primary key column A depends on the non-primary key column B, and the non-primary key column B depends on the primary key.
Consider an order table [Order] (OrderID, OrderDate, CustomerID, CustomerName, CustomerAddr, CustomerCity) whose primary key is (OrderID).
Among them, OrderDate, CustomerID, CustomerName, CustomerAddr, CustomerCity and other non-primary key columns are completely dependent on the primary key (OrderID), so they conform to 2NF. However, the problem is that CustomerName, CustomerAddr, and CustomerCity directly depend on CustomerID (non-primary key column) instead of the primary key. It depends on the primary key through transit, so it does not conform to 3NF.
By splitting [Order] into [Order] (OrderID, OrderDate, CustomerID) and [Customer] (CustomerID, CustomerName, CustomerAddr, CustomerCity) to achieve 3NF.
◆ First Normal Form (1NF): Emphasizes the atomicity of the column, that is, the column cannot be divided into other columns.
Consider such a table: [Contacts] (name, gender, phone)
If in the actual scenario, a contact has a home phone and a business phone, then this table structure design does not reach 1NF. To conform to 1NF we just need to split the column (phone), ie: [contact] (name, gender, home phone, business phone). 1NF is easy to distinguish, but 2NF and 3NF are easily confused.
◆ Second Normal Form (2NF): First is 1NF, and it contains two parts. One is that the table must have a primary key; the other is that the columns that are not included in the primary key must completely depend on the primary key, not only a part of the primary key.
Consider an order detail table: [OrderDetail] (OrderID, ProductID, UnitPrice, Discount, Quantity, ProductName).
Because we know that multiple products can be ordered in one order, so a single OrderID is not enough to become the primary key, the primary key should be (OrderID, ProductID). Obviously Discount (discount), Quantity (quantity) completely depends on (depends on) the primary key (OderID, ProductID), while UnitPrice, ProductName only depends on ProductID. So the OrderDetail table does not conform to 2NF. Designs that do not conform to 2NF are prone to redundant data.
The [OrderDetail] table can be split into [OrderDetail] (OrderID, ProductID, Discount, Quantity) and [Product] (ProductID, UnitPrice, ProductName) to eliminate the repeated repetition of UnitPrice and ProductName in the original order table.
◆ Third Normal Form (3NF): The first is 2NF, and the non-primary key columns must directly depend on the primary key, and there cannot be transitive dependencies. That is, it cannot exist: the non-primary key column A depends on the non-primary key column B, and the non-primary key column B depends on the primary key.
Consider an order table [Order] (OrderID, OrderDate, CustomerID, CustomerName, CustomerAddr, CustomerCity) whose primary key is (OrderID).
Among them, OrderDate, CustomerID, CustomerName, CustomerAddr, CustomerCity and other non-primary key columns are completely dependent on the primary key (OrderID), so they conform to 2NF. However, the problem is that CustomerName, CustomerAddr, and CustomerCity directly depend on CustomerID (non-primary key column) instead of the primary key. It depends on the primary key through transit, so it does not conform to 3NF.
By splitting [Order] into [Order] (OrderID, OrderDate, CustomerID) and [Customer] (CustomerID, CustomerName, CustomerAddr, CustomerCity) to achieve 3NF.
The concepts of second normal form (2NF) and third normal form (3NF) are easy to confuse. The key point to distinguish them is, 2NF: whether the non-primary key column depends entirely on the primary key, or depends on a part of the primary key; 3NF: the non-primary key column is Directly depend on the primary key, or directly depend on the non-primary key column.
Original address: http://blog.csdn.net/famousdt/article/details/6921622