Cathleen L.

Abila BSIT-2

Database normalization is the process of organizing a relational database in accordance

with a series of so-called normal forms in order to reduce data redundancy and improve data
integrity. It was first proposed by Edgar F. Codd. 4NF to 6NF applies to multivalued
dependencies and complex table scenarios.

Normalization entails organizing the columns (attributes) and tables (relations) of a

database to ensure that their dependencies are properly enforced by database integrity
constraints. It is accomplished by applying some formal rules either by a process of synthesis
(creating a new database design) or decomposition (improving an existing database design).

Different Normal forms

1. Unnormalized form (UNF): also known as an unnormalized relation or non-first

normal form (N1NF or NF2), is a database data model (organization of data in a
database) which does not meet any of the conditions of database normalization
defined by the relational model.

Example:
Suppose you have a list of customer orders, and the data is just stored as a flat list
without any organization:

OrderID: 101 OrderID: 102 OrderID: 103

CustomerName: CustomerName: CustomerName:
John Smith Jane Doe John Smith
Product: Product: Product: Tablet
Laptop Smartphone Quantity: 3
Quantity: 2 Quantity: 1 OrderDate:
OrderDate: OrderDate: 2023-10-07
2023-10-05 2023-10-06
 In this UNF example, the data is not structured in a relational format. Each piece
of information related to an order is listed together, but there's no clear
organization or separation into tables, and there's redundancy in customer names
and dates.

The goal in database design is to transform this UNF data into a set of well-
structured tables with appropriate relationships, which would typically involve
breaking it down into tables like "Customers," "Products," and "Orders," with
keys and relationships defined between them.

2. First Normal Form (1NF): This is the most basic level of normalization. In 1NF,
each table cell should contain only a single value, and each column should have a
unique name. The first normal form helps to eliminate duplicate data and simplify
queries.

Example:

This table is not in first normal form because the Color column can contain
multiple values. For example, the first row includes values "red" and "green."

To bring this table to first normal form, we split the table into two tables and now
we have the resulting tables. Now first normal form is satisfied, as the columns on
each table all hold just one value.
3. Second Normal Form (2NF): 2NF eliminates redundant data by requiring that
each non-key attribute be dependent on the primary key. This means that each
column should be directly related to the primary key, and not to other columns.

Example:

This table has a composite primary key Customer ID, Store ID. The non-key
attribute is Purchase Location. In this case, Purchase Location only depends on
Store ID, which is only part of the primary key. Therefore, this table does not
satisfy second normal form. To bring this table to second normal form, we break
the table into two tables. What we have done is to remove the partial functional
dependency that we initially had. Now, in the table TABLE_STORE, the column
[Purchase Location] is fully dependent on the primary key of that table, which is
Store ID.

4. Third Normal Form (3NF): 3NF builds on 2NF by requiring that all non-key
attributes are independent of each other. This means that each column should be
directly related to the primary key, and not to any other columns in the same table.

Example:
 In the table, Book ID determines Genre ID, and Genre ID determines Genre Type.
Therefore, Book ID determines Genre Type via Genre ID and we have transitive
functional dependency, and this structure does not satisfy third normal form. To
bring this table to third normal form, we split the table into two. Now all non-key
attributes are fully functional dependent only on the primary key. In
TABLE_BOOK, both Genre ID and Price are only dependent on Book ID. In
TABLE_GENRE, Genre Type is only dependent on Genre ID.

5. Boyce-Codd Normal Form (BCNF): BCNF is a stricter form of 3NF that

ensures that each determinant in a table is a candidate key. In other words, BCNF
ensures that each non-key attribute is dependent only on the candidate key.

Example:
 The table present above is not in BCNF, because as we can see that neither
Stu_ID nor Stu_Course is a Super Key. As the rules mentioned above clearly tell
that for a table to be in BCNF, it must follow the property that for functional
dependency X−>Y, X must be in Super Key and here this property fails, that’s
why this table is not in BCNF. For satisfying this table in BCNF, we have to
decompose it into further tables. Here is the full procedure through which we
transform this table into BCNF. Let us first divide this main table into two tables
Stu_Branch and Stu_Course Table. After decomposing into further tables, now it
is in BCNF, as it is passing the condition of Super Key, that in functional
dependency X−>Y, X is a Super Key.

6. Fourth Normal Form (4NF): 4NF is a further refinement of BCNF that ensures
that a table does not contain any multi-valued dependencies.

Example:

STUDENT

The given STUDENT table is in 3NF, but the COURSE and HOBBY are two
independent entity. Hence, there is no relationship between COURSE and
HOBBY.

In the STUDENT relation, a student with STU_ID, 21 contains two courses,

Computer and Math and two hobbies, Dancing and Singing. So there is a Multi-
valued dependency on STU_ID, which leads to unnecessary repetition of data.
 So to make the above table into 4NF, we can decompose it into two tables.

7. Elementary key normal form (EKNF): is a subtle enhancement on third normal

form, thus EKNF tables are in 3NF by definition. This happens when there is
more than one unique compound key and they overlap. Such cases can cause
redundant information in the overlapping column(s).

Example:
Suppose we have a relation (table) called "Students" with the following attributes:

StudentID (Candidate Key) CourseID (Candidate Key)

StudentName CourseName
Instructor

In this example, "StudentID" and "CourseID" are candidate keys because they
uniquely identify each student and each course. However, the other attributes like
 "StudentName," "CourseName," and "Instructor" are not part of any candidate
key.

To bring this relation into Elementary Key Normal Form (EKNF), we would need
to split it into two separate relations:

Relation 1: "Students" Relation 2: "Courses"

StudentID (Candidate Key) CourseID (Candidate Key)
StudentName CourseName
Instructor

By doing this, we have ensured that each attribute in both relations is either a
candidate key or part of a candidate key, and we have eliminated any redundancy
in the original table, making it conform to EKNF.

8. Fifth Normal Form (5NF): 5NF is the highest level of normalization and
involves decomposing a table into smaller tables to remove data redundancy and
improve data integrity.

Example:
 In the above table, John takes both Computer and Math class for Semester 1 but
he doesn't take Math class for Semester 2. In this case, combination of all these
fields required to identify a valid data.

Suppose we add a new Semester as Semester 3 but do not know about the subject
and who will be taking that subject so we leave Lecturer and Subject as NULL.
But all three columns together acts as a primary key, so we can't leave other two
columns blank.

So to make the above table into 5NF, we can decompose it into three relations P1,
P2 & P3

9. Domain-key normal form: is a normal form used in database normalization

which requires that the database contains no constraints other than domain
constraints and key constraints.

Example:

(Assume that the domain for Wealthy Person consists of the names of all wealthy
people in a pre-defined sample of wealthy people; the domain for Wealthy Person
Type consists of the values 'Millionaire' and 'Billionaire'; and the domain for Net
Worth in Dollars consists of all integers greater than or equal to 1,000,000.)
There is a constraint linking Wealthy Person Type to Net Worth in Dollars, even
though we cannot deduce one from the other. The constraint dictates that a
Millionaire will have a net worth of 1,000,000 to 999,999,999 inclusive, whilst a
Billionaire will have a net worth of 1,000,000,000 or higher. This constraint is
neither a domain constraint nor a key constraint; therefore we cannot rely on
domain constraints and key constraints to guarantee that an inconsistent Wealthy
Person Type / Net Worth in Dollars combination does not make its way into the
database.

The DKNF violation could be eliminated by removing the Wealthy Person Type
column. The wealthy person's status as a millionaire or billionaire is determined
by their Net Worth in Dollars, as defined in the Wealthiness Status table, so no
useful information is lost.