Tema 7. Diseño de bases de datos relacionales.

Juan Ignacio Rodrı́guez de León

Resumen
Normalización y dependencias de datos. Motivación de cada forma
normal. Significado intuitivo de cada tipo de dependencia de datos.
Primera forma normal. Dificultades en el diseño de bases de datos rela-
cionales. Dependencias funcionales. Descomposición. Propiedades de-
seables de la descomposición. Forma normal de Boyce-Codd. Tercera
forma normal. Cuarta forma normal. Otras formas normales. Proceso
general del diseño de bases de datos.

Índice
1. Normalización de datos 2
1.1. Formas normales . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. primera forma normal (1NF) . . . . . . . . . . . . . . . . . . 2
1.3. dependencia funcional . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Segunda forma normal (2FN) . . . . . . . . . . . . . . . . . . 5
1.5. Tercera forma normal (3NF) . . . . . . . . . . . . . . . . . . . 5
1.6. Forma normal de Boyce-Codd (BCNF) . . . . . . . . . . . . . 6
1.7. Comparación entre FNBC y 3FN . . . . . . . . . . . . . . . . 7
1.8. Dependencias multivaloradas . . . . . . . . . . . . . . . . . . 7
1.9. Cuarta forma normal 4NF . . . . . . . . . . . . . . . . . . . . 9

2. Otras formas normales 9

3. Proceso general del diseño de bases de datos 9

3.1. Desnormalización para el rendimiento . . . . . . . . . . . . . 10
3.2. Otros problemas de diseño . . . . . . . . . . . . . . . . . . . . 10

1
1 NORMALIZACIÓN DE DATOS 2

El objetivo del diseño de las bases de datos relacionales es la generación

de un conjunto de esquemas relacionales que nos permita almacenar la
información sin redundancias innecesarias, pero que también nos permita
recuperar fácilmente esa información. Un enfoque es el diseño de esquemas
que se hallen en una forma normal adecuada. Para determinar si el esquema
de una relación se halla en una de las formas normales deseables hace falta
información adicional sobre la empresa real que ese está modelando con la
base de datos. En este capı́tulo se introduce el concepto de la dependen-
cia funcional. Luego se definirán las formas normales en términos de las
dependencias funcionales y otros tipos de dependencias de datos.

1. Normalización de datos
La normalización de datos consiste en una serie de pasos que conducen a
un diseño de base de datos relacional que permite un almacenamiento de
datos consistente, sin redundancias innecesarias.
A veces, por cuestiones como capacidad del sistema, tamaño de los
datos, etc. es deseable desnormalizar, para obtener un mejor rendimiento,
aun a costa de reducir la consistencia.

1.1. Formas normales

Una tabla o relación se dice que está en una determinada forma normal
si satisface ciertas condiciones. En sus primeros trabajos, Edgar F. Codd
definió tres formas normales, aunque en la actualidad este modelo se ha
ampliado. Normalmente, cuando se habla de una base de datos normalizada
se refiere a que todas las tablas estén en tercera forma normal.
Cada forma normal incluye a las de nivel inferior, por ejemplo, si una
tabla está en tercera forma normal, también lo está en segunda y en primera
forma normal.

1.2. primera forma normal (1NF)

Una tabla está en primera forma normal si todos los valores de todas las
columnas son atómicos. Esto es otra forma de decir que no se aceptarán como
atributos de la relación listas de valores, sino valores simples. Una tabla que
no cumpliera esta condición se normalizarı́a creando una segunda tabla,
dependiente de la primera mediante una clave externa, y que contuviera
los valores múltiples.
Otra forma de describir que los valores de una columna sean atómicos
es que cada columna sólo contendrá los valores del dominio que le corre-
sponde, es decir, no se ”reciclará” una columna para almacenar otro tipo de
dato. De la misma manera, no se utilizarán varias columnas para almacenar
el mismo valor (no se duplicarán columnas).
1 NORMALIZACIÓN DE DATOS 3

