1. ITEC 3220A Using and Designing Database Systems Instructor: Gordon Turpin Course Website: www.cse.yorku.ca/~gordon/itec3220S07 Office: CSEB3020

2. 2 Supertypes and Subtypes Generalization hierarchy: depicts relationships between higher-level supertype and lower-level subtype entities Supertype:Supertype: contains the shared attributes Subtype:Subtype: contains the unique attributes Inheritance:Inheritance: –Subtype entities inherit values of all attributes of the supertype –An instance of a subtype is also an instance of the supertype

3. 3 Supertypes and Subtypes (Cont’d) Supertype/ subtype relationships SUPERTYPE Attributes shared by all entities SUBTYPE1 Attributes unique to subtype2 SUBTYPE2 Attributes unique to subtype1 General entity type And so forth Specialized version of supertype

4. 4 Supertypes and Subtypes (Cont’d) Disjoint relationships –Unique subtypes –Non-overlapping –Indicated with a ‘G’ Overlapping subtypes –An instance of the supertype could be more than one of the subtypes –Indicated with a ‘Gs’

5. 5 Generalization Hierarchy with Overlapping Subtypes

6. Chapter 5 Logical Database Design and Normalization of Database Tables

7. 7 In this chapter, you will learn: How to transform ERD into relations What normalization is and what role it plays in database design About the normal forms 1NF, 2NF, 3NF, BCNF, and 4NF How normal forms can be transformed from lower normal forms to higher normal forms Normalization and E-R modeling are used concurrently to produce a good database design Some situations require denormalization to generate information efficiently

8. 8 Transforming ERD into Relations Step one: Map regular entities –Each regular entity type in an ER diagram is transformed into a relation –The name given to the relation is generally the same as the entity type –Each simple attribute of the entity type becomes an attribute of the relation and the identifier of entity becomes the primary key of the corresponding relation

9. 9 Example Student_ID Student_Name Other_Attributes STUDENT

10. 10 Transforming ERD into Relations (Cont’d) Step two: Map weak entities –Create a new relation and include all of the simple attributes as the attributes of this relation. Then include the primary key of the identifying relation as a foreign key attribute in this new relation. The primary key of the new relation is the combination of this primary key of the identifying relation and the partial identifier of the weak entity type.

11. 11 Example EMPLOYEE Has DEPENDENT Employee_IDEmployee_Name Dependent_Name Gender Date_of_birth Employee_IDEmployee_Name EMPLOYEE DEPENDENT Dependent_NameEmployee_IDDate_of_birthGender

12. 12 Transforming ERD into Relations (Cont’d) Step three: Map binary relationship –Map Binary one-to-many relations First create a relation for each of the two entity types participating in the relationship, using the procedure described in step one. Next, include the primary key attribute of the entity on the one-side of the relationship as a foreign key in the relation that is on the many-side of the relationship.

13. 13 Example M Order_DateOrder_ID Customer Customer_NameCustomer_ID SubmitsOrder 1 (1,1)(0,N) Customer_IDCustomer_Name Customer Order Order_IDOrder_DateCustomer_ID

14. 14 Transforming ERD into Relations (Cont’d) Step three: Map binary relationship (Cont’d) –Map binary one-to-one relationships First, two relationships are created one for each of the participating entity types. Second, the primary key of one of the relations is included as a foreign key in the other relation.

15. 15 Example Location Centre_Name Nurse Nurse_NameNurse_ID In_charge Care Centre 1 (1,1) (0,1) 1 Nurse_IDNurse_Name Nurse Centre_NameLocationNurse_in_c harge Care Centre

16. 16 Transforming ERD into Relations (Cont’d) Step Four: Map composite Entities –First step Create three relations: one for each of the two participating entities, and the third for the composite entity. We refer to the relation formed from the composite entity as the composite relation –Second step Identifier not assigned: The default primary key for the composite relation consists of the two primary key attributes from the other two relations. Identifier assigned: The primary key for the composite relation is the identifier. The primary keys for the two participating entity types are included as foreign keys in the composite relation.

17. 17 Example 1 Order Order Line Order_DateOrder_IDQuantity ProductPrice Description Product_ID (1,N) M M 1 (1,1) (0,N)

18. 18 Example Order_IDOrder_Date Product_IDDescriptionStandard_Price Product_IDOrder_IDQuantity Order Order Line Product

19. 19 Example Customer_IDCustomer_Name Customer Shipment_N o Vendor_I D Customer_I D DateAmount Shipment Vendor Vendor_IDAddress M Vendor_ID Customer Name Customer_ID Shipment Vendor Shipment_No Amount Date 1M1

20. 20 Transforming ERD into Relations (Cont’d) Step Five: Map unary relationship –Map unary one-to-many relationship The entity type in the unary relationship is mapped to a relation using the procedure described in Step one. Then a foreign key attribute is added within the same relation that references the primary key values. A recursive foreign key is a foreign key in a relation that references the primary key values of that same relation.

21. 21 Example Manages Employee_IDBirthdate Name Employee 1 M (1,1) (0,N) Employee_IDNameBirthdateManager_ID Employee

22. 22 Transforming ERD into Relations (Cont’d) Step six: Map ternary relationship –Convert a ternary relationship to a composite entity –To map a composite entity that links three regular entities, we create a new composite relation. The default primary key of their relation consists of the three primary key attributes for the participating entities. Any attributes of the composite entity become attributes of the new relation

23. 23 Example 1 1 (1,1) (0,N) (1,1) (0,N) (1,1) M M 1 Treatment Physician Patient Physician_ID Physician_Name Patient_ID Patient_Name Description Treatment_ Code Patient Treatment Time Date Results M

