1. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-1 COS 346 Day 9

2. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-2 Agenda Assignment 3 is NOT Corrected –I looked at the assignments and only two students would receive a passing grade –REDO due Feb 23  I will grade either the REDO or the first submission Assignment 4 Posted Due next Monday Feb 23 Quiz 1  Mar 2 (note change!) –DP Chap 1-6, SQL Chap 1 & 2 –15 M/C @ 4 points each, – 5 Short essays @ 8 points each. –60 min Capstone Proposals OVERDue –Must be a database related capstone –Capstone Project Description sp 09.htmCapstone Project Description sp 09.htm –Received 5 …4 require modification..1 rejected Discussion on Transforming Data Models into Database Designs

3. Assignment 3 DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-3 Marcia is in the process of creating databases to support the operation and management of her business. For the past year, she and her staff have been using a cash register system that collects the following data: SALE (InvoiceNumber, DateIn, DateOut, Total, Phone, FirstName, LastName) Unfortunately, during rush times, not all of the data are entered, and there are many null values in Phone, FirstName, and LastName. In some cases all three are null, in other cases one or two are null. InvoiceNumber, DateIn, and Total are never null. DateOut has a few null values. Also, occasionally during a rush, phone number and name data have been entered incorrectly. To help create her database, Marcia purchased a mailing list from a local business bureau. The mailing list includes the following data: HOUSEHOLD (Phone, FirstName, LastName, Street, City, State, Zip, Apartment) In some cases, a phone number has multiple names. The primary key is thus the composite (Phone, FirstName, LastName). There are no null values in Phone, FirstName, and LastName, but there are some null values in the address data. There are many names in SALE that are not in HOUSEHOLD, and there are many names in HOUSEHOLD that are not in SALE.

4. Design an updateable database for storing customer and sales data. Explain how to deal with the problems of missing data. Explain how to deal with the problems of incorrect phone and name data. Design a read-only database for storing customer and sales data. Explain how to deal with the problems of missing data. Explain how to deal with the problems of incorrect phone and name data. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-4

5. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-5 David M. Kroenke’s Chapter Six: Transforming Data Models into Database Designs Part One Database Processing: Fundamentals, Design, and Implementation

6. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-6 Steps for Transforming a Data Model into a Database Design

7. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-7 Create a Table for Each Entity EMPLOYEE (EmployeeNumber, EmployeeName, Phone, Email, HireDate, ReviewDate, EmpCode) Note shadowless table Primary key is designated by key symbol

8. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-8 Select the Primary Key The ideal primary key is short, numeric and fixed Surrogate keys meet the ideal, but have no meaning to users

9. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-9 Specify Candidate (Alternate) Keys The terms candidate key and alternate key are synonymous Candidate keys are alternate identifiers of unique rows in a table ERwin uses AKn.m notation, where n is the number of the alternate key, and m is the column number in that alternate key

10. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-10 Specify Candidate (Alternate) Keys

11. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-11 Specify Column Properties: Null Status Null status indicates whether or not the value of the column can be NULL

12. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-12 Specify Column Properties: Data Type Generic Data Types: –CHAR(n) –VARCHAR(n) –DATE –TIME –MONEY –INTEGER –DECIMAL

13. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-13 Specify Column Properties: SQL Server Data Types http://msdn.microsoft.com/en-us/library/ms187752(SQL.90).aspx

14. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-14 Specify Column Properties: Oracle Data Types http://www.ss64.com/orasyntax/datatypes.html

15. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-15 Specify Column Properties: Default Value A default value is the value supplied by the DBMS when a new row is created

16. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-16 Specify Column Properties: Data Constraints Data constraints are limitations on data values: –Domain constraint - Column values must be in a given set of specific values –Range constraint - Column values must be within a given range of values –Intrarelation constraint – Column values are limited by comparison to values in other columns in the same table –Interrelation constraint - Column values are limited by comparison to values in other columns in other tables [Referential integrity constraints on foreign keys]

17. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-17 Verify Normalization The tables should be normalized based on the data model Verify that all tables are: –BCNF –4NF –DKNF??

18. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-18 Create Relationships: 1:1 Strong Entity Relationships Place the key of one entity in the other entity as a foreign key: –Either design will work – no parent, no child –Minimum cardinality considerations may be important: O-M will require a different design that M-O, and One design will be very preferable

19. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-19 Create Relationships: 1:1 Strong Entity Relationships

20. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-20 Create Relationships: 1:N Strong Entity Relationships Place the primary key of the table on the one side of the relationship into the table on the many side of the relationship as the foreign key The one side is the parent table and the many side is the child table, so “Place the key of the parent in the child”

21. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-21 Create Relationships: 1:N Strong Entity Relationships

22. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-22 Create Relationships: N:M Strong Entity Relationships In an N:M strong entity relationship there is no place for the foreign key in either table: –A COMPANY may supply many PARTs –A PART may be supplied by many COMPANYs

23. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-23 Create Relationships: N:M Strong Entity Relationships The solution is to create an intersection table that stores data about the corresponding rows from each entity The intersection table consists only of the primary keys of each table which form a composite primary key Each table’s primary key becomes a foreign key linking back to that table COMPANY_PART_INT (CompanyName, PartNumber)

24. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-24 Create Relationships: N:M Strong Entity Relationships COMPANY_PART_INT (CompanyName, PartNumber)

25. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-25 David M. Kroenke’s Database Processing Fundamentals, Design, and Implementation (10 th Edition) End of Presentation: Chapter Six Part One

26. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-26 David M. Kroenke’s Chapter Six: Transforming Data Models into Database Designs Part Two Database Processing: Fundamentals, Design, and Implementation

27. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-27 Relationships Using ID-Dependent Entities: Four Uses for ID-Dependent Entities Representing N:M Relationships –We just discussed this Association Relationships Multivalued Attributes Archtype/Instance Relationships

28. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-28 Relationships Using ID-Dependent Entities: Association Relationships An intersection table: –Holds the relationships between two strong entities in an N:M relationship –Contains only the primary keys of the two entities: As a composite primary key As foreign keys An association table: –Has all the characteristics of an intersection table –PLUS it has one or more columns of attributes specific to the associations of the other two entities

29. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-29 Relationships Using ID-Dependent Entities: Association Relationships QUOTATION (CompanyName, PartNumber, Price)

30. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-30 Relationships Using ID-Dependent Entities: Multivalued Attributes As a data model As a set of tables

31. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-31 Relationships Using ID-Dependent Entities: Archetype/Instance Pattern As a data model As a set of tables

32. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-32 Relationships Using Weak Entities: Archetype/Instance Pattern As a data model As a set of tables

33. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-33 Mixed Entity Relationships: The Line-Item Pattern As a data model

34. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-34 Mixed Entity Relationships: The Line-Item Pattern As a set of tables

35. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-35 Mixed-Entity Relationships As a data model As a set of tables

36. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-36 Subtype Relationships As a data model As a set of tables

37. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-37 Recursive Relationships: 1:1 Recursive Relationships As a data model As a table

38. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-38 Recursive Relationships: 1:N Recursive Relationships As a data model As a table

39. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-39 Recursive Relationships: N:M Recursive Relationships As a data model As a set of tables

40. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-40 Representing Ternary and Higher- Order Relationships Ternary and higher-order relationships may be constrained by the binary relationship that comprise them: –MUST constraint - Requires that one entity must be combined with another entity in the ternary (or higher- order) relationship –MUST NOT constraint - Requires that certain combinations of two entities are not allowed to occur in the ternary (or higher-order) relationship –MUST COVER constraint – A binary relationship specifies all combinations of two entities that must appear in the ternary (or higher-order) relationship

41. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-41 MUST Constraint

42. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-42 MUST NOT Constraint

43. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-43 MUST COVER Constraint

44. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-44 HighLine University

45. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-45 HighLine University

46. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-46 Design for Minimum Cardinality 4 possibilities –O-O FK = null allowed Do nothing! –O-M –M-O –M-M

47. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-47 When Parent =M

48. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-48 When Child = M

49. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-49 Actions to apply

50. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-50 Minimum Cardinality

51. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-51 Minimum Cardinality

52. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-52 View Ridge

53. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-53 View Ridge

54. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-54 View Ridge

55. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-55 View Ridge

56. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-56 David M. Kroenke’s Database Processing Fundamentals, Design, and Implementation (10 th Edition) End of Presentation: Chapter Six Part Two