3.2 Normalización.

La normalización de las relaciones en una base de datos resulta ser una

herramienta muy útil, este conjunto de técnicas se puede aplicar a bases de datos
en etapa de diseño o a bases de datos ya en uso para lograr su óptimo manejo.

La teoría de normalización está basada en lo que se denomina formas normales.

Formas normales

Para poder entender lo que son las formas normales, podemos decir que una
relación está en una forma normal específica si cumple con cierto conjunto de
restricciones o reglas que dicha forma normal específica.

Para empezar a tratar de forma individual lo que son las formas normales
necesitamos primeramente comprender los términos y formas de dependencias
funcionales que trataremos a continuación.

3.2.1 Dependencias funcionales.

Para poder comprender el concepto de dependencia funcional en una relación, lo

veremos desde dos puntos de vista diferentes, ambos validos y que podemos
evaluar en las relaciones de una base de datos.
Dependencia funcional tipo 1

“Dada una relación R, el atributo Y de R es funcionalmente dependiente del

atributo X de R si y sólo si cada valor de X en R tiene asociado a él exactamente
un valor de Y en R (en cualquier instante)”1

Las dependencias se expresan de la siguiente manera

X→Y

De esta manera estamos implicando que el atributo Y es funcionalmente

dependiente del atributo X

Si se quiere expresar en una forma gráfica lo haremos como se ilustra en la figura

45 a continuación:

Figura 45 Dependencia funcional X – Y

Supongamos que tenemos una relación cliente con los atributos rfc_cliente,
nombre-cliente, domicilio_cliente y teléfono_cliente como se ilustra en la figura 46.

1
C.J.Date, Introducción a los Sistemas de Bases de Datos. Addison-Wesley Iberoamericana, 1986, pp. 268.
 Figura 46 Relación cliente

Cada vez que aparece un nombre_cliente específico está asociado a un

rfc_cliente particular, lo mismo sucede con el domicilio_cliente y el
teléfono_cliente, por lo tanto podemos expresar las dependencias funcionales de
la siguiente forma:

rfc_cliente → Nombre_cliente
rfc_cliente → Domicilio_cliente
rfc_cliente → Teléfono_cliente

O de esta otra forma

rfc_cliente → Nombre_cliente, Domicilio_cliente, teléfono_cliente

También lo podemos ver de una manera grafica como se ilustra en la siguiente

figura 47.
 Figura 47 Ejemplo de dependencias funcionales tipo 1

Dependencia funcional tipo 2

“Dada una relación R, el atributo Y de R es funcionalmente dependiente del

atributo X de R si y sólo si, siempre que dos tuplas de R coincidan en sus valores
de X, también coincidan en sus valores de Y”2

En otras palabras, podemos decir que este tipo de dependencia funcional se

presenta siempre que hay pares de valores que aparecen en una relación siempre
iguales

Por ejemplo supóngase que en una relación de clientes contamos entre otros
atributos con clave_lada, (del teléfono) y ciudad_cliente. Esta relación se ilustra en
la figura 48

Figura 48 Relación cliente

Siempre que aparece una ciudad especifica de un cliente, esta ciudad esta
relacionada directamente con la clave lada, por lo que el par siempre aparecerán
en todas las tuplas que contengan dicha ciudad.

2
C.J.Date, Introducción a los Sistemas de Bases de Datos. Addison-Wesley Iberoamericana, 1986, pp. 268.
El diagrama de esta dependencia funcional se ilustra en la figura 49, y nos dice
que el atributo clave_lada es funcionalmente dependientemente de ciudad_cliente.

Figura 49 Ejemplo de dependencias funcionales tipo 2

3.2.2 Primeras formas normales.

Existen un gran número de formas normales, para efectos de nuestro estudio en

este capítulo abordaremos las primeras de ellas, haciendo énfasis en las tres
primeras

3.2.2.1 1FN.

La primera forma normal también conocida como 1FN se define de la siguiente

forma.
“Una relación R está en primera forma normal (1FN) si y sólo si todos los dominios
subyacentes sólo contienen valores atómicos”3

Es decir, que cada uno de los atributos de una relación solo sea capaz de
almacenar un solo valor por tupla.

