CAPÍTULO 10

Dependencias funcionales y
normalización en bases de
datos relacionales

n los Capítulos del 5 al 9, mostramos varios aspectos del modelo relacional y los lenguajes asociados a

E él. Cada esquema de relación consta de un número de atributos, mientras que un esquema de base de
datos relacional está compuesto por un número de esquemas de relación. Hasta ahora sólo hemos utili-
zado el sentido común del diseñador de la base de datos para agrupar los atributos y formar así un esquema
de relación, o bien hemos utilizado un diseño de esquema de base de datos a partir de un modelo de datos con-
ceptual como ER o EER, o algún otro. Estos modelos hacen que el diseñador identifique los tipos de entidad
y de relación y sus respectivos atributos, lo que nos lleva a un agrupamiento natural y lógico de los atributos
en relaciones cuando van seguidos por los procedimientos de mapeado del Capítulo 7. Sin embargo, aún nece-
sitamos algún tipo de medida formal que nos indique por qué un agrupamiento de atributos en el esquema de
una relación puede ser mejor que otro. Hasta el momento, en nuestro debate sobre el diseño conceptual de los
Capítulos 3 y 4 y su asignación en el modelo relacional del Capítulo 7, no hemos desarrollado ningún méto-
do que nos indique la idoneidad de la calidad del diseño, aparte de la intuición del diseñador. En este capítu-
lo vamos a ver parte de la teoría desarrollada con el objetivo de evaluar esquemas relacionales encaminados
a la calidad del diseño; es decir, mediremos formalmente por qué un conjunto de agrupaciones de atributos en
un esquema de relación es mejor que otro.
Hay dos niveles a los que podemos explicar la bondad de los esquemas de relación. El primero es el nivel
lógico (o conceptual): cómo los usuarios interpretan los esquemas de relación y el significado de sus atribu-
tos. Disponer de un buen esquema de relación a este nivel permite a los usuarios comprender con claridad el
significado de los datos en la relaciones y, por consiguiente, formular sus consultas correctamente. El segun-
do nivel es el de implementación (o almacenamiento): de qué modo se almacenan y actualizan las tuplas en
una relación base. Este nivel se aplica sólo a esquemas de relación base (cómo se almacenarán físicamente los
ficheros), mientras que a nivel lógico nos interesan tanto las relaciones base como las vistas (relaciones vir-
tuales). La teoría de diseño de una base de datos relacional desarrollada en este capítulo se aplica fundamen-
talmente a las relaciones base, aunque algunos criterios de idoneidad también se utilizan en las vistas (con-
sulte la Sección 10.1).
Como ocurre con otros muchos problemas de diseño, el de una base de datos debe llevarse a cabo usando dos
metodologías: ascendente (bottom-up) o descendente (top-down). Una metodología de diseño de tipo ascen-
dente, llamada también diseño por síntesis, tiene como punto de partida las relaciones básicas entre atributos
282 Capítulo 10 Dependencias funcionales y normalización en bases de datos relacionales

individuales, y los usa para construir los esquemas de relación. Esta metodología no es muy popular en la
práctica1, ya que tiene el problema de tener que recopilar al principio una gran cantidad de relaciones bina-
rias entre los atributos. Como contrapartida, en una metodología descendente, conocida también como dise-
ño por análisis, se empieza con varios agrupamientos de atributos de una relación que están juntos de forma
natural, como por ejemplo, en una factura, un formulario o un informe. Las relaciones son entonces analiza-
das individual y colectivamente, lo que conduce a una descomposición posterior que permite conocer todas
las propiedades deseables. La teoría descrita en este capítulo es aplicable a ambas metodologías de diseño,
aunque es más práctica cuando se emplea en la de tipo descendente.
Iniciamos este capítulo comentando de manera informal algunos criterios en la Sección 10.1 para determinar
un buen o mal esquema de relación. En la Sección 10.2 definimos el concepto de dependencia funcional, una
restricción formal entre los atributos que es la herramienta principal para la medida formal de la idoneidad del
agrupamiento de atributos en los esquemas de relación. También se estudian y analizan las propiedades de las
dependencias funcionales. La Sección 10.3 se centra en las formas normales y en el proceso de normalización
usando dependencias funcionales. Las formas normales sucesivas están definidas para cumplir el conjunto de
restricciones deseables expresadas mediante dependencias funcionales. El procedimiento de normalización
consiste en la aplicación de una serie de comprobaciones de las relaciones para cumplir con unos requisitos
cada vez más restrictivos y descomponer las relaciones cuando sea necesario. En la Sección 10.4 tratamos las
definiciones más generales de las formas normales que pueden aplicarse directamente a un diseño concreto y
que no precisan de un análisis paso a paso y una normalización.
El Capítulo 11 continúa con el desarrollo de la teoría para un buen diseño del esquema relacional.
Comentamos las propiedades deseables de la descomposición relacional (propiedad de reunión no aditiva y
de preservación de dependencia funcional) y después consideramos la metodología de tipo ascendente en el
diseño de una base de datos que consiste en un conjunto de algoritmos. Estos algoritmos asumen como entra-
da un conjunto dado de dependencias funcionales y consiguen un diseño relacional en una forma normal de
destino a la vez que añade las propiedades deseables antes comentadas. También se presenta un algoritmo
general que verifica si una descomposición tiene o no la propiedad de reunión sin pérdida (Algoritmo 11.1).
El Capítulo 11 contiene además la definición de tipos de dependencias adicionales y formas normales avan-
zadas que lleva más allá la idoneidad de un esquema de relación.
El lector que sólo está interesado en una introducción informal a la normalización puede saltarse las Secciones
10.2.3, 10.2.4 y 10.2.5. Si no se estudia el Capítulo 11 en un curso, recomendamos una introducción rápida a
las propiedades deseables de la descomposición mostradas de la Sección 11.1 y un debate de la propiedad
NJB, además del Capítulo 10.

