Database specific interpretation of paradigm

Hello everyone , I meet you again , I'm the king of the whole stack .

data Library paradigm 1NF 2NF 3NF BCNF( example ）

Design paradigm （ normal form , Database design paradigm , Database design paradigm ） Is a collection of relational patterns that fit at a certain level . The construction of database must follow certain rules . In a relational database , Such rules are paradigms . The relationship in relational database must meet certain requirements , That is to meet different paradigms . At present, there are six paradigms of relational databases ： First normal form （1NF）、 Second normal form （2NF）、 Third normal form （3NF）、 Fourth normal form （4NF）、 The fifth paradigm （5NF） And the sixth paradigm （6NF）. The paradigm that meets the minimum requirements is the first paradigm （1NF）. What further satisfies many other requirements on the basis of the first paradigm is called the second paradigm （2NF）, The other paradigms are analogies . As a general rule . The database only needs to meet the third paradigm （3NF） That's all. . Here are some examples of the first paradigm （1NF）、 Second normal form （2NF） And the third paradigm （3NF）. In the process of creating a database , Normalization is the process of converting it into some tables , Such a method can make the results obtained from the database more clear . This may cause the database to generate repeated data , This leads to the creation of redundant tables . Normalization is to identify the data elements in the database 、 Relationship , And a detailed process after the initial work of defining the required tables and items in each table . The following is an example of normalization Customer Item purchased Purchase price Thomas Shirt 40 Maria Tennis shoes 35 Evelyn Shirt 40 Pajaro Trousers 25 Suppose the above table is used to save the price of items , And you want to delete one of the customers , Then you have to delete a price at the same time . Normalization is to solve problems , You can turn this table into two tables . One is used to store information about each customer and the items he buys , There is also an information store for each product and its price , In this way, adding or deleting one of the tables will not affect the other table .

Introduction to several design paradigms of relational database

1 First normal form （1NF）

In any relational database , First normal form （1NF） It's a basic requirement for relational patterns . Not satisfied with the first paradigm （1NF） Is not a relational database . The so-called first paradigm （1NF） It refers to that every column of the database table is a basic data item that cannot be cut . Cannot have more than one value in the same column , That is, an attribute in an entity cannot have multiple values or repeated attributes . Suppose there are repeated attributes , It may be necessary to define a new entity , The new entity consists of repeated attributes , There is a one to many relationship between the new entity and the original entity . In the first paradigm （1NF） Each row in the table contains only the information of one instance . such as , For Graphs 3-2 Employee information table in , You cannot display all employee information in one column , You cannot display two or more columns in one column ; Each row of the employee information table only represents the information of one employee . The information of an employee only appears once in the table .

In short , The first paradigm is the column without repetition .

2 Second normal form （2NF） Second normal form （2NF） It's in the first paradigm （1NF） Based on . That is to meet the second paradigm （2NF） We must first satisfy the first paradigm （1NF）.

Second normal form （2NF） Every instance or row in the database table must be uniquely distinguished .

In order to distinguish, you usually need to add a column to the table . To store a unique identifier for each instance . Pictured 3-2 The employee number is added to the employee information form （emp_id） Column , Because the employee number of each employee is unique . Therefore, every employee can be uniquely distinguished . This unique attribute column is called master keyword Or the primary key 、 Main code .

Second normal form （2NF） The attributes of the entity are required to be completely dependent on the master keyword. The so-called total dependence means that there can be no existence and only depend on the Lord keyword Part of the properties , Suppose there is , Then this attribute and master keyword This part of should be separated to form a new entity , There is a one to many relationship between the new entity and the original entity .

In order to distinguish, you usually need to add a column to the table . To store a unique identifier for each instance . In short , The second paradigm is that the non principal attribute is not partially dependent on the principal keyword.

3 Third normal form （3NF）

Meet the third paradigm （3NF） The second paradigm must be satisfied first （2NF）. In short , Third normal form （3NF） It is required that a database table does not include non primary tables that have been included in other tables keyword Information .

such as , There is a department information table , Each department has a department number （dept_id）、 Department name 、 Brief introduction of the Department and other information . So in the figure 3-2 After the department number is listed in the employee information table, the Department name can no longer be 、 The brief introduction of the Department and other information related to the Department will be added to the employee information table . Assume that there is no department information table . According to the third paradigm （3NF） It should also be built . Otherwise, there will be a lot of data redundancy . In short . The third paradigm is that attributes do not depend on other non primary attributes . Analysis of three application examples of database design paradigm The design paradigm of database is the specification that database design needs to meet , Databases that meet these specifications are simple 、 Well structured , At the same time , No insertion occurs （insert）、 Delete （delete） And update （update） Abnormal operation . On the contrary, it is a mess , It's not just a problem for database programmers , And disgusting , It may store a lot of unnecessary redundant information . Is the design paradigm very difficult to understand ？ no , College textbooks give us a bunch of mathematical formulas, which we certainly can't understand . I can't remember . So many of us don't design databases according to the paradigm at all .

In essence , The design paradigm is very vivid 、 Very simple words can make it clear , Tao clear .

This article will explain the paradigm in a popular way . And take the database of a simple forum designed by the author as an example to explain how to apply these paradigms to practice project.

Paradigm explanation

First normal form （1NF）： The fields in the database table are all single property , Can not be further divided . This single property consists of basic types , Include integer 、 The set of real Numbers 、 Character 、 The logical model 、 Date type, etc .

such as . For example, the following database tables conform to the first paradigm ：

Field 1 Field 2 Field 3 Field 4

This kind of database table does not conform to the first paradigm ：

Field 1 Field 2 Field 3 Field 4 Field 3.1 Field 3.2

Obviously . In the current no matter what relational database management system （DBMS） in , It's impossible for a fool to make a database that doesn't conform to the first paradigm , Because of these DBMS I don't agree with you to divide a column of the database table into two or more columns . therefore . You want to be in the existing DBMS It is impossible to design a database that does not conform to the first paradigm .

Second normal form （2NF）： Non keyword Segment for any candidate keyword Some functional dependencies of segments （ Partial functional dependency refers to the existence of combinations keyword Some fields in determine non keyword Paragraph ）. That is, all non keyword All segments depend entirely on a random set of candidates keyword.

Suppose the relation table of course selection is SelectCourse( Student number , full name , Age , Course name , achievement , credits ),keyword For combination keyword( Student number , Course name ), Due to the existence of, for example, the following decision relationship ： ( Student number , Course name ) → ( full name , Age , achievement , credits )

This database table does not satisfy the second normal form , Due to the existence of, for example, the following decision relationship ： ( Course name ) → ( credits ) ( Student number ) → ( full name , Age ) That is, there is a combination keyword Fields in determine non keyword The situation of .

Because it doesn't fit 2NF, There will be the following problems in this course selection relationship table ： (1) data redundancy ： The same course is taught by n Students take .” credits ” Just repeat n-1 Time ; The same student took it m Courses , Name and age are repeated m-1 Time . (2) Update exception ： If the credits of a course are adjusted . Of all rows in the data table ” credits ” All values need to be updated . Otherwise, there will be different credits for the same course . (3) Insertion exception ： If you want to open a new course , No one has taken it yet .

such , Because there is not yet ” Student number ”keyword. Course names and credits cannot be recorded in the database . (4) Delete exception ： If a group of students have completed the elective course , These records should be deleted from the database table . But , At the same time , Course name and credit information have also been deleted .

Obviously . This can also cause insertion exceptions .

Make a list of course selection SelectCourse Change to, for example, the following three tables ： Student ：Student( Student number , full name , Age ). Course ：Course( Course name , credits ); Course selection relationship ：SelectCourse( Student number , Course name , achievement ).

This kind of database table conforms to the second normal form . Eliminates data redundancy 、 Update exception 、 Insert and delete exceptions . in addition , All orders keyword All database tables conform to the second normal form , Since there can be no combination keyword.

Third normal form （3NF）： On the basis of the second paradigm , The data table assumes that there is no non keyword Segment for any candidate keyword The transfer function dependency of segment conforms to the third normal form .

So called transfer function dependency , It refers to the assumption of existence ”A → B → C” The decisive relationship of , be C The transfer function depends on A. therefore . Database tables that meet the third paradigm should not exist, such as the following dependencies ： keyword paragraph → Not keyword paragraph x → Not keyword paragraph y

Suppose the student relationship table is Student( Student number , full name , Age , My college , College location , College phone ).keyword For single keyword” Student number ”. Due to the existence of, for example, the following decision relationship ： ( Student number ) → ( full name , Age , My college , College location , College phone )

This database is consistent with 2NF Of , But it doesn't meet 3NF. Due to the existence of, for example, the following decision relationship ： ( Student number ) → ( My college ) → ( College location , College phone ) That is, there is non keyword paragraph ” College location ”、” College phone ” Yes keyword paragraph ” Student number ” The transfer function depends on . It also has data redundancy 、 Update exception 、 Insert exception and delete exception , Readers can analyze and know .

Divide the student relationship table into, for example, the following two tables ： Student ：( Student number , full name , Age , My college ); college ：( college , place , Telephone ).

This database table conforms to the third paradigm , Eliminates data redundancy 、 Update exception 、 Insert and delete exceptions .

Boyce - The KOD paradigm （BCNF）： On the basis of the third paradigm . It is assumed in the database table that there are no fields for any candidate keyword The transfer function dependency of segment conforms to the third normal form .

If the warehouse management relation table is StorehouseManage( Warehouse ID, Store things ID, Administrators ID, Number ), And there is an administrator who only works in a warehouse ; A warehouse can store many items . There are, for example, the following decision relationships in this database table ： ( Warehouse ID, Store things ID) →( Administrators ID, Number ) ( Administrators ID, Store things ID) → ( Warehouse ID, Number ) therefore .( Warehouse ID, Store things ID) and ( Administrators ID, Store things ID) All are StorehouseManage A candidate for keyword, The only non in the table keyword Segments are numbers , It's in line with the third paradigm . But , Because there is, for example, the following decisive relationship ： ( Warehouse ID) → ( Administrators ID) ( Administrators ID) → ( Warehouse ID) There is keyword Paragraph decision keyword Paragraph , So it's not in line with BCNF normal form .

It will show the following exceptions ： (1) Delete exception ： When the warehouse is empty . All ” Store things ID” and ” Number ” At the same time that the information is deleted ,” Warehouse ID” and ” Administrators ID” The information has also been deleted .

(2) Insertion exception ： When the warehouse doesn't store anything , Unable to assign administrator to warehouse .

(3) Update exception ： Suppose the warehouse has changed its administrator . Then administrators of all rows in the table ID All have to be changed .

Decompose the warehouse management relation table into two relation tables ： Warehouse management ：StorehouseManage( Warehouse ID, Administrators ID). Warehouse ：Storehouse( Warehouse ID, Store things ID, Number ).

This database table is consistent with BCNF Paradigmatic . Delete exception eliminated 、 Insert exception and update exception .

Paradigm application Let's work out the database of a forum step by step , For example, the following information ： （1） user ：username,email, Home page , Telephone . Contact address （2） post ： Post title . Post content . Reply to the title , Reply content

For the first time, we designed the database to exist only tables ： username email Home page Telephone Contact address Post title Post content Reply to the title Reply content This database table conforms to the first paradigm . But there is no group of candidates keyword Can determine the entire row of the database table , Unique keyword paragraph username Nor can it completely determine the entire tuple . We need to add ” Post ID”、” reply ID” Field , Change the table to ： username email Home page Telephone Contact address Post ID Post title Post content reply ID Reply to the title Reply content In this way, the keyword(username, Post ID. reply ID) Can decide the whole line ： (username, Post ID, reply ID) → (email, Home page , Telephone , Contact address , Post title , Post content , Reply to the title , Reply content ) But , This design does not conform to the second paradigm , Due to the existence of, for example, the following decision relationship ： (username) → (email, Home page , Telephone , Contact address ) ( Post ID) → ( Post title , Post content ) ( reply ID) → ( Reply to the title , Reply content ) It's not keyword Segment partial functions depend on candidates keyword paragraph , clear as daylight , This design will lead to a lot of data redundancy and abnormal operation .

We decompose the database table into （ Underlined ones are keyword）： （1） User information ：username,email. Home page , Telephone , Contact address （2） Post information ： Post ID, title , Content （3） Reply message ： reply ID. title . Content （4） Post ：username, Post ID （5） reply ： Post ID. reply ID

This design is to meet the requirements of article 1、2、3 Paradigms and BCNF The paradigm requires , But is this design the best ？ not always .

Observation can be seen , The first 4 term ” Post ” Medium ”username” and ” Post ID” Between 1：N The relationship between , So we can put ” Post ” Merge into section 2 Term ” Post information ” in . The first 5 term ” reply ” Medium ” Post ID” and ” reply ID” In between, too 1：N The relationship between , So we can put ” reply ” Merge into section 3 Term ” Reply message ” in . This can reduce data redundancy to a certain extent . The new design is ： （1） User information ：username.email, Home page . Telephone , Contact address （2） Post information ：username, Post ID, title , Content （3） Reply message ： Post ID, reply ID, title . Content

Database table 1 Obviously, it meets the requirements of all paradigms ;

Database table 2 There is no such thing as keyword“ title ”、“ Content ” Yes keyword paragraph “ Post ID” Part of the functional dependency of . That is, it does not meet the requirements of the second paradigm , However, this design will not lead to data redundancy and abnormal operation ;

Database table 3 There are also non keyword paragraph ” title ”、” Content ” Yes keyword paragraph ” reply ID” Part of the functional dependency of , Nor does it meet the requirements of the second paradigm , But with database tables 2 be similar , This design will not lead to data redundancy and abnormal operation .

From this we can see , It is not necessary to forcibly meet the requirements of the paradigm , about 1：N Relationship , When 1 Merge one side of into N After the other side ,N There is no longer the second paradigm . But this design is better ！

about M：N The relationship between , Can't be M Side or N Merge one side into another , This will lead to non-compliance with the paradigm , At the same time, it leads to abnormal operation and data redundancy .

about 1：1 The relationship between . We can put the left 1 Or the one on the right 1 Merge to the other side . Design leads to non-compliance with paradigm requirements . However, it will not lead to abnormal operation and data redundancy .

Conclusion

The database design that meets the requirements of paradigm is structured clearly , At the same time, data redundancy and abnormal operation can be avoided .

This does not mean that a design that does not meet the requirements of the paradigm must be wrong . Exists in the database table 1：1 or 1：N In such a special case , It is reasonable that the merger does not meet the requirements of the paradigm .

When we design the database , Always consider the requirements of the paradigm .

Copyright notice ： This article is an original blog article . Blog , Without consent , Shall not be reproduced .

Publisher ： Full stack programmer stack length , Reprint please indicate the source ：https://javaforall.cn/117144.html Link to the original text ：https://javaforall.cn