Enhanced Entity Relationship

Modeling

2001 Irwin Levinstein

©

Basic concept:
Subset/Superset
• Examples:
– Some Employees are Hourly
– Some Employees are Managers
– All Employees are either technical,
clerical, or managerial
– All employees are either Hourly or
Salaried

2001 Irwin Levinstein

©

1
 Why is this Important?
• Subsets may have different
attributes:
– tech employee has SPECIALTY
– Hourly employee has OVERTIME
• Subsets may participate in different
relationships:
– managerial employee manages unit
– hourly employee belongs to a union

2001 Irwin Levinstein

©

MANAGER "IS-A" EMPLOYEE.

All Emps work for
Meaning: EMPLOYEE Departments
Manager ⊂ Employee WORKS
FOR

Department

Bonus
MANAGES

MANAGER But Managers can

also manage them
Mgrs can get bonuses

2001 Irwin Levinstein

©

2
 ISA = Inheritance
• MANAGER gets all attribs of
EMPLOYEE
• can participate in all relations
EMPLOYEE participates in.
• this is called INHERITANCE:
• every MANAGER is also an
EMPLOYEE.
• All of this is idea of "ISA" or
"Superclass/Subclass"
2001 Irwin Levinstein
©

Specialization and Generalization

• Specialization defines SETS of
Subclasses on a Class.
– Each SET called a Specialization
• Generalization unites several entities
into a Set of Sub-Classes, making a
new class.
• Subclasses in a Specialization may be
disjoint or overlap
• Entities in class may be total or
partial members of the specialization
2001 Irwin Levinstein
©

3
 Specializing Employee
EMPLOYEE Single line: some may be
d: employee "none of the above"
cannot be both
clerical and double line: EVERY employee
d
technical. must belong to one

o: can be
both

Clerical Technical Managerial

This set, CLERICAL, TECHNICAL, and

MANAGERIAL, is a SPECIALIZATION of
© EMPLOYEE.
2001 Irwin Levinstein

More than 1 Specialization

EMPLOYEE Partial
Total
Participation Participation

Can
Can’t d o belong to
belong to both
more than
one

Clerical Managerial Hourly

Technical Contractor
2001 Irwin Levinstein
©

4
 Kinds Of Specialization
• Condition (Predicate) defined involves
several attributes
– EX: (Job_type=‘Managerial’ and Salary >
100K ⇒ ‘Upper_Managerial’ subclass)
• Attribute Defined: only one Attribute
involved ⇒ ‘Clerical’ subclass)
– EX: (Job_type in (‘Secretary,
Receptionist, Clerk)
• User Defined
– User places entity in subclass when
entity is created
2001 Irwin Levinstein
©

Generalization
• Build Up Superclass from SubClasses
• Diagram Looks the same as in
Specialization
• Process goes in reverse direction

2001 Irwin Levinstein

©

5
 Generalization
• Ex: Company buys Steel and Paper Mills and
merges Databases
• Attributes of FACTORY: INTERSECTION
of attributes of the Subclasses.
FACTORY

Steel Mill Paper Mill

2001 Irwin Levinstein

©

Specialization Lattice
• Overlapping Specialization
• Specializations of Specializations
• Multiple Inheritance

2001 Irwin Levinstein

©

6
 Lattice Example
• Student graduates and so is Alumnus
• Returns to School and so is a Student
too
• Gets TA position and so is an
Employee

2001 Irwin Levinstein

©

Lattice Person
Example
o

Student Employee Alumnus

GRAD ASST could be

further specialized
into TA and RA

Grad Asst
2001 Irwin Levinstein
©

7
 Converting an EER-Diagram
To a Relational Schema

2001 Irwin Levinstein

©

The Problem 1. Solution must

KEY associate base
A B
attributes with
specialized attributes
BASE for each object
2. Desirable to enforce
d disjoint constraint

C 3. Avoid Nulls
G
D
H
E F

Sub1 Sub2 Sub3

• Base class, 3 subclasses in a specialization.

• How to represent in a DB Schema Diagram.
2001 Irwin Levinstein
©

8
 Solution 1: Super/Sub tables
KEY A B BASE
KEY A B
BASE Join on FK
to get all Sub1
d attribs KEY C D

C G
D Sub2
E F H
KEY E F
Sub1 Sub2 Sub3
Sub3
No way to enforce Disjoint
KEY G H
provision

2001 Irwin Levinstein

©

Solution 2: Subtables only

Need UNION to retrieve Sub1
BASE parts of all objects KEY A B C D

KEY A B Sub2
KEY A B E F
BASE
Sub3
KEY A B G H
d
C G Still cannot enforce
D disjoint requirement
E F H

Sub1 Sub2 Sub3 Only works if

participation mandatory

2001 Irwin Levinstein

©

9
 Solution 3: One big table
BASE
KEY A B KEY A B Type C D E F G H
123 aa bb Sub1 cc dd ∅ ∅ ∅ ∅
BASE
234 a2Type
b2 Sub2
says which ∅ ee each
∅ fields ff row
∅ will
∅
345 a3have
b3 Sub3 ∅ ∅ ∅ ∅ gg hh
d 456 a4 b4 sub2 ∅ ∅ e1 f1 ∅ ∅
C G
Disjoint constraint
D
E F H enforced by PK

Sub1 Sub2 Sub3 LOTS of NULLS (∅)

2001 Irwin Levinstein

©

Summary
• 3 Solutions
– super/sub tables
– subtables only
– one big table
• None is perfect
• Part of reason for development of
Object Relational Databases

2001 Irwin Levinstein

©

10