24. 24 Example Patient_IDPatient_Name Treatment_CodeDescription Physician_IDPhysician_Name Patient_ ID Physician_I D Treatment_C ode DateTimeResult Patient Physician Treatment Patient Treatment

25. 25 Transforming ERD into Relations (Cont’d) Step seven: Map supertype/subtype relationships 1.Create a separate relation for the supertype and for each of its subtype 2.Assign to the relation created for the supertype the attributes that are common to all members of the supertype, including the primary key 3.Assign to the relation for each subtype the primary key of the supertype, and only those attributes that are unique to that subtype 4.Assign one attribute of the supertype to function as the subtype discriminator

26. 26 Example Employee_Name Address Date_Hired EmployeeEmployee_Number Employee_Type Salaried Employee Hourly Employee Gs Hourly_Rate Stock_OptionAnnual_Salary

27. 27 Example Employee_Nu mber Employee_N ame AddressEmployee_Ty pe Date_Hi red S_Employee_NumberAnnual_SalaryStock_Option H_Employee_NumberHourly_Rate Employee Hourly_Employee Salaried_Employee

28. 28 Database Tables and Normalization Table is the basic building block in database design Normalization is the process for assigning attributes to entities –Reduces data redundancies –Helps eliminate data anomalies –Produces controlled redundancies to link tables Normalization stages –1NF - First normal form –2NF - Second normal form –3NF - Third normal form –4NF - Fourth normal form

29. 29 Need for Normalization

30. 30 Anomalies In the Table PRO_NUM intended to be primary key Table displays data anomalies –Update Modifying JOB_CLASS –Insertion New employee must be assigned project –Deletion If employee deleted, other vital data lost

31. 31 Conversion to 1NF Step 1: Eliminate the Repeating Groups –Present data in a tabular format, where each cell has a single value and there are no repeating groups –Eliminate repeating groups by eliminating nulls, making sure that each repeating group attribute contains an appropriate data value Step 2: Identify the Primary Key –Primary key must uniquely identify attribute value

32. 32 Dependency Diagram (1NF)

33. 33 1NF Summarized All key attributes defined No repeating groups in table All attributes dependent on primary key All relational tables satisfy 1NF requirements

34. 34 Conversion to 2NF Start with 1NF form: Write each key component on separate line Write original key on last line Each component is new table Write dependent attributes after each key PROJECT (PROJ_NUM, PROJ_NAME) EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS, CHG_HOUR) ASSIGN (PROJ_NUM, EMP_NUM, HOURS)

35. 35 2NF Conversion Results

36. 36 2NF Summarized In 1NF Includes no partial dependencies –No attribute dependent on a portion of primary key Still possible to exhibit transitive dependency –Attributes may be functionally dependent on nonkey attributes

37. 37 Conversion to 3NF Create separate table(s) to eliminate transitive functional dependencies –For every transitive dependency, write its determinant as a PK for a new table –Identify the Dependent Attributes PROJECT (PROJ_NUM, PROJ_NAME) ASSIGN (PROJ_NUM, EMP_NUM, HOURS) EMPLOYEE (EMP_NUM, EMP_NAME, JOB_CLASS) JOB (JOB_CLASS, CHG_HOUR)

38. 38 3NF Summarized In 2NF Contains no transitive dependencies

39. 39 Boyce-Codd Normal Form (BCNF) Every determinant in the table is a candidate key –Determinant is an attribute whose value determines other values within a row –3NF table with one candidate key is already in BCNF

40. 40 3NF Table Not in BCNF

41. 41 Decomposition of Table Structure to Meet BCNF

42. 42 Decomposition into BCNF

43. 43 An Example GRADE( Student_ID, Student_Name, Address, Major, Course_ID, Course_Title, Instructor_Name, Instructor_Office, Grade)

44. 44 Normalization and Database Design Normalization should be part of the design process E-R Diagram provides macro view Normalization provides micro view of entities –Focuses on characteristics of specific entities –May yield additional entities Difficult to separate normalization from E-R diagramming Business rules must be determined

45. 45 Higher-Level Normal Forms Fourth Normal Form (4NF) –Table is in 3NF –Has no multiple sets of multivalued dependencies

46. 46 Conversion to 4NF Stud-IDCourseService 11261212FRed Cross 11261620FUnited Way 11261320F Stud-IDCourseService 11261212F 11261620F 11261320F 1126Red Cross 1126United Way Stud-IDCourseService 11261212FRed Cross 11261620FUnited Way 11261320F Multivalued Dependencies Set of Tables in 4NF Stud-IDCourse 11261212F 11261620F 11261320F Stud-IDService 1126Red Cross 1126United Way

47. 47 Denormalization Normalization is one of many database design goals Normalized table requires –Additional processing –Loss of system speed Normalization purity is difficult to sustain due to conflict in: –Design efficiency –Information requirements –Processing

48. 48 Exercise Part_ No DescriptionVendor_Nam e AddressUnit_C ost 1234Logic ChipsFast Chips Smart Chips Cupertino Phoenix 10.00 8.00 5678Memory ChipsFast Chips Quality Chips Smart Chips Cupertino Austin Phoenix 3.00 2.00 5.00 Part Supplier Data

49. 49 Exercise(Cont’d) Convert the table to a relation in first normal form (Named Part Supplier) List the functional dependency in the Part Supplier and identify a candidate key For the relation Part Supplier, identify the followings: an insert anomaly, a delete anomaly, and a modification anomaly. Draw a relation schema and show the functional dependencies Develop a set of 3NF relations from Part Supplier

50. 50 Chapter 5 Review How to transform ERD into relations Definitions: 1NF, 2NF, 3NF, BCNF, and 4NF How normal forms can be transformed from lower normal forms to higher normal forms