Experiment No: 4
Aim of the experiment: To normalize given datasets to eliminate redundancy and anomalies and to identify keys and
functional dependencies in sample schemas of student database
Normalization
Normalization in DBMS is a systematic process of arranging data in a relational
database to minimize redundancy and improve data integrity. It involves decomposing
large tables into smaller, related tables and defining relationships among them using keys.
The primary goal of normalization in DBMS is to ensure that each piece of data is stored
only once, thereby avoiding inconsistencies and duplication.
By following normalization rules, we can:

Eliminate redundant data

Ensure logical data storage

Enhance data integrity

Simplify database maintenance
Normalization is applied using a series of normal forms.
Types of normal forms in DBMS
In DBMS, there are several levels of normalization, commonly referred to as normal
forms. Each form addresses specific types of anomalies and redundancies. Here, we’ll
touch on 1NF, 2NF, 3NF, BCNF to understand how they differ in their functionalities.
First Normal Form (1NF)
First Normal Form (1NF) focuses on ensuring that the values in each column of a table
are atomic, meaning they cannot be further divided. A table is in 1NF if:

All attributes (columns) contain only single, indivisible values

Each record is unique and there are no repeating groups
Scenario:
Consider a table storing student details:
StudentID
Name
Phone Numbers
101
Ram
9876543210, 9123456780
This violates 1NF because the “Phone Numbers” column holds multiple values. To
convert this into 1NF, we can split the phone numbers into two rows:
StudentID
Name
Phone Number
101
Ram
9876543210
101
Ram
9123456780
Why 1NF matters:
Applying 1NF removes nested or grouped data and lays the groundwork for further
normalization. It’s the first step in structuring data for consistency and clarity.
Second Normal Form (2NF)
Second Normal Form (2NF) builds upon 1NF and addresses partial dependencies. A table
is in 2NF if:

It is already in 1NF

Every non-prime attribute (an attribute that’s not part of a candidate key) is fully
functionally dependent on the entire primary key
Scenario:
Suppose we have a table for student-course enrollment:
StudentID
CourseID
StudentName
CourseName
101
CS101
Ram
DBMS
102
CS102
Sam
OS
Here, the composite primary key is (StudentID, CourseID). But “StudentName” depends
only on “StudentID” and “CourseName” depends only on “CourseID”, which indicates
partial dependency.
To convert this into 2NF, we can split the table into three parts:

Student table
 Course table
 Enrollment table
The student table will look like:
StudentID
StudentName
101
Ram
102
Sam
The course table will look like:
CourseID
CourseName
CS101
DBMS
CS102
OS
The enrollment table will look like:
StudentID
CourseID
101
CS101
102
CS102
Why 2NF matters:
2NF ensures that data is placed in the appropriate tables and that every column is fully
dependent on the whole key, not just part of it. This eliminates data duplication and
makes updates more efficient.
Third Normal Form (3NF)
Third Normal Form (3NF) eliminates transitive dependencies. A table is in 3NF if:

It is already in 2NF
 No non-prime attribute is dependent transitively on the primary key
In simpler terms, non-key attributes should not depend on other non-key attributes.
Scenario:
Consider a table storing employee details:
EmpID
EmpName
DeptID
DeptName
1
Shiv
D01
HR
2
Mohan
D02
IT
Here, “DeptName” depends on “DeptID”, which in turn depends on “EmpID”. This is a
transitive dependency.
To convert this into 3NF, we can split the table into two parts:

Employee table
 Department table
The employee table will look like:
EmpID
EmpName
DeptID
1
Shiv
D01
2
Mohan
D02
The department table will look like:
DeptID
DeptName
D01
HR
D02
IT
Why 3NF matters:
3NF promotes data integrity and reduces redundancy by ensuring that each non-key
attribute is directly dependent on the primary key.
Boyce-Codd Normal Form (BCNF)
BCNF (Boyce-Codd Normal Form) is a higher version of 3NF. A table is in BCNF if:

It is in 3NF
 Every functional dependency has a super key on the left-hand side
BCNF handles certain anomalies that 3NF cannot. If a table has overlapping candidate
keys, it might violate BCNF even while being in 3NF.
Scenario:
Suppose we have a table for storing course details:
Professor
Course
Time
Hari
DBMS
10AM
Hari
DBMS
2PM
Maruti
OS
11AM
Here, a professor can teach multiple courses, and each course is taught by one professor.
However, some professors may teach the same course at different times.
The functional dependencies in this scenario include:

Professor → Course (Each professor teaches only one course)
Course → Professor (Each course is taught by one professor)
But in this table, neither “Professor” nor “Course” is a super key, so it violates BCNF.

To convert this into BCNF, we can split the table into two parts:

Professor-course table
 Course-schedule table
The professor-course table will look like:
Professor
Course
Hari
DBMS
Maruti
OS
The course-schedule table will look like:
Course
Time
DBMS
10AM
DBMS
2PM
OS
11AM
Why BCNF matters:
BCNF ensures stricter normalization by resolving complex dependencies, especially in
tables with multiple candidate keys.
Types of Keys





Super Key: Set of attributes uniquely identifying tuples.
Candidate Key: Minimal super key.
Primary Key: Selected candidate key.
Foreign Key: Attribute referencing another table.
Composite Key: Key with multiple attributes.
DBMS student database schema, keys and functional dependencies (FDs) are the building
blocks used to organize data and ensure integrity.
Sample Schema Tables of student database
A standard university or school database generally includes the following core relations:

STUDENT: (STUD_ID, Name, DateOfBirth, Address, Phone, Dept_ID)
 COURSE: (Course_ID, Course_Name, Credits, Dept_ID)
 ENROLLMENT: (STUD_ID, Course_ID, Semester, Grade)
 DEPARTMENT: (Dept_ID, Dept_Name, Building)
Identifying Keys
Keys are attributes that uniquely identify records or link tables together.

Primary Keys (PK): Attributes that uniquely identify each row.
o

STUD_ID for STUDENT.
o Course_ID for COURSE.
o {STUD_ID, Course_ID} for ENROLLMENT (Composite Primary Key).
Foreign Keys (FK): Attributes that refer to the primary key of another table to
establish relationships.
o
Dept_ID in STUDENT refers to Dept_ID in DEPARTMENT.
STUD_ID and Course_ID in ENROLLMENT refer to their respective
primary keys in STUDENT and COURSE.
Candidate Keys: Any set of attributes that could serve as a primary key, such
as Phone or Email in a STUDENT table if they are guaranteed to be unique and nonnull.
o

Functional Dependencies (FDs)
Functional dependencies describe how one attribute determines another (X→Y means X
determine Y)
•

Full Functional Dependency: An attribute depends on the entire candidate key.
o
STUD_ID → {Name, Address, Phone}: Knowing the ID gives you all student
details.
o
{STUD_ID, Course_ID} → Grade: A grade is only determined by combining
a specific student with a specific course.
Partial Functional Dependency: A non-key attribute depends on only part of a
composite key.
o

In a table like (STUD_ID, Course_ID, Course_Name), if Course_ID →
Course_Name, it is a partial dependency because Course_Name doesn't
need STUD_ID to be identified.
Transitive Dependency: An attribute depends on another attribute that is not a primary
key.
o
STUD_ID → Dept_ID and Dept_ID → Building: This implies a transitive
dependency where STUD_ID indirectly determines
the Building through Dept_ID.