Normalización de Datos
La Base de un Diseño de Datos Robusto
El Fundamento: Sistemas Transaccionales (OLTP)
La normalización es la piedra angular del diseño de bases de datos para sistemas transaccionales (OLTP).
Piensa en ellos como la primera línea de tu negocio: cajas registradoras, formularios de registro, sistemas de inventario. Su prioridad absoluta es que los datos se escriban de forma rápida, segura y sin errores.
- Objetivo: Máxima integridad y cero redundancia.
- Técnica: Aplicar las Formas Normales (1NF, 2NF, 3NF...).
- Resultado: Datos consistentes en el sistema de origen.
1ª Forma Normal (1NF): Atomicidad
La regla es simple: cada celda de una tabla debe contener un único valor (atómico). No se permiten listas, arrays o conjuntos de valores en una sola celda.
Anomalía de Actualización: Si guardamos "Rojo, Verde" en una celda y queremos cambiar "Verde" por "Amarillo", necesitamos procesar el texto, lo cual es ineficiente y propenso a errores. Además, las búsquedas (`WHERE colores LIKE '%Verde%'`) son lentas y poco fiables.
La solución es dividir la información en tablas separadas, creando una tabla de enlace para manejar la relación de muchos a muchos, garantizando que cada pieza de información sea atómica.
2ª Forma Normal (2NF): Sin Dependencias Parciales
Requiere 1NF. La regla es que todos los atributos que no son clave deben depender de la clave primaria completa. Es crucial en tablas con llaves primarias compuestas.
Anomalía de Inserción: No podemos registrar un nuevo producto y su precio si aún no ha sido parte de ninguna orden, ya que necesitaríamos un `orden_id` para completar la clave primaria.
Anomalía de Eliminación: Si eliminamos la única orden que contiene un producto, perderíamos también la información del precio de ese producto.
3ª Forma Normal (3NF): Sin Dependencias Transitivas
Requiere 2NF. La regla es eliminar las dependencias transitivas: cuando un atributo no-clave depende de otro atributo no-clave.
Anomalía de Actualización: Si el nombre del departamento "Ventas" cambia a "Ventas Corporativas", habría que modificarlo en el registro de CADA empleado de ese departamento. Si olvidamos uno, los datos se vuelven inconsistentes.
La solución es mover el atributo dependiente (`Depto_Nombre`) a su propia tabla (`Departamentos`), donde existirá una sola vez.
Forma Normal de Boyce-Codd (BCNF)
Es una versión más estricta de la 3NF. Una tabla está en BCNF si, para cada dependencia funcional `X -> Y`, `X` es una superllave (es decir, una clave candidata).
Suele ser relevante en casos con múltiples claves candidatas compuestas y superpuestas. En el ejemplo, un estudiante puede tomar varias materias, y varios profesores pueden enseñar una materia, pero un profesor enseña una sola materia.
El problema: La dependencia `Profesor -> Materia` viola BCNF porque `Profesor` no es una clave candidata por sí solo. Esto puede llevar a redundancia si un profesor se asigna a la misma materia para diferentes estudiantes.
El Gran Debate: Normalización vs. Desnormalización
Hemos visto que la normalización es clave para la integridad. Pero, ¿qué pasa cuando nuestra prioridad es la velocidad de lectura para análisis complejos?
Aquí es donde entra la desnormalización. Para los sistemas analíticos (OLAP), a menudo rompemos las reglas de normalización a propósito. Combinamos tablas y duplicamos datos de forma controlada para que las consultas sean extremadamente rápidas, evitando los costosos JOINS.
Comparación de Enfoques: OLTP vs. OLAP
Sistemas Transaccionales (OLTP)
- Objetivo: Ejecutar operaciones diarias (INSERT, UPDATE, DELETE).
- Prioridad: Integridad y consistencia de datos.
- Diseño: Altamente Normalizado (3NF o superior).
- ✅ Máxima integridad, sin redundancia.
Sistemas Analíticos (OLAP)
- Objetivo: Analizar grandes volúmenes de datos (SELECT).
- Prioridad: Velocidad y simplicidad de las consultas.
- Diseño: Altamente Desnormalizado (Esquema de Estrella).
- ⚡️ Consultas mucho más rápidas (menos JOINS).