10.1 Directrices de diseño informales

para los esquemas de relación
Antes de entrar en detalles con la teoría formal del diseño de bases de datos relacionales, vamos a ver en esta
sección cuatro medidas informales de calidad para el diseño de un esquema de relación:
� La semántica de los atributos.
� La reducción de información redundante en las tuplas.
� La reducción de los valores NULL en las tuplas.
� Prohibición de la posibilidad de generar tuplas falsas.
Como podremos ver, estas medidas no siempre son independientes entre sí.

1 Elmodelo relacional binario es una excepción en la que se usa esta metodología en la práctica. Un ejemplo del mismo es la metodolo-
gía NIAM (Verheijen y VanBekkum 1982).
 10.1 Directrices de diseño informales para los esquemas de relación 283

10.1.1 Impartir una semántica clara a los atributos de las relaciones

Siempre que agrupamos atributos para formar un esquema de relación asumimos que pertenecen a una rela-
ción que tiene cierta similitud con el mundo real y una interpretación propia asociada a ellos. La semántica de
una relación hace referencia a la interpretación de los valores de un atributo en una tupla. En el Capítulo 5
vimos que una relación puede interpretarse como un conjunto de hechos. Si el diseño conceptual descrito en
los Capítulos 3 y 4 se lleva a cabo cuidadosamente y el procedimiento de mapeado del Capítulo 7 se sigue
sistemáticamente, el diseño del esquema relacional debería tener un significado claro.
En general, cuanto más sencillo es explicar la semántica de la relación, mejor será el diseño del esquema de
relación. Para ilustrar esto, considere la Figura 10.1, una versión simplificada del esquema de base de datos
relacional EMPRESA de la Figura 5.5, y la Figura 10.2, que muestra un ejemplo de estado de relación. El sig-
nificado del esquema de relación EMPLEADO es muy simple: cada tupla representa a un empleado, con valo-
res que contienen su nombre (NombreE), su Documento Nacional de Identidad (Dni), su fecha de nacimiento
(FechaNac), su dirección (Dirección) y el número del departamento en el que trabaja (NúmeroDpto). El atri-
buto NúmeroDpto es una foreign key que representa una relación implícita entre EMPLEADO y DEPARTA-
MENTO. Las semánticas de los esquemas DEPARTAMENTO y PROYECTO son también muy directas: cada
tupla DEPARTAMENTO representa a una entidad departamento, y cada tupla PROYECTO es una entidad pro-
yecto. El atributo DniDirector de DEPARTAMENTO relaciona un departamento con el empleado que es direc-
tor del mismo, mientras que NumDptoProyecto de PROYECTO asocia un proyecto con el departamento que
lo gestiona; ambos atributos son foreign keys. La facilidad con la que se pueda explicar el significado de los
atributos de una relación es una medida informal de lo bien que está diseñada esa relación.

Figura 10.1. Una versión simplificada del esquema de base de datos relacional EMPRESA.

EMPLEADO F.K.
NombreE Dni FechaNac Dirección NúmeroDpto
P.K.
DEPARTAMENTO F.K.
NombreDpto NúmeroDpto DniDirector
P.K.

