Chapter 4 Enhanced EntityRelationship and Object Modeling 4

Chapter 4 Enhanced Entity-Relationship and Object Modeling 4. 1 Subclasses, Superclasses, and Inheritance 4. 2 Specialization and Generalization 4. 3 Constraints and Characteristics of Specialization and Generalization 4. 4 Modeling of UNION Types Using Categories 4. 5 An Example UNIVERSITY EER Schema and Formal Definitions for the EER Model 4. 6 Conceptual Object Modeling Using UML Class Diagrams 4. 7 Relationship Types of Degree Higher Than Two 4. 8 Data Abstraction and Knowledge Representation Concepts 4. 9 Summary 1

database applications • traditional – database processing applications in business and industry • newer applications – – – – – CAD/CAM telecommunications images and graphics multimedia data mining data warehousing GIS databases for indexing the World Wide Web. . . 2

Enhanced ER (EER) model • • • modeling concepts of the ER model subclass and superclass (type inheritance) specialization and generalization (constraints) category (UNION) attribute and relationship inheritance UNIVERSITY database in EER model 3

subclass attributes relationships • entity type (a type of entity) – e. g. , EMPLOYEE • entity set (collection of entities of that type) – e. g. , current set of EMPLOYEE entities • subclass (vs superclass) – e. g. , SECRETARY, ENGINEER, TECHNICIAN, MANAGER, SALARIED_EMPLOYEE, HOURLY_EMPLOYEE ‧An entity must also be a member • class/subclass relationship – e. g. , of the superclass ‧An entity can be a member of any EMPLOYEE/SECRETARY number of subclasses ‧It is not necessary that every entity in a superclass be a member of some subclasses. 4

subclass (continued) • Implementation – A member entity of the subclass represents the same real-world entity as some member of the superclass the same entity but in specific role – A distinct record that is related via the key attribute to its superclass entity • type inheritance Besides specific (or local) attributes and relationships, – An entity that is a member of a subclass inherits all the attributes of the entity as a member of the superclass – The entity also inherits all the relationships in which the superclass participates 5

Specialization and Generalization • specialization – define a set of subclasses of an entity type superclass – {SECRETARY, ENGINEER, TECHNICIAN} is a specialization of EMPLOYEE by job type – {SALARIED_EMPLOYEE, HOURLY_EMPLOYEE} is a specialization of EMPLOYEE by method of pay • notation in EER diagram 6

Figure 4. 1 EER diagram for representing specialization an d subclasses. FName Minit LName Ssn Birth. Date Address EMPLOYEE specific (local) attributes completeness constraint: completeness constraint : partial specialization total specialization subset symbol Typing Speed SECRETARY disjointness constraint d TGrade TECHNICIAN subset symbol Eng. Type ENGINEER disjointness specific constraint disjoint d attributes MANAGER Pay Scale Salary HOURLY_EMPLOYEE SALARIED_EMPLOYEE MANAGES Three specializations of EMPLOYEE: PROJECT (SECRETARY, TECHNICIAN, ENGINEER) (MANAGER) (HOURLY_EMPLOYEE, SALARIED_EMPLOYEE) specific relationship BELONGS_TO specific relationship TRADE_UNION 7

SECRETARY . e. e. e EMPLOYEE e 1 e 2 e 3 e 4 e 5 e 6 e 7 e 8 . . . . 1 4 5 ENGINEER . e. e 2 7 TECHNICIAN Figure 4. 2 Some instances of the spcialization of EMPLOYEE into the {SECRERARY, ENGINEER, TECHNICIAN} set of subclasses. superclass/subclass relationship: 1: 1 relationship at the instance level . e. e 3 8 same entity in specialized role 8

Why including class/subclass relationships? • Certain attributes may apply to some but not all entities of the superclass – SECRETARY (attribute Typing. Speed) – ENGINEER (attribute Engineer. Type) • Some relationship types may be participated in only by entities that are members of the subclass – HOURLY_EMPLOYEE belongs to a trade union 會 9

