Unit 3

Relational Database Design

Lecture 1
By
Dr Shruti Bharadwaj
 Normalisation
A large database defined as a single relation may
result in data duplication. This repetition of data may
result in:
• Making relations very large.
• It isn't easy to maintain and update data as it would involve searching
many records in relation.
• Wastage and poor utilization of disk space and resources.
• The likelihood of errors and inconsistencies increases.

So to handle these problems, we should analyze and decompose the

relations with redundant data into smaller, simpler, and well-structured
relations that are satisfy desirable properties. Normalization is a process of
decomposing the relations into relations with fewer attributes.

Database System Concepts 4.2 ©Silberschatz, Korth and Sudarshan

 What is Normalisation?
•Normalization is the process of organizing the data in the
database.
•Normalization is used to minimize the redundancy from a relation
or set of relations. It is also used to eliminate undesirable
characteristics like Insertion, Update, and Deletion Anomalies.
•Normalization divides the larger table into smaller and links them
using relationships.
•The normal form is used to reduce redundancy from the database
table.

Database System Concepts 4.3 ©Silberschatz, Korth and Sudarshan

 What do we need Normalisation?

•The main reason for normalizing the relations is removing

these anomalies. Failure to eliminate anomalies leads to
data redundancy and can cause data integrity and other
problems as the database grows. Normalization consists of
a series of guidelines that helps to guide you in creating a
good database structure

Database System Concepts 4.4 ©Silberschatz, Korth and Sudarshan

 Anomalies in DBMS

Anomalies are problems that can occur in poorly planned,

unnormalized databases where all the data is stored in one table.
There are three types of anomalies that occur when the database
is not normalized. These are – insertion, update and deletion
anomaly. Let’s take an example to understand this. Consider a
relation Emp-Dept.
 Data modification anomalies can be
categorized into three types:

•Insertion Anomaly: Insertion Anomaly refers to when one cannot

insert a new tuple into a relationship due to lack of data.
•Deletion Anomaly: The delete anomaly refers to the situation
where the deletion of data results in the unintended loss of some
other important data.
•Updatation Anomaly: The update anomaly is when an update of a
single data value requires multiple rows of data to be updated

Database System Concepts 4.6 ©Silberschatz, Korth and Sudarshan

 •Insertion Anomaly: Insertion Anomaly refers to when one cannot
insert a new tuple into a relationship due to lack of data.
•Deletion Anomaly: The delete anomaly refers to the situation
where the deletion of data results in the unintended loss of some
other important data.
•Updatation Anomaly: The update anomaly is when an update of a
single data value requires multiple rows of data to be updated

Database System Concepts 4.7 ©Silberschatz, Korth and Sudarshan

 Insertion anomaly:

Let us assume that a new department has been started by

the organization but initially there is no employee
appointed for that department, then the tuple for this
department cannot be inserted into this table as the E# will
have NULL, which is not allowed as E# is primary key. This
kind of a problem in the relation where some tuple cannot
be inserted is known as insertion anomaly

Database System Concepts 4.8 ©Silberschatz, Korth and Sudarshan

 •Insertion Anomaly: Insertion Anomaly refers to when one cannot
insert a new tuple into a relationship due to lack of data.
•Deletion Anomaly: The delete anomaly refers to the situation
where the deletion of data results in the unintended loss of some
other important data.
•Updatation Anomaly: The update anomaly is when an update of a
single data value requires multiple rows of data to be updated

Database System Concepts 4.9 ©Silberschatz, Korth and Sudarshan

 Deletion anomaly:

Now consider there is only one employee in some

department and that employee leaves the organization,
then the tuple of that employee has to be deleted from the
table, but in addition to that the information about the
department also will get deleted. This kind of a problem in
the relation where deletion of some tuples can lead to loss
of some other data not intended to be removed is known as
deletion anomaly.
Database System Concepts 4.10 ©Silberschatz, Korth and Sudarshan
 •Insertion Anomaly: Insertion Anomaly refers to when one cannot
insert a new tuple into a relationship due to lack of data.
•Deletion Anomaly: The delete anomaly refers to the situation
where the deletion of data results in the unintended loss of some
other important data.
•Updatation Anomaly: The update anomaly is when an update of a
single data value requires multiple rows of data to be updated

Database System Concepts 4.11 ©Silberschatz, Korth and Sudarshan

 Modification/update anomaly:

Suppose the manager of a department has changed, this

