Introduction to

Database Systems

Mapping ER Models to
Relational Schemas

Werner Nutt

1
 Conceptual and Logical Design

name

Conceptual Model: PRODUCT BUYS PERSON

price name ssn

Relational Model:

2
 Mapping an E-R Diagram to a
Relational Schema
We cannot store date in an ER schema
(there are no ER database management systems)

 We have to translate our ER schema

into a relational schema

 What does “translation” mean?

3
 Translation: Principles
• Maps
– ER schemas to relational schemas
– ER instances to relational instances

• Ideally, the mapping should

– be one-to-one in both directions
– not lose any information

• Difficulties:
– what to do with ER-instances that have identical
attribute values, but consist of different entities?
– in which way do we want to preserve information?

4
 Mapping Entity Types to
Relations
• For every entity type create a relation
• Every atomic attribute of the entity type becomes a relation attribute
• Composite attributes: include all the atomic attributes
• Derived attributes are not included
(but remember their derivation rules)
• Relation instances are subsets of the cross product
of the domains of the attributes
• Attributes of the entity key make up the primary key of the relation

given family
courseno
no. of
students equip
name

STUDENT COURSE

studno subject
5
 Mapping Entity Types to Relations
(cntd.)

given family
courseno
no. of
students equip
name

STUDENT COURSE

studno subject

STUDENT (studno, givenname, familyname)

COURSE (courseno, subject, equip)

6
 Mapping Many:many Relationship
Types
to Relations
Create a relation with the following set of
attributes:
N (degree of relationship)

U primary_key(E ) i U {a1,…,aM}
i=1
primary keys of each
entity type participating attributes of the
in the relationship relationship type (if any)

given family
courseno
no. of
name labmark students equip

STUDENT ENROLLED COURSE

studno exammark subject

7
Mapping Many:many Relationship
Types
to Relations (cntd.)
given family
courseno
no. of
name labmark students equip

STUDENT ENROLLED COURSE

studno exammark subject

ENROL(studno, courseno, labmark, exammark)

Foreign Key ENROL(studno) references STUDENT(studno)

Foreign Key ENROL(courseno) references COURSE(courseno)

8
Mapping Many:one Relationship Types to
Relations
given family name
slot
roomno
studno name
m 1
STUDENT TUTOR STAFF

Idea: “Post the primary key”

• Given E1 at the ‘many’ end of relationship and E2 at the ‘one’ end
of the relationship, add information to the relation for E1
• The primary key of the entity at the ‘one’ end (the determined entity)
becomes a foreign key in the entity at the ‘many’ end (the determining
entity). Include any relationship attributes with the foreign key entity

E1 U primary_key(E2) U {a1,…,an}

relation attributes on
primary key for E2,
for entity the 9
is now a foreign key to
E1 relationship
E2
 Mapping Many:one Relationship
Types
to Relations: Example
given family name
slot
roomno
studno name
m 1
STUDENT TUTOR STAFF

The relation
STUDENT(studno, givenname, familyname)
is extended to
STUDENT(studno, givenname, familyname, tutor, roomno, slot)
and the constraint
Foreign Key STUDENT(tutor,roomno) references STAFF(name,roomno)
10
 Mapping Many:one Relationship
Types
to Relations (cntd.)

STUDENT STAFF
studno given family tutor roomno slot name roomno
s1 fred jones bush 2.26 12B kahn IT206
s2 mary brown kahn IT206 12B bush 2.26
s3 sue smith goble 2.82 10A goble 2.82
s4 fred bloggs goble 2.82 11A zobel 2.34
s5 peter jones zobel 2.34 13B watson IT212
s6 jill peters kahn IT206 12A woods IT204
capon A14
lindsey 2.10
barringer 2.125

11
 Mapping Many:one Relationship
Types
to Relations (cntd.)
given family name
slot
roomno
studno name
m 1
STUDENT TUTOR STAFF

Another Idea: If
• the relationship type is optional to both entity types, and
• an instance of the relationship is rare, and
• there are many attributes on the relationship then…
… create a new relation with the set of attributes:

