2. TM 6-1 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Logical Database Design and the Relational Database Professor Chen School of Business Administration Gonzaga University Spokane, WA 99258

3. TM 6-2 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems What is a Relation? A relation is a named, two-dimensional table of data. Each relation consists of a set of named columns and an arbitrary number of unnamed rows. Not all table are relations

4. TM 6-3 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Fig. 6-1: EMPLOYEE1 Relation with sample data EMPLOYEE1 Emp_IDNameDept_Name Salary 100 Margaret SimpsonMarketing 48,000 140 Allen BeetonAccounting 52,000 110Chris LuceroInfo. System 43,000 190Lorenzo DavisFinance 55,000 150Susan MartinMarketing 42,000

5. TM 6-4 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Relational Definitions Relation –Every relation has a unique name. –Every attribute value is atomic (singled-value) (Fig. 6-1) –Every row is unique. –Attributes in tables have unique names. –The order of the columns is irrelevant. –The order of the rows is irrelevant.

6. TM 6-5 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Fig. 6-2: Eliminating multi-valued attributes (a) Table with repeating groups (Un-Normalized) Emp_ID Name Dept_Name Salary Course_ Date_ Title Completed 100 Margaret Simpson Marketing 48,000 SPSS 6/19/199X Surveys 10/7/199X 140 Allen Beeton Accounting 52,000 Tax Acc 12/8/199X 110 Chris Lucero Info. System 43,000 SPSS 1/12/199X C++ 4/22/199X 190 Lorenzo Davis Finance 55,000 150 Susan Martin Marketing 42,000 SPSS 6/16/199X Java 8/12/199X

7. TM 6-6 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Emp_ID Name Dept_Name Salary Course_ Date_ Title Completed 100 Margaret Simpson Marketing 48,000 SPSS 6/19/199X Surveys 10/7/199X 140 Allen Beeton Accounting 52,000 Tax Acc 12/8/199X 110 Chris Lucero Info. System 43,000 SPSS 1/12/199X C++ 4/22/199X 190 Lorenzo Davis Finance 55,000 150 Susan Martin Marketing 42,000 SPSS 6/16/199X Java 8/12/199X Emp_ID Name Dept_Name Salary Course_ Date_ Title Completed 100 Margaret Simpson Marketing 48,000 SPSS 6/19/199X 100 Margaret Simpson Marketing 48,000 Surveys 10/7/199X 140 Allen Beeton Accounting 52,000 Tax Acc 12/8/199X 110 Chris Lucero Info. System 43,000 SPSS 1/12/199X 110 Chris Lucero Info. System 43,000 C++ 4/22/199X 190 Lorenzo Davis Finance 55,000 150 Susan Martin Marketing 42,000 SPSS 6/16/199X 150 Susan Martin Marketing 42,000 Java 8/12/199X

8. TM 6-7 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Fig. 6-2: Eliminating multi-valued attributes (b) EMPLOYEE2 Relation (Normalized) Emp_ID Name Dept_Name Salary Course_ Date_ Title Completed 100 Margaret Simpson Marketing 48,000 SPSS 6/19/199X 100 Margaret Simpson Marketing 48,000 Surveys 10/7/199X 140 Allen Beeton Accounting 52,000 Tax Acc 12/8/199X 110 Chris Lucero Info. System 43,000 SPSS 1/12/199X 110 Chris Lucero Info. System 43,000 C++ 4/22/199X 190 Lorenzo Davis Finance 55,000 150 Susan Martin Marketing 42,000 SPSS 6/16/199X 150 Susan Martin Marketing 42,000 Java 8/12/199X EMPLOYEE2

9. TM 6-8 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Relational Keys and Structures Primary Key Composite Key Foreign Key –One-to-Many Relationship –Many-to-Many Relationship Intersection Data Candidate Key Surrogate Key

10. TM 6-9 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Fig. 6-3: Schema for four relations (Pine Valley Furniture) Graphical Representation

11. TM 6-10 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Fig. 6-3: Schema for four relations (Pine Valley Furniture) Graphical and Text Representations CUSTOMER(Customer_ID, Customer_name,Address, City,State,Zip) ORDER(Order_ID, Order_Date,Customer_ID) ORDER_LINE(Order_ID, Product_ID,Quantity) PRODUCT(Product_ID, Product_Description, Product_Finish,Unit_Price, On_Hand)

12. TM 6-11 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Integrity Constraints Domain Constraints –Allowable values for an attribute. – A domain definition contains: domain name, data type, size, meaning, and allowable values/range (if applicable). Entity Integrity –No primary key attribute may be null. Operational Constraints –Business rules (see Chapter 4)

