Daeg 03 Bis

Diseño de las bases de datos relacionales
UNIDAD 3 DISEÑO DE LAS BASES DE DATOS RELACIONALES
3.1. Problemas que puede presentar el diseño de una base de datos relacional.
3.2. Teoría de la Normalización.
3.3. Dependencias funcionales:

- Dependencia funcional
- Dependencia funcional completa
- Dependencia funcional transitiva
- Diagrama de dependencias funcionales.
3.4. Primeras formas normales

- Primera formas normal
- Segunda forma normal
- Tercera forma normal.
3.5. Forma normal de Boyce-Codd
3.6. Dependencias Multievaluadas. Cuarta forma normal.
3.7. Dependencias de reunión. Quinta forma normal
3.8. Proceso de transformación de las relaciones a tercera forma normal.
Objetivos: Identificar los problemas que puede presentar un esquema de relación,

comprender los conceptos de dependencia funcional, multievaluada y de reunión, adquirir
los conocimientos sobre la optimización de las relaciones de la base de datos mediante la
normalización, eliminando las distintas anomalías que se pueden presentar al realizar las
operaciones de actualización de las relaciones.
Unidad 3 Página 1 de 18
3.1. PROBLEMAS QUE PUEDE PRESENTAR EL DISEÑO DE UNA BASE DE

DATOS RELACIONAL.
La información de nuestra base de datos puede representarse por medio de un conjunto
de objetos (dominios y relaciones) y de un conjunto de reglas de integridad.
En el modelo relacional, como en los demás modelos, el diseño de una base de datos
se puede abordar de dos formas distintas:
a) Obteniendo el esquema relacional directamente a partir de la observación de

nuestro universo del discurso, de forma que plasmemos nuestra percepción del
mismo en un conjunto de esquemas de relación, los cuales contendrán los atributos
y las restricciones de integridad que representan los objetos y reglas que hemos
podido captar en nuestro análisis del mundo real.
b) Realizando el proceso de diseño en dos fases, en la primera se lleva a cabo el

diseño conceptual, por ejemplo en el modelo E/R, obteniéndose el correspondiente
esquema conceptual; en la segunda, se transforma éste en un esquema relacional,
siguiendo unas determinadas reglas de transformación.
Estas relaciones que resultan de la observación del mundo real o de la transformación

del esquema E/R elaborado en la etapa de modelado conceptual, pueden presentar
algunos problemas, derivados de fallos en la percepción del UD, en el diseño del esquema
E/R o en el paso al modelo relacional; entre estos problemas cabe destacar los siguientes:
. Incapacidad para almacenar ciertos hechos
. Redundancias y, por tanto, posibilidad de incoherencias.
. Ambigüedades.
. Pérdida de información (aparición de tuplas espúreas).
. Pérdida de dependencias funcionales, es decir, de ciertas restricciones de
integridad que dan lugar a interdependencias entre los datos.
. Aparición en la base de datos, de estados que no son válidos en el mundo real, es
decir, anomalías de inserción, borrado y modificación (anomalías de Codd).
En definitiva, el esquema relacional debe ser analizado para comprobar que no

presenta los problemas anteriormente citados, evitando la pérdida de información y la
aparición de estados que son válidos en el mundo real.
Ejemplo 1.
Si observamos con atención la relación siguiente, vemos que presenta varios de los
problemas enumerados anteriormente:
. Gran cantidad de redundancia; ya que la nacionalidad del autor se repite por cada
ocurrencia del mismo, y algo análogo sucede, cuando un libro tiene más de un
autor, con la editorial y el año de publicación.
. Anomalías de modificaciones; ya que, inadvertidamente podemos, por ejemplo,
cambiar el nombre de la editorial en una tupla sin modificar en el resto de las que
corresponden al mismo libro, lo que da lugar a incoherencias.
. Anomalías de inserción; ya que si se quisiera incluir información sobre algún autor
del que no hubiera ningún libro en la base de datos, no sería posible, al formar el
atributo cod_libro parte de la clave primaria de la relación, ni tampoco podríamos
introducir obras anónimas (recuérdese la regla de integridad de entidad que no
permite los nulos en ningún atributo que forme parte de una clave primaria).
Además, la inserción de un libro que tuviera dos autores obligaría a incluir dos
tuplas en la base de datos.
. Anomalías de borrado, ya que si quisiéramos dar de baja un libro, también se

