Database System

The Enhanced Entity-

Relationship (EER) Model
The Enhanced Entity-Relationship
(EER) Model
• ER diagram represent the entity types and what they
contains (attributes and relationships).
• In many cases an entity type (like Employee) has numerous
subgroupings or subtypes of its entities (like SECRETARY,
ENGINEER, MANAGER, TECHNICIAN).
• These subgroupings are called a subclass or subtype of the
EMPLOYEE entity type, and the EMPLOYEE entity type is
called the superclass or supertype for each of these
subclasses.
• We call the relationship between a superclass and any one of
its subclasses a superclass/subclass or supertype/subtype
or simply class/subclass relationship
The Enhanced Entity-Relationship
(EER) Model

Figure 1 EER diagram notation to represent subclasses and specialization.

The Enhanced Entity-Relationship
(EER) Model
• An entity that is a member of a subclass inherits all the
attributes of the entity as a member of the superclass. And
inherits all the relationships in which the superclass
participates. This concept called type inheritance.

• Like secretary entity type (SUBCLASS) inherits all the

attributes and relationships of the employee entity type
(SUPERCLASS)
Specialization and Generalization

• Specialization is the process of defining a set of subclasses of

an entity type. The set of subclasses that forms a
specialization is defined on the basis of some distinguishing
characteristic of the entities in the superclass. For example,
the set of subclasses {SECRETARY, ENGINEER, TECHNICIAN}
is a specialization of the superclass EMPLOYEE that
distinguishes among employee entities based on the job type
of each employee entity.

• The subclasses that define a specialization are attached by

lines to a circle that represents the specialization, which is
connected in turn to the superclass.
Specialization and Generalization

• Attributes that apply only to entities of a particular subclass

—such as TypingSpeed of SECRETARY—are attached to the
rectangle representing that subclass. These are called
specific attributes (or local attributes) of the subclass.

• Similarly, a subclass can participate in specific relationship

types, such as the HOURLY_EMPLOYEE subclass
participating in the BELONGS_TO relationship in Figure 1
Specialization and Generalization

In summary, the specialization process allows us to do the

following:
■ Define a set of subclasses 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.
Specialization and Generalization

Specialization is a top-down approach

Specialization and Generalization

Generalization:
We can think of a reverse process of abstraction in which we
suppress the differences among several entity types, identify
their common features, and generalize them into a single
superclass of which the original entity types are special
subclasses. For example, consider the entity types CAR and
TRUCK shown in Figure 2(a). Because they have several
common attributes, they can be generalized into the entity type
VEHICLE, as shown in Figure 2(b). Both CAR and TRUCK are
now subclasses of the generalized superclass VEHICLE. We use
the term generalization to refer to the process of defining a
generalized entity type from the given entity types.
Specialization and Generalization

Figure 2 Generalization. (a) Two entity types, CAR and TRUCK. (b) Generalizing CAR and
TRUCK into the superclass VEHICLE.
Specialization and Generalization

Generalization is a bottom-up approach

Constraints on Specialization and
Generalization
In some specializations we can determine exactly the entities
that will become members of each subclass by placing a
condition on the value of some attribute of the superclass. Such
subclasses are called predicate-defined (or condition-defined)
subclasses. For example, if the EMPLOYEE entity type has an
attribute Job_type, as shown in Figure 3, we can specify the
condition of membership in the SECRETARY subclass by the
condition (Job_type = ‘Secretary’). We display a predicate-
defined subclass by writing the predicate condition next to the
line that connects the subclass to the specialization circle.
Constraints on Specialization and
Generalization
When we do not have a condition for determining membership
in a subclass, the subclass is called user-defined. Membership in
such a subclass is determined by the database users when they
apply the operation to add an entity to the subclass; hence,
membership is specified individually for each entity by the user,
not by any condition that may be evaluated automatically.
Constraints on Specialization and
Generalization

Figure 3 EER diagram notation for an attribute-defined specialization on Job_type.