13. TM 6-12 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Fig. 6-5: Referential integrity constraints (Pine Valley Furniture) pk ck/pk pk fk

14. TM 6-13 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Referential Integrity (Addition and Deletion) PK FK

15. TM 6-14 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Referential Integrity (Summary) Addition - you can’t add (insert) an ORDER record if Customer_ID (FK) does not exist (or does not match) a Customer_ID (PK) in the CUSTOMER table. Deletion - you can’t delete a CUSTOMER record if there is (are) related Customer_ID in the ORDER table.

16. TM 6-15 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Integrity Constraints Referential Integrity – A rule that states that either each foreign key value must match a primary key value in the other relation or else the foreign key value must be null. –For example: Delete Rules Restrict Cascade Set-to-Null

17. TM 6-16 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Referential Integrity (Conclusion) common field fk pk

18. TM 6-17 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Referential Integrity (Conclusion)

19. TM 6-18 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Referential Integrity (Conclusion)

20. TM 6-19 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Referential Integrity (Conclusion)

21. TM 6-20 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Order of Entering Data and Referential Integrity LOCATION FACULTY STUDENT

23. TM 6-22 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Well-Structured Relations A well-structured relation contains minimal redundancy and allows users to insert, modify, and delete the rows in a table without errors or inconsistencies. The following anomalies should be removed for a well-structured relation: –Insertion Anomaly –Deletion Anomaly –Modification Anomaly

24. TM 6-23 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Emp_ID Name Dept_Name Salary Course_ Date_ Title Completed 100 Margaret Simpson Marketing 48,000 SPSS 6/19/199X 100 Margaret Simpson Marketing 48,000 Surveys 10/7/199X 140 Allen Beeton Accounting 52,000 Tax Acc 12/8/199X 110 Chris Lucero Info. System 43,000 SPSS 1/12/199X 110 Chris Lucero Info. System 43,000 C++ 4/22/199X 190 Lorenzo Davis Finance 55,000 150 Susan Martin Marketing 42,000 SPSS 6/16/199X 150 Susan Martin Marketing 42,000 Java 8/12/199X EMPLOYEE2 Is EMPLOYEE2 a Well- Structured relation?

25. TM 6-24 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Is EMPLOYEE2 a Well- Structured relation? NO! WHY?

26. TM 6-25 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Insertion Anomaly : Inserting a new row, the user must supply values for both Emp_ID (PK) and Course_Title (CK and FK). This is an (insertion) anomaly, since the user should be able to enter employee data without knowing (supplying) course (title) data. Emp_ID Name Dept_Name Salary Course_ Date_ Title Completed 100 Margaret Simpson Marketing 48,000 SPSS 6/19/199X 100 Margaret Simpson Marketing 48,000 Surveys 10/7/199X 140 Allen Beeton Accounting 52,000 Tax Acc 12/8/199X 110 Chris Lucero Info. System 43,000 SPSS 1/12/199X 110 Chris Lucero Info. System 43,000 C++ 4/22/199X 190 Lorenzo Davis Finance 55,000 150 Susan Martin Marketing 42,000 SPSS 6/16/199X 150 Susan Martin Marketing 42,000 Java 8/12/199X EMPLOYEE2

27. TM 6-26 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Deletion Anomaly : Deleting the employee number 140, it results in losing not only the employee’s information but also the course had an offering that completed on that date. Emp_ID Name Dept_Name Salary Course_ Date_ Title Completed 100 Margaret Simpson Marketing 48,000 SPSS 6/19/199X 100 Margaret Simpson Marketing 48,000 Surveys 10/7/199X 140 Allen Beeton Accounting 52,000 Tax Acc 12/8/199X 110 Chris Lucero Info. System 43,000 SPSS 1/12/199X 110 Chris Lucero Info. System 43,000 C++ 4/22/199X 190 Lorenzo Davis Finance 55,000 150 Susan Martin Marketing 42,000 SPSS 6/16/199X 150 Susan Martin Marketing 42,000 Java 8/12/199X EMPLOYEE2

28. TM 6-27 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Modification Anomaly : If the employee number 100 gets a salary increase, we must record the increase in each of the rows for that employee (two occurences); otherwise the data will be inconsistent. Emp_ID Name Dept_Name Salary Course_ Date_ Title Completed 100 Margaret Simpson Marketing 48,000 SPSS 6/19/199X 100 Margaret Simpson Marketing 48,000 Surveys 10/7/199X 140 Allen Beeton Accounting 52,000 Tax Acc 12/8/199X 110 Chris Lucero Info. System 43,000 SPSS 1/12/199X 110 Chris Lucero Info. System 43,000 C++ 4/22/199X 190 Lorenzo Davis Finance 55,000 150 Susan Martin Marketing 42,000 SPSS 6/16/199X 150 Susan Martin Marketing 42,000 Java 8/12/199X EMPLOYEE2

