Chapter 4 The Enhanced

Entity-Relationship (EER) Model

Dr. Bernard Chen Ph.D.

University of Central Arkansas
EER Model
 The ER model concepts are sufficient for representing many
database schemas for traditional database applications, which
mainly include data-processing applications in business and
industry.

 However, designers of database applications have tried to

design more accurate database schemas that reflect the data
properties and constrains more precisely

 In this chapter, we describe features that have been proposed

for semantic data models, and show how the ER model can be
enhanced to include these concepts.
Outline
 Subclasses, Superclasses and
Inheritance
 Specialization and Generalization
 Constrains and Characteristics
 Union
Subclasses, Superclasses and
Inheritance
 In many cases an entity type has numerous
subgroupings of its entities that are meaningful and
need to be represented explicitly because of their
significance to the database application.

 For example: EMPLOYEE may be further grouped

into:
 SECRETARY, ENGINEER, TECHNICIAN, …
 Based on the EMPLOYEE’s Job
 MANAGER
 EMPLOYEEs who are managers
 SALARIED_EMPLOYEE, HOURLY_EMPLOYEE
 Based on the EMPLOYEE’s method of pay
Subclasses and Superclasses
Subclasses, Superclasses and
Inheritance
 We call each of these subgroupings a subclass of the
EMPLOYEE entity type, and the EMPLOYEE entity type is called
the superclass for each of these subclasses.

 These are called superclass/subclass (as well as simply

class/subclass) :

 EMPLOYEE/SECRETARY
 EMPLOYEE/TECHNICIAN
 EMPLOYEE/MANAGER
 …

 These are also called IS-A relationships

 SECRETARY IS-A EMPLOYEE, TECHNICIAN IS-A EMPLOYEE, ….
Subclasses, Superclasses and
Inheritance
 An Entity CANNOT exist in the
database merely by being a member of
a subclass; it must also be a member of
the superclass

 A member of the superclass can be

optionally included as a member of any
number of its subclasses
Subclasses and Superclasses
Example
 A salaried employee who is also an engineer
belongs to the two subclasses:
 ENGINEER, and
 SALARIED_EMPLOYEE

 A salaried employee who is also an engineering

manager belongs to the three subclasses:
 MANAGER,
 ENGINEER, and
 SALARIED_EMPLOYEE

 It is not necessary that every entity in a superclass be a

member of some subclass
Subclasses and Superclasses
Subclasses, Superclasses and
Inheritance
 An important concept associated with
subclasses is that of type inheritance

 An entity that is member of a subclass

inherits
 All attributes of the entity as a member of the
superclass
 All relationships of the entity as a member of the
superclass
Subclasses, Superclasses and
Inheritance
 Example:
 In the previous slide, SECRETARY (as well
as TECHNICIAN and ENGINEER) inherit the
attributes Name, SSN, …, from EMPLOYEE
 Every SECRETARY entity will have values
for the inherited attributes
 Every SECRETARY entity will also keep all
relationships
Outline
 Subclasses, Superclasses and
Inheritance
 Specialization and Generalization
 Constrains and Characteristics
 Union
Specialization
 Specialization is the process of defining a
set of subclasses of an entity type

 The set of subclasses is based upon some

distinguishing characteristics of the entities in
the superclass

 Example: {SECRETARY, ENGINEER, TECHNICIAN}

is a specialization of EMPLOYEE based upon job
type.
Specialization (Top-Down)
 It may have several specializations of the
same superclass

 Example: Another specialization of EMPLOYEE based

on method of pay is {SALARIED_EMPLOYEE,
HOURLY_EMPLOYEE}.

 The subset symbol on each line connecting a

subclass to ϵ indicates the direction of the
superclass/subclass relationship
Subclasses and Superclasses
Specialization (Top-Down)
 Attributes of a subclass are called specific
or local attributes.
 For example, the attribute TypingSpeed of
SECRETARY

 The subclass can also participate in specific

relationship types.
 For example, a relationship BELONGS_TO of
HOURLY_EMPLOYEE
Specialization (Top-Down)
 There are two major reasons for including
class/subclass relationship and specialization in a
data model:

1. Certain attributes may apply to some but not all

entities of the superclass (secretary subclass has
local attribute Typing speed where engineer has
eng_type)
2. some relationship types may be participate in only
by entities that are members of the subclass
(Hourly_employees are related to Trade_nuion via
velongs_to)
Specialization (Top-Down)
 In summary, the specialization process
allows us to do the following:
 Define a set of subclass of an entity type
 Establish additional specific attributes with
