Chapter 4: Enhanced Entity-Relationship (EER) Modeling

Chapter 4: Enhanced Entity-Relationship (EER)

Modeling

Data Modeling and Database Design

Chapter 4 – Enhanced Entity-Relationship (EER) Modeling 2

Remember!

• Presentation Layer ER Diagram Contains hashes and oval

• Design-specific ER Diagram (Coarse-granularity) Uses (min, max) notation Maps deletion rules

• Design-specific ER Diagram (Fine-granularity) Maps attribute characteristics into ER diagram Decomposes multi-valued attributes Decomposes m:n relationships


Enhanced Entity-Relationship (EER) Model

• Enhanced Entity-Relationship (EER) modeling is an extension to the ER modeling that incorporates additional constructs

• Central constructSuperclass/subclass (SC/sc) relationship

• More specifically:– Specialization/generalization– Categorization– Aggregation


Superclass/Subclass Relationship (SC/sc)

STORE Sells FURNITURE

CHAIR TABLE SOFA

Inter-Entity Class Relationship(Has-a Relationship)

Intra-Entity Class Relationship(Is-a Relationship)

Figure 4.4 I nter-entity and intra-entity class relationships

A STORE has a relationship with FURNI TURE

There are 3 SC/ sc relationships shown here.

A CHAI R is a FURNI TURE.A TABLE is a FURNI TURE.A SOFA is a FURNI TURE.

A CHAI R is a FURNI TURE.

CHAI R, TABLE, and SOFA are entity types that belong to the entity class FURNI TURE.


e1

e2

e3

e4

e5

e6

e7

e8

e1

e4

e5

e2

e7

e3

e8

.

.

.

.

.

.

.

.

.

FURNITURE

CHAIR

TABLE

SOFA

Figure 4.5 Superclass/ subclass entity instances

An Instance Diagram


Think About It…

• Theoretically, one has three choices of modeling furniture/chair/table/sofa– Model three separate entity types for chair, table,

and sofa, and create three separate relationship types with the entity type store

– Model furniture as an entity type with an attribute called furniture_type; then chair, table, and sofa would be values of that attribute

– Model furniture as a superclass/subclass


SC/sc Relationships

• There are two basic kinds of Sc/sc relationships– Specialization/Generalization: One superclass

(SC) is related to one or more subclasses (sc)– Categorization: One subclass (sc) is related to

one or more superclasses (SC)


Vignette 1


Modeling Vignette 1: Alternative 1






Properties of SC/sc Relationships

• An entity that exists in a subclass can be associated with only one superclass entity

• An entity cannot exist in the database merely by being a member of a subclass; it must also be a member of an associated superclass

• An entity that is a member of a superclass can be optionally included as a member of any number of its subclasses

• It is not required that every member of a superclass be a member of a subclass


Properties of SC/sc Relationships (continued)

• Type Inheritance Property: A subclass inherits all the attributes of the superclass to which it is related– In addition, it will also inherit all the relationship

types in which the superclass participates• A subclass may also have its own specific attributes

in addition to the attributes inherited– Likewise, a subclass may have its own specific

relationship(s) with other entity types (i.e., inter-entity class relationships)


Note That…

• The cardinality ratio of any SC/sc relationship is always 1:1

• The participation of the subclass in a SC/sc relationship is always total

• A subclass inherits all attributes as well as all relationship types that a superclass possesses (type inheritance property)


Specialization and Generalization

• Specialization is the process of generating subgroups (‘sc’s) of a generic entity class (SC) by specifying the distinguishing properties (attributes) of the subgroups (= top-down approach)

• Generalization, on the other hand, crystallizes the common properties (attributes) shared by a set of entity types (‘sc’s) into a generic entity type (SC) (= bottom-up approach)

• Notation: circle + fork (indicating subset)• Read: “is-a”


Specialization and Generalization (continued)

• Completeness ConstraintThe participation of the superclass in a specialization/ generalization is referred to as the completeness constraint and can assume one of two values: total or partial – Total specialization means that every entity of the

superclass must participate in this specialization/ generalization relationship (indicated by a solid line from the superclass to the specialization/generalization symbol (i.e., the circle))

– Partial specialization means that there may be entities present in the superclass that do not participate in this specialization/generalization (indicated by a dotted line)


Specialization and Generalization (continued)

• Disjointness ConstraintUsed to specify that the subclasses of a specialization must be: – Disjointed (indicated by ‘D’), i.e., an entity of the

superclass cannot be a member of more than one subclass

– Overlapped across subclasses (indicated by ‘O’)• Please note that you have to specify both:

completeness and disjointness constraints!


Notation


An EER Model of Vignette 1


Sample Data Sets For EER Model of Vignette 1


