se,"config_flag_value":""},{"config_name":"focusMode","isVisible":true,"config_flag_value":""},{"config_name":"deleteAccount","isVisible":true,"config_flag_value":""},{"config_name":"new_checkout","isVisible":false,"config_flag_value":""}],"children":"$2:props:children:1:props:children:0:props:fallback:props:children"}] 1b:T10d2,

Normalization is the process of organizing a database to reduce redundancy and dependency. This ensures that each piece of data is stored in one place. We achieve this by splitting data into smaller tables, which follow specific rules known as "normal forms" (like 1NF, 2NF, and 3NF). These rules help ensure that each table has a unique identifier (primary key) and that other information (non-key attributes) depends on the primary key.

Why normalize?

Reduces data duplication: Storing each piece of data only once minimizes inconsistencies and makes data easier to update and manage.
Improves data consistency: Since each data point exists in only one place, updating it in one spot keeps all your information consistent.
Minimizes data anomalies: Normalization reduces reliance on other data, making the database easier to understand and use while avoiding issues like insertion, update, and deletion anomalies.
Enhances scalability and performance: By managing less redundant data, the database becomes faster and easier to maintain.

First Normal Form (1NF)

A table is in 1NF if:

All columns contain atomic (indivisible) values.
Each column holds values of a single type.
There are no repeating groups or arrays in columns (only one value per row).

This table follows 1NF as it has no composite or multi-valued attributes.

Second Normal Form (2NF)

A table is in 2NF if:

It is already in 1NF.
All non-key attributes are fully functionally dependent on the entire primary key.

Partial dependency occurs when a non-prime attribute depends on only part of a composite key, violating 2NF rules. Here's an example:

In this case, StudentName depends on StudentID and CourseName depends on CourseID, showing partial dependency. To convert this to 2NF, we break it into two tables: one for students and one for courses.

Third Normal Form (3NF)

A table is in 3NF if:

It is in 2NF.
All attributes are functionally dependent only on the primary key.

This example has a transitive dependency: CustomerName depends on CustomerID, which in turn depends on the primary key. To remove this, we separate customers into a new table, achieving 3NF.

Boyce-Codd Normal Form (BCNF)

A table is in BCNF if:

It is in 3NF.
For every functional dependency, the left-hand side (X) is a super key.

In BCNF, we further decompose tables to remove any dependencies where X is not a super key. This is demonstrated by breaking down tables in the example.

Fourth Normal Form (4NF)

A table is in 4NF if:

It is in BCNF.
There are no multi-valued dependencies.

Here, we see a multi-valued dependency between Course and Hobby, which is independent of each other. To achieve 4NF, we decom