Fundamentals of Databases 1

2.0
ER-Modelling
Part 1
Fundamentals of Databases 1

2
 Fundamentals of Databases 1

Course Overview:
• Introduction
• ER modelling
• Relational database design
• Transforming ER model into relational DB model
• Design of the database schema
• Normalization
• Referential Integrity: Constraints
• Implementation
• DDL: Creation of database, tables and fields
• Loading data into the database
• Structured Query Language (SQL)
• Simple queries
• Complex queries: Joins, views, nested queries
• Referential Integrity: Temporal Data and Triggers
• Physical data organization
• Indexing Structures
 Fundamentals of Databases 1

Database Design
1. Requirements Analysis:
• Which section of the real world should be depicted?
• What are the overall information requirements?
Result: Requirements‘ Analysis
2. Conceptual Design
• Developing a data model that describes the requirements in an abstract way
Result: ER Model
3. Logical Design
• Mapping of the ER-Model into a database schema for a specific DBMS
• Normaliziation, Constraints
Result: Relational Database Structure / Schema
4. Physical Design
• Designing the internal Database Structures
Result: Physical Database Structure
5. Implementation
• Creating the database structure
• Result: Database Structure created.
6. Loading the database with data.
4
 Fundamentals of Databases 1

Miniworld

Steps of the Database Design

Requirement
Analysis

Conceptual •ER-Model
Design

•Relational
Logical Design Schema

•Internal
Physical Design Schema

Schema
•Database
Implementation
(DDL) Structure

5
Knirsch@htw-berlin.de
 Fundamentals of Databases 1

Requirement Analysis

Starting Point: Segment of the real world

1. What is the business case / scientific case?

2. What tasks / processes need to be supported?
3. What objects in the section of the real world are of interest?
4. Which object properties should be managed in the database?
5. What are the relationships between the objects?
6. What are the technical framework conditions
1. expected data / record quantity,
2. number of (concurrent) users,
3. availability requirements,
4. security requirements .

6
 Fundamentals of Databases 1

University Database Requirements

Some Requirements and constraints for a University Database System

(Campus Management System)

7
 Fundamentals of Databases 1

Conceptual design: ER model

The considered section of the real world is described in an abstract way, as a
graphical representation - the ER model:

• Entity Relationship Model,

• Developed by Peter Chen in 1976,
• We use the Chen notation for representation.

Building Blocks for the Conceptual Design:

1.Entities
2.Attributes
3.Relationships
4.Constraints

An ER model describes a logical structure.

8
 Fundamentals of Databases 1

DB / DBMS Architecture
User Application 1 Application 2 Administrative Tool

DML und Query Language DDL und DCL

Query Processing, Transaction Schema Administrative Tasks,

Query Optimization Management Management

Physical Organisation of Data

Logfiles Indices (Raw) Data DataDictionary

9
 Fundamentals of Databases 1

Building Blocks of the ER model

Attributes (properties)

Entity type (object type)

Relationship type

10
 Fundamentals of Databases 1

Building Blocks for the Conceptual Design: Entities

• the objects about which data will be stored,
university model:
• can be persons, things, places, concepts, events, …
• an entity occurrence is one instance of the entity type
example for university model:
• an entity type is the set that comprises all entity instances

Professor

Kemper

Seidl
Professor
Botchorishvili

Dundua
11
eva.knirsch@kiu.edu.ge
 Fundamentals of Databases 1