Constraints on Specialization and
Generalization
Two other constraints may apply to a specialization.
1. Disjointness / Overlapping

• disjointness (or disjointedness) constraint. This means that

an entity can be a member of at most one of the subclasses
of the specialization. Figure 3 illustrates this case, where the
d in the circle stands for disjoint.

d
Constraints on Specialization and
Generalization
• If the subclasses are not constrained to be disjoint, their sets
of entities may be overlapping; that is, the same (real-
world) entity may be a member of more than one subclass
of the specialization. This case, which is the default, is
displayed by placing an o in the circle, as shown in Figure 4.

o
Constraints on Specialization and
Generalization

Figure 4 EER diagram notation for an overlapping(nondisjoint) specialization.

Constraints on Specialization and
Generalization
2. Completeness (or totalness) constraint

• A total specialization constraint specifies that every entity in

the superclass must be a member of at least one subclass in
the specialization. For example, if every EMPLOYEE must be
either an HOURLY_EMPLOYEE or a SALARIED_EMPLOYEE,
in Figure 1. This is shown in EER diagrams by using a double
line to connect the superclass to the circle.
Constraints on Specialization and
Generalization
• A partial specialization which allows an entity not to belong
to any of the subclasses. For example, if some EMPLOYEE
entities do not belong to any of the subclasses {SECRETARY,
ENGINEER, TECHNICIAN} in Figures 1 and 3, then that
specialization is partial. A single line is used to display a
partial specialization.
The Enhanced Entity-Relationship
(EER) Model

Figure 1 EER diagram notation to represent subclasses and specialization.

Constraints on Specialization and
Generalization
Notice that the disjointness and completeness constraints are
independent. Hence, we have the following four possible
constraints on specialization:

■ Disjoint, total
■ Disjoint, partial
■ Overlapping, total
■ Overlapping, partial
Specialization and Generalization
Hierarchies and Lattices
A subclass itself may have further subclasses specified on it,
forming a hierarchy or a lattice of specializations. For example,
in Figure 5 ENGINEER is a subclass of EMPLOYEE and is also a
superclass of ENGINEERING_MANAGER; this represents the
real-world constraint that every engineering manager is
required to be an engineer.
Specialization and Generalization
Hierarchies and Lattices

Figure 5 A specialization lattice with shared subclass ENGINEERING_MANAGER.

Specialization and Generalization
Hierarchies and Lattices
• A subclass with more than one superclass is called a shared
subclass, such as ENGINEERING_MANAGER in Figure 5. This
leads to the concept known as multiple inheritance, where
the shared subclass ENGINEERING_MANAGER directly
inherits attributes and relationships from multiple classes.
• However, it is sometimes necessary to represent a single
superclass/subclass relationship with more than one
superclass, where the superclasses represent different entity
types. 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 or a category.
Modeling of UNION Types Using
Categories
For example, suppose that we have three entity types:
PERSON, BANK, and COMPANY. In a database for motor
vehicle registration, an owner of a vehicle can be a person, a
bank (holding a lien on a vehicle), or a company. We need to
create a class (collection of entities) that includes entities of all
three types to play the role of vehicle owner. A category (union
type) OWNER that is a subclass of the UNION of the three entity
sets of COMPANY, BANK, and PERSON can be created for this
purpose.
Modeling of UNION Types Using
Categories
We display categories in an EER diagram as shown in Figure 7.
The superclasses COMPANY, BANK, and PERSON are
connected to the circle with the ∪ symbol, which stands for the
set union operation. An arc with the subset symbol connects the
circle to the (subclass) OWNER category. If a defining predicate
is needed, it is displayed next to the line from the superclass to
which the predicate applies. In Figure 7 we have two categories:
OWNER, which is a subclass of the union of PERSON, BANK,
and COMPANY; and REGISTERED_VEHICLE, which is a subclass
of the union of CAR and TRUCK.
Modeling of UNION Types Using
Categories

