First normal form (1NF):Emphasis is placed on atomicity of columns, that is, columns can not be further divided into other columns.
Consider such a table: “contact” (name, gender, telephone).
If in the actual scenario a contact has a home phone and a company phone, the meter structure is not designed to reach 1NF. To conform to 1NF, we simply split the columns, i.e. [contacts] (name, sex, home phone, company phone). 1NF is a good judge, but2NF and 3NF are easy to mix up.
◆ Second normal form (2NF):The first is 1NF, which contains two other parts. The first is that a table must have a primary key; the second is that columns that are not included in the primary key must depend entirely on the primary key, not only on a part of the primary key.
Consider an order sheet: [OrderDetail] (OrderID, Product ID, UnitPrice, Discount, Quantity, Product Name).
Because we know that multiple products can be ordered in an order, a single OrderID is not enough to be a primary key. The primary key should be (OrderID, Product ID). Obviously Discount (discount), Quantity (quantity).(Dependent on) the primary key (OderID, Product ID), while UnitPrice, Product Name only depends on Product ID. So the OrderDetail table does not conform to 2NF. Not conforming to 2NThe design of F is easy to generate redundant data.
The OrderDetail table can be split into OrderDetail (OrderID, Product ID, Discount, Quantity) and Product (Product ID, UnitPrice)(ProductName) to eliminate repeated duplication of UnitPrice and ProductName in the original order form.
◆ Third normal form (3NF):The first is 2NF, and the other primary key column must depend directly on the primary key, and there can be no transmission dependency. That is, it does not exist: non-primary key column A depends on non-primary key column B and non-primary key column B depends on primary key.
Consider an order table [Order] (OrderID, OrderDate, CustomerID, CustomerName, CustomerAddr, CustomerCity) with the primary key (OrderID).
OrderDate, CustomerID, CustomerName, CustomerAddr, CustomerCity and other non-primary key columns are entirely dependent on the primary key (OrderID), so they conform to 2NF. But the problem isCustomerName, CustomerAddr, CustomerCity directly depends on the CustomerID (non-primary key column), rather than the primary key. It depends on the primary key through delivery, so it does not conform to 3NF.
By splitting [Order] into [Order] (Order ID, Order Date, Customer ID) and [Customer] (Customer ID, Customer Name, Customer Addr, Cu)StomerCity) to achieve 3NF.
