Functional Dependency

1. Functional Dependency CS157a Sec. 2 Koichiro Hongo

2. What is Functional Dependency? • A functional dependency is a constraint between two sets of attributes in a relation from a database. • An attribute or set of attributes X is said to functionally determine another attribute Y (written X  Y) if and only if each X value is associated with at most one Y value. Customarily we call X determinant set and Y a dependent set. • So if we are given the value of X we can determine the value of Y.

3. Why is Fanctional Dependency Important? • The determination of functional dependencies is an important part of designing databases in the relational model, and in database normalization and denormalization. • The functional dependencies, along with the attribute domains, are selected so as to generate constraints that would exclude as much data inappropriate to the user domain from the system as possible.

4. Functional Dependency Inference Rules Reflexivity: If B is a subset of A then A functionally determines B For example: {name, location}  {name}

5. Functional Dependency Inference Rules(cont.) Augmentation: If B is a subset of A and C functionally determines D then A and C functionally determine B and D For example: {name, location} and {birthdate, time}  {name} and {age} (as {name} is a subset of {name, location} and {birthdate, time} functionally determines {age})

6. Functional Dependency Inference Rules(cont.) Transitivity: If A functionally determines B and B functionally determines C then A functionally determines C For example: {name, location}  {initials} (as {name, location} functionally determines {name} and {name} functionally determines {initials})

7. Functional Dependency Inference Rules(cont.) Pseudo transitivity: If A functionally determines B and B and C functionally determine D then A and C functionally determine D

8. Functional Dependency Inference Rules(cont.) Union: If A functionally determines B and A functionally determines C then A functionally determines B and C For example: {name, location, birthdate, time}  {initials, age} (as {name, location, birthdate, time}  {initials} and {name, location, birthdate, time}  {age})

9. Functional Dependency Inference Rules(cont.) Decomposition: If A functionally determines B and C then A functionally determines B and A functionally determines C For example: {name, location, birthdate, time}  {initials, age} implies that {name, location, birthdate, time}  {initials} and {name, location, birthdate, time}  {age}

10. Trivial Functional Dependencies Some functional dependencies are said to be trivial because they are satisfied by all relation. For example: A  A X  Y if Y is a subset of X

11. Keys and Functional Dependencies • Keys and, more generally, functional dependencies, are constraints on the database that require relations to satisfy certain properties. Relations that satisfy all such constraints are legal relations.

12. What is Superkey? (review) A superkey is defined in the relational model as a set of attributes of a relation for which it holds that in all instances of the relation there are no two distinct tuples that have the same values for the attributes in this set. Equivalently a superkey can also be defined as those sets of attributes of a relation upon which all attributes of the relation are functionally dependent.

13. Keys and Functional Dependencies(cont.) Functional dependencies allow us to express constraints that we cannot express with superkeys. Let's consider the schema of the example in the textbook(p.265) Figure 7.2

14. Figure 7.2 Partial list of tuples in relations loan, borrower, and bor_loan . . . 23-652 15-202 23-521 . . . . . . L-100 L-100 L-100 . . . . . . L-100 . . . . . . 10000 . . . loan borrower . . . 23-652 15-202 23-521 . . . . . . L-100 L-100 L-100 . . . . . . 10000 10000 10000 . . . bor_loan

15. Keys and Functional Dependencies(cont.) Figure 7.2, we consider the schema bor_loan = (customer_id, loan_number, amount) in which the functional dependency loan_numberamount holds because for each loan (identified by loan_number) there is a unique amount. We denote the fact that the pair of attributes(customer_id, loan_amount) forms a superkey for bor_loan by writing: customer_id, loan_numbercustomer_id, loan_number, amount or, equivalently, customer_id, loan_numberbor_loan

16. Keys and Functional Dependencies(cont.) We shall use functional dependencies in two ways: 1. To test relations to see whether they are legal under a given set of functional dependencies. If a relation r is a legal under a set F of functional dependencies, we say that rsatisfiesF. 2. To specify constraints on the set of legal relations. We shall thus concern ourselves with only those relations that satisfy a given set of functional dependencies. If we wish to constrain ourselves to relations on schema R that satisfy a set F of functional dependencies, we say that Fholds on R.