Specialization process • Define a set of subclasses of an entity type • Establish additional specific attributes with each class • Establish additional specific relationship types between subclass and other entity types or other subclasses 10

Generalization • Define a generalized entity type from the given entity types subclass – {CAR, TRUCK} as a specialization of VEHICLE generalized superclass – VEHICLE as a generalization of CAR and TRUCK alternative generalization VEHICLE CAR VEHICLE TRUCK CAR specialization TRUCK 11

(a) No. Of. Axles No. Of. Passengers Price Max. Speed Price Tonnage CAR Vehicleld TRUCK License. Plate. NO (b) License. Plate. No Price Vehicleld No. Of. Passengers v 1 v 2 v 3 v 4 v 5 VEHICLE d Max. Speed CAR v 1 v 2 Vehicleld v 3 v 4 v 5 License. Plate. NO v 1 v 2 v 3 v 4 v 5 v 6 v 7 No. Of. Axles Tonnage TRUCK Figure 4. 3 Examples of generalization. (a) Two entity types CAR and TRUCK. (b) Generalizing CAR and TRUCK into VEHICLE. 12

Constraints on Specialization and Generalization • single subclass only EMPLOYEE – {MANAGER} specification • predicate-defined subclasses (condition-defined) – determined by a condition MANAGER – (Job. Type = ‘Secretary’) <--- defining predicate – attribute-defined specialization (see Figure 4. 4 at 4 -14) • membership condition on the same attribute of the superclass (defining attribute) • user-defined subclass Membership is specified – determined by the database users individually for each entity. – {HOURLY_EMPLOYEE, SALARIED_EMPLOYEE} 13

FName Minit LName Ssn Birth. Date Address Job. Type EMPLOYEE Job Type defining attribute d “Secretary” Typing Speed “Engineer” “Technician” SECRETARY TGrade TECHNICIAN predicate condition Eng. Type ENGINEER Figure 4. 4 Attribute-defined specialization on the Job. Type attribute of EMPLOYEE 14

Constraints (continued) • disjointness constraint – an entity can be a member of at most one of the subclasses of the specialization – attribute-defined specialization --> defining attribute is singled-valued – d : disjoint for attribute/user-defined subclass – o : an entity may be a member of more than one subclass of a specialization 15

Part. No Description PART o Manufacture. Date Drawing. No overlap Supplier. Name Batch. No MANUFACTURED_PART List. Price PURCHASED_PART Figure 4. 5 Specialization with nondisjoint (overlapping) subclasses. 16

Constraints (continued) • completeness constraint (4 -7) – total specialization constraint • every entity in the superclass must be a member of some subclass in the specialization • e. g. , {HOURLY_EMPLOYEE, SALARIED_EMPLOYEE} • notation: superclass – partial specialization constraint • an entity may not belong to any of the subclasses • e. g. , {SECRETARY, ENGINEER, TECHNICIAN} 17

Constraints (continued) • disjointness and completeness constraints are independent – Disjoint, total – Disjoint, partial – Overlapping, total – Overlapping, partial • a superclass identified through generalization process usually is total 18

Some insertion/deletion rules for specialization/generalization • Deleting an entity from a superclass – it is automatically deleted from all the subclasses to which it belongs • Inserting an entity in a superclass – it is mandatorily inserted in all predicate-defined (or attribute -defined) subclasses for which it satisfies the defining predicate • Inserting an entity in a superclass of a total specialization – it is mandatorily inserted in at lease one of subclasses 19

Specialization/Generalization Hierarchies and Lattices • A subclass itself may have further subclasses specified on it. – Specialization hierarchy • every subclass participates as a subclass in only one class/subclass relationship – Specialization lattice • a subclass can be a subclass in more than one class/subclass relationship 20

