Base de Datos I Ingeniera de Sistemas

Sesin 12
Otras Formas de Normalizacin de
Datos

Ing. Victor Hugo Tapia Jacinto Pag. 106

Base de Datos I Ingeniera de Sistemas

Forma Normal de Boyce-Cood

La Forma Normal de Boyce-Codd (o FNBC) es una forma normal utilizada en la normalizacin de

bases de datos. Es una versin ligeramente ms fuerte de la Tercera forma normal (3FN). La forma
normal de Boyce-Codd requiere que no existan dependencias funcionales no triviales de los
atributos que no sean un conjunto de la clave candidata. En una tabla en 3FN, todos los atributos
dependen de una clave, de la clave completa y de ninguna otra cosa excepto de la clave
(excluyendo dependencias triviales, como ). Se dice que una tabla est en FNBC si y solo
si est en 3FN y cada dependencia funcional no trivial tiene una clave candidata
como determinante. En trminos menos formales, una tabla est en FNBC si est en 3FN y los
nicos determinantes son claves candidatas.

Ejemplo:

Consideremos una empresa donde un trabajador puede trabajar en varios departamentos. En cada
departamento hay varios responsables, pero cada trabajador slo tiene asignado uno. Tendramos
una tabla con las columnas:

IDTrabajador, IDDepartamento, IDResponsable

La nica clave candidata es IDTrabajador (que ser por tanto la clave primaria).

Si aadimos la limitacin de que el responsable slo puede serlo de un departamento, este detalle
produce una dependencia funcional ya que: Responsable Departamento

Por lo tanto hemos encontrado un determinante (IDResponsable) que sin embargo no es clave
candidata. Por ello, esta tabla no est en FNBC. En este caso la redundancia ocurre por mala
seleccin de clave. La repeticin del par [IDDepartamento + IDResponsable] es innecesaria y
evitable.

Solamente en casos raros una tabla en 3NF no satisface los requerimientos de la FNBC. Un ejemplo
de tal tabla es (teniendo en cuenta que cada estudiante puede tener ms de un tutor):

Referencia cruzada de Tutor/Estudiante

ID Tutor Nmero de seguro social del tutor ID Estudiante
1078 088-51-0074 31850
1078 088-51-0074 37921
1293 096-77-4146 46224
1480 072-21-2223 31850

Ing. Victor Hugo Tapia Jacinto Pag. 107

Base de Datos I Ingeniera de Sistemas

El propsito de la tabla es mostrar qu tutores estn asignados a qu estudiantes. Las claves

candidatas de la tabla son:
{ID Tutor, ID Estudiante}
{Nmero de seguro social del tutor, ID Estudiante}

Otra Formulacin
Una forma sencilla de comprobar si una relacin se encuentra en FNBC consiste en comprobar,
adems de que est en 3FN, lo siguiente:
(1) Si no existen claves candidatas compuestas (con varios atributos), est en FNBC.
(2) Si existen varias claves candidatas compuestas y stas tienen un elemento comn, puede no
estar en FNBC. Slo si, para cada dependencia funcional en la relacin, el determinante es una
clave candidata, estar en FNBC.

Cuarta Forma Normal (4FN).

Un esquema de relaciones R est en 4FN con respecto a un conjunto D de dependencias

funcionales y de valores mltiples s, para todas las dependencias de valores mltiples en D de la
forma X Y, donde X<=R y Y<=R, se cumple por lo menos una de estas condiciones:

X Y es una dependencia de valores mltiples trivial.

X es una superllave del esquema R.

Para entender mejor an esto consideremos una afinidad (tabla) llamada estudiante que contiene
los siguientes atributos: Clave, Especialidad, Curso tal y como se demuestra en la siguiente figura:

Clave Especialidad Curso

S01 Sistemas Natacin

S01 Bioqumica Danza

S01 Sistemas Natacin

B01 Bioqumica Guitarra

C03 Civil Natacin

Suponemos que los estudiantes pueden inscribirse en varias especialidades y en diversos cursos. El
estudiante con clave S01 tiene su especialidad en sistemas y Bioqumica y toma los cursos de

Ing. Victor Hugo Tapia Jacinto Pag. 108

Base de Datos I Ingeniera de Sistemas

Natacin y danza, el estudiante B01 tiene la especialidad en Bioqumica y toma el curso de

Guitarra, el estudiante con clave C03 tiene la especialidad de Civil y toma el curso de natacin.

En esta tabla o relacin no existe 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. Por lo tanto existe dependencia de valores mltiples. Este tipo de
dependencias produce redundancia de datos, como se puede apreciar en la tabla anterior, en
donde la clave S01 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.

Existe una dependencia de valores mltiples cuando una afinidad tiene por lo menos tres
atributos, dos de los cuales poseen valores mltiples y sus valores dependen solo del tercer
atributo, en otras palabras en la afinidad R (A,B,C) existe una dependencia de valores mltiples si
A determina valores mltiples de B, A determina valores mltiples de C, y B y C son
independientes entre s.

