Mapping ERM to relational

database

Mapping the ER model to the relational model

Logical Database Design

Reading:
e.g. Connolly/Begg DB systems: (4th ed) Ch 16 – step 2.2
and/or (3rd ed) Ch 15.1
1
 BookTitle BookCopy
Reader
ISBN {PK} Has copyID {PPK} Borrows
readerNo {PK}
author [1..*] 1 1..20 loanType 0..* 0..*
name
title purchaseDate
firstName
mainTitle shelf dateOut
lastName
subTitle returnDate
address
publisher \dueDate
year \fine

 What does this ERM model?

 Work with your friends and identify:
– Entities (strong, weak)
– Attributes (simple, composite, derived, multi-valued)
– Relationships (cardinality, participation, attributes)
 Mapping the conceptual model

 Step-by-step “cookbook recipe”

 Details how to create a logical (relational)
model from a conceptual (ERM) model
 Main ideas:
– Entity with attributes  Relation with fields
– Relationship  Foreign key

 Let’s start with the steps we need for the books example

3
 Steps Summary (from Connolly/Begg)

1. Strong entities
2. Weak entities
3. Binary 1:* relationships
4. Binary 1:1 relationships
5. Recursive 1:1 relationships
6. Super- and subclasses
7. Binary *:* relationships
8. Complex relationships
9. Multi-valued attributes

4
 Steps 1&2: Entities

 For each entity type create a relation

– include all simple attributes
– include composite attributes:
 usually use one field per component,
 or single field
– Leave out multi-valued attributes
– Strong entity: Choose a primary key
– Weak entity: will get its primary key later

 Now apply this to the books example

5
 Mapping binary relationships

 Identify one entity as “parent”

 other entity as “child”
 as general rule,
PK of parent is added to child as FK
 Any attributes of the relationship
– are added to child relation

6
 Step 3: (1:*) Relationships

 Relation at “1” end is parent

 Relation at “many” end is child
 include parent's PK in child as foreign key.
 Any attributes of the relationship are added to
child
 Apply this to the (1:*) relationships in the books
example now
 Note: for recursive (1:*) relationships, use same rule.
Add primary key of the relation a second time as
foreign key
7
 Step 7: (*:*) relationships

 For each binary many-to-many relationship

type create a new relation.
 Add PKs of both “parents” to the new relation (as FKs)
and also any attributes of the relationship.
 PK of the new relation is usually composite: simply
combine both FKs. If this is not unique, include additional
fields as needed
 Apply this to the (1:*) relationships in the books
example now

 Note: Apply same method for unary *:*: create a new table, with
two foreign keys both linking to the original PKs
8
 Step 9: Multi-valued attributes

For each multi-valued attribute:

 create a new relation that contains
– the attribute itself, plus
– the primary key of the “parent” entity as foreign key.
 The primary key of the new relation is usually made up
of all its attributes.
– Sometimes, not all attributes may be needed

 Apply this to the books ERM now

9
 Step 4: Binary (1:1)

Three options, depending on participation

 Option A (mandatory participation on both
sides):
– Merge both entities into a single entity
– choose either of the original PKs as the new PK
– include any attributes of the relationship

 Option B (mandatory participation on one side):

– relation with optional participation is parent
– Relation with mandatory participation is child
– add PK of parent to child as FK.
10 – add any attribute of the relationship to child
 Step 4: Binary (1:1)

 Option C (optional participation on both sides)

– Arbitrarily choose one entity as child, the other as
parent
– proceed as usual - add PK of parent to child as FK;
also add any attributes of the relationship
– also use this option if mandatory participation on
both sides and want to keep separate relations
– If one entity is close to mandatory participation,
choose that one as child.

11
 Step 4 Example

Manager Branch
managerID {PK} 1..1 Manages 0..1 bName {PK}
name address
salary phone
• “Each branch has one manager, each manager may
manage a branch (but those at head office don’t)”

How would you map this?

12
 Step 5: Unary (Recursive) 1:1

 Follow Step 4 in principle, but same entity on

both sides of relationship
 Mandatory participation both sides
– keep single relation
– add new attribute - “copy” of PK, to act as FK
 Optional on both sides
– create a new relation with just two copies of PK.
They act as composite PK and separately as FKs to
link back to entity
 Optional one side
13 – follow either of the two methods above.
 Step 5 example

1..1
Supervises “Each staff member
Staff has one supervisor
ID {PK} 0..1 and may supervise
name one staff member”
department

One relation: Staff(ID, supervisorID*, name, department)

Or
Two relations: Staff(ID, name, department)
Supervision(staffID*, supervisorID*)
14
 Directed Reading
 Connolly/Begg “Database Systems”
– (4th ed) Ch 16 – step 2.2 or (3rd ed) Ch 15.1
– Ignore “Step 6” (super- and sub-classes) for now
or
 Connolly/Begg “Database Solutions”
– Chapter 10 – step 2.1

*****************************************************************
Note that if you read any other database textbook or access any websites you may
see other descriptions of the mapping “recipe”. They all do the same thing! We use
the numbering of Connolly and Begg DB Systems. DB solutions uses the same
method but no numbering.
*****************************************************************

15
 What about unary (recursive) relationships?

 Textbooks usually discuss recursive 1:1

relationships explicitly
 Often don't mention 1:* or *:* recursive
relationships
 Essentially, treat all recursive relationships like
the equivalent binary ones, except the entities
at both ends are one and the same.

16
 Summary
 Follow 9 Step procedure
– should result in a “good” relational model,
i.e. at least in 3rd Normal Form
– Be careful!!!
– Remember to identify Primary Keys
 For relationships:
– Identify one relation as “parent”, one as “child”
– post parent’s PK to child as FK

17
 Summary ctd.

 In the relational model,

– entities are represented as relations
– simple attributes are represented as fields
 multi-valued attributes represented as a relation
 derived attributes are not usually stored
 Composite attributes are usually split into several fields
– relationships are represented indirectly through
the use of foreign keys
 1:1 relationship  foreign key or single relation
 1:* relationship  foreign key in “child”
 *:* relationship  relation and two foreign keys

18