25/03/2025

Databases I UN

Lecturer: Teaching assistants:

Lili Nemec Zlatolas Luka Hrgarek
Nika Jeršič

About the course

• Course:
• Lectures: 15 hours (Lili Nemec Zlatolas)
• Computer exercises: 30 hours
• Independent work: 105 hours
• Evaluation:
• Exercises: 40% of the final mark
• Written exam: 60% of final grade

1
 25/03/2025

Summary
Databases, DBMS, Database design

Conceptual design

• E-R model
• Normalisation

Logical design

• Relational data model

Database implementation (SQL)

• DCL
• DDL (CREATE)
• DML (INSERT, UPDATE, DELETE)
• DQL (SELECT)
• EVENTS, STORED PROCEDURES
• Triggers
• TCL - Transactions

Basic information on
databases

2
 25/03/2025

Data and information

Data is a reproducible representation of Information is knowledge about objects,

information in a formalised manner such as facts, events, things, processes
suitable for communication, or ideas, including concepts, which have
interpretation and processing (ISO/IEC a specific meaning within a particular
2382-1:1993). context (ISO/IEC 2382-1:1993).
• Example: 15, Matevž • Example: 15°C, person Matevž / potato
and bean dish Matevž

Data  information
• The relationship between data and information is represented by a
formula:

I = i(D, S, t)

I - Information
D - Data
S - semantic background / context
t - time interval

Börje Langefors 7

3
 25/03/2025

Database definition

A database is an
A database is a collection
organised collection of
of interlinked data about
structured information or
an organised working
data stored electronically
system, intended for
in a computer system.
different users.
(Oracle)

Important concepts
• DB conceptual design
• Entity-relational model (E-R model)
• Logical DB design
• Relational data model
• SQL
• Data definition language (DDL) - setting up a database
• CREATE, ALTER, DROP, TRUNCATE
• Data manipulation language (DML) - data insertion, querying and database management
• INSERT, UPDATE, DELETE
• Data query language (DQL) -queries
• SELECT
• Transaction Control Language (TCL) - enable transactions
• COMMIT, ROLLBACK, SAVEPOINT SET TRANSACTION
• Data Control Language (DCL) - allow commands for rights, permissions, etc.
• GRANT, REVOKE

4
 25/03/2025

Database development
• 1960s
• Charles W. Bachman designed
the Integrated Data Store (IDS),
the first known DBMS.
• IBM has created its own IMS.
• 1st generation DB:
hierarchical DBMS.

hierarchical
10

Database development
• 1960s
• 1965 - 1971 activities of the
DataBase Task Group (DBTG) of
the CODASYL (Conference on
Data Systems Languages)
• 1st generation DBMS:
networked DBMS.

hierarchical Network
11

5
 25/03/2025

Database development
• 1970s
• 1970 Edgar F. ´Ted´ Codd
publishes a seminal paper that
enables the introduction of the
relational data model.
• 1976 entity-relational (E-R)
data model (P. Chen).
• 2nd generation DB: relational
DBMS.

hierarchical Network relational

12

Database development
• 1980s
• In the early 1980s, the first
object-oriented data models
appear.
• 3rd generation DB: object-
oriented DBMS.

hierarchical relational object

Network object-oriented 13

6
 25/03/2025

Database development
• 2000 ->
• Worldwide Web Consortium -
Semantic Web Stack.
• 2008 - Neo4j Cypher language
• 2008 ->
• Facebook -> Hive and
Cassandra.
• Model as you go / on the fly.
• Usage today mostly for big data
& real-time web applications

hierarchical relational object NoSQL

Network object-oriented 14

Database development
• NewSQL (2011 ->)
Relational NoSQL NewSQL
DB
ACID yes NO yes
transactions
SQL support yes NO yes
Standardised yes NO NO
High availability NO yes yes
Horizontal NO yes yes
expansion

hierarchical Network relational object NoSQL NewSQL

object-oriented 15

7
 25/03/2025

DBMS market share (after income)

16

Use of databases

• Examples of how databases can be used:

• All websites.
• Electricity suppliers hold customer and fault data in a database.
• Social networks store information about users, friends, activities, messages, etc.

17

8
 25/03/2025

Where to look for

information and go deeper
• https://dev.mysql.com/doc/refman/8.0/en/
• https://www.sololearn.com/
• https://www.w3schools.com/sql/default.asp
• https://stackoverflow.com/
• https://sqlzoo.net/
• AI tools - with critical thinking!

