Database Technology - Functional Dependency, Keys and Constraints, Normal Form

1. Functional dependencies

·Given an x, a Y can be uniquely determined, it is said that x determines Y, or Y depends on x, for example, Y=X*X function.
Functional dependency can be extended to the following two rules:
Partial functional dependency: A can determine C, (A, B) can also determine C, and a part of (A, B) (ie A) can determine C, called partial Functional dependencies.
·Transfer function dependence: when A and B are not equivalent, A can determine B, B can determine c, then A can determine c, which is a transfer function dependency; if A and B are equivalent, there is no transfer, and it can be directly OKC.
insert image description here

2. Keys and constraints

Superkey: A combination of attributes that can uniquely identify this table.
Candidate key: Remove redundant attributes from the superkey, and the remaining attributes are candidate keys. Primary key: Any candidate key can be used as the primary key.
Foreign keys: Primary keys in other tables.
Main attribute: The attribute in the candidate key is the main attribute, and other attributes are non-main attributes.

Entity integrity constraints: primary key constraints, primary key values ​​cannot be empty or repeated.
·Referential integrity constraint: that is, foreign key constraint, the foreign key must be the value of the primary key that already exists in other tables, or be empty. User-defined integrity constraints: custom expression constraints, such as setting the value of the age attribute must be between o and 150.

3. Paradigm

First normal form: 1NF

Each component in a relation must be an inseparable data item. In layman's terms, the first normal form is that small tables are not allowed in the table. For example, the following employee table is not in first normal form:
insert image description here

Second Normal Form: 2NF

insert image description here

·If the relation R belongs to 1NF, and each non-prime attribute is fully functionally dependent on any candidate key, then R belongs to 2NF.
·In layman's terms, 2NF means that on the basis of 1NF, each non-primary attribute in the table will not depend on a column in the composite primary key.
·According to the definition, the above student table does not satisfy 2NF, because the student number cannot completely determine the course number and grade (each student can choose multiple courses).

·Decompose the student table into:
·Student (student number, student name, department number, department name, department head) ·Course selection (student number, course number, grade).
· Each table belongs to 2NF.

Third normal form: 3NF

·On ​​the basis of satisfying 1NF, there is no transitive dependence of non-key attributes on codes in the table.
·Continuing the above example, the student relationship model does not belong to 3NF, because students cannot directly determine the department head and department name, from student number -> department number, then department number -> department head, department number -> department name, Therefore, there is a transitive dependence of the non-main attribute on the main attribute.
The student table is further decomposed into:
student student (student number, student name, department number)
department (department number, department name, department head)
course selection (student number , course number, grade)
· Each table belongs to 3NF.

BC paradigm: BCNF

·The so-called BCNF refers to the further elimination of partial functional dependence and transitive dependence of the main attribute on the code on the basis of the third normal form.
In layman's terms, in each case, each dependent left determinant must contain candidate keys, as follows: In the
insert image description here
above figure, there are two cases of candidate keys: composite keys (S, T) or ( S, J), and the dependency set is {SJ-T, T-J}. It can be seen that the three attributes of STJ are all primary attributes, so they reach 3NF (no non-primary attributes). However, the second case, namely (S When ,J) is a candidate key, for the dependency T->J, T is not a candidate key in this case, that is, the determinant of TJ does not contain any candidate code, so the above figure is not BCNF.
·It is also very simple to convert the above relational model into BCNF, just change the dependency T->s to TS->, so that the left determinant includes S, one of the candidate keys.

Guess you like

Origin blog.csdn.net/MARKDD915/article/details/129109966