4-1

Chapter 4Enhanced Entity-Relationship and Object Modeling

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

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

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

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, MA

NAGER, SALARIED_EMPLOYEE, HOURLY_EMPLOYEE

• class/subclass relationship– e.g., EMPLOYEE/SECRETARY

attributes

relationships

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

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

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

4-7

EMPLOYEE

SECRETARY TECHNICIAN ENGINEER MANAGER

PROJECT

SALARIED_EMPLOYEE

HOURLY_EMPLOYEE

TRADE_UNION

MANAGES BELONGS_TO

FName Minit LName

Name Ssn BirthDate Address

Typing Speed TGrade EngType

Salary

Pay Scale

d

d

Three specializations of EMPLOYEE:(SECRETARY, TECHNICIAN, ENGINEER)(MANAGER)(HOURLY_EMPLOYEE, SALARIED_EMPLOYEE)

Figure 4.1 EER diagram for representing specialization an d subclasses.

completeness constraint :

total specialization

completeness constraint:

partial specialization

disjointness constraint

disjointness constraint specific

disjoint attributes

specific (local) attributes

subsetsymbol

subsetsymbol

subsetsymbol

specific relationship specific

relationship

4-8

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

eeeeeeee

1

2

3

4

5

6

7

8

eee

ee

ee

1

4

5

2

7

3

8

SECRETARY

ENGINEER

TECHNICIAN

EMPLOYEE

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

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

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

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

CAR TRUCK CAR TRUCK

specialization

4-12

MaxSpeed

NoOfPassengers

Vehicleld

Price

LicensePlateNO

NoOfAxles

Price

Tonnage

Vehicleld

LicensePlateNo

LicensePlateNOPriceVehicleld

NoOfPassengers

MaxSpeed

NoOfAxles

Tonnage

CAR TRUCK

VEHICLE

CAR TRUCK

d

(b)

(a)

Figure 4.3 Examples of generalization. (a) Two entity types CAR and TRUCK. (b) Generalizing CAR and TRUCK into VEHICLE.

v1 v1v2 v2

v3 v3v4 v4v5 v5

v1v2v3v4v5

v1 v2v3v4v5v6v7

4-13

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

4-14

EMPLOYEE

SECRETARY TECHNICIAN ENGINEER

FName Minit LName

Name Ssn BirthDate Address

Typing Speed TGrade EngType

d

JobType

Job Type

“Engineer”“Secretary”

“Technician”

Figure 4.4 Attribute-defined specialization on the JobType attribute of EMPLOYEE

defining attribute

predicate condition

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

4-16

PART

MANUFACTURED_PART PURCHASED_PART

PartNo Description

DrawingNo BatchNo ListPrice

o

Figure 4.5 Specialization with nondisjoint (overlapping) subclasses.

ManufactureDateSupplierName

overlap

4-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}

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

4-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 attribut

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

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

4-21

EMPLOYEE

SECRETARY TECHNICIAN ENGINEER MANAGER

SALARIED_EMPLOYEE

HOURLY_EMPLOYEE

d

d

Figure 4.6 Specialization lattice with the shared subclass EMGINEERING_MANAGER..

ENGINEERING_MANAGER

shared subclassmultiple inheritance

e1e2e3e4e5e6e7e8e9e10

e1e2

e3e4

e5e6e7e8

e8e9 e1

e2e3e4e5

e6e7e8e9e10

e8lattice

4-22

PERSON

STAFF FACULTYSTUDENT_ASSISTANT

ALUMNUS

RESEARCH_ASSISTANT

GRADUATE_STUDENT

UNDERGRADUATE_STUDENT

TEACHING_ASSISTANT

SexName

SSN BirthDate

Address

Position Rank

Percent Time

ClassDegreeProgram

d d

o

d

EMPLOYEE STUDENT

Degrees

Year Degree Major

Project Course

Figure 4.7 Specialization lattice for a UNIVERSITY database.

leaf node

shared subclassmultiple inheritance(inherited only once)

P1 P6P2 P7P3 P8P4 P9P5 P10

An entity may exist in several leaf nodes of the hierarchye.g. GRADUATE_STUDENT RESEARCH ASSISTANT

A subclass inherits attributes of all its predecessor superclasses

4-23

Specialization/Generalizationin Conceptual Data Modeling

• top-down conceptual refinement process– a specialization process

• bottom-up conceptual synthesis– a generalization process

• combination

4-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)

4-25