An Extension of Vignette 1: Multiple Specializations


Sample Data Sets For Vignette 1 Extension




Specialization/Generalization Hierarchy

• Example of a Hierarchy: [STUDENT -> STUDENT_ATHLETE -> FOOTBALL_PLAYER -> {DEFENSIVE_PLAYER, OFFENSIVE_PLAYER}] shows a 3-level hierarchy

• InheritanceA subclass inherits the attributes and relationship types of not just the immediate parent, but also of the predecessor superclasses in the hierarchy all the way up to the root of the specialization hierarchy




Specialization/Generalization Lattice

• In a specialization lattice, an entity type can participate as a subclass in more than one specialization (i.e., a child can have more than one parent)

• InheritanceThe subclass will inherit all the attributes and relationship types from the superclasses of all the specializations participating in the lattice and the predecessor hierarchy of all these superclasses– This is called multiple type inheritance, and the

subclass in the lattice is referred to as a shared subclass


The Categorization Construct

• A categorization occurs when a subclass is associated with more than one superclass of different entity types– The subclass is called category

• An entity that is a member of the category (subclass) must exist in ONLY ONE of the superclasses in the categorization relationship

• Example: A financial donor can be an individual, a company, or a foundation no “is-a” relationship!

• Notation: ‘U’ (= union, the subclass is a subset of the union of the superclasses)


Categorization Example


Characteristics of a Categorization

• There is only one subclass in each categorization• The cardinality ratio is 1:1 within and across the

SC/sc relationship• The participation of the subclass in the categorization

is always total


Characteristics of a Categorization (continued)• Each superclass may exhibit either total or partial

participation• A category can either be:

– A total category (i.e., the category is the union of all the superclass entities)

– A partial category (i.e., the category is a true subset of the union of all the superclass entities)

• A category possesses the property of selective type inheritance (i.e., it inherits attributes of one entity type only)

• Often a unique identifier for a category must be manufactured (which is called a surrogate key)


Sample Data Sets For Categorization Example


Choosing the Appropriate EER Construct

Exercise: • Part1: Consider an automobile dealership in the state

of Texas; the dealership typically stocks cars, trucks, vans, and sport utility vehicles (SUVs)

• Part 2: Not all vehicles in the dealership are registered vehicles though– How would we model REGISTERED_VEHICLE?

• One exception exists in which a categorization and a generalization/specialization are mutually substitutable constructs: in the case of a total category!


Choosing the Appropriate EER Construct (continued)








The Aggregation Construct• An aggregation allows us to model a “whole/part”

relationship as an “is-a-part-of” relationship between a subclass and a superclass

• An entity in the aggregate contains superclass entities from ALL SC/sc relationships in which it participates

• Inheritance: Selective type inheritance connotes the inheritance of attributes and relationships from ALL superclass entities contained in the specific aggregation

• Notation: ‘A’• Read: “is-part-of”• Note that an aggregate can never be partial


An Example of Aggregation


An Aggregation Hierarchy


Aggregation Versus Categorization


STUDENT_ATHLETE

FOOTBALL_PLAYER

BASKETBALL_PLAYER

BASEBALL_PLAYER

d1

U U U

Gpa

Weight

Height

TouchdownsSpeed

Position

Pts_per_game

Assists_per_game

Rebounds_per_game

Batting_avg

Home_runs

Errors"Football" "Basketball" "Baseball"

TEAM_CAPTAIN

VARSITY_PLAYER

INTRAMURAL_PLAYER

U

d3

U U

TeamScholarship Redshirt

(0,1)

STUDENT

DEFENSIVE_PLAYER

OFFENSIVE_PLAYER

o

U U

PITCHER

U

No_of_tacklesNo_of_interceptions Yards_gainedReceptionsEra Pitching_speed

Innings_pitched

Strikeouts

Walks

U

Major

Student#Name

F_b_b

Figure 4.20 A Fine-granular Design-Specific ER Diagram

Uniform#

Uniform#

POSITION_BA

Bpid

[N,6][A,30]

[N,1.2][A,25]

[A,1]

[N,2]

[N,3]

[N,2][N,2.2]

[N,2]

[N,2]

[A,15]

[N,2.1]

[N,2.1]

[N,2.1]

[N,1.3]

[N,2]

[N,2]

[N,3]

[N,3]

[N,3.1]

[N,3]

[N,2.2][N,3][N,3][N,2] [N,4]

[A,1] [A,1]

Plays_pitcher(0,1) (1,1)

Position-----------

[A,15]

Plays_position

N[A,15]

(1,n)

(1,1)

F_b_b_value

C

C

d2

ORGANIZATION

Sponsored_by

Name

Type

(1,n)

[A,20]

[A,2]

League

Auto

POSITION_BK

Plays_position