primary_key(E1) U primary_key(E2) U {a1,…,am}

primary key for E1, attributes on

primary key for
is now a foreign key to E1; E2, is now a the 12
also the PK for this relationship
foreign key to
 Mapping Many:one Relationship Types
to Relations (cntd.)

given family name

slot
roomno
studno name
m 1
STUDENT TUTOR STAFF

Compare with the

mapping of
TUTOR(studno, staffname, rommno, slot) many:many
relationship types!
and
Foreign key TUTOR(studno) references STUDENT(studno)
Foreign key TUTOR(staffname, roomno) references
13
STAFF(name, roomno)
 Mapping Many:one Relationship Types
to Relations (cntd.)
STUDENT STAFF
studno given family name roomno
s1 fred jones kahn IT206
s2 mary brown bush 2.26
s3 sue smith goble 2.82
s4 fred bloggs zobel 2.34
s5 peter jones watson IT212
s6 jill peters woods IT204
capon A14
TUTOR lindsey 2.10
studno tutor roomno slot barringer 2.125
s1 bush 2.26 12B
s2 kahn IT206 12B
s3 goble 2.82 10A
s4 goble 2.82 11A
s5 zobel 2.34 13B
s6 kahn IT206 12A 14
 Optional Participation of
the Determined Entity (‘one end’)
A student entity instance A school entity instance
must participate in a
relationship instance of need not participate in a
REG relationship instance of
REG
given family
hons faculty
studno name

1
STUDENT REG SCHOOL

SCHOOL (hons, faculty)

STUDENT (studno, givenname,
familyname, ??? ) 15
 Optional Participation of the
Determined Entity
STUDENT
studno given family hons “hons” cannot be NULL
s1 fred jones ca because it is mandatory
s2 mary brown cis for a student to be
s3 sue smith cs registered for a school
s4 fred bloggs ca
s5 peter jones cs  “not null” constraint
s6 jill peters ca

SCHOOL
hons faculty No student is registered for
ac accountancy “mi”, so “mi” doesn’t occur
is information systems as a foreign key value
cs computer science (but that’s no
ce computer science problem)
mi medicine
16
ma mathematics
 Optional Participation of the
Determinant Entity (‘many end’)

given family name

slot
roomno
studno name
m 1
STUDENT TUTOR STAFF

A student entity A staff entity instance

instance must participate in a
need not participate in a relationship instance
relationship instance of of TUTOR
TUTOR

17
 Optional Participation of the
Determinant Entity
1. STUDENT (studno, givenname, familyname, tutor, roomno, slot)
STAFF(name, roomno)

Integrity constraint:

name,roomno STAFF \ tutor,roomno STUDENT = 

2. STUDENT(studno, givenname, familyname)

STAFF(name, roomno)
TUTOR(studno, tutor, roomno, slot)

Do we also need an integrity constraint? 18

 Optional Participation of the
Determinant Entity (cntd.)

STUDENT STAFF
studno given family tutor roomno slot name roomno
s1 fred jones bush 2.26 12B kahn IT206
s2 mary brown kahn IT206 12B bush 2.26
s3 sue smith goble 2.82 10A goble 2.82
s4 fred bloggs goble 2.82 11A zobel 2.34
s5 peter jones NULL NULL NULL watson IT212
s6 jill peters kahn IT206 12A woods IT204
capon A14
lindsey 2.10
barringer 2.125

19
Mapping One:one Relationship Types

to Relations
• Post the primary key YEAR
yea
r of one of the entity year yeartutor
YEAR types into the other 1 zobel
entity type as a 2 bush
1
foreign key, including 3 capon
YEARTUTOR any relationship
attributes with it STAFF
1
name
STAFF
name roomno year
or kahn IT206 NULL
roomno
bush 2.26 2
• Merge the entity goble 2.82 NULL
zobel 2.34 1
types together watson IT212 NULL
woods IT204 NULL
capon A14 3
Which constraint lindsey 2.10 NULL
holds in this case? barringer 2.125 NULL20
 Multi-Valued Attributes