perderían datos sobre autores (si éstos no habían escrito nada más que un libro) y,
viceversa, si borramos un autor desaparecerían de nuestra base de datos los libros
escritos por él (a no ser que el libro tuviera más de un autor).
AUTOR NACIONALIDAD COD_LIBRO TITULO EDITORIAL AÑO
DATE. C NORTEAMERICA 96987 DATABASES ADDISON-W 1990
DATE. C NORTEAMERICA 97777 SQLSTANDARD ADDISON-W 1985
DATE. C NORTEAMERICA 98987 A GUIDE TO INGRES ADDISON-W 1988
CODD. E NORTEAMERICA 78900 RELATIONAL MOD ADDISON-W 1990
GARDIN FRANCESA 12345 BASES DE DATOS PARANINFO 1985
GARDIN FRANCESA 67890 COMPARACIÓN BD EYRROLYES 1984
VALDURIEZ FRANCESA 67870 COMPARACION BD EYRROLYES 1984
KIM. W NORTEAMERICANA 11223 O-O DATABASES ACM PRESS 1989
LOCHOVSKY CANADIENSE 11233 O-O DATABASES ACM PRESS 1989
Vemos, por tanto, que la actualización (alta, baja o modificación) de un solo libro o de un
solo autor nos puede obligar a actualizar más de una tupla, dejándose la integridad de la
base de datos en manos del usuario; además de la falta de eficiencia asociada a estas
múltiples actualizaciones.
Esta relación presenta todos estos problemas, y algunos más, debido a que atenta
contra un principio básico en todo diseño:
"hechos distintos se deben almacenar en objetos distintos"
en este caso, en relaciones distintas, con lo que se habrían evitado redundancias y, por
tanto, anomalías de actualización.
El problema es que a menudo no se llega a comprender completamente el UD, debido a

una excesiva premura al realizar el análisis, o por carecer el analista de conocimientos
sobre metodologías de diseño de bases de datos o de experiencia para aplicarlas
adecuadamente.
Ejemplo 2.
Supóngase una base de datos que contiene información sobre Vendedores, Artículos
y Cantidades con los siguientes datos.
CodVen Ciudad País CodPiez Cantidad

S1 Londres Inglaterra P1 200
S2 Madrid España P1 24
S2 Madrid España P6 988
S3 París Francia P2 200
Es fácil darse cuenta que esta base de datos no se encuentra bien diseñada, debido al
alto grado de redundancia que existe, es decir; no es necesario especificar tantas veces
que el vendedor S1 es de Londres ya, que con que hubiese una sola referencia a este
hecho, sería suficiente.
Esta redundancia a su vez puede provocar graves problemas. Por ejemplo si el

proveedor S1 cambia de ciudad, sería necesario actualizar al nuevo valor todas las tuplas
en las cuales aparezca el proveedor S1. Otro de los problemas que se plantea en una
base de datos de este tipo es que, en el momento en el que un proveedor deje de
suministrar alguna pieza, automáticamente habría que borrar esa tupla de la tabla, con lo
cual también se perderían todos los datos de ese proveedor (su nombre, ciudad, etc.).
3.2. TEORÍA DE LA NORMALIZACIÓN

La teoría de la normalización trata de evitar las redundancias y las anomalías de
actualización, obteniendo relaciones más estructuradas que no presenten los problemas
anteriores.
Al proceso de dividir cualquier relación en dos o más relaciones se llama proceso de

normalización. Consiste en reemplazar las relaciones por proyecciones adecuadas, de tal
forma que la reunión natural de las proyecciones genere la relación original, es decir, que
no se produzca pérdida de información. Incluso las nuevas relaciones pueden contener
información que no se podía representar originalmente (un nuevo registro en alguna de las
nuevas relaciones), pero siempre conservando las dependencias funcionales.
La teoría de la normalización puede definirse como una técnica formal para organizar
datos que nos ayuda a determinar qué está equivocado en un diseño y nos enseña la
manera de corregirlo. Introduce una formalización en el diseño lógico de bases de datos
relacionales, lo que, además, permite mecanizar parte del proceso al poder disponer de
instrumentos algorítmicos de ayuda al diseño.
Se dice que un esquema de relación está en una determinada forma normal si satisface
determinado conjunto específico de restricciones.
Los esquemas de relación obtenidos en el proceso de normalización son equivalentes,

cumpliéndose las siguientes propiedades:
. Conservación de la información
. Conservación de las dependencias
. Mínima redundancia de los datos
3.3. DEPENDENCIAS FUNCIONALES

La teoría de la normalización también se conoce como teoría de las dependencias por
basarse en ellas.
Las dependencias son propiedades inherentes al contenido semántico de los datos que
se han de cumplir para cualquier extensión del esquema de relación y forma parte de las
restricciones de usuario del modelo relacional.
Un esquema de relación se representara como: R(A,DF)

donde A es el conjunto de atributos y DF el conjunto de dependencias funcionales
existentes entre dichos atributos.
Existen diferentes tipos de dependencias, aunque, ahora, sólo vamos a tratar las
dependencias funcionales, que son las más extendidas y constituyen la base de la tres
primeras formas normales.
Dependencia funcional
Dada una relación R y los subconjuntos de atributos X e Y, se dice que Y depende

funcionalmente de X o que X determina o implica a Y
XY
si y sólo si cada valor de X tiene asociado un único valor de Y.
X e Y son denominados descriptores. X se conoce como determinante o implicante e Y

como implicado.
Por ejemplo, todos sabemos que entre los atributos "DNI" y "NOMBRE" existe una
dependencia funcional, puesto que un valor de DNI se corresponde con un solo NOMBRE.
DNI  NOMBRE
En este caso (suponiendo que el NOMBRE es único y no existen dos nombres de

personas diferentes que sean iguales) se cumple también la dependencia
NOMBRE  DNI
Pudiéndose abreviar con:

DNI  NOMBRE
Se dice, en este caso, que los descriptores X e Y son equivalentes, si se cumple:
X  Y e Y  X, lo que se puede representar por: X  Y
No siempre se cumple de modo biunívoco la dependencia funcional entre dos atributos,

