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 . 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. 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). 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