Paradigm is the basis of the relationship database theory, but also in our design process database structure to be followed the rules and guidance methods. Currently there are eight kinds of paradigm traced, followed by: 1NF, 2NF, 3NF, BCNF, 4NF, 5NF, DKNF, 6NF.
Commonly used just before the three paradigms, namely: a first paradigm (1NF), a second paradigm (2NF), a third paradigm (3NF)
The first paradigm (1NF): emphasized that the atomic columns, i.e., columns not be subdivided into several other columns.
Consider this 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. We just need to comply with the 1NF column (telephone) split, namely: [contact] (name, gender, home phone, business phone).
1NF good discrimination, but 2NF and 3NF it is easy to confuse.
The second paradigm (2NF): First 1NF, further comprising two parts, one table must have a primary key; the second is not contained in the master key must be entirely dependent on the primary key, but can not rely only on a part of the primary key.
Consider an Order Details: 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.
[] Table can be split into OrderDetail OrderDetail [] (OrderID, ProductID, Discount, Quantity ) , and [Product] (ProductID, UnitPrice, ProductName) to eliminate the original Orders table UnitPrice, ProductName repeated situation.
The third paradigm (3NF): First, 2NF, additional non-primary key column must be directly dependent on the primary key, you can not rely on the presence of transfer. I.e. not exist: A case of non-primary key column depends on the non-primary key columns B, non-primary key column B is dependent on the primary key.
Consider an order form] [Order (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.
By resolution of [] [Order Order] (OrderID, OrderDate, CustomerID)] and [Customer (CustomerID, CustomerName, CustomerAddr, CustomerCity ) to achieve 3NF.
Concept (2NF), and a third paradigm (3NF) a second paradigm can easily be confused, distinguish them key point is, 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 It is directly dependent on the primary key, or depend directly on the non-primary key column.