17. Database Normalization • Database normalization relates to the level of redundancy in a relational database's structure. The key idea is to reduce the chance of having multiple different versions of the same data, like an address, by storing all potentially duplicated data in different tables and linking to them instead of using a copy. Then updating the address in one place will instantly change all the places where the address is used. • Well-normalized databases have a schema that reflects the true dependencies between tracked quantities. This means that updates can be quickly performed with little risk of data becoming inconsistent. • Database normalization relates to the level of redundancy in a relational database's structure. The key idea is to reduce the chance of having multiple different versions of the same data, like an address, by storing all potentially duplicated data in different tables and linking to them instead of using a copy. Then updating the address in one place will instantly change all the places where the address is used. • Well-normalized databases have a schema that reflects the true dependencies between tracked quantities. This means that updates can be quickly performed with little risk of data becoming inconsistent.

18. History of Database Normalization • British computer scientist who made seminal contributions to the theory of relational databases. • While working for IBM, he created the relational model for database management. • Edgar F. Codd first proposed the process of normalization and what came to be known as the 1st normal form in his paper A Relational Model of Data for Large Shared Data Banks Communications of the ACM, Vol. 13, No. 6, June 1970, pp. 377-387 Edgar F. Codd

19. Normal Forms Normal Forms • In the relational model, formal methods exist for quantifying "how normalized" a database is. These classifications are called normal forms, and there are algorithms for converting a given database between them. • Edgar F. Codd originally established three normal forms: 1NF, 2NF and 3NF. There are now others that are generally accepted, but 3NF is widely considered to be sufficient for many practical applications. Most tables when reaching 3NF are also in BCNF.

20. 1NF(First Normal Form) 1NF(First Normal Form) In the relational model, we formalize this idea that attributes do not have any substructure. A domain is atomic if elements of the domain are considered to be indivisible units. We say that a relation schema R is in first normal form if the domains of all attributes of R are atomic. In the relational model, we formalize this idea that attributes do not have any substructure. A domain is atomic if elements of the domain are considered to be indivisible units. We say that a relation schema R is in first normal form if the domains of all attributes of R are atomic. In other words, a relation schema R is in 1NF if there are no muntivalued attributes.

21. 1NF(First Normal Form) (cont.) To understand first normal form (1NF), consider these two examples of things you might know: "What is your favorite color?" "What food will you not eat?" A difference between these two examples is that, you can have only one favorite color; but, there is very little limitation on the number of foods you might not eat. Data that has a single value such as "person's favorite color" is inherently in first normal form. Storing such data has not much changed since Codd wrote and needs no further explanation here. Data that has multiple values must be stored differently.

22. 2NF(Second Normal Form) Second normal form (2NF) prescribes full functional dependancy on the primary key. It most commonly applies to tables that have composite primary keys, where two or more attributes comprise the primary key. It requires that there are no non-trivial functional dependencies of a non-key attribute on a part (subset) of a candidate key. A table is said to be in the 2NF if and only if it is in the 1NF and every non-key attribute is irreducibly dependent on the primary key.

23. 2NF(Second Normal Form) (cont.) How about this example? Example: Machine_parts(part_number, supplier_name, price, supplier_address) In this case, price is fully dependent on the primary key(different suppliers may charge different price on the same part). However, supplier_address is partially dependent because it only depends on the supplier_name. Therefore, this table is not in 2NF.

24. 3NF(Third Normal Form) Third normal form (3NF) requires that there are no non-trivial functional dependencies of non-key attributes on something other than a superset of a candidate key. A table is in 3NF if it is in 2NF, and none of the non-primary key attributes is a fact about any other non-primary key attribute. In summary, all non-key attributes are mutually independent(i.e. there should not be transitive dependencies).

25. 3NF(Third Normal Form) (cont.) How about this example? Example: Machine_parts(part_number, supplier_name, supplier_address) In this case, supplier_address is dependent on supplier_name. Therefore, there is a transitive dependency in the table. It means that it is not in 3NF.

26. BCNF (Boyce-Codd Normal Form) Boyce-Codd normal form (or BCNF) requires that there are no non-trivial functional dependencies of attributes on something else than a superset of a candidate key. At this stage, all attributes are dependent on a key, a whole key and nothing but a key (excluding trivial dependencies, like AA). A table is said to be in the BCNF if and only if it is in the 3NF and every non-trivial, left-irreducible functional dependency has a candidate key as its determinant. In more informal terms, a table is in BCNF if it is in 3NF and the only determinants are the candidate keys.

27. Work Cited: Silberschatz, Avi. Hank Korth, and S. Sudarshan. DATABASE SYSTEM CONCEPTS FIFTH EDITION. New York: The McGraw-Hill Companies, Inc., 205. 263-309. Wikipedia: <http://en.wikipedia.org/wiki/Functional_dependency> <http://en.wikipedia.org/wiki/Database_normalization>