1. Lecture9:Functional Dependencies and Normalization for Relational Databases Prepared by L. Nouf Almujally Ref. Chapter14 - 15 Lecture9 1

2. How to produce a good relation schema? STEPS: 1.Start with a set of relation. 2.Define the functional dependencies for the relation to specify the PK. 3.Transform relations to normal form. 2 Lecture9

3. Functional Dependencies Describes the relationship between attributes in a relation. If A and B are attributes of relation R, B is functionally dependent on A, denoted by A B, if each value of A is associated with exactly one value of B. B may have several values of A. Determinant Dependent 3 AB B is functionally dependent on A Lecture9 Normalization

4. Functional Dependencies 4 Example StaffNoposition Position is functionally dependent on Staffno positionStaffNo StaffNo is NOT functionally dependent on position SL21 Manager Manager SL21 SG5 Lecture9 Normalization

5. Examples of FD constraints Social security number determines employee name SSN -> ENAME Project number determines project name and location PNUMBER -> {PNAME, PLOCATION} Employee ssn and project number determines the hours per week that the employee works on the project {SSN, PNUMBER} -> HOURS Lecture9 5 Normalization

6. Identifying the PK Purpose of functional dependency, specify the set of integrity constraints that must hold on a relation. The determinant attribute(s) are candidate of the relation, if: 1:1 relationship between determinant & dependent. No subset of determinant attribute(s) is a determinant. (nontrivial) If (A, B) C, then NOT A B, and NOT B A All attributes that are not part of the CK should be functionally dependent on the key: CK all attributes of R PK is the candidate attribute(s) with the minimal set of functional dependency. Normalization 6 Lecture9

7. Identifying the PK If a relation schema has more than one key, each is called a candidate key. One of the candidate keys is arbitrarily designated to be the primary key, and the others are called secondary keys. A Prime attribute is an attribute that does occur in some candidate key A Nonprime attribute is an attribute that does not occur in any candidate key. Example : Employee Address would be a non-prime attribute in the "Employees" table Lecture9 7 Normalization

8. The Purpose of Normalization Normalization Is the process of organizing the fields and tables of a relational database to minimize redundancy and dependency. Normalization usually involves dividing large tables into smaller (and less redundant) tables and defining relationships between them Is a bottom-up approach to database design that begins by examining the relationships between attributes. It is performed as a series of tests on a relation to determine whether it satisfies or violates the requirements of a given normal form. Purpose: - Guarantees no redundancy due to FDs - Guarantees no update anomalies Normal Forms: First Normal Form (1NF) Second Normal Form (2NF) Third Normal Form (3NF) Boyce-Codd Normal Form (BCNF) 8 Lecture9 Normalization

9. Normal Forms Defined Informally 1 st normal form All attributes depend on the key 2 nd normal form All attributes depend on the whole key 3 rd normal form All attributes depend on nothing but the key Lecture9 9 Normalization

10. First Normal Form (1NF) 10 Unnormalized form (UNF): A relation that contains one or more repeating groups. First normal form (1NF): A relation in which the intersection of each row and column contains one & only one value. 1NF Disallows: composite attributes multivalued attributes nested relations; attributes whose values for an individual tuple are non- atomic ( cannot be decomposed into smaller pieces by the DBMS ) Example Nested relations from a library Book title, Set of authors,Publisher, Set of keywords Where Publisher is ( pub-name,Pub-branch) Lecture9 Normalization The Books relation can be represented in IN’F

11. First Normal Form (1NF) 11 ClientNo CR76 PropertyNo PG4 Name John Key CLIENT_PROPERTY PG16 PG4 PG36 PG16 CR56 Aline Stewart Unnormalized form (UNF) Lecture9  Not in the 1NF because there are Multivalued attribute in the table (PropertyNo) Normalization

12. UNF 1NF Approach 1 Expand the key so that there will be a separate tuple in the original relation for each repeated attribute(s). Primary key becomes the combination of primary key and redundant value (multivalued attribute). 1NF relation Disadvantage: introduce redundancy in the relation. 12 ClientNo CR76 PropertyNo PG4 Name John Key CLIENT_PROPERTY PG16 PG4 PG36 PG16 CR56 Aline Stewart CR76 John Key CR56 Aline Stewart CR56 Aline Stewart Lecture9 Normalization