29. TM 6-28 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Fig. 6-7: Normalized Relations from EMPLOYEE2 EMPLOYEE2 Emp_IDName Dept_Name Salary 100 Margaret Simpson Marketing 48,000 140 Allen Beet Accounting 52,000 110 Chris Lucero Info. System 43,000 190 Lorenzo Davis Finance 55,000 150 Sususan Martin Marketing 42,000 Emp_ID Name Dept_Name Salary Course_ Date_ Title Completed 100 Margaret Simpson Marketing 48,000 SPSS 6/19/199X 100 Margaret Simpson Marketing 48,000 Surveys 10/7/199X 140 Allen Beeton Accounting 52,000 Tax Acc 12/8/199X 110 Chris Lucero Info. System 43,000 SPSS 1/12/199X 110 Chris Lucero Info. System 43,000 C++ 4/22/199X 190 Lorenzo Davis Finance 55,000 150 Susan Martin Marketing 42,000 SPSS 6/16/199X 150 Susan Martin Marketing 42,000 Java 8/12/199X Emp_ID Course_ Date_ Title Completed 100 SPSS 6/19/199X 100 Surveys 10/7/199X 140 Tax Acc 12/8/199X 110 SPSS 1/12/199X 110 C++ 4/22/199X 150 SPSS 6/19/199X 150 Java 8/12/199X EMPLOYEE1EMP_COURSE

30. TM 6-29 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Normalization Normalization is the process of decomposing relations with anomalies to produce smaller, well- structured and stable relations.

31. TM 6-30 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Data Normalization Normalization is a formal process for deciding which attributes should be grouped together in a relation (see Fig.6-7 next). Primarily a tool to validate and improve a logical design so that it satisfies certain constraints that avoid unnecessary duplication of data.

32. TM 6-31 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Fig. 6-7: Normalized Relations from EMPLOYEE2 EMPLOYEE2 Emp_IDName Dept_Name Salary 100 Margaret Simpson Marketing 48,000 140 Allen Beet Accounting 52,000 110 Chris Lucero Info. System 43,000 190 Lorenzo Davis Finance 55,000 150 Sususan Martin Marketing 42,000 Emp_ID Name Dept_Name Salary Course_ Date_ Title Completed 100 Margaret Simpson Marketing 48,000 SPSS 6/19/199X 100 Margaret Simpson Marketing 48,000 Surveys 10/7/199X 140 Allen Beeton Accounting 52,000 Tax Acc 12/8/199X 110 Chris Lucero Info. System 43,000 SPSS 1/12/199X 110 Chris Lucero Info. System 43,000 C++ 4/22/199X 190 Lorenzo Davis Finance 55,000 150 Susan Martin Marketing 42,000 SPSS 6/16/199X 150 Susan Martin Marketing 42,000 Java 8/12/199X Emp_ID Course_ Date_ Title Completed 100 SPSS 6/19/199X 100 Surveys 10/7/199X 140 Tax Acc 12/8/199X 110 SPSS 1/12/199X 110 C++ 4/22/199X 150 SPSS 6/19/199X 150 Java 8/12/199X EMPLOYEE1 EMP_COURSE

33. TM 6-32 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Functional Dependencies and Keys Functional Dependency: The value of one attribute (the determinant) determines the value of another attribute. Candidate Key:An attribute, or combination of attributes, that uniquely identifies a row in a relation. A candidate key is always a determinant, while a determinant may or may not be a candidate key. Each non-key field is functionally dependent on every candidate key.

34. TM 6-33 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Fig. 6-22: Steps in normalization

35. TM 6-34 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems First Normal Form Normal form is a state of a relation that results from applying simple rules regarding functional dependencies (or relationships between attributes) to that relation. No multi-valued attributes. Every attribute value is atomic. Fig. 6-2a, b.