Plays_position

(1,n)

(1,1)

C

[A,15]Position-----------

A Fine-granular Design-Specific EER Diagram for Vignette 3


EMPLOYEE

Works_in

Managed_by

PLANT

Undertaken_by

PROJECT

Assigned

Dependent_of

Supervised_by

Held_by_E

DEPENDENT

ParticipatesHeld_by_D

HOBBY

BANK_ACCOUNT

Supports

SPONSOR

NOT_FOR_PROFIT_ORGANIZATION CHURCH SCHOOL INDIVIDUAL

PUBLIC_SCHOOL

U

Name_tag

Lname

MinitName

Fname

Emp#Salary

Address

Gender

No_of_dependents

Date_hired

No_of_employees

dIN_HOUSE_PROJECT

OUTSOURCED_PROJECT

Contracted_to

VENDOR

Mg_start_dt

Pl_name

Pnumber

Budget

Building

U

Description

Hours

Description

Pnumber

Pr_name

Plocation

V_name

V_address

V_phone

UDependent--------------

Dname

Related_how

Birthdate

Gender

Bank#

Account_id

Account#

Acc_type

Hb_name

lo_activity

Gi_activity

Status

Ssn

Name

Phone#

AddressPrincipal

Size

Name

Denomination

Name

Pastor

Exempt_id

Type

Budget

n 1

11

worker

manager

employer

managed by

Holder of

Supervisor

Supervisee

201

1

m

Belongs to

Having 1

nDepends_on

Account Holder1

n

Account of

Responsible1

Controlledn

Assignee

m

7

Assignment

1

n

Participantm

nUsage

m

Figure 4.21 Presentation Layer ER diagram f or Bearcat, I ncorporated

Annual_cost

Hrs_per_wk

n

District Tax_base

A Presentation Layer EER Diagram For Bearcat, Inc.


EMPLOYEE

Works_in

Managed_by

PLANT

Houses

PROJECT

Belongs_to

Uses

Dependent_of

ASSIGNMENT

BUILDING

Supervised_by

Held_by_E

DEPENDENT

PARTICIPATIONIncludes_D

Includes_H

Held_by_D

HOBBY

BANK_ACCOUNT

Receives

Provides

SUPPORT

SPONSOR

NOT_FOR_PROFIT_ORGANIZATION CHURCH SCHOOL INDIVIDUAL

PUBLIC_SCHOOL

U

[N,1]Name_tag

[A,20]Lname

[A,1]Minit

Name

[A,20]Fname

[N,5]Emp_n

[A,1]Emp_a Emp#

[N,6]Salary

[X,50]Address

[A,1]Gender

[N,2]No_of_dependents

[Dt,8]Date_hired

D R

R

R

(1,m)

(0,20) (0,1) (0,n)

(0,7)

(0,1) (1,1)

[N,3]No_of_employees

d

IN_HOUSE_PROJECT

OUTSOURCED_PROJECT

Contracted_to

VENDOR

(1,1) (100,n)

R

[Dt,8]Mg_start_dt

[A,30]Pl_name

[N,2]Pnumber

[N,7]Budget

(3,n) R

(1,1)

[A,20]Building----------

[X,50]Description

(1,m)

C

(1,1)[N,3]Hours

[X,50]Description

[N,2,1]Hrs_per_wk

[N,6]Annual_cost

[N,2]Pnumber

[A,20]Pr_name

[A,15]Plocation

(1,n)

(0,1)

[A,30]V_name

[X,50]V_address

[X,10]V_phone#

C

(1,1)

Dependent--------------

[A,15]Dname

[A,12]Related_how

[Dt,8]Birthdate

[A,1]Gender

(0,1)

(1,1)

[N,2]Bank#

Account_id

[X,6]Account#

[A,1]Acc_type

C

C

(0,1)

(0,n)

(0,n)

C(1,1)

[A,20]Hb_name

[A,1]lo_activity

[A,1]Gi_activity

(0,m)(0,n)

(1,1)

(1,m)

[A,1]Status

C

C

c

Ssn[N,9]

[A,30]Name

[X,10]Phone#

[X,50]Address

Principal[A,30]

Size[N,4]

Name[A,30]

Denomination[A,20]

[A,30]Name

[A,30]Pastor

Exempt_id[X,6]

Type[A,1]

[N,10.0]Budget

Figure 4.22 Fine-granular Design-Specifi c ER diagram for Bearcat, I ncorporated

District[A,30]

Tax_base[N,10.0]

(1,1)

Undertaken_by

R

(0,m)

(0,1)N

N

(1,1)

A Fine-granular Design-Specific EER Diagram For Bearcat, Inc.

Documents

Chapter 4: Enhanced Entity-Relationship (EER) Modeling