Introduction/Overview

Data Modeling
E-R Diagrams - Basics
Guidelines

Databases
ER-Models

Michael Emmerich, LIACS, Leiden University

Paul Breukel, Haagse Hogeschool

February 8, 2010

Michael T. M. Emmerich & Paul Breukel Databases

 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

3 layer model ANSI/SPARC

Many views, single

conceptual (logical)
schema and physical
schema
Views describe how users
see the data
Conceptual schema
defines logical structure
Physical schema describes
the files and indexes used

Michael T. M. Emmerich & Paul Breukel Databases

 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Example: University
Data Model

Conceptual schema
Students(sid: string, name: string, login: string, age: integer)
Courses(cid: string, cname:string, credits:integer)
Enrolled(sid:string, cid:string, grade:string)
Physical schema
Relations stored as unordered files.
B+ tree index on first column of Students.
External Schema (View)
CourseInfo(cid:string,enrollment:integer)
Michael T. M. Emmerich & Paul Breukel Databases
 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Steps in building a database

Requirements Analysis
Informal description of the data objects to be stored in the
database
List of integrity constraints and relations between the data
objects
Data Modeling (ER Diagram)
Formal specification of data model and constraints in a
human-understandable, graphical way
Translation into relational schema using Data Definition
Language of SQL (DDL)
Schema Refinement, Tuning (Indexes, Query optimization)
Application programming on top of Database using SQL
Data-Manipulation Language (DML), also definition of views

Michael T. M. Emmerich & Paul Breukel Databases

 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

E-R Diagrams: General purpose

How can we specify objects and relationships between them in a

formal and graphical way?

Michael T. M. Emmerich & Paul Breukel Databases

 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

E-R Diagrams

The E-R (entity-relationship) data model views the real world

as a set of basic objects (entities) and relationships among
these objects
Graphical visualization is called E-R diagram
They were introduced by Peter Pin-Shan Chen, 1976, who
was inspired by the Chinese language
http://bit.csc.lsu.edu/~chen/pdf/ER_C.pdf

Michael T. M. Emmerich & Paul Breukel Databases

 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Entity sets, Attributes, Keys

Entity: Real-world object distinguishable from other objects.

An entity is described (in DB) using a set of attributes.
Entity Set: A collection of similar entities. E.g., all employees
All entities in an entity set have the same set of attributes.
(Until we consider ISA hierarchies, anyway!)
Each entity set has a key (e.g. ssn) consisting of one or more
attributes; The key attribute(s) uniquely identifies each entity
Each attribute has a domain (e.g. ssn:int, name:string), e.g.
an entity from an entity-set with n attributes having domains
A1 , . . . , An is an n-tuple with
(a1 , . . . , an ) ∈ A1 × · · · × An
Michael T. M. Emmerich & Paul Breukel Databases
 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Relationship (sets)

Relationship: Association among two or more entities. E.g.,

Attishoo works in Pharmacy department.
Relationship Set: Collection of similar relationships.
An n-ary relationship set R relates n entity sets E1 ... En
An relationship set has also a specified number of attributes
from attribute domains A1 , . . . , Am
each relationship in R is a m + n tuple

(e1 , . . . , en , a1 , . . . am ) ∈ E1 × · · · × En × A1 × · · · × Am

Michael T. M. Emmerich & Paul Breukel Databases

 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Roles

The entity involved in an

relationship set need not to be
distinct.
If the same entity is involved
multiple times in the same
relationships, different roles are
specified

Michael T. M. Emmerich & Paul Breukel Databases

 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Key Constraints

Constraints of the type: For each entity in e1 ∈ E1 there can

be at most one tuple (e2 , . . . , em ) ∈ E2 × · · · × Em such that
(e1 , . . . , em ) ∈ R
If aforementioned constraint hold we draw an arrow from E1
to R instead of a simple line

Michael T. M. Emmerich & Paul Breukel Databases

 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Key Constraints

Constraints of the type: For each entity in e1 ∈ E1 there can

be at most one tuple (e2 , . . . , em ) ∈ E2 × · · · × Em such that
(e1 , . . . , em ) ∈ R
If aforementioned constraint hold we draw an arrow from E1
to R instead of a simple line
Example: Departments are managed by at most one
employee, but an employee may manage many departments

Michael T. M. Emmerich & Paul Breukel Databases

 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Total Participation Constraints

Constraints of the type: For all e1 ∈ E1 there must exist

one tuple (e2 , . . . , em ) ∈ E2 × · · · × Em such that
(e1 , . . . , em ) ∈ R
If aforementioned constraint hold we draw a thick (or double)
line from E1 to R instead of a simple line

Michael T. M. Emmerich & Paul Breukel Databases

 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Total Participation Constraints

Constraints of the type: For all e1 ∈ E1 there must exist

one tuple (e2 , . . . , em ) ∈ E2 × · · · × Em such that
(e1 , . . . , em ) ∈ R
If aforementioned constraint hold we draw a thick (or double)
line from E1 to R instead of a simple line
Each course is teached by at least one employee, but not
every employee teaches a course

