first normal form
- First Normal Form (1NF) requires that each column of a database table is an indivisible basic data item, and there cannot be multiple values in the same column.
- If a column has multiple values, the column can be split into an entity, and there is a one-to-many relationship between the new entity and the original entity.
- In any relational database, the first normal form (1NF) is the basic requirement for the relational schema, and a database that does not satisfy the first normal form (1NF) is not a relational database.
The first normal form is the most basic paradigm. If all field values in a database table are indecomposable atomic values , it means that the database table satisfies the first normal form.
The reasonable compliance of the first normal form needs to be determined according to the actual needs of the system. For example, in some database systems, the attribute "address" needs to be used. Originally, the "address" attribute can be directly designed as a field of a database table. However, if the system often accesses the "city" part of the "address" attribute, then the "address" attribute must be re-divided into multiple parts such as province, city, and detailed address for storage. It will be very convenient for some operations. This design is considered to meet the first normal form of the database
second normal form
- Satisfying the second normal form (2NF) must first satisfy the first normal form (1NF).
- The second normal form requires that all non-primary attributes of no row in the entity must be completely dependent on the primary key; that is, the non-primary attributes must be completely dependent on the primary key.
- Complete dependency: The primary key may be composed of multiple attributes. The complete dependency requirement does not allow non-primary attributes to depend on a certain part of the primary key.
- If there is any non-primary attribute that depends on a part of the attributes in the primary key, then create a new entity for the set of attributes where the partial dependence occurs, and use the foreign key in the old entity to associate with the new entity, and between the new entity and the old entity is a one-to-many relationship.
The second normal form goes a step further on the basis of the first normal form. The second normal form needs to ensure that each column in the database table is related to the primary key, not only a part of the primary key (mainly for the joint primary key). That is to say, in a database table, only one type of data can be stored in one table, and multiple types of data cannot be stored in the same database table.
For example, to design an order information table, because there may be multiple commodities in the order, the order number and commodity number should be used as the joint primary key of the database table, as shown in the following table.
Order Information Sheet
This creates a problem: in this table, the order number and the item number are used as the joint primary key. In this way, the commodity name, unit, commodity price and other information in the table are not related to the primary key of the table, but are only related to the commodity number. So here is a violation of the design principles of Second Paradigm.
And if this order information table is split, the product information is separated into another table, and the order item table is also separated into another table, it is perfect
third normal form
- In order to satisfy the third normal form, the second normal form must be satisfied first.
- Third Normal Form requires that properties in an entity cannot be non-primary properties in other entities. Because there will be redundancy. That is: properties do not depend on other non-primary properties.
- If non-primary attributes of other entities appear in one entity, these two entities can be associated with foreign keys instead of directly writing the non-primary attributes of another table in the current table.
The third normal form needs to ensure that each column of data in the data table is directly related to the primary key, not indirectly related .
For example, when designing an order data table, the customer number can be used as a foreign key to establish a corresponding relationship with the order table. It is not possible to add fields about other customer information (such as name, company, etc.) in the order table.