Figure 4. 6 Specialization lattice with the shared subclass EMGINEERING_MANAGER. . EMPLOYEE e 1 e 2 e 3 e 4 e 5 e 6 e 7 e 8 e 9 e 10 d SECRETARY e 1 e 2 TECHNICIAN e 3 e 4 ENGINEER e 5 e 6 e 7 e 8 d MANAGER e 8 e 9 HOURLY_EMPLOYEE SALARIED_EMPLOYEE ENGINEERING_MANAGER e 8 shared subclass multiple inheritance lattice e 6 e 7 e 8 e 9 e 10 e 1 e 2 e 3 e 4 e 5 21

Sex Name Figure 4. 7 Specialization lattice for a UNIVERSITY database. SSN Address PERSON P 1 P 2 P 3 P 4 P 5 EMPLOYEE P 6 P 7 P 8 P 9 P 10 o ALUMNUS Birth. Date An entity may exist in several leaf nodes of the hierarchy e. g. GRADUATE_STUDENT RESEARCH ASSISTANT STUDENT Degrees Year d Degree Major d Percent Time STAFF FACULTY Position STUDENT_ ASSISTANT Rank Project GRADUATE_ STUDENT shared subclass multiple inheritance Degree. Program d (inherited only once) leaf node UNDERGRADUATE_ STUDENT Class Course RESEARCH_ASSISTANT TEACHING_ASSISTANT A subclass inherits attributes of all its predecessor superclasses 22

Specialization/Generalization in Conceptual Data Modeling • top-down conceptual refinement process – a specialization process • bottom-up conceptual synthesis – a generalization process • combination 23

union type (or category) • a single superclass vs. more than one superclass – ENGINEERING_MANAGER is a subclass in three distinct superclass/subclass relationship (4 -21) – Each has single superclass • union type or category – model a single superclass/subclass relationship with more than one superclass – the subclass represents a collection of objects that is (a subset of) the UNION of distinct entity types – e. g. , OWNER is a subclass of the UNION of (COMPANY, BANK, PERSON) 24

BName SSN Driver. License. No Name BAddress BANK Address PERSON P 1 P 2 P 3 P 4 CName b 1 b 2 b 3 Figure 4. 8 Two categories: OWNER and REGISTERED_VEHICLE. c 1 c 2 COMPANY u P 1 P 2 b 1 c 1 CAddress set union operation OWNER Lien. Or. Regular Purchase. Date M OWNS N License. Plate. No REGISTERED_VEHICLE CYear CMake CModel CStyle Vehicleld CAR c 1 c 2 c 3 c 1 c 2 u t 1 set union operation TYear TMake TModel Tonnage TRUCK t 1 Vehicleld 25

