Database Modeling & Design Fourth Edition- P8 doc

22 CHAPTER 2 The Entity-Relationship Model
(b)
Figure 2.3 (continued)
(f) Recursive binary relationship
ER model constructs
using the
Chen notation
ER model constructs
using IDEF1X
[Bruc92]
Department
Division has Department
Department
Division
Office Employee
Employee
Project
Employee
is-
managed-
by
is-managed-by
is-
occupied-
by
is-occupied-by
works-
on
works-on
11
1

Office
Employee
Employee
1
Project
M
N
N
N
N
Employee
has
Employee
Employee
EMPLOYEE
emp-id
emp-name
job-class
is-group-leader-of
Employee
1
P
is-
group-leader-
of
Entity,
attribute
(no operation)
Entity
Primary key

emp-id
emp-name
job-class
(a) Entity with attributes
(b) One-to-one
(c) One-to-many, many side optional
(d) One-to-many, one side optional
(e) Many-to-many
Nonprimary
key attributes
Department
Teorey.book Page 22 Saturday, July 16, 2005 12:57 PM
2.2 Advanced ER Constructs 23
2.2 Advanced ER Constructs
2.2.1 Generalization: Supertypes and Subtypes
The original ER model has been effectively used for communicating fun-
damental data and relationship definitions with the end user for a long
time. However, using it to develop and integrate conceptual models with
different end user views was severely limited until it could be extended
to include database abstraction concepts such as generalization. The gen-
eralization relationship specifies that several types of entities with cer-
tain common attributes can be generalized into a higher-level entity
type—a generic or superclass entity, more commonly known as a super-
type entity. The lower levels of entities—subtypes in a generalization hier-
archy—can be either disjoint or overlapping subsets of the supertype
entity. As an example, in Figure 2.4 the entity Employee is a higher-level
Figure 2.4 Supertypes and subtypes
supertype
Employee
d

subtypes
Secreta
ry
Technician
EngineerManager
Individual
Customer
Employee
(a) Generalization with disjoint subtypes
(b) Generalization with overlapping subtypes and completeness constrain
t
O
Teorey.book Page 23 Saturday, July 16, 2005 12:57 PM
24 CHAPTER 2 The Entity-Relationship Model
abstraction of Manager, Engineer, Technician, and Secretary—all of
which are disjoint types of Employee. The ER model construct for the
generalization abstraction is the connection of a supertype entity with
its subtypes, using a circle and the subset symbol on the connecting
lines from the circle to the subtype entities. The circle contains a letter
specifying a disjointness constraint (see the following discussion). Spe-
cialization, the reverse of generalization, is an inversion of the same con-
cept; it indicates that subtypes specialize the supertype.
A supertype entity in one relationship may be a subtype entity in
another relationship. When a structure comprises a combination of
supertype/subtype relationships, that structure is called a supertype/sub-
type hierarchy or generalization hierarchy. Generalization can also be
described in terms of inheritance, which specifies that all the attributes
of a supertype are propagated down the hierarchy to entities of a lower
type. Generalization may occur when a generic entity, which we call the
supertype entity, is partitioned by different values of a common

attribute. For example, in Figure 2.4 the entity Employee is a generaliza-
tion of Manager, Engineer, Technician, and Secretary over the attribute
“job-title” in Employee.
Generalization can be further classified by two important constraints
on the subtype entities: disjointness and completeness. The disjointness
constraint requires the subtype entities to be mutually exclusive. We
denote this type of constraint by the letter “d” written inside the gener-
alization circle (Figure 2.4a). Subtypes that are not disjoint (i.e., that
overlap) are designated by using the letter “o” inside the circle. As an
example, the supertype entity Individual has two subtype entities,
Employee and Customer; these subtypes could be described as overlap-
ping, or not mutually exclusive (Figure 2.4b). Regardless of whether the
subtypes are disjoint or overlapping, they may have additional special
attributes in addition to the generic (inherited) attributes from the
supertype.
The completeness constraint requires the subtypes to be all-inclu-
sive of the supertype. Thus, subtypes can be defined as either total or
partial coverage of the supertype. For example, in a generalization hier-
archy with supertype Individual and subtypes Employee and Customer,
the subtypes may be described as all-inclusive or total. We denote this
type of constraint by a double line between the supertype entity and
the circle. This is indicated in Figure 2.4b, which implies that the only
types of individuals to be considered in the database are employees and
customers.
Teorey.book Page 24 Saturday, July 16, 2005 12:57 PM
2.2 Advanced ER Constructs 25
2.2.2 Aggregation
Aggregation is a form of abstraction between a supertype and subtype
entity that is significantly different from the generalization abstraction.
Generalization is often described in terms of an “is-a” relationship

between the subtype and the supertype—for example, an Employee is an
Individual. Aggregation, on the other hand, is the relationship between
the whole and its parts and is described as a “part-of” relationship—for
example, a report and a prototype software package are both parts of a
deliverable for a contract. Thus, in Figure 2.5, the entity Software-prod-
uct is seen to consist of component parts Program and User’s Guide. The
construct for aggregation is similar to generalization, in that the super-
type entity is connected with the subtype entities with a circle; in this
case, the letter “A” is shown in the circle. However, there are no subset
symbols because the “part-of” relationship is not a subset. Furthermore,
there are no inherited attributes in aggregation; each entity has its own
unique set of attributes.
2.2.3 Ternary Relationships
Ternary relationships are required when binary relationships are not suf-
ficient to accurately describe the semantics of an association among
three entities. Ternary relationships are somewhat more complex than
binary relationships, however. The ER notation for a ternary relationship
is shown in Figure 2.6 with three entities attached to a single relation-
ship diamond, and the connectivity of each entity is designated as either
“one” or “many.” An entity in a ternary relationship is considered to be
“one” if only one instance of it can be associated with one instance of
Figure 2.5 Aggregation
Software-product
A
User’s Guide
Program
Teorey.book Page 25 Saturday, July 16, 2005 12:57 PM
26 CHAPTER 2 The Entity-Relationship Model
each of the other two associated entities. It is “many” if more than one
instance of it can be associated with one instance of each of the other

two associated entities. In either case, it is assumed that one instance of
each of the other entities is given.
As an example, the relationship “manages” in Figure 2.6c associates
the entities Manager, Engineer, and Project. The entities Engineer and
Figure 2.6 Ternary relationships
Each employee assigned to a project works at
only one location for that project, but can be
at different locations for different projects. At
a particular location, an employee works on
only one project. At a particular location,
there can be many employees assigned to
a given project.
A technician uses exactly one notebook for
each project. Each notebook belongs to one
technician for each project. Note that a
technician may still work on many projects
and maintain different notebooks for
different projects.
Project
Technician
Notebook
1
1
1
uses-
notebook
Functional dependencies
(a) One-to-one-to-one ternary relationship
emp-id, project-name notebook-no
emp-id, notebook-no project-name

project-name, notebook-no emp-id
→
→
→
Employee
Project
Location
1
1
N
assigned-
to
Functional dependencies
(b) One-to-one-to-many ternary relationship
emp-id, loc-name project-name
emp-id, project-name loc-name
→
→
Teorey.book Page 26 Saturday, July 16, 2005 12:57 PM