table of Contents
Chapter One Database Basics
Article Directory
Preface
I think I didn't study deeply enough in university, and found that I need to use it in many places in actual work. So write down this article to help you sort out your knowledge, and hope that you can provide help if you need it. The road of self-study, if there are mistakes, please correct them, thank you very much !
The text from the author's inner understanding (and comprehensive consideration in combination with relevant literature):
Database design paradigm
Definition and function
The paradigm is a relational database design specification. Its introduction is to solve the problems of storage exceptions (additions, deletions, and changes) and data redundancy , but cannot improve access efficiency.
species
From low to high as required: 1NF ⊃ 2NF ⊃ 3NF ⊃ BCNF ⊃ 4NF ⊃ 5NF.
High-level paradigms have increased requirements on the basis of low-level paradigms. The higher the level, the smaller the data redundancy, but the more complex the query, and generally only need to meet the third paradigm.
First Normal Form (1NF)
Each attribute in the definition relationship is indivisible , that is, each field is an indivisible data unit .
After reading the following two examples, you will understand~
eg1_ The wrong way of the first normal form:
we found that the "contact information" also contains "mobile phone number" and "email", which violates the inseparability of fields in the first normal form . Should be set as follows:
The correct way of eg2_ first normal form:
Second Normal Form (2NF)
The definition is based on the first normal form , eliminating the partial dependence of non -primary attributes on codes (keys), and non-primary key fields are completely dependent on candidate code fields .
That is, there must be one (or more) primary key, and the columns not included in the primary key must all depend on all primary keys, not just a part of the primary key.
What is partial dependence ? Let's look at an example in the same way~
The table after the first paradigm is divided: [Admission ticket number, examination subject] is our main attribute.
Its field relationship is as follows:
As can be seen from the above figure, the admission ticket number can be uniquely determined [name, mobile phone number, email, professional Name, professional director], there is no need to determine through examination subjects
, we believe that [name, mobile phone number, email address, professional name, professional director] partly depends on [admission ticket number, examination subject]
What are the disadvantages of this ?
1. There is a large amount of data redundancy : the admission ticket number, name and other data of each candidate are repeated many times. The data of each major and corresponding director is repeated many times.
2. There is an insertion exception : If a new major is created, but no students are enrolled, the major name and professional director data cannot be inserted into the data table.
(Because the primary key value cannot be empty, that is, the admission ticket number and the test subject cannot be empty)
3. There is a modification exception : If Gaochun transfers to the network security major, the professional name and professional director data in the three records need to be modified at the same time.
4. There is a deletion exception : If the records of all candidates in a certain profession are deleted, the professional name of the profession and the data of the professional director will also disappear.
(The absence of all candidates for a major does not mean that the major does not exist)
How to eliminate partial dependence so that it meets the second normal form ?
After schema decomposition, the field relations are as follows: The
table structure is as follows: Have
you improved the shortcomings before ?
1. There is a lot of data redundancy? [Improved] The admission ticket number and name of each candidate; the number of repetitions of data for each major and the corresponding director is reduced.
2. Is there an insert exception ? [No improvement] If you create a new major, but no candidates are set, you cannot insert the name of the major and the data of the professional director into the table.
3. Is there a modification exception? [Improved] If Gaochun transfers to the network security major, he only needs to modify the professional name and professional director data in one record.
4. Is there a deletion exception ? [No improvement] If you delete all records of candidates in a major, the name of the major and the data of the professional director will also disappear.
Therefore, only meeting the requirements of 2NF is not enough in many cases. We also need to improve the database tables that meet the requirements of 2NF to those that meet the requirements of 3NF.
Third Normal Form (3NF)
Defined on the basis of the second paradigm , eliminating transitive dependence, non-primary key columns must directly depend on the primary key column .
What is transitive dependency ?
In the above example, the professional name can uniquely identify the professional director, and it does not need to be determined by the admission ticket number, so the transmission of [professional director] depends on the [admission ticket number].
How to eliminate transitive dependence and make it satisfy the third normal form ?
After schema decomposition, the field relations are as follows: The
table structure is as follows: Have
you improved the shortcomings before ?
1. There is a lot of data redundancy? [Improved] There is no need to write out the professional director of each candidate.
2. Is there an insert exception? [Improved] If you create a new major but no candidates are set, you can also insert the name of the major and the data of the professional director into the table.
3. Is there a deletion exception? [Improved] If you delete all records of candidates in a major, then the major name and professional director data still exist.
to sum up
1NF: Every attribute in the relationship is indivisible.
2NF: On the basis of 1NF, part of the functional dependence of non-primary attributes on codes (keys) is eliminated.
3NF: On the basis of 2NF, the transfer function dependence of non-primary attributes on codes (keys) is eliminated.