For each multi-valued attribute of Ei, create a relation with
the attributes

primary_key(Ei) U multi-valued attribute

The primary key comprises all attributes

STUDENT
studno given family
given family s1 fred jones
s2 mary brown
studno name

STUDENT
STUDENT_CONTACT
studno contact
s1 Mr. Jones
contact s1 Mrs Jones
s2 Bill Brown
s2 Mrs Jones 21
s2 Billy-Jo Woods
 Mapping Roles and Recursive
Relationships

name
STAFF

roomno

appraiser appraise
e

APPRAISAL
APPRAISAL

How can the entity STAFF appear in both of its roles ?

STAFF(name, roomno,
appraiser, approomno )
22
 Multiple Relationships between
Entity Types
1. Treat each relationship type separately
2. Represent distinct relationships by different foreign keys
drawing on the same relation
given family
name
1 SUPERVISE m name
studno

STAFF STUDENT

1 m
EXAMINE
roomno

STAFF(name, roomno)

STUDENT(studno, given, family, ??? )

STUDENT(studno, given, family, ??? )

EXAMINER( ??? )
SUPERVISOR( ??? )
23
EXAMINER-SUPERVISOR( ??? )
 Non-binary Relationship
roomno
STAFF
STAFF
name
p
given family courseno
equip
name TUTORS
m n
COURSE
STUDENT
slot
subject
studno

COURSE(courseno, subject, equip)

STUDENT(studno, givenname, familyname)
STAFF(staffname, roomno)
TUTORS( ??? ) 24
 Weak Entities
• Strong entity type c-name
• Identifying entity for CUSTOMER
ORDER address
1
• Identifying entity for
LINE_ITEM CUST-ORDER

m orderid
• Weak entity type
• Identifying entity for ORDER
LINE_ITEM date
1

ORDER-MAKEUP

m
lineno
• Weak entity type LINE_
ITEM quantity
25
 Mapping Weak Entities to
Relations
Create a relation with the attributes:
n
primary_key(E0) U U discriminator(Ei) U {a1,…,an}
i=1
Primary key of Discriminators of Attributes of the
identifying identifying weak weak entity
strong entity type entity types type
c-name
CUSTOMER
address
1

CUST-ORDER

m orderid

ORDER
26
date
 Association Entity Types
An entity type that represents a relationship
type:

given family
courseno
equip
name

m studno
STUDENT COURSE

1 subje 1
ct
m m
STUD_ENROL ENROL COURSE_ENROL

labmark exammark

27
 Association Entity Types
We have:
• COURSE(courseno, subject, equip)
• STUDENT(studno, givenname, familyname)

given family
courseno
equip
name

m studno
STUDENT COURSE

1 subje 1
ct
m m
STUD_ENROL ENROL COURSE_ENROL

labmark exammark

Then:
• ENROL(courseno, studno, labmark, exammark) 28
 Translation of the University
Diagram
given family 1 STUDENT
SCHOOL
(studno, givenname,
studno name REG
hons familyname, hons,
faculty
STUDENT
tutor, tutorroom, slot,
year
year)
m YEARREG
1
ENROL(studno, courseno,
labmark YEAR
labmark,exammark)
1
ENROL TUTOR
COURSE(courseno, subject,
YEARTUTOR
exammark
slot equip)
1 1
name STAFF(lecturer,roomno,
courseno
n
m
n STAFF appraiser,
COURSE
TEACH 1 m roomno approom)
subject appraisee
appraiser TEACH(courseno,
equip APPRAISAL
lecturer,lecroom )

YEAR(year, yeartutor,
29
yeartutorroom)
 Exercise: Supervision of PhD Students
A database needs to be developed that keeps track of PhD students:

• For each student store the name and matriculation number.

Matriculation numbers are unique.

• Each student has exactly one address. An address consists of street,

town and post code, and is uniquely identified by this information.

• For each lecturer store the name, staff ID and office number. Staff
ID's are unique.

• Each student has exactly one supervisor. A staff member may