LOCALIZACIONES_DPTO
F.K.
NúmeroDpto UbicaciónDpto

P.K.

PROYECTO F.K.
NombreProyecto NumProyecto UbicaciónProyecto NumDptoProyecto
P.K.

TRABAJA_EN
F.K. F.K.
Dni NumProyecto Horas

P.K.
284 Capítulo 10 Dependencias funcionales y normalización en bases de datos relacionales

La semántica de los otros dos esquemas de relación de la Figura 10.1 es algo más compleja. Cada tupla de
LOCALIZACIONES_DPTO consta de un número de departamento (NúmeroDpto) y una de las localizaciones
del departamento (UbicaciónDpto). Cada tupla de TRABAJA_EN contiene el DNI del empleado
(DniEmpleado), el número de uno de los proyectos en los que trabaja (NumProyecto) y el número de horas
semanales que le dedica al mismo (Horas). Sin embargo, ambos esquemas tienen una interpretación bien defi-
nida y sin ambigüedad. El esquema LOCALIZACIONES_DPTO representa un atributo multivalor de DEPAR-
TAMENTO, mientras que TRABAJA_EN es una relación M:N entre EMPLEADO y PROYECTO. Por consi-
guiente, todo el esquema de relaciones de la Figura 10.1 podría considerarse como fácil de explicar y, por
tanto, bueno desde el punto de vista de contar con una semántica clara. De esta forma, podemos formular la
siguiente directriz informal de diseño.
Directriz 1
Diseñar un esquema de relación para que sea fácil explicar su significado. No combine atributos de varios
tipos de entidad y de relación en una única relación. Intuitivamente, si un esquema de relación se corres-

Figura 10.2. Ejemplo del estado de la base de datos para el esquema de base de datos relacional de la
Figura 10.1.

EMPLEADO
NombreE Dni FechaNac Dirección NúmeroDpto
Pérez Pérez, José 123456789 09-01-1965 Eloy I, 98 5
Campos Sastre, Alberto 333445555 08-12-1955 Avda. Ríos, 9 5
Jiménez Celaya, Alicia 999887777 19-07-1968 Gran Vía, 38 4
Sainz Oreja, Juana 987654321 20-06-1941 Cerquillas, 67 4
Ojeda Ordóñez, Fernando. 666884444 15-09-1962 Portillo, s/n 5
Oliva Avezuela, Aurora 453453453 31-07-1972 Antón, 6 5
Pajares Morera, Luis 987987987 29-03-1969 Enebros, 90 4
Ochoa Paredes, Eduardo 888665555 10-11-1937 Las Peñas, 1 1

DEPARTAMENTO LOCALIZACIONES_DPTO
NombreDpto NúmeroDpto DniDirector NúmeroDpto UbicaciónDpto
Investigación 5 333445555 1 Madrid
Administración 4 987654321 4 Gijón
Sede central 1 888665555 5 Valencia
5 Sevilla
5 Madrid
PROYECTO
NombreProyecto NumProyecto UbicaciónProyecto NumDptoProyecto
ProductoX 1 Valencia 5
ProductoY 2 Sevilla 5
ProductoZ 3 Madrid 5
Computación 10 Gijón 4
Reorganización 20 Madrid 1
Comunicaciones 30 Gijón 4
 10.1 Directrices de diseño informales para los esquemas de relación 285

Figura 10.2. (Continuación).

TRABAJA_EN
Dni NumProyecto Horas
123456789 1 32.5
123456789 2 7.5
666884444 3 40.0
453453453 1 20.0
453453453 2 20.0
333445555 2 10.0
333445555 3 10.0
333445555 10 10.0
333445555 20 10.0
999887777 30 30.0
999887777 10 10.0
987987987 10 35.0
987987987 30 5.0
987654321 30 20.0
987654321 20 15.0
888665555 20 Null

Figura 10.3. Dos esquemas de relación con anomalías en la actualización. (a) EMP_DEPT y (b) EMP_PROY

(a)
EMP_DEPT
NombreE Dni FechaNac Dirección NúmeroDpto NombreDpto DniDirector

(b)
EMP_PROY
Dni NumProyecto Horas NombreE NombreProyecto UbicaciónProyecto
DF1

DF2

DF3

ponde con un tipo de entidad o de relación, es correcto interpretar y explicar su significado. Por contra, si la
relación está compuesta por una mezcla de múltiples entidades y relaciones, se producirá una ambigüedad
semántica y la relación no podrá explicarse con claridad.