es más, en contados casos sucede. Por ejemplo, entre los atributos "DNI" y "DIRECCIÓN"
existe una dependencia funcional puesto que una persona identificada por el DNI vive en
una única DIRECCIÓN o domicilio, pero en este caso no se cumple la dependencia en
sentido inverso, puesto que una DIRECCIÓN viven varias personas. Además, la dirección
no nos dice ni siquiera la ciudad en donde se encuentra (por ejemplo, la "C/Mayor,7" se
encuentra en multitud de ciudades), por lo tanto.
DIRECCIÓN  DNI
Existen atributos que no tienen entre sí una dependencia funcional como es el caso de
DNI_AUTOR y TITULO_LIBRO tratando el tema de libros publicados por autores. En este
caso, un autor escribe varios libros y un libro puede estar escrito por varios autores.
DNI_AUTOR  TITULO_LIBRO
En numerosas ocasiones, para determinar un único valor de un atributo, no nos basta

con conocer el valor de otro atributo, sino que es necesario encontrar los valores de varios
atributos. Así sucede, si tenemos los atributos: dni, empresa y sueldo, y sabemos que una
persona puede trabajar en varias empresas. Entre los atributos DNI y SUELDO no existe
dependencia funcional, puesto que un individuo puede ganar varios sueldos dependiendo
de la empresa en la que trabaje. Pero si conocemos la empresa en la que trabaja, sí
podemos decir que:
DNI.EMPRESA  SUELDO
Se suele utilizar el operador punto "." para representar la expresión "junto con " o "y"
entre ambos atributos y el operador coma ó "|" para hacer referencia a la expresión "o
también". Por tanto, podemos decir que el DNI "junto con" la EMPRESA determinan el
SUELDO.
Y, podemos representar que con el DNI se conoce el nombre "o también" la dirección,
de la forma:
DNI  NOMBRE | DIRECCIÓN
Dependencia funcional completa
Se dice que el descriptor Y tiene una dependencia funcional completa con el

descriptor compuesto X si depende funcionalmente de X, pero no depende de ningún
subconjunto del mismo.
Por ejemplo, una dependencia funcional sería:
DNI.EMPRESA  NOMBRE
Pero, lógicamente, esta dependencia no es completa puesto que el NOMBRE depende

del DNI. Por ello, a esta dependencia se la denomina dependencia parcial.
Una dependencia funcional completa sería:
DNI.EMPRESA  SUELDO
Ahora sí, el SUELDO no depende de ningún subconjunto.
Las dependencias que nos interesan para tratar los problemas son siempre las
dependencias funcionales completas, y sólo ellas servirán para encontrar la solución.
Una dependencia funcional es trivial cuando el implicado es un subconjunto del

implicante.
Las dependencias funcionales DNI.EMPRESA  EMPRESA o DNI  DNI son triviales.
No todas las dependencias son útiles para la teoría de la normalización, sino solamente
un subconjunto de ellas, que son las llamadas dependencias funcionales elementales.
Se denomina dependencia funcional elemental a una dependencia funcional completa no

trivial en la que el implicado es sólo un atributo
La dependencia DNI.EMPRESA  SUELDO es elemental.
Dependencia funcional transitiva
Dados los descriptores X, Y, Z de la relación R, existe dependencia transitiva de Z

respecto de X a través de Y, si se cumple que X  Y, Y  Z y X e Y no son
equivalentes.
Si además, Z e Y tampoco son equivalentes, es decir, no se cumple que Z  Y , la

dependencia transitiva es estricta
Gráficamente será: Y
Por lo tanto, un atributo (Z) es transitivamente dependiente de otro (X) si se conoce por
diferentes vías, una directamente, y otra a partir de otro atributo intermedio (en nuestro
caso, Y).
Por ejemplo, consideremos cuatro atributos que forman parte de datos relativos a un
alumno: NUMMAT (número matricula), NOMALU (nombre del alumno), GRUASI (grupo
asignado), AULGRU (aula correspondiente al grupo). Se parte de los condicionantes:
* Un alumno sólo tiene asignado un grupo.

* A un grupo siempre le corresponde un único aula.
El atributo AULGRU es transitivamente dependiente de NUMMAT, puesto que se puede

conocer por medio del atributo intermedio GRUASI.
GRUASI
NUMMAT
AULGRU
Diagrama de dependencias funcionales
Una herramienta muy útil a la hora de explicar las dependencias funcionales es el grafo
o diagrama de dependencias funcionales, mediante el cual se representa un conjunto de
atributos y las dependencias funcionales existentes entre ellos.
Una vez estudiado el problema, se identifican las entidades, las asociaciones, y se