each subclass
 Establish additional specific relationship
types between each subclass and other
entity types or other subclasses
Generalization (Bottom Up)
 Generalization is the reverse of the
specialization process

 Several classes with common features

are generalized into a superclass;
 original classes become its subclasses
Generalization (Bottom Up)
 Example: CAR, TRUCK generalized into
VEHICLE;
 both CAR, TRUCK become subclasses of
the superclass VEHICLE.
 We can view {CAR, TRUCK} as a
specialization of VEHICLE
 Alternatively, we can view VEHICLE as a
generalization of CAR and TRUCK
Generalization (2)
Outline
 Subclasses, Superclasses and
Inheritance
 Specialization and Generalization
 Constrains and Characteristics
 Union
Constraints on Specialization
and Generalization
 Two basic constraints can apply to a
specialization/generalization:
 Disjointness Constraint:
 Completeness Constraint:
Constraints on Specialization
and Generalization
 Disjointness Constraint:
 Specifies that the subclasses of the
specialization must be disjoint: an entity
can be a member of at most one of the
subclasses of the specialization

 Specified by d in EER diagram

Displaying an attribute-defined
specialization in EER diagrams
Constraints on Specialization
and Generalization

 If not disjoint, specialization is overlapping:

 that is the same entity may be a member of
more than one subclass of the specialization

 Specified by o in EER diagram

Example of overlapping total Specialization
Constraints on Specialization
and Generalization
 Completeness Constraint:
 Total specifies that every entity in the superclass must be a
member of some subclass in the specialization/generalization
 Shown in EER diagrams by a double line

 Partial allows an entity not to belong to any of the

subclasses
 Shown in EER diagrams by a single line

 In general, a superclass that was identified through the

generalization process usually total, because the superclass
is derived from the subclasses and hence contains only the
entities that are in the subclass
Constraints on Specialization and
Generalization (6)
 Hence, we have four types of
specialization/generalization:

 Disjoint, total
 Disjoint, partial
 Overlapping, total
 Overlapping, partial
Constraints on Specialization
and Generalization
 Some general rules:
 Deleting an entity from s superclass implies
that it is automatically deleted from all the
subclasses to which it belongs
 Inserting an entity in a superclass of a total
specialization implies that the entity is
mandatorily inserted in at least one of the
subclasses of the specialization
Specialization/Generalization
Hierarchies, Lattices
 A subclass may itself have further subclasses
specified on it

 Hierarchy has a constraint that every subclass has

only one superclass (called single inheritance); this
is basically a tree structure

 In a lattice, a subclass can be subclass of more than

one superclass (called multiple inheritance)
Shared Subclass “Engineering_Manager”
Specialization/Generalization
Hierarchies, Lattices
 Leaf node is a class that has no subclasses
of its own

 A subclass with more than one superclass is

called a shared subclass (multiple
inheritance)

 Notice that the existence of at least one

shared subclass leads to a lattice, otherwise,
it’s a hierarchy
Specialization / Generalization
Lattice Example (UNIVERSITY)
Outline
 Subclasses, Superclasses and
Inheritance
 Specialization and Generalization
 Constrains and Characteristics
 Union
Union
 All of the superclass/subclass relationships we
have seen so far origin from a single
superclass

 Sometimes we may need more than one

superclass
 In this case, the subclass will represent a
collection of objects that is a subset of the
UNION of distinct entity types
 We call such a subclass a UNION TYPE
Union
 Example: In a database for vehicle
registration, a vehicle owner can be a
PERSON, a BANK (holding a lien on a
vehicle) or a COMPANY.
 A UNION type called OWNER is created to
represent a subset of the union of the
three superclasses COMPANY, BANK, and
PERSON
Two categories (UNION types):
OWNER, REGISTERED_VEHICLE
Union
 We can compare a UNION (OWNER) with shared subclass
(ENGINEERING_MANAGER)

 The latter is a subclass of each of the three superclass

ENGINEER, MANAGER and SALARIED_EMPLOYEE, so an entity
that us a member of ENGINEERING_MANAGER must exist in
all three

 This means that an engineering manager must be an

ENGINEER, a MANAGER, and a SALARIED_EMPLOYEE

 On the other hand, an entity that is a member of OWNER must

exist in only one of the superclass
Shared Subclass “Engineering_Manager”
UNION
 Attribute inheritance works more selectively
in the case of UNION.

 For example, OWNER entity inherits

attributes of a COMPANY, a PERSON OR a
BANK

 A shared subclass such as

ENGINEERING_MANAGER inherits ALL the
attributes of its superclasses
EER
Example