database lecture notes mapping er diagrams to tables 2 dr. meg murray [email protected]

DatabaseLecture NotesMapping ER Diagrams to Tables 2

Dr. Meg Murray

[email protected]

Mapping Relationships

• What are the 2 categories of relationships?

Mapping Strong Entity Relationships

Representing Relationships1: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 (3rd Edition)© 2008 Pearson Prentice Hall

Representing Relationships1:1 Relationship Example


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


Representing Relationships1: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


Representing Relationships1:N Relationship Example


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


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


Create Relationships:N:M Strong Entity Relationships

COMPANY_PART_INT (CompanyName, PartNumber)


Representing RelationshipsN:M Relationship Example 2


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


Four Relationships for Weak Entities

• Representing N:M Relationships– We just discussed this

• Association Relationships

• Multivalued Attributes

• Archtype/Instance Relationships


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


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


Representing RelationshipsAssociation Relationships

• When an intersection table has columns beyond those in the primary key, the relationship is called an association relationship


ID-Dependent Association Relationship Example 2

QUOTATION (CompanyName, PartNumber, Price)


Relationships Using ID-Dependent Entities:Multivalued Attributes

As a data

model

As a set of tables


Relationships Using ID-Dependent Entities:Archetype/Instance Pattern

As a data

model

As a set of tables


Representing Weak EntitiesNon 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


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


Entities:Tables with Surrogate Key:

CUSTOMER

Example Surrogate Keys

-CustomerID (id) -FirstName-LastName-Street-City-State-Zip

CUSTOMER

-PhoneNumber(id)-Customer(id) -PhoneType

PHONES

SurrogateKeyCustomerIDFirstNameLastNameStreetCityStateZip

PHONES

-PhoneNumber-PhoneType-Customer(FK)

Other Examples

6-27

Representing RelationshipsSupertype/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


Subtype RelationshipsExample 2

As a data

model

As a set of tables


Representing RelationshipsRecursive 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


Recursive Relationships:1:1 Recursive Relationships

As a data

model

As a table


Recursive Relationships:1:N Recursive Relationships

As a data

model

As a table


Recursive Relationships:N:M Recursive Relationships

As a data

model

As a set of tables


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


As a data

model



As a set of tables


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


Heather Sweeney Designs:Final Data Model


Heather Sweeney Designs:Database Design


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)


database lecture notes mapping er diagrams to tables 2 dr. meg murray [email protected]

Documents

representing relationships

mapping relationships

strong entity relationships

foreign key

categories of relationships

pearson prentice hall

auer database concepts

rd edition