Como ejemplo de una tabla no normalizada, supongamos que tenemos

que guardar información de los ingresos y saldos que tenemos en nuestras
cuentas bancarias. Supongamos que trabajamos con los bancos Alfabank,
BBLAV y CityCrash. Un primer enfoque podrı́a ser la relación:

Operación = (Fecha, Ingreso, Al f abank, BBLAV, CityCrash)

Suponemos que podemos usar el campo Fecha como clave primaria.
Y un ejemplo de datos de la tabla podrı́a ser:
Operación
Fecha Ingreso Alfabank BBLAV CityCrash
1/ene/2005 1500 NULL 1500 NULL
3/ene/2005 100 NULL 1500 100
7/ene/2005 200 200 1500 100
14/mar/2005 -50 200 1450 100
Estamos repitiendo las columnas de los saldos de los bancos, luego
la relación no está en primera forma normal. Para solucionarlo, primero
eliminamos las columnas repetidas, con lo que nos quedarı́a la relación ası́:

Operación = (Fecha, Ingreso)

Operación
Fecha Ingreso
1/ene/2005 1500
3/ene/2005 100
7/ene/2005 200
14/mar/2005 -50
y crearı́amos una nueva relación, Saldos, relacionada con la primera
mediante una clave externa, para poder almacenar la información de las
columnas duplicadas

Saldos = (Fecha, Banco, Saldo)

Que, en nuestro ejemplo, contendrı́a los siguientes datos:
Saldo
Fecha Banco Saldo
1/ene/2005 BBLAV 1500
3/ene/2005 CityCrash 100
7/ene/2005 Alfabank 200
14/mar/2005 BBLAV 1450
Obsérvese que esta normalización ya presenta varias ventajas: Se aprovecha
mejor el espacio de almacenamiento, se elimina valores nulos de la base de
datos y se simplifican tareas como crear un nuevo banco o anotar un ingreso.
1 NORMALIZACIÓN DE DATOS 4

1.3. dependencia funcional

Antes de pasar a la segunda forma normal tenemos que definir el con-
cepto de dependencia funcional.
Sean X e Y dos subconjuntos de atributos de la relación R. Se dice que
existe una dependencia funcional, denotada por X → Y si se cumple que,
para cualesquiera dos tuplas t1 y t2 de R tales que t1 [X] = t2 [X], entonces
obligatoriamente t1 [Y] = t2 [Y].
Esta significa que los valores de los atributos Y de una tupla de R
dependen de los valores de los atributos de X. Dicho de otra manera, si
conozco los valores de X de una tupla, puedo obtener o calcular de forma
inmediata los valores de Y.
Nótese que el concepto de dependencia funcional no depende de los
datos que en un momento determinado tenga la tabla, sino que es una
noción semántica. Si existen o no dependencias funcionales entre atributos
no lo determina una serie abstracta de reglas, sino, más bien, los modelos
mentales del usuario y las reglas de negocio de la organización o empresa
para la que se desarrolla el sistema de información.
Un mismo atributo puede determinar funcionalmente a varios atributos
lo cual se denota a → (b1 , b2 , . . . , bn ). También puede darse una dependencia
funcional mutua: a → b y b → a, lo cual se representa a ↔ b.
Las dependencias funcionales verifican una serie de propiedades de-
nominadas axiomas de Armstrong:

Reflexividad o Dependencia trivial. A partir de cualquier atributo o con-

junto de atributos siempre puede deducirse él mismo: x → x.

Aumentatividad. Si x → y entonces (x, z) → y. Ası́ se puede aumentar

trivialmente el antecedente de una dependencia. Ejemplo: si con el
DNI se determina el nombre de una persona, entonces con el DNI
más la dirección también se determina el nombre.

Proyectividad. Si x → (y, z) entonces x → y. Ejemplo: si a partir del DNI

