MAP EER TO

RELATIONAL
Textbook:
8.1-8.2

or 9.1-9.2

Map EER to Relational

Choice A
Map each entity to a

separate schema
Include primary key
for each
Include foreign key
constraints
Staff(ssn, name)
Technician(ssn, skill)
Salesman(ssn, product)

Staff
Name

SSN

Technician

Salesman

Skill

Product

Foreign key constraints

Suppose relation Uses is

mapped into CarUsage

Staff(ssn, name)
Technician(ssn, skill)
Salesman(ssn, product)
CarUsage(rego, ssn)

Staff

Name
Technician

SSN
Salesman
1

Skill
Product

Uses
N

Rego

Car

Notice the FK constraint on relation CarUsage! It says that ssn must

be an actual ssn-value in Salesman. It is not enough for this ssnvalue to be an ssn-value in Staff, because Cars are only related to
Salesman !

Map EER to Relational

Choice B
If Staff is a total
generalization then map
Full-time and Part-time
separately
Include disjointness
constraint

Staff
Name

SSN

Full-time

Part-time

Salary

Schedule

FullTimeStaff(ssn, name, salary)

PartTimeStaff(ssn, name, schedule)

disjointness
constraint

ssns in FullTimeStaff and ssns in PartTimeStaff are disjoint

Map EER to Relational

Choice B
FullTimeStaff(ssn, name, salary)

Staff

Name

PartTimeStaff(ssn, name, schedule) Full-time

ssns in FullTimeStaff and

Salary

SSN
Part-time
Schedule

ssns in PartTimeStaff are disjoint

Advantage: non-redundant storage, all attributes of an entity

are stored in one place

Disadvantage: there is no single relation to retrieve the

identifiers (primary keys) of all Staff. (Basically the notion of

Staff is not represented)

Map EER to Relational

Choice C
If space is not a
problem
Must be disjoint types

Staff
Name

Technician
Skill
Staff(ssn, name, skill, product, jobType)
jobType is one of {Technician, Salesman}

SSN
Salesman
Product

Map EER to Relational

Choice C

Staff

Name
Technician

Skill
Staff(ssn, name, skill, product, jobType)

SSN
Salesman
Product

jobType is one of {Technician, Salesman}

Advantage: one schema for all instances of Staff, Technician

and Salesman

Disadvantage: does not work for overlapping generalizations

(although they are rare); always has null values (non-applicable

attributes)

Map EER to Relational

Choice D
Slight variant of choice C
Works for overlapping
generalizations

Staff
Name

SSN

Manager

Engineer

Level

Grade

Staff(ssn, name, level, grade)

Loses information (e.g. how to interpret that the value
for Level is NULL?); therefore...

Map EER to Relational

Choice D
Therefore...to rectify this
problem we add two
boolean attributes:
isManager and isEngineer

Staff
Name

Manager

SSN
Engineer

Level
Grade
Staff(ssn, name, level, grade, isManager, isEngineer)
Works also for NULL values

Conclusion on mapping EER to Relational

Mapping generalization hierarchies: there are several

strategies; we have studied four

The choice depends on the database population and

usage patterns
We propose that the first mapping choice is the cleanest

one, because it has no redundancy

However, if efficiency dictates, then one of the other three

options may have to be considered