13. UNF 1NF Approach 2 If the maximum number of values is known for the attribute, replace repeated attribute (PropertyNo) with a number of atomic attributes (PropertyNo1, PropertyNo2, PropertyNo3). 1NF relation Disadvantage: introduce NULL values in the relation. 13 ClientNo CR76 PropertyNo1 PG4 Name John Key CLIENT_PROPERTY PG16 PG4 PG36 CR56 Aline Stewart PropertyNo2PropertyNo3 NULL PG16 Lecture9 Normalization

14. Summary : first normal form 1NF : if all attribute values are atomic: no repeating group, no composite attributes. Lecture9 14 Normalization

15. UNF (multivalued) 1NF Lecture9 15 Normalization

16. UNF (nested relations) 1NF Lecture9 16 Normalization

17. Example : First normal form -1NF The following table is not in 1NF because there are nested relations in the table DPT_NOMG_NOEMP_NOEMP_NM D1011234520000 20001 20002 Carl Sagan Mag James Larry Bird D1021345630000 30001 Jim Carter Paul Simon 17 Lecture9Normalization

18. Table in 1NF all attribute values are atomic because there are no repeating group and no composite attributes. DPT_NOMG_NOEMP_NOEMP_NM D1011234520000Carl Sagan D1011234520001Mag James D1011234520002Larry Bird D1021345630000Jim Carter D10213456 30001 Paul Simon 18 NormalizationLecture9

19. Second Normal Form Uses the concepts of FDs, primary key Definitions Prime attribute: An attribute that is member of the primary key K Full functional dependency: a FD Y -> Z where removal of any attribute from Y means the FD does not hold any more Examples: {SSN, PNUMBER} -> HOURS is a full FD since neither SSN -> HOURS nor PNUMBER -> HOURS hold {SSN, PNUMBER} -> ENAME is not a full FD (it is called a partial dependency ) since SSN -> ENAME also holds Lecture9 19 Normalization

20. Second Normal Form Second normal form (2NF) further addresses the concept of removing duplicative data A relation R is in 2NF if 1.R is 1NF, and 2.All non-prime attributes are fully dependent on the candidate keys. Which is creating relationships between these new tables and their predecessors through the use of foreign keys. A prime attribute appears in a candidate key. There is no partial dependency in 2NF. Lecture9 20 Normalization

21. Summary : Second Normal Form (2NF) 1)Meet all the requirements of the 1NF 2)Remove columns that are not fully dependent upon the primary key. 21 Lecture9 Normalization

22. Example1: 1NF 2NF Lecture9 22  Remove partial dependencies by placing the functionally dependent attributes in a new relation along with a copy of their determinants. Normalization

23. Example2: Second normal form -2NF Lecture9 23 Inventory DescriptionSupplierCostSupplier Address Inventory DescriptionSupplierCost There are two non-key fields. So, here are the questions: If I know just Description, can I find out Cost? No, because we have more than one supplier for the same product. If I know just Supplier, and I find out Cost? No, because I need to know what the Item is as well.  Therefore, Cost is fully, functionally dependent upon the ENTIRE PK (Description-Supplier) for its existence. Normalization

24. Example 2: Second normal form -2NF Lecture9 24 Supplier NameSupplier Address Inventory DescriptionSupplierCostSupplier Address If I know just Description, can I find out Supplier Address? No, because we have more than one supplier for the same product. If I know just Supplier, and I find out Supplier Address? Yes. The Address does not depend upon the description of the item.  Therefore, Supplier Address is NOT functionally dependent upon the ENTIRE PK (Description-Supplier) for its existence. Normalization

25. Inventory DescriptionSupplierCost Supplier NameSupplier Address The above relations are now in 2NF 25 Lecture9 Example 2: Second normal form -2NF Normalization

26. Third Normal Form (1) Transitive functional dependency X, Y, Z are attributes of a relation, such that: If X Y and Y Z, then Z is transitively dependent on X via Y. Provided X is NOT functionally dependent on Y or Z (nontrivial FD). non trivial dependency means X-->Y that is if Y is not proper subset of X table or relation with X then it said to be non trivial functional dependency Lecture9 26 Normalization