Los esquemas de relación de las Figuras 10.3(a) y 10.3(b) tienen también semánticas claras (el lector debe
ignorar por el momento las líneas que aparecen bajo las relaciones; se utilizan para documentar la notación
de dependencia funcional que explicamos en la Sección 10.2). Una tupla en el esquema de relación
EMP_DEPT de la Figura 10.3(a) representa a un solo empleado, aunque incluye información adicional: el
286 Capítulo 10 Dependencias funcionales y normalización en bases de datos relacionales

nombre del departamento en el que trabaja (NombreDpto) y el DNI del director de ese departamento
(DniDirector). En la relación EMP_PROY de la Figura 10.3(b), cada tupla relaciona un empleado con un pro-
yecto, aunque incluye también el nombre del empleado (NombreE), el del proyecto (NombreProyecto) y la
localización de éste (UbicaciónProyecto). Aunque desde el punto de vista lógico no existe nada erróneo en
estas dos relaciones, se considera que tienen un diseño pobre porque violan la directriz 1 al mezclar atributos
de dos entidades del mundo real; EMP_DEPT combina atributos de empleados y departamentos, mientras que
EMP_PROY combina atributos de empleados y proyectos y la relación TRABAJA_EN. Deberían utilizarse
como vistas, aunque esto provocaría problemas cuando se usasen como relaciones base, tal y como veremos
en la siguiente sección.

10.1.2 Información redundante en tuplas y

anomalías en la actualización
Uno de los objetivos de un esquema de diseño es reducir el espacio de almacenamiento utilizado por las rela-
ciones base (y, por tanto, por los ficheros correspondientes). El agrupamiento de atributos en esquemas de
relación tiene un efecto significativo sobre el espacio de almacenamiento. Por ejemplo, compare el espacio
empleado por las dos relaciones base EMPLEADO y DEPARTAMENTO de la Figura 10.2 con el necesario para
EMP_DEPT de la Figura 10.4, que es el resultado de aplicar la operación NATURAL JOIN a EMPLEADO y
DEPARTAMENTO. En EMP_DEPT, los valores de atributo pertenecientes a un departamento particular
(NúmeroDpto, NombreDpto, DniDirector) están repetidos para cada empleado que trabaja en ese departamen-
to. Por contra, la información de cada departamento sólo aparece una vez en la relación DEPARTAMENTO de
la Figura 10.2. Por cada empleado que trabaja en ese departamento, sólo se repite el número de departamen-
to (NúmeroDpto) en la relación EMPLEADO como una foreign key. A la relación EMP_PROY pueden aplicár-
sele comentarios similares (véase la Figura 10.4), que aumenta la relación TRABAJA_EN con atributos adi-
cionales procedentes de EMPLEADO y PROYECTO.
Otro serio problema que aparece cuando se usan las relaciones de la Figura 10.4 como relaciones base son las
anomalías en la actualización, las cuales pueden clasificarse en anomalías de inserción, de borrado y de
modificación.2
Anomalías de inserción. Las anomalías de inserción pueden diferenciarse en dos tipos, que se ilustran con
los siguientes ejemplos basados en la relación EMP_DEPT:
� Para insertar una nueva tupla en EMP_DEPT, debemos incluir los valores correspondientes al departa-
mento en el que dicho empleado trabaja, o valores NULL en el caso de que no lo haga para ninguno.
Por ejemplo, para insertar una nueva tupla para un empleado que trabaja en el departamento número
5, debemos introducir correctamente los valores de atributo del departamento 5, de modo que sean
coherentes con los valores correspondientes del resto de tuplas de EMP_DEPT. En el diseño de la
Figura 10.2 no tenemos que preocuparnos por el problema de la coherencia ya que sólo indicamos el
número de departamento en la tupla de empleado; el resto de valores de atributo del departamento 5
sólo se graban una vez en la base de datos, como una única tupla de la relación DEPARTAMENTO.
� Es complicado insertar un nuevo departamento que aún no tenga ningún empleado en la relación
EMP_DEPT. La única forma de hacerlo es colocando valores NULL en los atributos correspondiente al
empleado. Esto genera un problema, ya que el DNI es la clave principal de EMP_DEPT, y se supone
que cada tupla representa a una entidad empleado, no a una entidad departamento. Además, cuando se
asigna el primer empleado a ese departamento, ya no necesitaremos nunca más esta tupla con valores
NULL. Este problema no se da en el diseño de la Figura 10.2 porque un departamento se introduce en

2 Estas
anomalías fueron identificadas por Codd (1972a) para justificar la necesidad de normalización en las relaciones, como ya comen-
taremos en la Sección 10.3.
 10.1 Directrices de diseño informales para los esquemas de relación 287

