• 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
Trang 1Project 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
manages
Functional dependency
(c) One-to-many-to-many ternary relationship
project-name, emp-id → mgr-id
Project Employee
Skill 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
Trang 228 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
Time Room
Trang 3entity (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.
Trang 430 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.)
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 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 abstracimplementa-tions
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
Trang 52.4 Literature Summary
Most of the notation in this chapter is from Chen’s original ER defini-tion [Chen, 1976] The concept of data abstracdefini-tion 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]