Enhanced Entity-Relationship Model

last updated 10/7/04

Entity Type Hierarchies

One entity type might be a subtype of another--very similar to subclasses in OO programming

A relationship exists between a Freshman entity and the corresponding Student entity

This relationship is called IsA

 


Properties of IsA

Inheritance - All attributes of the supertype apply to the subtype.

Transitivity - This property creates a hierarchy of IsA relationships

Advantage: Used to create a more concise and readable E-R diagram.  It best maps to object oriented approaches either to databases or related applications.

 


Example of IsA

 


Type Hierarchy

Associated constraints may apply:

Covering constraint: Union of subtype entities is equal to set of supertype entities. An entity is an element of at least one subtype

Disjointness constraint: Sets of subtype entities are disjoint from one another (i.e., the sets are mutually exclusive). An entity can be an element of at most one entity

 

 


Why Extend the E-R Model?

E-R is suitable for traditional business applications

E-R is not semantically rich enough for advanced applications

Applications where E-R is inadequate

 

 


Specialization Abstraction

Specialization-needed when an entity set has subsets that have special attributes or that participate in special relationships

Process of breaking up a class into subclasses

Ex: Faculty contains AdjunctFac and FullTimeFac

 


Representing Specialization

E-ER diagram –shows specialization circle (isa relationship), and inheritance symbol (subset symbol)

Specialization can also involve just one subclass – no need for circle, but show inheritance symbol

 


Generalization Abstraction

Inverse of specialization

Recognizing that classes have common properties and identifying a superclass for them

Ex. Student and Faculty are both people

Bottom-up process, as opposed to top-down process of specialization

EER diagram is the same as for specialization

 

 


Generalization/Specialization Constraints

Subclasses can be overlapping or disjoint

Place o or d in specialization circle to indicate constraint

Specialization can be total (every member of superclass must be in some subclass) or partial

Total -double line connecting superclass to specialization circle

Partial-single line

Specialization definition can be

 

 


Multiple Specializations

Can have different specializations for the same class

See undergraduates specialized by year and by residence. These are independent of each other

Can have shared subclasses – have multiple inheritance from two or more superclasses

 


Union or Category

Subclass related to a collection of superclasses

Each instance of subclass belongs to one, not all, of the superclasses

Superclasses form a union or category

Ex. A Sponsor may be a team, a department, or a club –

Each Sponsor entity instance is a member of one of these superclasses, so Sponsor is a subclass of the union of Team, Dept, Club

EER diagram - connect each superclass to union circle, connect circle to subclass, with subset symbol on line bet circle and subclass

 

 


Total and Partial Unions

Total category – every member of the sets that make up the union must participate

Shown on E-ER by double line from union circle to subset

See below every Concert or Fair must be a Campus-Wide Event

Partial category – not every member of the sets must participate

Shown by single line

See below-- not every Club, Team, or Dept must be a Sponsor

 


Total Union vs. Specialization

Total union can often be replaced by hierarchy

Choose hierarchy representation if superclasses have many common attributes

 


(min..max) Notation for Relationships

Shows both cardinality and participation constraints

Can be used for both E-R and E-ER diagrams

Use pair of integers (min..max) on line connecting entity to relationship diamond

min is the least number of relationship instances an entity must participate in

max is the greatest number it can participate in (can write M or N for many); some authors use * for many

 


E-ER to Relational Model -1

For entity sets that are not part of generalization or union, do the mapping as usual

Map strong entity sets to tables, with column for each attribute, but

For composite attributes, create column for each component, or single column for composite

For multi-valued attribute, create separate table with primary key of entity, plus multi-valued attribute as composite key

Weak entity sets – include primary key of owner

 


Binary Relationships

1-M: use key of “one” side as foreign key in “many” side

1-1: use either key as foreign key in the other’s table

M-M: create relationship table with both primary keys

Higher-Order Relationships-create relationship table