1. 1 Normalization

2. 2 Normal Forms v If a relation is in a certain normal form (BCNF, 3NF etc.), it is known that certain kinds of redundancies are avoided/minimized. This can be used to help us decide whether decomposing the relation will help. v Role of FDs in detecting redundancy: –Consider a relation R with 3 attributes, ABC. u Given A  BC: There is no redundancy here. u Add B C: Several tuples could have the same B value, and if so, they’ll all have the same C value!

3. 3 First Normal Form (1NF) v 1NF: Each field is an atomic (scalar) value v All relations are in first normal form (1NF) v Some definitions we’ll need to understand the other normal forms: –A prime attribute is an attribute that is an element of one or more CKs for a relation. –A trivial FD is one in which the RHS is contained in the LHS (e.g., AB  A or B  B). We will ignore such FDs in this lecture.

4. 4 Second Normal Form (2NF) v Relation R is in 2NF if, for all FDs X  A –A is prime, or –X is not a proper subset of any CK. v Example : R = (part, wh, qty, wh-addr) –FDs: {part, wh}  qty wh  wh-addr –Is R in 2NF?

5. 5 2NF (continued) v No, it’s in 1NF only. Only candidate key is {part, wh}, and second FD violates 2NF. v So what? v We’re storing wh-addr once for each part stored at that warehouse. v Solution: R1 ( ) and R2 ( ) v Are R1, R2 in 2NF?

6. 6 Third Normal Form (3NF) v Relation R is in 3NF if, for all FDs X A –X is a superkey for R, or –A is prime v Example: ED = (enum, ename, sal, dnum, dname, mgr) –FDs: enum  ename, sal, dnum dnum  dname, mgr –Is ED in 2NF?3NF? v The problem: stored for each employee in a department

7. 7 3NF (continued) v One solution: –Emp (enum, ename, sal, mgr) –Dept (dnum, dname, mgr) –Removes the redundancy –A problem remains: v This is an example of a lossy-join decomposition, which is avoidable in 3NF. v Use Emp1 (enum, ename, sal, ) instead of Emp.

8. 8 Boyce-Codd Normal Form (BCNF) v Relation R is in BCNF if, for all FDs X A –X is a superkey v Example: R = (branch, cust, banker) –FDs: banker  branch cust, branch  banker –Is R in 3NF?BCNF? v Problems: –Bankers must have at least one customer –Branch stored redundantly for each of a banker’s customers

9. 9 BCNF (continued) v Decomposition: R1 (banker, branch) and R2 (cust, banker) –avoids redundancy and other problems –A problem remains: v In this case, no dependency-preserving decomposition into BCNF is possible.

10. 10 Problems with Decompositions v There are three potential problems to consider: ¶ Some queries become more expensive. u e.g., find employee and department names · Given instances of the decomposed relations, we may not be able to reconstruct the corresponding instance of the original relation! u First 3NF decomposition attempt ¸ Checking some dependencies may require joining the instances of the decomposed relations. u BCNF decomposition example v Tradeoff : Must consider these issues vs. redundancy.

11. 11 Summary of Schema Refinement v If a relation is in BCNF, it is free of redundancies that can be detected using FDs. v If a relation is not in BCNF, we can try to decompose it into a collection of BCNF relations: –Lossless-join, dependency preserving decomposition into BCNF is not always possible –Lossless-join decomposition into BCNF is always possible –Lossless-join, dependency preserving decomposition into 3NF is always possible –Decompositions should be carried out and/or re-examined while keeping performance requirements in mind. –Various decompositions of a single schema are possible.