CS4222 Principles of Database System 4/7/2019 CS4222 Principles of Database System 6. Enhanced Entity-Relationship model 2 Huiping Guo Department of Computer Science California State University, Los Angeles

Outline Categories or UNION types Categories vs. shared subclasses 4/7/2019 Outline Categories or UNION types Categories vs. shared subclasses A sample UNIVERSITY EER schema Design Choices for Specialization/Generalization Formal definition of EER In-class exercises 6. EER 2 CS4222_Su17

Categories (UNION TYPES) (1) It is sometimes necessary to represent a collection of entities from different entity types In this case, a subclass will represent a collection of entities that is a subset of the UNION of entities from distinct entity types Such a subclass is called a union type or a category Example: In a database for vehicle registration, a vehicle owner can be a PERSON, a BANK (holding a lien on a vehicle) or a COMPANY. A category (UNION type) called OWNER is created to represent a subset of the union of the three superclasses COMPANY, BANK, and PERSON A category member must exist in at least one (typically just one) of its superclasses 6. EER 2 CS4222_Su17

Categories (UNION TYPES) (2) Categories in EER The superclasses COMPANY, BANK, and PERSON are connected to the circle with the ∪ symbol, which stands for the set union operation. An arc with the subset symbol connects the circle to the (subclass) OWNER category 6. EER 2 CS4222_Su17

Two categories (UNION types): OWNER, REGISTERED_VEHICLE 6. EER 2 CS4222_Su17

Categories vs. Shared subclasses A shared subclass is a subset of the intersection of its superclasses shared subclass member must exist in all of its superclasses EX: ENGINEERING_MANAGER shared subclass in Figure 4.6 The latter is a subclass of each of the three superclasses ENGINEER, MANAGER, and SALARIED_EMPLOYEE, so an entity that is a member of ENGINEERING_MANAGER must exist in all three collections. The ENGINEERING_MANAGER entity set is a subset of the intersection of the three entity sets 6. EER 2 CS4222_Su17

Categories vs. Shared subclasses 2 A category is a subset of the union of its superclasses. Hence, an entity that is a member of OWNER must exist in only one of the superclasses. This represents the constraint that an OWNER may be a COMPANY, a BANK, or a PERSON 6. EER 2 CS4222_Su17

Categories vs. Shared subclasses 3 Attribute inheritance works more selectively in the case of categories. For example each OWNER entity inherits the attributes of a COMPANY, a PERSON, or a BANK, depending on the superclass to which the entity belongs. On the other hand, a shared subclass such as ENGINEERING_MANAGER (Fig. 4.6) inherits all the attributes of its superclasses SALARIED_EMPLOYEE, ENGINEER, and MANAGER. 6. EER 2 CS4222_Su17

Categories vs. Shared subclasses 4 What’s the difference between the category REGISTERED_VEHICLE (Fig4.8) and the generalized superclass VEHICLE (Fig 4.3(b))? In fig4.3(b), every car and every truck is a VEHICLE; but in Fig 4.8, the REGISTERED_VEHICLE category includes some cars and some trucks but not necessarily all of them for example, some cars or trucks may not be registered. In general, a specialization or generalization such as that in Figure 4.3(b), if it were partial, would not preclude VEHICLE from containing other types of entities, such as motorcycles. However, a category such as REGISTERED_VEHICLE in Fig4.8 implies that only cars and trucks, but not other types of entities, can be members of REGISTERED_VEHICLE. 6. EER 2 CS4222_Su17

Constraints on categories A category can be total or partial. A total category holds the union of all entities in its superclasses, whereas a partial category can hold a subset of the union. A total category is represented diagrammatically by a double line connecting the category and the circle, whereas a partial category is indicated by a single line. If a category is total (not partial), it may be represented alternatively as a total specialization The choice of which representation to use is subjective 6. EER 2 CS4222_Su17

Figure 4.9 An EER conceptual schema for a different UNIVERSITY database. 6. EER 2 CS4222_Su17

