Las formas normales nos permiten diseñar adecuadamente una Base de Datos, lo que nos garantiza un correcto funcionamiento en el almacenamiento y recuperación de la información. Ahora nos corresponde analizar la Segunda Forma Normal.
Repasando un poco, recordemos que llamamos Relación a una tabla en la que podemos almacenar datos. Dicho esto, definimos la Segunda Forma Normal de esta manera:
“Una relación se encuentra en segunda forma normal si, y solo si, se encuentra en 1FN y si todos los atributos no clave dependen por completo de la clave” (Reynosa E., Maldonado C., Muñoz R., Damiano L., Abrutsky M, 2012).
En el artículo anterior comentamos la Primera Forma Normal. (1FN). Y una relación debe normalizarse a ese nivel si deseamos cumplir con la 2FN. Una vez cubierto este requisito, analicemos el siguiente: los atributos no clave deben depender por completo de la clave primaria y no a una parte de ella. Los atributos no clave son todos aquellos que no forman parte de la clave primaria, y ninguno de ellos dependerá de una parte de la clave primaria.
Veamos una de las relaciones que normalizamos en el artículo anterior. La relación que ahora llamaremos Detalle de Factura quedó de la siguiente forma:
Detalle de Factura | ||||||
PK | ||||||
Sucursal | Número de factura | Código de artículo | Nombre de artículo | Cantidad del artículo | Precio unitario del artículo | Subtotal del artículo |
01 | 100 | 01 | CAMISA | 2 | 50 | 100 |
01 | 100 | 02 | ZAPATOS | 3 | 80 | 240 |
01 | 100 | 05 | MESA | 1 | 100 | 100 |
01 | 101 | 09 | TINTA | 4 | 25 | 100 |
02 | 100 | 13 | CUADRO | 5 | 90 | 450 |
02 | 100 | 05 | MESA | 1 | 100 | 100 |
Fk |
Podemos afirmar que NO se encuentra en 2FN. ¿Por qué? Observe el atributo (columna) Nombre de artículo. Depende directamente del atributo Código de artículo que a su vez es parte de la Clave Primaria (PK). Lo mismo ocurre con Precio unitario del artículo. Decimos que depende de “Código” porque si cambiara “Código”, necesariamente tendría que cambiar el nombre de artículo y su precio.
Para resolver la situación anterior descompondremos la relación Detalle de Factura en 2 relaciones que se llamarán: Detalle de Factura (mantiene su nombre) y Artículos. En otras palabras, estamos sacando los atributos de artículo a una tabla nueva, que tendría la siguiente forma:
Artículos | ||
PK | ||
Código de artículo | Nombre de artículo | Precio unitario del artículo |
01 | CAMISA | 50 |
02 | ZAPATOS | 80 |
05 | MESA | 100 |
09 | TINTA | 25 |
13 | CUADRO | 90 |
05 | MESA | 100 |
Por lo que la relación Detalle de Factura quedaría de esta manera:
Detalle de Factura | |||||
PK | |||||
Sucursal | Número de factura | Código de artículo | Cantidad del artículo | Precio unitario del artículo | Subtotal del artículo |
01 | 100 | 01 | 2 | 50 | 100 |
01 | 100 | 02 | 3 | 80 | 240 |
01 | 100 | 05 | 1 | 100 | 100 |
01 | 101 | 09 | 4 | 25 | 100 |
02 | 100 | 13 | 5 | 90 | 450 |
02 | 100 | 05 | 1 | 100 | 100 |
Fk | Fk |
Observemos lo siguiente: Ahora el atributo Código de artículo es una clave foránea hacia la relación Artículos. También observemos que se mantiene el atributo Precio, y esto es así porque realmente son dos datos: el precio del artículo en la tabla Artículos representa el precio actual del artículo, mientras que el precio en la tabla Detalle de Factura representa el precio al momento de la venta del artículo.
En resumen: La 2FN se utiliza para eliminar las dependencias parciales (Oppel A., 2010). Cuando encontremos una violación a la 2FN debemos mover los atributos que son parcialmente dependientes a una nueva relación donde ese atributo dependa completamente de la clave primaria.
Normalizar nuestras tablas a 2FN nos permitirá eliminar cualquier anomalía que pudiera existir en una relación, lo que se traduce en Bases de Datos muy bien organizadas.
Referencias