Extended ER Model and other Modelling Languages - Lecture 2 - Introduction to Databases (1007156ANR)

2 December 2005
Introduction to Databases
Extended ER Model and other Modelling Languages
Prof. Beat Signer
Department of Computer Science
Vrije Universiteit Brussel
http://www.beatsigner.com

Beat Signer - Department of Computer Science - bsigner@vub.ac.be 2February 24, 2017
Extended Entity-Relationship (EER) Model
 Over the years the ER model has been extended with
additional concepts to increase its expressiveness
 specialisation and generalisation (ISA relationship)
 ISA constraints
 aggregation

Specialisation and Generalisation
 An entitiy set can be further subgrouped
or specialised into distinctive entity sets
 an entity subset may for example have additional attributes
 top-down approach
 Parts of multiple entity sets may be generalised in a
higher level entity set
 bottom-up approach
 Specialisations as well as generalisations are
represented by the same ISA relationship construct
 represented by a triangle in the EER model
 A ISA B implies that every A entity is also a B entity
 generalisation can be seen as the inversion of specialisation
ISA

ISA Relationship
Persons
id name
Students
ISA
Teachers
PhD
Students
Professors
ISA
research
topic
teaching
hours
studentID
#projects
LivesAt Locations
address
0..*0..1
ISA

ISA Relationship ...
 The attributes of a higher level entity set (superclass) are
inherited by the lower level entity set (subclass) via the
ISA relationship
 e.g. students inherit the id attribute from persons
 A subclass also inherits any relationship participation
from its superclass
 e.g. students, teachers etc. can participate in the LivesAt
relationship
ISA

ISA Constraints
 To model an application domain more precisely, specific
constraints can be defined over an ISA relationship
 Membership constraints
 a condition-defined membership constraint assigns an entity to a
specific subclass based on one or more attribute values
 a user-defined membership constraint can be used to manually
assign entities to a specific subclass (manual classification)
 Disjointness constraints
 an overlapping constraint over subclasses specifies that an entity
may belong to multiple subclasses
- e.g. a person may be a teacher as well as a student
- by default, subclasses participate in an overlapping constraint
ISA

ISA Constraints ...
 Disjointness constraints ...
 a disjoint constraint specifies that an entity can only belong to
exactly one subclass
- e.g. a teacher can be either a PhD student or a professor (but not both)
- expressed by writing the word disjoint next to the triangle
 Completeness constraints
 a partial specialisation (generalisation) constraint specifies that
some superclass entities may not belong to any subclass
- default completeness constraint
 a total specialisation (generalisation) constraint defines that each
superclass entity must belong to a subclass
- e.g. each teacher must belong to the PhD Students or Professors subclass
(or to both of them)
- represented by a double line connection to the triangle (like total participation)
ISA

ISA Constraints ...
disjointness and completeness constraints are independent of each other
ISA
Persons
id name
Students
ISA
Teachers
PhD
Students
Professors
ISA
research
topic
teaching
hours
studentID
#projects
LivesAt Locations
address
birthdate
Adults
ISA
birthdate <
23.02.1996
disjoint
0..*0..1

Aggregation
 A limitation of the ER model is that relationships cannot
be modelled over other relationship sets
 What if we would like to introduce a manager for some
(employee, company, duration) combinations?
WorksFor CompaniesEmployees
id name name address
Durations
from to
0..* 0..*
1..1

Aggregation ...
 We cannot just create a
4-ary relationship WorksFor
 not all combinations have
a manager
 Introduce a new
4-ary Manages
relationship
 problem: we
introduce some
redundancy!
- (employee, company, duration)
are replicated in (manager,
employee, company, duration)
Durations
from to
Manages
Managers
1..1
0..* 0..*
0..*
0..*
0..*
0..*

Aggregation ...
 An aggregation treats the
relationship as a higher
level entity
 can be used in another relationship
Durations
from to
Manages
Managers
1..1
0..* 0..*
1..*
0..*

