Jdbc notes-database design paradigm and case

Database Design

Relationship between multiple tables

  1. Relationship classification

    1. One to one

      Such as people and ID cards. One person has only one ID

    2. One to many

      Such as students and departments. One student belongs to one department, and one department has many students

    3. Many to many

      Such as students and courses. A student can choose multiple courses, and a course can also be selected by multiple students

  2. Realization relationship

    1. 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

    2. 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

    3. 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:

  1. 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 学号-->姓名,(学号,课程名称) --> 分数

  2. Fully functional dependency

    A-->BIf 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

  3. Partial functional dependency

    A-->BIf 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

  4. Transfer function dependency

    A-->B, , B-->CIt 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学号

  5. 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

  1. Data is redundant (data duplication), such as student ID, name, department, professor, etc.

  2. 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

  3. 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

如此以来,就遵循了第三范式。可以新增新开设的院系和教授,学生毕业后,直接删除学生记录,不会清除掉院系的信息。数据冗余,添加数据,删除数据这三个问题都解决了。

Guess you like

Origin blog.csdn.net/vcj1009784814/article/details/106179813