supervise a number of students.

• The date when supervision began also needs to be stored.

30
 Exercise: Supervision of PhD Students
• For each research topic store the title and a short description. Titles
are unique.

• Each student can be supervised in only one research topic, though

topics that are currently not assigned also need to be stored in the
database.

Tasks:

a) Design an entity relationship diagram that covers the requirements

above. Do not forget to include cardinality and participation
constraints.

b) Based on the ER-diagram from above, develop a relational database

schema. List tables with their attributes. Identify keys and foreign
keys.
31
 Translating of Hierarchies: Options
To store information about these given family
classes,
name
We have to define appropriate
relations. m studno
STUDENT

For each relation, we have to

define:
• set of attributes d
thesis title
• primary key



year

In principle, there are UNDERGRADUATE POSTGRADUATE

three options:
A. Create a relation for each entity type in the schema,
i.e., for both, superclass and subclasses
B. Create only relations for subclasses
C. Create only one relation, for the superclass
32
 Translation into Relations: Option A
1. Create a relation for the superclass
2. For each subclass, create a relation over the set of attributes
primary_key(superclass) U attributes of subclass
The key for each subclass relation is:
primary_key(superclass)
Inclusion constraint (foreign keys):
given family
key(superclass) key(subclassi)
name

Covering constraint ( n = number of subclasses): m studno

STUDENT
n
U key(subclassi) 
key(superclass) d
i=1 thesis title



year

Disjointness constraint:
UNDERGRADUATE POSTGRADUATE
33
key(subclassi)  key(subclassj) =
 Translation into Relations: Option B
Create only relations for subclasses. Each subclass becomes a
relation over the set of attributes:
attributes of superclass U attributes of subclass
The key for each subclass relation is: primary_key(superclass)

• Works only if coverage is given family

total and
name
disjoint
m studno
• Partial coverage: entities STUDENT

that are
not in a subclass are lost
• Overlapping classes: d
thesis title



redundancy year

• Recovery of the superclass:

Codd: union that extends the UNDERGRADUATE POSTGRADUATE
OUTER UNION on the 34
schema to all common attributes
subclass
 Translation into Relations: Option C
Create a single relation over the set of attributes
n
attributes of superclass U  attributes of subclassi U { class }
i=1

The key is: primary_key(superclass)

given family

• Drawback: many ‘not- name

applicable’ m studno
STUDENT
nulls
• Benefit: No need for joins
• Disjoint coverage: one
attribute d
thesis title
class which indicates the



year
subclass the tuple
represents UNDERGRADUATE POSTGRADUATE
35
• Overlapping coverage: class
 Applying the Three Translations
(Overlapping Coverage)
A. STAFF(payrollno, name,
lengthOfService)
payroll no ACADEMIC(payrollno, level)
name TECHNICAL(payrollno, project)
STAFF
ADMIN(payrollno, grade)
length of service
B. ACADEMIC(payrollno, name,
lengthOfService,
o
  level)
level  TECHNICAL(payrollno, name,
grade lengthOfService,

project)
ACADEMIC TECHNICAL ADMIN
ADMIN ADMIN(payrollno, name,
lengthOfService, grade)
project
C. STAFF(payrollno, name,
lengthOfService, level,
36
project, grade, class1,
class2, class3)
 Specialisation Lattice with Shared
Subclass
payroll no
Staff
 no_hours
d


dept
d task 
title Manager
 Hourly Staff

 salary


Academic Technical Admin Salaried Staff
 phone


expertise

Admin Manager

Exercise: For each of the approaches A, B, C, decide

• Which tables need to be created?
37
• Which are the attributes? And which are their possible values?
 References
In preparing these slides I have used several sources.
The main ones are the following:

Books:
• A First Course in Database Systems, by J. Ullman and J. Widom
• Fundamentals of Database Systems, by R. Elmasri and S. Navathe

Slides from Database courses held by the following people:

• Enrico Franconi (Free University of Bozen-Bolzano)
• Carol Goble and Ian Horrocks (University of Manchester)

38