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(Ei) 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 for attributes on the

primary key for E2,
entity E1 relationship type 9
is now a foreign key to E2
(if any)
 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 the

primary key for E2,
is now a foreign key to E1; relationship type12
is now a foreign key
also the PK for this relation (if any)
to E2
 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 many:many
TUTOR(studno, staffname, rommno, slot) relationship types!
and
Foreign key TUTOR(studno) references STUDENT(studno)
Foreign key TUTOR(staffname, roomno) references
STAFF(name, roomno)
13
 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 must A school entity instance
participate in a relationship need not participate in a
instance of 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 because
s1 fred jones ca it is mandatory for a student to
s2 mary brown cis be registered for a school
s3 sue smith cs
s4 fred bloggs ca Î “not null” constraint
s5 peter jones cs
s6 jill peters ca

SCHOOL
hons faculty No student is registered for “mi”,
ac accountancy so “mi” doesn’t occur
is information systems as a foreign key value
cs computer science (but that’s no problem)
ce computer science
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 instance A staff entity instance must

need not participate in a participate in a relationship
relationship instance of instance 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 zobel 2.34 13B watson IT212
s6 jill peters kahn IT206 12A woods IT204
capon A14
lindsey 2.10
barringer 2.125

19
 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

20
 Mapping One:one Relationship Types
to Relations
• Post the primary key YEAR
year
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
Which constraint capon A14 3
lindsey 2.10 NULL
holds in this case? barringer 2.125 NULL21
 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 22
s2 Billy-Jo Woods
Mapping Roles and Recursive Relationships

name
STAFF

roomno

appraiser appraisee

APPRAISAL
APPRAISAL

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

STAFF(name, roomno, appraiser, approomno )

23
 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( ??? )
24
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( ??? ) 25
 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
26
 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 identifying Discriminators of identifying Attributes of the

strong entity type weak entity types weak entity type

c-name
CUSTOMER
address
1

CUST-ORDER

m orderid

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

given family
courseno
equip
name

m studno
STUDENT COURSE

1 subject 1

m m
STUD_ENROL ENROL COURSE_ENROL

labmark exammark

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

given family
courseno
equip
name

m studno
STUDENT COURSE

1 subject 1

m m
STUD_ENROL ENROL COURSE_ENROL

labmark exammark

Then:
• ENROL(courseno, studno, labmark, exammark)
29
 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 ENROL(studno, courseno,
1
labmark,exammark)
labmark YEAR

ENROL
1 COURSE(courseno, subject, equip)
TUTOR

YEARTUTOR
exammark
slot STAFF(lecturer,roomno,
1 1
appraiser, approom)
name
n n STAFF
courseno
m
TEACH(courseno, lecturer,lecroom )
TEACH 1 m roomno
COURSE

subject
YEAR(year, yeartutor, yeartutorroom)
appraisee
appraiser

equip APPRAISAL SCHOOL(hons, faculty)

30
 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.

31
 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.

32
 Translating of Hierarchies: Options
To store information about these classes, given family
We have to define appropriate relations.
name

For each relation, we have to define: m studno

STUDENT
• set of attributes
• primary key
d
In principle, there are thesis title

∩
∩
year
three options:
UNDERGRADUATE POSTGRADUATE

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
33
 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)
i=1
d
thesis title

∩
∩
Disjointness constraint: year

πkey(subclassi) ∩ πkey(subclassj) = ∅
UNDERGRADUATE POSTGRADUATE
34
for i ≠ j
 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 total and given family

disjoint
name
• Partial coverage: entities that are
m studno
not in a subclass are lost STUDENT

• Overlapping classes: redundancy

• Recovery of the superclass: d
OUTER UNION on the subclass thesis title

∩
∩
year
relations
Codd: union that extends the UNDERGRADUATE POSTGRADUATE
35
schema to all common attributes
 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-applicable’ name

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

∩
∩
• Overlapping coverage: class year
has to represent a set of classes
• Partial coverage: class is null UNDERGRADUATE POSTGRADUATE
36
∴ entity is from superclass
 Applying the Three Translations
(Overlapping Coverage)
A. STAFF(payrollno, name, lengthOfService)
ACADEMIC(payrollno, level)
payroll no TECHNICAL(payrollno, project)
name
ADMIN(payrollno, grade)
STAFF

length of service B. ACADEMIC(payrollno, name, lengthOfService,

level)
o TECHNICAL(payrollno, name, lengthOfService,
∩ ∩ project)
ADMIN(payrollno, name, lengthOfService, grade)
level ∩ grade
C. STAFF(payrollno, name, lengthOfService, level,
project, grade, class1, class2, class3)
ACADEMIC TECHNICAL ADMIN
ADMIN or

project STAFF(payrollno, name, lengthOfService, level,

project, grade, class)
37
class = powerset of classes
 Specialisation Lattice with Shared Subclass
payroll no
Staff
∩ d
no_hours

∩
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?
38
• 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)

39