requires that the Dmgr# in all the tuples corresponding to
that department must be changed to reflect the new status.
If we fail to update all the tuples of the given department,
then two different records of employee working in the
same department might show different Dmgr# leading to
inconsistency in the database. This is known as
modification/update anomaly.
Database System Concepts 4.12 ©Silberschatz, Korth and Sudarshan
 Functional Dependency

In a relational database management, functional

dependency is a concept that specifies the
relationship between two sets of attributes where
one attribute determines the value of another
attribute. It is denoted as X → Y, where the attribute
set on the left side of the arrow, X is
called Determinant, and Y is called the Dependent.

Functional dependencies are used to mathematically

express relations among database entities.

Database System Concepts 4.13 ©Silberschatz, Korth and Sudarshan

 Functional Dependency
R

t1

t2

t3

t4

t5

Database System Concepts 4.14 ©Silberschatz, Korth and Sudarshan

 Functional Dependency

Consider a relation schema R, and let A ⊆ R and

B ⊆ R.
The functional dependency α → β holds on
relation schema R if, in any legal relation r(R),
for all pairs of tuples t1 and t2 in r such that
t1[α] = t2[α], then t1[β] = t2[β] must also satisfy
with in r(R).

Database System Concepts 4.15 ©Silberschatz, Korth and Sudarshan

 Armstrong’s axioms/properties of
functional dependencies:
1.Reflexivity: If Y is a subset of X, then X→Y holds by reflexivity rule
Example, {roll_no, name} → name is valid.
2.Augmentation: If X → Y is a valid dependency, then XZ → YZ is also
valid by the augmentation rule.
Example, {roll_no, name} → dept_building is valid, hence {roll_no,
name, dept_name} → {dept_building, dept_name} is also valid.
3.Transitivity: If X → Y and Y → Z are both valid dependencies, then
X→Z is also valid by the Transitivity rule.
Example, roll_no → dept_name & dept_name → dept_building, then
roll_no → dept_building is also valid.

Database System Concepts 4.16 ©Silberschatz, Korth and Sudarshan

 Types of Functional Dependency
Types of Functional Dependencies in
DBMS
1.Trivial functional dependency
2.Non-Trivial functional dependency
3.Multivalued functional dependency
4.Transitive functional dependency

Database System Concepts 4.17 ©Silberschatz, Korth and Sudarshan

 1. Trivial functional dependency
In Trivial Functional Dependency, a dependent is always a subset of the
determinant. i.e. If X → Y and Y is the subset of X, then it is called trivial
functional dependency
Example:

roll_no name age

42 abc 17

43 pqr 18

44 xyz 18

Here, {roll_no, name} → name is a trivial functional dependency, since the

dependent name is a subset of determinant set {roll_no, name}. Similarly, roll_no
→ roll_no is also an example of trivial functional dependency.

Database System Concepts 4.18 ©Silberschatz, Korth and Sudarshan

 2. Non-Trivial functional dependency

In Non-trivial functional dependency, the dependent is strictly not a subset of the

determinant. i.e. If X → Y and Y is not a subset of X, then it is called Non-trivial
functional dependency.

Example:
roll_no name age

42 abc 17

43 pqr 18

44 xyz 18

Here, roll_no → name is a non-trivial functional dependency, since the

dependent name is not a subset of determinant roll_no. Similarly, {roll_no,
name} → age is also a non-trivial functional dependency, since age is not a
subset of {roll_no, name}

Database System Concepts 4.19 ©Silberschatz, Korth and Sudarshan

 3. Multivalued functional dependency

In Multivalued functional dependency, entities of the dependent set are not

dependent on each other. i.e. If a → {b, c} and there exists no functional
dependency between b and c, then it is called a multivalued functional
dependency.
roll_no name age
Example:
42 abc 17

43 pqr 18

44 xyz 18

45 abc 19

Here, roll_no → {name, age} is a multivalued functional dependency, since the

dependents name & age are not dependent on each other(i.e. name → age or age
→ name doesn’t exist !

Database System Concepts 4.20 ©Silberschatz, Korth and Sudarshan

 4. Transitive functional dependency

In transitive functional dependency, dependent is indirectly dependent on

determinant. i.e. If a → b & b → c, then according to axiom of transitivity, a → c.
This is a transitive functional dependency.

Example: building_n
enrol_no name dept
o

42 abc CO 4

43 pqr EC 2

44 xyz IT 1

45 abc EC 2

Here, enrol_no → dept and dept → building_no. Hence, according to the axiom
of transitivity, enrol_no → building_no is a valid functional dependency. This is an
indirect functional dependency, hence called Transitive functional dependency.

Database System Concepts 4.21 ©Silberschatz, Korth and Sudarshan