Part-Of Hierarchies
PartOf
Tires
Cars
CPartOf TPartOf
Chassis
3..4
1..1
1..1
1..1
PartOf
particular product
general Part-Of
PartOf
Products
0..1
superpart subpart
0..*

ER Design Issues
 When do we model something as an attribute
and when as an entity set?
 there is no general answer and the choice depends on the
specific application domain to be modelled
 When do we model something as a relationship set and
when as an entity set?
 a relationship set often corresponds to an action between entities
 In general we should try to avoid higher level n-ary
relationship sets
 3-ary relationship sets should be the maximum and even these
should be used carefully

Attribute or Entity?
 Should the address in the example be modelled
as an attribute or as a separate entity?
 depends on the intended use of the address
 if we need an address for different entities (e.g. not just for
employees) it is better to model the address as separate entity
LocatedAt OfficesEmployees
id name
birthday
phone age #offices
address
street city
0..1 0..*

Attribute or Entity?
 Should the duration be modelled as a from and to
attribute or as a separate entity?
 Depends again on the use
 if we foresee that the same duration period is used by other entity
sets, it should be modelled as a separate entity
Durations
from to
0..* 0..*
1..1

N-ary or Binary Relationships?
 Basically any n-ary relationship can be replaced
by a number of binary relationship sets
 "real" 3-ary relationships should not be replaced
- e.g. WorksFor presented earlier
 the Parents relationship is a example of a
non-real 3-ary relationship
- have to use null values if there is either no father or mother
- better to model it as two separate binary relationships
ParentsPersons
child
father
mother
PersonsHasFather HasMother
child child
father mother
0..*
0..*
0..1 0..1 0..1
0..* 0..*

ER Design Principles
 Make sure that you pay attention to all the entities, their
relationships and any other constraints mentioned in the
description (requirements) of a specific application
domain
 e.g. show cardinality constraints for all relationships
 Avoid redundancy!
 The resulting conceptual model should be as simple as
possible, but not simpler
 introduce only necessary entities and relationships
 Some constraints (e.g. functional dependencies) cannot
be expressed in the ER model

ER Design Principles ...
 In two weeks we will see how the conceptual ER model
can be mapped to a logical database schema
(e.g. relational database schema)
 The resulting relational schema can be further analysed
by using functional dependencies and normalisation

ER Summary
 Entities and attributes
 Relationships
 cardinality constraints
 participation constraints
 Keys
 Weak entities
 ISA hierarchies
 Aggregation

Classification and Typing
 Aristotle (384 BC-322 BC) introduced
a biological classification (ontology)
 artificial classification system
 organisms with the two subclasses plants
and animals
 animals further subclassified into animals
with blood and animals without blood
 animals also classified into walking animals,
flying animals and swimming animals (habitat)
 Characteristics (problems) of Aristotle's classification
 based on behaviour and not on similarities (non-evolutionary)
 animals can belong to multiple classes
- e.g. a duck belongs to the walking animals as well as swimming animals class
Aristotle

Classification and Typing ...
 Bertrand Russell defined the
type of a given predicate P as
the entity set spanned by P
 intensional notion of type
 The notion of type for classi-
fying entities based on a set
of conditions was questionned
by Wittgenstein
 there exists no precise definition (type) for some general concepts
- e.g. no definition for the general concept of a game
 We can have a definitional (e.g. intensional) or
prototypical definition of a type
Bertrand Russell Ludwig Wittgenstein

OM Model
 Data model that integrates concepts from
the entity-relationship and object-oriented
data models
 based on objects, collections and associations
(binary collections)
- supports associations over associations
 different types of collections
- sets, bags, rankings and sequences
 Separates typing and classification (role modelling)
 Operational part (algebra) over objects and collections
 A family of object database platforms have been realised
based on the OM model (e.g. OMS Java)
Moira C. Norrie

