SISTEMAS GESTORES DE BASE DE DATOS.

APUNTES
UNIDAD 5
NORMALIZACION DE ESQUEMAS RELACIONALES

Habitualmente, el diseño de una base de datos termina en el paso del modelo

entidad—relación al modelo relacional. Sin embargo, siempre que se diseña un sistema,
no solamente base de datos, se debe de medir la calidad de la misma, y si no cumple
determinados criterios de calidad hay que realizar sucesivos refinamientos en el diseño
para alcanzar la calidad deseada. Uno de estos parámetros en la forma normal.

Si hemos diseñado los modelos conceptual y lógico veremos que la

normalización generalmente no requerirá cambios en el diseño.

El proceso de normalización consiste en verificar el cumplimiento de ciertas reglas

que aseguran la eliminación de redundancias e inconsistencias. Esto se hace mediante la
aplicación de ciertos procedimientos y en ocasiones se traduce en la separación de los
datos en diferentes relaciones.

El objetivo de una normalización es conseguir, un conjunto de relaciones óptimo

que, una vez implementado físicamente:

 Evite anomalías en operaciones de manipulación de datos.

 Forme una estructura flexible y fácil de mantener.
 Evite redundancias, y por lo tanto, posibilidad de inconsistencias.
 Evite perdida de información.

Veamos un ejemplo de estos problemas derivados de un diseño inadecuado. En la figura

se muestra la relación PARTICIPA que almacena datos sobre los proyectos
(Codigo_proyecto, Nombre y Horas) y sobre los empleados que realizan dichos proyectos
(DNI, nombre y dirección). Si observamos esta relación, vemos que presenta varios de
los problemas enumerados anteriormente.

Los principales problemas de esta relación se derivan de la gran cantidad de redundancia

que presenta. Por ejemplo, la dirección del empleado se repite por cada proyecto en el
que participa; y algo análogo sucede con los proyectos. Esta redundancia produce a su
vez:

Anomalías de inserción, ya que dar de alta un proyecto obliga a insertar en la base de

datos tantas tuplas como participantes tenga el proyecto.

-- 1
 SISTEMAS GESTORES DE BASE DE DATOS. APUNTES
Anomalías de modificación, ya que cambiar la dirección de un empleado obliga a
modificar todas las tuplas que corresponden a dicho empleado, y viceversa, si
cambiamos el nombre de un proyecto habría que cambiarlo en tantas tuplas como
empleados participen en dicho proyecto.
Anomalías de borrado, ya que el borrado de un proyecto obliga a borrar varias
tuplas, tantas como participantes tenga ese proyecto y, viceversa, el borrado de un
empleado nos lleva a borrar tantas tuplas como proyectos en los que participa .

Vemos, por tanto, que la actualización (alta, baja o modificación) de un solo empleado o
de un solo proyecto nos puede obligar a actualizar más de una tupla, dejándose la
integridad de la base de datos en manos del usuario. Al riesgo de la posible pérdida de
integridad, hay que añadir la falta de eficiencia asociada a estas múltiples
actualizaciones.

Además de estas anomalías de inserción, borrado y modificación, existen otros

problemas adicionales, como la imposibilidad de almacenar ciertos hechos, o la
desaparición de información que desearíamos mantener en la base de datos. Por ejemplo
si se quisiera incluir información sobre un empleado que no participe en ningún proyecto,
no sería posible ya que el atributo Codigo_proy forma parte de la clave primaria de la
relación.
Por otro lado, al dar de baja un empleado, se pierden también los datos de sus proyectos
(si éstos no tuviesen más que un empleado participando en él) y, viceversa, si borramos
un proyecto desaparecen de nuestra base de datos los datos de los empleados que
participen en dicho proyecto (a no ser que participen en más de un proyecto).

Esta relación presenta todos estos problemas debido a que atenta contra un principio básico
en todo diseño

En este caso, en relaciones distintas, con lo que se habrían evitado redundancias y, por
tanto, los problemas que acabamos de describir.

Si se hubiera llevado a cabo un diseño riguroso no se habría presentado una relación de

este tipo. Si se siguiera la metodología de diseño propuesta, realizando un buen diseño
conceptual en el modelo E/R, seguido de una cuidadosa transformación al modelo
relacional, se evitarían en gran parte estas anomalías, obteniéndose en general un
esquema exento de errores. Sin embargo, ante las posibles dudas respecto a si un
determinado esquema relacional es o no correcto, será preferible aplicar siempre a dicho
esquema un método formal de análisis que determine lo que pueda estar equivocado en
el mismo y nos permita llegar a otro esquema en el que se asegure el cumplimiento de
ciertos requisitos; este método formal, como ya hemos indicado, es la teoría de la
normalización.

-- 2
 SISTEMAS GESTORES DE BASE DE DATOS. APUNTES

