BASES DE DATOS RELACIONALES

Normalizacin
Antes de poder aplicar el proceso de normalizacin, debemos asegurarnos de que estamos
trabajando con una base de datos relacional, es decir, que cumple con la definicin de base de datos
relacional.
El proceso de normalizacin consiste verificar el cumplimiento de ciertas reglas que aseguran la
eliminacin de redundancias e inconsistencas. Esto se hace mediante la aplicacin de ciertos
procedimientos y en ocasiones se traduce en la separacin de los datos en diferentes relaciones. Las
relaciones resultantes deben cumplir ciertas caractersticas
a. !e debe conservar la informacin
"onservacin de los atributos.
"onservacin de las tuplas, evitando la aparicin de tuplas que no estaban en las relaciones
originales.
b. !e deben conservar las dependencias.
Este proceso se lleva a cabo aplicando una serie de reglas llamadas "formas normales".
Estas reglas permiten crear bases de datos libres de redundancias e inconsistencias, que se ajusten
a la definicin del doctor "odd de base de datos relacional.
MySQL usa bases de datos relacionales, de modo que debemos aprender a usar con soltura, al
menos, las tres primeras formas normales.
La teora completa de bases de datos relacionales es muy compleja, y puede resultar muy oscura si
se e#presa en su forma m$s simblica. %er esta teora en profundidad est$ fuera de los objetivos de este
curso, al menos por el momento.
!in embargo, necesitaremos comprender bien parte de esa teora para aplicar las tres primeras
formas normales. La comprensin de las formas cuarta y quinta requieren una comprensin m$s profunda
de conceptos complejos, como el de las dependencias multivaluadas o las dependencias de proyeccin.
&'
4.1 Peligros en el diseo de bases de datos relacionales.
Los principales inconvenientes que se presentan cuando el dise(o de un modelo no satisface las
formas normales son
)epeticin de la informacin
*ificultad para representar y+o interpretar cierta informacin.
,erdida de la informacin
Ejemplo: !uponga que se desea controlar el pr-stamo de libros a alumnos del tecnolgico. !e
asume que e#iste una base de datos de la bibliografa e#istente cuya llave es la clasificacin.
Versin 1
PROBLEMAS
)epeticin de datos del alumno en cada pr-stamo
.o es posible establecer comparativos con usuarios y no usuarios por solo est$n
restringidos los usuarios.
Al modificar un atributo del alumno deber$ recorrerse todo el archivo...
Versin 2 (ESPECIALIZACI!"
.o funciona porque no hay relacin.
Versin #
,)/0LE1A!
&2
.o es posible determinar fechas de prestamos de un libro a aun alumno en particular.
!olo se registran alumnos con prestamos o se desperdicia atributo clasif.
)epetir datos del alumno por el pr-stamo o reutilizar el campo clasif, lo ultimo tiene
dos problemas
!e pierde historial de prestamos
3n alumno solo puede tener un pr-stamo a la vez.
Al caso mostrado en la %ersin 4 se le denomina *E!"/1,/!5"56. "/. ,E)*5*A dado que
al realizar la especializacin se pierde informacin que e#ista por la relacin entre los atributos.
Versin $
MO%ELO OP&IMO'
%e(ini)in: ,ara que una base de datos sea 78., es decir, que cumpla la primera forma normal,
cada columna debe ser atmica.
A*mi)+ no tiene que ver con la energa nuclear 9:, no se trata de crear columnas e#plosivas ni
que produzcan grandes cantidades de energa y residuos radiactivos...
A*mi)+ significa ;indivisible;, es decir, cada atributo debe contener un <nico valor del dominio.
Los atributos, en cada tabla de una base de datos 78., no pueden tener listas o arrays de valores, ya sean
del mismo dominio o de dominios diferentes.
Adem$s, cada atributo debe tener un nombre <nico. Esto es algo que en general, al menos
trabajando con MySQL, no nos preocupa= ya que la creacin de las tablas implica definir cada columna
de un tipo concreto y con un nombre <nico.
>ampoco pueden e#istir tuplas id-nticas. Esto puede parecer obvio, pero no siempre es as.
!upongamos una base de datos para la gestin de la biblioteca, y que el mismo da, y al mismo socio, se le
presta dos veces el mismo libro ?evidentemente, el libro es devuelto entre cada pr-stamo, claro:. Esto
@A
producir$, si no tenemos cuidado, dos registros iguales. *ebemos evitar este tipo de situaciones, por
ejemplo, a(adiendo una atributo con un identificador <nico de pr-stamo.
"omo vemos, las restrinciones de la primera forma normal coinciden con las condiciones de las
relaciones de una base de datos relacional, por lo tanto, siempre es obligatorio aplicar esta forma normal.
Aplicar la primera forma normal es muy simple, bastar$ con dividir cada columna no atmica en
tantas columnas atmicas como sea necesario. ,or ejemplo, si tenemos una relacin que contiene la
informacin de una agenda de amigos con este esquema
A,en-+?.ombre, email:
El nombre, normalmente, estar$ compuesto por el tratamiento ?se(or, se(ora, don, do(a,
e#celencia, alteza, se(ora, etc:, un nombre de pila y los apellidos. ,odramos considerar el nombre como
un dato atmico, pero puede interesarnos separar algunas de las partes que lo componen.
BC qu- pasa con la direccin de correo electrnicoD >ambi-n podemos considerar que es un valor
no atmico, la parte a la izquierda del smbolo E es el usuario, y a la derecha el dominio. *e nuevo,
dependiendo de las necesidades del cliente o del uso de los datos, podemos estar interesados en dividir
este campo en dos, o incluso en tres partes ?puede interesar separar la parte a la derecha del punto en el
dominio:.
>anto en esta forma normal, como en las pr#imas que veremos, es importante no llevar el
proceso de normalizacin demasiado lejos. !e trata de facilitar el trabajo y evitar problemas de
redundancia e integridad, y no de lo contrario. *ebemos considerar las ventajas o necesidades de aplicar
cada norma en cada caso, y no e#cedernos por intentar aplicar las normas demasiado al pi- de la letra.
El esquema de la relacin puede quedar como sigue
A,en-+?.ombreF>ratamiento, .ombreF,ila, .ombreFApellidos, email:
@7
/tro caso frecuente de relaciones que no cumplen 78. es cuando e#isten atributos multivaluados,
si todos los valores se agrupan en un <nico atributo
Li.ros?>itulo, autores, fecha, editorial:
Gemos previsto, muy astutamente, que un libro puede tener varios autores. .o es que sea muy
frecuente pero sucede, y m$s con libros t-cnicos y libros de te#to.
!in embargo, esta relacin no es 78., ya que en la columna de autores slo debe e#istir un valor
del dominio, por lo tanto debemos convertir ese atributo en uno multivaluado
Li.ros
>itulo autor fecha editorial
Hue bueno es 1y!HL fulano 7I+7A+IAA4 La buena
Hue bueno es 1y!HL mengano 7I+7A+IAA4 La buena
"at$strofes naturales tulano 7'+A4+722' ,en<triga
3no de los retos en el dise(o de la base de datos es el de obtener una estructura estable y lgica tal
que
El sistema de base de datos no sufra de anomalas de almacenamiento.
El modelo lgico pueda modificarse f$cilmente para admitir nuevos requerimientos.
3na base de datos implantada sobre un modelo bien dise(ado tiene mayor esperanza de vida aun
en un ambiente din$mico, que una base de datos con un dise(o pobre. En promedio, una base de datos
e#perimenta una reorganizacin general cada seis a(os, dependiendo de lo din$mico de los requerimientos
de los usuarios. 3na base de datos bien dise(ada tendr$ un buen desempe(o aunque aumente su tama(o, y
ser$ lo suficientemente fle#ible para incorporar nuevos requerimientos o caractersticas adicionales.
E#isten diversos riesgos en el dise(o de las bases de datos relacionales que afecten la
funcionalidad de la misma, los riesgos generalmente son la redundancia de informacin y la
inconsistencia de datos.
La normalizacin es el proceso de simplificar la relacin entre los campos de un registro. ,or
medio de la normalizacin un conjunto de datos, en un registro, se reemplaza por varios registros que son
@I
m$s simples y predecibles y, por lo tanto, m$s manejables. La normalizacin se lleva a cabo por cuatro
razones
Estructurar los datos de forma que se puedan representar las relaciones pertinentes entre los datos.
,ermitir la recuperacin sencilla de los datos en respuesta a las solicitudes de consultas y reportes.
!implificar el mantenimiento de los datos actualiz$ndolos, insert$ndolos y borr$ndolos.
)educir la necesidad de reestructurar o reorganizar los datos cuando surjan nuevas aplicaciones.
En t-rminos m$s sencillos la normalizacin trata de simplificar el dise(o de una base de datos,
esto a trav-s de la b<squeda de la mejor estructuracin que pueda utilizarse con las entidades involucradas
en ella.
P+sos -e l+ norm+li/+)in:
*escomponer todos los grupos de datos en registros bidimensionales.
Eliminar todas las relaciones en la que los datos no dependan completamente de la llave primaria
del registro'
Eliminar todas las relaciones que contengan dependencias transitivas.
La teora de normalizacin tiene como fundamento el concepto de formas normales= se dice que
una relacin est$ en una determinada forma normal si satisface un conjunto de restricciones.
Dependencias funcionales
Ca hemos comentado que una relacin se compone de atributos y dependencias. Los atributos son
f$ciles de identificar, ya que forman parte de la estructura de la relacin, y adem$s, los elegimos nosotros
mismos como dise(adores de la base de datos.
,ero no es tan sencillo localizar las dependencias, ya que requieren un an$lisis de los atributos, o
con m$s precisin, de las interrelaciones entre atributos, y frecuentemente la intuicin no es suficiente a la
hora de encontrar y clasificar todas las dependencias.
@4
La teora nos puede ayudar un poco en ese sentido, clasificando las dependencias en distintos
tipos, indicando qu- caractersticas tiene cada tipo.
,ara empezar, debemos tener claro que las dependencias se pueden dar entre atributos o entre
subconjuntos de atributos.
Estas dependencias son consecuencia de la estructura de la base de datos y de los objetos del
mundo real que describen, y no de los valores actualmente almancenados en cada relacin.
,or ejemplo, si tenemos una relacin de vehculos en la que almacenamos, entre otros atributos, la
cilindro y el color, y en un determinado momento todos los vehculos con IAAA c.c. son de color rojo, no
podremos afirmar que e#isten una dependencia entre el color y la cilindrada. *ebemos suponer que esto
es slo algo casual.
,ara buscar dependencias, pues, no se deben analizar los datos, sino los entes a los que se refieren
esos datos.
%e(ini)in: !ean J e C subconjuntos de atributos de una relacin. *iremos que C tiene una
dependencia funcional de J, o que J determina a C, si cada valor de J tiene asociado siempre un <nico
valor de C.
El hecho de que J determine a C no quiere decir que conociendo J se pueda conocer C, sino que
en la relacin indicada, cada vez que el atributo J tome un determinado valor, el atributo C en la misma
tupla siempre tendr$ el mismo valor.
,or ejemplo, si tenemos una relacin con clientes de un hotel, y dos de sus atributos son el n<mero
de cliente y su nombre, podemos afirmar que el nombre tiene una dependencia funcional del n<mero de
cliente. Es decir, cada vez que en una tupla aparezca determinado valor de n<mero de cliente, es seguro
que el nombre de cliente ser$ siempre el mismo.
La dependencia funcional se representa como J 9K C.
El smbolo 9K se lee como ;implica; o ;determina;, y la dependencia anterior se lee como X
implica Y o X determina Y.
,odemos a(adir otro smbolo a nuestra $lgebra de dependencias el smbolo | significa negacin.
As X -> |Y se lee como X no determina Y.
@&
%epen-en)i+ (0n)ion+l )omple*+
%e(ini)in: En una dependencia funcional J 9K C, cuando J es un conjunto de atributos, decimos
que la dependencia funcional es completa , si slo depende de J, y no de ning<n subconjunto de J.
La dependencia funcional se representa como X => Y.
%epen-e)i+ (0n)ion+l elemen*+l
%e(ini)in: !i tenemos una dependencia completa J LK C, diremos que es una dependencia
funcional elemental si C es un atributo, y no un conjunto de ellos.
Estas son las dependencias que buscaremos en nuestras relaciones. Las dependencias funcionales
elementales son un caso particular de las dependencias completas.
%epen-e)i+ (0n)ion+l *ri1i+l
%e(ini)in: 3na dependencia funcional A -> B es trivial cuando 0 es parte de A. Esto sucede
cuando A es un conjunto de atributos, y 0 es a su vez un subconjunto de A.
4.2 Primera y segunda forma normal.
Formas normales.
!on las t-cnicas para prevenir las anomalas en las tablas. *ependiendo de su estructura, una tabla
puede estar en primera forma normal, segunda forma normal o en cualquier otra.
)elacin entre las formas normales
@@
Primera forma normal.
Definicin formal:
3na relacin ) se encuentra en 78. si y solo s por cada rengln y columna contiene valores atmicos.
Abreviada como 78., se considera que una relacin se encuentra en la primera forma normal
cuando cumple lo siguiente
a. Las celdas de las tablas poseen valores simples y no se permiten grupos ni arreglos repetidos como
valores, es decir, contienen un solo valor por cada celda.
b. >odos los ingresos en cualquier columna ?atributo: deben ser del mismo tipo.
c. "ada columna debe tener un nombre <nico, el orden de las columnas en la tabla no es importante.
d. *os filas o renglones de una misma tabla no deben ser id-nticas, aunque el orden de las filas no es
importante.
,or lo general la mayora de las relaciones cumplen con estas caractersticas, as que podemos
decir que la mayora de las relaciones se encuentran en la primera forma normal.
,ara ejemplificar como se representa gr$ficamente las relaciones en primera forma normal
consideremos la relacin alumno cursa materia cuyo diagrama E9) es el siguiente
@M
"omo esta relacin maneja valores atmicos, es decir un solo valor por cada uno de los campos que
conforman a los atributos de las entidades, ya se encuentra en primera forma normal, gr$ficamente as
representamos a las relaciones en 78..
Segunda forma normal (2FN)
%e(ini)in: ,ara que una base de datos sea I8. primero debe ser 78., y adem$s todas las
columnas que formen parte de una clave candidata deben aportar informacin sobre la clave completa.
La segunda forma normal se representa por dependencias funcionales como
.tese que las llaves primarias est$n representadas con doble cuadro, las flechas nos indican
que de estos atributos se puede referenciar a los otros atributos que dependen funcionalmente de la llave
primaria.
Esta regla significa que en una relacin slo se debe almacenar informacin sobre un tipo de
entidad, y se traduce en que los atributos que no aporten informacin directa sobre la clave principal
deben almacenarse en una relacin separada.
Lo primero que necesitamos para aplicar esta forma normal es identificar las claves candidatas.
Adem$s, podemos elegir una clave principal, que abreviaremos como P2, las iniciales de ,rimary Ney.
,ero esto es optativo, el modelo relacional no obliga a elegir una clave principal para cada relacin, sino
tan slo a la e#istencia de al menos una clave candidata.
La ine#istencia de claves candidatas implica que la relacin no cumple todas las normas para ser
parte de una base de datos relacional, ya que la no e#istencia de claves implica la repeticin de tuplas. En
general, si no e#iste un candidato claro para la clave principal, crearemos una columna especfica con ese
propsito.
%eamos cmo aplicar esta regla usando un ejemplo. En este caso trataremos de guardar datos
relacionados con la administracin de un hotel. ,lanteemos, por ejemplo, este esquema de relacin
@O
O)0p+)in?.oFcliente, .ombreFcliente, .oFhabitacin, precioFnoche, tipoFhabitacin,
fechaFentrada:
Lo primero que tenemos que hacer es buscar las posibles claves candidatas. En este caso slo
e#iste una posibilidad
?.oFhabitacin, fechaFentrada:
)ecordemos que cualquier clave candidata debe identificar de forma unvoca una clave completa.
En este caso, la clave completa es la ocupacin de una habitacin, que se define por dos par$metros la
habitacin y la fecha de la ocupacin.
Es decir, dos ocupaciones son diferentes si cambian cualquiera de estos par$metros. La misma
persona puede ocupar varias habitaciones al mismo tiempo o la misma habitacin durante varios das o en
diferentes periodos de tiempo. Lo que no es posible es que varias personas ocupen la misma habitacin al
mismo tiempo ?salvo que se trate de un acompa(ante, pero en ese caso, slo una de las personas es la
titular de la ocupacin:.
El siguiente paso consiste en buscar columnas que no aporten informacin directa sobre la clave
completa la ocupacin. En este caso el precio por noche de la habitacin y el tipo de habitacin ?es decir,
si es doble o sencilla:, no aportan informacin sobre la clave principal. En realidad, estos datos no son
atributos de la ocupacin de la habitacin, sino de la propia habitacin.
El n<mero de cliente y su nombre aportan datos sobre la ocupacin, aunque no formen parte de la
clave completa. E#presado en forma de dependencias se ve muy claro
?.oFhabitacin, fechaFentrada: 9K .oFcliente
(No_habitacin, fecha_entrada) -> Nombre_cliente
No_habitacin -> precio_noche
No_habitacin -> tipo_habitacin
@'
El <ltimo paso consiste en e#traer los atributos que no forman parte de la clave a otra relacin. En
nuestro ejemplo tendremos dos relaciones una para las ocupaciones y otra para las habitaciones
O)0p+)in?.oFcliente, .ombreFcliente, .oFhabitacin, fechaFentrada(P2":
3+.i*+)in?.oFhabitacin, precioFnoche, tipoFhabitacin:
La segunda tabla tiene una <nica clave candidata, que es el n<mero de habitacin. El resto de los
atributos no forman parte de la clave completa ?la habitacin:, pero aportan informacin slo y
e#clusivamente sobre ella.
Estas dos relaciones est$n interrelacionadas por la clave de habitacin. ,ara facilitar el
establecimiento de esta interrelacin elegiremos la clave candidata de la habitacin en clave principal. El
mismo atributo en la relacin de ocupaciones es, por lo tanto, una clave for$nea
O)0p+)in?.oFcliente, .ombreFcliente, .oFhabitacin, fechaFentrada(P2":
3+.i*+)in?.oFhabitacin(P2", precioFnoche, tipoFhabitacin:
"omo norma general debemos volver a aplicar la primera y segunda forma normal a estas nuevas
tablas. La primera slo en el caso de que hallamos a(adido nuevas columnas, la segunda siempre.
La interrelacin que hemos establecido es del tipo uno a muchos, podemos elegir una clave de
habitacin muchas veces, tantas como veces se ocupe esa habitacin.
4.3 ercera forma normal y la forma normal de !oyce "odd.
Dependencia funcional transitiva
%e(ini)in: !upongamos que tenemos una relacin con tres conjuntos de atributos J, C y P, y las
siguientes dependencias X -> Y, Y -> Z, Y -> |X. Es decir J determina C e C determina P, pero C
no determina J. En ese caso, decimos que P tiene dependencia transitiva con respecto a J, a trav-s de C.
5ntentaremos aclarar este concepto tan terico con un ejemplo. !i tenemos esta relacin
Ci0-+-es?ciudad, poblacin, superficie, renta, pas, continente:
@2
Los atributos como poblacin, superficie o renta tienen dependencia funcional de ciudad, as que
de momento no nos preocupan.
En esta relacin podemos encontrar tambi-n las siguientes dependencias
ciudad 9K pas, pa! -> continente. Adem$s, pa! -> |ci"dad. Es decir, cada ciudad
pertenece a un pas y cada pas a un continente, pero en cada pas puede haber muchas ciudades. En este
caso continente tiene una dependencia funcional transitiva con respecto a ciudad, a trav-s de pas. Es
decir, cada ciudad est$ en un pas, pero tambi-n en un continente. ?Q/joR las dependencias transitivas no
son siempre tan evidentes 9:.
,ara definir formalmente la 48. necesitamos definir dependencia transitiva: En una afinidad
?tabla bidimensional: que tiene por lo menos 4 atributos ?A,0,": en donde A determina a 0, 0 determina
a " pero no determina a A.
ercera forma normal 3#N
La tercera forma normal consiste en eliminar las dependencias transitivas.
%e(ini)in: 3na base de datos est$ en 48. si est$ en I8. y adem$s todas las columnas que no
sean claves dependen de la clave completa de forma no transitiva.
"onsiste en eliminar la dependencia transitiva que queda en una segunda forma normal, en pocas
palabras una relacin esta en tercera forma normal si est$ en segunda forma normal y no e#isten
dependencias transitivas entre los atributos, nos referimos a dependencias transitivas cuando e#iste m$s de
una forma de llegar a referencias a un atributo de una relacin.
,ero esto es una definicin demasiado terica. En la pr$ctica significa que se debe eliminar
cualquier relacin que permita llegar a un mismo dato de dos o m$s formas diferentes.
>omemos el ejemplo que usamos para ilustrar las dependencias funcionales transitivas. >enemos
una tabla donde se almacenen datos relativos a ciudades, y una de las columnas sea el pas y otra el
continente al que pertenecen. ,or ejemplo
Ci0-+-es?5*Fciudad(P2", .ombre, poblacin, superficie, renta, pas, continente:
MA
3n conjunto de datos podra ser el siguiente
Ci0-+-es
5*Fciudad .ombre poblacin superficie renta pas continente
7 ,aris MAAAAAA 7@ 7'AA 8rancia Europa
I Lion 4@AAAAA 2 7MAA 8rancia Europa
4 0erlin O@AAAAA 7M 72AA Alemania Europa
& ,eSin 72AAAAAA 4M @@A "hina Asia
@ 0onn MAAAAAA 7I 72AA Alemania Europa
,odemos ver que para cada aparicin de un determinado pas, el continente siempre es el mismo.
Es decir, e#iste una redundancia de datos, y por lo tanto, un peligro de integridad. E#iste una relacin
entre pas y continente, y ninguna de ellas es clave candidata. ,or lo tanto, si queremos que esta table sea
48. debemos separar esa columna
Ci0-+-es?5*Fciudad(P2", .ombre, poblacin, superficie, renta, nombreFpais:
P+ises?nombreFpais(P2", nombreFcontinente:
Ci0-+-es
5*Fciudad .ombre poblacin superficie renta pas
7 ,aris MAAAAAA 7@ 7'AA 8rancia
I Lion 4@AAAAA 2 7MAA 8rancia
4 0erlin O@AAAAA 7M 72AA Alemania
& ,eSin 72AAAAAA 4M @@A "hina
@ 0onn MAAAAAA 7I 72AA Alemania
P+ises
,as continente
8rancia Europa
Alemania Europa
"hina Asia
Esta separacin tendra m$s sentido si la tabla de paises contuviese m$s informacin, tal como est$
no tiene mucho sentido separar estas tablas, aunque efectivamente, se evita redundancia.
/tro ejemplo, consideremos el siguiente caso
M7

>enemos la relacin alumno9cursa9materia manejada anteriormente, pero ahora consideramos al
elemento maestro, gr$ficamente lo podemos representar de la siguiente manera

,odemos darnos cuenta que se encuentra graficado en segunda forma normal, es decir que todos
los atributos llave est$n indicados en doble cuadro indicando los atributos que dependen de dichas llaves,
sin embargo en la llave .econo tiene como dependientes a 4 atributos en el cual el nombre puede ser
referenciado por dos atributos .econo y )8" ?E#iste dependencia transitiva:, podemos solucionar esto
aplicando la tercera forma normal que consiste en eliminar estas dependencias separando los atributos,
entonces tenemos
MI
#orma Normal de !oycce y "odd $#N!"%
Determinante: 3no o m$s atributos que, de manera funcional, determinan otro atributo o
atributos. En la dependencia funcional ?A,0:99K", ?A,0: son los determinantes.
Definicin formal:
%e(ini)in: 3na relacin est$ en 8.0" si cualquier atributo slo facilita informacin sobre claves
candidatas, y no sobre atributos que no formen parte de ninguna clave candidata. Esto significa que no
deben e#istir interrelaciones entre atributos fuera de las claves candidatas. ,ara ilustrar esta forma normal
volvamos a uno de nuestros ejemplos anteriores, el de las ocupaciones de habitaciones de un hotel.
O)0p+)in?.oFcliente, .ombreFcliente, .oFhabitacin, fechaFentrada:
3+.i*+)in?.oFhabitacin(P2", precioFnoche, tipoFhabitacin:
En la primera relacin los atributos .oFcliente y .ombreFcliente slo proporcionan informacin
entre ellos mutuamente, pero ninguno de ellos es una clave candidata.
5ntuitivamente ya habremos visto que esta estructura puede producir redundancia, sobre todo en el
caso de clientes habituales, donde se repetir$ la misma informacin cada vez que el mismo cliente se aloje
en el hotel. La solucin, como siempre, es simple, y consiste en separar esta relacin en dos diferentes
O)0p+)in?.oFcliente, .oFhabitacin, fechaFentrada:
Clien*e?.oFcliente(P2", .ombreFcliente:
M4
3+.i*+)in?.oFhabitacin(P2", precioFnoche, tipoFhabitacin:
Otro ejemplo.
"ontinuando con el ejemplo anterior, si consideramos que en la entidad alumno sus atributos
control y nombre nos puede hacer referencia al atributos esp., entonces decimos que dichos atributos
pueden ser llaves candidato. Tr$ficamente podemos representar la forma normal de 0oyce "odd de la
siguiente forma

/bs-rvese que a diferencia de la tercera forma normal, agrupamos todas las llaves candidato para
formar una global ?representadas en el recuadro: las cuales hacen referencia a los atributo que no son
llaves candidato.
&tributos multi'aluados
%e(ini)in: se dice que un atributo es multivaluado cuando para una misma entidad puede tomar
varios valores diferentes, con independencia de los valores que puedan tomar el resto de los atributos.
!e representa como J 9K9K C, y se lee como X multidetermina Y.
3n ejemplo claro es una relacin donde almacenemos contactos y n<meros de tel-fono
A,en-+?nombre, fechaFnacimiento, estadoFcivil, tel-fono:
,ara cada nombre de la agenda tendremos, en general, varios n<meros de telfono, es decir, que
nombre multidetermina telfono nombre 9K9K tel-fono. Adem$s, nombre determina funcionalmente otros
atributos, como la fecha_nacimiento o estado_civil. ,or otra parte, la clave candidata no es el nombre, ya
que debe ser unvoca, por lo tanto debe ser una combinacin de nombre y tel-fono.
M&
En esta relacin tenemos las siguientes dependencias
a. nombre 9K fechaFnacimiento
b. nombre 9K estadoFcivil
c. nombre 9K9K tel-fono, o lo que es lo mismo ?nombre,tel-fono: 9K tel-fono
Es decir, la dependencia multivaluada se convierte, de hecho, en una dependencia funcional trivial.
Este tipo de atributos implica redundancia ya que el resto de los atributos se repiten tantas veces como
valores diferentes tenga el atributo multivaluado
A,en-+
nombre fechaFnacimiento estadoFcivil tel-fono
1engano 7@+7I+72'@ soltero 7I4II74I
8ulano 74+AI+72MA casado 744I7I4I
8ulano 74+AI+72MA casado I@@M@&&@
8ulano 74+AI+72MA casado 4MM4@4M4
>ulana I&+AM+72O@ soltera &@MM@&@M
!iempre podemos evitar el problema de los atributos multivaluados separandolos en relaciones
distintas. En el ejemplo anterior, podemos crear una segunda relacin que contenga el nombre y el
tel-fono
A,en-+?nombre(P2", fechaFnacimiento, estadoFcivil:
&el4(onos?nombre, tel-fono(P2":
,ara los datos anteriores, las tablas quedaran as
A,en-+
nombre fechaFnacimiento estadoFcivil
1engano 7@+7I+72'@ soltero
8ulano 74+AI+72MA casado
>ulana I&+AM+72O@ soltera
&el4(onos
nombre tel-fono
1engano 7I4II74I
8ulano 744I7I4I
8ulano I@@M@&&@
8ulano 4MM4@4M4
>ulana &@MM@&@M
M@
Dependencias multi'aluadas
!i e#iste m$s de un atributo multivaluado es cuando se presentan dependencias multivaluadas.
%e(ini)in: en una relacin con los atributos J, C y P e#iste una dependencia multivaludada de C
con respecto a J si los posibles valores de C para un par de valores de J y P dependen <nicamente del
valor de J.
!upongamos que en nuestra relacin anterior de A,en-+ a(adimos otro atributo para guardar
direcciones de correo electrnico. !e trata, por supuesto, de otro atributo multivaluado, ya que cada
persona puede tener m$s de una direccin de correo, y este atributo es independiente del n<mero de
tel-fono
A,en-+?nombre, fechaFnacimiento, estadoFcivil, tel-fono, correo:
Ahora surgen los problemas, supongamos que nuestro amigo ;8ulano;, adem$s de los tres
n<meros de tel-fono, dispone de dos direcciones de correo. B"mo almacenaremos la informacin
relativa a estos datosD >enemos muchas opciones
A,en-+
nombre fechaFnacimiento estadoFcivil tel-fono correo
8ulano 74+AI+72MA casado 744I7I4I fulanoEsucasa.eSo
8ulano 74+AI+72MA casado I@@M@&&@ fulanoEsutrabajo.aSa
8ulano 74+AI+72MA casado 4MM4@4M4 fulanoEsucasa.eSo
!i optamos por crear tres tuplas, ya que hay tres tel-fonos, y emparejar cada direccin con un
tel-fono, en la tercera tupla estaremos obligados a repetir una direccin. /tra opcin sera usar un NULL
en esa tercera tupla.
A,en-+
nombre fechaFnacimiento estadoFcivil tel-fono correo
8ulano 74+AI+72MA casado 744I7I4I fulanoEsucasa.eSo
8ulano 74+AI+72MA casado I@@M@&&@ fulanoEsutrabajo.aSa
8ulano 74+AI+72MA casado 4MM4@4M4 .3LL
,ero estas opciones ocultan el hecho de que ambos atributos son multivaluados e independientes
entre si. ,odra parecer que e#iste una relacin entre los n<meros y las direcciones de correo.
5ntentemos pensar en otras soluciones
A,en-+
MM
nombre fechaFnacimiento estadoFcivil tel-fono correo
8ulano 74+AI+72MA casado 744I7I4I fulanoEsucasa.eSo
8ulano 74+AI+72MA casado I@@M@&&@ fulanoEsucasa.aSa
8ulano 74+AI+72MA casado 4MM4@4M4 fulanoEsucasa.eSo
8ulano 74+AI+72MA casado 744I7I4I fulanoEsutrabajo.eSo
8ulano 74+AI+72MA casado I@@M@&&@ fulanoEsutrabajo.aSa
8ulano 74+AI+72MA casado 4MM4@4M4 fulanoEsutrabajo.eSo
A,en-+
nombre fechaFnacimiento estadoFcivil tel-fono correo
8ulano 74+AI+72MA casado 744I7I4I .3LL
8ulano 74+AI+72MA casado I@@M@&&@ .3LL
8ulano 74+AI+72MA casado 4MM4@4M4 .3LL
8ulano 74+AI+72MA casado .3LL fulanoEsutrabajo.eSo
8ulano 74+AI+72MA casado .3LL fulanoEsucasa.eSo
Ahora est$ claro que los atributos son independientes, pero el precio es crear m$s tuplas para
guardar la misma informacin, es decir, mayor redundancia. ,ero no slo eso. Las operaciones de
insercin de nuevos datos, correccin o borrado se complican. .inguna de esas operaciones se puede
hacer modificando slo una tupla, y cuando eso sucede es posible que se produzcan inconsistencias.
4.4 "uarta y (uinta forma normal
Cuarta forma normal (4FN)
La cuarta forma normal tiene por objetivo eliminar las dependencias multivaluadas.
%e(ini)in: 3na relacin est$ en &.8 si y slo si, en cada dependencia multivaluada X ->-> Y
no trivial, J es clave candidata. 3na dependencia multivaluada A ->-> B es trivial cuando 0 es parte
de A. Esto sucede cuando A es un conjunto de atributos, y 0 es un subconjunto de A. >omemos por
ejemplo la tabla de Agenda, pero dejando slo los atributos multivaluados
A,en-+?nombre, tel-fono, correo:
Lo primero que debemos hacer es buscar las claves y las dependencias. )ecordemos que las claves
candidatas deben identificar de forma unvoca cada tupla. *e modo que estamos obligados a usar los tres
atributos para formar la clave candidata.
,ero las dependencias que tenemos son
MO
4 nombre 9K9K tel-fono
& nombre 9K9K correo
C nombre no es clave candidata de esta relacin.
)esumiendo, debemos separar esta relacin en varias ?tantas como atributos multivaluados tenga:.
&el4(onos?nombre, tel-fono:
Correos?nombre, correo:
Ahora en las dos relaciones se cumple la cuarta forma normal.
,ara entender mejor a<n esto consideremos una afinidad ?tabla: llamada estudiante que contiene
los siguientes atributos "lave, Especialidad, "urso tal y como se demuestra en la siguiente figura
Cl+1e Espe)i+li-+- C0rso
!A7 !istemas .atacin
!A7 0ioqumica *anza
!A7 !istemas .atacin
0A7 0ioqumica Tuitarra
"A4 "ivil .atacin
!uponemos que los estudiantes pueden inscribirse en varias especialidades y en diversos cursos. El
estudiante con clave !A7 tiene su especialidad en sistemas y 0ioqumica y toma los cursos de .atacin y
danza, el estudiante 0A7 tiene la especialidad en 0ioqumica y toma el curso de Tuitarra, el estudiante
con clave "A4 tiene la especialidad de "ivil y toma el curso de natacin.
En esta tabla o relacin no e#iste dependencia funcional porque los estudiantes pueden tener
distintas especialidades, un valor <nico de clave puede poseer muchos valores de especialidades al igual
que de valores de cursos. ,or lo tanto e#iste dependencia de valores mltiples. Este tipo de
dependencias produce redundancia de datos, como se puede apreciar en la tabla anterior, en donde la
clave !A7 tiene tres registros para mantener la serie de datos en forma independiente lo cual ocasiona que
al realizarse una actualizacin se requiera de demasiadas operaciones para tal fin.
M'
E#iste una dependencia de valores m<ltiples cuando una afinidad tiene por lo menos tres atributos,
dos de los cuales poseen valores m<ltiples y sus valores dependen solo del tercer atributo, en otras
palabras en la afinidad ) ?A,0,": e#iste una dependencia de valores m<ltiples si A determina valores
m<ltiples de 0, A determina valores m<ltiples de ", y 0 y " son independientes entre s.
En la tabla anterior "lave determina valores m<ltiples de especialidad y clave determina valores
m<ltiples de curso, pero especialidad y curso son independientes entre s. Las dependencias de valores
m<ltiples se definen de la siguiente manera "lave 9K9KEspecialidad y "lave9K9K"urso= Esto se lee ;"lave
multidetrmina a Especialidad, y clave multidetermina a "urso;
,ara eliminar la redundancia de los datos, se deben eliminar las 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.
,ara nuestro ejemplo, las tablas correspondientes son
>abla Eespecialidad
Cl+1e Espe)i+li-+-
!A7
!istemas
0A7
0ioqumica
"A4
"ivil
>abla E"urso
Cl+1e C0rso
!A7 .atacin
!A7 *anza
0A7 Tuitarra
"A4 .atacin

)uinta forma normal.
Definicin formal:
M2
3n esquema de relaciones ) est$ en @8. con respecto a un conjunto * de dependencias
funcionales, de valores m<ltiples y de producto, si para todas las dependencias de productos en * se
cumple por lo menos una de estas condiciones
U ?)7, )I, )4, ... )n: es una dependencia de producto trivial.
U >oda )i es una superllave de ).
La quinta forma normal se refiere a dependencias que son e#tra(as. >iene que ver con tablas que
pueden dividirse en subtablas, pero que no pueden reconstruirse.
Ejemplo 1
Aplicaremos ahora la normalizacin a las relaciones que obtuvimos en el captulo anterior. En el
caso del primer ejemplo, para almacenar informacin sobre estaciones meteorolgicas y las muestras
tomadas por ellas, habamos llegado a esta estructura
Es*+)in?5dentificador, Latitud, Longitud, Altitud:
M0es*r+?5dentificadorEstacion, 8echa, >emperatura mnima, >emperatura m$#ima,
,recipitaciones, Gumedad mnima, Gumedad m$#ima, %elocidad del viento mnima,
%elocidad del viento m$#ima:
Primera forma normal
Esta forma nos dice que todos los atributos deben ser atmicos. Ca comentamos antes que este
criterio es en cierto modo relativo, lo que desde un punto de vista puede ser atmico, puede no serlo desde
otro.
En lo que respecta a la relacin stacin, el 5dentificador y la Altitud son claramente atmicos.
!in embargo, la Latitud y Longitud pueden considerarse desde dos puntos de vista. En uno son
coordenadas ?de hecho, podramos haber considerado la posicin como atmica, y fundir ambos atributos
en uno:. A pesar de que ambos valores se e#presen en grados, minutos y segundos, m$s una orientacin,
norte, sur, este u oeste, puede hacernos pensar que podemos dividir ambos atributos en partes m$s
simples.
OA
Esta es, desde luego, una opcin. ,ero todo depende del uso que le vayamos a dar a estos datos. ,ara
nuestra aplicacin podemos considerar como atmicos estos dos atributos tal como los hemos definido.
,ara la relacin !uestras todos los atributos seleccionados son atmicos.
*egunda forma normal
,ara que una base de datos sea I8. primero debe ser 78., y adem$s todas las columnas que
formen parte de una clave candidata deben aportar informacin sobre la clave completa. ,ara la relacin
stacin e#isten dos claves candidatas identificador y la formada por la combinacin de Latitud y
Longitud.
Gay que tener en cuenta que hemos creado el atributo 5dentificador slo para ser usado como clave
principal. Las dependencias son
5dentificador 9K ?Latitud, Longitud:
5dentificador 9K Altitud
En estas dependencias, las claves candidatas 5dentificador y ?Latitud, Longitud: son equivalentes
y, por lo tanto, intercambiables. Esta relacin se ajusta a la segunda forma normal, veamos la de
!uestras.
En esta relacin la clave principal es la combinacin de ?5dentificador, 8echa:, y el resto de los
atributos son dependencias funcionales de esta clave. ,or lo tanto, tambi-n esta relacin est$ en I8..
ercera forma normal
3na base de datos est$ en 48. si est$ en I8. y adem$s todas las columnas que no sean claves dependen
de la clave completa de forma no transitiva. .o e#isten dependencias transitivas, de modo que podemos
afirmar que nuestra base de datos est$ en 48..
#orma normal de !oyce+"odd
3na relacin est$ en 8.0" si cualquier atributo slo facilita informacin sobre claves candidatas,
y no sobre atributos que no formen parte de ninguna clave candidata. >ampoco e#isten atributos que den
informacin sobre otros atributos que no sean o formen parte de claves candidatas.
O7
"uarta forma normal
Esta forma se refiere a atributos multivaluados, que no e#isten en nuestras relaciones, por lo tanto,
tambi-n podemos considerar que nuestra base de datos est$ en &8..
Ejemplo 2
.uestro segundo ejemplo se modela una biblioteca, y su esquema de relaciones final es este
Li.ro?"laveLibro, >tulo, 5dioma, 8ormato, "ategora, "laveEditorial:
&em+?"lave>ema, .ombre:
A0*or?"laveAutor, .ombre:
E-i*ori+l?"laveEditorial, .ombre, *ireccin, >el-fono:
Ejempl+r?"laveLibro, .<mero/rden, Edicin, 3bicacin:
So)io?"lave!ocio, .ombre, *ireccin, >el-fono, "ategora:
Pr4s*+mo?"lave!ocio, "laveLibro, .<mero/rden, 8echaFpr-stamo,
8echaFdevolucin, .otas:
&r+*+5so.re?"laveLibro, "lave>ema:
Es)ri*o5por?"laveLibro, "laveAutor:
Los ejemplos que estamos siguiendo desde el captulo I demuestran que un buen dise(o
conceptual sirve para dise(ar bases de datos relacionales libres de redundancias, y generalmente, la
normalizacin no afecta a su estructura. Este ha sido el caso del primer ejemplo, y como veremos,
tambi-n del segundo.
Primera forma normal
>enemos, desde luego, algunos atributos que podemos considerar no atmicos, como el nombre
del autor, la direccin de la editorial, el nombre del socio y su direccin. "omo siempre, dividir estos
atributos en otros es una decisin de dise(o, que depender$ del uso que se le vaya a dar a estos datos. En
nuestro caso, seguramente sea suficiente dejarlos tal como est$n, pero dividir algunos de ellos no afecta
demasiado a las relaciones.
OI
*egunda forma normal
,ara que una base de datos sea I8. primero debe ser 78., y adem$s todas las columnas que formen parte
de una clave candidata deben aportar informacin sobre la clave completa.
En el caso de Libro, la <nica clave candidata es "laveLibro. >odos los dem$s valores son
repetibles, pueden e#istir libros con el mismo ttulo y de la misma editorial editados en el mismo formato
e idioma y que englobemos en la misma categora. Es decir, no e#iste ning<n otro atributo o conjunto de
atributos que puedan identificar un libro de forma unvoca.
!e pueden dar casos especiales, como el del mismo libro escrito en diferentes idiomas. En ese caso
la clave ser$ diferente, de modo que los consideraremos como libros distintos. Lo mismo pasa si el mismo
libro aparece en varios formatos, o ha sido editado por distintas editoriales. Es decir, todos los atributos
son dependencias funcionales de "laveLibro.
"on "ema y #utor no hay dudas, slo tienen dos atributos, y uno de ellos ha sido creado
especficamente para ser usado como clave. Los tres atributos de ditorial tambi-n tienen dependencia
funcional de "laveEditorial. C lo mismo cabe decir para las entidades $emplar, %ocio y &rstamo. En
cuanto a las relaciones que almacenan interrelaciones, la clave es el conjunto de todos los atributos, de
modo que todas las dependencias son funcionales y triviales.
ercera forma normal
3na base de datos est$ en 48. si est$ en I8. y adem$s todas las columnas que no sean claves
dependen de la clave completa de forma no transitiva. En Libro no hay ning<n atributo que tenga
dependencia funcional de otro atributo que no sea la clave principal. >odos los atributos defienen a la
entidad Libro y a ninguna otra.
Las entidades con slo dos atributos no pueden tener dependencias transitivas, como "ema o
#utor. "on ditorial tampoco e#isten, todos los atributos dependen e#clusivamente de la clave principal.
En el caso del $emplar tampoco hay una correspondencia entre ubicacin y edicin. / al menos
no podemos afirmar que e#ista una norma universal para esta correspondencia. Es posible que todas las
O4
primeras ediciones se guarden en el mismo sitio, pero esto no puede ser una condicin de dise(o para la
base de datos. C para &rstamo los tres atributos que no forman parte de la clave candidata se refieren
slo a la entidad &rstamo.
#orma normal de !oyce+"odd
3na relacin est$ en 8.0" si cualquier atributo slo facilita informacin sobre claves candidatas,
y no sobre atributos que no formen parte de ninguna clave candidata.
>ampoco e#isten atributos que den informacin sobre otros atributos que no sean o formen parte
de claves candidatas.
"uarta forma normal
.o hay atributos multivaluados. / mejor dicho, los que haba ya se convirtieron en entidades
cuando dise(amos el modelo E9).
Ejemplo 3
La normalizacin ser$ mucho m$s <til cuando nuestro dise(o arranque directamente en el modelo
relacional, es decir, cuando no arranquemos de un modelo E9). !i no somos cuidadosos podemos
introducir relaciones con m$s de una entidad, dependencias transitivas o atributos multivaluados.
O&