diseña el modelo entidad-asociación. Tenemos que tener claramente identificada la
información, que queremos incluir en cada entidad y en cada asociación. Esa información,
o sea los atributos, será estudiada más a fondo para obtener las dependencias funcionales
que aparecen a simple vista. Si es necesario, se aplicarán las propiedades anteriores para
obtener nuevas dependencias (Armstrong). Es útil utilizarlas en atributos que son códigos
compuestos y que relacionan otros códigos, a su vez compuestos. Por último, debemos
identificar la clave de las entidades y las asociaciones.
El grafo de las DF es una forma clara de tener una visión general de los datos y de la
cohesión existente entre ellos. La clave que se obtiene de tratar todas las DF, se
representa dentro de una caja de líneas continuas con sus atributos primarios. El resto de
los atributos se representan fuera de la caja, y después las dependencias entre todos ellos.
Si existen dependencias de varios atributos, que no son la clave, irán en una caja de
líneas discontinuas para no confundirlo con la propia clave de la tabla.
Por ejemplo sean las dependencias:
A.B.C  M,N,S
MN
B.C  O,P,R
CQ
El grafo asociado es:
A M N
B O P
C Q
R
S
3.4. PRIMERAS FORMAS NORMALES

La primera forma normal, al igual que la segunda y la tercera, fueron introducidas por
Codd.
Primera Forma Normal
Una relación R se encuentra en primera forma normal (IFN) si y sólo si todos los
dominios simples subyacentes contienen sólo valores atómicos. Es decir, el cruce de
fila con columna sólo tiene un dato.
La 1FN es una restricción inherente al modelo relacional por lo que su cumplimiento es

obligatorio, por lo que podemos afirmar que toda relación por el hecho de ser, está en 1FN.
Por ejemplo, si disponemos de una tabla EMPLEADOS para almacenar la información

de las personas que trabajan en varias empresas y, en cada una de ellas percibe un
sueldo:
EMPLEADO (DNI, EMPRESA, NOMBRE_E, SUELDO)
No estaría en 1FN puesto que los atributos EMPRESA y SUELDO, tienen varios valores
para un DNI dado. Una solución sería elegir una clave compuesta formada por DNI y
EMPRESA :
EMPLEADO (DNI, EMPRESA, NOMBRE_E, SUELDO)
De esta forma la tabla EMPLEADO es una relación y, por tanto, está en 1FN.
Segunda Forma Normal
Una relación R se encuentra en segunda forma normal (2FN) si y sólo si está en

1FN y todos los atributos no clave dependen funcionalmente de manera completa de la
clave primaria.
Si una relación no se encuentra en 2FN se puede aplicar el siguiente teorema de

manera que, al descomponer la relación original en dos, por lo menos una de ellas se
encuentre en 2FN.
Teorema 1
Sea una relación R(A,B,C,D) y la clave primaria es A.B y tal que A  D. Entonces la
relación R puede descomponerse como:
RI (A, D)
R2(A, B, C)
En la relación EMPLEADO, suponiendo que NOMBRE_E --/ DNI, no está en 2FN

pues existen las dependencias funcionales:
DNI NOMBRE_E
EMPRESA SUELDO
Aplicando el teorema 1, descomponemos la relación dada en:
EMPLEADO (DNI, NOMBRE_E)

SUELDOS (DNI, EMPRESA, SUELDO)
Obteniendo así dos relaciones que están en 2FN.
Tercera Forma Normal
Una relación R se encuentra en tercera forma normal (3FN) si y sólo si está en 2FN
y ningún atributo no clave tiene una dependencia funcional transitiva de ninguna de las
claves.
Si una relación no se encuentra en 3FN se puede aplicar el siguiente teorema, de

manera que al descomponer la relación original en dos por lo menos una de ellas se
encuentre en 3FN.
Teorema II
Sea una relación R(A,B,C) con clave primaria (A) y tal que B  C. Entonces la relación
R puede descomponerse como:
R1(A, B)
R2(B, C)
En el ejemplo dado en la definición de dependencias funcionales transitivas:
ALUMNOS (NumMat, Nombre_A, Domicilio, Localidad, GruAsi, AulaGru)

“ALUMNOS”
Nombre_A
NumMat Localidad
GruAsi AulaGru
existía una dependencia transitiva a partir de la clave NumMat. Por lo que la tabla no se
encuentra en 3FN; si se normaliza según el teorema II, quedaría:
“ALUMNOS” “GRUPOS”
Nombre_A
NumMat Localidad GruAsi AluGru
GruAsi
Las dos tablas resultantes se encuentran en 3FN.
3.5. FORMA NORMAL DE BOYCE-CODD

Tras la creación de la 3FN se observó que se encontraban algunas anomalías que no
eran abordadas. Son casos de tablas que estando en 3FN mantienen una dependencia de
un atributo secundario con parte de la clave
Para ello, se pensó en una definición más global que abordase las anomalías
observadas. La nueva definición se debe a Boyce y Codd.
Para definir la forma normal de Boyce-Codd (FNBC) es conveniente introducir

primero un nuevo término. Se define un determinante como un atributo del cual
depende funcionalmente de manera completa algún otro atributo.
Una relación está en FNBC si y sólo si todo determinante es una clave candidata.
La definición engloba la 3FN puesto que las dependencias transitivas existen por medio
de atributos secundarios que no eran clave.
- Si la clave está formada por un sólo atributo, la tabla está en FNBC (si ya estaba en
3FN) como sucedía con la 2FN.
- Si una relación no tiene claves solapadas y está en 3FN, también se encuentra en
BNFC.
En realidad son muy pocos los casos de relaciones que se encuentran en 3FN y no
están en FNBC. Este tipo de tablas son aquellas en las que se dan las siguientes
circunstancias:
● Existan dos o más claves candidatas
● Las claves candidatas son compuestas
● Las claves candidatas se solapan (tienen por lo menos un atributo común)
En estos casos se puede aplicar el siguiente teorema, de manera que al descomponer

