Hoy vamos a profundizar, ahora con más detalle, en un tema importante: las ventajas y desventajas de la normalización, para que entiendas mejor cómo se aplican estos conceptos en la vida real. Así que abróchate el cinturón — ¡empezamos!
Eliminación de la redundancia de datos
Cuando los datos en una tabla no están normalizados, puedes encontrarte con que la misma información se repite en diferentes filas. Por ejemplo, en una tabla de pedidos puede haber una dirección de cliente repetida para cada pedido. La normalización elimina estas duplicaciones, moviendo los datos comunes a tablas separadas.
Ejemplo:
-- Antes de la normalización
CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
customer_name TEXT,
customer_address TEXT,
order_date DATE
);
-- Después de la normalización
CREATE TABLE customers (
customer_id SERIAL PRIMARY KEY,
customer_name TEXT,
customer_address TEXT
);
CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
customer_id INT REFERENCES customers(customer_id),
order_date DATE
);¿Por qué es importante? Menos datos duplicados significa menos posibilidades de cometer errores. Si la dirección del cliente cambia, solo tendrás que actualizarla en un solo sitio.
Garantizar la integridad de los datos
Cuando los datos están separados en tablas lógicas, es fácil gestionar sus relaciones. Usar claves externas ayuda a mantener la integridad de los datos automáticamente. Por ejemplo, no podrás borrar accidentalmente un cliente al que hacen referencia registros en la tabla de pedidos.
Ejemplo:
-- La clave externa garantiza que al borrar un cliente se borren también los pedidos relacionados
ALTER TABLE orders
ADD CONSTRAINT fk_customer FOREIGN KEY (customer_id)
REFERENCES customers(customer_id)
ON DELETE CASCADE;
Puedes estar seguro de que la estructura de la base de datos no permitirá que existan datos "huérfanos".
Facilita las actualizaciones
Cuando tu base de datos está normalizada, las actualizaciones son fáciles y menos propensas a errores. Volviendo al ejemplo de los clientes — si un cliente cambia de dirección, solo actualizas su registro en una tabla. En tablas no normalizadas, es probable que te olvides de actualizar la dirección en algunas filas, lo que lleva a inconsistencias en los datos.
Minimización de anomalías
Anomalías de inserción: en una tabla no normalizada puedes encontrarte con situaciones en las que no puedes añadir un registro sin información extra. Por ejemplo, no puedes añadir un pedido si no sabes el nombre del cliente.
Anomalías de actualización: pueden ocurrir errores al actualizar datos. Por ejemplo, si cambias el nombre del cliente en una fila, en otra puede quedar el nombre antiguo.
Anomalías de borrado: borrar un registro puede llevar a la pérdida de información importante. Por ejemplo, borrar un pedido también borra el nombre del cliente si esos datos están en la misma tabla.
Reducción del volumen de datos
La normalización suele reducir el tamaño de la base de datos, ya que elimina la duplicidad de datos. Esto es un aspecto importante para almacenar grandes volúmenes de información.
Desventajas de la normalización
1. Complejidad de la estructura de la base de datos
Con el tiempo, la normalización puede llevar a una estructura de base de datos compleja, compuesta por miles (!) de tablas relacionadas. En estos casos, para obtener datos que antes estaban en una sola tabla, tendrás que escribir consultas SQL complejas con múltiples JOIN.
Ejemplo de complejidad:
-- Consulta para obtener información de pedidos con detalles de productos y categorías
SELECT
o.order_id,
o.order_date,
c.customer_name,
p.product_name,
cat.category_name,
oi.quantity,
oi.unit_price
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.product_id
JOIN categories cat ON p.category_id = cat.category_id;
Si el número de tablas y relaciones aumenta, el tiempo de ejecución de las consultas puede crecer mucho.
2. Bajada de rendimiento con joins frecuentes
Hacer joins (JOIN) a menudo puede ser costoso en recursos, especialmente si las tablas son grandes y no tienen índices. En sistemas analíticos, donde las consultas requieren procesar millones de filas, la normalización puede causar penalizaciones importantes en el rendimiento.
3. Necesidad de operaciones extra para desnormalizar
Si la estructura normalizada de la base de datos se usa para fines analíticos, a veces hay que desnormalizarla temporalmente para acelerar las consultas analíticas. Esto puede incluir la creación de vistas (VIEW) o tablas para la agregación de datos.
Ejemplo:
-- Vista desnormalizada para analítica
CREATE VIEW orders_with_customers AS
SELECT
o.order_id,
o.order_date,
c.customer_name,
c.customer_address
FROM
orders o
JOIN
customers c ON o.customer_id = c.customer_id;
4. Alta barrera de entrada
Para los que empiezan, la normalización puede parecer complicada. En vez de una sola tabla con todos los datos, tienes que trabajar con varias tablas y entender sus relaciones. Esto puede ralentizar el desarrollo, sobre todo si el equipo no tiene mucha experiencia con bases de datos.
5. A veces la redundancia es útil
En proyectos reales, a veces es mejor mantener datos redundantes para mejorar el rendimiento. Por ejemplo, si una app usa a menudo datos que solo se pueden obtener con un join complicado, es mejor guardarlos en una sola tabla.
GO TO FULL VERSION