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

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

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

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

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

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

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

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

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

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

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

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

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

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

UNF (multivalued) 1NF Lecture9 15 Normalization

UNF (nested relations) 1NF Lecture9 16 Normalization

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 D Carl Sagan Mag James Larry Bird D Jim Carter Paul Simon 17 Lecture9Normalization

Table in 1NF all attribute values are atomic because there are no repeating group and no composite attributes. DPT_NOMG_NOEMP_NOEMP_NM D Carl Sagan D Mag James D Larry Bird D Jim Carter D Paul Simon 18 NormalizationLecture9

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

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

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

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

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

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

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

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

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

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

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

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

Review Example 31 PG4 PG16 Pno pAddress 18-Oct Apr-01 1-Oct Apr 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

UNF 1NF 32 PG4 PG16 Pno pAddress 18-Oct Apr-01 1-Oct Apr 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

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

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

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

Lecture9 36 Normalization

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