18

19

9
 25/03/2025

Database
management
systems

Database Management System (DBMS)

• The database is usually managed through a database management

system (DBMS).
• The data and the DBMS and related applications constitute the database
management system, or the database for short.
• DBMS provides efficient, reliable and secure storage of data
accessible to different users and access to large amounts of data.

21

10
 25/03/2025

The most • MySQL (open source

widely used DBMS)

DBMS • ORACLE (multi-model

DBMS, NoSQL)
• Microsoft SQL Server
• PostgreSQL (open source
object-relational DBMS)
• SQLite

22

Database design

11
 25/03/2025

Databases

24

Database design

• The DB is the core of the information system.

• The aim of the DB design is to have an efficient database that satisfies all
the information requirements of the potential users for the given scope.
• The consequences of good DB design:
• easy data modification,
• easy access to information,
• easy app design.

25

12
 25/03/2025

ANSI-SPARC tri-level architecture

• ANSI - American National Standard

Institute
• SPARC - Standard Planning And
Requirements Committee

26

Architecture DB

• Primary objective:
• Separating the selected user view from its physical representation.
• Independencies in ANSI-SPARC:
• The three-tier architecture ensures data independence.

27

13
 25/03/2025

Architecture DB

• External level
• A user view of the database or a description of
the part of the database relevant to a particular
user, represented by:
• entities,
• attributes,
• the relations of your own real environment.
• Different representations of the same data.

28

Architecture DB

• Conceptual level
• Comprehensive information on the content and
structure of the database, presented with:
• all entities, relations and associated
attributes,
• restrictions,
• semantic information about the data,
• information related to security and integrity.

29

14
 25/03/2025

Architecture DB

• Internal level
• Physical representation of the database on
• on your computer.
• A description of HOW the data is stored in the
DB is given.
• Physical organisation of data
• It is handled by the operating system, supported
by DBMS.
• The separation of functions between the DBMS
and the OS at the physical level is not strictly
defined and varies widely between systems.

30

DB design
• Conceptual design
• We design a model for the information use of a
selected work-integrated organised system
(enterprise), which is completely independent
of logical and physical design.
• Logical design
• We design a model of a selected work-
concluded organised system for the target
group of a database management system -
DBMS.
• Physical design
• The process of preparing the description of the
database implementation in secondary storage
(description of the data structure and access
methods) for the selected target DBMS.

32

15
 25/03/2025

DB conceptual
design

DB conceptual design

DB conceptual design

The purpose of conceptual modelling is to achieve a goal:

EVERYTHING THAT IS NEEDED IS HERE and EVERYTHING THAT IS HERE IS NEEDED.

Steps in the design of the DB conceptual model:

1. data analysis and requirements gathering,
2. E-R model design,
3. normalisation.

34

16
 25/03/2025

DB conceptual design

1. data analysis and requirements gathering

Definition of user groups and application areas

Analysis of the operational environment and processing requirements

Examining sources of information and data

Archiving (legal provisions)

Name and description of the entity

Attributes and their properties (types, thresholds, use, safety, relevance to

COS)

35

DB conceptual design

2. designing the E-R model

• Entity-relationship model
• An E-R model is a conceptual representation of the real world and the objects of a
closed organised system.
• The E-R model consists of entities and relations.
• There may be several E-R models for a single database.
• The E-R model contains objects that are relevant to the functions and processes of
the outside world.
• A picture says more than a word.
• Easy and quick to learn and widely used in practice.
• Prevalence in the literature.
• Compatibility with DBMS-containing devices.

36

17
 25/03/2025

DB conceptual design

2. designing the E-R model

• Let's try to make the E-R model as wide as possible.

• In specific cases, additional E-R modeling guidelines are used to shrink and reshape the E-R model
to the point where it is optimal for the case at hand.
• The E-R model is always built according to the case being considered. We take into account the
client's requirements, the way DB is used, etc.
• In which cases does the E-R model need to be shrunk or otherwise adapted?
• When we want to speed up certain SQL queries that will e.g. be executed more frequently than others
(adapt by crossing/merging entities, etc.),
• when you want to frequently access data that is computable (adding an attribute representing e.g. the sum
of the values of other attributes),
• ...

37

DB conceptual design

2. designing the E-R model

• The basics of the E-R model:

