1. Process of Normalization Produce a set of relations with – minimal number of attributes to support organization’s data requirements – attributes with a close logical relation described as functional dependency are in same relation – minimal redundancy with each attribute occurring only once with the exception of foreign keys needed to join related relations

2. Database Design A major aim of database design is to group attributes into relations to minimize data redundancy which has the benefits updates to the database are achieved with a minimal number of operations, reducing the potential for data inconsistencies reduction in file storage space

3. Overview of Normalization Process 1.1 st Normal Form No non-atomic values or repeating groups 2.2 nd Normal Form No partial dependencies 3.3 rd Normal Form No transitive dependencies

4. Functional Dependencies Functional Dependency  If A and B are two sets of attributes of a relation R, then A functionally determines B if  each value of A is associated with exactly one value of B  Example – Relation R is address, A = {Zip}, B = {City,State} ZipCityState 38501CookevilleTN 39302NashvilleTN 42020LouisvilleKY A  B imposes a integrity constraint on the database The left side is called the “determinant” of the dependency.

5. staffNosNamePositionSalaryBranch SL21WhiteMgr30000B005 SG37BeechAssist12000B003 SG5BrandMgr24000B003 BranchAddress B005London B007Aberdeen b003Glasgow staffNosNamePosiionSalaryBranchAddress SL21WhiteMgr30000B005London SG37BeechAssist12000B003Aberdeen SG5BrandMgr24000B003Glasgow Staff Branc h StaffBranch partial dependency full {staffNo, sName}  {Branch} is a partial dependency since determinant is not minimal; {staffNo}  {Branch} is a functional (full) dependency {staffNo}  {Branch} and {Branch}  {Address} is a transitive dependency Partial Dependencies : a non-key attribute is functionally dependent on part but not all of the primary key.

6. 1.{staffNo}  {sName, Position, Salary,Branch, Address} 2. {Branch}  {Address} 3. {Address}  {Branch} 4. {Branch, Position}  {Salary} 5. {Address, Position}  {Salary} staffNosNamePositionSalaryBranchAddress SL21WhiteMgr30000B005London SG37BeechAssist12000B003Aberdeen SG5BrandMgr24000B003Glasgow StaffBranch Identify all functional dependencies in the StaffBranch relation.

7. Functional Dependencies – Purchase Order Example already in 1 st normal form PurchaseInfo = (poID,supID,supName,street,city,state,zipcode,movieID, title,quantity, orderDate) Partial Dependencies : a non-key attribute is functionally dependent on part but not all of the primary key. 2 nd Normal Form : A relation is in 2 nd normal form if it is in 1 st normal form and contains no partial dependencies Functional Dependencies : {poID,movieID}  rest-of-attributes – primary key {poID}  {suppID, suppName, street, city, state, zip,date} – partial dependency {movieID}  {title,quantity} - partial dependency poIDsuppIDsupNamestreetcitystatezipmovieIDtitlequantitydate 11232ABCMWashNashTN342121912xyz22/19/08 11232ABCMWashNashTN342123233bam12/19/08 11232ABCMWashNashTN342122312nuts32/19/08

8. 1 st to 2 nd normal form Conversion Technique  Create new relation for each primary key attribute or combination that is a determinant in a partial dependency.  The primary key attribute or combination is the primary key in the new relation.  Move the nonkey attributes which depend on the primary key attribute from the old to the new relation.

9. poIDsuppIDsupNamestreetcitystatezip 11232ABCMWashNashTN34212 movieIDtitlequantity 1912xyz2 3233bam1 2312nuts3 poIDmovieIDdate 112322/19/08 Supplier Info Movie Info Purchase Order All relations in 2 nd normal form

10. 2 nd to 3 rd Normal Form 3 rd Normal Form : A relation is in 3 rd normal form if it is in 2 nd normal form and has no transitive dependencies A transitive dependency is a functional dependency between two or more non-key attributes The relation Supplier_Info(poID, supID,supName,street,city,state,zipcode) has a transitive dependency. {zipcode}  {city,state} is a transitive dependency since the determinant {zipcode} is non-key as are {city,state}. Note : {poID}  {zipcode} and {zipcode}  {city,state}

11. 2 nd to 3 rd normal form Conversion Technique  For each nonkey attribute (or set of attributes) that is a determinant of a transitive dependency in the relation, create a new relation. That attribute becomes the primary key of the relation.  Move all the attributes that are functionally dependent on the determinant to the new relation.  Leave the determinant attribute (or set of attributes) in the old relation as a foreign key to the new relation.

