Article Directory
Database Design
Relationship between multiple tables
-
Relationship classification
-
One to one
Such as people and ID cards. One person has only one ID
-
One to many
Such as students and departments. One student belongs to one department, and one department has many students
-
Many to many
Such as students and courses. A student can choose multiple courses, and a course can also be selected by multiple students
-
-
Realization relationship
-
One to many
On the more side, create a foreign key field to point to the primary key on the one side. For example, create a foreign key field dep_id in the student table, pointing to the primary key id in the department table
-
Many to many
Create an intermediate table, the intermediate table contains at least two fields, these two fields respectively point to the primary key of the two related tables. These two fields together, as the joint primary key of the intermediate table
-
One to one
Add a foreign key field on either side (the foreign key field must have a unique constraint) and point to the primary key of the other side.
-
Three paradigms
concept
When designing database tables, some specifications need to be followed.
When designing relational databases, follow different specifications, design a reasonable relational databases, these specifications are called paradigm, the paradigm in a variety of delivery times norm , the higher the paradigm, the smaller database redundancy. The sequential specification refers to the following paradigm requirements, including the previous paradigm requirements. That is, if you want to follow 2NF, you must first follow 1NF.
classification
Currently, relational databases have 6 paradigms: First Normal Form (1NF), Second Normal Form (2NF), Third Normal Form (3NF), Bath-Cord Normal Form (BCNF), Fourth Normal Form (4NF), Fifth Normal Form Paradigm (5NF, also known as perfect paradigm)
First Normal Form (1NF)
Each column is an indivisible atomic data item
Second Normal Form (2NF)
On the basis of 1NF, non-code attributes must be completely dependent on candidate codes (on the basis of 1NF, partial functional dependence of non-primary attributes on the main code is eliminated)
Some conceptual explanations:
-
Functional dependency
A-->B
, If the value of the attribute B can be uniquely determined through the attribute A (attribute group), then B depends on A.For example
学号-->姓名
,(学号,课程名称) --> 分数
-
Fully functional dependency
A-->B
If A is an attribute group, the determination of the attribute B needs to depend on all the attributes in the attribute group A. For example,(学号,课程名称)
being分数
completely dependent on -
Partial functional dependency
A-->B
If A is an attribute group, then the determination of the attribute B only needs to rely on some attributes in the attribute group A.(学号,课程名称) --> 姓名
. Only学号
one attribute is required for name confirmation -
Transfer function dependency
A-->B
, ,B-->C
It can be uniquely determined by the value of B if the value of the property attribute A (attribute group), and then through the B value can be uniquely determined attribute property value C.学号 --> 院系
,院系 --> 教授名
Then教授名
transfer depends on学号
-
code
If in a table, an attribute or attribute group is dependent on all other attributes, then this attribute or attribute group is called the code of this table
- Primary attribute: all attributes in the code attribute group
- Non-primary attributes: other attributes
Third Normal Form (3NF)
On the basis of 2NF, any non-primary attribute does not depend on other non-primary attributes (on the basis of 2NF, the transitive dependency is eliminated)
Case
student ID | Name | Faculty | course | fraction |
---|---|---|---|---|
1000 | Ari | Performance Department-Johnson | High number | 90 |
1001 | Lux | Broadcasting Department-Robin | English | 99 |
1002 | Akali | Department of Physical Education-Tom | High number | 89 |
1003 | Robbery | Department of Physical Education-Tom | English | 120 |
1000 | Ari | Performance Department-Johnson | computer | 20 |
The above database table, the department column, contains the name of the department and the professor of the department, which is obviously a separable data item and does not satisfy the first normal form. The changes are as follows.
student ID | Name | Faculty | professor | course | fraction |
---|---|---|---|---|---|
1000 | Ari | Performance Department | Johnson | High number | 90 |
1001 | Lux | Department of Broadcasting | Robin | English | 99 |
1002 | Akali | Department of Physical Education | Tom | High number | 89 |
1003 | Robbery | Department of Physical Education | Tom | English | 120 |
1000 | Ari | Performance Department | Johnson | computer | 20 |
But there are still problems
-
Data is redundant (data duplication), such as student ID, name, department, professor, etc.
-
There is a problem with adding data. If you want to open a new department, but the department has not started enrolling students, you cannot add
-
Deleting data is also problematic. If a student graduates and deletes his data, the department information will be deleted.
According to the second normal form, dismantle the table.
Student table
student ID | Name | Faculty | professor |
---|---|---|---|
1000 | Ari | Performance Department | Johnson |
1001 | Lux | Department of Broadcasting | Robin |
1002 | Akali | Department of Physical Education | Tom |
1003 | Robbery | Department of Physical Education | Tom |
Class Schedule
student ID | Course Title | fraction |
---|---|---|
1000 | High number | 90 |
1001 | English | 99 |
1002 | High number | 89 |
1003 | English | 120 |
1000 | computer | 20 |
After dismantling the table, the code of the student table is the student number, and other attributes are completely dependent on the student number; the code of the course table is (student number, course name), and other attributes are completely dependent on the code. (Partial dependence of non-primary attributes on primary attributes is eliminated)
Data redundancy has been solved , but there are still problems with adding and deleting data. For example, add a new department, or delete the record of a classmate after graduation.
Looking at the student table, the professor depends on the department, the department depends on the student number, and the relationship between the professor and the student number is transitive. According to the third paradigm, the student table is split to eliminate transitive dependence. Split the student table into the student table and the department table
Student table
student ID | Name | Faculty |
---|---|---|
1000 | Ari | Performance Department |
1001 | Lux | Department of Broadcasting |
1002 | Akali | Department of Physical Education |
1003 | Robbery | Department of Physical Education |
Faculty list
Faculty | professor |
---|---|
Performance Department | Johnson |
Department of Broadcasting | Robin |
Department of Physical Education | Tom |
如此以来,就遵循了第三范式。可以新增新开设的院系和教授,学生毕业后,直接删除学生记录,不会清除掉院系的信息。数据冗余,添加数据,删除数据这三个问题都解决了。