• The structure of a database can be
represented by an entity-relational
model.
• The E-R model is represented by an E-
R diagram.

38

18
 25/03/2025

2. designing the E-R model:

Basic of an E-R model

• Entity
• is an independent data object (physical, conceptual) of a complete
organised system, which is by definition a data carrier.
• We use a noun to write it.
• Example: person, thing, event.
• The properties of entities are described by attributes.
• A weak entity:
• is an entity without its own key attribute (not recognisable by itself). It is always
represented together with (in relation to) a strong entity whose key is represented
from its own attributes.

39

2. designing the E-R model:

Basic of an E-R model

• Key (identifier): • Attribute:

• A leading attribute that allows • provides information about
entities as well as relations,
the identification of a single describing their properties.
entity. We distinguish:
• Candidate, • Attribute domain:
• primary, • is the set of allowed values for
• secondary, each attribute.
• composed and • Relation:
• external (foreign) key. • is a link between two or more
• It can be optional or entities.
compulsory. • We use a verb to write it.

40

19
 25/03/2025

2. designing the E-R model:

Basic of an E-R model

• Cardinality (numerosity):
• is the participation of an entity in a particular relation (a link between two or more entities).
• IMPORTANT: For each relationship, cardinality is established in both directions (A->B and B->A)!
• We distinguish cardinalities:
• minimum cardinality (between 0 and 1)
• optional: if the minimum cardinality in the A->B direction is 0.
• mandatory: if cardinality is in the direction A->B 1.
• maximum cardinality (between 1 and n)
• 1:1 - one-to-one
• 1:M - one-to-many
• M:N - many-to-many
• The cardinality M:N is undesirable, so we replace it with
with two new cardinality relations 1:N and N:1 and
a new entity.

41

2. designing the E-R model

Design guidelines - examples

Resolution of the M:N

relation
• The resolving entity also
has ITS primary key!

42

20
 25/03/2025

2. designing the E-R model

E-R diagram notations

Examples of cardinality:

43

2. designing the E-R model

Design guidelines - EXCEL and DB examples

Student Faculty NAME OF ENTITY

registration_num nam ATTRIBUTES
No Name ber Date of birth ID e Description
1 David E9320376041 12.12.2001 1 FERI FERI was founded...
tuples
EPF has a tradition
2 May E3107410974 15.03.2001 2 EPF of...
PRIMARY KEY 3 Ales E1234464687 NULL 1 FERI FERI was founded...
4

Student Faculty
ID name entry_no Date of birth fk_Faculty ID name Description
1 David E9320376041 12.12.2001 1 1 FERI FERI was founded...
2 May E3107410974 15.3.2001 2 2 EPF EPF has a tradition of...
3 Ales E1234464687 NULL 1 3 PF PF used to be part of a larger...
4

44

21
 25/03/2025

2. designing the E-R model

Design guidelines - examples

• HISTORICAL data is stored in the database!

• In most cases, the price is not an attribute, it is put in a new entity,
because the price changes over time! The new entity is related to the
original entity by relationship 1...n.
Example:

converted

45

2. designing the E-R model

Design guidelines - examples

• We aim for the cardinality between an entity and its attributes to be 1..1! Exceptions are
e.g. the first and last name of a person in the entity person, the date (we also don't put the
date in a new entity), etc.
• Types, categories, fields, types are not attributes, they are put into a new entity, also
called a code list. The new entity is linked to the original entity by a 1...n or m...n
relationship.
Example:

converted

46

22
 25/03/2025

2. designing the E-R model

Design guidelines - examples

• We separate the address and the post (code lists) into two entities:

Example:

converted

47

2. designing the E-R model

Design guidelines - examples

• There can be several relationships between two entities.

Each relationship has its own meaning. It is therefore very important to give each link as
descriptive a name as possible! (Example: a wedding and a football match)

• An entity can be connected to itself.

It is very important to give the relationship a name in both directions of the relationship!

48

23
 25/03/2025

2. designing the E-R model

Design guidelines - examples

Example for "sales/accounting":

 Appendix 1: Quantity attribute in the quantity entity.

If you have purchased e.g. 10 of the same item, now you don't need to link it
10 times to the invoice entity, you link the item 1x and enter the number 10 in
the quantity attribute.
 Appendix 2: The final_price attribute in the invoice entity.
