Normalización 1FN-3FN
Mapa conceptual
- Bases de Datos
- Modelo E-R
- Entidades
- Relaciones
- Cardinalidad
- Normalización
- 1FN
- 2FN
- 3FN
- SQL
- SELECT
- JOIN
- GROUP BY
- Transacciones
- ACID
- Bloqueos
- Índices
- B-tree
- Hash
- Modelo E-R
Por qué normalizar
Sin normalizar, el mismo dato se copia en muchas filas. Eso genera anomalías: actualizar un dato exige tocar todas las copias (anomalía de actualización), insertar obliga a repetir o inventar (de inserción) y borrar puede llevarse información que querías conservar (de borrado). La normalización las ataca de raíz.
Dependencia funcional
Es el concepto motor. Decimos que B depende funcionalmente de A si conocer A determina un único B. La clave determina todos sus atributos; pero a veces un atributo depende de otro atributo no clave, y ahí empiezan los problemas que cada forma normal resuelve.
Primera forma normal
Un atributo es atómico si no se puede desglosar en subpartes con significado propio. La primera forma normal prohíbe guardar varios valores en una celda: una columna de teléfonos separados por comas rompe la primera forma normal. Se resuelve moviendo la lista repetida a filas o a una tabla aparte.
Segunda forma normal
Requiere la primera, además de que ningún atributo no clave dependa de solo una parte de una clave compuesta. Si la clave es (pedido, producto) y el nombre del producto depende solo de producto, está parcialmente dependiente: se extrae a su propia tabla.
Tercera forma normal
Requiere la segunda y elimina dependencias transitivas: que un atributo no clave dependa de otro no clave. Si en una tabla de pedidos guardas ciudad y código postal del cliente, y ciudad depende del código postal, hay una transitiva. Se separa la dirección en su propia entidad.
- Identifica las dependencias funcionales entre atributos.
- Primera forma normal: haz cada valor atómico, sin listas en una celda.
- Segunda forma normal: quita dependencias parciales de la clave compuesta.
- Tercera forma normal: quita dependencias transitivas entre no claves.
- Repite hasta que cada tabla dependa de la clave, toda la clave y nada más que la clave.
La máxima recordada
Una regla mnemotécnica resume todo: cada atributo no clave debe depender «de la clave, de toda la clave y nada más que la clave». La primera parte la asegura la forma normal segunda (toda la clave), la segunda la tercera (nada más que la clave). Lo resume en una frase.
Anomalía de actualización
Si el nombre del proveedor se repite en cada producto que vende, cambiarlo obliga a actualizar cientos de filas, y una actualización incompleta deja versiones contradictorias. Normalizar guarda el nombre una sola vez, en la tabla proveedor.
Desnormalizar a propósito
En lectura intensiva, a veces compensa duplicar un dato derivado para evitar JOIN costosos: un nombre de ciudad copiado en la fila de pedido para no unir siempre. Es desnormalización consciente, típica de almacenes de datos, que cambia integridad por velocidad y exige mantener la copia sincronizada.
Formas más allá
Existen formas superiores (BCNF, cuarta y quinta) que tratan dependencias multivalor y de unión. Para el diseño cotidiano, llegar a tercera forma normal, o a BCNF cuando hay varias claves candidatas, suele ser suficiente y equilibrado.
| Forma normal | Exige | Elimina |
|---|---|---|
| 1FN | valores atómicos | listas en una celda |
| 2FN | sin dependencia parcial de clave compuesta | atributos que dependen de media clave |
| 3FN | sin dependencia transitiva | atributos que dependen de otro no clave |
En una tabla con clave compuesta (alumno, asignatura) guardas también el nombre del alumno, que depende solo de alumno. ¿Qué forma normal se viola?
Dependencias multivalor
Cuando un atributo determina un conjunto independiente de valores (un empleado con varios idiomas y varias titulaciones, sin relación entre ambos), se generan duplicaciones que tercera no captura. Ahí entra la cuarta forma normal, separando cada conjunto multivalor en su tabla.
Normalizar no es un fin
El objetivo no es coleccionar formas normales, sino un esquema sin anomalías que responda bien a las consultas reales. Un modelo sobre-normalizado con veinte tablas que obliga a catorce JOIN puede ser tan malo como uno desnormalizado lleno de redundancia.
Claves candidatas
Una tabla puede tener varias combinaciones de atributos que sirvan como clave. Alguna se elige primaria y las demás quedan candidatas (UNIQUE). La BCNF exige que todo determinante sea una clave candidata, cerrando rincones que tercera deja abiertos.
Errores frecuentes
- Quedarse en tercera cuando una dependencia multivalor sigue duplicando datos.
- Sobre-normalizar hasta volver las consultas impracticables.
- Confundir clave primaria con clave candidata y perder otras restricciones de unicidad.
Una tabla en tercera forma normal está automáticamente en primera y segunda.
Procedimiento práctico
Se parte de una tabla universal con todos los atributos y se van proyectando: cada dependencia detectada saca a su propia tabla. Es un ejercicio mecánico si identificas bien las dependencias funcionales, y un arte si el dominio es ambiguo.
Escalera de las formas normales
Toca una tarjeta para ver la respuesta.
Ordena la escalera de la normalización:
Arrastra cada ficha a su categoría (o tócala y luego toca la categoría). También puedes usar el teclado.
WikipediaRecorrido formal por las formas normales con ejemplos.
Dada una tabla Pedido (pedido id, cliente id, cliente nombre, producto, precio unitario, cantidad), identifica dependencias y descompónla hasta tercera forma normal.
Tu texto se guarda sólo en este dispositivo.
Documentación PostgreSQLReferencia oficial de SQL y bases de datos.
Comentarios
Inicia sesión para comentar.
Todavía no hay comentarios. Sé la primera persona en opinar.