Figura 10.4. Ejemplo de los estados de EMP_DEPT y EMP_PROY resultantes de aplicar una NATURAL JOIN
a las relaciones de la Figura 10.2. Éstas deberían almacenarse como relaciones base por motivos de rendi-
miento.
Redundancia

EMP_DEPT
NombreE Dni FechaNac Dirección NúmeroDpto NombreDpto DniDirector
Pérez Pérez, José 123456789 09-01-1965 Eloy I, 98 5 Investigación 333445555
Campos Sastre, Alberto 333445555 08-12-1955 Avda. Ríos, 9 5 Investigación 333445555
Jiménez Celaya, Alicia 999887777 19-07-1968 Gran Vía, 38 4 Administración 987654321
Sainz Oreja, Juana 987654321 20-06-1941 Cerquillas, 67 4 Administración 987654321
Ojeda Ordóñez, Fernando. 666884444 15-09-1962 Portillo, s/n 5 Investigación 333445555
Oliva Avezuela, Aurora 453453453 31-07-1972 Antón, 6 5 Investigación 333445555
Pajares Morera, Luis 987987987 29-03-1969 Enebros, 90 4 Administración 987654321
Ochoa Paredes, Eduardo 888665555 10-11-1937 Las Peñas, 1 1 Sede central 888665555

Redundancia Redundancia

EMP_PROY

Dni NumProyecto Horas NombreE NombreProyecto UbicaciónProyecto

123456789 1 32.5 Pérez Pérez, José ProductoX Valencia
123456789 2 7.5 Pérez Pérez, José ProductoY Sevilla
666884444 3 40.0 Ojeda Ordóñez, Fernando. ProductoZ Madrid
453453453 1 20.0 Oliva Avezuela, Aurora ProductoX Valencia
453453453 2 20.0 Oliva Avezuela, Aurora ProductoY Sevilla
333445555 2 10.0 Campos Sastre, Alberto ProductoY Sevilla
333445555 3 10.0 Campos Sastre, Alberto ProductoZ Madrid
333445555 10 10.0 Campos Sastre, Alberto Computación Gijón
333445555 20 10.0 Campos Sastre, Alberto Reorganización Madrid
999887777 30 30.0 Jiménez Celaya, Alicia Comunicaciones Gijón
999887777 10 10.0 Jiménez Celaya, Alicia Computación Gijón
987987987 10 35.0 Pajares Morera, Luís Computación Gijón
987987987 30 5.0 Pajares Morera, Luís Comunicaciones Gijón
987654321 30 20.0 Sainz Oreja, Juana Comunicaciones Gijón
987654321 20 15.0 Sainz Oreja, Juana Reorganización Madrid
888665555 20 Null Ochoa Paredes, Eduardo Reorganización Madrid

la relación DEPARTAMENTO independientemente de que existan o no empleados trabajando en él, y

siempre que un empleado se asigne a ese departamento se inserta una tupla en EMPLEADO.
Anomalías de borrado. El problema de las anomalías de borrado está relacionado con la segunda anoma-
lía de inserción comentada anteriormente. Si eliminamos de EMP_DEPT una tupla empleado que representa
al último que trabaja para un departamento dado, la información concerniente a ese departamento se pierde
de la base de datos. Este problema no ocurre en la base de datos de la Figura 10.2 porque las tuplas DEPAR-
TAMENTO se almacenan de forma separada.
288 Capítulo 10 Dependencias funcionales y normalización en bases de datos relacionales

Anomalías de modificación. En EMP_DEPT, si cambiamos el valor de uno de los atributos de un depar-