Dicho de una manera informal, podemos decir que una relación está en primera
forma normal si tiene una llave primaria bien definida y no tiene atributos
multivalorados

Si una relación se encuentra solamente en primera forma normal, presenta varias

complicaciones en su uso, que expondremos un poco mas adelante.

3.2.2.2 2FN.

A continuación citaremos la segunda forma normal o 2FN.

“Una Relación R está en segunda forma normal (2FN) si y sólo si está en 1FN y
cada atributo no primo es completamente dependiente de la llave primaria”4

Atributo no primo

Un atributo no primo es aquel atributo de la relación que no forma parte de la llave

primaria

En esta segunda forma normal, la debemos tomar con especial cuidado cuando
hablamos de llaves primarias compuestas, ya que los atributos no primos, es decir
los que no forman parte de la llave primaria pueden depender solamente de uno
de los componentes de la llave primaria, no necesariamente de toda ésta.

3
C.J.Date, Introducción a los Sistemas de Bases de Datos. Addison-Wesley Iberoamericana, 1986, pp. 271.
4
C.J.Date, Introducción a los Sistemas de Bases de Datos. Addison-Wesley Iberoamericana, 1986, pp. 274.
Por ejemplo si tenemos una relación Pagos que cuenta con los atributos:
Rfc_cliente, Numero_pago, fecha, nombre_cliente, e importe_pago. Que se utiliza
para registrar los pagos que ha hecho un cliente específico del adeudo que tiene y
estos se llevan en forma consecutiva esta relación la encontramos en la figura 50

Figura 50 Ejemplo Relación Pagos

Entonces podemos decir que la llave primaria está compuesta por Rfc_cliente, y
Numero_pago, ahora veamos como se representan las dependencias funcionales
en esta relación, esto se ilustra en la figura 51 a continuación

Figura 51 Ejemplo de dependencias funcionales en una relación que no está en 2FN

En este diagrama podemos apreciar que si bien es cierto la relación pagos está en
primera forma normal en vista de que cada uno de los atributos con que cuenta
dicha relación solo tiene valores atómicos por cada tupla que contenga, sin
embargo, no lo está en segunda forma normal, debido a que los atributos fecha e
importe_pago si tienen dependencia funcional hacia la llave primaria completa, sin
embargo el atributo nombre_cliente solo tiene dependencia funcional al
rfc_clientes.

3.2.2.3 3FN.

Para continuar con las formas normales ahora expliquemos lo que corresponde a
la tercera forma normal o 3FN

“Una relación R está en tercera forma normal (3FN) si y sólo si está en 2FN, y todo
atributo no primo es dependiente no transitivamente de la llave primaria”5

En esta tercera forma normal, nos enfocamos ahora a los atributos no primos y
sus dependencias funcionales entre si, independientemente de las dependencias
funcionales que tengan sobre la llave primaria.

En algunas ocasiones habrá atributos en los cuales exista una dependencia

transitiva hacia la llave primaria, ¿qué queremos decir con esto?, simplemente que
un atributo depende funcionalmente de la llave primaria porque tiene una
dependencia hacia un atributo no primo que depende directamente de la llave
primaria.

Ahora supongamos que contamos con una relación para registrar tarjetas de
crédito, llamada tarjetas, que cuenta con los siguientes atributos: numero_tarjeta,
fec_exp (fecha de expedición), año_venc, Limite_credito, rfc_cliente,
nombre_cliente, domicilio_cliente. Esto lo ilustramos en la figura 52 a continuación.

5
C.J.Date, Introducción a los Sistemas de Bases de Datos. Addison-Wesley Iberoamericana, 1986, pp. 276.
 Figura 52 Relación tarjetas

Las dependencias funcionales están reflejadas en el siguiente diagrama que

muestra la figura 53, aquí podemos apreciar que la relación tarjetas está en
primera forma normal ya que los dominios de sus atributos son atómicos, también
está en segunda forma normal, dado que todos los atributos no primos tienen una
dependencia funcional completamente hacia la llave primaria, pero no está en
tercera forma normal ya que existe una dependencia transitiva en lo que se refiere
a los atributos nombre_cliente y domicilio_cliente que dependen de la llave
primaria a través del atributo rfc_cliente.

Figura 53 Dependencias funcionales de la relación tarjetas