The total amount is a calculable attribute, but it can be added here by
exception. Since this amount will most likely be queried frequently (daily),
the total_amount attribute can be added to speed up the querying of the
amount.

49

2. designing the E-R model

Design guidelines - examples

Fan trap
The cardinality of the relationship is set up in such a way that the relationship between entities are ambiguous. It occurs, in
principle, when two 1:m relationships arise from a single entity. Example of a fan trap:

• To write an enquiry for: In which department does Maja Meško work? Because of the wrong cardinality, we can't find out.
The solution is to recast the relationships as they really are (Employee works in a department, department is located in a
location.):

50

24
 25/03/2025

2. designing the E-R model

Design guidelines - examples

• We are developing a complete organised

system (COS).
• Important: COS does not normally include the
entity of itself.
• Example: HOTEL
• A hotel does not have the entity of a hotel if there is
only 1 hotel and we are doing COS for it.
• However, if it is a chain of hotels, you can name one
entity HOTEL and add attributes to indicate which
hotel it is (e.g. name, hotel number, etc.).

52

2. designing the E-R model

Design guidelines

• Consistent naming!
• E.g.: singular entity name in upper case, key in lower
case and with underscores
• Not used:
• Hyphens, spaces
• ENTITLE
• # key (id_entity)
• * attribute
• ° option_attribute

53

25
 25/03/2025

DB conceptual design

Steps to build an E-R model - repeat

