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