es posible deducir el nombre y la dirección de una persona, entonces
con el DNI es posible determinar el nombre.

Aditividad. Si x → y y z → w entonces (x, z) → (y, w). Ejemplo: si con

el DNI se determina el nombre y con la dirección el teléfono de una
persona, entonces con el DNI y la dirección podrá determinarse el
nombre y el teléfono.

Transitividad o enlace de dependencias funcionales . Si x → y e y → z

entonces x → z. Ejemplo: si con el DNI se puede determinar el código
de la provincia de residencia de una persona y con éste código puede
determinarse el nombre de la provincia, entonces con el DNI puede
determinarse el nombre de la provincia.
1 NORMALIZACIÓN DE DATOS 5

También se usa la expresión Y depende funcionalmente de X para

señalar que hay una dependencia funcional entre X e Y.

1.4. Segunda forma normal (2FN)

Para que una tabla esté en segunda forma normal es necesario:

1. Que esté en primera forma normal.

2. Que no exista ninguna dependencia funcional entre una parte de la

clave primaria y un atributo que no forme parte de la clave. Dicho de
otra manera, que cada atributo de la tabla que no forma parte de la
clave depende funcionalmente de toda la clave y no de algún subcon-
junto de ella. Si la clave están formada por un único atributo entonces
ese esquema ya estará, obviamente, en segunda forma normal.

Como ejemplo de una normalización 2FN, considérese la relación Com-

ponentes:

Componentes = (id componente, proveedor, precio, direccion proveedor)

La clave primaria está compuesta por los atributos id componente y

proveedor. Esto es correcto, porque el mismo componente puede ser sum-
inistrado por diferentes proveedores. El atributo precio también está correc-
tamente ubicado en esta relación, porque es totalmente dependiente de la
clave primaria -diferentes proveedores pueden tener distintos precios para
la misma pieza-.
Sin embargo, la dirección del proveedor sólo depende del nombre del
proveedor, por lo que esta relación no cumple la segunda forma normal.
Este atributo deberı́a ubicarse en una nueva relación, de la forma

Proveedor = (proveedor, direccion proveedor)

1.5. Tercera forma normal (3NF)

Para que una tabla esté en tercera forma normal es necesario:

1. Que esté en segunda forma normal.

2. Que todos los atributos que no formen parte de la clave primaria

sean mutuamente independientes; es decir, que no haya dependencias
transitivas.
Otra forma de verlo es que para toda dependencia funcional a → b
(siendo a , b) que se verifique en una relación, a siempre forma parte
de la clave primaria
1 NORMALIZACIÓN DE DATOS 6

Este es el esquema de normalización más utilizado. Llegados a este

punto, todos los atributos que no forman parte de la clave dependen de
la clave primaria, de toda la clave primaria y de nada más que de la clave
primaria (con la excepción de las dependencias triviales del tipo A → A).
Como ejemplo, considérese de nuevo la relación componente, ahora
descrita de la siguiente manera:

Componente = (Id Componente, nombre proveedor, direccion proveedor)

La dirección del proveedor no deberı́a formar parte de esta relación,

porque rompe la tercera forma normal. Existe una dependencia funcional
transitiva, porque nombre proveedor → direccion proveedor, e Id Componente →
nombre proveedor, luego Id Componente → direccion proveedor. En otras pal-
abras, ni nombre proveedor ni direccion proveedor forman parte de la
clave, y existe una dependencia entre ellos.
Para remediarlo, es necesario crear una nueva relación Proveedor, de la
forma:

Proveedor = (nombre proveedor, direccion proveedor)

y dejar la relación Componente en la forma:

Componente = (Id Componente, nombre proveedor)

1.6. Forma normal de Boyce-Codd (BCNF)

