Three database paradigm
(1) First Normal Form (1NF):
Definition: Each column is indivisible atomic data items (emphasized that the atomic column);
Example: a table: [contact] (name, gender, telephone) if the actual scenario, there is a contact home phone and business phone, then this table structure design is not reached 1NF. Solution: To comply with 1NF we simply column (telephone) split, namely: [contact] (name, gender, home phone, business phone). 1NF good discrimination, but 2NF and 3NF it is easy to confuse.
(2) The second paradigm (2NF):
Definition: primary key, required properties of the entity entirely dependent on the primary key. The so-called completely dependent on the presence of means can not rely solely on a part of the primary key attribute; (emphasized be unique)
For example: an order list: [OrderDetail] (OrderID, ProductID, UnitPrice, Discount , Quantity, ProductName).
Because we know that the order can be ordered in a variety of products, it is not enough to be just a OrderID primary key, the primary key should be (OrderID, ProductID).
Apparent from the Discount (discounts), Quantity (amount) is completely dependent (dependent) to the main key (OderID, ProductID),
and UnitPrice, ProductName only depends on the ProductID. So OrderDetail table does not meet the 2NF. The design does not meet the 2NF prone redundant data. Solution:
can OrderDetail] [[table split into OrderDetail] (OrderID, ProductID, Discount, Quantity ) , and
[Product] (ProductID, UnitPrice, ProductName) to eliminate the original Orders table UnitPrice, ProductName repeated situation.
(3) Third Normal Form (3NF):
Definition: Any non-primary property is not dependent on other non-primary property (to eliminate transfer rely on 2NF basis);
i.e. not exist: non-primary key column A is dependent on non-primary key columns B, non-primary key non-primary key column must be directly dependent on the primary key, not transitive dependencies exist. Column B depends on the case of the primary key.
Example: Order [a] Orders table (OrderID, OrderDate, CustomerID, CustomerName , CustomerAddr, CustomerCity) is the primary key (OrderID).
Wherein OrderDate, CustomerID, CustomerName, CustomerAddr, CustomerCity other non-primary key column are fully dependent on the primary key (OrderID), so the compliance 2NF.
But the problem is CustomerName, CustomerAddr, CustomerCity is directly dependent on the CustomerID (non-primary key columns), rather than directly dependent on the primary key,
which is passed through only dependent on the primary key, so do not meet 3NF. Solution:
by resolution of [] [Order Order] (OrderID, OrderDate, CustomerID) and
[] Customer (CustomerID, CustomerName, CustomerAddr, CustomerCity ) to achieve 3NF.
The second paradigm and the third paradigm comparison:
2NF: non-primary key column is completely dependent on the primary key, or dependent on the part of the primary key;
3NF: non-primary key column is directly dependent on the primary key, or depend directly on the non-primary key column.
Original link: https: //blog.csdn.net/csdnluolei/article/details/83410855