la relación original en dos por lo menos una de ellas se encuentre en FNBC.
Teorema III
Sea una relación R(A,B,C,D) con claves candidatas (A,B) y (B,C) y tal que: A  C.
Entonces, la relación R puede descomponerse de cualquiera de las dos siguientes
maneras:
R1 (A, C) RI(A,C)
R ó R
R2(B, C, D) R2(A, B, D)
Vamos a utilizar como ejemplo la relación siguiente:
ACTIVIDADES_SOCIOS (DNI, COD_SOCIO, ACTIVIDAD, FECHA_ALTA)
Esta relación fue diseñada para registrar las actividades practicadas por los socios de
un club deportivo. Sus claves candidatas son: {ACTIVIDAD, DNI} y {ACTIVIDAD,
COD_SOCIO}.
Asociadas a esta relación existen las siguientes dependencias funcionales:
ACTIVIDAD.DNI  FECHA_ALTA
ACTIVIDAD.COD_SOCIO  FECHA_ALTA
DNI  COD_SOCIO
COD_SOCIO  DNI
El diagrama de dependencias funcionales sería:
COD_SOCIO ACTIVIDAD
DNI
FECHA_ALTA
Es evidente que la relación ACTIVIDADES_SOCIOS está en 3FN; su único atributo no

clave (FECHA_ALTA) tiene dependencia funcional completa y no transitiva de las claves.
Pero para que se encuentre en FNBC no puede haber más determinantes que las claves, y
eso no se cumple. El atributo DNI, que no es clave, determina a COD_SOCIO, e
igualmente, COD_SOCIO determina a DNI.
Por tanto, para llevar esta relación a FNBC será necesario aplicar el Teorema III.
Eligiendo los atributos de la siguiente manera:
A = (COD_SOCIO)
B = (ACTIVIDAD)
C = (DNI)
D = (FECHA_ALTA)
R1(A,C)
Es posible descomponer sin pérdidas la relación original R 
R2(A,B,D)
es decir,
R1 = (COD_SOCIO, DNI) y R2 = (COD_SOCIO, ACTIVIDAD, FECHA_ALTA)
3.7. DEPENDENCIAS MULTIEVALUADAS . CUARTA FORMA NORMAL

En la siguiente figura aparece la relación TAQUILLAS_SOCIOS, diseñada para
almacenar las taquillas que los socios de un gimnasio tienen asignadas permanentemente
para guardar sus objetos personales.
TAQUILLAS_SOCIOS
COD_SOCIO COD_FAMILIAR TAQUILLA
A1111 H0001 223
A1111 H0001 274
A2222 K0010 341
A2222 K0010 412
A2222 K0011 341
A2222 K0011 412
A cada socio se le asignan una o más taquillas, dependiendo de las actividades

deportivas practicadas por él o por sus familiares. Las taquillas de un socio pueden ser
usadas por él o por cualquiera de sus familiares; así, el socio A1111 comparte con su
familiar H0001 las taquillas 223 y 274, y el socio A2222 y sus familiares K0010 y K0011
tienen las taquillas 341 y 412.
Esta relación, cuya clave primaria está formada por sus tres atributos, está en FCBC, ya
que no tiene dependencias funcionales asociadas. No obstante, en ella hay redundancias
y se producen anomalías de actualización. Por ejemplo, para registrar el hecho de que al
socio A2222 se le asigna un nueva taquilla, será necesario añadir dos tuplas.
El problema radica en que en esta relación existen un tipo de dependencias

denominadas dependencias multievaluadas.
Una dependencia multievaluada es una sentencia X Y, donde X e Y son

descriptores tales que un cierto valor de X implica un conjunto bien definido de valores
de Y, con independencia de los demás atributos de la relación.
La dependencia multievaluada es un concepto que se introduce para posteriormente

tratar la 4FN.
En la relación TAQUILLAS_SOCIOS cada valor de COD_SOCIO determina un conjunto

de una o más taquillas independientemente de los familiares del socio, es decir, existe la
dependencia multievaluada COD_SOCIO  TAQUILLA. También, existe la dependencia

COD_SOCIO  COD_FAMILIAR, ya que existe una relación entre socio y familiares,
independiente de las taquillas.
Las dependencias multievaluadas siempre aparecen por parejas; así, si en un esquema

existe la dependencia X Y, al mimo tiempo habrá de cumplirse X A – (XY),
donde A es el conjunto de todos los atributos de la relación. Las dependencias funcionales
que forman pareja se representan:
X Y | A – (XY)
Se puede pues demostrar que dada la relación R(A,B,C), la DMV A  B se cumple si

y sólo si también se cumple A  C.
Cuarta forma normal

En 1977 R. Fagin enunció la cuarta forma normal.
Una relación se encuentra en cuarta forma normal (4FN) si, y sólo si,
- Está en FBNC y
- Las únicas DMV existentes son las DF de la clave con los atributos
secundarios..
La relación TAQUILLAS_SOCIOS no está en 4FN, puesto que sus dependencias

