1. Database Lecture Notes Mapping ER Diagrams to Tables 2 Dr. Meg Murray mcmurray@kennesaw.edu

2. Mapping Relationships What are the 2 categories of relationships?

3. Mapping Strong Entity Relationships

4. Representing Relationships 1:1 Relationships The maximum cardinality determines how a relationship is represented 1:1 relationship –The key from one relation is placed in the other as a foreign key –It does not matter which table receives the foreign key usually –Should be placed in the most frequently accessed entity –If one side is optional, Foreign Key goes on the OPTIONAL side KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

5. Representing Relationships 1:1 Relationship Example KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

6. Create Relationships: 1:1 Notes Either design will work – no parent, no child Minimum cardinality considerations may be important: –O-M will require a different design than M-O –One design is often preferable –THE FOREIGN KEY SHOULD BE PLACED IN THE OPTIONAL SIDE Make the foreign key an alternate key KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

7. Representing Relationships 1:N Relationships Like a 1:1 relationship, a 1:N relationship is saved by placing the key from one table into another as a foreign key However, in a 1:N the foreign key always goes into the many-side of the relationship –The 1 side is called the parent –The N side is called the child KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

8. Representing Relationships 1:N Relationship Example KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

9. 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 KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

10. Create Relationships: N:M Strong Entity Relationships N:M strong entity will always be mapped to two 1:N relationships –This table is called an intersection table The key of the intersection table is a composite key of both primary keys from the related entities –Each table’s primary key becomes a foreign key linking back to that table KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

11. Create Relationships: N:M Strong Entity Relationships COMPANY_PART_INT (CompanyName, PartNumber) KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

12. Representing Relationships N :M Relationship Example 2 KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

13. Mapping Weak Entity Relationships

14. Representing Weak Entities ID-dependent –must add primary key of the parent entity Not ID-dependent –use the same techniques as for strong entities KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

15. Four Relationships for Weak Entities Representing N:M Relationships –We just discussed this Association Relationships Multivalued Attributes Archtype/Instance Relationships KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

16. ID-Dependent ID-dependent –The primary key of the strong entity becomes part of the composite primary key of the weak entity –Except in cases of surrogate keys, N:M, Association relationships and Multivalued Attributes map to ID-dependent relationships

17. Representing Weak Entities – ID-dependent Example KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

18. 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 KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

19. Representing Relationships Association Relationships When an intersection table has columns beyond those in the primary key, the relationship is called an association relationship KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

20. ID-Dependent Association Relationship Example 2 QUOTATION (CompanyName, PartNumber, Price) KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

21. Relationships Using ID-Dependent Entities: Multivalued Attributes As a data model As a set of tables KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

22. Relationships Using ID-Dependent Entities: Archetype/Instance Pattern As a data model As a set of tables KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

23. Representing Weak Entities Non ID-dependent Not ID-dependent –The primary key of the strong entity is placed as an attribute [foreign key] in the weak entity Not used in the primary key Special case for surrogate keys –An alternate key in the strong entity is placed as an attribute [foreign key] in the weak entity

24. Relationships Using Weak Entities: Non ID-dependent As a data model As a set of tables Note where the Foreign Key is placed – not part of the primary key KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

25. Note when using Surrogate Keys Surrogate keys in an ID-dependent relationship take special consideration because the surrogate key has no ‘human’ meaning One way to handle this is to put the identifier of the parent as a foreign key in the child BUT NOT as part of the primary key –Use a surrogate key for the child as well –This means you will have a Weak relationship but not an ID dependent one KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

26. Entities: Tables with Surrogate Key: CUSTOMER Example Surrogate Keys -CustomerID (id) -FirstName -LastName -Street -City -State -Zip CUSTOMER -PhoneNumber(id) -Customer(id) -PhoneType PHONES SurrogateKey CustomerID FirstName LastName Street City State Zip PHONES -PhoneNumber -PhoneType -Customer(FK)

27. Other Examples 6-27

28. Representing Relationships Supertype/Subtype Relationships The identifier of the supertype becomes the primary key and the foreign key of each subtype Note the supertype and subtypes all have the same primary key KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

29. Subtype Relationships Example 2 As a data model As a set of tables KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

30. Representing Relationships Recursive Relationships A recursive relationship is a relationship that a relation has with itself. Recursive relationships adhere to the same rules as the binary relationships. –1:1 and 1:M relationships are saved using foreign keys –M:N relationships are saved by creating an intersecting relation KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

31. Recursive Relationships: 1:1 Recursive Relationships As a data model As a table KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

32. Recursive Relationships: 1:N Recursive Relationships As a data model As a table KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

33. Recursive Relationships: N:M Recursive Relationships As a data model As a set of tables KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

34. Mixed Entity Relationships: The Line-Item Pattern Common Sales Order {shopping cart} Problem –Create a separate table to represent each line for each item ordered

35. Mixed Entity Relationships: The Line-Item Pattern As a data model KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

36. Mixed Entity Relationships: The Line-Item Pattern As a set of tables KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

37. Heather Sweeney Designs: Developing a Database Design Heather Sweeney Designs will be used as on ongoing example throughout Chapters 4, 5, 6 and 7. –Heather Sweeney is an interior designer who specializes in home kitchen design –She offers a variety of free seminars at home shows, kitchen and appliance stores, and other public locations –She earns revenue by selling books and videos that instruct people on kitchen design –She also offers custom-design consulting services KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

38. Heather Sweeney Designs: Final Data Model KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

39. Heather Sweeney Designs: Database Design KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall

40. Heather Sweeney Designs: Database Design Schema SEMINAR (SeminarID, Date, Time, Location, Title) CUSTOMER (EmailAddress, Name, Phone, Street, City, State, Zip) SEMINAR_CUSTOMER (SeminarID, EmailAddress) CONTACT (EmailAddress, Date, ContactNumber, ContactType, SeminarID) PRODUCT (ProductNumber, Description, UnitPrice, QuantityOnHand) INVOICE (InvoiceNumber, Date, PaymentType, SubTotal, Tax, Total, EmailAddress) LINE_ITEM (InvoiceNumber, LineNumber, Quantity, UnitPrice, Total, ProductNumber) KROENKE and AUER - DATABASE CONCEPTS (3 rd Edition) © 2008 Pearson Prentice Hall