Enhanced ER Model

EER model = ER Model + hierarchical relationships

– entities that are member of one entity type (the superclass) may be grouped into
meaningful subsets (the subclasses)
– often referred to as an “IS-A” relationship
– e.g. the two subclasses of TRAINEE in the training courses company (EMPLOYEE and
PROFESSIONAL)

attribute inheritance permits economy of representation

– entity that is a member of a subclass inherits all of the attributes of the entity as a
member of the superclass
a PROFESSIONAL, as a TRAINEE, has a code, name, etc.

– also inherits all relationship types the superclass participates in

a PROFESSIONAL, as a TRAINEE, attends editions of courses


EER Modelling
Specialisation
– start from one entity and create sub-entities
– two main reasons:
1. certain attributes may apply to some but not all members of a entity
type:
e.g. we keep Title and Area for professional trainees only

a subclass is defined to group the entities to which these attributes apply

2. some relationship types may be participating in only by some

members of an entity type:
e.g. employee trainees are the only trainees who works for an employer

a subclass is defined to group the entities participating to this relationship

EER Modelling

Generalisation
– inverse of specialisation
– realise two entity types have lots of common features
– suppress differences between entity types, identify the common
features and generalise them into a superclass
e.g. generalise CAR and TRUCK into the VEHICLE superclass


EER Diagrams

subclasses that define a specialisation are attached by lines to a circle,

which is connected with the superclass

subset symbol indicates direction of relationship superclass/subclass

specific attributes (those that apply only to the entities of the subclass) are
attached to that subclass

relationship types that apply only to a subclass are called specific

relationship types (e.g. WORKS FOR between EMPLOYEES and
EMPLOYER)
EER Diagrams

Code NIN
Sex TownBirth

Surname

Age TRAINEE

Level Area
U

U
Position Title
EMPLOYEE PROFESSIONAL
Constraints on Subclasses

can sometimes determine exactly the entities that will become members
of each subclasses
e.g. for EMPLOYEE subclass we may specify the condition of
membership to be predicate JobType=“Employee”
such condition act as constraints on the members of the EMPLOYEE
subclass
then we might have a class of “Young” trainees, whose age is less than 30
(no matter the job)

we have therefore predicate-defined subclasses

predicate condition is placed next to line joining subclass to circle
Constraints on Subclasses

Code NIN
Sex TownBirth

Surname
JobType
Age TRAINEE

Level Area
JobType = JobType =
U
U

"Employee" "Professional"
Position Title
EMPLOYEE U PROFESSIONAL
Age < 30
YOUNG
if all subclasses in a specialisation have the membership condition on the
same attribute of the superclass we have attribute-defined subclasses
attribute is the defining attribute of the specialisation

shown by placing the name of the attribute on the arc from circle to
superclass
Code NIN
Sex TownBirth

Surname
JobType
Age TRAINEE
JobType

Level Area
U
U

"Employee" "Professional"
Position Title
EMPLOYEE PROFESSIONAL
where there is no condition we have a user-defined subclass
– membership is determined by database users when adding an entity to
the subclass
– e.g. the original TRAINEE definition without JobType attribute
Code NIN
Sex TownBirth

Surname

Age TRAINEE

Level Area
U

Position Title
EMPLOYEE PROFESSIONAL
we can have several specialisations of the same entity type using different
distinguishing characteristics
e.g. EMPLOYEE can be specialised on the basis of Position into SALARIED-EMPLOYEE,
HOURLY-PAID-EMPLOYEE
Code NIN
Sex TownBirth

Surname
JobType
Age TRAINEE
JobType

Level Area

U
U

"Employee" "Professional"
Position Title
EMPLOYEE PROFESSIONAL
Position

Salary
PayScale
U
U

"Salaried" "Hourly"

SALARIED HOURLY-PAID

Note that SALARIED and HOURLY-PAID are both EMPLOYEE and TRAINEE
Disjointness Constraint
specifies that subclasses of a specialisation are disjoint
– an entity can be a member of at most one of the subclasses of the specialisation
– attribute defined specialisation implies disjoint subclasses if the defining attribute is
single-valued