tamento particular (por ejemplo, el director del departamento 5), debemos actualizar las tuplas de todos los
empleados que trabajan en ese departamento; en caso de no hacerlo, la base de datos se volverá inconsisten-
te. Si falla la actualización de alguna tupla, el mismo departamento tendrá dos valores diferentes como direc-
tor en distintas tuplas de empleado, lo que será incorrecto.3
Basándonos en las tres anomalías precedentes, podemos enunciar la siguiente directriz.
Directriz 2
Diseñar los esquemas de relación base de forma que no se presenten anomalías de inserción, borrado o actua-
lización en las relaciones. En caso de que aparezca alguna de ellas, anótela claramente y asegúrese de que los
programas que actualizan la base de datos operarán correctamente.
La segunda directriz es coherente, en cierto modo, con una reafirmación de la primera directriz. Podemos ver
también la necesidad de una metodología más formal para evaluar si un diseño cumple estas directrices. Las
Secciones de la 10.2 a la 10.4 muestran estas necesidades formales. Es importante indicar que estas directri-
ces pueden, a veces, tener que violarse para mejorar el rendimiento de ciertas consultas. Por ejemplo, si una
consulta importante recupera información relativa al departamento de un empleado junto con atributos de ese
empleado, podría usarse el esquema EMP_DEPT como relación base. Sin embargo, deben indicarse y justifi-
carse las anomalías de EMP_DEPT (por ejemplo, usando triggers o procedimientos almacenados que lleva-
rían a cabo actualizaciones automáticas) de modo que, si se actualiza la relación base, no nos encontremos
con incoherencias. En general, es aconsejable usar relaciones base que estén libres de anomalías y especificar
vistas que incluyan las concatenaciones necesarias para recuperar los atributos que se referencian frecuente-
mente en las consultas. Esto reduce el número de términos JOIN especificados en la consulta, simplificando
la escritura correcta de la consulta y, en muchos casos, mejorando el rendimiento.4

10.1.3 Valores NULL en las tuplas

En algunos diseños podemos agrupar muchos atributos en una relación “muy grande”. Si muchos de los atri-
butos no se aplican a todas las tuplas de la relación, nos encontraremos con muchos valores NULL en esas
tuplas. Esto puede desperdiciar espacio de almacenamiento y puede inducir a problemas a la hora de enten-
der el significado de los atributos con la especificación de operaciones JOIN a nivel lógico.5 Otro problema
con los NULL es cómo contabilizarlos cuando se aplican operaciones de agregación como COUNT o SUM. Las
operaciones SELECT o JOIN implican comparaciones. Si hay presentes valores NULL, los resultados serán
impredecibles.6 Además, los NULL pueden tener múltiples interpretaciones:
� El atributo no se aplica a esta tupla.
� El valor de atributo de esta tupla es desconocido.
� El valor es conocido pero está ausente, es decir, aún no se ha grabado.

3 Esto no es tan serio como otros problemas, ya que todas las tuplas pueden actualizarse con una sola sentencia SQL.
4 El rendimiento de una consulta especificada en una vista que es la concatenación de varias relaciones base depende de cómo el DBMS

implementa la vista. Muchos RDBMSs materializan las vistas usadas frecuentemente de forma que no se tengan que llevar a cabo las
concatenaciones más habituales. El DBMS es responsable de la actualización de la vista materializada (ya sea inmediata o periódicamen-
te) siempre que las relaciones base se modifiquen.
5 Esto se debe a que las concatenaciones externas e internas producen resultados diferentes cuando existen valores NULL implicados en

ellas. Los usuarios deben, por tanto, tener cuidado con los distintos significados de cada tipo de concatenación. Lo que resulta razonable
para usuarios sofisticados, puede ser difícil para otros.
la Sección 8.5.1 presentamos varias comparaciones que implican valores NULL donde el resultado (en la lógica de tres valores) es
6 En

TRUE, FALSE y UNKNOWN.

 10.1 Directrices de diseño informales para los esquemas de relación 289

El tener la misma representación para todos los NULL compromete los diferentes significados que pueden
tener. Por consiguiente, podemos establecer otra directriz.

Directriz 3
Hasta donde sea posible, evite situar en una relación base atributos cuyos valores sean NULL frecuentemente.
En caso de no poderse evitar, asegúrese de que se aplican sólo en casos excepcionales y no los aplique a la
mayor parte de las tuplas de la relación.
Utilizar el espacio eficientemente y evitar concatenaciones son los dos criterios principales que determinan si
incluir las columnas que pueden tener valores NULL en una relación o tener una relación separada para esas
columnas (con las columnas clave apropiadas). Por ejemplo, si sólo el 10 por ciento de los empleados tienen
oficinas individuales, no es razón suficiente para la inclusión de un atributo NúmeroOficina en la relación
EMPLEADO; en lugar de ello, se puede crear una relación OFICINAS_EMPS(DniEmpleado, NúmeroOficina)
que incluya las tuplas de los empleados con oficinas individuales.

10.1.4 Generación de tuplas falsas

