Database Modeling & Design Fourth Edition- P9 pptx

2.2 Advanced ER Constructs 27
Project are considered “many;” the entity Manager is considered “one.”
This is represented by the following assertions.
• Assertion 1: One engineer, working under one manager, could
be working on many projects.
• Assertion 2: One project, under the direction of one manager,
could have many engineers.
• Assertion 3: One engineer, working on one project, must have
only a single manager
Figure 2.6 (continued)
Each engineer working on a particular
project has exactly one manager, but
each manager of a project may manage
many engineers, and each manager of
an engineer may manage that engineer
on many projects.
Engineer
Manager
Project
N
1
N
manages
Functional dependency
(c) One-to-many-to-many ternary relationship
project-name, emp-id mgr-id→
Project
Employee
Skill
N
N

N
skill-used
Functional dependencies
Employees can use many skills on any one
of many projects, and each project has
many employees with various skills.
(d) Many-to-many-to-many ternary relationship
None
Teorey.book Page 27 Saturday, July 16, 2005 12:57 PM
28 CHAPTER 2 The Entity-Relationship Model
Assertion 3 could also be written in another form, using an arrow
(->) in a kind of shorthand called a functional dependency. For example:
emp-id, project-name -> mgr-id
where emp-id is the key (unique identifier) associated with the entity
Engineer, project-name is the key associated with the entity Project, and
mgr-id is the key of the entity Manager. In general, for an n-ary relation-
ship, each entity considered to be a “one” has its key appearing on the
right side of exactly one functional dependency (FD). No entity consid-
ered “many” ever has its key appear on the right side of an FD.
All four forms of ternary relationships are illustrated in Figure 2.6. In
each case, the number of “one” entities implies the number of FDs used
to define the relationship semantics, and the key of each “one” entity
appears on the right side of exactly one FD for that relationship.
Ternary relationships can have attributes in the same way that
many-to-many binary relationships can. The values of these attributes
are uniquely determined by some combination of the keys of the entities
associated with the relationship. For example, in Figure 2.6d the rela-
tionship “skill-used” might have the attribute “tool” associated with a
given employee using a particular skill on a certain project, indicating
that a value for tool is uniquely determined by the combination of

employee, skill, and project.
2.2.4 General n-ary Relationships
Generalizing the ternary form to higher-degree relationships, an n-ary
relationship that describes some association among n entities is repre-
sented by a single relationship diamond with n connections, one to each
Figure 2.7 n-ary relationships.
Day
enrolls-in
Class
Student
TimeRoom
Teorey.book Page 28 Saturday, July 16, 2005 12:57 PM
2.2 Advanced ER Constructs 29
entity (see Figure 2.7). The meaning of this form can best be described in
terms of the functional dependencies among the keys of the n associated
entities. There can be anywhere from zero to n FDs, depending on the
number of “one” entities. The collection of FDs that describe an n-ary
relationship must have n components: n – 1 on the left side (determi-
nant) and 1 on the right side. A ternary relationship (n =3), for example,
has two components on the left and one on the right, as we saw in the
example in Figure 2.6. In a more complex database, other types of FDs
may also exist within an n-ary relationship. When this occurs, the ER
model does not provide enough semantics on its own, and it must be
supplemented with a narrative description of these dependencies.
2.2.5 Exclusion Constraint
The normal, or default, treatment of multiple relationships is the inclu-
sive OR, which allows any or all of the entities to participate. In some sit-
uations, however, multiple relationships may be affected by the exclusive
OR (exclusion) constraint, which allows at most one entity instance
among several entity types to participate in the relationship with a sin-

gle root entity. For example, in Figure 2.8, suppose the root entity Work-
task has two associated entities, External-project and Internal-project. At
most one of the associated entity instances could apply to an instance of
Work-task.
Figure 2.8 Exclusion constraint
External-project
is-for
is-
assigned-
to
Work-task
Internal-project
+
A work task can be assigned to
either an external project or an
internal project, but not both.
Teorey.book Page 29 Saturday, July 16, 2005 12:57 PM
30 CHAPTER 2 The Entity-Relationship Model
2.2.6 Referential Integrity
We note that a foreign key is an attribute of a table (not necessarily a key
of any kind) that relates to a key in another table. Referential integrity
requires that for every foreign key instance that exists in a table, the row
(and thus the key instance) of the parent table associated with that for-
eign key instance must also exist. The referential integrity constraint has
become integral to relational database design and is usually implied as
requirements for the resulting relational database implementation.
(Chapter 5 discusses the SQL implementation of referential integrity
constraints.)
2.3 Summary
The basic concepts of the ER model and their constructs are described in

this chapter. An entity is a person, place, thing, or event of informa-
tional interest. Attributes are objects that provide descriptive informa-
tion about entities. Attributes may be unique identifiers or nonunique
descriptors. Relationships describe the connectivity between entity
instances: one-to-one, one-to-many, or many-to-many. The degree of a
relationship is the number of associated entities: two (binary), three (ter-
nary), or any n (n-ary). The role (name), or relationship name, defines
the function of an entity in a relationship.
The concept of existence in a relationship determines whether an
entity instance must exist (mandatory) or not (optional). So, for exam-
ple, the minimum connectivity of a binary relationship—that is, the
number of entity instances on one side that are associated with one
instance on the other side—can either be zero, if optional, or one, if
mandatory. The concept of generalization allows for the implementa-
tion of supertype and subtype abstractions.
The more advanced constructs in ER diagrams are sporadically used
and have no generally accepted form as yet. They include ternary rela-
tionships, which we define in terms of the FD concept of relational data-
bases; constraints on exclusion; and the implicit constraints from the
relational model, such as referential integrity.
Teorey.book Page 30 Saturday, July 16, 2005 12:57 PM
2.4 Literature Summary 31
2.4 Literature Summary
Most of the notation in this chapter is from Chen’s original ER defini-
tion [Chen, 1976]. The concept of data abstraction was first proposed by
Smith and Smith [1977] and applied to the ER model by Scheuermann,
Scheffner, and Weber [1980], Elmasri and Navathe [2003], Bruce [1992],
IDEF1X [2005], among others. The application of the semantic network
model to conceptual schema design was shown by Bachman [1977],
McKleod and King [1979], Hull and King [1987], and Peckham and

Maryanski [1988].
Teorey.book Page 31 Saturday, July 16, 2005 12:57 PM