El documento describe las formas normales, que son propiedades que deben cumplir las tablas de un esquema relacional para evitar redundancias y contradicciones. Explica las primeras tres formas normales (1NF, 2NF y 3NF), la forma normal de clave elemental, y la forma normal de Boyce-Codd, la cual es más estricta. También proporciona ejemplos para ilustrar cómo aplicar las formas normales al diseñar tablas relacionales.
en este ensayo se da una breve explicacion de la dependencia funcional y las formas de normalizacion utilizadas como bases al momento de realizar el diseño de un modelo relacional a partir de un modelo entidad- relación
en este ensayo se da una breve explicacion de la dependencia funcional y las formas de normalizacion utilizadas como bases al momento de realizar el diseño de un modelo relacional a partir de un modelo entidad- relación
Diseño de base de datos relacional, dando a conocer las características y propiedades con las que debe contar el diseño relacional para lograr una personificación apropiada con la realidad además de cuáles son los inconvenientes que se pueden presentar al realizar un mal diseño
1. Universidad de Cantabria Bases de Datos
Formas Normales
Para construir un sistema de información que responda a un problema real concreto, lo primero que
hay que hacer es decidir cuál es el esquema relacional más adecuado. Encontrar la mejor manera de
agrupar los datos en forma de tablas y de relacionar éstas entre sí, es la esencia del diseño de bases de
datos relacionales. Por ello, muchos autores se han dedicado a delimitar los problemas que se pueden
presentar por una composición inadecuada de las tablas y a especificar las condiciones que éstas
deben cumplir para evitarlos. Estas propiedades exigibles a cada tabla se conocen con el nombre de
Formas Normales.
A partir de ellas, para decidir la composición de las tablas de una base de datos, hay dos formas de
proceder:
• Síntesis: partir de los atributos simples desagregados e ir agrupándolos progresivamente.
• Descomposición: suponer que todos los atributos están agrupados formando una sola
tabla, que se va dividiendo paulatinamente.
En cada etapa debe verificarse el cumplimiento de las Formas Normales y un diseño no podrá
considerarse correcto hasta comprobar que todas las tablas responden a ellas.
En el pasado reciente, la mayor parte de los diseñadores de bases de datos se han auxiliado de estas
técnicas. Pero, por la dificultad práctica de ir comprobando la verificación de las Formas Normales,
en la actualidad, ya son muchos los que realizan un primer diseño conceptual, apoyándose en
metodologías como NIAM, ORM, ER o UML, que conduzca al diseño de la base de datos,
asegurando el cumplimiento de las formas normales sin necesidad de un análisis expreso. Algunos
aún utilizan la normalización, aunque sólo para refinar el esquema relacional obtenido a partir del
esquema conceptual.
Las técnicas de diseño de bases de datos relacionales basadas en estos métodos implican el proceso
de conversión de un esquema conceptual, expresado en términos propios de cada metodología, en un
esquema relacional cuya presentación se basa en tablas. La ventaja de esta forma de proceder radica
en trabajar con unidades simples, lo que facilita su correcta elección y que las restricciones son
fáciles de expresar y comprobar; además, el mismo esquema conceptual puede ser convertido en
diferentes modelos de datos, dependiendo del gestor de bases de datos que se vaya a utilizar.
En lo que sigue, se presentan las definiciones y conceptos necesarios para comprender las
propiedades exigibles a las tablas de un esquema relacional para que éste no pueda dar lugar a
redundancias y contradicciones en sus datos.
Eduardo Mora y Marta Zorrilla Pág. -1-
2. Universidad de Cantabria Bases de Datos
Esquema de relación (o esquema de tabla):
Es una lista ordenada de nombres de atributos.
Relación (o tabla):
Es una determinación de un esquema de relación mediante valores concretos de los atributos,
es decir, una tabla de valores.
Notación utilizada:
1.- Las letras mayúsculas del comienzo del alfabeto representan atributos simples.
2.- Las letras mayúsculas del final del alfabeto representan conjuntos de atributos (atributos
compuestos), siendo posibles conjuntos simples.
3.- La letra R se usa para denotar un esquema de relación.
4.- Se utiliza r para indicar una relación, es decir, el contenido de una tabla.
5.- La concatenación significa unión, es decir: A1A2...An es el conjunto{A1, A2, ..., An}, XY es
lo mismo que X ∪ Y y también XA es igual que X ∪ {A}.
Primera forma normal (1NF):
Un esquema de relación, R, está en 1NF si y sólo si tiene un número de atributos fijo y éstos
toman valores no compuestos.
Muchas veces, la definición de lo que es un valor no compuesto no es clara, y puede depender
del uso que se vaya a hacer de los valores del atributo. Por ejemplo, cuando se trata de procesar datos
de personas puede tener sentido utilizar un atributo “Nombre” para almacenar el nombre propio y los
apellidos, si siempre se va a abordar de forma conjunta. En cambio, si se desea acceder por el nombre
propio y/o por los apellidos separadamente, para que el esquema de relación esté en primera forma
normal, debería tener atributos diferenciados para ellos, “Nombre_propio”, “Apellido_1” y
“Apellido_2”, por ejemplo.
Clave:
Es todo atributo, simple o compuesto, que toma valores únicos (no repetidos). Esto equivale a
decir que, para un esquema de relación, R, K ⊆ R es una clave si, para cualquier contenido, r(R), de
la relación, para todas las parejas t1 y t2 de tuplas de r(R), tales que t1 ≠ t2 entonces t1[K] ≠ t2[K].
Clave principal:
Es la clave que se utiliza para identificar cada tupla de una relación.
Atributo de clave (Key atribute):
Es un atributo que pertenece a una clave.
Atributo no de clave (Non key attribute):
Es un atributo que ni es una clave ni forma parte de una clave.
Eduardo Mora y Marta Zorrilla Pág. -2-
3. Universidad de Cantabria Bases de Datos
Dependencia funcional:
Sean V ⊆ R y W ⊆ R, se dice que W depende funcionalmente de V en R, V →W, si en
cualquier relación r(R), para todas las parejas t1 y t2 de tuplas de r(R) tales que t1[V] = t2[V] entonces
t1[W] = t2[W]. También suele decirse que V determina funcionalmente a W.
Del planteamiento directo de cada problema concreto puede observarse un cierto conjunto de
dependencias funcionales entre atributos. Generalmente, hay otras dependencias que pueden
deducirse a partir de las primeras.
Dado un conjunto, F, de dependencias funcionales. El conjunto cerrado de dependencias
funcionales de F, F+, es aquel que contiene todas las dependencias funcionales que F implica
lógicamente. El conjunto cerrado de dependencias funcionales contiene todas las que el problema
implica.
Tres son las reglas que, dado un conjunto de dependencias funcionales, permiten encontrar su
conjunto cerrado y se conocen bajo el nombre de axiomas de Armstrong. Éstos son
1.- Regla de la reflexividad: Si Y ⊆ X ⇒ X →Y
2.- Regla de la amplificación: Si X →Y ⇒ WX →WY
3.- Regla de la transitividad: Si X →Y e Y →Z ⇒ X →Z
Se dice que estas reglas son válidas porque no generan dependencias funcionales incorrectas
y son completas porque, dado un conjunto de dependencias funcionales, F, permiten encontrar su
conjunto cerrado, F+.
Su utilización práctica suele resultar incomoda, por lo que frecuentemente, junto a ellas, se
utilizan otras reglas deducidas como:
Regla de la unión: Si X →Y y X →Z ⇒ X →YZ
Regla de la descomposición: Si X →YZ ⇒ X →Y y X →Z
Regla de la seudotransitividad: Si X →Y y WY →Z ⇒ XW →Z
Descomposición sin pérdida de dependencias
Sea R un esquema de relación y F un conjunto de dependencias funcionales de R. Se
demuestra que R1 ⊂ R y R2 ⊂ R, tales que R1∪R2 = R, constituyen una descomposición sin pérdida
de R si, en F+, está al menos una de las dependencias funcionales siguientes:
R1 ∩ R2 →R1
R1 ∩ R2 →R2
A cada esquema de relación Ri ⊂ R se le denomina proyección de R.
Con relación al concepto de dependencia funcional, para lo que sigue, conviene tener en cuenta
algunas definiciones como las siguientes:
Eduardo Mora y Marta Zorrilla Pág. -3-
4. Universidad de Cantabria Bases de Datos
• X →Y es una dependencia funcional trivial si y sólo si Y ⊆ X.
• X →Y es una dependencia funcional completa si y sólo si Y no depende funcionalmente de
ningún subconjunto de X.
• Una dependencia funcional completa y no trivial se dice que es una dependencia funcional
elemental.
• Una clave es una clave elemental si algún atributo en la tabla depende funcionalmente de ella
mediante una dependencia funcional elemental.
• Un atributo es un atributo de clave elemental si pertenece a alguna clave elemental.
Segunda forma normal (2NF):
Un esquema de relación, R, está en 2NF si y sólo si está en 1NF y todo atributo no de clave,
V ⊆ R, depende funcionalmente de la clave (o claves) y no de ningún subconjunto propio de ella (o
ellas).
Ejemplo:
En el caso de que se desee pedir más de un artículo en un mismo pedido, si la tabla, PEDIDO,
de que se dispone es la de la figura, el esquema de relación NO está en 2FN.
En efecto, se observa que Cod_prov (código del proveedor) depende funcionalmente de
Num_ped (número de pedido), que es un subconjunto de la clave (Num_ped, Cod_artic). Esto hace
que haya que repetir el Cod_prov cuando se quiera pedir un segundo artículo en el mismo pedido.
PEDIDO
Cod_prov Num_ped Cod_artic Unidades_ped
Num_ped Cod_prov
A20 729 2745 110
A20 729 3752 240
B09 730 3752 250
Num_ped Cod_artic Unidades_ped
... ... ... ...
Solución adecuada en este caso conduce a la siguiente descomposición:
Eduardo Mora y Marta Zorrilla Pág. -4-
5. Universidad de Cantabria Bases de Datos
PEDIDO
Cod_prov Num_ped
A20 729
B09 730
... ... LINEA_DE_PEDIDO
Num_ped Cod_artic Unidades_ped
729 2745 110
729 3752 240
730 3752 250
... ... ...
Tercera forma normal (3NF):
Un esquema de relación, R, está en 3NF si está en 2NF y todo atributo no de clave no
depende funcionalmente de ningún atributo no de clave.
La tabla de la siguiente figura está en 2NF, pues todo atributo no de clave depende
funcionalmente de la clave y no de ningún subconjunto propio de ella, pero no está en 3NF pues
Edificio depende funcionalmente de Departamento, que no es parte de la clave (Nombre_empleado),
ya que, en este ejemplo, se supone que todo departamento está en un único edificio.
La tabla requiere que se repita el dato del Edificio cuando se trate del mismo Departamento, lo
que puede dar lugar a inconsistencias, por errores en la entrada de datos.
EMPLEADOS
Nombre_empleado
Nombre_empleado Departamento Edificio
López, Juan PER 32
Cruz, Pedro DIR 10
Mas, Luis PER 32
Departamento Edificio ... ... ...
El modo de corregir esta deficiencia consiste en efectuar la siguiente descomposición:
Eduardo Mora y Marta Zorrilla Pág. -5-
6. Universidad de Cantabria Bases de Datos
DEPARTAMENTOS
Departamento Edificio
PER 32
DIR 10
EMPLEADOS ... ...
Nombre_empleado Departamento
López, Juan PER
Cruz, Pedro DIR
Mas, Luis PER
... ...
Forma normal de Clave Elemental (EKNF):
Un esquema de relación R está en EKNF si, para todas sus dependencias funcionales
elementales de la forma X →Y, X es una clave de R o Y es un atributo de clave elemental.
En el ejemplo de la figura, como la tabla no tiene atributos que no formen parte de una clave,
automáticamente está en 3FN. Sin embargo, tiene deficiencias claras (la alumna de número de
expediente 32678, llamada “Laso, Ana”, está duplicada). Una forma de descubrir el mal diseño es
observar que la tabla no está en EKFN.
En efecto, sólo hay dos dependencias funcionales elementales, una de Num_exp respecto a
Nombre_al y otra de Nombre_al respecto a Num_exp. Pero ni Num_exp ni Nombre_al son claves ni
atributos de clave elemental, pues no hay ninguna clave elemental ya que ningún atributo en la tabla
depende funcionalmente de una clave mediante una dependencia funcional elemental, pues todos los
atributos son atributos de clave.
Obsérvese que las dos claves de la tabla son (Nombre_al , Cod_asig) y ( Num_exp,
Cod_asig).
MATRICULA
Nombre_al Num_exp Cod_asig
Nombre_al Num_exp
Laso, Ana 32678 2745
Laso, Ana 32678 3752
Mas, Luis 25663 3752
... ... ...
La solución al problema consiste en realizar la siguiente descomposición:
Eduardo Mora y Marta Zorrilla Pág. -6-
7. Universidad de Cantabria Bases de Datos
ALUMNOS
Nombre_al Num_exp
Laso, Ana 32678
Mas, Luis 25663 MATRICULA
... ...
Num_exp Cod_asig
32678 2745
32678 3752
25663 3752
... ...
Forma normal de Boyce-Codd (BCNF):
Un esquema de relación, R, está en BCNF si y sólo si para todas sus dependencias
funcionales elementales de la forma X →Y se verifica que X es una clave de R.
En la figura se representa una tabla y todas sus dependencias funcionales elementales. En las
dependencias entre Num_exp y Nombre_al, ambos atributos son de clave elemental (pues forman
parte de alguna clave elemental) y, en las otras dos dependencias funcionales, los atributos de la
izquierda son claves, por lo que la tabla está en EKNF.
MATRICULA
Nombre_al Num_exp
Nombre_al Num_exp Cod_asig Calificacion
Laso, Ana 32678 2745 APROBADO
Num_exp Cod_asig Calificacion 32678 3752
Laso, Ana
Mas, Luis 25663 3752 NOTABLE
Nombre_al Cod_asig Calificacion ... ... ... ...
No obstante, la tabla presenta la misma redundancia que la tabla anterior. Una forma de
localizar este problema consiste en observar que la tabla no está en BCNF, lo que resulta sencillo al
observar que ni Num_exp ni Nombre_al son claves.
El problema de la redundancia puede evitarse dividiendo la tabla en las dos que se
representan en la figura, las cuales verifican la BCNF.
Eduardo Mora y Marta Zorrilla Pág. -7-
8. Universidad de Cantabria Bases de Datos
ALUMNOS
Nombre_al Num_exp
Laso, Ana 32678
Mas, Luis 25663 NOTAS
... ...
Num_exp Cod_asig Calificacion
32678 2745 APROBADO
32678 3752
25663 3752 NOTABLE
... ... ...
Para que un esquema de relación esté en 3NF o en EKNF pero no en BCNF es preciso que existan
dos claves que se solapen.
Se demuestra que si una tabla está en BCNF también está en EKNF y que, si está en EKNF también
está en 3NF.
* En la definición original de Codd de 2NF y 3NF aparece el termino “clave” en el sentido de “clave
principal” y “candidata a clave” en el de “clave”. En la actualidad, un atributo se considera “atributo
de clave” si pertenece a una clave (clave principal) o a una candidata a clave (clave).
Dependencia de valores múltiples:
Las dependencias de valores múltiples o multivaluadas, V → →W, se definen sobre una
relación y son una generalización de las dependencias funcionales. En ellas, para cada valor de V
existen un conjunto de valores de W con independencia del resto de atributos de la relación.
En el ejemplo que se propone en la figura, PROFESOR e IDIOMA, son atributos con múltiples
valores para un mismo valor del DEPORTE, independientes entre sí. Se ha supuesto que en la realidad
(ver esquema de datos) existe una regla que obliga a que todos los profesores de un deporte han de
utilizar todos los idiomas correspondientes a él.
DEPORTE PROFESOR IDIOMA
TENIS PEDRO ESPAÑOL
LUIS INGLES
GOLF LUIS FRANCES
CARLOS
Esquema de datos.
Por lo que, al normalizar hasta BCNF, la relación que recoja estos datos debe responder al
esquema de la siguiente figura. Así, deben aparecer todas las posibles combinaciones entre los
valores de los atributos PROFESOR e IDIOMA, correspondientes a cada valor de DEPORTE .
Eduardo Mora y Marta Zorrilla Pág. -8-
9. Universidad de Cantabria Bases de Datos
V W R-V-W
Deporte Profesor Idioma
Tenis Pedro Español t4
Tenis Pedro Inglés t1
Tenis Luis Inglés t3
Tenis Luis Español t2
Golf Luis Francés
Golf Carlos Francés
Relación con dependencias de valores múltiples
La tabla obtenida presenta redundancias, lo que puede acarrear errores de actualización. Todo
ello, a pesar de que el esquema está en BCNF, ya que no existen en ella dependencias funcionales
elementales puesto que su clave está formada por el conjunto de los tres atributos.
Se recuerda que las dependencias de valores múltiples dependen del contexto. Éstas fueron
introducidas, independientemente, por Zanolo (1976), Fagin (1977) y Delobel (1978).
De acuerdo a la definición de Fagin, la dependencia de valores múltiples se define del
siguiente modo:
Sea R un esquema de relación y sea V ⊆ R y W ⊆ R. La dependencia de valores múltiples,
V → →W, se cumple en R si en cualquier relación r(R), para todas las parejas t1 y t2 de tuplas tales
que:
a) t1[V]=t2[V]
b) t1[W]≠t2[W]
c) t1[R-V-W]≠t2[R-V-W]
existen las tuplas t3 y t4 en r(R), tales que:
i) t1[V]=t2[V]=t3[V]=t4[V]
ii) t3[W]=t2[W] y t3[R-V-W]=t1[R-V-W]
iii) t4[W]=t1[W] y t4[R-V-W]=t2[R-V-W]
Ullman y Delobel no incluyen expresamente las condiciones b y c, aunque puedan
presuponerlo. En el ejemplo propuesto son necesarias porque para el caso de las dos últimas tuplas
no se requiere que existan las tuplas complementarias.
Reglas de inferencia:
Eduardo Mora y Marta Zorrilla Pág. -9-
10. Universidad de Cantabria Bases de Datos
Reglas que, dado un conjunto, D, de dependencias funcionales y de valores múltiples,
permiten encontrar el conjunto, D+, de todas las dependencias funcionales y de valores múltiples que
D implica lógicamente.
1.- Regla de la reflexividad (“reflexivity”): Si Y ⊆ X ⇒ X →Y
2.- Regla de la amplificación (“augmentation”): Si X →Y ⇒ WX →WY
3.- Regla de la transitividad (“transitivity”): Si X →Y e Y →Z ⇒ X →Z
4.- Regla de la complementación (“complementation”): Si X → →Y ⇒ X → →R-Y-Z
5.- Regla de amplificación de valores múltiples (“augmentation for multivalued dependencies”):
Si X → →Y y V ⊆ R y W ⊆ R ⇒ WX → →WY
6.- Regla de transitividad de valores múltiples (“transitivity for multivalued dependencies”):
Si X → →Y e Y → →Z ⇒ X → →Z-Y
7.- Regla de repetición: Si X →Y ⇒ X → →Y
8.- Regla de condensación (“coalescence”):
Si X → →Y y Z ⊆ Y y ∃ W / W ⊆ R, W ∩ Y= ∅ y W →Z ⇒ X →Z
Estas reglas son válidas y completas.
Los tres primeros axiomas son los de Armstrong para dependencias funcionales, los tres
siguientes son propios de las dependencias de valores múltiples y los dos últimos relacionan
dependencias de valores múltiples y funcionales.
Cuarta forma normal (4NF):
Un esquema de relación está en 4NF si y sólo si está en BCNF y todas sus dependencias no
triviales son dependencias funcionales (de valores simples). Esto equivale a decir que una relación en
4NF no puede tener ninguna dependencia de valores múltiples no trivial. Básicamente, para evitar
errores en los datos, por causa de su redundacia, cada dependencia de valores múltiples no funcional
requiere una tabla separada.
La tabla anterior está en BCNF pero no en 4NF y la solución para evitar los inconvenientes
mencionados consiste en descomponer la relación anterior en las dos siguientes:
Deporte Profesor Deporte Idioma
Tenis Pedro Tenis Español
Tenis Luis Tenis Inglés
Golf Luis Golf Francés
Golf Carlos
Dependencia de combinación:
Eduardo Mora y Marta Zorrilla Pág. - 10 -
11. Universidad de Cantabria Bases de Datos
Una relación tiene una dependencia de combinación si puede ser reconstruida sin pérdida de
información a partir una combinación de algunas de sus proyecciones. Si una de esas proyecciones es
la propia tabla, entonces se trata de una dependencia de combinación trivial.
En la figura se presenta una tabla de vendedores-aparatos-marcas. En el segundo nivel se
presentan sus proyecciones binarias y, a continuación, su combinación, realizada en dos fases. Como
el resultado vuelve a ser la tabla de partida, la relación presenta una dependencia de combinación y,
como ninguna de las proyecciones es la propia tabla, ésta es no trivial.
No obstante, pese a estar en 4NF, en la tabla se observan redundancias que hacen pensar que
su composición no es la adecuada. Este tipo de dificultad puede ser detectado analizando el
cumplimiento de la quinta forma normal, que se define a continuación.
Vendedor Aparato Marca
Luis TV Sony
Luis PC Sony
Luis TV Loewe
Pedro TV Sony
Vendedor Aparato Vendedor Marca Aparato Marca
Luis TV Luis Sony TV Sony
Luis PC Luis Loewe PC Sony
Pedro TV Pedro Sony TV Loewe
Vendedor Aparato Marca
1ª - 1ª Luis TV Sony
1ª - 2ª Luis TV Loewe
2ª - 1ª Luis PC Sony
2ª - 1ª Luis PC Loewe FALSA
3ª - 3ª Pedro TV Sony
Vendedor Aparato Marca
1ª - 1ª Luis TV Sony
3ª - 2ª Luis PC Sony
2ª - 3ª Luis TV Loewe
5ª - 2ª Pedro TV Sony
Eduardo Mora y Marta Zorrilla Pág. - 11 -
12. Universidad de Cantabria Bases de Datos
Quinta forma normal (5NF):
Un esquema de relación, R, está en 5NF si y sólo si, para cada dependencia de combinación
no trivial, cada proyección incluye una clave de la tabla original.
Como las proyecciones de la figura anterior no contienen la clave de la tabla de partida, ésta no está
en 5NF. Para solucionar este inconveniente, la tabla dada debe descomponerse en las tres tablas que
constituyen las proyecciones de la misma figura.
Consideraciones finales
La idea central en el diseño de bases de datos relacionales radica en el concepto de
dependencias entre los datos. Las dependencias son propiedades inherentes al significado de los
datos, forman parte del problema de información a tratar y se han de cumplir para cualquier
ampliación de un esquema de relación.
Existen distintos tipos de dependencias, en este texto se han comentado las dependencias
funcionales, de valores múltiples y de combinación. Cada tipo de dependencia se caracteriza por ser
un modo de asociación entre los datos. Además, cada uno de los tipos de dependencia mencionados
constituye un caso particular del tipo que le sigue, según el orden en el que se han enumerado.
Las dependencias funcionales son las más numerosas, con diferencia, y, además, las más
restrictivas.
Las siete Formas Normales analizadas también están estrictamente ordenadas, es decir, el
cumplimiento de una forma normal implica el de las anteriores.
La principal dificultad para llegar hasta la 5FN no se halla en el proceso propio de
normalización, sino en la detección de todas las dependencias implicadas. Es recomendable
normalizar hasta 5FN aunque, en el estado actual de la técnica y ante la eficiencia que se exige a las
aplicaciones, las base de datos en uso pueden no cumplir todos los requisitos en la práctica. Hay que
evaluar el porcentaje de actualizaciones frente a consultas para decidir hasta qué Forma Normal es
adecuado llegar (al menos hasta la 3NF).
Hay muchos autores que han tratado el diseño de algorítmico de esquemas relacionales, como
Ullman, Ceri, Milton, Mannila. Los dos últimos proponen nuevos métodos y algoritmos más rápidos
para la normalización de bases de datos.
Referencias
CERI (1983). Methodology and Tools for Data Base Design. Amsterdam, North-Holland.
HALPIN, T. (2001). Information modelling and relational databases: from conceptual
analysis to logical design. Academic Press.
MANNILA, H. y RAIHA, K.J. (1986). Inclusion Dependencies in Database Design. Proc. Of
the 2nd Conference on Data Engineering, pp. 713-718.
MIGUEL, A., PIATTINI, M. y MARCOS, E. (1999). Diseño de Bases de Datos Relacionales.
Ra-ma.
ULLMAN, J.D. (1990). Principles of Database and Knowledge Base Systems. EE.UU.
Computer Science Press.
Eduardo Mora y Marta Zorrilla Pág. - 12 -