La teoría de la normalización
va perdiendo peso con el paso de los años
como herramienta de diseño
de bases de datos relacionales en favor de
modelos de datos más ricos
en su representación, como pueda ser el
Entidad-Relación de Chen
que veremos en temas posteriores.
Aún así, los conceptos que
se van a desarrollar aquí son totalmente
válidos desde el punto de
vista de comprobar lo correcto que es un
esquema de base de datos
relacional, en el sentido de que no se
produzcan redundancias
innecesarias entre los datos a almacenar.
Por otra parte, ayudará a
la mejor comprensión del Modelo Relacional y,
en general, a justificar
la estructuración en tablas (relaciones en su
denominación formal)
interrelacionadas mediante claves ajenas de los
sistemas de información a
mecanizar mediante técnicas de bases de
datos.
88
V1. Introducción
Cuando trabajamos con una
base de datos relacional, los esquemas de las
distintas relaciones que
la constituyen nos indican que “cada dato tiene su
lugar”. Pero, ¿qué ocurre
si se modifican estas estructuras lógicas?. Muchas
veces es tan obvio que un
dato debe de almacenarse en una de las
relaciones y no en otra
que se nos escapa la respuesta a porqué es así.
La teoría
de la normalización es en esencia una expresión formal de
ideas
sencillas con una aplicación muy práctica en el área del diseño de
bases de datos, ya que
conducen a una correcta elección del esquema de
la base
de datos.
Ya que el diseño de la
base de datos es el diseño de los esquemas que la
componen, debemos recordar
que lo que nos interesa son las propiedades de
los datos que siempre se
cumplen y no las que se cumplen por casualidad en
un instante de tiempo. El
propósito del esquema es capturar aquellas
propiedades que siempre
son verdaderas, es decir nos vamos a ocupar de la
cabecera
o esquema de la relación independientemente del cuerpo o valores
variables con el tiempo.
El punto fundamental es
que algunas relaciones pueden presentar aspectos
indeseables y la teoría de
la normalización nos permite identificar esos casos
y nos muestra la forma de
convertir esas relaciones a una forma más
deseable. Para ello, la
teoría de la normalización tiene como fundamento
el
concepto de formas normales. Se dice que una relación
está en una
determinada
forma normal si satisface un cierto conjunto de
restricciones. Cuantas
más restricciones satisface “más deseable” es la
forma de la relación.
Las formas normales que se
han definido se muestran en el gráfico anterior
junto con el nombre de
quien (o quienes) las han definido. Como da idea la
ilustración, cada conjunto
de relaciones normalizadas en una determinada
forma, además de las suyas
propias, cumple con las restricciones impuestas
por la forma normal
anterior. En otras palabras, la quinta forma normal es más
restrictiva que la cuarta,
la cuarta que la de Boyce-Codd, y así
sucesivamente.
Se debe aclarar que
formalmente cuando se habla de relaciones
normalizadas
nos estamos refiriendo a relaciones que están en primera
forma
normal (1FN), es decir, los términos “normalizada” y “1FN” significan
exactamente lo mismo.
Además de ver la
definición de las distintas formas normales se introduce la
idea de un procedimiento
de normalización adicional, con el que una
Universo de las Relaciones (normalizadas y no normalizadas)
Relaciones 1FN (normalizadas) - Codd
Relaciones 2FN - Codd
Relaciones 3FN - Codd
Relaciones BCFN - Boyce y Codd
Relaciones 4FN - Fagin
Relaciones 5FN - Fagin
introducción
al diseño de BDR
89
relación en una cierta
forma normal, por ejemplo en 2FN, se puede convertir
en un conjunto de
relaciones en una forma más deseable, 3FN, y así
sucesivamente. Es decir,
este procedimiento es la reducción sucesiva de un
conjunto
dado de relaciones a una forma más deseable. Es
importante
destacar que este
procedimiento es reversible, siempre es posible tomar la
salida del procedimiento y
convertirla en la entrada, lo que significa que no se
pierde
información durante el proceso de normalización adicional.
Las tres formas normales
originales de Codd y la forma normal de
Boyce/Codd se asientan en
el concepto de dependencia funcional. Se dará
primero una definición
este concepto para poder definir posteriormente
cuando una relación está
en una cierta forma normal.
Ejemplo
propuesto
El ejemplo que se va a
seguir para aclarar todas las definiciones trata de
forma muy reducida de una
empresa que tiene una serie de empleados, de
los que se conoce su
N.I.F., su nombre, su dirección, un teléfono de contacto
y su año de nacimiento.
Esta empresa tiene una serie de proyectos
identificados unívocamente
por un código y de los que se conoce su nombre,
su presupuesto, su fecha
de inicio, su fecha de finalización, la ciudad donde
se desarrolla y el grado
de idoneidad del proyecto, éste tiene que ver con la
facilidad de
desplazamiento desde la ciudad donde se encuentra la sede de la
empresa hasta la ciudad
donde se desarrolla el proyecto y depende no sólo
de los kilómetros sino
también de los medios de comunicación que existan
entre ellos según un
estudio hecho por la propia empresa. A los empleados
los pueden destinar a
trabajar en distintos proyectos durante un período de
tiempo establecido
pudiendo ir alternando su trabajo en distintos proyectos.
Si realizamos el diseño
lógico partiendo del esquema conceptual adecuado, el
esquema de la base de
datos que obtendremos, prescindiendo de los
dominios asociados a los
atributos, es el que se muestra a continuación:
EMPLEADO (N.I.F., nombre,
dirección, fecha-nacimiento)
Clave primaria: N.I.F.
CIUDAD(ciudad, idóneo)
Clave primaria: ciudad
PROYECTO (código, nombre,
presupuesto, inicio, finalización, ciudad)
Clave primaria: código
Clave ajena: ciudad → CIUDAD
TRABAJAR (N.I.F., código,
desde, hasta)
Clave primaria: (N.I.F.,
código, desde)
Clave ajena: N.I.F. → EMPLEADO
Clave ajena: código → PROYECTO
Pero, ¿es completamente
correcta la forma en que pensamos almacenar la
información? Hay cosas que
tenemos muy claro que “están en su sitio”
porque parece “natural”.
Por ejemplo, parece lógico que si, además,
queremos almacenar el
teléfono personal de cada empleado, este dato debe
estar en la tabla EMPLEADO.
Supongamos que no, que el
teléfono del empleado lo incluimos en la tabla
TRABAJAR.
BD1 2006-2007
90
TRABAJAR (N.I.F., teléfono,
código, desde, hasta)
Clave primaria: (N.I.F.,
código, desde)
Clave ajena: N.I.F. → EMPLEADO
Clave ajena: código → PROYECTO
Una posible ocurrencia de
la tabla TRABAJAR sería:
N.I.F. TELÉFONO CÓDIGO
DESDE HASTA
22446688A 5632224 A111
10/10/92 20/12/92
22446688A 5632224 A112
09/01/93 12/03/93
22446688A 5632224 A112
20/03/93 14/03/93
22446688A 5632224 A116
15/08/93 24/11/93
11116666B 5211111 A112
09/01/93 20/05/93
11116666B 5211111 A114
07/07/93 27/10/93
Como vemos, el teléfono de
contacto de un empleando se va a repetir tantas
veces como proyectos esté
asignado. Esta redundancia puede provocar
información inconsistente
si no se manejan con cuidado las posibles
actualizaciones del
teléfono de contacto de un empleado.
Este problema surge porque
de todas las columnas de la tabla TRABAJAR el
teléfono de contacto de un
empleado lo podemos conocer sabiendo su N.I.F.
Sin embargo, la fecha en
la que comienza a trabajar en un proyecto no
depende sólo de su N.I.F.
sino que necesitamos conocer también el código
del proyecto al que nos
referimos.
En general, la redundancia
introducida por un mal diseño de las relaciones
provoca lo que se conoce
como anomalías de actualización, es decir,
problemas con las tres
operaciones básicas: inserción, borrado y
modificación.
INSERCIÓN
Para almacenar el teléfono
de un empleado debemos asignarlo,
obligatoriamente a un
proyecto (recordemos que la clave primaria incluye el
código del empleado).
N.I.F. TELÉFONO CÓDIGO
DESDE HASTA
22446688A 965632224 A111
10/10/92 20/12/92
22446688A 965632224 A112
09/01/93 12/03/93
22446688A 965632224 A112
20/03/93 14/03/93
22446688A 965632224 A116
15/08/93 24/11/93
11116666B 965211111 A112
09/01/93 20/05/93
11116666B 965211111 A114
07/07/93 27/10/93
21555777C
965227820 ? ? ?
Además, puede que, para un
mismo empleado, tengamos varios teléfonos
distintos, cuando debería
ser único para cada uno.
N.I.F. TELÉFONO CÓDIGO DESDE
HASTA
22446688A 965632224 A111
10/10/92 20/12/92
22446688A 965632224 A112
09/01/93 12/03/93
22446688A 965632224 A112
20/03/93 14/03/93
22446688A 965632224 A116
15/08/93 24/11/93
11116666B 965211111 A112
09/01/93 20/05/93
11116666B 965211111 A114
07/07/93 27/10/93
11116666B 965212222 A111
10/10/92 20/12/92
introducción
al diseño de BDR
91
BORRADO
Podría eliminarse
información innecesariamente.
Si un empleado trabajaba
en un único proyecto y esa relación ha terminado,
lo lógico es eliminar la
tupla que representa la relación entre ambos. Sin
embargo, entre la
información a borrar de la base de datos está el teléfono del
empleado, dato éste que
perderíamos innecesariamente.
N.I.F. TELÉFONO CÓDIGO
DESDE HASTA
22446688A 965632224 A111
10/10/92 20/12/92
22446688A 965632224 A112
09/01/93 12/03/93
22446688A 965632224 A112
20/03/93 14/03/93
22446688A 965632224 A116
15/08/93 24/11/93
11116666B 965211111 A112
09/01/93 20/05/93
MODIFICACIÓN
Proceso costoso
computacionalmente y posibilidad de introducir
inconsistencias en la base
de datos.
La redundancia de
información que presenta la relación TRABAJAR, hace
que si un empleado cambia
de teléfono tengamos que modificar este dato en
todas las tuplas de ese
empleado.
Todo esto no ocurriría si
el teléfono hubiera sido definido como un atributo
más de la relación
EMPLEADO en vez de en TRABAJAR.
Por tanto, parece que no
es adecuado mantener toda la información en la
misma tabla. Los problemas
surgen porque ciertos atributos no dependen
directa o completamente de
las claves candidatas.
La normalización es un
proceso por el cual se modifica la estructura de la
base de datos buscando la
eliminación de la redundancia innecesaria, a
obtener un conjunto de
tablas con una estructura más deseable.
Vamos a definir lo que se
entiende por “dependencia”.23
V2. dependencia funcional
Dada una relación R, el
atributo Y de R depende
funcionalmente del
atributo X de R -en símbolos, R.X → R.Y y
se lee “ R.X
determina funcionalmente a R.Y”- si y sólo si,
23 En
realidad, todo son consideraciones de diseño de una base de datos, más o menos
cercanas
a la realidad pero,
finalmente, decisiones del diseñador. Éste busca el conjunto de relaciones
entre los datos más
apropiado para el uso final de esa base de datos. Sin ser habitual, por
características propias y
excepcionales del sistema de información a representar, podría llegar a
decidirse que el teléfono
es único para cada dirección.
BD1 2006-2007
92
como mucho, un solo
valor Y en R está asociado a cada valor X
en R (en cualquier
momento dado). Los atributos X e Y pueden
ser compuestos.
Por ejemplo en la relación
EMPLEADO, los atributos nombre, dirección,
teléfono de contacto y
fecha de nacimiento dependen funcionalmente del
atributo N.I.F., porque
dado un valor específico de N.I.F., existe sólo un valor
correspondiente de nombre,
dirección, teléfono y fecha de nacimiento. En
símbolos:
EMPLEADO.NIF → EMPLEADO.NOMBRE
EMPLEADO.NIF → EMPLEADO.DIRECCIÓN
EMPLEADO.NIF → EMPLEADO.TELÉFONO
EMPLEADO.NIF → EMPLEADO.FECHA
o, de forma más concisa:
EMPLEADO.NIF → EMPLEADO.(NOMBRE, DIRECCION,
TELEFONO, FECHA)
Sin embargo, dada una
dirección no ocurre que sólo haya un empleado con
esa dirección, puede que
más de un empleado viva en la misma casa24.
EMPLEADO.DIRECCION → EMPLEADO.NIF
Por decirlo de otra forma:
Dada una relación R, el
atributo Y depende funcionalmente
del atributo X de R, si y sólo si,
siempre que dos tuplas de R
concuerden en su
valor de X, deben por fuerza concordar en su
valor de Y.
De forma gráfica, las
dependencias funcionales se representan como arcos
dirigidos cuyo inicio es
el atributo (o atributos) del que depende el atributo al
que apunta. Así, y como ya
se ha dicho antes de NIF dependen
funcionalmente tanto
NOMBRE, DIRECCIÓN, TELÉFONO, como FECHA,
como se observa en el
siguiente diagrama de dependencias funcionales:
Nótese que todas estas
dependencias funcionales están dentro del esquema
de base de datos que
estamos manejando como ejemplo, aún cuando los
atributos se encuentren
repartidos entre varias tablas relacionadas con las
24 Nuevamente
hay que tener en cuenta que las dependencias funcionales las decide el
diseñador
de la base de datos: en el
sistema de información que estamos manejando no existen
restricciones del tipo
“sólo hay un empleado, como mucho, por cada dirección”, o similares. Pero
en otro sistema de
información sí podría ser necesario representar estas restricciones.
NOMBRE
DIRECCIÓN
TELÉFONO
FECHA
DESDE
HASTA
PRESUPUESTO
INICIO
NOMBRE
CIUDAD
IDÓNEO
NIF CÓDIGO FIN
introducción
al diseño de BDR
93
correspondientes claves
ajenas. Más adelante, con las formas normales, se
justificará porqué es este
el esquema y no otro.
DEPENDENCIA
FUNCIONAL COMPLETA
Se dice que el
atributo Y de la relación R es por completo dependiente
funcionalmente
del atributo X de la relación R si depende funcionalmente
de X y no depende
funcionalmente de ningún subconjunto propio de X.
En el siguiente diagrama,
C depende de forma completa de A, pero no de (A,
B). D sí depende de forma
completa de (A,B).
DEPENDENCIA
FUNCIONAL TRANSITIVA
Sean X, Y, y Z atributos
de la relación R. Si Z depende funcionalmente de Y, e
Y depende funcionalmente
de X, se dice que el atributo Z depende
funcionalmente
del atributo X de forma transitiva.
Aunque no se represente,
existe otro arco entre A y C puesto que esa es,
precisamente, la propiedad
de transitividad. En ocasiones aparecerá
explícitamente como en el
siguiente, pero ambos diagramas son
absolutamente
equivalentes:
V3. formas normales
Las que vamos a
desarrollar aquí son las primeras formas normales que
definió Codd.
Posteriormente se vio que eran insuficientes para tratar algunos
casos especiales,
básicamente aquellos que manejaban varias claves
candidatas. De hecho las
definiciones que se dan a continuación hablan de
Clave Primaria y no de
Clave Candidata.
Por otra parte, para la
mayoría de las relaciones que se describen en una
base de datos, suele ser
suficiente normalizar hasta tercera forma normal
(3FN) para conseguir un
diseño correcto de la BD.
A
B
C
D
A B C
A B C
BD1 2006-2007
94
V3.1. primera forma normal
Nosotros partimos de la
idea de que por la estructura de las tablas cada tupla
únicamente admite un valor
para cada uno de los atributos. Esto es lo que se
expresa en la definición
de primera forma normal.
Una relación está en
primera forma normal (1FN) si y sólo si
todos los dominios
simples subyacentes contienen sólo valores
atómicos.
V3.2. segunda forma normal
Una relación está en
segunda forma normal (2FN) si y sólo si
está en 1FN y todos
los atributos no clave dependen por
completo de cualquier
clave candidata.25
Este diagrama representa
una relación con la siguiente definición:
R(A, B, C, D, E, F) CP(A,
B)
La elección de la clave
primaria es evidente: el único conjunto de atributos del
que dependen funcionalmente
todos los demás es (A, B). Si hubiéramos
elegido (A) sólo podríamos
“llegar” a E y a F, con (B) a ninguno, y (A, B, C),
por ejemplo, no puede ser
clave candidata porque (A, B) ya lo es.
En el diagrama de
dependencias funcionales anterior podemos observar
como los atributos C y D
dependen funcionalmente de forma completa de la
clave primaria (A, B).
Pero E y F sólo dependen de A, por lo que decimos que
esta relación no se
encuentra en 2FN.
El proceso para pasar de
una relación en una determinada forma normal a un
conjunto de relaciones en
una forma normal más deseable, procedimiento de
normalización, tiene
como operador de descomposición la proyección (el
de recomposición es la concatenación
natural).
El primer paso del
procedimiento de normalización es transformar una
relación que sólo está en
1FN a varias en 2FN (algunas estarán además en
tercera o más). Esto hace
que tengamos que sacar proyecciones para
eliminar las dependencias
funcionales no completas de la clave primaria (si
una relación está en 1FN
pero no está en 2FN su clave primaria es
compuesta).
Dada una relación R en
1FN:
R (A, B,
C, D, E, F)
Clave primaria: (A, B)
25 Al hablar
de atributos no clave o no primos de una relación se hace referencia a
los que no
pertenecen a ninguna de las
claves candidatas de la relación.
C
E
D
F
B
A R
introducción
al diseño de BDR
95
Ya hemos comentado que son
E y F los atributos que no dependen
funcionalmente de forma
completa de la clave primaria (A, B); se recomienda
sustituir R por sus dos
proyecciones R1 y R2.
R1 (A, E,
F)
Clave primaria: A
R2 (A, B,
C, D)
Clave primaria: (A, B)
Clave ajena: A → R1
Ambas relaciones, R1 y R2
parten de una misma relación original: R. Es
evidente que si, antes,
toda la información estaba asociada por pertenecer a
una única relación, al
efectuar la proyección de atributos, las relaciones
resultantes han de
relacionarse por alguna clave ajena.
V3.3. tercera forma normal
Una relación está en
tercera forma normal (3FN) si y sólo si
está en 2FN y todos
los atributos no clave dependen de manera
no transitiva de
cualquier clave candidata.
Hablamos de dependencia
transitiva cuando ocurre:
A → B, B → C y, por
tanto, A → C
Siguiendo con el proceso
de normalización veamos cuales son los pasos a
seguir para descomponer
una relación R que sólo está en 2FN en otras
relaciones más deseables
en 3FN. Las proyecciones irán encaminadas a
eliminar las dependencias
transitivas.
R (A, B,
C)
Clave primaria: A
En realidad, la DF que
provoca las anomalías en las actualizaciónes es R.B →
R.C.
Se recomienda sustituir R
por sus dos proyecciones R1 y R2:
R1 (B, C)
Clave primaria: B
R2 (A, B)
Clave primaria: A
Clave ajena: B → R1
Estas dos relaciones se
encuentran en 3FN.
C
A B
R
BD1 2006-2007
96
V3.4. Un ejemplo
Volvamos al diagrama de
dependencias funcionales de empleados y
proyectos.
En primer lugar debemos
definir la primera relación:
R(NIF, nombreE,
dirección, fecha-nacimiento, código, nombreP,
presupuesto, inicio,
finalización, ciudad, idóneo, desde, hasta)26
CP: (código, NIF, desde)
Todas las DF de NIF y
todas las de CÓDIGO son DF no completas, lo que
provoca la definición de
dos nuevas tablas, ya que R no está en 2FN:
R(NIF, código, desde,
hasta)
CP: (código, NIF, desde)
CAj: (código) → PROYECTO
CAj: (NIF) → EMPLEADO
EMPLEADO (NIF, nombre,
dirección, fecha-nacimiento)
CP: (NIF)
PROYECTO (código, nombre,
presupuesto, inicio, finalización, ciudad,
idóneo)
CP: (código)
La relación R (que podemos
renombrar como TRABAJAR) está en 2FN y 3FN
puesto que la única DF que
contiene es (código, NIF, desde) → hasta.
No obstante, hay que
comprobar las dos nuevas tablas. EMPLEADO tiene,
también, una única
dependencia funcional: NIF→ (nombre, dirección, fechanacimiento),
por lo tanto está en 3FN,
pero PROYECTO tiene:
26 Tenemos
dos atributos llamados “nombre” por lo que, en esta primera relación, los vamos
a
diferenciar como “nombreE”
y “nombreP”.
NOMBRE
DIRECCIÓN
TELÉFONO
FECHA
DESDE
HASTA
PRESUPUESTO
INICIO
NOMBRE
CIUDAD
IDÓNEO
NIF CÓDIGO FIN
introducción
al diseño de BDR
97
Código → (nombre,
presupuesto, inicio, finalización, ciudad, idóneo)
Ciudad → idóneo
PROYECTO no está en 3FN y
debemos proyectar una nueva tabla:
CIUDAD(ciudad, idóneo)
CP: (ciudad)
PROYECTO (código, nombre,
presupuesto, inicio, finalización, ciudad)
CP: (código)
CAj: (ciudad) → CIUDAD
Ahora ya está el esquema
completo:
EMPLEADO (NIF, nombre,
dirección, fecha-nacimiento)
CP: (NIF)
CIUDAD(ciudad, idóneo)
CP: (ciudad)
PROYECTO (código, nombre,
presupuesto, inicio, finalización, ciudad)
CP: (código)
CAj: (ciudad) → CIUDAD
TRABAJAR(NIF, código,
desde, hasta)
CP: (código, NIF, desde)
CAj: (código) → PROYECTO
CAj: (NIF) → EMPLEADO
V4. forma normal de boyce-codd
Esta forma normal se
definió para resolver las anomalías de actualización
provocadas por un caso muy
específico, que se da cuando:
• La relación tiene varias
claves candidatas
• Las claves candidatas
están solapadas en algún subconjunto de
atributos de las dos.
Si cualquiera de estas dos
condiciones no se cumpliese, normalizar hasta
3FN sería suficiente.
Una relación está en
forma normal de Boyce-Codd (FNBC) si y
sólo si todo
determinante es una clave candidata.
Definimos determinante
como un conjunto de atributos del que depende
funcionalmente por
completo algún otro atributo.
Supongamos la siguiente
relación y sus atributos, sus claves candidatas y las
dependencias funcionales
observadas:
C
A B
R
BD1 2006-2007
98
Los determinantes en esta
relación son (A) y (B,C) puesto que de todos ellos
depende funcionalmente de
forma completa un conjunto de atributos.
Las claves candidatas son
(A,B) y (B,C) ya que de estos conjuntos de
atributos depende el
resto.
Por eso, R no está en
FNBC. Para normalizar y conseguir que todo
determinante sea clave
candidata debemos proyectar (A) → (C), la
dependencia que provoca
que la relación no esté en FNBC, a otra relación,
quedando entonces:
R1 (A, B)
Clave primaria: (A, B)
Clave ajena: (A) → R2
R2 (A, C)
Clave primaria: (A)
No hay comentarios:
Publicar un comentario