first normal form
Book : Eliminate duplicate data groups and ensure atomicity (data is self-contained and independent)
Understanding :
For example, in a table with a primary key created, if the primary keys of data are repeated, the repeated data groups will be moved to a new table and new primary keys will be created for these data.
In addition, the data in each column in the data table is independent (atomic).
For example:
| Name | height/weight |
|---|---|
| Xiao Ming | 170/60 |
| Xiaohong | 175/60 |
Then the first column is atomic and the second column is not atomic.
Example:
Table 1:
The primary keys of Table 1 are not repeated, but the goods in the third column are not atomic. Let's take it apart.
Table 2:
Although each column in Table 2 is atomic, the primary key is no longer unique. This can be solved by adding row item numbers to the table and then by combining keys. As shown in Table 3.
table 3:
second normal form
Book : Second Normal Form further reduces the occurrence of duplicate data. There are two rules in second normal form: First, the table must conform to the rules of first normal form. Second, each column must depend on the entire key.
In practice, an entity also needs to be split into two tables, so that there are two entities. The header is part of the parent table of two related tables. The header information only needs to be stored once, while the detail table may store multiple instance information. The header usually keeps the name of the original table, and the detail table usually starts with the header name and adds some information of the detail table.
Understanding :
The following table is shown in
Table 4:
The order time and company name are only related to the order ID and have nothing to do with the line item number. So it can be divided into 2 tables (Table 5, Table 6). Make each column in the table dependent on the entire key.
Table 5:
Table 6:
third normal form
From the book : Third normal form makes all columns in the table not only dependent on one thing, but on the right thing.
There are three rules:
The table must conform to 2NF.
No column can depend on a non-key column.
No derived data is allowed.
Understanding :
Look at Table 7 below:
It can be seen that the description is only related to the model and has nothing to do with the key. (Description depends on model not key). So we can divide Table 7 into Table 8 and Table 9. (The unit price may be different for each order, so the unit price is not included in this discussion.)
Table 8:
Table 9:
There is a column for the total price here. The total price can be calculated based on the unit price and quantity (that is, derived data.). This is not allowed in the specification. Just delete the column and perform calculations when needed to avoid taking up too much space.
fourth paradigm
Book : Solving multi-valued dependency problems. Conforms to third normal form and one column in the primary key may depend on other columns in the primary key. This situation is very rare and usually causes no real problems. Therefore, it is basically ignored in the database field.
fifth paradigm
Book : Dealing with lossless and lossy decomposition. Although a relationship can be decomposed, it cannot be logically reconstructed back to its original form. This is also very rare and is largely an academic issue and will not be discussed here.
The paradigm expression in another place is slightly different from the above. (Collated by classmates)
First normal form: Any table should have a primary key, and each field is atomic and cannot be subdivided.
Second normal form: All non-primary key fields are completely dependent on the primary key and cannot produce partial dependencies.
Third normal form: All non-primary key fields directly depend on the primary key and cannot produce transitive dependencies.
BC paradigm: Based on 3NF, there cannot be partial or transitive dependencies inside the primary key field.
Fourth Normal Form: Based on BCNF, non-primary key fields should not have multiple values.
Fifth paradigm: Based on 4NF, with the elimination of dependent multi-values, as standardization proceeds, data redundancy becomes less and less, but the efficiency of the database becomes lower and lower.
The database design should follow the three paradigms as much as possible, but trade-offs should still be made based on the actual situation. Sometimes redundancy may be traded for speed, and the ultimate purpose must be to meet customer needs.