tailieunhanh - Lecture Database management systems - Chapter 6: Functional dependencies

Chapter 6 presents the following content: Functional dependencies (FD) - definition, trivial FDs, functional dependencies and keys, Superkeys and candidate keys, reasoning about functional dependencies, armstrong’s axioms, additional rules based on armstrong’s axioms, closure of a set of functional dependencies,. | Functional Dependencies Functional Dependencies (FD) - Definition Let R be a relation scheme and X, Y be sets of attributes in R. A functional dependency from X to Y exists if and only if: For every instance of |R| of R, if two tuples in |R| agree on the values of the attributes in X, then they agree on the values of the attributes in Y We write X Y and say that X determines Y Example on Student (sid, name, supervisor_id, specialization): {supervisor_id} {specialization} means If two student records have the same supervisor (., Dimitris), then their specialization (., Databases) must be the same On the other hand, if the supervisors of 2 students are different, we do not care about their specializations (they may be the same or different). Sometimes, I omit the brackets for simplicity: supervisor_id specialization 2 Trivial FDs A functional dependency X Y is trivial if Y is a subset of X {name, supervisor_id} {name} If two records have the same values on both the name and supervisor_id attributes, then they obviously have the same name. Trivial dependencies hold for all relation instances A functional dependency X Y is non-trivial if Y X = {supervisor_id} {specialization} Non-trivial FDs are given implicitly in the form of constraints when designing a database. For instance, the specialization of a students must be the same as that of the supervisor. They constrain the set of legal relation instances. For instance, if I try to insert two students under the same supervisor with different specializations, the insertion will be rejected by the DBMS 3 Functional Dependencies and Keys A FD is a generalization of the notion of a key. For Student (sid, name, supervisor_id, specialization), we write: {sid} {name, supervisor_id, specialization} The sid determines all attributes (., the entire record) If two tuples in the relation student have the same sid, then they must have the same values on all .