Design Choices for Specialization/Generalization In general, many specializations and subclasses can be defined to make the conceptual model accurate. It is important to represent only those subclasses that are deemed necessary to avoid extreme cluttering of the conceptual schema. If a subclass has few specific (local) attributes and no specific relationships, it can be merged into the superclass. The specific attributes would hold NULL values for entities that are not members of the subclass. A type attribute could specify whether an entity is a member of the subclass. Similarly, if all the subclasses of a specialization/generalization have few specific attributes and no specific relationships, they can be merged into the superclass and replaced with one or more type attributes that specify the subclass or subclasses that each entity belongs 6. EER 2 CS4222_Su17

Design Choices for Specialization/Generalization 2 Union types and categories should generally be avoided unless the situation definitely warrants this type of construct, which does occur in some practical situations. If possible, we try to model using specialization/generalization The choice of disjoint/overlapping and total/partial constraints on specialization/generalization is driven by the rules in the miniworld being modeled. If the requirements do not indicate any particular constraints, the default would generally be overlapping and partial, since this does not specify any restrictions on subclass membership. 6. EER 2 CS4222_Su17

Design Choices for Specialization/Generalization 3 Consider Figure 4.6, where no specific (local) attributes are shown We could merge all the subclasses into the EMPLOYEE entity type and add the following attributes to EMPLOYEE: An attribute Job_type whose value set {‘Secretary’, ‘Engineer’, ‘Technician’} would indicate which subclass in the first specialization each employee belongs to. An attribute Pay_method whose value set {‘Salaried’, ‘Hourly’} would indicate which subclass in the second specialization each employee belongs to. An attribute Is_a_manager whose value set {‘Yes’, ‘No’} would indicate whether an individual employee entity is a manager or not. 6. EER 2 CS4222_Su17

Formal Definitions of EER Model (1) Class C: A type of entity with a corresponding set of entities: could be entity type, subclass, superclass, or category Subclass S is a class whose: Set of entities must always be a subset of the set of entities of the other class C S ⊆ C C is called the superclass of S A superclass/subclass relationship exists between S and C 6. EER 2 CS4222_Su17

Formal Definitions of EER Model (2) Specialization Z: Z = {S1, S2,…, Sn} is a set of subclasses with same superclass G; hence, G/Si is a superclass relationship for i = 1, …., n. G is called a generalization of the subclasses {S1, S2,…, Sn} Z is total if we always have: S1 ∪ S2 ∪ … ∪ Sn = G; Otherwise, Z is partial. Z is disjoint if we always have: Si ∩ S2 empty-set for i ≠ j; Otherwise, Z is overlapping. 6. EER 2 CS4222_Su17

Formal Definitions of EER Model (3) Subclass S of C is predicate defined if predicate (condition) p on attributes of C is used to specify membership in S; that is, S = C[p], where C[p] is the set of entities in C that satisfy condition p A subclass not defined by a predicate is called user-defined Attribute-defined generalization G if a predicate A = ci (where A is an attribute of G and ci is a constant value from the domain of A) is used to specify membership in each subclass Si in Z Note: If ci ≠ cj for i ≠ j, and A is single-valued, then the attribute-defined specialization will be disjoint. 6. EER 2 CS4222_Su17

Formal Definitions of EER Model (4) Category or UNION type T A class that is a subset of the union of n defining superclasses D1, D2,…Dn, n>1: T ⊆ (D1 ∪ D2 ∪ … ∪ Dn) Can have a predicate pi on the attributes of Di to specify entities of Di that are members of T. If a predicate is specified on every Di: T = (D1[p1] ∪ D2[p2] ∪…∪ Dn[pn]) 6. EER 2 CS4222_Su17

In-class exercise 1 Which of the following EER diagrams is/are incorrect and why? State clearly any assumptions you make. 6. EER 2 CS4222_Su17

In-class exercise 2 6. EER 2 CS4222_Su17

In-class exercise 2 Consider the BANK ER schema, and suppose that it is necessary to keep track of different types of ACCOUNTS (SAVINGS_ACCTS, CHECKING_ACCTS, … ) and LOANS(CAR_LOANS, HOME_LOANS, … ). Suppose that it is also desirable to keep track of each ACCOUNT’s TRANSACTIONS (deposits, withdrawals, checks, … ) and each LOAN’s PAYMENTS; both of these include the amount, date, and time. Modify the BANK schema, using ER and EER concepts of specialization and generalization. State any assumptions you make about the additional requirements. 6. EER 2 CS4222_Su17