BANK

PERSON COMPANY

OWNER

CAR

REGISTERED_VEHICLE

TRUCK

OWNS

Address

BName BAddress

NameSSN CName CAddress

TModel

Vehicleld

TYear

TMake

Tonnage

u

u

DriverLicenseNo

Vehicleld

CYear

CModelCMake

CStyle

LicensePlateNo

LienOrRegular

PurchaseDateM

N

Figure 4.8 Two categories: OWNER and REGISTERED_VEHICLE.

b1b2b3P1

P2P3P4

set union operation

c1c2

P1P2b1c1

c1c2t1

c1c2c3

setunionoperation

t1t2

4-26

category vs. shared subclass

• 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

Only cars & trucks can be members of REGISTERED_VEHICLE

Partial: VEHICLE may contain other types of entities

Category VS. generalized superclassREGISTERED_VEHICLE VEHICLE(Fig. 4.8, 4.25) (Fig. 4.3, 4-12)

4-27

COMPANY PERSON

ACCOUNT_HOLDER

BUILDING

BANK

LOT

HAS_ACCT

u

d

C1 C2

u

PROPERTYLOTBUILDING

PROPERYT

(b)

(a)

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 category can be total or partial.

c1 c2c3c4

P1P2

predicate conditions

partial

b1 b2b3

c1 c2P1

l1 l2

b1 l1 b2 l2 b3

specialization/generalization

total

total

total category

4-28

An Example UNIVERSITYEER Schema

4-29

PERSON

COLLEGE COURSE

DEPARTMENT

GRAD_STUDENT

INSTRUCTOR_RESEARCHER

Sex

Name

Ssn BDate

Address

u

d

FACULTY

STUDENT

Degrees

YearDegreeCollege

FName Minit LName No Street AptNo City State Zip

FOffice Rank Salary

FPhone

ADVISOR

COMMITTEE

CHAIRS

BELONGS

P1

CS

SECTION

CURRENT_SECTION

MINOR

MAJOR

REGISTERED

TRANSCRIPT

TEACH

GRANT

SUPPORT

Title No

Agency

StDateStart

Time

End

Class

Grade

YearSec#

Qtr

COfficeCName

Dean CdescCNameC#

CD DC

DName DPhone Office

1 N

M N

1

N

M

N1

1

N

NN

N

1

1

M

M

1

N

1

1N

N

N

1

Figure 4.10 ERR conceptual schema for a UNIVERSITY database

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

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

GSn

ii

1 SS ji

generalized entity type

4-32

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

)...( 2211 nn PDPDPDT

4-33

Conceptual Object Modeling Using UML Class Diagrams

• UML - Universal Modeling Language

• OMT - Object Modeling Technique

4-33.1 4-34

classname

attributes

compositeattributes

operations

domain

qualifiedaggregation

(identifyingrelationship)

Multipicities min..max (* : no maximum limit)(relationship constraints) association(relationship types)

link attribute(relationship attribute)

role

role

reflexiveassociation(recursive relationship)

multivaluedattributeis modeleda class

a relationship between a whole object and its component parts

4-33.2 4-35

generalization / specialization

overlapping

disjoint

4-34 4-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-35 4-37

Ternary Relationship TypesProjName

SName ProjName

PartNo

SName Quantity ProjName

PartNo

PROJECT

PART

SUPPLIER PROJECT

PART

SUPPLIER SUPPLY PROJECT

PART

SUPPLY

SUPPLIES

CAN_SUPPLY USES

SS SPJ

SP

PartNo

SName

SUPPLIER

Quantity(a)

(b)

(c)

M N

M M

NN

1 N N 1

N

1

The ternary relationship type SUPPLY

SUPPLY represented as a weak entity type

Three binary relationship types.They are not equivalent to SUPPLY

owner

owner owneridentifyingrelationship

(s,p), (j,p), (s,j) --?--> (s, j, p) <----

ternary relationship

more informative

Some DB tools permit only binary relationship.

4-36 4-38

TAUGHT_DURING

OFFERS

CAN_TEACH OFFERED_DURING

CCI

RESULTS_IN

INSTRUCTOR SEMESTER

COURSE

CANDIDATE COMPANY

INTERVIEW JOB_OFFER

IName Sem_Year

CNumber

YearSemester

Name CName

Department Date

Dept/Date

A weak entity type INTERVIEW, with a ternary identifying relationship type.

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)

The weak entity type has two owner entity types.