En la tabla anterior Clave determina valores mltiples de especialidad y clave determina valores
mltiples de curso, pero especialidad y curso son independientes entre s.

Las dependencias de valores mltiples se definen de la siguiente manera: Clave Especialidad y

Clave Curso; Esto se lee Clave multidetrmina a Especialidad, y clave multidetermina a Curso

Para eliminar la redundancia de los datos, se deben eliminar las dependencias de valores
mltiples. Esto se logra construyendo dos tablas, donde cada una almacena datos para solamente
uno de los atributos de valores mltiples.

Para nuestro ejemplo, las tablas correspondientes son:

Tabla Especialidad Tabla Curso

Clave Especialidad Clave Curso

S01 Sistemas S01 Natacin

B01 Bioqumica S01 Danza

C03 Civil B01 Guitarra

C03 Natacin

Ing. Victor Hugo Tapia Jacinto Pag. 109

Base de Datos I Ingeniera de Sistemas

Forma Normal de Dominio/Clave

La forma normal de dominio/clave (DKNF) es una forma normal usada en normalizacin de

bases de datos que requiere que la base de datos contenga restricciones de dominios y de claves.

Una restriccin del dominio especifica los valores permitidos para un atributo dado, mientras que
una restriccin clave especifica los atributos que identifican nicamente una fila en una tabla dada.

Esta es el santo grial de la Base de datos y es alcanzado cuando cada restriccin en la relacin es
una consecuencia lgica de la definicin de claves y dominios, y, haciendo cumplir las
restricciones y condiciones de la clave y del dominio, causa que sean satisfechas todas las
restricciones. As, esto evita todas las anomalas no-temporales.

Es mucho ms fcil construir una base de datos en forma normal de dominio/clave que convertir
pequeas bases de datos que puedan contener numerosas anomalas. Sin embargo, construir con
xito una base de datos en forma normal de dominio/clave sigue siendo una tarea difcil, incluso
para programadores experimentados de bases de datos. As, mientras que la forma normal de
dominio/clave elimina los problemas encontrados en la mayora de las bases de datos, tiende para
ser la forma normal ms costosa de alcanzar. Sin embargo, el no poder alcanzar la forma normal de
dominio/clave puede llevar costos ocultos a largo plazo, debido a anomalas que aparecen con el
tiempo en las bases de datos que solamente se adhieren a formas normales ms bajas.

Una violacin de DKNF ocurre en la siguiente tabla:

Persona rica

DNI Persona rica Tipo de persona rica Valor neto en dlares

123 Millonario excntrico 124,543,621

456 Multimillonario malvado 6,553,228,893

789 Multimillonario excntrico 8,829,462,998

012 Millonario malvado 495,565,211

Asuma que el dominio para la 'DNI Persona rica consiste en los DNI's de toda la gente rica en una
muestra predefinida de gente rica; el dominio para el Tipo de persona rica consiste de los valores
'Millonario excntrico', 'Multimillonario excntrico', 'Millonario malvado', y 'Multimillonario

Ing. Victor Hugo Tapia Jacinto Pag. 110

Base de Datos I Ingeniera de Sistemas

malvado'; y el dominio para el Valor neto en dlares consiste de todos los nmeros enteros mayor
que o igual a 1.000.000.

Hay una restriccin que liga el Tipo de persona rica al Valor neto en dlares, incluso aunque no
podamos deducir uno del otro. La restriccin dicta que un Millonario excntrico o Millonario
malvado tendr un valor neto de 1.000.000 a 999.999.999 inclusive, mientras que un Multimillonario
excntrico o un Multimillonario malvado tendr un valor neto de 1.000.000.000 o ms. Esta restriccin
no es ni una restriccin de dominio ni una restriccin de clave; por lo tanto no podemos confiar en
las restricciones de dominio y las de clave para garantizar que una combinacin de anmala
de Tipo de persona rica / Valor neto en dlares no tenga cabida en la base de datos.

La violacin de la DKNF podra ser eliminada alterando dominio Tipo de persona rica para hacer
que sea consistente con solo dos valores, 'Malvado' y 'Excntrico' (el estatus de persona rica como
un millonario o un multimillonario es implcito en su Valor neto en dlares, as que no se pierde
ninguna informacin til).

DKNF es frecuentemente difcil de alcanzar en la prctica.

Quinta Forma Normal

La quinta forma normal (5FN), tambin conocida como forma normal de proyeccin-
unin (PJ/NF), es un nivel de normalizacin de bases de datos diseado para reducir redundancia
en las bases de datos relacionales que guardan hechos multi-valores
aislando semnticamente relaciones mltiples relacionadas. Una tabla se dice que est en 5NF si y
slo si est en 4NF y cada dependencia de unin (join) en ella es implicada por las claves
candidatas.

Ejemplo:

Considere el siguiente ejemplo:

