Enhanced Entity-Relationship and Object Modeling 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

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

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

subclass entity type (a type of entity) 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 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.

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

Specialization and Generalization 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

completeness constraint: partial specialization 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 subset symbol disjointness constraint disjointness constraint specific disjoint attributes subset symbol specific (local) attributes d d subset symbol 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

. . e e superclass/subclass relationship: SECRETARY . e 1 4 5 2 7 3 8 EMPLOYEE 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 relationship at the instance level same entity in specialized role

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 工會

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

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 alternative generalization VEHICLE VEHICLE specialization CAR TRUCK CAR TRUCK

v1 v2 v3 v4 v5 v6 v7 v1 v2 v3 v4 v5 v3 v3 v4 v4 v5 v5 v1 v1 v2 v2 (a) NoOfPassengers NoOfAxles Price Price MaxSpeed Tonnage CAR TRUCK Vehicleld Vehicleld LicensePlateNO LicensePlateNo (b) LicensePlateNO Price Vehicleld v1 v2 v3 v4 v5 v6 v7 VEHICLE v1 v2 v3 v4 v5 d NoOfPassengers NoOfAxles MaxSpeed Tonnage CAR v3 v3 v4 v4 v5 v5 TRUCK v1 v1 v2 v2 Figure 4.3 Examples of generalization. (a) Two entity types CAR and TRUCK. (b) Generalizing CAR and TRUCK into VEHICLE.

Constraints on Specialization and Generalization 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} EMPLOYEE MANAGER (condition-defined) Membership is specified individually for each entity.

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

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

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

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}

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

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

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

lattice shared subclass multiple inheritance Figure 4.6 Specialization lattice with the shared subclass EMGINEERING_MANAGER.. EMPLOYEE e1 e2 e3 e4 e5 e6 e7 e8 e9 e10 d d SECRETARY TECHNICIAN ENGINEER MANAGER HOURLY_EMPLOYEE e1 e2 e3 e4 e5 e6 e7 e8 e8 e9 SALARIED_EMPLOYEE e1 e2 e3 e4 e5 e6 e7 e8 e9 e10 lattice ENGINEERING_MANAGER e8 shared subclass multiple inheritance

A subclass inherits attributes of all its predecessor superclasses Figure 4.7 Specialization lattice for a UNIVERSITY database. Name Sex Address SSN PERSON BirthDate An entity may exist in several leaf nodes of the hierarchy e.g. GRADUATE_STUDENT RESEARCH ASSISTANT P1 P6 P2 P7 P3 P8 P4 P9 P5 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

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

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)

c1 c2 b1 b2 b3 P1 P2 P3 P4 set union operation P1 P2 b1 c1 c1 c2 t1 BName BAddress BANK SSN Name Address b1 b2 b3 CName CAddress c1 c2 DriverLicenseNo PERSON COMPANY P1 P2 P3 P4 u set union operation P1 P2 b1 c1 Figure 4.8 Two categories: OWNER and REGISTERED_VEHICLE. OWNER LienOrRegular M PurchaseDate OWNS N LicensePlateNo REGISTERED_VEHICLE c1 c2 t1 CYear u TYear CModel CMake set union operation TMake TModel CStyle c1 c2 c3 Tonnage CAR TRUCK Vehicleld Vehicleld t1 t2

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

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 c2 c3 c4 P1 P2 predicate conditions C1 C2 u partial HAS_ ACCT c1 c2 P1 ACCOUNT_ HOLDER BANK (b) specialization/ generalization BUILDING LOT PROPERTY total category b1 b2 b3 l1 l2 total d u total b1 l1 b2 l2 b3 PROPERYT BUILDING LOT

An Example UNIVERSITY EER Schema

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

Formal Definitions class subclass S 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

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

Formal Definitions (continued) 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 attribute

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

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

generalization / specialization overlapping disjoint 4-33.2

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

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

The weak entity type has two owner entity types. TAUGHT_DURING Semester Year IName Sem_Year OFFERS INSTRUCTOR 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 CName CCI CANDIDATE COMPANY A weak entity type INTERVIEW, with a ternary identifying relationship type. Department Date Dept/Date RESULTS_IN INTERVIEW JOB_OFFER The weak entity type has two owner entity types. 4-36