Three paradigms of database design-clear concepts and popular understanding

First, the database noun

Before understanding the three paradigms, we first clarify the concept of some nouns in the database to facilitate our understanding later.

  • Entity-a collection of things of a certain type, the individual of each type of data object is called an entity
  • Attributes-a characteristic of an entity, also called a field, a column in a database table
  • Tuple-a collection of all attributes of an entity, a row of information in a database table
  • Relations-collections of tuples of entities, tables in databases
  • Code-A code is an attribute that can uniquely identify an entity. He is the nature of the entire entity set, not the nature of a single entity. It includes super code, candidate code, main code.
  • Supercode-a collection of one or more attributes that can uniquely identify an entity, that is, can find a unique list of information in the database
  • Candidate code-one of the super codes. The candidate code is the smallest supercode, and any true subset of the candidate code cannot become a supercode
  • Main code-also becomes the main attribute, the primary key. The candidate code selected by the database designer to distinguish different entities in the same entity set

The following figure explains these concepts as an example
Insert picture description here

  • Students are entities
  • The student's student ID, name, etc. become attributes (fields). The attributes in the database table include attribute name, attribute type, attribute value, and value type. For example 姓名, the attribute of the first piece of data , whose attribute name is name, attribute type is non-primary attribute, attribute value is Xu San, and value type is varchar. The detailed description here is like telling everyone that the attribute does not only refer to 姓名these two words, but contains more content.
  • The entire table is a relationship, each row of data in the table is a tuple
  • Supercode: {Student ID}, {ID No.}, {Student ID, ID No.}, {Student ID, Name}, {Student ID, Faculty}, {Student ID, ID No., Name, Faculty } Etc. are all supercodes, and their collections can uniquely identify a piece of data, but there may be some redundant information in the supercode, such as the
    name and department in {student number, ID number, name, department} All are redundant information, even one of the student number and ID number can be regarded as redundant information
  • Candidate code: The smallest supercode, that is, the redundant information is removed, and its true subset is not a supercode, such as {Student ID}, {Faculty}. Assuming that the name of each class student is unique, {department, class, name} can also constitute a candidate code, his real subset {college}, {class}, {name}, {college, name}, {class , Name}, {college, class} can not identify a piece of data.
  • Master code: here we can choose either {student number}, {ID card number} as the master code

Two, three paradigms

First normal form

When all the attributes of the relational model R cannot be decomposed into more basic data units, it is said that R satisfies the first normal form, abbreviated as 1NF.

Assuming that the student list is as follows, the first paradigm is not satisfied, and the information of departments and classes can be further divided
Insert picture description here

简单理解:属性不可再分
Second normal form

If the relational model R satisfies the first normal form, and all non-principal attributes of R completely depend on each candidate key attribute of R, it is said that R satisfies the second normal form, which is abbreviated as 2NF.

Assuming that there is a grade table as follows, the second normal form is not satisfied
Insert picture description here
. The main code of the table is {student number, subject}, and the main code can uniquely identify a piece of data, but the name in the piece of data is found by relying on the student number. It has nothing to do with the subject attribute, that is, the name attribute does not completely depend on each attribute of the candidate code, and does not satisfy the second normal form. Modify to two tables
Insert picture description here

简单理解:所有非主属性只能通过主键的属性集合查询出,不能通过主键的真子集属性(一个或多个不完全包含于主键的属性)查询出

Third normal form

Let R be a relational model that satisfies the conditions of the first normal form, and X is any set of attributes of R. If X does not pass any candidate keyword that depends on R, it is said that R satisfies the third normal form, which is abbreviated as 3NF.

Assuming that there is a student table as follows, the third normal form
Insert picture description here
is not satisfied. Set the primary key of this table to {student number}, all attributes are completely dependent on the student number, so the second normal form is satisfied. But the college says that the address can be found by the department, that is, the address attribute of the college directly depends on the department, and the transfer depends on the student number.

Change it into two tables

Insert picture description here
However, considering the name attribute, I think he can be regarded as directly dependent on the primary key student ID, can also be seen as directly dependent on the ID number, transfer depends on the student ID, at this time it does not meet the third normal form.

However, the database design allows partial redundancy, and generally requires that the design at least reach the second normal form, without modification.

简单理解:所有非主属性只能通过主键查出,不能通过非主属性查出

3. Summary

  • The first normal form requires that fields must be atomic.
    -That is, the attributes are inseparable.
  • The second paradigm requires that non-primary attributes cannot partially depend on code.
    ——That is, all non-primary attributes can only be queried through the attribute set of the primary attribute, and cannot be queried through the true subset attribute of the primary attribute (one or more attributes that are not completely included in the primary key)
  • The third paradigm requires that non-principal attributes are neither partly dependent on code nor transitive dependent on code.
    ——That is, all non-primary attributes can only be detected through the primary attribute, not through the non-primary attribute
Published 35 original articles · praised 7 · 40,000+ views

Guess you like

Origin blog.csdn.net/weixin_44804750/article/details/105121306