First paradigm, second paradigm, and third paradigm

First paradigm

Partial dependency between non-primary attributes and codes R (A, B, C) AB is code C non-primary attributes B --> c B determines that C depends on B

First paradigm

Definition: if the value ranges of all attributes in relational R are pure domains, then relational mode r is the first paradigm.

So there are some characteristics that conform to the first model.

1) Primary keywords

2) The primary key cannot be blank,

3) Primary keys cannot be repeated,

4) The field cannot be further divided.

For example:

Studyno | Name | sex | contact

20040901 John male Email: kkkk@ee.net, phone: 222456

20040901 Mary famale Email: kkk@fff.net Phone: 123455

The preceding table does not match. The first paradigm is primary key duplication (in reality, duplicate databases are not allowed), and the contact field can be further divided.

So which of the following statements is correct?

Studyno | Name | sex | email | phone

20040901 John male kkkk@ee.net 222456

20040902 Mary famale kkk@fff.net 123455

 

Second paradigm

The existence of non-master Attribute-to-code transmission dependency R (A, B, C) A is code A --> B, B --> C

Definition: If the relational mode r is the first paradigm, and each non-primary attribute in the link does not depend on the primary key, r is the second paradigm.

So the main task of the Second paradigm is

Eliminate some function dependencies on the premise that the first paradigm is met.

Studyno | Name | sex | email | phone | classno | classaddress

01 John male kkkk@ee.net 222456 200401 A Floor 2

01 Mary famale kkk@fff.net 123455 200402 a floor 3

This table is fully satisfied with the first paradigm,

The primary key consists of studyno and classno to locate the specified row.

However, the classaddress part depends on the keyword (classno-> classaddress ),

So we need to change it to two tables.

Table 1

Studyno | Name | sex | email | phone | classno

01 John male kkkk@ee.net 222456 200401

01 Mary famale kkk@fff.net 123455 200402

Table 2

Classno | classaddress

200401 Building A 2

200402 Building A 3

Third paradigm

The non-master attribute does not depend on the Code's transmission and partial dependency,
Studyno | Name | sex | email | bounslevel | bouns

20040901 John male kkkk@ee.net excellent $1000

20040902 Mary famale kkk@fff.net good $600

This fully satisfies the second paradigm, but bounslevel and bouns have transmission dependencies.

Changed:

Studyno | Name | sex | email | bouunsno

20040901 John male kkkk@ee.net 1

20040902 Mary famale kkk@fff.net 2

Bounsno | bounslevel | bouns

1 excellent $1000

2 Good $600

Here, I prefer to use bounsno as the primary key,

For two reasons

1) do not use characters as the primary key. Some people may say: what if my grade is replaced by a numerical value at the beginning?

2) But if the level name is changed, it is not 1, 2, 3 or excellent or good, so that it can be easily changed. Therefore, I generally use a field unrelated to the business as a keyword.

 

Generally, data redundancy can be avoided when the first three paradigms are met.