Set Theory
• Set theory is the foundation of relational database theory.
– An entity set is a collection of clearly distinguishable entity instances, the
elements
• the set „Professors“ has 4 elements
• In the following example the set "course" has 3 elements (entity
instances:
Course = {databases, usability, Java programming}
– The elements have attributes of the same type
• Example: course_id, title, description and semester hours per week
– A certain element occurs only 1x in the set.
– Starting point: The elements are not ordered.
– A set can be represented in enumerated form or as a Venn diagram.

12
knirsch@htw-berlin.de
 Fundamentals of Databases 1

Conceptual Design / ER Model

Entity type ≍ entity set

entity instance element

Meier
Databases
Schmidt
Müller Usability

Haase Java Programming

Student Course

13
 Fundamentals of Databases 1

Building Blocks for the Conceptual Design: Attributes

• properties (characteristics) of the entities
• each attribute has a name and a datatype (numeric, character, datetime, logical)
• Key: a minimal set of attributes whose values uniquely identify an entity instance in
an entity set.
– The key is minimal if it can no longer be reduced without losing its uniqueness.
– natural key: attribute or set of attributes that hold(s) semantic information
– artificial key: attribute that does not hold semantic information but usually
shows better performance
– keys are underlined in the graphical model

Professor

p_id name type

f_name l_name
14
eva.knirsch@kiu.edu.ge
 Fundamentals of Databases 1

ER model terms

Key
• Uniquely identifies a specific entity instance in the entity set

Definition Key:
A minimal set of attributes whose values uniquely identify an entity instance
from the entity set of its type. The key is minimal if it can no longer be reduced
without losing its uniqueness.

Correct example?
Car

registration_number vehicle_number

15
 Fundamentals of Databases 1

Attributes and attribute values

• Attributes are properties of entities.

• A set of values (domain) is assigned to each attribute. The value set (domain) provides all
possible values and thus determines which attribute values are permitted.
• Usually, only a small number the allowed values exist in a database at a given time.

Example:
Attribute: DoB
Attribute Domain: Date data type, starting e.g. from 01.01.1900
Attribute value:

Attribute: ID
Attribute Domain: Int (range -2147483648 to +2147483647, storage: 4 bytes)
Attribute value:

Attribute: Grade
Attribute Domain: Integer {1,2,3,4,5}
Attribute value:

16
 Fundamentals of Databases 1

• Exactly one attribute value of the domain is assigned to an attribute. Attributes may
not assume multiple values.
• Attributes exist in the ER model as simple or composite attributes. Composite
attributes are used to keep the ER model concise. They must be atomized for the
database design.
• The NULL value is a special attribute value. It means that a particular entity instance
has no attribute value for the attribute.
• NULL values are problematic in a couple of ways and should be avoided as much as
possible. One problem is that the underlying semantic often is not clear:
• is the condition not applicable?
• is it an unknown value?
• is it a missing value?

• Example: attribute driver's license number. If it is NULL it could mean:

• The person does not have a driver's license.
• The person does have a driver‘s licence but number is unknown.
• The person does have a driver‘s licence but the value is missing

17
 Fundamentals of Databases 1

Building Blocks for the Conceptual Design: Relationships

Student enrolls Course

• Relationships exist between the individual entity instances of the entity types.

• The set of relationships between entity types is called a relationship type.

• In mathematical terms, the instances in relation R are a subset of the Cartesian product of
the entity types involved.

R E1 x E 2 x … E n

• Relationship types cannot exist on their own, but are defined via the entity types involved.

• A relationship type therefore does not require its own key; the key attributes of the entity
types involved are used for identification.

18
 Fundamentals of Databases 1

Building Blocks for the Conceptual Design: Relationships

Student enrolls Course

• Relationship degrees: The degree of a relationship type is the number of participating entity
types.

• recursive relationship: There is only participating entity type. The entity instances of this
entity type participate in different roles.

• binary relationship: Most common relationship. two participating entity types

• ternary relationships: Three participating entity types

• multi-entity relationship: relationships of degree n.

19
 Fundamentals of Databases 1

tutors Can Relationships also have

attributes?

Student

examine

take
Professor

Course teach

20
 Fundamentals of Databases 1

Recursive Relationship

tutors Student x Student tutors

Student
In order to characterize a singular instance

(s1, s2) tutors

roles are needed:

(mentor: s1, mentee: s2).

These roles define that student s1 tutors student s2

21
 Fundamentals of Databases 1

Recursive relationship (self-referencing relationship)

E1 R

• There is only participating entity type. The entity instances of this entity type
participate in different roles.
• Two entity instances of the same entity type relate to each other.

Example: course – requires completion- course

predeccessor course

course requires

successor course
22
Knirsch@htw-berlin.de
 Fundamentals of Databases 1

Cardinality Ratios of Relationships

• Relastionships

1:1 relationship
1:N relationship / N:1 relationship
M:N relationship

store manager – runs – store

employee – has – job skills
painter – paints – painting
author – writes - book

23
eva.knirsch@kiu.edu.ge
 Fundamentals of Databases 1

E1 E2
1:N
1:1

N:1 N:M

Kemper - Slides on Database Systems: An Introduction, Chapter 2 : Conceptual Modeling 24

 Fundamentals of Databases 1

Cardinalities

1:1 an entity instance e1 of E1 is assigned at most one entity instance e2

of E2 and vice versa.

N:1 an entity instance e1 of E1 is assigned at most one entity instance e2

of E2 but every entity instance e2 of E2 can have any number (one,
several or none) of assigned entity instances e1 of E1

1:N an entity instance e1 of E1 are assigned any number of (one, several

or none) entitiy instances e2 of E2 but each entity instance e2 of E2
is assigned at most one entity instance e1 of E1.

N:M an entity instance e1 of E1 can be assigned any number of entity

instances e2 of E2 and vice versa.

25
Knirsch@htw-berlin.de
 Fundamentals of Databases 1

1-1 relationship:

1 1
E1 R E2

Examples: Person - has - driver's license

26
Knirsch@htw-berlin.de
 Fundamentals of Databases 1

E1 R E2

Examples: Company - employs -- employees

Woman - has - child
Customer - orders – Order
Student - enrolls - course

What is the cardinality of the recursive relationships on slides 21

and 22?

27
Knirsch@htw-berlin.de
 Fundamentals of Databases 1

Ternary relationships

E1 R E3

E2

Examples: Doctor – prescribes – patient – drug

Member – reserves – sports device – timeslot
Professor – supervises – student – Ph.D. thesis
Professor – examines – student – course

28
Knirsch@htw-berlin.de
 Fundamentals of Databases 1

Cardinalities for Ternary Relationships

Doctor prescribes Patient

Drug

How to set cardinality for a ternary relationship:

1. Can doctor A prescibe Drug B for more than one patient?
2. Patient C takes drug B. Can drug B have been prescribed for patient C by
more than one doctor?
3. Can doctor A treating patient C prescribe more than one drug?

29
Knirsch@htw-berlin.de
 Fundamentals of Databases 1

Cardinalities for Ternary relationships

ClubMember reserves SportsDevice

Timeslot

Set the cardinalities.

30
Knirsch@htw-berlin.de
 Fundamentals of Databases 1

Cardinalities for Ternary relationships

Professor supervises Ph.D.Student

Ph.D. Thesis

Set the cardinality:

31
Knirsch@htw-berlin.de
 Fundamentals of Databases 1

Cardinalities for n-digit relations

Professor supervises Student

Course_paper

1. Professor P and Student S 

2. Student S and Course_Paper T 
3. Professor P and Course_Paper T 

32
Knirsch@htw-berlin.de
 Fundamentals of Databases 1

p1 Professors

s1 p2

Students s2 p3
s1
p4
s2 s3

s3 s4
t1 CourseThesis
s4
s5
t2

s6 t3

t4

dotted lines mark illegal instances.

33
 Fundamentals of Databases 1

University ER Model requires

Successor
St_No Predecessor Course_No

takes Course ECTS

Name Student

Semester Title

Grade examines teaches

PersNo
Rank

Name Assistant worksfor Professor Room

Research Field
PersNo Name
34
 Fundamentals of Databases 1

Substitute Ternary Relationship by Binary Relationships?

Doctor prescribes Patient

Drug

How to set cardinality for a ternary relationship:

1. Can doctor A prescibe Drug B for more than one patient?
2. Patient C takes drug B. Can drug B have been prescribed for patient C by
more than one doctor?
3. Can doctor A treating patient C prescribe more than one drug?

35
Knirsch@htw-berlin.de
 Fundamentals of Databases 1

Decomposing Ternary Relationships into Binary Relationships:

Doctor treats Patient

prescribes takes
Drug

Can a ternary relationship be replaced by (three) binary relationships?

36
Knirsch@htw-berlin.de
 Fundamentals of Databases 1
Ternary Relationships
• El: “In general, a ternary relationship type represents different information than do three
binary relationship types.”

• Consider the ternary relationship (doctor, drug, patient – model 1) and compare with the
three binary relationships (model 2)
– treats (doctor, patient),
– prescribes (doctor, drug),
– takes (patient, drug).

• The following constraint should hold true:

A relationship instance (doctor A, drug B, patient C) should not exist in relationship
prescribes in model 1 unless the following relationship instances exist in model 2:
– a relationship instance (doctor A, drug B),
– a relationship instance (doctor A, patient C) and
– a relationship instance (patient C, drug B)

• But: The existence of three binary relationship instances (doctor A, drug B), (doctor A,
patient C) and (drug B, patient C) does not necessarily imply that an instance (doctor A,
patient C ,drug B) exists in the ternary relationship, because the meaning is different.

37
 Fundamentals of Databases 1

Cardinalities for Ternary relationships

Doctor treats Patient

prescribes Drug takes

Can a ternary relationship be replaced by three binary relationships?

EL, chapter 3.9.1, p.91: Although in general three binary relationships cannot replace
a ternary relationship, they may do so under certain additional constraints.

38
Knirsch@htw-berlin.de
 Fundamentals of Databases 1
Ternary Relationship

Elmasri, p. 89

39
 Fundamentals of Databases 1

Strong / Weak Entities

Seat is_in Airplane

seat_id
Seat 6a in airplane_id: AB_1234
Seat 6b in airplane_id: AB_1234
Seat 6a in airplane_id: AB_6789
Seat 6b in airplane_id: AB_6789

Weak entity instance:

- can only be identified with its owner entity instance

Weak entity type:

- always has a total participation constraint in regard to its identifying relationship.
- has a partial key that uniquely identify instances that belong to the same owner entity.
- partial key is marked with a dotted line.
- Composite key is key of owner entity + key of weak entity

Relationship between owner entity and „weak“ entity is always 1:N or 1:1.
40
Knirsch@htw-berlin.de
 Fundamentals of Databases 1

Strong / Weak Entities

belongs_
Case to
Client

Example: Law firm

• Client Smith has cases 1,2,3 and 4

• Client Harper has cases 1,2,3,4 and 5

• The key for the entity "case" is only unique in relation to a client.
• A weak entity always has a composite (minimal) key: its own partial key
and the key of the owner entity

41
Knirsch@htw-berlin.de
 Fundamentals of Databases 1

Which entity could very well be a weak entity here? 42

Fundamentals of Databases 1

43
 Fundamentals of Databases 1

University ER Model
requires
Successo
St_No Predecessor Course_No
r

takes Course ECTS

Name Student

Semester Title

Grade examines teaches

PersNo
Rank
Name Assistant worksfor Professor Room

Research Field
PersNo Name
44
 Fundamentals of Databases 1

1 N grade
Student takes exam
exam_part

N
Stud_id
holds

M prof_id

Professor
Entity Exam modelled as a weak entity

45
Fundamentals of Databases 1

46
 Fundamentals of Databases 1

Building Blocks for Conceptual Design: Constraints

Constraints are restrictions or conditions on the data.

1. Structural Constraints (Mapping Constraints)

Goal: data is consistent with the requirements.
2. Integrity Constraints
Goal: Data stay consistent in the database

Structural Constraints

• Cardinality Ratio
Examples:
• A person can only be married to one other person or not be married at all.
• An employee can only work in one department.
• A pupil can only go to one school.
• A person can only have one passport.

47
 Fundamentals of Databases 1

Building Blocks for Conceptual Design: Constraints

• Participation Constraints: This specifies whether the existence of an entity

instance e1 of E1 depends on its being related to an entity instance e2 of E2.
via the relationship type.
There are two types of participations: total (mandatory) and partial (optional).
Example for total:
• Every employee must work for a department.
• Every student needs to take at least one course.
Example for partial:
• Some of the employees may manage a department. Not all employees
manage a department.
• A person can be married but does not have to be married

48
 Fundamentals of Databases 1

Integrity Constraints
Goal: Data Integrity in the databse

49
eva.knirsch@kiu.edu.ge
 Fundamentals of Databases 1

Building Blocks for Conceptual Design: Constraints

1. Domain Constraints: Definition of a valid set of values for an attribute
Restrictions on the attribute values:
- data type
- not NULL
- unique values
- check constraints: only certain values are allowed

2. Entity Integrity Constraint

Entity integrity constraint specifies that the primary key attribute must not
contain a NULL value in any entity instance. This is because the presence of
NULL value in the primary key violates the uniqueness property.

3. Key Constraint
Attribute or minimal combination of attributes that uniquely identifies each
entity instance.

50
 Fundamentals of Databases 1

Reading:

• Elmasri, Chapter 3, Data Modelling using the ER Model

• Coronel, Morris, Chapter 2 (2.1 – 2.3, 2.5), Data Models
• Cardinality of Ternary Relationships, nicely explained again in
https://www.youtube.com/watch?v=HOd061LGgGU

51