La forma normal de Boyce-Codd es una versión más fuerte de la tercera
forma normal. Aquı́ todos los atributos (incluidos los que forman parte de
la clave primaria) dependen de la clave primaria, de toda la clave primaria y
de nada más que de la clave primaria (con la excepción de las dependencias
triviales del tipo A → A).
Se basa en el concepto de determinante funcional: uno o varios atributos
de una tabla de los cuales dependen funcionalmente de forma completa
algún otro atributo de la misma tabla.
Una relación está en FNBC si cada determinante funcional es una clave
candidata de la tabla. Ası́ se garantiza que se han elegido bien las claves, al
no existir dependencias funcionales entre atributos que no son clave. Cada
vez que se verifica una dependencia funcional α → β entonces α es clave
primaria o candidata con seguridad.
Otra forma de verlo es que se debe cumplir que todas las dependencias
funcionales cumplen que en su parte izquierda solo aparecen atributos que
son parte de una clave candidata. Esta forma normal es más restrictiva
que la tercera y tiene la interesante propiedad de que su cumplimiento
implica la satisfacción de FN3 o sea que una relación que esté en FNBC
está automáticamente en FN3.
1 NORMALIZACIÓN DE DATOS 7

Las afinidades en BCNF no tienen anomalı́as con respecto a las depen-

dencias funcionales. Las siguientes formas normales eliminar las anomalı́as
que pueden surgir de situaciones distintas a las dependencias funcionales.

1.7. Comparación entre FNBC y 3FN

De las dos formas normales para los esquemas de las bases de datos
relacionales, 3FN y FNBC, hay ventajas en 3FN porque se sabe que siempre
es posible obtener un diseño en 3FN sin sacrificar la reunión sin pérdida o
la conservación de las dependencias.
Sin embargo, hay inconvenientes en 3FN: si no se eliminan todas las
dependencias transitivas de las relaciones de los esquemas, puede que se
tengan que emplear valores nulos para representar algunas de las relaciones
significativas posibles entre los datos, y está el problema de repetición de la
información.

1.8. Dependencias multivaloradas

Para poder explicar la cuarta forma normal, necesitamos definir el con-
cepto de dependencia funcional multivalorada.
Dada una relación R(A, B, C), hay una dependencia multivalorada entre
A y B, denotada por A →→ B, si y sólos si el conjunto de valores posibles
de B, dado unos valores concretos de A y C (a:A, c:C), sólo depende de a
y es independiente de c. Es decir, que si tenemos un valor concreto a para
el atributo A, existe un conjunto limitado de posibles valores de B, y ese
conjunto de valores es independiente de cualquiera que fuera el valor c
Toda dependencia funcional es también una dependencia multivalorada
(pero no al revés).
La definición formal de dependencia multivalorada, para aquellos espı́ri-
tus fuertes que ansı́an un desafı́o, serı́a:
Sea R un esquema de relación y sean α ⊆ R y β ⊆ R. La dependencia
multivalorada α →→ β se cumple en r(R) si para todo par de tuplas t1 y t2
de r tales que t1 [α] = t2 [β], existen unas tuplas t3 y t4 de r tales que:

t1 [α] = t2 [α] = t3 [α] = t4 [α]

t3 [β] = t1 [β]
t3 [R − β] = t2 [R − β]
t4 [β] = t2[β]
t4 [R − β] = t1[R − β]
Las dependencias multivaloradas nos producen anomalı́as cuando vienen
en parejas; veámoslo con un ejemplo:
1 NORMALIZACIÓN DE DATOS 8

Supongamos una relación de un fabricante de zapatos, en la cual que

un determinado modelo de zapato se puede fabricar en distintas tallas,
ası́ como en diferentes colores. Podemos representar esto con la siguiente
relación:

Catalogo = (Color, Modelo, Talla)

La clave primara de la tabla es la composición de los tres atributos.