multievaluadas COD_SOCIO  COD_FAMILIAR | TAQUILLA tienen como determinante
a COD_SOCIO que no es clave.
Una relación que no esté en 4FN puede ser descompuesta, sin pérdida de información,
en dos proyecciones que sí están en 4FN.
Teorema de Fagin
Sea una relación R(A,B,C) con las siguientes dependencias multivaluadas
A  B
A C
R1(A,B)
Entonces la relación R puede descomponerse como: R
R2(A,C)
Los problemas que presenta la relación TAQUILLAS_SO CIOS desaparecen al sustituirla

por las siguiente proyecciones:
F_SOCIOS T_SOCIOS
COD_SOCIO COD_FAMILIAR COD_SOCIO TAQUILLA
A1111 H0001 A1111 223
A2222 K0010 A1111 274
A2222 K0011 A2222 341
A2222 412
Se puede comprobar que dichas proyecciones están en 4FN.
Es frecuente comenzar el proceso de normalización descomponiendo en proyecciones

independientes teniendo en cuenta las dependencias multievaluadas. A continuación, se
seguirá con la normalización de dichas proyecciones, que pueden no estar en 2FN, 3FN o
FNBC.
3.8. DEPENDENCIAS DE REUNIÓN. QUINTA FORMA NORMAL.

Existen relaciones imposibles de descomponer sin pérdidas de información en dos
proyecciones, pero que si pueden descomponerse en tres o más.
En la siguiente figura tenemos la relación EQUIPOS diseñada para registrar los equipos
que participan en un campeonato escolar entre colegios. Cada tupla almacena los datos de
un equipo: el nombre del colegio, el deporte y la categoría.
EQUIPOS
COLEGIO DEPORTE CATEGORÍA
S. APOSTOL BALONMANO ALEVIN
S. APOSTOL VOLEIBOL INFANTIL
A. SELA VOLEIBOL ALEVIN
S. APOSTOL VOLEIBOL ALEVIN
En las reglas del campeonato se establece que si un colegio presenta algún equipo de
un determinado deporte, si ese colegio participa con algún equipo en una determinada
categoría, y si además, hay competición de ese deporte en esa categoría, obligatoriamente
el colegio debe participar con un equipo de ese deporte y esa categoría. Es decir, que si
existen las tres tuplas siguientes:
(S. APOSTOL, VOLEIBOL, X)

(S. APOSTOL, X, ALEVIN)
(X, VOLEIBOL, ALEVIN)
donde X representa cualquier valor del correspondiente dominio. También debe existir la
tupla:
(S. APOSTOL, VOLEIBOL, ALEVIN)
A pesar de que la relación está en 4FN (no tiene asociadas dependencias funcionales o
multievaluadas no triviales), presenta anomalías de actualización. Así, si se pretende
eliminar la tupla (S. APOSTOL, VOLEIBOL, ALEVIN), necesariamente se debe eliminar
también alguna de las otras tres. De igual forma, si se inserta (A. SELA, BALONMANO,
INFANTIL) habrá que insertar (A. SELA, VOLEIBOL, INFANTIL) y (S. APOSTOL,
BALONMANO, INFANTIL).
Hasta ahora solucionamos el problema de las anomalías descomponiendo, sin pérdida

de información en dos de sus proyecciones:
C_DEPORTE C_CATEGORÍA
COLEGIO DEPORTE COLEGIO CATEGORÍA
S. APOSTOL BALONMANO S. APOSTOL ALEVIN
S. APOSTOL VOLEIVOL S. APOSTOL INFANTIL
A. SELA VOLEIVOL A. SELA ALEVIN
Pero ¿qué sucede si pretendemos en un futuro recuperar la tabla original? Debemos

hacer un join de ambas proyecciones.
C_DEPORTE * C_CATEGORÍA
COLEGIO DEPORTE CATEGORÍA
S. APOSTOL BALONMANO ALEVIN
S. APOSTOL BALONMANO INFANTIL
S. APOSTOL VOLEIBOL INFANTIL
A. SELA VOLEIBOL ALEVIN
S. APOSTOL VOLEIBOL ALEVIN
La descomposición de EQUIPOS en dos proyecciones se realiza con pérdida de

información, puesto que la tupla (S. APOSTOL, BALONMANO, INFANTIL), que aparece en
la reunión natural de las proyecciones, no obstante en EQUIPOS. Se podría haber elegido
otras proyecciones, pero se seguiría produciendo pérdida de información.
No obstante, el problema queda resuelto si la descomposición se hace en tres

proyecciones. Se puede comprobar que la reunión natural de las proyecciones de
EQUIPOS sobre (COLEGIO, DEPORTE), (COLEGIO, CATEGORÍA) y (DEPORTE,
CATEGORÍA) da como resultado la relación EQUIPOS.
Se dice que la relación R satisface la dependencia de reunión (X,Y,...,Z) si y sólo si

R es igual a la reunión de sus proyecciones según X,Y,...,Z donde X,Y,...,Z son
subconjuntos del conjunto de atributos de R.
Las dependencias de reunión vienen dadas por restricciones que el diseñador impone
sobre la tabla, tales como la siguiente. Veamos otro ejemplo:
Supóngase una relación con datos sobre vendedores, países y piezas.
Vendedor Pieza Pais

