Database Tertiary paradigm

short and not cut

1NF: field is not divided;
2NF: Primary key, non-primary key field depends on primary key;
3NF: Non-primary key fields cannot depend on each other;

Explain:
1NF: Atomic field can not be re-divided, otherwise it is not a relational database;
2NF: Uniqueness A table shows only one thing;
3NF: Each column is directly related to the primary key, there is no transitive dependency;

first paradigm (ensuring that each column remains atomic)

The rational follow-up of the first paradigm needs to be determined according to the actual needs of the system. For example, some database systems need to use the "address" attribute, the "address" attribute should be directly designed as a database table field. However, if the system often accesses the "city" part of the "address" attribute, then it is not to be the "address" attribute to be re-split into provinces, cities, detailed address and other parts of storage, so that in the address of a part of the operation will be very convenient. This design satisfies the first paradigm of the database, as shown in the following table.

second paradigm (ensure that each column in the table is related to the primary key)

The second paradigm needs to ensure that each column in a database table is related to the primary key, not just one part of the primary key (primarily for the Federated primary key). In other words, in a database table, only one data can be saved in a table, and multiple data cannot be saved in the same database table.

For example, to design an order information table, because there may be more than one item in the order, the order number and the product number are used as the federated primary key for the database table, as shown in the following table.

This creates a problem: The table is the Union primary key with the order number and the product number. in this table, the product name, unit, commodity price and other information is not related to the table's primary key, but only related to the product number. So this violates the design principle of the second paradigm.

And if the Order Information table is split, the product information is separated into another table, the Order Item table is also separated into another table, it is perfect. as shown below.

third paradigm (ensure that each column is directly related to the primary key column, not indirectly)

The third paradigm needs to ensure that each column of data in a data table is directly related to the primary key, not indirectly.

For example, when designing an order data table, the customer number can be used as a foreign key and order table to establish the corresponding relationship. Instead of adding fields to the order form about other customer information (such as name, company, etc.). The design shown in the following two tables is a database table that satisfies the third paradigm.

In this way, when the order information is queried, the customer number can be used to refer to the records in the Customer information table, and the data redundancy is reduced without having to enter the contents of the customer information multiple times in the Order Information table.

I'm the dividing line of the king of the land Tiger.

Reference: http://www.cnblogs.com/linjiqin/archive/2012/04/01/2428695.html

Database Tertiary paradigm