El proceso de normalización se trata las dependencias que existen entre los atributos de
la relación.

 Dependencias funcionales

 Dependencias funcional

Se dice que un atributo B depende funcionalmente de otro A de la misma relación si,

para todo valor de A, se cumple que a cada valor de A le corresponde no más de un valor
de B.

Notación para indicar que un atributo B depende funcionalmente de A será: A -> B

Ejemplo: ALUMNOS

Dni Curso Grupo Aula Edificio

15985143 1 A INF 1
74895632 1 A INF 1
12233445 2 A BD 1
13569854 2 A BD 1
12569874 2 B SIST 2
15985243 2 B SIST 2

Podremos decir que el atributo edificio depende funcionalmente de aula, ya que cada
aula está situada en un edificio concreto, o sea, para cada valor de aula sólo existe un
valor de edificio (suponemos que lo nombres de las aulas son distintos en cada edificio),
luego

Aula -> edificio

Sin embargo, aula no depende funcionalmente de edificio porque para cada valor de
edificio existen varios valores de aula (cada aula que se sitúa en el mismo edificio)

Edificio aula

Las dependencias también se pueden expresar respecto a combinaciones de atributos. En

este caso la representación sería:

A
B C

Pues a cada par de valores de A y B le corresponde un valor de C. En este caso C tiene

una dependencia funcional de conjunto de A y B.

En el ejemplo, podremos decir que el atributo aula depende funcionalmente de la unión

de los atributos curso y grupo ya que, para cada par de valores de grupo y curso, sólo
existe un valor de aula.

Curso
Grupo

-- 3
 SISTEMAS GESTORES DE BASE DE DATOS. APUNTES
Aula

 Dependencia funcional completa

Se dice que un atributo C tiene dependencia funcional completa de un grupo de

atributos X de la misma relación, si C depende funcionalmente de X(A Y B) pero no de
ningún subconjunto obtenido de los posibles atributos que forman X (o de A o de B).

A
B C

En el ejemplo, el conjunto formado por curso y grupo con respecto al atributo aula, es un
ejemplo de dependencia funcional completa, ya que para cada curso existen varias aulas
y para cada grupo también, sólo para el par completo, el valor de aula es único.

Luego

Curso
Grupo Aula

 Dependencia transitiva

Sean A ,B y C tres atributos ( o grupos de atributos) de una relación. Si B depende

funcionalmente de A, y C de B, pero A no depende funcionalmente de , se dice que C
depende transitivamente de A.

A B C

En el ejemplo, podemos encontrar una dependencia funcional transitiva de edificio con

respecto a dni, ya que cumple:

aula depende edificio depende

funcionalmente del funcionalmente del
dni, por cada valor DNI aula edificio aula, por cada valor
de dni solo existe un de aula solo existe
aula un edificio
dni no depende funcionalmente
del aula, por cada valor de aula
hay varios valores de dni

-- 4
 SISTEMAS GESTORES DE BASE DE DATOS. APUNTES

 Pasos a seguir en la normalización

Las relaciones deben cumplir con unas restricciones que han sido definidas en las
distintas formas normales. En un principio, Codd definió las tres primeras formas normales.
Posteriormente, la tercera forma normal fue revisada por Boyce y el mismo Codd
aumentando el número de restricciones y pasándole a llamar forma normal de Boyce y
Codd (FNBC). Posteriormente, en los años setenta, fue Fagin quien definió la cuarta y
quinta forma normal.

Para un buen diseño de una base de datos el nivel exigible es hasta la tercera forma
normal.
 Primera forma normal (1FN)

Una relación esta en 1FN si el valor de los dominios de los atributos es único, es
decir, si todos sus atributos son monovaluados.

Ejemplo:

Cod_pedido Fecha Código Nombre Ciudad Tfno Codigo Descrip precio Codigo Tfno cantidad
pedido cliente cliente cliente cliente produt produt proved Prov
0001 12/3/02 32 Juan Madrid 9999999 010 Galletas 3€ 01 4444 5
Perez 045 Zumo 1€ 66 5555 10
095 Vino 2€ 21 1111 5
0002 12/4/02 25 Antonio Sevilla 7777777 033 Detergente 12€ 32 2222 3
Lopez 095 Vino 2€ 21 1111 2
078 champu 3€ 32 2222 1

Esta relación no esta en 1FN ya que para código de pedido (0001) existen varios códigos
de productos (010, 045).

Solución:

Una vez identificados los atributos que tienen varios valores para uno concreto de la
clave, se formará con ellos una nueva relación y se eliminarán de la antigua. La clave
principal de la nueva relación estará formada por la concatenación de uno o varios
atributos y la clave principal de la antigua.

Ejemplo:

Relación pedidos

Cod_pedido Fecha Código Nombre Ciudad Tfno