Ejemplo 1FN, 2FN y 3FN

Hasta ahora hemos definido y explicado lo que son la primera, segunda y tercera
forma normal, de modo siguiente lo que haremos es llevar una relación que este
en primera forma normal, hasta la tercera forma normal con sus respectivas
conversiones y explicando claramente la problemática de dejar una relación solo
en primera forma normal o solo en segunda forma normal, al momento de agregar,
eliminar o actualizar tuplas.

Consideremos la siguiente relación mostrada en la figura 54

Figura 54 Relación Almacen

Esta relación llamada Almacen contiene el registro de un almacén en donde se

representa el artículo a quien lo compramos, cuanto tenemos y los datos del
proveedor como nombre, tipo y descripción del tipo para especificar si es un
proveedor al que le compramos a crédito o en efectivo. La llave primaria de esta
relación es compuesta por no_articulo y no_proveedor.

En la figura 55, mostramos lo que se refiere al diagrama de dependencias

funcionales de la relación anterior
 Figura 55 Diagrama de dependencias funcionales de la relación Almacen

Una vez descrito el contexto, empecemos con el ejemplo.

La relación Almacen, se encuentra en primera forma normal, porque todos los

dominios asociados a sus atributos son atómicos, sin embargo no está en
segunda forma normal.

No se encuentra en segunda forma normal porque no todos los atributos no

primos dependen completamente de la llave primaria ya que los atributos
nombre_proveedor, tipo_prov y desc_tipo solo dependen funcionalmente de lo que
es no_proveedor, que no es la llave primaria completa.

Ahora bien, se pudiera pensar que esto no tiene mayor importancia ya que en la
figura 54 vemos registrada la información que se supone queremos.

Analicemos algunos problemas de que una relación este en 1FN y no en 2FN.

En la relación Almacen tenemos registrada la información de varios proveedores,

¿qué sucede si quiero contar con la información del proveedor 500 y no le hemos
comprado ningún articulo? Sencillo, no podríamos ingresar dicha información
debido a que no podemos ingresar una llave primaria con valores nulos y
no_articulo seria nulo. Esto lo vemos en la figura 56 a continuación.

Figura 56 Error de inserción en la relación Almacen

Vamos a plantear otra situación, ¿qué pasa si queremos borrar la tupla donde está
el artículo número 3 porque esa compra ya no se llevó a cabo? En este caso
estaríamos borrando además de la información del artículo, toda la información del
proveedor número 456 incluyendo nombre, tipo y descripción de tipo, lo que no
sería nada conveniente. Veamos el gráfico de la figura 57, lo mismo pasaría con el
proveedor número 823.

Figura 57 Error de borrado en la relación Almacen

Una situación más, ¿qué pasa si un proveedor cambia de forma en la que le
tenemos que pagar y este tiene más de dos tuplas en la relación? En este caso
corremos el riesgo de no afectar todas sus apariciones, y entonces dejar la base
de datos en un estado inconsistente, veamos como ejemplo el proveedor número
222 si cambia de efectivo a crédito en su forma de pago y solo se modifica su
segunda aparición, este error o problema lo reflejamos en la figura 58. Se nota
claramente que tenemos un problema de inconsistencia de la base de datos ya
que podemos consultar en una tupla es crédito y en otra es efectivo, lo que es
incorrecto.

Figura 58 Error de actualización en la relación Almacen

Para poder eliminar estos problemas mencionados, tendremos que hacer una
modificación a la relación Almacen original. Ahora representemos una división de
la misma como sigue en la figura 59 que nos indica como quedarían las
dependencias funcionales al hacer la separación.

La descomposición de la relación Almacen se hace tomando la llave primaria y

dejando solo los atributos que son completamente dependientes de la misma.
Aquellos que solo dependen de una parte de ella, vienen a formar otra relación en
este caso llamada Proveedor.
 Figura 59 Dependencias funcionales de las relaciones Almacen y proveedor.

Continuando con el ejemplo, la relación Almacen ya se encuentra en primera,

segunda y tercera forma normal, sus atributos tienen dominios atómicos, todos los
atributos no primos dependen completamente de la llave primaria y no tiene
dependencias transitivas.

