Summary of "Normalización de Base de datos - Te enseño a normalizar tu base de datos en 10 minutos"

Main ideas, concepts, and lessons

Database normalization is a set of techniques for designing relational databases so data is stored logically and coherently.
Normalization is important because it:
- Reduces redundancy (avoids storing the same information in multiple places).
- Facilitates updates (a change is made in one place).
- Prevents anomalies during insert, update, and delete operations.
- Protects data integrity (consistency across related data).
- Simplifies maintenance (less duplicated data to manage).
Normalization is expressed via normal forms, which apply to database tables:
- A database is “in normal form n” when its tables satisfy the rules of normal form n.
- Common practice: most databases aim for at least the first three normal forms.

Normal forms (methodology/rules) with examples

1st Normal Form (1NF)

Goal: ensure atomic, non-repeating data.

Rules:

Each cell must contain a unique (single) value.
No repeating groups / sets of columns for the same data type (e.g., no “product1, product2, product3…” style columns for the same attribute concept).
Order independence:
- Reordering rows or columns must not change meaning.

Example problem:

An orders table where the products column (or product values) contains multiple values in the same record/cell, violating the “single value per cell” rule.
A naive fix like adding multiple product columns (product1/product2) fixes the single-cell issue but breaks the “no multiple columns for the same domain/concept” rule.

1NF-compliant solution:

Split into separate tables:
- orders
- products (or order-products)
Store each product as a separate row linked by keys (e.g., order ID + product ID).
This avoids:
- Multiple product columns for the same attribute concept
- Repeated multi-value cells
- Structural inconsistency

2nd Normal Form (2NF)

Goal: remove redundancy caused by partial key dependency (especially with composite keys).

Requirements:

The table must already be in 1NF.
Every non-key attribute must depend entirely on the primary key, not just part of it.
- This matters most when the primary key is composite.

Example problem:

A courses/enrollments-style table includes:
- student ID, student name
- course ID, course name
Student name repeats across multiple rows because the same student is enrolled in multiple courses → redundancy.

2NF-compliant solution:

Decompose into three tables:
- students (student ID → student details like name)
- courses (course ID → course details like name)
- enrollments (composite key such as student ID + course ID)
The repeated student name is stored in the students table, not duplicated per enrollment row.

3rd Normal Form (3NF)

Goal: eliminate transitive dependencies among non-key attributes.

Requirements:

The table must be at least in 2NF.
There must be no transitive dependencies:
- Non-key attributes should depend directly on the primary key (and not on other non-key attributes).

Example problem (employees/departments):

employees table includes:
- employee ID, employee name
- department
- department location
department location depends on the department, not directly on the employee → transitive dependency.

3NF-compliant solution:

Split into two tables:
- employees (employee ID → employee name, department ID/reference)
- departments (department ID → department name, location)
To find an employee’s department location, you JOIN employees with departments.

Lesson:

3NF is presented as the minimum expected for a database to be considered normalized (in typical understanding).

4th Normal Form (4NF)

Goal: remove multivalued dependencies.

Problem pattern:

For the same key, there are two or more independent sets of data stored together redundantly.

Example problem (employees languages & skills):

An employee table includes both:
- multiple languages per employee
- multiple skills per employee
Combining these creates redundant cross-product-like rows (repetition of language/skill combinations).

4NF-compliant solution:

Decompose into multiple tables so the independent sets are stored separately:
- employees (employee data)
- employee_languages (employee ID + language)
- employee_skills (employee ID + skill)

5th Normal Form (5NF)

Goal: handle union dependencies for very complex relationships.

Concept:

A complex relationship can be decomposed into smaller ones such that the only way to reconstruct the original is by performing a JOIN/UNION of those decomposed parts.
Decomposition must ensure that joining the parts does not generate extra tuples beyond what the original relationship contains.

Example (suppliers/products/cities):

Original table represents valid combinations of:
- supplier offers product
- in which city
A naive decomposition into fewer tables can lead to extra combinations when joined back, producing pairs that were not originally present.
A 5NF-compliant decomposition uses more relations, but enforces the union constraint/business rule so that only the original valid combinations are recoverable.

Lesson:

5NF is described as relevant to very complex systems and is often not needed in typical applications.

Performance and practical guidance (Q&A style)

Does normalization affect query performance?
- Generally no; normalization mainly improves integrity and reduces errors.
- Performance impact may occur in systems with very complex queries.
- In practice, this can lead to controlled denormalization, often with:
  - replication
  - parallel tools
  - maintaining normalized data as the “source” while optimizing access in another form (e.g., for decision-making systems).
Is it always necessary to apply all normal forms?
- No.
- Most relational database applications are fine with up to 3NF.
- Higher normal forms (4NF, 5NF) are typically reserved for very complex requirements.
- If advanced normalization makes engineering/performance tradeoffs too costly, systems may use denormalization or other database paradigms.

Final takeaway summary of normal forms (as stated)

1NF: each cell has a single value.
2NF: eliminates partial dependencies.
3NF: eliminates transitive dependencies.
4NF & 5NF: refinements for complex relationships.

Speakers / sources featured

The video creator/host (unnamed in the subtitles) — explains normalization concepts.
Mentions / sources for further material:
- SQL in 10 minutes (another video on the same channel)
- ccy.com
- decoder.com
- coder.com (appears in subtitles; likely meant as a resources site/channel)