27. Third Normal Form (2) A relation schema R is in third normal form (3NF) if : 2NF, and 2NF, and no transitive dependencies (functional dependencies on non-primary-key attributes) no transitive dependencies (functional dependencies on non-primary-key attributes) Note: This is called transitive, because the primary key is a determinant for another attribute, which in turn is a determinant for a third Note: This is called transitive, because the primary key is a determinant for another attribute, which in turn is a determinant for a third Solution: Non-key determinant with transitive dependencies go into a new table; Solution: Non-key determinant with transitive dependencies go into a new table; non-key determinant becomes primary key in the new table,and non-key determinant becomes primary key in the new table,and stays as foreign key in the old table stays as foreign key in the old table Lecture9 27 Normalization

28. Summary : Third Normal Form (3NF) 1)Meet all the requirements of the 1NF 2)Meet all the requirements of the 2NF 3)Remove columns that are not dependent upon the primary key. 28 Lecture9 Normalization

29. Example: 2NF 3NF Lecture9 29  If transitive dependencies exist, place transitively dependent attributes in a new relation along with a copy of their determinants. Normalization

30. Books NameAuthor's NameAuthor's Non-de Plume# of Pages Books NameAuthor's Name# of Pages If I know # of Pages, can I find out Author's Name? No. Can I find out Author's Non-de Plume? No. If I know Author's Name, can I find out # of Pages? No. Can I find out Author's Non-de Plume? YES.  Therefore, Author's Non-de Plume is functionally dependent upon Author's Name, not the PK for its existence. Author NameNon-de Plume Lecture9 30 Example : Third normal form -3NF Normalization

31. Review Example 31 PG4 PG16 Pno pAddress 18-Oct-00 22-Apr-01 1-Oct-01 22-Apr-01 24-Oct-01 iDateiTime 10:00 09:00 12:00 13:00 14:00 comments Replace crockery Good order Damp rot Replace carpet Good condition StaffNo SG37 SG14 SG37 CarReg M23JGR M53HDR N72HFR M53HDR N72HFR Lawrence St, Glasgow 5 Novar Dr., Glasgow sName Ann David Ann STAFF_PROPERTY_INSPECTION Unnormalized relation Lecture9 Normalization

32. UNF 1NF 32 PG4 PG16 Pno pAddress 18-Oct-00 22-Apr-01 1-Oct-01 22-Apr-01 24-Oct-01 iDateiTime 10:00 09:00 12:00 13:00 14:00 comments Replace crockery Good order Damp rot Replace carpet Good condition StaffNo SG37 SG14 SG37 CarReg M23JGR M53HDR N72HFR M53HDR N72HFR Lawrence St, Glasgow 5 Novar Dr., Glasgow sName Ann David Ann STAFF_PROPERTY_INSPECTION 1NF Lecture9 Normalization

33. 1NF 2NF 33 Pno pAddressiDateiTime commentsStaffNo CarReg sName STAFF_PROPERTY_INSPECTION Partial Dependency : Pno pAddress Lecture9 Normalization

34. 1NF 2NF 34 Pno iDateiTime commentsStaffNo CarReg sName PROPERTY_INSPECTION 2NF Pno pAddress PROPERTY 2NF Pno pAddress Transitive Dependency : StaffNo Sname Lecture9 Normalization

35. 2NF 3NF 35 Pno iDateiTime commentsStaffNo CarReg PROPERTY_INSPECTION PROPERTY(Pno, pAddres) STAFF(StaffNo, sName) PROPERTY_INSPECT(Pno, iDate, iTime, comments, staffNo, CarReg) 3NF Pno pAddress PROPERTY 3NF StaffNo sName STAFF 3NF Lecture9 Normalization

36. Lecture9 36 Normalization

37. References “Database Systems: A Practical Approach to Design, Implementation and Management.” Thomas Connolly, Carolyn Begg. 5 th Edition, Addison-Wesley, 2009. Lecture9 37 Normalization