subclasses that are not disjoint may overlap

– some entity may be a member of more than one subclass of the specialisation
 Code NIN
Sex TownBirth

Surname
JobType
Age TRAINEE
JobType

Level o
Area
"Part−time"OR "Part−time"OR

U
U
"Employee" "Professional"
Position Title
EMPLOYEE PROFESSIONAL
Position

d
Salary
PayScale
U
U

"Salaried" "Hourly"

SALARIED HOURLY−PAID

professional trainees may have also a part time employment,

but an employment can either be salaried or hourly paid

Completeness Constraints
1. Total Specialisation
every entity in a superclass must be a member of some subclass in some specialisation


e.g. every EMPLOYEE must be either HOURLY-PAID or SALARIED



2. Partial Specialisation
allows an entity not to belong to any of the subclasses


e.g. can have TRAINEES who are neither EMPLOYERS nor PROFESSIONALS

Completeness Constraints
Code NIN
Sex TownBirth

Surname
JobType
Age TRAINEE
JobType

Level o
Area

U
U
"Employee" "Professional"
Position Title
EMPLOYEE PROFESSIONAL
Position

d
Salary
PayScale
U
U

"Salaried" "Hourly"

SALARIED HOURLY-PAID
Insertion and Deletion Rules
1. deleting an entity from a superclass implies that it is automatically
deleted from all of the subclasses it belongs to
2. inserting an entity in a superclass implies that the entity is inserted in
all predicate-defined subclasses for which the entity satisfies the
defining predicate
3. inserting an entity in a superclass of total specialisation implies that
the entity is inserted in at least one of the subclasses of the
specialisation
4. inserting an entity in a superclass of disjoint, total specialisation
implies that the entity is inserted in one and only one of the subclasses
of the specialisation
special care for multiple hierarchies and lattices:
View Integration ER Schema Design
requirements are given for many user groups or applications
independently
an ER schema (view) is designed for each user group and application
(typically by different developers)
individual views are merged into the global conceptual schema
individual views can be reconstructed as external schemas after view
integration
can be difficult!
– need to specify correspondences among entity types, relationship
types and attributes before starting integration
– require good methodology and software support
– need to integrate conflicting views and verify the consistency of
inter-schema correspondences
View Integration: Tasks

1. Identification of correspondences and conflicts among schemas

need to identify constructs in schemas that represent the same
real-world concept
2. modification of views to conform to one another
some of the view schemas may need to be refined to resolve conflicts
identified in 1

3. merging of views
global schema is created by merging individual schemas

4. restructuring
global schema may require further refinement to remove redundancies
or unnecessary complexity
Conflicts Among Schemas

1. naming conflicts: synonyms and homonyms

synonyms occur when two schemas use different names to describe
the same concept
homonyms occur when two schemas use the same name to describe
different concepts
Conflicts Among Schemas
1. naming conflicts: synonyms and homonyms
Date Time Telephone Number
Class
Code Code
NIN N N EDITION N
ATTENDS N
Surname TEACHES Age
1
Age PARTICIPANT HELD IN EMPLOYEE
Code
Sex 1
COURSE TYPE TownBirth Position
TownBirth
Name
Surname

Code NIN
Sex TownBirth

Surname
JobType
Age TRAINEE
JobType

Level Area
U
U

"Employee" "Professional"
Position Title
EMPLOYEE PROFESSIONAL
Conflicts Among Schemas
2. type conflicts: the same concept may be represented in two schemas using
different modelling concepts
e.g. a department may be represented as an attribute in one schema
and an entity in another
e.g. a match can be represented as a relation in a schema or an entity
in another
Conflicts Among Schemas
2. type conflicts: the same concept may be represented in two schemas using
different modelling concepts
 Date Time
Class
Code
NIN N N EDITION
ATTENDS
Surname
1
Age TRAINEE HELD IN
Code
Sex 1
TownBirth COURSE TYPE
Name