36. TM 6-35 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Emp_ID Name Dept_Name Salary Course_ Date_ Title Completed 100 Margaret Simpson Marketing 48,000 SPSS 6/19/199X 100 Margaret Simpson Marketing 48,000 Surveys 10/7/199X 140 Allen Beeton Accounting 52,000 Tax Acc 12/8/199X 110 Chris Lucero Info. System 43,000 SPSS 1/12/199X 110 Chris Lucero Info. System 43,000 C++ 4/22/199X 190 Lorenzo Davis Finance 55,000 150 Susan Martin Marketing 42,000 SPSS 6/16/199X 150 Susan Martin Marketing 42,000 Java 8/12/199X Emp_ID Name Dept_Name Salary Course_ Date_ Title Completed 100 Margaret Simpson Marketing 48,000 SPSS 6/19/199X Surveys 10/7/199X 140 Allen Beeton Accounting 52,000 Tax Acc 12/8/199X 110 Chris Lucero Info. System 43,000 SPSS 1/12/199X C++ 4/22/199X 190 Lorenzo Davis Finance 55,000 150 Susan Martin Marketing 42,000 SPSS 6/16/199X Java 8/12/199X

37. TM 6-36 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Second Normal Form 1NF and every non-key attribute is fully functionally dependent on the primary key. Every non-key attribute must be defined by the entire key (either a single PK or a CK), not by only part of the key. No partial functional dependencies. Fig. 6-1,6-23a

38. TM 6-37 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Fig. 6-23: A Process of 1NF to 2NF (EMPLOYEE2 - - 1NF) (b) Functional Dependencies in EMPLOYEE2 Partial Depend. Emp_IDCourse_TitleNameDept_NameDate_CompletedSalary Emp_ID Name Dept_Name Salary Course_ Date_ Title Completed 100 Margaret Simpson Marketing 48,000 SPSS 6/19/199X 100 Margaret Simpson Marketing 48,000 Surveys 10/7/199X 140 Allen Beeton Accounting 52,000 Tax Acc 12/8/199X 110 Chris Lucero Info. System 43,000 SPSS 1/12/199X 110 Chris Lucero Info. System 43,000 C++ 4/22/199X 190 Lorenzo Davis Finance 55,000 150 Susan Martin Marketing 42,000 SPSS 6/16/199X 150 Susan Martin Marketing 42,000 Java 8/12/199X

39. TM 6-38 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Fig. 6-23: A Process of 1NF to 2NF EMPLOYEE1 Emp_IDNameSalaryDept_Name (a) Functional dependencies in EMPLOYEE1 (2NF) Emp_IDNameDept_Name Salary 100 Margaret SimpsonMarketing 48,000 140 Allen BeetonAccounting 52,000 110Chris LuceroInfo. System 43,000 190Lorenzo DavisFinance 55,000 150Susan MartinMarketing 42,000

40. TM 6-39 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Emp_IDNameSalaryDept_Name Emp_IDCourse_TitleNameDept_NameDate_CompletedSalary Partial Depend. EMPLOYEE2 EMPLOYEE1 Emp_IDCourse_TitleDate_Completed EMP_COURSE 2NF 3NF ? Fig. 6-23: Summary on Normalization

41. TM 6-40 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems EMPLOYEE2 (1NF) Emp_IDName Dept_Name Salary 100 Margaret Simpson Marketing 48,000 140 Allen Beet Accounting 52,000 110 Chris Lucero Info. System 43,000 190 Lorenzo Davis Finance 55,000 150 Sususan Martin Marketing 42,000 Emp_ID Name Dept_Name Salary Course_ Date_ Title Completed 100 Margaret Simpson Marketing 48,000 SPSS 6/19/199X 100 Margaret Simpson Marketing 48,000 Surveys 10/7/199X 140 Allen Beeton Accounting 52,000 Tax Acc 12/8/199X 110 Chris Lucero Info. System 43,000 SPSS 1/12/199X 110 Chris Lucero Info. System 43,000 C++ 4/22/199X 190 Lorenzo Davis Finance 55,000 150 Susan Martin Marketing 42,000 SPSS 6/16/199X 150 Susan Martin Marketing 42,000 Java 8/12/199X Emp_ID Course_ Date_ Title Completed 100 SPSS 6/19/199X 100 Surveys 10/7/199X 140 Tax Acc 12/8/199X 110 SPSS 1/12/199X 110 C++ 4/22/199X 150 SPSS 6/19/199X 150 Java 8/12/199X EMPLOYEE1 (3NF) EMP_COURSE (3NF) Fig. 6-23: Summary on Normalization

42. TM 6-41 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Third Normal Form 2NF and no transitive dependencies (functional dependency between non-key attributes.) Fig. 6-23, 6-24, 6-25.

43. TM 6-42 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Fig. 6-24: Relation with transitive dependency (a) SALES relation with simple data