• Define the purpose of the database,
• We find and organise the information you need,
• Designing the E-R model (Consistent naming (case and singular/plural).
• Define entities
• We define relationships between entities
• Define cardinality (minimum, maximum; 1:1, 1:M, M:N)
• Define primary keys (each entity has a primary key)
• Define mandatory and optional attributes (entity to attribute ratio is 1:1)
• Normalisation.
• Correcting the E-R model.

• Building an E-R model is subjective and there are several possible solutions for certain scenarios,
but we need to follow the guidelines and build a good quality E-R model.

54

2. designing the E-R model

Design guidelines - tools

• We can use:
• https://www.diagrameditor.com/ ,
https://app.diagrams.net/
• Search for "Entity relation" etc. in the search engine
• MySQL Workbench - features:
• It resolves M:N relations by itself, but according to the
guidelines we have to correct them (name change -
consistency, adding a primary key) or we prefer to do it
ourselves.
• Automatically generates foreign keys and transitive
foreign keys. The transitive ones should be deleted, the
others can be left and named consistently.

55

26
 25/03/2025

2. designing the E-R model

Creating an E-R model in MySQL Workbench

56

2. designing the E-R model

Creating an E-R model in MySQL Workbench
• Default: • Corrected:

57

27
 25/03/2025

DB conceptual design

Identifying and non-identifying link

• The default non-identifying relationship is usually used
• Example of an identifying relationship
Student Telephone numbers
ID name entry_no Date of birth ID fk_student Number
1 David E9320376041 12.12.2001 1 1 041 335 668
2 May E3107410974 15.3.2001 2 1 068 335 335
3 Ales E1234464687 NULL Composite primary 3 2 051 668 335
key
4 4 3 068 335 668

• Example of a non-identifying relationship

Student Town
ID name entry_no fk_town ID Name
1 David E9320376041 1 1 Maribor
2 May E3107410974 2 2 Ljubljana
3 Ales E1234464687 1 3 Celje
4 Ana E8528525464 null 4 Dill
58

Transitive foreign keys in MySQL Workbench

• Removal of transitive foreign keys generated by identification links

59

28
 25/03/2025

SQL - DDL

Datatypes in MySQL

• Choose the appropriate data type for each attribute (column) and specify the values to be stored.
• They may be different for different DBMSs, so check the documentation to see what the correct data
types are for your DBMS.
• We distinguish:
• Numeric data types
• Time data types
• Character data types
• Spatial data types
• ...
• MySQL data types: https://dev.mysql.com/doc/refman/8.0/en/data-types.html

60

SQL - DDL

Numeric data types

• Storing numeric/number strings
• Examples: id, size, price, discount, quantity,...
• The most common:
Tip Description Example of an entry
INT Integers, the default size is 4 syllables, which means you can enter numbers between - 12345678
2147483648 and 2147483647. Example input: tax number.
DECIMAL(M,D) Example: DECIMAL (5,2) are numbers from -999.99 to 999.99. The first number tells the total 952.23
number of digits, the second the number of digits after the decimal point. Numbers that should
not be rounded should be in DECIMAL. Example: price of a product.
FLOAT(M,D) / Mostly used for physical properties (e.g. temperature, altitude, etc.). It works similarly to -123.4567
DECIMAL, i.e. the first number in parentheses is the total number of digits, the second is the
FLOAT
number of digits after the comma, but if you don't enter the number in parentheses and you
have a floating point. Example: temperature.
BOOL(EAN) / TINYINT(1) T (1), F(0) - depending on the DBMS, the content can be "true" or "false" or 0 or 1. Alternatively, 0/1
NULL can be stored.MySQL does not fully support the BOOLEAN data type.

61

29
 25/03/2025

SQL - DDL

Time data types

• Time data storage
• Examples: date of birth, running time, valid until, valid from,...
• The most common:
Tip Description Example of an entry
DATE YYYY-MM-DD '2020-10-31'
DATETIME YYYY-MM-DD HH:MM:SS '2020-10-31 16:23:59'
TIME HH:MM:SS '500:15:15'
TIMESTAMP Suitable for calculating the time difference between two times. It is stored as '2020-05-15 00:05:00'
the number of seconds elapsed since 1.1.1970 (UTC). The value is
automatically assigned when an input is requested.
https://www.unixtimestamp.com/
UNIX_TIMESTAMP(attribute) '1589493900'
YEAR 4 integers between 1901 and 2155. '1999'

62

SQL - DDL

Character data types

• Storing character strings
• Examples: first name, last name, address, email address, description, title,...
• The most common:
Tip Description Example of an entry
VARCHAR(N) It occupies memory dynamically, unlike CHAR. Thus, if only 1 character out of 4 is entered, a '[email protected]'
VARCHAR(4) with 2 characters occupies 3 syllables (1 syllable is reserved for the length prefix in
VARCHAR). A CHAR(4) with 2 characters occupies 4 syllables.
CHAR(N) Example: CHAR(4) represents 4 characters (used e.g. for a postcode or tax code when the '12345678'
length is fixed).
TEXT Suitable for longer texts. 'Lorem ipsum dolor sit amet, consectetur
adipiscing elit. Ut in lorem feugiat, ultricies odio
ac, vehicula ligula. '
ENUM() In the table, assign values to each number. The number 0 is NULL by default, so we start with 1, 2, 3
the 1st position, e.g. small, then the 2nd position medium, the 3rd position large, etc. Example:
ENUM('S','M','L'). We prefer to use code lists in such cases because of the harder expansion
possibilities and easier querying.

63

30
 25/03/2025

SQL - DDL

Data types

• We plan the database appropriately without having to expand and

change the database frequently.
• Example:
• Enrolment No. 2010: 93545201  INT type selected
• 2020 Enrolment No: E3545201  new type VARCHAR(8)
• Enrolment No in 2030: E35452010  new type VARCHAR(9)
• If the database was planned in 2010, it might be most appropriate to
choose the VARCHAR(15) data type in the above example.

64

DB conceptual design

Example of an E-R model:

STUDENT OFFICE
The computer support for the student office must be able to view the basic personal data of
each student (enrolment number, first name, last name, address, study program, pre-
education). We also want to know where the student's permanent, temporary and postal
address is.
The database must also provide an overview of the courses and the teaching staff involved in the
teaching process (lecturer, teaching assistant, laboratory assistant). All participants in the
teaching process are taken into account. For each course, it should be possible to view all the
basic data and a brief overview of the course content.
Students can also buy various souvenirs or pay for an exam registration at the desk. They will
receive an invoice for this.
We would also like to have access to the theses (already completed and those for which only the
title has been confirmed). In addition to the title of the thesis, we would like to know the author,
the mentor, the co-mentor or assistant for the thesis, the deadline for submission or defence of
the thesis.

66

31
 25/03/2025

Normalisation

3. Normalisation

This is a process to ensure that

entities do not contain redundant or
Normalisation is a technique that
ambiguous data, which will not be
allows the creation of a set of entities
subject to inaccuracies when they
with desired properties derived from
are entered, deleted or corrected.
the data requirements of a closed
We consider normalisation as a
organised system.
process complementary to the E-R
model.

INPUT:
OUTPUT:
non-normalised normalisation
normalised
entity (relation)
entities (relations)

68

32
 25/03/2025

PB conceptual design

Data redundancy
• Redundancy means duplication. Data redundancy means that the same data
is stored multiple times. Uncontrolled redundancy is an undesirable
phenomenon. Unwanted consequences of uncontrolled data redundancy are:
• doubling the need to enter and update data,
• sooner or later, some users forget to change (update) one of the copies of the data - so the
data becomes inconsistent (inconsistent, contradictory),
• excessive use of persistent memory, even archive copies are too large.

Student Faculty
No Name registration_number Date of birth ID name Description
1 David E9320376041 12.12.2001 1 FERI FERI was founded...
2 May E3107410974 15.03.2001 2 EPF EPF has a tradition of...
3 Ales E1234464687 NULL 1 FERI FERI was founded...
4

69

Anomalies
• Entities containing redundant data
can cause anomalies in data
modification.
Worker
• There are several types of
Last Departmen Department Place of
anomalies: ID
name tID name department
• Anomalies when adding rows to an 104 Perko 3 Sales Ljubljana
entity
180 Mevded 2 Finance Maribor
• Anomalies when deleting rows from an
entity 192 Volk 2 Finance Maribor
• Anomalies when updating rows in 197 Pihlar 3 Sales Ljubljana
Entities 199 Kalin 2 Finance Maribor

Attributes with repeated data

70

33
 25/03/2025

PB conceptual design

Adding anomalies - an example

• If you want to add information
about new employees (surname)
for a department, you also need to
enter all the details of the Worker
organisational unit. ID
Last Departmen Department Place of
name tID name department
• If you want to add information 104 Perko 3 Sales Ljubljana
about a new department that has 180 Mevded 2 Finance Maribor
no employees yet, you must enter
192 Volk 2 Finance Maribor
Null in all fields describing the
197 Pihlar 3 Sales Ljubljana
employees.
199 Kalin 2 Finance Maribor

71

Deletion anomalies - an example

• If we delete the row representing
the last member of an
organisational unit from an entity,
we also lose the data about that Worker
organisational unit. ID
Last Departmen Department Place of
name tID name department
104 Perko 3 For sale Ljubljana
180 Mevded 2 Finance Maribor
192 Volk 2 Finance Maribor
197 Pihlar 3 Sales Ljubljana
199 Kalin 2 Finance Maribor
212 Novak 1 HR Celje

72

34
 25/03/2025

PB conceptual design

Update anomalies - an example

• If we want to change the value of
an attribute of a certain section
(e.g. place), we need to edit all the
rows where the attribute value Worker
appears. DelavecID
Last Departmen Department Place of
name tID name department
104 Perko 3 Sales Ljubljana
180 Mevded 2 Finance Maribor
192 Volk 2 Finance Maribor
197 Pihlar 3 Sales Ljubljana
199 Kalin 2 Finance Maribor
212 Novak 1 HR Celje

73

Keys
• Keys: Primary Candidate Composite Secondary External (foreign)
• candidate,
• primary,
• secondary, ID name entry_st date_of_birth email fk_Faculty
• composite and 1 David E9320376041 12.12.2001 [email protected] 1
• foreign 2 May E3107410974 15.3.2001 [email protected] 2
Student

(external) / 3 Ales E1234464687 NULL [email protected] 1

foreign key. 4

ID name Number_of_students
1 FERI 3000
2 EPF 2000
Faculty

3 PF 500

74

35
 25/03/2025

PB conceptual design

Functional dependence
• Functional dependency describes the relationships between attributes in an entity
(relation).
• If A and B are attributes of an entity (relation) E, then attribute B is functionally dependent on
attribute A, or A functionally determines B (notation: A  B), if each value of attribute A has
exactly one value of attribute B associated with it.

A B
X
• X = {A, B}, X → Y ∧ B → C
A Full functional
dependence (X Y)
Partial functional
Y
dependence (B  C)
C B

75

Functional dependence - types and properties

• Types of functional dependencies:

• Full: the attribute depends on the whole key.
• Partial: the attribute depends only on part of the key (if there are
compound keys).
• Transitive: an attribute depends on a key via an indirect attribute
that is not the key.

76

36
 25/03/2025

PB conceptual design

Functional dependence - an example

• We have an entity with a schema
• Exam(StudentID, LastName, FirstName, CourseCode, ExamDate, GradeAll,
GradeExam)
• with the following meaning:
• The student with the registration number StudentID and the surname
Surname and first name FirstName has taken an examination in the
course with the code CourseCode on the DateOfExam. He/she has
obtained a grade of ExercisesGrade and a ExamGrade.
• The functional dependencies of the Exam relational schema are:
• F ≡{StudentID  (Surname, FirstName),
(StudentID, CourseCode, DateOfExam) (ExercisesGrade, ExamGrade)
}

77

PB conceptual design

Normalisation process
• The process of transforming entities
(relations) into a form in which
anomalies cannot occur is
normalisation.
• Normal forms represent rules for
grouping attributes into entities, taking
into account logical dependencies.
• There are several levels of normal forms,
and in practical cases we usually
normalise up to the 3rd normal form.

• Entity(Attribute)
• E(A1 , A2 , .... , A )n

78

37
 25/03/2025

Normal forms
• 1NF: Entity E(A1 , A2 , ..., An ) is in first normal form if the values in the
domains are basic for each attribute Ai in entity E(A1 , A2 , ..., An ).
• 2NF: An entity E(A1 , A2 , ..., An ) is in second normal form if it is in first
normal form and every non-key attribute is completely functionally
dependent on the primary key of entity E(A1 , A2 , ..., An ).
• 3NF: An entity E(A1 , A2 , ..., An ) is in the third normal form if it is in the
second normal form and none of its non-key attributes are transitively
dependent on the entity key.

79

PB conceptual design

Normal shapes
• BCNF: An entity E(A1 , A2 , ..., An ) is in Boyce-Codd normal form if it is in
third normal form and every determinant is a key.
• 4NF: An entity E(A1 , A2 , ..., An ) is in fourth normal form if it is in BC normal
form and does not contain multi-valued dependencies.
• 5NF: An entity E(A1 , A2 , ..., An ) is in fifth normal form if it is in fourth
normal form and does not contain a projection-merge dependency that is
not due to a candida key.
• 6NF: Entity E(A1 , A2 , ..., An ) is in sixth normal form if it is in fifth normal
form and there is no key dependency.

80

38
 25/03/2025

1NF - first normal form

• An entity is in its first normal form if:
• Contains atomic values and
• has no repeating attributes  there are no attributes or groups of attributes that have multiple values
at the same value of the other attributes (there are multiple values at the intersection of one row and
one column),
• has a defined primary key and certain functional dependencies.
• Steps:
• split the composite data in the attributes into atomic values (separate the composite data),
• remove repeating attribute groups,
• determine functional dependencies,
• determine the primary key.

81

PB conceptual design

Entity in non-normalised form - example

• Index (enrolment_nr, surname_name, post, place, { course_code, course_title, grade } )

Values represent composite data

A group of repeating attribute values.
(first name + last name).

Index
enrolment_ surname_name Mail Country Course_code course_title grade
nr
E12234564 Bratina Simon 4000 Kranj 20020 IS 10
20021 TPO 8
20033 IPI 8
E12234562 Bizjak Tadeja 2250 Ptuj 20060 E1 9
20033 IPI 6

82

39
 25/03/2025

Conversion to 1NF - example

Index(enrolment_nr, surname_name, post, place, ( course_code, course_title, grade ) )

Identify the composite attributes and split them into atomic values
Index(enrolment_nr, surname, first_name, post, place, (course_code, course_title, grade ) )
Identifying functional dependencies
F  {enrolment_nr  (surname, first_name, post, place),
course_code  course_title,
post  place,
(enrolment_nr, course_code )  grade }
Determine the primary key
Index(enrolment_nr, surname, first_name, post, place, ( course code, course_title, grade ) )
Eliminate recurring attributes
Student (enrolment_nr, surname, first_name, post, place )
Course(enrolment_nr, course code, course_title, grade )

83

PB conceptual design
Conversion to 1NF - example
Index
enrolment_ surname_name post place Course_code Course_title grade
nr
E12234564 Bratina Simon 4000 Kranj 20020 IS 10
20021 TPO 8
20033 IPI 8
E12234562 Bizjak Tadeja 2250 Ptuj 20060 E1 9
20033 IPI 6

Student
enrolment_nr surname fist_nam post place
1NF
e 1NF Subject
E12234564 Bratina Simon 4000 Kranj
enrolment_ Course_code Course_title grade
nr
E12234562 Bizjak Tadeja 2250 Ptuj 20020 IS 10
E12234564
E12234564 20021 TPO 8
E12234564 20033 IPI 8
E12234562 20060 E1 9
E12234562 20033 IPI 684

40
 25/03/2025

2NF - second normal form

• An entity is in its second normal form if:
• is in first normal form and
• does not contain partial functional dependencies  no attribute that is not part
of the key is functionally dependent not only on part of the primary key but on the
whole key
• The second normal form depends mainly on the entity key. An entity is
automatically in the second normal form if:
• its primary key consists of only one attribute, or
• its primary key consists of all attributes of the entity.

85

PB conceptual design

Conversion to 2NF - example

Student (enrolment_nr, surname, first_name, post, place)
Course(enrolment_nr, course code, course_title, grade)

An entity is broken because part of the composite

the primary key specifies the title of the course

Student (enrolment_nr, surname, first_name, post, place)

Course(course code, course_title)
Grade (enrolment_nr, course code, grade)

86

41
 25/03/2025

Conversion to 2NF - example Subject

Enrolment_n Course_co Course_title rating
Student
r de
Enrolment_nr surname First_na post place E12234564 20020 IS 10
me E12234564 20021 TPO 8
E12234564 Bratina Simon 4000 Kranj
E12234564 20033 IPI 8
E12234562 20060 E1 9
E12234562 Bizjak Tadeja 2250 Ptuj
2NF E12234562 20033 IPI 6
1NF

Evaluation
Subject
Enrolment_nr Course_code rating
Course_code Course_title
E12234564 20020 10
20020 IS
E12234564 20021 8
20021 TPO
E12234564 20033 8
20033 IPI
E12234562 20060 9
20060 E1
E12234562 20033 6
2NF 2NF

3NF - third normal form

• An entity is in its third normal form if:
• is in the second normal form, and
• does not contain transitive functional dependencies  there are
no functional dependencies between attributes that are not part of
the primary key.
• An entity is automatically in the third normal form if:
• its key consists of all attributes of the entity.

88

42
 25/03/2025

Conversion to 3NF - example

Student (registration_nr, surname, first_name, post, place)
Course(course code, course_title)
Grade (enrolment_nr, course code, grade)

We break an entity because attributes,

which are not part of the primary key, determine the dependency

Student (enrolment_nr, surname, first_name, post)

Post office (post, place)
Course(course code, course_title)
Grade (enrolment_nr, course code, grade)

PB conceptual design
Evaluation
Conversion to 3NF - example Enrolment_st Course_code rating
E12234564 20020 10
Student
E12234564 20021 8
Enrolment_nr surname First_na post place E12234564 20033 8
me
E12234562 20060 9
E12234564 Bratina Simon 4000 Kranj
E12234562 20033 6
E12234562 Bizjak Tadeja 2250 Ptuj Subject 3NF
2NF
Course_code Course_title
20020 IS
20021 TPO
20033 IPI
20060 E1
Student 3NF
Post
Enrolment_nr surname Fist_nam Post Post place
e 4000 Kranj
E12234564 Bratina Simon 4000
2250 Ptuj
E12234562 Bizjak Tadeja 2250
3NF 3NF 90

43
 25/03/2025

PB conceptual design

Use of non-normalised entities

• Sometimes we deliberately use entities (relations) that do not correspond to
the highest normal forms.
• The first and other normal forms are never violated.
• Higher normal forms are sometimes forgone at the expense of achieving better
efficiency.
• Example: result (athlete, competition, first run time, second run time, total
time)
• The entity is not in its third normal form.
• The total time is a derived attribute of  not dependent on the key, but is the sum of the
times of the two runs.
• The total time is calculated at the time of entry into the database, improving the efficiency
of further data processing.

92

44
 25/03/2025

3. Normalisation - Example
• Normalise the relation R to the third normal form, taking into account the
following functional dependencies:
KEY ATTRIBUTES ENTITLE
RECURRING ATTRIBUTES
• R(ABCDE {FGHIJ})
• F  {AB  CDEFGHIJ, B CD, C  D, FG  HIJ, I  J, G  H}
3NF
2NF
R111(CD) 3NO
R11(BCD) R112(BC) 3NO
R12(ABE) 3NO
1NF
2NF 3NF
R1(ABCDE) 2NF
R211(GH) 3NO R2121(IJ) 3NO
R2(ABFGHIJ) R21(FGHIJ)
R212(FGIJ) R2122(FGI) 3NO
R22(ABFG) 3NO
3NO 93

45