Entities for which a total participation constraint is (not)

specified are said to participate totally (partially) in R
Michael T. M. Emmerich & Paul Breukel Databases
 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Participation Constraints and Key Constraints

Participation and key constraints can be combined

Michael T. M. Emmerich & Paul Breukel Databases

 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Participation Constraints and Key Constraints

Participation and key constraints can be combined

Michael T. M. Emmerich & Paul Breukel Databases

 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Key Constraints
Instances of relationship sets can be denoted as hypergraphs
Example: Instances of binary relationship sets fulfilling
different kinds of key-constraints:

Participation and key constraint allow reasoning about the

relative size of entity sets, e.g.
Michael T. M. Emmerich & Paul Breukel Databases
 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Example 1

Model the relationship between football-players and teams in

the Champion League
Each player plays for at most one team
In each team there are players
Every player plays for a team
Draw the E-R diagram!

Michael T. M. Emmerich & Paul Breukel Databases

 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Example 2

Relationship between students and database-accounts in

LIACS
For each student e-mail there is a unique database account
Some of the database accounts may be owned by teachers

Michael T. M. Emmerich & Paul Breukel Databases

 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Example 3

Consider the ice-speed skating 500m contest

Two ice-speed skaters are competing in each race - one on the
left and one on the right starting position. Model the
relationship ’competes-with’ between two ice-speed skaters!

How to extend the model when different contests (e.g.

500m/men, 1000m/women, 3000/women etc,) are to be
modeled?

Michael T. M. Emmerich & Paul Breukel Databases

 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Weak entities

A weak entity can be identified uniquely only by considering

the primary key of another (owner) entity
Owner entity set and weak entity set must participate in a
one-to-many relationship set (one owner, many weak entities).
Weak entity set must have total participation in this
identifying relationship set.

Michael T. M. Emmerich & Paul Breukel Databases

 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

’is-a’ Hierarchies

As in C++, or other PLs, attributes are inherited.

If we declare A IS-A B, every A entity is also considered to be a B
entity (key should be shared!).
Two kinds of constraints:
Overlap constraints: Can Joe be an Hourly Emps as well as a
Contract Emps entity? (Allowed/disallowed)
Covering constraints: Does every Employees entity also have
to be an Hourly Emps or a Contract Emps entity? (Yes/no)
Reasons for using ISA:
Several reasons
Michael T. M. Emmerich & Paul Breukel Databases
 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Example 3

Boats have a price, unique boat-id and a name

Boats can be motorboats that have also a maximum speed
Boats can be sailing boats with specific types of sail

Each animal species is identified by its latin name

An animal can be a bird or a fish, or some other animal
A bird has also an attribute ’wingspread in meter’, a fish has
the attribute ’water-type (sea/fresh/both)’

Michael T. M. Emmerich & Paul Breukel Databases

 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Aggregation

Aggregation allows relationships between relationships and

entities (or other relationships)

Michael T. M. Emmerich & Paul Breukel Databases

 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Ternary Relationship vs. Aggregation

All three entities participate always in a relation (in case of

aggregation this does not have to be the case)
Different constraints can be expressed for ternary relations as
compared to aggregation

Michael T. M. Emmerich & Paul Breukel Databases

 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Binary Relations vs. Ternary Relations

The fact that a costumer bought a book at a certain time at

a certain bookshop cannot be expressed as a combination of
binary relations among entities from bookshop book and
customer

Michael T. M. Emmerich & Paul Breukel Databases

 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Guidelines: Attributes vs. Entities

if objects occur independently in relationships they should be

modeled as entities
attributes should not have sub-attributes
attributes should not contain lists, attributes should be
elementary
sometimes modelling attributes as entities allows to express
constraints easier

Michael T. M. Emmerich & Paul Breukel Databases

 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Example 1: Attribute vs. Entity

In the second case a list of duration times can be modeled

Michael T. M. Emmerich & Paul Breukel Databases
 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Example 2: ’Bad’ Entity

Bad design! A single entity would be enough

Michael T. M. Emmerich & Paul Breukel Databases

 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Example 3: Relationships with subclass

Discretionary budget for employees that manage departments.

Good design uses ’is-a’ hierarchy; avoid redundant storage and
misleading attribute for non-manager employees.
Michael T. M. Emmerich & Paul Breukel Databases
 Introduction/Overview
Data Modeling
E-R Diagrams - Basics
Guidelines

Summary

Conceptual design follows requirements analysis

It yields high level data description
Basic constructs: entities, relationships, and attributes, key-
and participation constraints
Some additional constructs: weak entities, ISA hierarchies,
and aggregation.
Note 1: E-R design is subjective - there can be different good
designs
Note 2: There are different conventions for the notation
Note 3: Not all constraints can be expressed, e.g. general
functional dependencies (see chapter on Schema refinement)
and quantitative constraints.

Michael T. M. Emmerich & Paul Breukel Databases