Pepe Clavo España
Pepe Tuerca Brasil
Juan Clavo Brasil
Pepe Clavo Brasil
en la que se impone la siguiente restricción:
Si PEPE vende CLAVOS,

Los CLAVOS se venden en BRASIL
Y PEPE vende en BRASIL
Entonces PEPE vende CLAVOS en BRASIL
lo cual supone que:

si aparece la pareja (Pepe,Clavo)
y la pareja (Clavo,Brasil)
y la pareja (Pepe,Brasil)
entonces la tripleta (Pepe, Clavo, Brasil) ¡debe aparecer!.
Esto hace que la relación anterior sea 3-descomponible, es decir, es igual a la reunión
de las proyecciones (vendedor, pieza), (vendedor, país) y (pieza, país) y que por tanto
existe la siguiente DR ((vendedor, pieza), (vendedor, país) y (pieza, país)).
Quinta Forma Normal
Una relación R se encuentra en quinta forma normal 5FN si y sólo si:

- Está en 4FN y
- Toda dependencia de reunión en R es una consecuencia de las claves
candidatas.
Esto viene a decir que una relación estará en 5FN cuando esté en 4FN y siempre que
no existan restricciones impuestas por el creador.
Cuando una tabla se encuentra en 4FN y no en 5FN la solución es descomponerla para

deshacer las DR.
3.7. PROCESO DE TRANSFORMACION DE LAS RELACIONES A TERCERA
FORMA NORMAL.
Algoritmo de descomposición
El diseño de las bases de datos por descomposición permite obtener una relación en
FNBC, el algoritmo general de diseño es:
1. Se obtiene la relación universal para la base de datos.
2. Se determinan todas las DF entre los atributos de la relación universal.
3. Se eliminan todas las DF redundantes en el conjunto inicial de DF, obteniendo
una cobertura mínima. Este proceso debe realizarse eliminando las DF una a una y
comprobando las DF restantes después de cada eliminación para averiguar si sigue
habiendo alguna DF redundante.
4. Se utilizan las DF presentes en la cobertura mínima para descomponer la
relación universal en un conjunto de relaciones FNBC. Se averigua si la relación
está en FNBC. Si lo está, el diseño está completo; en caso contrario, la relación
debe descomponerse en otras dos (Se repiten los pasos 2, 3 y 4 para cada nueva
relación obtenida por descomposición).
5. Si pudiera obtenerse más de una cobertura mínima, se compararán los diseños
generados por cada una de ellas para determinar la que mejor se ajuste a las
necesidades.
Al efectuar el paso 4 conviene recordar que nunca se debe proyectar una DF cuyo
atributo dependiente sea, al mismo tiempo, el determinante de otra DF. Asimismo,
conviene ser cuidadoso en los casos en que un atributo dependa de más de un
determinante. Cualquiera de los dos casos anteriores puede provocar la pérdida de una
DF.
Si durante el proceso de descomposición se llegase a un punto en el que no se pudiera

seguir proyectando sin provocar la pérdida de una DF, el diseñador habrá de elegir entre
dos opciones: 1) construir una relación con cada uno de los determinantes restantes y sus
atributos dependientes, o 2) alterar el orden de las primeras descomposiciones, ya que el
algoritmo no garantiza una única solución y puede existir otra más conveniente.
Ejemplo 3.
La siguiente relación (tabla) almacena los artículos que se sirven a nuestros clientes
distribuidos por toda la geografía españolas:
NCL NOMBRE LOCALIDAD CT NART ARTICULO CANT PVP FECHA

11 Luis Málaga 0.8 A1 Papel 100 5 3/5
50 5 5/5
A9 Disco 25 200 7/5
44 Ana Gijón 1.1 A1 Papel 130 5 10/5
A3 Cinta 20 500 7/5
55 José Valencia 1.4 A4 Grapas 30 50 3/5
A partir de aquí se obtienen las dependencias funcionales:

NCL  NOMBRE
NCL  LOCALIDAD
LOCALIDAD  CT
NART  ARTICULO
NART  PVP
NCL, NART  CANT
NCL, NART  FECHA
No existen atributos extraños ni dependencias redundantes, por lo que tenemos una
cobertura mínima.
La tabla dada se puede normalizar a 1ªFN con la creación de un nuevo registro por cada
uno de los distintos valores de un campo, tal que permita expresar la relación como una
tabla.
NCL NOMBRE LOCALIDAD CT NART ARTICULO CANT PVP FECHA

11 Luis Málaga 0.8 A9 Disco 25 200 7/5
44 Ana Gijón 1.1 A1 Papel 130 5 10/5
44 Ana Gijón 1.1 A2 Cinta 20 500 7/5
55 José Valencia 1.4 A4 Grapas 30 50 3/5
Dadas las anomalías de almacenamiento, es preciso pasar la relación a 2ªFN, quedando

como sigue:
Relación CLIENTES
NCL NOMBRE LOCALIDAD CT
11 Luis Málaga 0.8
44 Ana Gijón 1.1
55 José Valencia 1.4
Relación ARTICULOS
NART ARTICULO PVP
A1 Papel 5
A3 Cinta 500
A4 Grapas 50
A9 Disco 200
Relación VENTAS
NCL NART CANT FECHA

