Normalización de Base de Datos (v2)
Veamos este nuevo ejemplo de una situación a normalizar:
Supongamos que tenemos la siguiente ficha de pedido de productos a proveedores:
Vamos a colocar los atributos descriptos usando el modelo lógico:
Pedido = {NPedido, Fecha, NProveedor, NomProveedor, Domicilio, NProducto, Descripción, PUnitario, Cantidad, PTotal, ImporteTotal}
Se detecta la existencia de un conjunto repetitivo de datos compuesto por los elementos del cuerpo de los productos pedidos.
{NProducto, Descripción, PUnitario, Cantidad, PTotal}
Quedando ahora de la siguiente manera:
Pedido = {NPedido, Fecha, NProveedor, NomProveedor, Domicilio, ImporteTotal}
DetallePedido = {NPedido, NProducto, Descripción, PUnitario, Cantidad, PTotal}
Ahora ya se encuentra aplicada la primera forma normal (1FN), pero presenta un conjunto de problemas o anomalías:
- Creación: La información sobre un nuevo producto no se puede insertar, si no hay un pedido que lo incluya.
- Eliminación: Eliminar un registro de Producto en un pedido, implica la eliminación de un producto.
- Modificación: por cada registro de Pedido que solicite un producto determinado, escribe un ocurrencia en DetallePedido, que repite la información de éste. Si cambia algún atributo, no se verá reflejado en toda la base.
El mismo problema se presenta con los Proveedores.
Para aplicar la segunda forma normal (2FN), tenemos que recordar el concepto de Dependencia Funcional Completa, que indica que un atributo depende completamente de la clave y no de una parte la la clave.
Ejemplo: si tengo una relación
ProveedorProducto = {NProducto, NProveedor, Cantidad}
Cantidad depende de los dos componentes de la clave.
Dado que si no fuera así, no podríamos establecer a que producto o a que pedido pertenece la cantidad.
Por lo tanto la segunda forma normal (2FN) se aplica siempre que exista una clave compuesta.
Una relación que ya esté en (1FN) y no tenga claves compuestas, ya se encuentra en (2FN).
ProveedorProducto = {NProducto, NProveedor, Cantidad}
Cantidad depende de los dos componentes de la clave.
Dado que si no fuera así, no podríamos establecer a que producto o a que pedido pertenece la cantidad.
Por lo tanto la segunda forma normal (2FN) se aplica siempre que exista una clave compuesta.
Una relación que ya esté en (1FN) y no tenga claves compuestas, ya se encuentra en (2FN).
Pedido = {NPedido, Fecha, NProveedor, NomProveedor, Domicilio, ImporteTotal}
se encuentra en (1FN) y en (2FN)
DetallePedido = {NPedido, NProducto, Descripción, PUnitario, Cantidad, PTotal}
se encuentra (1FN) pero no en (2FN)
Dado que Descripción y PUnitario no depende funcional y completamente de la clave
(NPedido, NProducto)
Entonces debemos crear una relación para todos los atributos que dependan funcional y completamente de la clave:
Pedido = {NPedido, Fecha, NProveedor, NomProveedor, Domicilio, ImporteTotal}
DetallePedido = {NPedido, NProducto, Cantidad, PTotal}
Producto = {NProducto, Descripción, PUnitario}
El problema se presenta ahora, con la relación Pedido y la información de los proveedores, entonces aplicamos la tercera forma normal (3FN) que dice:
DetallePedido = {NPedido, NProducto, Cantidad, PTotal}
---
El problema se presenta ahora, con la relación Pedido y la información de los proveedores, entonces aplicamos la tercera forma normal (3FN) que dice:
Que los atributos no clave son independientes a cualquier otro atributo no clave. Indicando esto, que los atributos deben depender solo de la clave.
Pedido = {NPedido, Fecha, NProveedor, ImporteTotal}
DetallePedido = {NPedido, NProducto, Cantidad, PTotal}
Proveedor = {NProveedor, NomProveedor, Domicilio}
Producto = {NProducto, Descripción, PUnitario}
---