Chapter 4

1. Chapter 4 4.1 Subclasses, Superclasses, and Inheritance4.2 Specialization and Generalization4.3 Constraints and Characteristics of Specialization and Generalization4.4 Modeling of UNION Types Using Categories4.5 An Example UNIVERSITY EER Schema and Formal Definitions for the EER Model4.6 Conceptual Object Modeling Using UML Class Diagrams4.7 Relationship Types of Degree Higher Than Two 4.8 Data Abstraction and Knowledge Representation Concepts4.9 Summary Enhanced Entity-Relationship and Object Modeling

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

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

4. attributes relationships subclass • 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 • class/subclass relationship • e.g., EMPLOYEE/SECRETARY ‧An entity must also be a member of the superclass‧An entity can be a member of any number of subclasses‧It is not necessary that every entity in a superclass be a member of some subclasses.

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

6. Specialization and Generalization • specialization • define a set of subclasses of an entity type • {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 superclass

7. Figure 4.1 EER diagram for representing specialization an d subclasses. FName Minit LName Name Ssn BirthDate Address EMPLOYEE completeness constraint: partial specialization completeness constraint : total specialization subsetsymbol disjointness constraint disjointness constraint specific disjoint attributes subsetsymbol specific (local) attributes d d subsetsymbol Typing Speed TGrade EngType Pay Scale SECRETARY TECHNICIAN ENGINEER MANAGER Salary HOURLY_EMPLOYEE SALARIED_EMPLOYEE MANAGES BELONGS_TO specific relationship specific relationship Three specializations of EMPLOYEE: (SECRETARY, TECHNICIAN, ENGINEER) (MANAGER) (HOURLY_EMPLOYEE, SALARIED_EMPLOYEE) PROJECT TRADE_UNION

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

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

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

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

12. (a) NoOfPassengers NoOfAxles Price Price MaxSpeed Tonnage CAR TRUCK Vehicleld Vehicleld LicensePlateNO LicensePlateNo LicensePlateNO (b) Price Vehicleld v1 v2v3v4v5v6v7 VEHICLE v1v2v3v4v5 d NoOfPassengers NoOfAxles MaxSpeed Tonnage CAR TRUCK v3v3v4v4v5 v5 v1v1v2v2 Figure 4.3 Examples of generalization. (a) Two entity types CAR and TRUCK. (b) Generalizing CAR and TRUCK into VEHICLE.

13. Constraints onSpecialization and Generalization EMPLOYEE • single subclass only • {MANAGER} specification • predicate-defined subclasses • determined by a condition • (JobType = ‘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 • determined by the database users • {HOURLY_EMPLOYEE, SALARIED_EMPLOYEE} MANAGER (condition-defined) Membership is specified individually for each entity.

14. FName Minit LName Name Ssn BirthDate Address JobType EMPLOYEE defining attribute Job Type d predicate condition “Secretary” “Engineer” Typing Speed TGrade EngType “Technician” SECRETARY TECHNICIAN ENGINEER Figure 4.4 Attribute-defined specialization on the JobType attribute of EMPLOYEE

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

16. PartNo Description PART overlap o ManufactureDate SupplierName DrawingNo BatchNo ListPrice MANUFACTURED_PART PURCHASED_PART Figure 4.5 Specialization with nondisjoint (overlapping) subclasses.

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

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

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

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

21. Figure 4.6 Specialization lattice with the shared subclass EMGINEERING_MANAGER.. EMPLOYEE e1e2e3e4e5e6e7e8e9e10 d d SECRETARY TECHNICIAN ENGINEER MANAGER HOURLY_EMPLOYEE e1e2 e3e4 e5e6e7e8 e8e9 SALARIED_EMPLOYEE e1e2e3e4e5 e6e7e8e9e10 lattice ENGINEERING_MANAGER shared subclass multiple inheritance e8

22. Figure 4.7 Specialization lattice for a UNIVERSITY database. Sex Name Address SSN PERSON BirthDate An entity may exist in several leaf nodes of the hierarchye.g. GRADUATE_STUDENT RESEARCH ASSISTANT P1 P6P2 P7P3 P8P4 P9P5 P10 o EMPLOYEE ALUMNUS STUDENT Degrees d Year Degree Major d Percent Time STUDENT_ ASSISTANT GRADUATE_ STUDENT UNDERGRADUATE_ STUDENT STAFF FACULTY shared subclass multiple inheritance (inherited only once) Position Rank d DegreeProgram Class leaf node Project Course RESEARCH_ASSISTANT TEACHING_ASSISTANT A subclass inherits attributes of all its predecessor superclasses

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

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

25. BName BAddress BANK b1b2b3 SSN Name Address CName CAddress c1c2 DriverLicenseNo PERSON COMPANY P1P2P3P4 u set union operation P1P2b1c1 Figure 4.8 Two categories: OWNER and REGISTERED_VEHICLE. OWNER LienOrRegular M PurchaseDate OWNS N LicensePlateNo REGISTERED_VEHICLE c1c2t1 CYear u TYear CModel CMake setunionoperation TMake TModel c1c2c3 CStyle Tonnage CAR TRUCK Vehicleld t1t2 Vehicleld

26. Only cars & trucks can be members of REGISTERED_VEHICLE Partial: VEHICLE may contain other types of entities category vs. shared subclass Category VS. generalized superclassREGISTERED_VEHICLEVEHICLE(Fig. 4.8, 4.25) (Fig. 4.3, 4-12) • intersection • shared subclass (Fig. 4.6, 4-21) • ENGINEERING_MANAGER is a 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

27. A category can be total or partial. 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. (a) COMPANY PERSON c1 c2c3c4 P1P2predicate conditions C1 C2 u partial HAS_ ACCT c1 c2P1 ACCOUNT_ HOLDER BANK specialization/generalization (b) BUILDING LOT PROPERTY total category b1 b2b3 l1 l2 total d u total b1 l1 b2 l2 b3 PROPERYT BUILDING LOT

28. An Example UNIVERSITYEER Schema

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

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

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

32. Formal Definitions(continued) attribute • specialization Z (generalization G) is attribute-defined • 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 D1, D2, …, Dn • T  (D1  D2  …  Dn) • relationship type: allow class to participate in a relationship

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

34. Multipicities min..max(* : no maximum limit)(relationship constraints)association(relationship types) class name attributes domain compositeattributes link attribute(relationship attribute) operations multivaluedattributeis modeleda class role role qualifiedaggregation reflexiveassociation(recursive relationship) (identifyingrelationship) a relationship between a whole object and its component parts 4-33.1

35. generalization / specialization overlapping disjoint 4-33.2

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

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

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