No hay dependencias funcionales entre ellos, ası́ que la relación es BCNF.
Sin embargo, se presentan ciertas ambigüedades, al ser independientes los
colores de las tallas. Existe una dependencia multivalorada entre el modelo
y los posibles colores, y existe otra dependencia multivalorada entre el
modelo y las tallas, y no existe ninguna relación entre los posibles colores y
tallas. Ası́ las cosas, veremos a continuación que no está claro como debemos
almacenar la información.
Supongamos, por ejemplo, un modelo de zapato M, que se produce en
dos colores (azul y negro) y en dos tallas (40 y 42).
Una forma de almacenar esta información serı́a la siguiente:

Catalogo
Color Modelo Talla
azul M 40
negro M 42

No tenemos problemas cuando intentamos acceder a la información de

forma separada, pro ejemplo, las consultas ¿En cuantos colores se comer-
cializa el modelo M? y ¿En cuantas tallas se comercializa el modelo M? se
pueden realizar fácilmente.
Sin embargo, este sistema es confuso y propenso a error: ¿No existen
zapatos del modelo M en color azul y de la talla 42?
Existe otras posibilidad 1 , que serı́a almacenar todas las combinaciones,
ası́:

Catalogo
Color Modelo Talla
azul M 40
azul M 42
negro M 40
negro M 42

Sin embargo, esto nos produce más problemas de los que resuelve:
En primer lugar, es redundante, y ocupa más espacio del necesario.
1
Que existan distintas formas de almacenar la misma información en una base de datos
ya es, en si, un problema de falta de normalización
2 OTRAS FORMAS NORMALES 9

Además, nos produce anomalı́as de inserción. No es posible almacenar

las posibles tallas si no conocemos los colores en que se va a fabricar, a no
ser que permitamos valores nulos en el campo color. De igual forma, en
caso de querer incorporar un nuevo color, no podemos limitarnos a realizar
una única inserción, habrá que realizar n inserciones, siendo n el número
de tallas distintas en que se fabrica el modelo.
De igual forma, hay anomalı́as de borrado. retirar una posible talla del
catálogo implica borrar n tuplas, tantas como colores posibles hubiera.
Para resolver estas ambigüedades, la solución pasa por dividir la relación
en dos, de la forma:

Colores = (Modelo, Color)

Tallas = (Modelo, Talla)

1.9. Cuarta forma normal 4NF

Una relación está en cuarta forma normal si está en BCNF y no tiene
dependencias multivaloradas.

2. Otras formas normales

La cuarta forma normal no es, de ningún modo, la forma normal ((definitiva)).
Como ya se ha visto, las dependencias multivaloradas ayudan a compren-
der y a abordar algunas formas de repetición de la información que no
pueden comprenderse en términos de las dependencias funcionales. Hay
tipos de restricciones denominadas dependencias de reunión que gener-
alizan las dependencias multivaloradas y llevan a otra forma normal de-
nominada forma normal de reunión por proyección (FNRP) o Quinta forma
normal (5NF).
Hay una clase de restricciones todavı́a más generales, que lleva a una
forma normal denominada forma normal de dominios y claves (FNDC).

3. Proceso general del diseño de bases de datos

Cuando se parte de un diagrama E-R, identificando correctamente todas
las entidades, las tablas generadas normalmente no necesitan más normal-
ización.
No obstante, puede haber dependencias funcionales entre los atributos
de una entidad. Sin embargo, la mayor parte de los problemas surgen de
un mal diseño del diagrama E-R, por lo que las dependencias funcionales
pueden ayudar a detectar el mal diseño E-R.
3 PROCESO GENERAL DEL DISEÑO DE BASES DE DATOS 10

Un segundo enfoque es partir de un único esquema de relación que con-

tenga todos los atributos de interés y descomponerlo. Uno de los objetivos
al escoger una descomposición es que sea una descomposición de reunión
sin pérdida, es decir, que a partir de las relaciones resultantes se pueda
obtener la relación inicial mediante reuniones.

3.1. Desnormalización para el rendimiento