category vs. shared subclass • intersection Only cars & trucks can be members of REGISTERED_VEHI Category CLE superclass Partial: VEHICLE may contain other types of entities VS. generalized – shared subclass (Fig. 4. 6, 4 -21) REGISTERED_VEHICLE 4. 25) (Fig. 4. 3, 4 -12) – ENGINEERING_MANAGER (Fig. is a 4. 8, subset of the intersection of ENGINEER, MANAGER, and SALARIED_EMPLOYEE – an engineering manager must be an ENGINEER, a MANAGER, and a SALARIED_EMPLOYEE – ENGINEERING_MANAGER inherits all the attributes of its superclasses • union – category (Fig. 4. 8, 4 -25) – OWNER is a subset of the union of COMPANY, a BANK, or a person – an OWNER may be a COMPANY, a BANK, or a PERSON – an OWNER entity inherits the attributes depending on the superclass to which the entity belongs 26

A category can be total or partial. (a) COMPANY c 1 c 2 c 3 c 4 PERSON C 1 C 2 P 1 P 2 Figure 4. 9 Categories. (a) Partial category ACCOUNT_HOLDER that is a subset of the union of two entity types COMPANY and PERSON. (b) Total category PROPERTY and a similar generalization. predicate conditions u partial c 1 c 2 P 1 ACCOUNT_ HOLDER HAS_ ACCT BANK (b) BUILDING total category b 1 b 2 b 3 LOT PROPERTY l 1 l 2 total specialization/ generalization d u total b 1 l 1 b 2 l 2 b 3 PROPERYT BUILDING LOT 27

An Example UNIVERSITY EER Schema 28

FName Minit LName Ssn BDate Name Sex No Street Apt. No PERSON City State Zip Address d FOffice FPhone Rank Salary FACULTY 1 ADVISOR M 1 COMMITTEE College Year STUDENT Degrees N GRAD_STUDENT Title No GRANT Agency St. Date Start M BELONGS CHAIRS Degree P 1 N 1 Class N N SUPPORT Time u M N End 1 REGISTERED MINOR 1 INSTRUCTOR_RESEARCHER N N MAJOR Grade 1 TRANSCRIPT 1 TEACH N CURRENT_SECTION N COLLEGE COffice 1 Dean CName CD DPhone CS Office N 1 1 DC N Sec# Year Qtr SECTION DEPARTMENT DName M COURSE N C# CName Figure 4. 10 ERR conceptual schema for a UNIVERSITY database Cdesc 29

Formal Definitions • class – a set or collection of entities, including any of the EER schema constructs that group entities such as entity types, subclasses, superclasses, and categories • subclass S – a class whose entities must always be a subset of the entities in another class C (superclass) of the superclass/subclass relationship C/S – S C 30

Formal Definitions (continued) • specialization Z = {S 1, S 2, …, Sn) – a set of subclasses that have the same superclass G – G/Si is a superclass/subclass relationship generalized entity type • • generalization total disjoint predicate-defined partial (otherwise) overlapping (otherwise) user-defined (otherwise) – a predicate p on the attributes of G is used to specify which entries in G are members of S 31

Formal Definitions (continued) • specialization Z (generalization G) is attribute-defined attribute – a predicate (A=ci) is used to specify membership in each subclass Si in Z • category T – a class that is a subset of the union of n defining superclasses D 1, D 2, …, Dn – T (D 1 D 2 … Dn) • relationship type: allow class to participate in a relationship 32

Conceptual Object Modeling Using UML Class Diagrams • UML - Universal Modeling Language • OMT - Object Modeling Technique 33

Multipicities min. . max (* : no maximum limit) (relationship constraints) class name attributes composite attributes operations qualified aggregation (identifying relationship) association (relationship types) domain link attribute (relationship attribute) role multivalued attribute is modeled a class role reflexive association (recursive relationship) a relationship between a whole object and its component parts 4 -33. 1 34

generalization / specialization overlapping disjoint 4 -33. 2 35

Relationships of Higher Degree • Relationship types of degree 2 are called binary • Relationship types of degree 3 are called ternary and of degree n are called n-ary • In general, an n-ary relationship is not equivalent to n-binary relationships 4 -34 36

Ternary Relationship Types (a) SName PROJECT SUPPLY SUPPLIER Part. No The ternary relationship type SUPPLY PART (b) SName Proj. Name M SUPPLIER ternary relationship M SUPPLIES more informative (s, p), (j, p), (s, j) --? --> (s, j, p) <---SName Some DB tools permit only binary relationship. 1 PROJECT M USES PART N SUPPLIER owner N Part. No CAN_SUPPLY (c) Proj. Name Quantity SS N Three binary relationship types. They are not equivalent to SUPPLY Quantity N identifying relationship Part. No SUPPLY N SP 1 Proj. Name N SPJ 1 PROJECT owner SUPPLY represented as a weak entity type PART owner 4 -35 37

TAUGHT_DURING Semester Year Sem_Year IName INSTRUCTOR OFFERS SEMESTER CAN_TEACH OFFERED_DURING CNumber COURSE Another example of ternary versus binary relationship types. (i, s, c) -----> (i, s), (s, c), (i, c) <--? -- (i, s), (s, c), (i, c) <----- (i, s), (s, c), (i, c) + CAN_TEACH (1: 1) Name CCI CANDIDATE Department COMPANY A weak entity type INTERVIEW, with a ternary identifying relationship type. Date Dept/Date INTERVIEW RESULTS_IN The weak entity type has two owner entity types. 4 -36 JOB_OFFER 38