Illustrate functional dependency.

Functional dependency is a relationship between two attributes or columns in a database table, where
the value of one attribute uniquely determines the value of another attribute.

For example, consider the following table of student grades:

Student ID Student Name Course Grade

001 Alice Math A

002 Bob English B

003 Charlie Math B

004 Dave Science A

In this table, we can see that the Student ID uniquely identifies each row, and so does the combination of
Student ID and Course. Therefore, we can say that there is a functional dependency between the
Student ID attribute and the other attributes in the table.

We can represent this functional dependency using an arrow notation:

Student ID -> Student Name, Course, Grade

This notation means that the value of Student ID uniquely determines the values of Student Name,
Course, and Grade. In other words, if we know the value of the Student ID, we can determine the values
of the other attributes for that particular row.

Functional dependencies are important in database design because they help to ensure data integrity
and reduce redundancy. By identifying functional dependencies, we can minimize the risk of data
inconsistencies and anomalies.

Discuss normalization
Normalization is the process of organizing data in a relational database so that it is structured efficiently
and free from redundancy and other anomalies. The goal of normalization is to reduce data redundancy,
minimize data anomalies, and improve data integrity. Normalization is a key aspect of database design,
and it helps ensure that databases are scalable, maintainable, and optimized for querying and retrieval.

There are several levels of normalization, each with its own set of rules and guidelines. The most
commonly used normalization levels are:

First Normal Form (1NF): In this level, the table must have a primary key and all attributes must be
atomic, meaning that they cannot be divided into smaller pieces. Each row in the table must be unique
and must have a primary key that can be used to identify it.

Second Normal Form (2NF): In this level, the table must already be in 1NF, and all non-key attributes
must depend on the entire primary key. In other words, each non-key attribute must be dependent on
the entire primary key, not just a part of it.

Third Normal Form (3NF): In this level, the table must already be in 2NF, and all non-key attributes must
depend only on the primary key and not on any other non-key attributes. This level helps to eliminate
transitive dependencies, where an attribute is determined by another non-key attribute instead of the
primary key.

Fourth Normal Form (4NF): In this level, the table must already be in 3NF, and it must not have any multi-
valued dependencies. Multi-valued dependencies occur when a table has one or more attributes that
can have multiple values for each primary key value.

Each level of normalization builds on the previous one, with each level providing more rules and
guidelines to ensure data integrity and reduce redundancy. By normalizing a database, we can ensure
that it is well-organized, optimized for querying and retrieval, and easier to maintain and scale.

Elaborate and experiment types of normalization.

First Normal Form (1NF): In 1NF, all the attributes in a table must be atomic, i.e., indivisible. Each column
should have a single value, and no repeating groups or arrays should be allowed. Every table should have
a primary key that uniquely identifies each row. For example, consider the following table:

Student ID Student Name Courses

001 Alice Math, Science

002 Bob English, History

This table is not in 1NF because the Courses column contains multiple values. To bring it into 1NF, we
need to split it into a separate table, as shown below:

Student ID Student Name

001 Alice

002 Bob

Student ID Course

001 Math

001 Science

002 English

002 History

Second Normal Form (2NF): In 2NF, the table should be in 1NF, and all non-key attributes should be
dependent on the entire primary key. In other words, there should be no partial dependencies. For
example, consider the following table:

Order ID Product ID Product Name Quantity

001 001 Pen 2

002 001 Pen 4

002 003 Notebook 1

This table is not in 2NF because the Product Name column depends only on the Product ID, not on the
entire primary key (Order ID and Product ID). To bring it into 2NF, we need to split it into two tables, as
shown below:

Order ID Product ID Quantity

001 001 2

001 002 3

002 001 4

002 003 1

Product ID Product Name

001 Pen

002 Pencil

003 Notebook

Third Normal Form (3NF): In 3NF, the table should be in 2NF, and there should be no transitive
dependencies. In other words, no non-key attribute should depend on another non-key attribute. For
example, consider the following table:

Book ID Book Name Author Author Country

001 The Catcher in the Rye J.D. Salinger USA

002 To Kill a Mockingbird Harper Lee USA

003 Pride and Prejudice Jane Austen UK

This table is not in 3NF because the Author Country column depends on the Author column, not on the
primary key (Book ID). To bring it into 3NF, we need to split it into two tables, as shown below:
Book ID Book Name Author ID

001 The Catcher in the Rye 001

002 To Kill a Mockingbird 002