A veces los diseñadores de bases de datos escogen un esquema que
tiene información redundante; es decir, que no está normalizada. Utilizan
la redundancia para mejorar el rendimiento para aplicaciones concretas. La
penalización sufrida por no emplear un esquema normalizado es el trabajo
extra (en términos de tiempo de codificación y de tiempo de ejecución) de
mantener consistentes los datos redundantes.
El proceso de tomar un esquema normalizado y hacerlo no normalizado
se denomina desnormalización, y los diseñadores lo utilizan para ajustar el
rendimiento de los sistemas para dar soporte a las operaciones crı́ticas en
el tiempo.
Una alternativa mejor, soportada hoy en dı́a por muchos sistemas de
bases de datos, es emplear el esquema normalizado y, de manera adicional,
almacenar la reunión o cuenta e impositor en forma de vista materializa-
da. (Recuérdese que una vista materializada es una vista cuyo resultado se
almacena en la base de datos y se actualiza cuando se actualizan las rela-
ciones utilizadas en la vista.) Al igual que la desnormalización, el empleo
de las vistas materializadas supone sobrecargas de espacio y de tiempo; sin
embargo, presenta la ventaja de que conservar la vista actualizada es labor
del sistema de bases de datos, no del programador de la aplicación.

3.2. Otros problemas de diseño

Hay algunos aspectos del diseño de bases de datos que la normalización
no aborda y, por tanto, pueden llevar a un mal diseño de la base de datos.
A continuación se ofrecerán algunos ejemplos; evidentemente, conviene
evitar esos diseños.
Considérese la base de datos de una empresa, donde se desea almacenar
los beneficios de las compañı́as de varios años. Se puede utilizar la relación:

bene f icios(id empresa, anio, importe)

para almacenar la información de los beneficios. La única dependencia

funcional de esta relación es (id empresa, anio) → importe), y esta relación se
halla en FNBC.
Un diseño alternativo es el empleo de varias relaciones, cada una de
las cuales almacena los beneficios de un año diferente. Supóngase que los
3 PROCESO GENERAL DEL DISEÑO DE BASES DE DATOS 11

años de interés son 2000, 2001 y 2002; se tendrán, entonces, las relaciones
de la forma bene f icios 2000, bene f icios 2001, bene f icios 2002, todos los cuales
se hallan en el esquema (id empresa, bene f icios). Aquı́, la única dependencia
funcional de cada relación será id empresa → bene f icios, por lo que estas
relaciones también se hallan en FNBC.
No obstante, este diseño alternativo es, claramente, una mala idea:
habrı́a que crear una relación nueva cada año, y también habrı́a que es-
cribir consultas nuevas cada año, para tener en cuenta cada nueva relación.
Las consultas también tendrı́an que ser más complicadas, ya que puede que
tengan que hacer referencia a muchas relaciones.
Otra manera más de representar los mismos datos es tener una sola
relación:

empresa anio(id empresa, bene f icios 2000, bene f icios 2001, bene f icios 2002)

En este caso, las únicas dependencias funcionales van de id empresa

hacia los demás atributos, y la relación vuelve a estar en FNBC. Este diseño
también es una mala idea, ya que tiene problemas parecidos al diseño
anterior, es decir, habrı́a que modificar el esquema de la relación y escribir
consultas nuevas cada año. Las consultas también serı́an más complicadas,
ya que puede que tengan que hacer referencia a muchos atributos.
Las representaciones como las de la compañı́a empresa anio, con una
columna para cada valor de un atributo, se denominan de tablas cruzadas;
se emplean ampliamente en las hojas de cálculo, en los informes y en las
herramientas de análisis de datos. Aunque estas representaciones resul-
tan útiles para mostrárselas a los usuarios, por las razones que acaban de
darse, no resultan deseables en el diseño de bases de datos. Se han prop-
uesto extensiones de SQL para convertir los datos desde una representación
relacional normal en una tabla cruzada, para poder mostrarlos.