Considere los dos esquemas de relación EMP_LOCS y EMP_PROY1 de la Figura 10.5(a), la cual puede usar-
se en lugar de la relación simple EMP_PROY de la Figura 10.3(b). Una tupla en EMP_LOCS significa que el
empleado cuyo nombre es NombreE trabaja en algún proyecto cuya localización es UbicaciónProyecto. Una
tupla EMP_PROY1 se refiere al hecho de que el empleado cuyo Documento Nacional de Identidad es Dni tra-
baja un número de Horas por semana en el proyecto cuyo nombre, número y ubicación son NombreProyecto,
NumProyecto y UbicaciónProyecto. La Figura 10.5(b) muestra el estado de relación de EMP_LOCS y
EMP_PROY1 correspondiente a la relación EMP_PROY de la Figura 10.4, la cual se obtiene aplicando la ope-
ración PROYECCIÓN ( ) adecuada a EMP_PROY [ignore por ahora las líneas discontinuas de la Figura
10.5(b)].
Supongamos que utilizamos EMP_PROY1 y EMP_LOCS como relaciones base en lugar de EMP_PROY. Esto
produce un diseño de esquema incorrecto algo peculiar porque no podemos recuperar la información origina-
ria de EMP_PROY desde EMP_PROY1 y EMP_LOCS. Si intentamos llevar a cabo una operación
CONCATENACIÓN NATURAL en estas relaciones, el resultado produce muchas más tuplas que las existentes
en el conjunto original de EMP_PROY. En la Figura 10.6, sólo se muestra la aplicación de la concatenación
a las tuplas que están por encima de las líneas discontinuas de la Figura 10.5(b) (para reducir el tamaño de la
relación resultante). Las tuplas adicionales que no se encontraban en EMP_PROY reciben el nombre de tuplas
falsas (spurious tuples) porque representa información falsa que no es válida. Las tuplas falsas están marca-
das con asteriscos (∗) en la Figura 10.6.
No es aconsejable descomponer EMP_PROY en EMP_LOCS y EMP_PROY1 porque cuando deshacemos la
CONCATENACIÓN usando una CONCATENACIÓN NATURAL, no obtenemos la información original correc-
ta. Esto es así porque, en este caso, UbicaciónProyecto es el atributo que relaciona EMP_LOCS y
EMP_PROY1, y no es ni una clave principal ni una foreign key en EMP_LOCS o EMP_PROY1. Ahora esta-
mos en condiciones de definir otra directriz de diseño.

Directriz 4
Diseñar los esquemas de relación de forma que puedan concatenarse con condiciones de igualdad en los atri-
butos que son parejas de clave principal y foreign key de forma que se garantice que no se van a generar tuplas
falsas. Evite las relaciones que contienen atributos coincidentes que no son combinaciones de foreign key y
clave principal porque la concatenación de estos atributos puede producir tuplas falsas.
Esta directriz informal debe ser, obviamente, redefinida de una manera más adecuada. En el Capítulo 11 tra-
taremos una condición formal llamada propiedad de reunión no aditiva que garantiza que ciertas concatena-
ciones no producen tuplas falsas.
290 Capítulo 10 Dependencias funcionales y normalización en bases de datos relacionales

Figura 10.5. Diseño particularmente pobre de la relación EMP_PROY de la Figura 10.3(b). (a) Los dos
esquemas de relación EMP_LOCS y EMP_PROY1. (b) El resultado de proyectar la extensión de EMP_PROY
de la Figura 10.4 a las relaciones EMP_LOCS y EMP_PROY1.
(a)
EMP_LOCS
NombreE UbicaciónProyecto

P.K.
EMP_PROJ1
Dni NumProyecto Horas NombreProyecto UbicaciónProyecto

P.K.
(b)
EMP_LOCS EMP_PROJ1
Ubicación- Ubicación-
NombreE Dni NumProyecto Horas NombreProyecto
Proyecto Proyecto
Pérez Pérez, José Valencia 123456789 1 32.5 ProductoX Valencia

Pérez Pérez, José Surgarland 123456789 2 7.5 ProductoY Sevilla

Ojeda Ordóñez, Fernando. Madrid 666884444 3 40.0 ProductoZ Madrid

Oliva Avezuela, Aurora Valencia 453453453 1 20.0 ProductoX Valencia

Oliva Avezuela, Aurora Surgarland 453453453 2 20.0 ProductoY Sevilla

Campos Sastre, Alberto Surgarland 333445555 2 10.0 ProductoY Sevilla

Campos Sastre, Alberto Madrid 333445555 3 10.0 ProductoZ Madrid

Campos Sastre, Alberto Gijón 333445555 10 10.0 Computación Gijón

Jiménez Celaya, Alicia Gijón 333445555 20 10.0 Reorganización Madrid

Pajares Morera, Luis Gijón 999887777 30 30.0 Comunicaciones Gijón

Sainz Oreja, Juana Gijón 999887777 10 10.0 Computación Gijón

