La normalización es un proceso de diseño que busca organizar los datos para reducir redundancias e inconsistencias.
Normalización no es solo teoría
Las formas normales intentan evitar problemas reales de mantenimiento. Cuando una tabla mezcla demasiados conceptos, los errores aparecen al insertar, actualizar o eliminar.
La normalización obliga a preguntarnos de qué depende cada dato.
¿Qué problema resuelve?
Cuando la misma información se repite en muchas filas, actualizarla puede volverse peligroso. También puede ser difícil insertar o eliminar datos sin efectos no deseados.
Anomalía de actualización
El mismo dato aparece varias veces y debe modificarse en todas.
Ejemplo: si el teléfono de un profesor está repetido en 50 filas de alumnos y cambia, debemos actualizar las 50. Si una queda distinta, la base ya es inconsistente.
Anomalía de inserción
No podemos guardar una información sin crear otra que no debería ser necesaria.
Por ejemplo, no deberíamos necesitar inventar un alumno para poder registrar un nuevo curso.
Anomalía de eliminación
Al eliminar una fila perdemos información adicional.
Si el único registro del curso “SQL” estuviera mezclado con un alumno y eliminamos ese alumno, podríamos perder también la información del curso.
Primera Forma Normal: 1FN
Una tabla cumple 1FN cuando cada celda contiene un valor atómico y no listas de valores.
“Atómico” significa que, para el modelo que estamos diseñando, el valor se trata como una unidad. Guardar varios teléfonos separados por comas rompe esa idea porque luego es difícil buscar, validar o relacionar cada teléfono.
id | nombre | telefonos 1 | Ana | 123456, 654321
Ese campo mezcla dos teléfonos. Es mejor crear otra tabla.
Separación correcta
alumnos ------- id nombre telefonos_alumnos ----------------- id alumno_id telefono
Dependencia funcional
Decimos que un dato depende de otro cuando conocer la clave permite determinar ese valor.
Por ejemplo, si alumno_id = 10 identifica a Ana, entonces el nombre depende de alumno_id.
Segunda Forma Normal: 2FN
Además de cumplir 1FN, todos los atributos no clave deben depender de toda la clave primaria.
El problema aparece especialmente con claves compuestas.
Si la clave está formada por dos columnas, un atributo no clave no debería depender solo de una mitad de esa clave.
alumno_id | curso_id | alumno_nombre | curso_nombre | nota
Si la clave es (alumno_id, curso_id), alumno_nombre depende solo de alumno_id y curso_nombre solo de curso_id.
Por qué separar en tres tablas
alumnos guarda datos propios del alumno, cursos datos propios del curso e inscripciones datos de la relación, como nota o fecha de inscripción.
Cada dato queda entonces en el lugar del que realmente depende.
Solución 2FN
Separar alumnos, cursos e inscripciones.
Tercera Forma Normal: 3FN
Además de cumplir 2FN, un atributo no clave no debería depender de otro atributo no clave.
alumno_id | nombre | ciudad_id | ciudad_nombre | provincia
El nombre de ciudad y provincia dependen de ciudad_id, no directamente del alumno.
Dependencia transitiva
Ocurre cuando A determina B y B determina C. Entonces C depende indirectamente de A.
En términos prácticos: si un dato describe a otra entidad intermedia y no a la fila principal, probablemente merece su propia tabla.
Muchos a muchos
Se resuelve habitualmente con una tabla intermedia.
CREATE TABLE alumnos_cursos ( alumno_id INT NOT NULL, curso_id INT NOT NULL, fecha_inscripcion DATE, PRIMARY KEY (alumno_id, curso_id), FOREIGN KEY (alumno_id) REFERENCES alumnos(id), FOREIGN KEY (curso_id) REFERENCES cursos(id) );
¿Hasta dónde normalizar?
En aplicaciones transaccionales, llegar a 3FN suele ser una base razonable de diseño. Existen formas normales más avanzadas, pero no siempre hacen falta para sistemas comunes.
Normalizar no significa dividir todo
El objetivo es mejorar consistencia y diseño, no crear tablas sin necesidad.
Desnormalización
A veces se duplica información intencionalmente para rendimiento o reportes. Debe ser una decisión consciente y medida.
Ejemplo histórico
En una venta conviene guardar precio_unitario aunque el producto ya tenga un precio actual, porque necesitamos conservar el valor histórico cobrado.
Resumen
- 1FN: valores atómicos.
- 2FN: sin dependencias parciales.
- 3FN: sin dependencias transitivas.
Errores comunes
- pensar que normalizar es solo crear más tablas;
- guardar listas separadas por comas;
- duplicar datos sin motivo;
- desnormalizar antes de medir rendimiento.
Ejercicios
- normalizar teléfonos múltiples;
- separar alumnos y cursos;
- identificar dependencia parcial;
- identificar dependencia transitiva;
- diseñar clientes, pedidos y productos.
¿Qué sigue?
Proyecto práctico completo.
¿Te sirvió esta guía? ☕
Si este contenido te ayudó y querés apoyar a Club Programador para seguir publicando ejercicios, proyectos y guías gratuitas, podés colaborar mediante:
Ruta SQL / MySQL
Ver todos los contenidos de SQL / MySQL
Descubre más desde Club Programador
Suscríbete y recibe las últimas entradas en tu correo electrónico.
Un comentario en “Normalización de bases de datos: 1FN, 2FN y 3FN con ejemplos”