La relación Proveedor ahora está en 2FN ya que tiene dominios atómicos, los
atributos no primos dependen completamente de la llave primaria. Sin embargo no
está en tercera forma normal ya que si existen dependencias transitivas entre
desc_tipo y tipo_prov, es decir la descripción si depende del número de proveedor
pero a través del tipo de proveedor.

A continuación mostramos como quedan los ejemplares de las relaciones Almacen

y Proveedor en la figura 60.
 Figura 60 Ejemplares de las relaciones Almacen y Proveedor.

En este momento analicemos si se solucionaron los problemas al hacer esta

modificación.

El problema de insertar un nuevo proveedor ahora no lo es mas, como se ve en la

figura 61 a continuación

Figura 61 Inserción de un proveedor

Para el caso de borrado en el que queríamos eliminar el artículo número 3, ahora

lo podemos hacer conservando la información del único proveedor 456 que estaba
asociado a él. La figura 62 nos muestra como quedan las relaciones al hacer esta
acción.

Figura 62 Borrado de un artículo sin afectar al proveedor.

En el caso de actualización, habíamos mencionado que si cambiábamos la forma

de pago del proveedor 222 de Efectivo a Crédito podíamos ocasionar
inconsistencia de la base de datos porque puede aparecer este proveedor en
varios lugares, ahora ya no sucede eso, debido a que cada proveedor solo
aparece una vez en la relación. La figura 63 lo ilustra.

Figura 63 Actualización de proveedor.

Enfoquémonos ahora a la relación Proveedor y su problemática al solo estar en
2FN y no en tercera forma normal.

Imagine que ahora queremos tener una nueva forma de pago específica y es del
tipo T y se llamara Tarjeta para denotar que se pagara con tarjeta de crédito. No
podríamos registrar eso en la base de datos ya que implica dar de alta un registro
en la relación Proveedor pero sin llave primaria, lo que sería un gran error.
Veámoslo en la figura 64.

Figura 64 Error de inserción en la relación Proveedor.

Veamos la situación del borrado, ¿qué sucedería si de casualidad tuviéramos que

borrar las tuplas de los clientes 222 y 823? Pues estaríamos eliminando también la
información de que el tipo_prov con valor E corresponde a pago en Efectivo. Esto
se aprecia en la figura 65 siguiente.
 Figura 65 Error de borrado en la relación Proveedor.

Para concluir con los problemas de la relación proveedor, pensemos en la

actualización, queremos cambiar el tipo_prov C, que ahora tiene Crédito en
desc_tipo por una nueva descripción que diga 30 días, si no lo hacemos en todas
las tuplas que aparece, ocasionaremos un problema de inconsistencia como se
aprecia en la figura 66.

Figura 66 Error de actualización en la relación Proveedor.

Bueno ya vimos que no es conveniente que una relación se quede solo en 2FN y
no llegue a 3FN, entonces hagamos la conversión correspondiente de la tabla
proveedor para poder salvar estos errores. Queda como sigue en la figura 67 el
diagrama de dependencias funcionales
 Figura 67 Diagrama de dependencias funcionales de las relaciones Proveedor y Tipos.

Y el ejemplar de las relaciones Proveedor y Tipo es como está en la figura 68, ahí
podemos apreciar mas claramente como queda su contenido.

Figura 68 Diagrama de dependencias funcionales de las relaciones Proveedor y Tipos.

En este punto veremos si los problemas manifestados de solo estar en 2FN se

han logrado resolver.
Primero el caso de la inserción de un tipo, ahora se hace sin violar reglas de la
llave primaria, ver figura 69.
 Figura 69 Inserción en relación Tipos.

En el caso de borrado, ahora podemos fácilmente borrar todos los proveedores

asociados a un tipo, sin borrar dicho tipo como podemos ver en la figura 70, en la
que se borraron los proveedores 222 y 823 y no se borro el tipo

Figura 70 Borrado correcto de proveedores sin afectar los tipos.

En el último de los casos que se refiere a la actualización de un tipo, ahora no

existe la posibilidad de dejar inconsistente la base de datos, esto queda
claramente ilustrado en la figura 71 a continuación.
 Figura 71 Actualización correcta de la relación Tipos.

En este momento ya tenemos tres relaciones normalizadas hasta la 3FN.