OM Typing and Classification
{ p1,p2 } p1,p2,p3,p4 }
p1
p2
Classification
Entities
Objects
Roles
Collections
represented by
Semantic
Grouping
employee
designer
Typing
Employees
Designers
Females
subtype
subcollection

OM Example (RSL Link Metamodel)

The Unified Modelling Language (UML)
 UML is a standard
developed by the
Object Manage-
ment Group (OMG)
 used to specify the
components of a
software system
 based on earlier
work including the object-modelling technique (OMT) by
Rumbaugh et al., the Booch method by Booch and object-
oriented software engineering (OOSE) by Jacobson
 UML supports different types of diagrams
 class diagrams, use case diagrams, package diagrams,...
Ivar JacobsonGrady BoochJames Rumbaugh

UML Class Diagrams
 A UML class diagram is similar to an ER model
 A UML class is "like" an ER entity set
 contains attributes as well as methods
Employees
id name
birthday
phone age
address
employee
id
name
birthday
phone
address
age()
ER entity set UML class

UML Class Diagrams ...
 UML relationship class with attributes can be used like
an ER aggregation in other UML relationships
 e.g. locatedAt in the example
 Note that the position of the cardinality constraints are
switched in UML
ER relationships UML relationships
employee office
employee office
officeemployee locatedAt
employee office
years
0..*0..1 0..* 0..1
employee office
officeemployee
locatedAt
years

UML Class Diagrams ...
Teachers
PhD
Students
Professors
ISA
disjoint
teacher
phdStudent professor
Teachers
PhD
Students
Professors
ISA
teacher
phdStudent professor
overlapping
disjoint
ER specialisation UML specialisation

Modelling Exercises
 Model the RSL link model in ER
 Define an ER model for the following application
 You are going to develop a database for the Chamber of Com-
merce and Industry of Brussels (CVO) to manage information
about language courses in Dutch, Spanish, French and Italian.
The database should store information about the teachers and
students as well as the individual language courses. A semester
lasts for 13 weeks. Regular courses are scheduled for two
sessions (each 3 hours) per week; advanced courses for three
sessions (each 4 hours) per week. Each course has a difficulty
level (module) of 1, 2 or 3 and costs a certain amount of money.
A teacher may not give more than 4 courses and not teach in
more than 2 languages. Each student has to do a final exam and
will get a grade for the exam.

Homework
 Study the following chapter of the
Database System Concepts book
 chapter 7
- sections 7.8-7.10
- Extended ER Model (EER)
- Unified Modelling Language (UML)

Exercise 2
 Entity-Relationship (ER) model
 Extended Entity-Relationship (EER) model

References
 A. Silberschatz, H. Korth and S. Sudarshan,
Database System Concepts (Sixth Edition),
McGraw-Hill, 2010
 M.C. Norrie, An Extended Entity-Relationship Approach
to Data Management in Object-Oriented Systems,
Proceedings of ER 1993, 12th International Conference
on Conceptual Modeling, Arlington, USA, December
1993
 https://globis.ethz.ch/files/2015/05/1993b-n-er.pdf

References ...
 B. Signer and M.C. Norrie, As We May Link:
A General Metamodel for Hypermedia Systems,
Proceedings of ER 2007, 26th International Conference
on Conceptual Modeling, Auckland, New Zealand,
November 2007
 http://beatsigner.com/publications/signer_ER2007.pdf

2 December 2005
Next Lecture
Relational Model and Relational Algebra

Extended ER Model and other Modelling Languages - Lecture 2 - Introduction to Databases (1007156ANR)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Extended ER Model and other Modelling Languages - Lecture 2 - Introduction to Databases (1007156ANR)

Similaire à Extended ER Model and other Modelling Languages - Lecture 2 - Introduction to Databases (1007156ANR) (20)

Plus de Beat Signer

Plus de Beat Signer (20)

Dernier

Dernier (20)

Extended ER Model and other Modelling Languages - Lecture 2 - Introduction to Databases (1007156ANR)