Psiquiatra-para-Asegurador-para-Condicin

Psiquiatra Asegurador Condicin

Dr. James Healthco Ansiedad

Dr. James Healthco Depresin

Dr. Kendrick FriendlyCare OCD

Dr. Kendrick FriendlyCare Ansiedad

Ing. Victor Hugo Tapia Jacinto Pag. 111

Base de Datos I Ingeniera de Sistemas

Dr. Kendrick FriendlyCare Depresin

Dr. Lowenstein FriendlyCare Esquizofrenia

Dr. Lowenstein Healthco Ansiedad

Dr. Lowenstein Healthco Demencia

Dr. Lowenstein Victorian Life Trastorno de conversin

El psiquiatra puede ofrecer tratamiento reembolsable a los pacientes que sufren de la condicin
dada y que son asegurados por el asegurador dado. En ausencia de cualquier regla que restrinja
las combinaciones vlidas posibles de psiquiatra, asegurador, y condicin, la tabla de tres
atributos Psiquiatra-para-Asegurador-para-Condicin es necesaria para modelar la situacin
correctamente.

Sin embargo, suponga que la regla siguiente se aplica:

Cuando un psiquiatra es autorizado a ofrecer el tratamiento reembolsable a los pacientes asegurados

por el asegurador P, y el psiquiatra puede tratar la condicin C, entonces - en caso que el asegurador
P cubra la condicin C - debe ser cierto que el psiquiatra puede ofrecer el tratamiento reembolsable a
los pacientes que sufren de la condicin C y estn asegurados por el asegurador P.

Con estas restricciones es posible dividir la relacin en tres partes.

Psiquiatra-para-Condicin

Psiquiatra Condicin

Dr. James Ansiedad

Psiquiatra-para-Asegurador
Dr. James Depresin
Psiquiatra Asegurador
Dr. Kendrick OCD
Dr. James Healthco
Dr. Kendrick Ansiedad
Dr. Kendrick FriendlyCare
Dr. Kendrick Depresin
Dr. Lowenstein FriendlyCare
Dr. Lowenstein Esquizofrenia
Dr. Lowenstein Healthco
Dr. Lowenstein Ansiedad
Dr. Lowenstein Victorian Life
Dr. Lowenstein Demencia

Dr. Lowenstein Trastorno de conversin

Ing. Victor Hugo Tapia Jacinto Pag. 112

Base de Datos I Ingeniera de Sistemas

Asegurador-para-Condicin

Asegurador Condicin

Healthco Ansiedad

Healthco Depresin

Healthco Demencia

FriendlyCare OCD

FriendlyCare Ansiedad

FriendlyCare Depresin

FriendlyCare Trastorno emocional

FriendlyCare Esquizofrenia

Victorian Life Trastorno de conversin

Note como esta disposicin ayuda a quitar redundancia. Suponga que el Dr. James se convierte en
un proveedor de tratamientos para FriendlyCare. En la disposicin anterior tendramos que
agregar dos nuevas entradas puesto que el Dr. James puede tratar dos condiciones cubiertas por
FriendlyCare: ansiedad y depresin. Con la nueva disposicin necesitamos agregar una sola
entrada (en la tabla Psiquiatra-para-Asegurador).

Uso

Solamente en contadas ocasiones una tabla 4NF no se corresponde con una 5NF. stas son
situaciones en las cuales una restriccin compleja del mundo real, que limita las combinaciones
vlidas de los valores de atributos en la tabla 4NF, no est implcita en la estructura de esa tabla. Si
esa tabla no se normaliza a 5NF, la tarea de mantener la consistencia lgica de los datos dentro de
la tabla debe ser llevada en parte por la aplicacin responsable de inserciones, borrados, y
actualizaciones a ella; y hay un riesgo elevado de que los datos dentro de la tabla se vuelvan
inconsistentes. Por el contrario, el diseo 5NF excluye la posibilidad de tales inconsistencias.

Ing. Victor Hugo Tapia Jacinto Pag. 113

Base de Datos I Ingeniera de Sistemas

Desnormalizacin

Hasta dnde hay que llegar? Es necesario llegar a quinta forma normal?

La principal ventaja de la normalizacin es que divide una gran tabla en tablas ms pequeas:
Pasamos de una tabla de 100 campos a 20 tablas de 5 campos cada una. Pero esto a la vez puede
generar un problema: La excesiva particin de las tablas y la aparicin de numerosas tablas que
dificulten el uso de la base de datos

Por eso nace el concepto de desnormalizacin: Volver atrs, asumiendo que nuestra solucin
puede generar redundancia, pero facilitando el uso de la base de datos.

A la hora de disear una base de datos es tan importante la normalizacin de la misma como la
facilidad de uso: Si una excesiva normalizacin complica la compresin y el uso de la base de
datos, es mejor dejarla en una forma normal anterior.

Ing. Victor Hugo Tapia Jacinto Pag. 114