Normalización
Una tabla única llamada pedidos tiene estas columnas: id_pedido, fecha, id_cliente, nombre_cliente, ciudad_cliente, id_producto, nombre_producto, precio_unitario, cantidad. Llévala a tercera forma normal y explica qué problema concreto evita cada paso.
Cómo se resuelve
- 1Antes de aplicar ninguna regla hay que saber cuál es la clave, porque las tres formas normales se definen contra ella. Una fila de esta tabla no es un pedido: es una línea de pedido, porque un pedido con tres productos ocupa tres filas. La clave es la pareja (id_pedido, id_producto).
- 2Primera forma normal: ya se cumple. Pide que cada celda guarde un solo valor, y aquí ninguna columna trae listas ni valores repetidos adentro. Es el paso que casi siempre está resuelto de entrada y en el que no hay nada que hacer.
- 3Segunda forma normal: prohíbe que una columna dependa de SOLO UNA PARTE de la clave compuesta. fecha, id_cliente, nombre_cliente y ciudad_cliente dependen únicamente de id_pedido, así que se van a una tabla pedidos(id_pedido, fecha, id_cliente, nombre_cliente, ciudad_cliente). Y nombre_producto depende únicamente de id_producto, así que se va a productos(id_producto, nombre, precio_actual). Lo que queda con la clave completa es pedido_items(id_pedido, id_producto, cantidad).
- 4Eso es lo que evita la 2FN: hoy, un pedido de tres productos repite tres veces la fecha y el nombre del cliente, y nada impide que las tres copias terminen distintas.
- 5Tercera forma normal: prohíbe que una columna que no es clave dependa de OTRA columna que tampoco es clave. En la tabla pedidos, nombre_cliente y ciudad_cliente dependen de id_cliente, que no es la clave. Se llevan a clientes(id_cliente, nombre, ciudad) y en pedidos queda solo id_cliente.
- 6Ahora la excepción, que es lo que separa a quien entiende de quien aplica reglas de memoria: precio_unitario NO se va a productos, se queda en pedido_items con el nombre precio_cobrado.
- 7La razón: el precio del catálogo cambia con el tiempo; el precio que se le cobró a ese cliente ese día es un hecho del pedido y no puede volver a moverse nunca. No es redundancia, es un dato histórico.
Respuesta: Cuatro tablas: clientes(id, nombre, ciudad), productos(id, nombre, precio_actual), pedidos(id, fecha, id_cliente) y pedido_items(id_pedido, id_producto, cantidad, precio_cobrado). Corregir el nombre de un cliente pasa a ser una sola fila en vez de cientos, y deja de ser posible que quede escrito de dos formas distintas.
El error de siempre: Normalizar también el precio y leerlo siempre desde productos con un join. El día que suban los precios, todas las facturas viejas cambian solas, los totales históricos dejan de cuadrar con la contabilidad y no hay forma de reconstruir lo que realmente se cobró. La normalización se aplica a los datos que describen algo; los que registran lo que pasó en un momento se congelan a propósito.
