Example of table data
Suppose there is a named employeeemployee table, which has nine properties: id(employee number), name(employee name), mobile(phone), zip(zip code), province(provinces), city(city), district(counties), deptNo(department number ), deptName(department name), total data table as follows:
| id | name | mobile | zip | province | city | district | deptNo | DEPTNAME |
|---|---|---|---|---|---|---|---|---|
| 101 | Joe Smith | 13910000001<br />13910000002 | 100001 | Beijing | Beijing | Haidian District | D1 | Sector 1 |
| 101 | Joe Smith | 13910000001<br />13910000002 | 100001 | Beijing | Beijing | Haidian District | D2 | Sector 2 |
| 102 | John Doe | 13910000003 | 200001 | Shanghai | Shanghai | Jing'an District | D3 | Sector 3 |
| 103 | Wang Wu | 13910000004 | 510001 | Guangdong Province | Canton | Baiyun District | D4 | Sector 4 |
| 103 | Wang Wu | 13910000004 | 510001 | Guangdong Province | Canton | Baiyun District | D5 | Sector 5 |
Because the employee table is non-standardized, we will face the following problems.
Modify abnormal table has two records on Joe Smith, because he belongs to two sectors: If we want to modify the seating of the address, modify the compulsory two rows. If a department got a new address John's and updated, and the other departments do not, then this time Joe Smith would have two different addresses in the table, resulting in inconsistent data
New Exception: If a new employee if the company, he is in the induction phase, has not been formally assigned to a department, if the
deptNofield does not allow empty, we will not be able toemployeeadd data to the employee table.To delete an exception: assume that the company withdrew D3 department, then delete
deptNoto row D3, the information will be John Doe also be deleted. D3 because he belongs to this sector.
The first paradigm (1NF)
Column in the table containing only atoms of values (no longer min).
Table seating for two phone numbers stored in the mobile column, in violation of the rules of 1NF. In order to meet the table 1NF, data should be modified as follows:
| id | name | mobile | zip | province | city | district | deptNo | DEPTNAME |
|---|---|---|---|---|---|---|---|---|
| 101 | Joe Smith | 13910000001 | 100001 | Beijing | Beijing | Haidian District | D1 | Sector 1 |
| 101 | Joe Smith | 13910000002 | 100001 | Beijing | Beijing | Haidian District | D1 | Sector 1 |
| 101 | Joe Smith | 13910000001 | 100001 | Beijing | Beijing | Haidian District | D2 | Sector 2 |
| 101 | Joe Smith | 13910000002 | 100001 | Beijing | Beijing | Haidian District | D2 | Sector 2 |
| 102 | John Doe | 13910000003 | 200001 | Shanghai | Shanghai | Jing'an District | D3 | Sector 3 |
| 103 | Wang Wu | 13910000004 | 510001 | Guangdong Province | Canton | Baiyun District | D4 | Sector 4 |
| 103 | Wang Wu | 13910000004 | 510001 | Guangdong Province | Canton | Baiyun District | D5 | Sector 5 |
The second paradigm (2NF)
The second paradigm to satisfy the following conditions
First normal form.
No part depend on
For example, a candidate key employee table is {id, mobile, deptNo}, and rely on deptName deptno, equally dependent on the name id, is therefore not 2NF. In order to meet the conditions of the second paradigm, the table needs to be split into employee, dept, employee_dept, employee_mobile four tables. as follows:
Employees table employee
| id | name | zip | province | city | district |
|---|---|---|---|---|---|
| 101 | Joe Smith | 100001 | Beijing | Beijing | Haidian District |
| 102 | John Doe | 200001 | Shanghai | Shanghai | Jing'an District |
| 103 | Wang Wu | 510001 | Guangdong Province | Canton | Baiyun District |
Department table dept
| deptNo | DEPTNAME |
|---|---|
| D1 | Sector 1 |
| D2 | Sector 2 |
| D3 | Sector 3 |
| D4 | Sector 4 |
| D5 | Sector 5 |
Employee relations department table employee_dept
| id | deptNo |
|---|---|
| 101 | D1 |
| 101 | D2 |
| 102 | D3 |
| 103 | D4 |
| 104 | D5 |
Employee phone list employee_mobile
| id | mobile |
|---|---|
| 101 | 13910000001 |
| 101 | 13910000002 |
| 102 | 13910000003 |
| 103 | 13910000004 |
Third Normal Form (3NF)
The third paradigm for both of the following conditions
- Second normal form
- No transitive dependencies
For example, province employee table, city, district depends on the zip, and zip depends on the id, in other words, province, city, district transfer depends on the id, 3NF violated the rules. In order to satisfy the condition of the third paradigm, this table may be split into two zip and employee table as follows
employee
| id | name | zip |
|---|---|---|
| 101 | Joe Smith | 100001 |
| 102 | John Doe | 200001 |
| 103 | Wang Wu | 510001 |
Area Table area
| zip | province | city | district |
|---|---|---|---|
| 100001 | Beijing | Beijing | Haidian District |
| 200001 | Shanghai | Shanghai | Jing'an District |
| 51000 | Guangdong Province | Canton | Baiyun District |
In the relational database model design in general, we need to meet the requirements of the third paradigm. If a good primary table foreign key design, it should meet the 3NF table. Bring the benefits of standardization is to improve the efficiency of the update data by reducing data redundancy, while ensuring data integrity. However, we have to prevent excessive standardization issues in practical applications. The higher degree of standardization, the more the division table, the more likely the query data using a table join operation. And too many table if connected, will affect query performance. The key question is to be based on business needs, carefully weighing data query and update the relational data, specify the most appropriate degree of standardization. Not to follow the strict rules of standardization and modify business needs.