pedido cliente cliente cliente cliente
0001 12/3/02 32 Juan Perez Madrid 9999999
0002 12/4/02 25 Antonio Lopez Sevilla 7777777

Relación líneas_de-pedido

Cod_pedido Codigo Descrip precio Codigo Tfno cantidad

produt produt proved Prov
0001 010 Galletas 3€ 01 4444 5
0001 045 zumo 1€ 66 5555 10
0001 095 Vino 2€ 21 1111 5

-- 5
 SISTEMAS GESTORES DE BASE DE DATOS. APUNTES
0002 033 Detergente 12€ 32 2222 3
0002 095 Vino 2€ 21 1111 2
0002 078 champu 3€ 32 2222 1
La clave principal de esta relación pasará a ser cod_pedido+codigo product

 Segunda forma normal (2FN)

Una relación está en 2FN si está en 1FN y cada atributo suyo distinto de los que
componen una clave principal tiene una dependencia funcional completa de dicha clave
principal. Es decir, si está en 1FN y cada uno de los atributos depende de toda la clave.

En el ejemplo se observa que en la relación lineas_de_pedido, todos los atributos

menos el atributo cantidad no tienen una dependencia funcional completa de la clave,
sino que la tienen de una parte de la clave principal, del código del producto.

Relación líneas_de-pedido

Cod_pedido Codigo Descrip precio Codigo Tfno cantidad

produt produt proved Prov
0001 010 Galletas 3€ 01 4444 5
0001 045 zumo 1€ 66 5555 10
0001 095 Vino 2€ 21 1111 5
0002 033 Detergente 12€ 32 2222 3
0002 095 Vino 2€ 21 1111 2
0002 078 champu 3€ 32 2222 1

También podemos observar que la relación pedidos dispone de una clave simple, por
lo tanto podemos afirmar directamente que la relación pedidos esta en 2FN.

Solución

Una vez identificados los atributos que no dependen completamente de la clave

candidata, sino solamente de parte de ella, se formará con ellos otra relación y se
quitarán de la antigua. La clave principal de la nueva relación estará formada por la parte
de la antigua de la que dependen totalmente.

Ejemplo:

Relación líneas_de_pedido

Cod_pedido Codigo cantidad

produt
0001 010 5
0001 045 10
0001 095 5
0002 033 3
0002 095 2
0002 078 1

Relación productos

Codigo Descrip precio Codigo Tfno

produt produt proved Prov
010 Galletas 3€ 01 4444

-- 6
 SISTEMAS GESTORES DE BASE DE DATOS. APUNTES
045 zumo 1€ 66 5555
033 Detergente 12€ 32 2222
095 Vino 2€ 21 1111
078 champu 3€ 32 2222

Ahora la relación productos ya está en 2FN

 Tercera forma normal (3FN)

Una relación está en 3FN si está en 2FN y cada atributo que no pertenezca a un clave
candidata concreta no depende transitivamente de dicha clave candidata. Es decir, si
está en 2FN y cada uno de sus atributos depende sólo de la clave.

En el ejemplo, se observa que la relación productos el atributo tfno prov depende

transitivamente de la clave principal, que es el código de producto, o lo que es igual, no
dependen funcionalmente de la clave principal, sino del atributo código proved.

Asi mismo, en la relación pedidos, los atributos nombre cliente, ciudad cliente,
telefono cliente dependen del código cliente.

Solución:

Una vez identificados los atributos que dependen de otro atributo distinto de una
clave candidata, se formará con ellos otra relación y se quitarán de la antigua.
La clave principal de la nueva relación será el atributo del cual dependen. Este
atributo en la relación antigua pasará a ser una clave ajena.

Relación pedidos

Cod_pedido Fecha Código

pedido cliente
0001 12/3/02 32
0002 12/4/02 25

Relación clientes

Código Nombre Ciudad Tfno

cliente cliente cliente cliente
32 Juan Perez Madrid 9999999
25 Antonio Lopez Sevilla 7777777

Relación productos

Codigo Descrip precio Codigo

produt produt proved
010 Galletas 3€ 01
045 zumo 1€ 66
033 Detergente 12€ 32
095 Vino 2€ 21
078 champu 3€ 32

Relación proveedores

-- 7
 SISTEMAS GESTORES DE BASE DE DATOS. APUNTES
Codigo Tfno
proved Prov
01 4444
66 5555
21 1111
32 2222

Relación líneas_de_pedido

Cod_pedido Codigo cantidad

produt
0001 010 5
0001 045 10
0001 095 5
0002 033 3
0002 095 2
0002 078 1

 Forma Normal de Boyce-Codd(FNBC)

Se define determinante en una relación a un atributo del cual depende

funcionalmente de manera completa cualquier otro atributo de la relación. Una relación
está en forma normal de Boyce-Codd si y solo si ,todo determinante de ella es una clave
candidata.