44. TM 6-43 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems What Anomalies might be in SALES relation? Insertion anomaly ? Deletion anomaly ? Modification anomaly ?

45. TM 6-44 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Fig. 6-24: (b) Transitive dependency in SALES relation Cust_ID ---> Name, Salesperson, Region and Salesperson ---> Region therefore... Cust_ID ---> Region

46. TM 6-45 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Fig. 6-25: Removing a transitive dependency (a) Decomposing the SALES relation

47. TM 6-46 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Fig. 6-25: (b) Relations in 3NF

48. TM 6-47 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Snum Origin Destination Distance 409 Seattle Denver 1,537 618 Chicago Dallas 1,058 723 Boston Atlanta 1,214 824 Denver Las Angeles 1,150 629 Minneapolis St. Louis 587 353 Seattle Denver 1,537 Fig. 6-26: Another example with transitive dependencies Insertion anomaly? Deletion anomaly? Modification anomaly?

49. TM 6-48 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Break !

50. TM 6-49 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Fig. 6-26: Another example with transitive dependencies Snum Origin DestinationDistance SHIPMENT Snum Origin Destination 409 Seattle Denver 618 Chicago Dallas 723 Boston Atlanta 824 Denver Las Angeles 629 Minneapolis St. Louis 353 Seattle Denver Origin Destination Distance Seattle Denver 1,537 Chicago Dallas 1,058 Boston Atlanta 1,214 Denver Las Angeles 1,150 Minneapolis St. Louis 587 Seattle Denver 1,537

51. TM 6-50 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Fig. 6-22: Steps in normalization

52. TM 6-51 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Merging Relations (View Integration) In a project development process, there may be a number of separate E-R diagrams and user views created and some of them may be redundant. Therefore, some relations should be merged to remove the redundancy.

53. TM 6-52 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Merging Relations (View Integration - A example) EMPLOYEE1( Employee_ID, Name, Address, Phone) EMPLOYEE2(Employee_ID, Name, Address, Jobcode, No_Years) EMPLOYEE(Employee_ID, Name, Address,Phone, Jobcode, No_Years)

54. TM 6-53 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Merging Relations (Problems on View Integration) ÊSynonyms: Different names, same meaning. ·Homonyms: Same name, different meanings. ¸Transitive Dependencies: e.g. (Stu ID, Major) (Stu ID, Advisor). ¹Supertype/Subtype.

55. TM 6-54 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Problems on View Integration ¶Synonyms: Different names, same meaning. STUDENT1(Student_ID, Name) STUDENT2(Matriculation_No,Name, Address) STUDENT(SSN, Name, Address) ·Homonyms: Same name, different meanings. STUDENT1(Student_ID, Name,Address) STUDENT2(Student_ID,Name, Phone_No,Address) STUDENT2(Student_ID,Name, Phone_No, Campus_Address, Permanent_Address)

56. TM 6-55 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Problems on View Integration ¶Synonyms: Different names, same meaning. STUDENT1(Student_ID, Name) STUDENT2(Matriculation_No,Name, Address) STUDENT(SSN, Name, Address) ·Homonyms: Same name, different meanings. STUDENT1(Student_ID, Name,Address) STUDENT2(Student_ID,Name, Phone_No,Address) STUDENT2(Student_ID,Name, Phone_No, Campus_Address, Permanent_Address)

57. TM 6-56 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Problems on View Integration ¸Transitive Dependencies STUDENT1(Student_ID, Major) STUDENT2(Student_ID, Advisor) the result is... STUDENT(Student_ID, Major, Advisor) and after removing transitive dependency STUDENT(Student_ID, Major) STUDENT(Major, Advisor)

58. TM 6-57 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Problems on View Integration ¹Supertype/Subtype PATIENT1(Patient_ID, Name, Address) PATIENT2(Patient_ID, Room_No) PATIENT(Patient_ID, Name, Address) INPATIENT(Patient_ID, Room_No) OUTPATIENT(Patient_ID, Date_Treated)

59. TM 6-58 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems After learning one of most important database concepts and theories... WHAT’S NEXT ?

60. TM 6-59 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Relational Definitions Tuple Attribute View

61. TM 6-60 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Relational Concepts Relational Algebra Relational Calculus Relational Operations –SELECT –PROJECT –JOIN Equijoin - Join field appears twice. Natural Join - Join field appears once.

62. TM 6-61 Copyright © Addison Wesley Longman, Inc. & Dr. Chen, Business Database Systems Logical Database Design You have just learned and completed one of the most important concepts and theories, integrity constraints and normalization, for developing a quality of database.