12. poIDsuppIDsupNamestreetzip 11232ABCMWash34212 movieIDtitlequantity 1912xyz2 3233bam1 2312nuts3 poIDmovieIDdate 112322/19/08 Supplier Info Movie Info Purchase Order All relations in 3 nd normal form citystatezip NashTN34212 SupplierAddress

13. SQL examples DDL : Create Table ( ) Create Table PurchaseOrder(poID integer, movieID integer, odate date) Design View Data View

14. SQL examples continued

15. SELECT suppInfo.supName, movieInfo.title FROM (suppAdress INNER JOIN (PurchaseOrder INNER JOIN suppInfo ON PurchaseOrder.poID = suppInfo.poID) ON suppAdress.Zip = suppInfo.zip) INNER JOIN movieInfo ON PurchaseOrder.movieID = movieInfo.movieID WHERE (((PurchaseOrder.poID)=112) AND ((movieInfo.movieID)=32));

16. Identifying Functional Dependencies ABCCE abzwq ebrwp adzwf edfwq afzsf effst Using sample data that is representative of all possible data values that relation / table might hold. Functional Dependencies : fd1 : A  C, fd1 : C  A, fd3 : B  D, fd4 : {A,B}  E

17. Reasons for Identifying Functional Dependencies Main reason is to identify integrity constraints that must hold on a relation in a database. Identifying candidate keys : Example – StaffBranch relation staffNo  sName, position, salary, branch, address branch  address address  branch branch, position  salary address, position  salary It is clear that staffNo is the only candidate key and so would be chosen as the primary key if this relation were to be part of the schema of the database.

18. Process of Normalization clientNocNamepropNoaddressrStartrStoprentownNoownName T051BrownP32 P81 Oak Maple 1/1/07 9/1/08 6/1/07550 600 O03 O07 Carter Biggs T067DoddP81 P96 Maple Cherry 2/1/07 12/1/07 11/31/07600 525 O07 O04 Biggs Stevens Example : Tenant rents property only once and not more than one at a time. TenantRental (clientNo, cName, propNo, address, rStart, rStop, rent, ownNo, ownName) If the same tenant has rented several units, there will be multiple values (repeating groups) in rows corresponding to that tenant.

19. Conversion to 1 st normal form clientNocNamepropNoaddressrStartrStoprentownNoownName T051 Brown P32 P81 Oak Maple 1/1/07 9/1/08 6/1/07550 600 O03 O07 Carter Biggs T067 Dodd P81 P96 Maple Cherry 2/1/07 12/1/07 11/31/07600 525 O07 O04 Biggs Stevens clientNopropNoaddressrStartrStoprentownNoownName T051 P32 P81 Oak Maple 1/1/07 9/1/08 6/1/07 null 550 600 O03 O07 Carter Biggs T067 P81 P96 Maple Cherry 2/1/07 12/1/07 11/31/07 null 600 525 O07 O04 Biggs Stevens Conversion Process 1st Normal Form (atomic values in each column) Client and PropertyRentalOwner relations: clientNocName T051Brown T067Dodd Method 1 : Enter appropriate data in empty columns for repeating data 1st Normal Form (atomic values in each column) Method 2 : Separate repeating data with a copy of key into separate relation or table.

20. Functional Dependencies in 1 st Normal Form The PropertyRentalOwner relation is (clientNo, propNo, address, rStart, rStop, rent, ownNo, ownName) and has the following functional dependencies : 1.clientNo, propNo  address, rStart, rStop rent, ownNo, ownName (primary key) 2.propNo  address, rent, ownNo, ownName 2 nd Normal Form : every non-primary key value is fully functionally dependent on the primary key – no non-key attribute is partially dependent on primary key Functional dependency #2 shows that {address, rent, ownNo, ownName} is partially dependent on the primary key – e.g., clientNo can be removed from determinant Remove {address, rent, ownNo, ownName} along with the determinant propNo and create a new relation PropertyOwner(propNo, address, rent, ownNo, ownName) which, with the client relation Client(clientNo,cName) and Rental(clientNo,propNo,rStart,rStop) relations are in 2 nd normal form.

21. 2 nd to 3 rd Normal Form PropertyOwner(propNo, address, rent, ownNo, ownName) Client(clientNo,cName) Rental(clientNo,propNo,rStart,rStop) are in 2nd normal form 3 rd Normal Form : 2 nd normal form and no transitive dependencies. propNo  ownNo and ownNo  ownName form a transitive dependency. Owner(ownNo,ownName) PropertyOwner(propNo, address, rent, ownNo*) Client(clientNo,cName) Rental(clientNo,propNo,rStart,rStop) are in 3 rd normal form