La violación de esta forma es poco frecuente ya que se da bajo condiciones que

raramente se presentan. Se debe comprobar si una relación no cumple la FNBC si tiene
dos o más claves candidatas compuestas que tienen al menos un atributo en común.

La FNBC es más fuerte que la 3FN, por lo tanto, toda relación en FNBC está en
3FN.

Teorema de Boyce-Codd: sea una relación R formadas por los atributos A,B,C,D
con claves candidatas compuestas (A,B)y (B,C) tal que: AC, entonces la relación puede
descomponerse en cualquiera de las dos siguiente maneras: R1(A,C) y R2(B,C,D) o bien
R1(A,C) y R2(A,B,D).

Ejemplo: EMPLEADOS

DNI NUM_SS NOMBRE APELLIDO DEPART. PUESTO SALARIO

413245-B 28-123456 Juan Ramos Compras Gerente 2.300
234556-J 28-234568 Pedro Pérez Nóminas Auxiliar 1.200
123123-C 19-458766 Maria Gil Almacén Conserje 1.530
123455-B 45-223344 Antonio Sanz Compras Gestión 2.200

Observando los atributos de esta relación podemos ver que NUM_SS y el grupo
NOMBRE_APELLIDOS son claves candidatas (determinantes). Esta relación se transforma
en dos tablas: una contendrá la clave junto con las claves candidatas y la otra la clave
con el resto de campos .

-- 8
 SISTEMAS GESTORES DE BASE DE DATOS. APUNTES
EMPLEADOS

DNI NUM_SS NOMBRE APELLIDO

413245-B 28-123456 Juan Ramos
234556-J 28-234568 Pedro Perez
123123-C 19-458766 Maria Gil
123455-B 45-223344 Antonio Sanz

EMPLE-TRABAJO

DNI DEPART. PUESTO SALARIO

413245-B Compras Gerente 2.300
234556-J Nóminas Auxiliar 1.200
123123-C Almacen Conserje 1.530
123455-B Compras Gestión 2.200

 Cuarta Forma Normal(4FN)

Una relación está en cuarta forma normal si, y solo si, está en
FNBC y no existen dependencias multivaluadas.

Dependencia multivaluada: sean X e Y dos atributos , X multidetermina a Y (x->-

>Y) si para cada valor de X existe un conjunto bien definido de valores posibles en Y, con
independencia del resto de los atributos de la relación.

DNI TITULACION
413245-B Licenciado en Exactas.
413245-B Licenciado en Ciencias Físicas
234556-J Ingeniero en Telecomunicaciones.
123455-B Licenciado en Historia.
123455-B Licenciado en Filosofía.

Este tipo de dependencias produce redundancia de datos, en donde las claves

413245-B y 123455-B tienen dos registros para mantener la serie de datos de forma
independiente.

Teorema de Fagin: dada la relación formada por los atributos X,Y,Z con las
siguientes dependencias multivaluadas:
X->->Y y x->->Z, entonces la relación puede descomponerse en dos relaciones: R1(X,Y)
y R2(X,Z).

Ejemplo: GEOMETRÍA

FIGURA COLOR TAMAÑO

ESFERA ROJO GRANDE
ESFERA VERDE GRANDE
CUBO BLANCO MEDIANO
CUBO AZUL GRANDE
PIRAMIDE BLANCO GRANDE
PIRAMIDE BLANCO GRANDE
PIRAMIDE ROJO GRANDE

-- 9
 SISTEMAS GESTORES DE BASE DE DATOS. APUNTES
En ejemplo vemos que figura determina valores múltiples de color y tamaño, pero
color y tamaño son independientes entre si. Así, pues las dependencias son FIGURA ->-
>COLOR y FIGURA->->TAMAÑO.
Observamos que se repiten ESFERA-GRANDE, PIRÁMIDE-GRANDE O PIRÁMIDE-
BLANCO. Para Eliminar las redundancias de los datos se deben eliminar estas
dependencias de valores múltiples. Esto se logra, construyendo dos tablas, donde cada
una almacena datos para solamente uno de los atributos de valores múltiples.

FIGURA COLOR FIGURA TAMAÑO

ESFERA ROJO ESFERA GRANDE
ESFERA VERDE CUBO GRANDE
CUBO BLANCO CUBO MEDIANO
CUBO AZUL PIRAMIDE GRANDE
PIRAMIDE BLANCO
PIRAMIDE ROJO

 Quinta Forma Normal(5FN)

Una relación se encuentra en 5FN si, y solo si, toda dependencia de reunión en la
relación es una consecuencia de las claves candidatas. Esto es, la relación está en 5FN si
está en 4FN y no existen restricciones impuestas por el creador de la BD. La 5FN se
refiere a dependencias que son extrañas.

-- 10