Date Time Telephone Number

Class
Code
Code
N N
EDITION TEACHES Age

Code INSTRUCTOR
CourseType
Name
TownBirth Position

Surname
Conflicts Among Schemas
3. value set conflict: values of attributes may be represented differently
e.g. an ID code may be represented as a number in a schema and as text in another


4. constraint conflict: schemas may impose different constraint

e.g. primary key may be different: a schema uses National Insurance Number and


another uses Trainee Code as primary key for TRAINEE

e.g. relationship may have different cardinality: a schema assumes that an instructor


may teach different courses, and another that an instructor must teach only one course at
a time
 Modifying Views

Date Time
Class
Date Time Telephone Number
Code
Class
N N EDITION
ATTENDS Code
name
N N
1 VIEW 1 EDITION TEACHES Age VIEW 2
e PARTICIPANT HELD IN
Code CourseType
Code EMPLOYEE
1
Level
Position COURSE TYPE Name
Name
TownBirth Surname Position

Code NIN
Sex TownBirth

Surname
JobType
Age TRAINEE
JobType
VIEW 3

Level Area
U
U

"Employee" "Professional"
Position Title
EMPLOYEE PROFESSIONAL
 Modifying Views

Date Time
Date Time
Class
Class Telephone Number
Code

N N EDITION Code
ATTENDS
name N
EDITION N
1 VIEW 1 TEACHES Age VIEW 2
e EMPLOYEE 1
HELD IN
Code HELD IN INSTRUCTOR
1 Code Name
Position Level COURSE TYPE 1
Name
COURSE TYPE TownBirth Surname Position

Code NIN
Sex TownBirth

Surname
JobType
Age TRAINEE
VIEW 3
JobType

Level Area
U
U

"Employee" "Professional"
Position Title
EMPLOYEE PROFESSIONAL
Merge Views & Eliminate Redundancies
Date Time Telephone Number
Class
Code
N N N N
ATTENDS EDITION TEACHES Age
1

HELD IN INSTRUCTOR
Code
1
COURSE TYPE TownBirth Surname Position
Name

Code NIN
Sex TownBirth

Surname
JobType
Age TRAINEE
JobType

Level Area
U
U

"Employee" "Professional"
Position Title
EMPLOYEE PROFESSIONAL
Another Example
Vol Num
Title

N N
PUBLISHED IN JOURNAL
Size

ARTICLE VIEW 1

N RESEARCHER
AUTHORED_BY

Name ClassificationID
Title

N N
BELONGS TO SUBJECT
Publisher
VIEW 2
BOOK
N

N AUTHOR
WRITTEN_BY
Modifying Views

RESEARCHERS and AUTHORS can be assumed to be synonyms for the

same entity type
AUTHORED-BY and WRITTEN-BY are synonyms for the same
relationship type

may include a SUBJECT for ARTICLE too

 Vol Num

Title

N PUBLISHED IN N JOURNAL

Size
VIEW 1
ARTICLE N N
BELONGS TO SUBJECT
N
N Name ClassificationID
WRITTEN_BY AUTHOR

Name ClassificationID
Title

N N
BELONGS TO SUBJECT
Publisher
VIEW 2
BOOK
N
N AUTHOR
WRITTEN_BY
Merging Views
introduced a generalisation, PUBLICATION, including BOOKS and
ARTICLES
Name ClassificationID

Type N N
BELONGS TO SUBJECT
Title
N
PUBLICATION
Type
N AUTHOR
WRITTEN_BY
d
U
U

"Book" "Article"
Vol Num
BOOK ARTICLE

Size N N
Publisher PUBLISHED IN JOURNAL
Integration Strategies
several approaches, order is based on measure of schema similarity (e.g.
shared entity types)
 3

2 V5

V4
1
V3
V1 V2 V3 V4 V5
V1 V2

BINARY N-ARY

2 3
1 1 2
V3 V4 V5

V1 V2 V1 V2 V3 V4 V5

BINARY BALANCED MIXED