Database Lecture Notes Mapping ER Diagrams to Tables 2 Dr. Meg Murray

Mapping Relationships What are the 2 categories of relationships?

Mapping Strong Entity Relationships

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

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

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

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

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

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

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

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

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

Mapping Weak Entity Relationships

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

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

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

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

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

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

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

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

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

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

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

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

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)

Other Examples 6-27

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

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

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

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

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

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

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

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

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

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

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

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

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