1ra 2da 3ra Forma Normal Base De Datos

3.3.1 Primera forma normal (1FN).

El primer paso en la normalización es poner los datos en la primera forma normal. Esto se hace situando los datos en tablas separadas, de manera que los datos de cada tabla sean de un tipo similar, y dando a cada tabla una clave primaria y un identificador o etiqueta única. Esto elimina los grupos repetidos de datos.

Una tabla esta en 1FN si sólo si, en cada valor válido de esta tabla, toda tupla contiene un valor para cada atributo.

Esta definición establece simplemente que todas las tablas están siempre en 1FN, lo que por supuesto es correcto. Sin embargo, una tabla que solamente está en primera forma normal (es decir, una tabla 1FN que no está a la vez en 2FN y por lo tanto tampoco en 3FN) tiene una estructura que es indeseable por diversas razones. supongamos que la información relativa a Proveedores y Envíos se engloba en una sola tabla como sigue:

Primera

IdProveedor Estatus Ciudad idParte Cantidad

Estatus es dependiente funcionalmente de Ciudad. El significado de esta restricción es que el Estatus de un Proveedor se determina mediante la ubicación de ese proveedor; por ejemplo todos los Proveedores de Londres deben tener Estatus de 20. La llave primaria es la combinación de {idProveedor,idParte}; mostramos el diagrama de Dependencias Funcionales DF:

Dependencias Funcionales de la Tabla Primera

Observe que este diagrama DF es más copmplejo que el vimos en la sección anterior, un diagrama que esta en 3FN tiene flechas que parten sólo de las claves candidatas, mientras que un diagrama que no es 3FN, como el de Primera, tiene flechas que parten de claves candidatas junto con ciertas flechas adicionales (y son precisamente esas flechas las que ocacionan el problema). Los atributos que no son clave no son todos mutuamente independientes –puesto que Estatus depende de Ciudad (una flecha adicional)- y no son todos dependientes irreduciblemente de la clave primaria, debido a que Estatus y Ciudad son cada uno dependientes solo de idProveedor (dos flechas adicionales más).

Como base para ilustrar algunas de las dificultades que surgen de esas flechas adicionales, la siguiente figura presenta un valor de ejemplo para la tabla Primera. Los valores de los atributos son basicamente los de costumbre, salvo que cambiamos el Estatus del Proveedor P3 de 30 a 10 para que fuera consistente con la nueva restricción de que Ciudad determina a Estatus. Las redundancias son ovias. Por ejemplo, toda tupla del proveedor P1 muestra la ciudad como Londres; en forma similar, toda tupla de la ciudad de Londres muestra el Estus 20.

IdProveedor Estatus Ciudad IdParte Cantidad

P1 20 Londres A1 300

P1 20 Londres A2 200

P1 20 Londres A3 400

P1 20 Londres A4 200

P1 20 Londres A5 100

P1 20 Londres A6 100

P2 10 París A1 300

P2 10 París A2 400

P3 10 París A2 200

P4 20 Londres A2 200

P4 20 Londres A4 300

P4 20 Londres A5 400

Las redundancias en la Tabla Primera conducen a una variedad de lo que por razones historicas se ha denominado regularmente como anomalías de actualización; es decir, dificultades con las operaciones de actualización insert, delete y update. Para ordenar nuestras ideas nos concentraremos primero en la redundancia proveedor.ciudad, que corresponde a la DF idProveedor  Ciudad. Cada una de las tres operaciones presentan problemas:

Insert: No podemos insertar el hecho de que un proveedor en particular esté ubicado en una ciudad en particular hasta que ese proveedor sumnistre por lo menos una parte. De hecho, la figura anterior no muestra que el proveedor P5 está ubicado en Atenas. El motivo es que, hasta que P5 no suministre alguna parte, no tenemos un valor adecuado de la clave primaria.

Delete: Si eliminamos de Primera la única tupla de un proveedor en particular, no solo eliminamos el envio que conecta a ese proveedor con una parte en particular sino tambien la información de que el proveedor está ubicado en una ciudad en particular. Por ejemplo, si eliminamos de Primera la tupla con el valor P3 en {idProveedor} y el valor A2 en {idParte}, perdemos la información de que P3 está ubicado en París. (Los problemas de Insert y Delete representan en realidad dos caras de la misma moneda).

Nota: El verdadero problema aquí es que la tabla Primera contiene demasiada información incluida; de ahí que cuando eliminamos una tupla, eliminamos demasiado. Para ser más especificos, la tabla Primera contiene información con respecto a los envios e información alusiva a los proveedores, por lo que eliminar un envio hace que se elimine también la información del proveedor. Por supuesto, la solución a este problema consiste en “separar”, es decir, colocar la información de envios en una tabla y la información de proveedores en otra. Por lo tanto, otra manera informal de caracterizar el procedimiento de normalización es como un procedimiento de separación: colocar en tablas distintas, la información logicamente distinta.

Update: En general, el valor de una determinada ciudad aparece varias veces en la tabla Primera. Esta redundancia genera problemas de actualización. Por ejemplo, si el proveedor P1 se cambia de Londres a Amsterdam, nos enfrentamos ya sea al problema de examinar Primera para encontrar todas las tuplas que conectan P1 con Londres (y cambiarlo), o bien a la posibilidad de producir un resultado inconsistente (como dar a la ciudad de P1 el valor el valor de Amsterdam en una tupla y de Londres en otra).

La solución a estos problemas, es remplazar la tabla Primera por las dos tablas siguientes:

Segunda

{IdProveedor, Estatus, Ciudad}

Y

Envíos

{IdProveedor, idParte, Cantidad}

La siguiente figura muestra los diagramas de DFs para estas dos tablas; observe que ahora se incluye la información del Proveedor P5 (en la tabla

...