11 A1 100 3/5
11 A3 50 5/5
11 A9 25 7/5
44 A1 130 10/5
55 A4 30 3/5
la relación CLIENTES presenta anomalías de almacenamiento debido a que el atributo CT

es funcionalmente dependiente de LOCALIDAD, que a su vez depende de NCLI.
Al normalizar (3ªFN) la relación CLIENTES quedaría:
Relación CLIENTES Relación TRANSPORTE

NCL NOMBRE LOCALIDAD LOCALIDAD CT
11 Luis Málaga Malága 0.8
44 Ana Gijón Gijón 1.1
55 José Valencia Valencia 1.4
Salamanca 1.0

Daeg 03 Bis

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Daeg 03 Bis

Cargado por

Copyright:

Formatos disponibles

Diseño de las bases de datos relacionales

UNIDAD 3 DISEÑO DE LAS BASES DE DATOS RELACIONALES

3.2. Teoría de la Normalización.

3.3. Dependencias funcionales:

3.4. Primeras formas normales

3.5. Forma normal de Boyce-Codd

3.6. Dependencias Multievaluadas. Cuarta forma normal.

3.7. Dependencias de reunión. Quinta forma normal

3.8. Proceso de transformación de las relaciones a tercera forma normal.

Objetivos: Identificar los problemas que puede presentar un esquema de relación,

3.1. PROBLEMAS QUE PUEDE PRESENTAR EL DISEÑO DE UNA BASE DE

a) Obteniendo el esquema relacional directamente a partir de la observación de

b) Realizando el proceso de diseño en dos fases, en la primera se lleva a cabo el

Estas relaciones que resultan de la observación del mundo real o de la transformación

En definitiva, el esquema relacional debe ser analizado para comprobar que no

. Anomalías de borrado, ya que si quisiéramos dar de baja un libro, también se

AUTOR NACIONALIDAD COD_LIBRO TITULO EDITORIAL AÑO

DATE. C NORTEAMERICA 96987 DATABASES ADDISON-W 1990

DATE. C NORTEAMERICA 97777 SQLSTANDARD ADDISON-W 1985

DATE. C NORTEAMERICA 98987 A GUIDE TO INGRES ADDISON-W 1988

CODD. E NORTEAMERICA 78900 RELATIONAL MOD ADDISON-W 1990

GARDIN FRANCESA 12345 BASES DE DATOS PARANINFO 1985

GARDIN FRANCESA 67890 COMPARACIÓN BD EYRROLYES 1984

VALDURIEZ FRANCESA 67870 COMPARACION BD EYRROLYES 1984

KIM. W NORTEAMERICANA 11223 O-O DATABASES ACM PRESS 1989

LOCHOVSKY CANADIENSE 11233 O-O DATABASES ACM PRESS 1989

El problema es que a menudo no se llega a comprender completamente el UD, debido a

CodVen Ciudad País CodPiez Cantidad

Esta redundancia a su vez puede provocar graves problemas. Por ejemplo si el

3.2. TEORÍA DE LA NORMALIZACIÓN

Al proceso de dividir cualquier relación en dos o más relaciones se llama proceso de

Los esquemas de relación obtenidos en el proceso de normalización son equivalentes,

3.3. DEPENDENCIAS FUNCIONALES

Un esquema de relación se representara como: R(A,DF)

Dada una relación R y los subconjuntos de atributos X e Y, se dice que Y depende

X e Y son denominados descriptores. X se conoce como determinante o implicante e Y

En este caso (suponiendo que el NOMBRE es único y no existen dos nombres de

Pudiéndose abreviar con:

Se dice, en este caso, que los descriptores X e Y son equivalentes, si se cumple:

X  Y e Y  X, lo que se puede representar por: X  Y

No siempre se cumple de modo biunívoco la dependencia funcional entre dos atributos,

DIRECCIÓN  DNI

DNI_AUTOR  TITULO_LIBRO

En numerosas ocasiones, para determinar un único valor de un atributo, no nos basta

Dependencia funcional completa

Se dice que el descriptor Y tiene una dependencia funcional completa con el

Por ejemplo, una dependencia funcional sería:

Pero, lógicamente, esta dependencia no es completa puesto que el NOMBRE depende

Ahora sí, el SUELDO no depende de ningún subconjunto.

Una dependencia funcional es trivial cuando el implicado es un subconjunto del

Las dependencias funcionales DNI.EMPRESA  EMPRESA o DNI  DNI son triviales.

Se denomina dependencia funcional elemental a una dependencia funcional completa no

La dependencia DNI.EMPRESA  SUELDO es elemental.

Dependencia funcional transitiva

Dados los descriptores X, Y, Z de la relación R, existe dependencia transitiva de Z

Si además, Z e Y tampoco son equivalentes, es decir, no se cumple que Z  Y , la

* Un alumno sólo tiene asignado un grupo.

El atributo AULGRU es transitivamente dependiente de NUMMAT, puesto que se puede

Diagrama de dependencias funcionales

Una vez estudiado el problema, se identifican las entidades, las asociaciones, y se

El grafo asociado es:

3.4. PRIMERAS FORMAS NORMALES

Primera Forma Normal