functional dependencies
In databases, functional dependency refers to a relationship between two attributes in which the value of one attribute can uniquely determine the value of the other attribute. In relational databases, functional dependency means that the value of one or more attributes can uniquely determine the value of other attributes.
For example, in a student table, a student's student ID can uniquely determine the student's name, gender, age, and other information, so it can be said that "the student ID determines attributes such as name, gender, and age."
In relational databases, functional dependencies are fundamental to database design and normalization, helping to ensure data integrity and consistency. For example, the value of one attribute depends on the value of other attributes, and if these dependencies are not defined and managed properly, it can lead to redundant, inconsistent, and incomplete data.
full functional dependency
The attribute set X is completely dependent on Y, which means that in R, if any proper superset of X does not satisfy the functional dependency Y, then Y is said to be completely dependent on X. To put it simply, if any attribute in X is removed, Y cannot be uniquely determined.
For example, if the Academic Affairs Office wants to determine the grades of a student in a certain course, it needs to know the student's student number and course name, that is,
(X, Y) -> Z, both of which are indispensable. This means that Z is completely dependent on the set (X,Y).
partial functional dependency
The attribute set X is partially dependent on Y, which means that in R, there is a proper subset X' of X such that X' ->
Y, that is, Y depends on a proper subset of X, not X itself. To put it simply, some attributes in X are removed, and Y can still be uniquely determined.
For example, if the Academic Affairs Office wants to determine the average grade of a student, it does not need the course name, only the student number. Then U is partially dependent on the set (X,Y).
transitive functional dependencies
The attribute set X is transitively dependent on Y, which means that in R, there is Z such that X -> Z, and Z -> Y, that is, Y depends on an indirect subset of X. Simply put, X indirectly determines Y.
candidate key
候选键是关系模型中的一组属性，可以唯一地标识关系模型中的每一个元组。
候选键的属性个数最小化，也就是说，不能存在多余的属性。
候选键的属性不能是空值（NULL）。
在一个关系模型中，可能会存在多个候选键，这些候选键中的任何一个都可以被选作主键。
候选键是在满足第一范式的基础上进行的规范化处理。
Note: In functional dependencies, attributes with an in-degree of 0 must be included in the candidate key set.
Among them, the attributes that constitute the candidate key are called primary attributes , and other attributes are called non-primary attributes
Three paradigms of database
1NF
first normal form (1NF): Mandatory attributes are atomic
The first normal form requires that all attributes in a relationship must be atomic, that is, attributes cannot be decomposed. A relationship is a table, and an attribute is a column in the table. If an attribute contains multiple values, it will lead to problems such as data redundancy and inconsistency, which will affect the performance of the database.
For example, if a table contains three attributes of "name, gender, and age", if the first and last names in the "name" column are stored separately, it does not conform to the first normal form.
The 2NF
second normal form requires that the attributes in the relational table must be completely dependent on the primary key, that is, any non-primary key attribute must depend on all primary keys rather than part of the primary key. If an attribute only depends on part of the primary key, data redundancy and update exceptions will occur.
For example, if a table contains attributes such as "order number, product number, product name, product unit price, order quantity, total price", if you separate "product name, product unit price" into another table, redundancy can be eliminated .
3NF
Third Normal Form requires that non-primary key attributes in relational tables do not depend on other non-primary key attributes. If an attribute depends on another non-primary key attribute, it will cause data redundancy and update exceptions.
For example, if a table contains attributes such as "student number, course number, course name, teacher name, teacher phone", if "teacher name, teacher phone" is separated into another table, redundancy can be eliminated.