Relational Database Design

Ram Datta Bhatta

 Functional Dependency
✓ Functional Dependency (FD) is a constraint that determines the relation of one
attribute to another attribute in the Database Management System(DBMS).
✓ It expresses a relationship between attributes, where the value of one attribute (or
a set of attributes) uniquely determines the value of another attribute (or set of
attributes).
✓ A functional dependency is denoted by 𝑋→𝑌 where 𝑋 and 𝑌 are sets of attributes
in a relation. The FD 𝑋→𝑌 means that if two tuples (rows) in the relation have
the same value for 𝑋, then they must also have the same value for 𝑌. In other
words, 𝑋 functionally determines 𝑌.

EmpID EmpName Salary City

1 Ram 15000 Pok
2 Shyam 20000 Ktm
3 Gopal 22000 Dharan

Here, EmpID→EmpName
Types of Functional Dependency
 Closure properties of functional
dependencies
▪ The Closure Properties of FDs refers to the set of all
functional dependencies that can be logically
inferred from a given set of FDs using a set of
inference rules.
▪ The closure properties help determine all possible
FDs that can be derived from a given set of FDs.
▪ These properties, or rules, ensure that any FD that
logically follows from the original set can be
identified.
Closure Properties
Closure Properties
 Closure of Attributes

▪ The closure of a set of attributes in a relational

database schema is the set of all attributes that can
be functionally determined by that set of attributes
using a given set of functional dependencies.
▪ The closure of a set of attributes, denoted as X + ,
is the set of all attributes that can be functionally
determined by 𝑋 using a given set of functional
dependencies (FDs).
▪ In other words, it represents all the attributes that
are dependent on X directly or indirectly.
Question: Find the Closure of Attributes
Closure of Attributes
 Normalization
▪ Normalization is a process in database design that
decomposes a table into multiple tables to minimize
redundancy and eliminate anomalies such as insertion,
deletion, and update anomalies.
▪ The main objective is to:
✓ Eliminate Duplicate Data: Reduce storage space and
improve data consistency by minimizing data
redundancy.
✓ Avoid Anomalies: Ensure that changes to data
(insertions, deletions, and updates) do not lead to
inconsistencies
 Anomalies
▪ 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.
▪ Updatate Anomaly: The update anomaly is when an
update of a single data value requires multiple rows of
data to be updated.
Let’s consider database design

What are the Problems in this design?

Solution: Normalization
 Advantages
▪ Eliminates Redundancy: By breaking down tables into smaller, related tables,
normalization reduces duplicate data, saving storage space.
▪ Prevents Anomalies: Ensures that updates to data are consistent and do not lead to
anomalies such as partial updates or conflicting data entries.
▪ Enhances Query Performance: Optimizes query performance by reducing the
amount of data that needs to be scanned and processed, especially for large
databases.
▪ Supports Data Consistency: Ensures that the same data is not stored in multiple
places, reducing the risk of data discrepancies and promoting consistency.
▪ Reduces Storage Costs: By minimizing redundant data, normalization can lead to
reduced storage costs, especially in large databases.
▪ Enhances Security: Enables more precise access control by organizing data into
distinct tables, making it easier to restrict access to sensitive information.
 Types of Normal Forms

First Normal Form (1NF) :

A relation is in 1NF if it contains an atomic value.
Second Normal Form (2NF):
A relation will be in 2NF if it is in 1NF and all non-key attributes are fully
functional dependent on the primary key.
Third Normal Form (3NF):
A relation will be in 3NF if it is in 2NF and no transition dependency exists.
Boyce Code Normal Form (BCNF):
A stronger definition of 3NF is known as Boyce Codd's normal form.
 ✓ A table is in 1NF if it contains only atomic
values (indivisible) and there are no repeating
First Normal groups ( values of single type)
✓ It states that an attribute of a table cannot hold
Form ( 1 NF ) multiple values. It must hold only single-valued
attribute.

rollno name subjects

1 Ram Math, Physics
2 Sita Chemistry, Math
3 Gita Physics, Math This table is not in 1NF

4 Shyam Math, Biology

The subjects column contains multiple values, which violates the rule of atomicity in 1NF.
Each cell must hold a single value, not a list or set of values
 Creating a separate row for each subject a
Converting into student is enrolled in. Now, the
combination of rollno and subject is the
1NF primary key of the table. Here, the design
is not perfect, still remains redundancy.
 Example: 1 NF
roll_no name subject
101 Akon OS, CN
103 Ckon Java
102 Bkon C, C++

roll_no name subject

101 Akon OS
101 Akon CN
103 Ckon Java
102 Bkon C
102 Bkon C++
 Atomic Domain
▪ An atomic domain means that each value in a column of a table
is simple and indivisible (can’t be broken down into smaller
parts).
▪ In following table, the PhoneNumbers column is not atomic
because it can contain multiple phone numbers separated by a
comma
▪ To make the domains atomic, we should ensure that each
column has only one value per row.
StudentID Name PhoneNumbers

11 Alice 0134455555, 014555555

2 Bob 34444555
 A relation is in Second Normal Form (2NF) if it is
in First Normal Form (1NF) and all non-key
Second Normal attributes are fully functionally dependent on the
primary key. If any attribute is only partially
Form (2NF) dependent on the primary key (i.e., it depends on a
part of a composite primary key rather than the
whole key), then the table is not in 2NF

This table is not in 2NF. Here, roomNo is dependent only in subject i.e. not whole composite key
 To convert the table to 2NF, we need to remove
Converting into partial dependencies. We can achieve this by
creating two tables: one for the student_subject
2NF relationship and another for the subject_room
relationship.
Alternative Design for 2 NF
 Third
Normal
Form (3NF)
▪ A relation is in Third Normal
Form (3NF) if it is in Second
Normal Form (2NF) and it has
no transitive dependencies.
▪ In other words, the non-key
attributes must not depend on
other non-key attributes i.e.,
Every non-key attribute must be This relation is not in 3 NF as
directly dependent on the primary roomNo→Building
key.
 Converting into 3NF

The building attribute is dependent on roomNo, and roomNo is dependent on subject.

To eliminate this transitive dependency, we need to create a new table that captures the
relationship between roomNo and building
 Boyce-Codd Normal Form (BCNF)

▪ A relation is in Boyce-Codd Normal Form

(BCNF) if it is in Third Normal Form (3NF) and,
for every functional dependency X→Y, X is a
candidate key.
▪ In other words, for every functional dependency,
the left-hand side (LHS) must be a candidate key.
▪ BCNF is the advance version of 3NF. It is stricter
than 3NF.
 The functional dependency Realease_Year_Month
→ Release_Year does not satisfy BCNF because
Not in BCNF Realease_Year_Month is not a superkey

The candidate keys: {MovieName}, {Release_Year, Popularity_Ranking}, {Realease_Year_Month,

Popularity_Ranking}
The functional dependency is: Realease_Year_Month → Release_Year
It is in BCNF
 References
https://www.youtube.com/watch?v=VWnKUKH
4tLg
https://www.javatpoint.com/dbms-boyce-codd-
normal-form
Thank you.