Sainz Oreja, Juana Madrid 987987987 10 35.0 Computación Gijón

Ochoa Paredes, Eduardo Madrid 987987987 30 5.0 Comunicaciones Gijón

987654321 30 20.0 Comunicaciones Gijón
987654321 20 15.0 Reorganización Madrid
888665555 20 NULL Reorganización Madrid

10.1.5 Resumen y explicación acerca de las directrices de diseño

En las Secciones de la 10.1.1 a la 10.1.4, hemos visto situaciones que provocan esquemas de relación proble-
máticos, y hemos propuesto unas directrices informales para definir un buen diseño relacional. Los problemas
que hemos apuntado, que pueden detectarse sin la intervención de herramientas de análisis adicionales, son
los siguientes:
� Anomalías que causan trabajo redundante durante la inserción y modificación de una relación, y que
pueden causar pérdidas accidentales de información durante el borrado de la misma.
� Desaprovechamiento del espacio de almacenamiento debido a valores NULL y la dificultad de llevar a
cabo operaciones de selección, agregación y concatenación debido a estos valores.
 10.2. Dependencias funcionales 291

Figura 10.6. Resultado de aplicar una CONCATENACIÓN NATURAL a las tuplas que se encuentran por enci-
ma de las líneas discontinuas en EMP_PROY1 y EMP_LOCS de la Figura 10.5. Las tuplas falsas generadas
aparecen marcadas con asteriscos.

Dni NumProyecto Horas NombreProyecto UbicaciónProyecto NombreE

123456789 1 32.5 ProductoX Valencia Pérez Pérez, José
* 123456789 1 32.5 ProductoX Valencia Oliva Avezuela, Aurora
123456789 2 7.5 ProductoY Sevilla Pérez Pérez, José
* 123456789 2 7.5 ProductoY Sevilla Oliva Avezuela, Aurora
* 123456789 2 7.5 ProductoY Sevilla Campos Sastre, Alberto
666884444 3 40.0 ProductoZ Madrid Ojeda Ordóñez, Fernando.
* 666884444 3 40.0 ProductoZ Madrid Campos Sastre, Alberto
* 453453453 1 20.0 ProductoX Valencia Pérez Pérez, José
453453453 1 20.0 ProductoX Valencia Oliva Avezuela, Aurora
* 453453453 2 20.0 ProductoY Sevilla Pérez Pérez, José
453453453 2 20.0 ProductoY Sevilla Oliva Avezuela, Aurora
* 453453453 2 20.0 ProductoY Sevilla Campos Sastre, Alberto
* 333445555 2 10.0 ProductoY Sevilla Pérez Pérez, José
* 333445555 2 10.0 ProductoY Sevilla Oliva Avezuela, Aurora
333445555 2 10.0 ProductoY Sevilla Campos Sastre, Alberto
* 333445555 3 10.0 ProductoZ Madrid Ojeda Ordóñez, Fernando.
333445555 3 10.0 ProductoZ Madrid Campos Sastre, Alberto
333445555 10 10.0 Computación Gijón Campos Sastre, Alberto
* 333445555 20 10.0 Reorganización Madrid Ojeda Ordóñez, Fernando.
333445555 20 10.0 Reorganización Madrid Campos Sastre, Alberto
*
*
*
� Generación de datos incorrectos y falsos durante las concatenaciones en relaciones base incorrecta-
mente relacionadas.
En el resto de este capítulo vamos a presentar conceptos y teorías formales que pueden utilizarse para definir
de forma más precisa la idoneidad y la mala calidad de un esquema de relación individual. En primer lugar
comentaremos la dependencia funcional como una herramienta de análisis. A continuación especificaremos
las tres formas normales y la BCNF (Forma normal de Boyce-Codd, Boyce-Codd Normal Form) para un
esquema de relación. En el Capítulo 11, definimos formas normales adicionales que están basadas en depen-
dencias de tipos de datos adicionales llamadas dependencias multivalor y dependencias de concatenación.

10.2 Dependencias funcionales

El concepto básico más importante en la teoría de diseño de un esquema relacional es el de una dependencia
funcional. En esta sección definiremos formalmente el concepto, mientras que en la Sección 10.3 veremos
cómo usarlo para definir formas normales para los esquemas de relación.

10.2.1 Definición de dependencia funcional

Una dependencia funcional es una restricción que se establece entre dos conjuntos de atributos de la base de
datos. Supongamos que nuestro esquema de base de datos relacional tiene n atributos A1, A2, . . . , An; pense-