Figure 7 Two categories (union types): OWNER and REGISTERED_VEHICLE.

Modeling of UNION Types Using
Categories
A category has two or more superclasses that may represent
distinct entity types, whereas other superclass/subclass
relationships always have a single superclass. To better
understand the difference, we can compare a category, such as
OWNER in Figure 7, with the ENGINEERING_MANAGER shared
subclass in Figure 5. The latter is a subclass of each of the three
superclasses ENGINEER, MANAGER, and
SALARIED_EMPLOYEE, so an entity that is a member of
ENGINEERING_MANAGER must exist in all three. This
represents the constraint that an engineering manager must be
an ENGINEER, a MANAGER, and a SALARIED_EMPLOYEE; that
is, ENGINEERING_MANAGER is a subset of the intersection of
the three classes (sets of entities).
Modeling of UNION Types Using
Categories
On the other hand, a category is a subset of the union of its
superclasses. Hence, an entity that is a member of OWNER
must exist in only one of the super-classes. This represents the
constraint that an OWNER may be a COMPANY, a BANK, or a
PERSON in Figure 7.
Specialization and Generalization
Hierarchies and Lattices
The requirements for the part of the UNIVERSITY database
shown in Figure 6 are the following:
1. The database keeps track of three types of persons:
employees, alumni, and students. A person can belong to one,
two, or all three of these types. Each person has a name, SSN,
gender, address, and birth date.
2. Every employee has a salary, and there are three types of
employees: faculty, staff, and student assistants. Each
employee belongs to exactly one of these types. For each
alumnus, a record of the degree or degrees that he or she
earned at the university is kept, including the name of the
degree, the year granted, and the major department. Each
student has a major department.
Specialization and Generalization
Hierarchies and Lattices
3. Each faculty has a rank, whereas each staff member has a
staff position. Student assistants are classified further as either
research assistants or teaching assistants, and the percent of
time that they work is recorded in the database. Research
assistants have their research project stored, whereas teaching
assistants have the current course they work on.
4. Students are further classified as either graduate or
undergraduate, with the specific attributes degree program
(M.S., Ph.D., M.B.A., and so on) for graduate students and class
(freshman, sophomore, and so on) for undergraduates.
Specialization and Generalization
Hierarchies and Lattices
In Figure 6, all person entities represented in the database are
members of the PERSON entity type, which is specialized into
the subclasses {EMPLOYEE, ALUMNUS, STUDENT}. This
specialization is overlapping; for example, an alumnus may also
be an employee and may also be a student pursuing an
advanced degree. The subclass STUDENT is the superclass for
the specialization {GRADUATE_STUDENT,
UNDERGRADUATE_STUDENT}, while EMPLOYEE is the
superclass for the specialization {STUDENT_ASSISTANT,
FACULTY, STAFF}. Notice that STUDENT_ASSISTANT is also a
subclass of STUDENT.
Specialization and Generalization
Hierarchies and Lattices
Finally, STUDENT_ASSISTANT is the superclass for the
specialization into {RESEARCH_ASSISTANT,
TEACHING_ASSISTANT}. In such a specialization lattice or
hierarchy, a subclass inherits the attributes not only of its direct
superclass, but also of all its predecessor superclasses all the
way to the root of the hierarchy or lattice if necessary. For
example, an entity in GRADUATE_STUDENT inherits all the
attributes of that entity as a STUDENT and as a PERSON.
 Gender

Specialization and Generalization

Hierarchies and Lattices

Figure 6 A specialization lattice with multiple inheritance for a UNIVERSITY database.

Review Questions:

1. What is a subclass? When is a subclass needed in data

modeling ?
2. Discuss the mechanism of attribute/relationship inheritance.
Why is it useful ?
3. Discuss user-defined and predicate-defined subclasses, and
identify the differences between the two.
4. Discuss the two main types of constraints on specializations
and generalizations.
5. How does a category differ from a regular shared subclass?
What is a category used for? Illustrate your answer with
examples.
Homework

8.20