Tema 05 - Normalizacion y Algebra Relacional - P3.1

Tema 5: Normalización y álgebra
relacional
Esta obra está bajo una licencia de Reconocimiento-

NoComercial-CompartirIgual de CreativeCommons.
Para ver una copia de esta licencia visite:

http://creativecommons.org/licenses/
Documento original
Jorge Sánchez Asenjo (2009)
Ampliación y Modificación
Joaquín Álvarez García (2011)
Pilar García López (2012 y ss.)
Tema 5: Normalización y álgebra relacional
Cuando se diseña un determinado software o una aplicación informática, al principio no

es más que una lista de requisitos que el cliente plantea al analista. Tras el
correspondiente análisis, la mayoría de proyectos desembocan en la necesaria
utilización de bases de datos y eso implica un diseño detallado de los datos a utilizar,
definidos en términos específicos sin ambigüedad y mediante un completo diccionario
de datos (información que recoge la estructura de la base de datos).
Los modelos de datos son el instrumento principal para obtener estos, y son utilizados
para la representación y el tratamiento de los problemas. En las unidades anteriores
hemos visto cómo debe ser llevado a cabo el diseño conceptual, obteniendo el
diagrama E/R para transformarlo después en un modelo relacional en el que están
definidas cada una de las tablas con sus columnas correspondientes, y la clave principal
que garantiza la unicidad de las filas.
Esas tablas obtenidas en el modelo relacional, pueden presentar ciertas anomalías,

como la existencia de redundancia, incoherencia y problemas para mantener la
integridad de los datos, por ello las tablas resultantes del esquema relacional deben
seguir determinadas normas que eviten esas anomalías y garanticen un resultado
adecuado a las necesidades planteadas inicialmente por el cliente. Para conseguir esto
se aplica la Normalización de las tablas de las Bases de Datos.
La normalización es una técnica de diseño de bases de datos relacionales a partir de los

datos de un sistema de información. Fue iniciada por Codd en 1972 y continuada por
otros autores entre los que destacan Boyce y Fagin.
La normalización busca agrupar los atributos en relaciones de modo que se minimice la

redundancia de los datos. Si se consigue, se obtienen las siguientes ventajas:
Las actualizaciones de los datos almacenados en la BD pueden llevarse a cabo con un

número mínimo de operaciones, reduciendo la incoherencia en los datos.
Reduce el espacio de almacenamiento de archivos requerido por las relaciones base.
Minimiza costos
En el proceso de normalización se debe ir comprobando que

cada relación (tabla) cumple una serie de reglas que se basan
en la clave primaria y las dependencias funcionales. Cada
regla que se cumple aumenta el grado de normalización. Si
una regla no se cumple, la tabla se debe descomponer en
varias tablas que sí la cumplan.
Es una estrategia de diseño de abajo hacia arriba: se parte de los atributos y estos se
van agrupando en relaciones (tablas) según su afinidad.
Joaquín Alvarez García y Pilar García López Página 2

La normalización se lleva a cabo en una serie de pasos. Cada paso corresponde a una
Forma Normal (FN) que tiene unas propiedades.
• Inicialmente Codd propuso las primeras formas normales (1FN, 2FN y 3FN)
basadas en las dependencias funcionales.
• Después, en 1974, se definió la forma normal de Boyce–Codd (FNBC), también
basada en dependencias funcionales.
• Posteriormente, en 1977 y 1979, Fagin propuso la 4ª y la 5ª Formas Normales
(4FN y 5FN), basadas en otros tipos de dependencias.
• En los últimos años se habla de otras formas normales más.
Vamos a ver las fases de la normalización una base de datos

desde la 1FN, aunque habitualmente no se utilizará la
normalización como una técnica de diseño de bases de datos,
sino como una etapa posterior a la correspondencia entre el
esquema conceptual (Entidad/Relación) y el esquema lógico
(esquema relacional). Si el esquema E/R es correcto y su
transformación al esquema relacional también, se asegura
que la base de datos resultante estará en Tercera Forma
Normal.
La Teoría de Normalización se basa en el concepto de dependencias funcionales entre

los datos. Se centra en el estudio de las dependencias que presenta cada atributo de
una relación con respecto al resto de atributos de la misma.
Las dependencias funcionales son de primordial importancia a la hora de encontrar y

eliminar la redundancia de los datos almacenados en las tablas de una base de datos
relacional.
De forma genérica podemos decir que una tabla o relación (R) se compone de un
conjunto de atributos (A) y sus dependencias (DF):
R (A, DF).
Tanto las relaciones (R) como los atributos (A) podemos identificarlos de las
especificaciones del cliente, pero para las dependencias (DF), tendremos que ahondar
en el valor semántico de esos atributos y no pueden obtenerse de manera automática en
una tabla determinada.
La dependencia funcional es una noción semántica. Si hay 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.

Las dependencias funcionales reflejan enlaces semánticos permanentes entre los datos
que podemos concretar en:
Restricciones de integridad establecidas por el usuario que permiten conocer las

relaciones que existen entre los atributos del problema planteado.
Propiedades inherentes a la semántica del problema.
Restricciones que deben cumplir todas las filas de una relación.
Supongamos el siguiente ejemplo:
Tenemos un tabla (o relación) EMPLEADO cuyos atributos son DNI, NOMBRE,

DIRECCION, TELEFONO, DEPARTAMENTO.
Si cada persona tiene un único DNI y si además suponemos que cada persona tiene
un único teléfono y una única dirección, y que además trabaja en un único
departamento de la empresa, podemos decir que NOMBRE, DIRECCION,
TELEFONO, DEPARTAMENTO depende funcionalmente del DNI y lo
representaremos de la forma siguiente:
DNI NOMBRE, DIRECCION, TELEFONO, DEPARTAMENTO.
Hemos de tener en cuenta que una dependencia funcional puede cumplirse en un

sentido pero no necesariamente en el otro, por ejemplo, es evidente que el
nombre de una persona depende funcionalmente del DNI, es decir, para un DNI
determinado existe sólo un nombre que le corresponda. Sin embargo, si
consideramos el ejemplo al revés, DNI no depende funcionalmente de NOMBRE,
ya que para un mismo nombre puede haber muchos DNI diferentes.
Ahora bien, si en nuestro problema necesitáramos almacenar (o quisiéramos

permitir que se almacenara) más de una dirección para una misma persona, o más
de un teléfono, o que trabajara en más de un departamento, esos tres atributos
no dependerían funcionalmente de DNI y esta información nos la da la semántica
del problema, por ello se dice que “las dependencias funcionales vienen
definidas por la semántica del problema”.
Consideramos un esquema de relación general R(A), con A el conjunto de sus atributos,

y consideramos X, Y, y Z subconjuntos de A llamados descriptores.
Se dice que un conjunto de atributos (Y) depende funcionalmente de otro conjunto de

atributos (X), si en todo momento cada valor de X tiene asociado un único valor de Y.
Se representa por X Y.

Y depende funcionalmente de X.
También se dice que X determina a Y o que X implica a Y.
X se conoce como determinante o implicante e Y como implicado.
En una dependencia funcional X Y, cuando X es un conjunto de atributos,

decimos que la dependencia funcional es completa, si sólo depende de X, y no de ningún
subconjunto de X.
Por ejemplo, si el descriptor X es compuesto, X(X1, X2), se dice que Y tiene

dependencia funcional completa o plena de X, si la eliminación de cualquier atributo de
X hace que la dependencia deje de existir.
Y depende funcionalmente de manera completa de X,

si Y depende funcionalmente de X
pero no de ningún subconjunto propio de X
Una dependencia funcional completa se representa como:
Si la dependencia funcional no fuese completa se diría parcial.
Una dependencia funcional X → Y es una dependencia parcial si existe algún atributo

que puede eliminarse de X y la dependencia continua verificándose.
Veamos un ejemplo.
Supongamos la relación PEDIDOS (Cod_Cliente, Cod_Producto, Cantidad), el conjunto de

atributos formado por el código del cliente y el código del producto producen una
dependencia funcional completa sobre la cantidad del pedido.
Cod_Cliente + Cod_Producto Cantidad

Veamos ahora otro ejemplo:
NOTAS (codEstudiante, nombre, mediaExamenes, asignatura, nota)
codEstudiante nombre mediaExamenes asignatura nota

101 Luis 3.75 501 4
101 Luis 4,75 502 5
101 Luis 6.75 503 7
102 Juan 6,40 501 6
102 Juan 5,40 503 5
103 Marta 8,09 501 8
……
La clave primaria de la tabla viene determinada por codEstudiante + asignatura.
El nombre del estudiante viene determinado por la clave primaria, pero si eliminásemos
el atributo asignatura, el nombre del estudiante sigue estando determinado por el
CodEstudiante. En este caso existe una dependencia funcional parcial del nombre con
respecto a codEstudiante + asignatura.
Además, codEstudiante + asignatura mediaExamenes
y codEstudiante + asignatura nota
Consideramos la relación R(X, Y, Z) con las siguientes dependencias funcionales:
X Y (Y depende funcionalmente de X)
Y Z (Z depende funcionalmente de Y)
En estas condiciones se dice que Z tiene una dependencia funcional transitiva respecto a
X, a través de Y. Es decir, un descriptor Z es transitivamente dependiente de otro X si se
puede conocer por diferentes vías, una directamente y otra a partir de otro descriptor
intermedio Y.
X Y Z
NOMBRE_ALUMNO DIRECCION POBLACION
NOMBRE_ALUMNO determina su DIRECCION y su DIRECCION determina la POBLACION en

la que vive; por transitividad NOMBRE_ALUMNO determina la POBLACION.
NOMBRE_ALUMNO POBLACION

Sean X e Y dos descriptores, se dice X multidetermina a Y (X Y) si para cada

valor de X existe un conjunto bien definido de valores posibles de Y, con independencia
del resto de atributos de la relación.
Por ejemplo, supongamos una tabla como la siguiente:
CODIGO_CLIENTE CUENTA_CORRIENTE
1234 2056-3202-2000335588
1234 1023-2202-4500235677
3452 2786-6782-9265623434
5231 8563-5522-3499324233
Podemos apreciar como para el CODIGO_CLIENTE 1234, tenemos dos filas diferentes. Se
dice que CODIGO_CLIENTE multidetermina a CUENTA_CORRIENTE.
CODIGO_CLIENTE CUENTA_CORRIENTE
La teoría de la normalización ayuda a los diseñadores a prevenir problemas de

redundancia y consiste en ir descomponiendo las relaciones en otras, con menos
atributos, con el fin de satisfacer alguna Forma Normal basadas en los conceptos de
dependencias funcionales.
Esta teoría se basa en la aplicación de las Formas Normales, que son un conjunto de
restricciones sobre las tablas que permiten evitar los problemas de redundancia y
anomalías en la actualización, inserción y borrado de datos. De esta manera
transformamos, si es necesario, las tablas obtenidas directamente del modelo
Entidad/Relación, en un conjunto de tablas más simples y fáciles de mantener.
Codd definió en 1970 la primera forma normal, desde ese momento aparecieron la
segunda, tercera, la Boyce-Codd, la cuarta y la quinta forma normal e incluso algunos
libros hablan de más formas normales, sin embargo se considera que con llegar a la
forma normal de Boyce-Codd es suficiente, más cuando no existe consenso de la
operatividad del resto de las formas normales
Una tabla puede encontrarse en primera forma normal (1FN) y no en segunda forma
normal (2FN), pero no al contrario. Es decir, cada forma normal incluye a las anteriores.

La primera forma normal es inherente al modelo relacional y dice: “Una relación está en
Primera Forma Normal (1FN) si y sólo si todos sus atributos son atómicos”.
La tabla siguiente no se encuentra en la Primera Forma Normal pues tiene tuplas con
más de un valor en los atributos ASIGNATURA y NOTA.
DNI NOMBRE ASIGNATURA NOTA

11444523R Ana Redes 5
45325612W Vanesa Operativos 7
Redes 3
34589233Y Juan Operativos 5
Como el modelo relacional no admite esta posibilidad, tendremos que eliminar los
grupos repetitivos. Hay dos técnicas para eliminar grupos repetitivos:
Caso A.- Si sabemos el máximo de asignaturas por alumno podemos crear tantas
columnas como asignaturas y en consecuencia tantas columnas como notas.
DNI NOMBRE ASIGNATURA1 ASIGNATURA2 NOTA1 NOTA2

45325612W Vanesa Operativos Redes 7 3
Caso B.- Creamos una tupla para cada asignatura del alumno/a.
DNI NOMBRE ASIGNATURA NOTA

45325612W Vanesa Operativos 7
45325612W Vanesa Redes 3

En ambos casos la tabla ya estaría en la Primera Forma Normal, aunque podemos

observar que tenemos duplicados de datos que ya se eliminarán en las fases siguientes.
La Segunda Forma Normal dice: “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 la clave
primaria”.
Supongamos la relación siguiente:
ALUMNADO (DNI, COD_ASIG, NOMBRE, APELLIDOS, NOTA, CURSO, AULA)
DNI COD_ASIG NOMBRE APELLIDOS NOTA CURSO AULA

11444523R 0129 Ana Gómez 5 ASIR 102
45325612W 0456 Vanesa Blanco 7 ASIR 101
45325612W 0487 Vanesa Blanco 5 ASIR 101
34589233Y 1342 Juan López 5 ASIR 109
Si analizamos las dependencias funcionales tendremos:
DNI NOMBRE, APELLIDOS

DNI, COD_ASIGNATURA NOTA
COD_ASIGNATURA CURSO, AULA
La clave de la relación es DNI+COD_ASIG. Como no todos los atributos que no forman

parte de la clave, dependen completamente de ella, la relación no cumple la segunda
forma normal.
¿Qué problemas conlleva que no esté en la Segunda Forma Normal?
Redundancia de datos: Con cada alumno de una misma asignatura repetimos toda
la información acerca del CURSO Y AULA.
Anomalías en la inserción de tuplas: Tenemos anomalías de inserción ya que no se

pueden insertar las asignaturas que se imparten en un curso hasta que no
insertamos algún alumno matriculado en esas asignaturas. En caso contrario,
estaríamos violando la regla de integridad de la clave al existir valores nulos en
dicha clave.
Anomalías en el borrado de tuplas: Igualmente aparecen anomalías en el borrado

de tuplas, ya que al eliminar todos los alumnos de una determinada asignatura
quedan eliminados de manera automática datos de la asignatura.
Anomalías en la actualización de tuplas: Si se hace un cambio de aula para una

asignatura, es necesario modificar todas las tuplas de todos los alumnos
matriculados en esa asignatura.
Posible inconsistencia de datos en las actualizaciones: No es más que una

consecuencia de las anomalías en la actualización de tuplas, por ejemplo al

modificar el AULA de una ASIGNATURA podríamos cometer errores y tener
Alumnos que tienen datos distintos para una misma asignatura. Sería una
inconsistencia.
Imposibilidad de almacenar ciertos datos. No es más que una consecuencia de las

anomalías en la inserción. No nos resultaría posible representar datos sobre
asignaturas en las que no haya matriculado ningún alumno, o sobre aulas en las
que no se imparte ninguna asignatura, cuando es perfectamente posible que
queramos almacenar esa información.
Para conseguir que la tabla pase a cumplir la Segunda Forma Normal hay que eliminar
las dependencias parciales de la clave primaria, descomponiendo la relación dada en
otras relaciones que sí estén en 2FN. Para ello, se separan los atributos que son
funcionalmente dependientes, y se ponen en una nueva tabla junto con sus
determinantes (los atributos de la clave primaria de los que dependen).
Dependencias:
DNI NOMBRE, APELLIDOS
DNI, COD_ASIGNATURA NOTA
COD_ASIGNATURA CURSO, AULA
La relación anterior se descompone en las siguientes relaciones que sí cumplen la 2FN:

ALUMNADO (DNI, NOMBRE, APELLIDOS)
CALIFICACIONES (DNI, COD_ASIGNATURA, NOTA)
ASIGNATURAS (COD_ASIGNATURA, CURSO, AULA)
Nota.- Si una tabla está en 1FN y su clave primaria es simple (tiene un solo atributo),
entonces también está en 2FN.
La Tercera Forma Normal dice: “Una relación está en tercera forma normal (3NF) si y
sólo si está en 2NF y todos los atributos no claves dependen de manera no transitiva
de la clave primaria”
Es decir, una relación está en ·FN si sus atributos no clave son mutuamente
independientes (no existe ningún atributo no clave que dependa funcionalmente de
alguna combinación del resto de atributos no clave) y además sean por completo
dependientes funcionalmente de la clave primaria.
Consideramos la relación ASIGNATURA del ejemplo anterior:
ASIGNATURAS (COD_ASIGNATURA, CURSO, AULA)
En la que existen las siguientes dependencias funcionales:

COD_ASIGNATURA CURSO
CURSO AULA
Existe una dependencia transitiva COD_ASIGNATURA CURSO AULA, por lo

tanto la relación no cumple la tercera forma normal.
Con estas dependencias surgen una serie de inconvenientes en la relación:
Anomalías en la inserción de tuplas: no se puede insertar un curso si no se indica

al menos una de las asignaturas de dicho curso. Estaríamos violando la regla de
integridad de la clave al insertar una tupla con valores nulos en la clave primaria.
Anomalías en el borrado de tuplas: si se borran las tuplas de todas las asignaturas

de un curso concreto, se borra de manera automática dicho curso de la Base de
Datos.
Anomalías en la actualización de tuplas: si se realiza un cambio de aula para un

curso determinado, tenemos que cambiar todas las tuplas de las asignaturas de
dicho curso, lo que indica que existe una gran redundancia de información en la
Base de Datos.
La solución pasa por una descomposición de la relación dada en otras relaciones que sí
estén en 3FN. Realizamos una descomposición de la relación dada en otras de tal
manera que desaparezca dicha dependencia, es decir, separando el atributo (o
atributos) que producen la dependencia funcional transitiva en una nueva.
Teníamos: ASIGNATURAS (COD_ASIGNATURA, CURSO, AULA)
Con las siguientes dependencias funcionales:
COD_ASIGNATURA CURSO
CURSO AULA
Procedemos tal y como hemos dicho obteniendo dos relaciones:
ASIGNATURAS (COD_ASIGNATURA, CURSO)

CURSOS (CURSO, AULA)
Se define determinante en una relación (tabla) a un atributo del cual depende de forma
funcional y completa cualquier otro atributo de la relación.
La Forma Normal de Boyce-Codd dice: “Una relación está en Forma Normal Boyce-Codd
(BCNF) si y solo si está en 3FN y cada dependencia funcional no trivial tiene una clave
candidata como determinante”.
En términos menos formales, una relación se encuentra en FNBC si y solo si todo

determinante es clave candidata.
Una tabla puede incumplir la Forma Normal de Boyce-Codd cuando:

• tenga dos o más claves candidatas compuestas
• las claves candidatas se solapen, es decir, tengan al menos un atributo en común.
Si consideramos la siguiente relación:
CALLEJERO (CALLE, CIUDAD, COD_POSTAL)
con las siguientes dependencias funcionales:
CALLE, CIUDAD COD_POSTAL

COD_POSTAL CIUDAD
COD_POSTAL es un determinante que no es clave candidata, por lo que la relación

no está en FNBC.
En esta ocasión vuelven a aparecer anomalías de inserción, actualización y borrado en la

Base de Datos, y dichas anomalías desaparecen realizando una descomposición adecuada
de la relación. En ocasiones esta descomposición puede dar lugar a una pérdida de
dependencias funcionales, motivo por el que algunos autores no aconsejan pasar a la
FNBC y quedarse en la 3FN. Otros sin embargo, prefieren continuar el proceso de
normalización hasta sus formas más avanzadas.
Para descomponer la relación procedemos de la siguiente manera:
1. Dejamos en la relación la parte de la clave que es independiente y todos los

atributos no primarios.
2. Se crea una nueva tabla con la parte de la clave restante y el atributo secundario
del que depende, siendo éste último la clave de la nueva tabla.
Teníamos: CALLEJEROS (CALLE, CIUDAD, COD_POSTAL)
Con las siguientes dependencias funcionales:
CALLE, CIUDAD COD_POSTAL

COD_POSTAL CIUDAD
Procedemos tal y como hemos dicho obteniendo dos relaciones:
CALLEJEROS (CALLE, COD_POSTAL)

CODIGOS_POSTALES(COD_POSTAL, CIUDAD,)
Ahora CALLEJEROS Y CODIGOS_POSTALES están en FNBC.

La Cuarta Forma Normal, enunciada por Fagin, dice que una relación (R) está en Cuarta
Forma Normal (4NF) si y sólo si, las únicas dependencias multivaluadas no triviales son
aquellas en las que una clave multidetermina un atributo.
Supongamos el ejemplo siguiente:
TABLA CURSOS
CURSO PROFESOR MATERIAL
17 Eva 1
17 Eva 2
17 Julia 1
17 Julia 2
25 Eva 1
25 Eva 2
25 Eva 3
En este ejemplo se está considerando que los profesores van a utilizar todos los
materiales de cada curso que impartan (el curso 17 tiene 2 materiales y el curso 25
tiene 3). Por lo tanto, en la relación CURSOS hay redundancia de datos.
Esta tabla está en FNBC, sin embargo, tiene redundancia.
Para el par CURSO y PROFESOR podemos saber los materiales que se van a utilizar por el
curso que imparte y no por el profesor. Por este motivo, los materiales dependen de
forma multivaluada del curso, pero no del profesor.
CURSO MATERIAL
Como la clave no multidetermina el material, esta tabla no está en 4FN.
Para transformar la tabla a la 4FN la dividiremos en dos tablas:
TABLA CURSOS-PROFESOR TABLA CURSOS-MATERIAL

CURSO PROFESOR CURSO MATERIAL
17 Eva 17 1
17 Julia 17 2
25 Eva 25 1
25 2
25 3

La Quinta Forma Normal, enunciada por Fagin y también conocida como Forma Normal
de Proyección-Unión, dice: “Una relación (R) se encuentra en Quinta Forma Normal si, y
sólo si, está en 4FN y toda dependencia de reunión en la relación es consecuencia de las
claves candidatas”.
Esta Quinta Forma Normal, se ha diseñado para reducir redundancia en las bases de
datos relacionales que guardan hechos multi-valores aislando semánticamente
relaciones múltiples.
La mayoría de los expertos coinciden en que las tablas que están en la 4FN se
encuentran también en 5FN a excepción de restricciones semánticas muy especiales.
Lo que nos está diciendo es que una relación sólo está en Quinta Forma Normal si lo
está en cuarta y no puede tener una descomposición sin pérdidas en cualquier
número de tablas más pequeñas.
Mientras que las anteriores formas normales se basan en el concepto de dependencia

funcional, la 5FN se basa en el concepto de dependencia reunión.
El concepto de dependencia de reunión (JOIN) significa que una tabla, después de que
se ha descompuesto en varias tablas más pequeñas, debe poderse reunirlas de nuevo
para formar la tabla original.
Supongamos el ejemplo siguiente:
Tenemos una tabla de empleados que trabajan en proyectos realizando unas tareas
concretas.
EMPLEADO PROYECTO TAREA

1 1 Diseño
1 2 Programación
2 1 Programación
Subdividiendo la tabla en dos tablas, como hubiéramos hecho con la Cuarta Forma
Normal tendríamos:
EMPLEADO PROYECTO PROYECTO TAREA

1 1 1 Diseño
1 2 2 Programación
2 1 1 Programación
Pero cuando se necesite reconstruir la tabla original a partir de las tablas anteriores,
vemos que no se obtiene la misma información de la tabla original.
EMPLEADO PROYECTO TAREA

1 1 Diseño
1 1 Programación <- Dato Falso

1 2 Programación
2 1 Diseño <- Dato Falso
2 1 Programación
Para evitar el problema anterior se aplica la 5FN, que añade una tabla más para
completar la información de la tabla original, quedando de la siguiente manera:
EMPLEADO PROYECTO EMPLEADO TAREA PROYECTO TAREA

1 1 1 Diseño 1 Diseño
1 2 1 Programación 2 Programación
2 1 2 Programación 1 Programación
Resumiendo, una tabla está en Quinta Forma Normal si hay una descomposición de
esa tabla que muestre la misma información que la original.
En 1981, Fagin describió un enfoque diferente para las tablas normalizadas cuando
propuso la Forma Normal Dominio-Clave (FNDC), la cual describe la meta final al diseñar
una base de datos.
Si una tabla está en la DKNF, también debe estar en todas las demás formas normales.
La dificultad es que no hay un método definido para hacer que una tabla esté en la
DKNF. De hecho, es posible que algunas tablas nunca puedan convertirse a la DKNF.
La meta de la DKNF es hacer que cada tabla represente un tema y que todas las
restricciones se expresen en términos de restricciones de dominios y de claves. Es
decir, todas las restricciones se describen de manera explícita por medio de las reglas
de las tablas.
Una restricción del dominio especifica los valores permitidos para un atributo dado,
mientras que una restricción de clave especifica los atributos que identifican
únicamente una fila en una tabla dada.
La siguiente tabla no cumple la FNDC:
PERSONAS_RICAS
DNI Persona rica Tipo de persona rica Valor neto en euros
123 Millonario excéntrico 124,543,621
456 Multimillonario malvado 6,553,228,893
789 Multimillonario excéntrico 8,829,462,998
012 Millonario malvado 495,565,211
Asumiendo que el dominio para la 'DNI Persona rica consiste en los DNI's de toda la gente
rica en una muestra predefinida de gente rica; el dominio para el Tipo de persona rica

consiste de los valores 'Millonario excéntrico', 'Multimillonario excéntrico', 'Millonario

malvado', y 'Multimillonario malvado'; y el dominio para el Valor neto en dólares consiste
de todos los números enteros mayor que o igual a 1.000.000.
Hay una restricción que liga el Tipo de persona rica al Valor neto en dólares, incluso
aunque no podamos deducir uno del otro. La restricción dicta que un Millonario
excéntrico o Millonario malvado tendrá un valor neto de 1.000.000 a 999.999.999
inclusive, mientras que un Multimillonario excéntrico o un Multimillonario malvado
tendrá un valor neto de 1.000.000.000 o más. Esta restricción no es ni una restricción de
dominio ni una restricción de clave; por lo tanto no podemos confiar en las restricciones
de dominio y las de clave para garantizar que una combinación errónea de Tipo de
persona rica / Valor neto en euros no tenga cabida en la base de datos.
La violación de la DKNF podría ser eliminada alterando dominio Tipo de persona rica
para hacer que sea consistente con solo dos valores, 'Malvado' y 'Excéntrico' (el
estatus de persona rica como un millonario o un multimillonario viene implícito por
su Valor neto en dólares, así no se pierde ninguna información útil).
DKNF es frecuentemente difícil de alcanzar en la práctica.
Para definir un grupo de tablas en la DKNF, primero hay que trabajar en las reglas de las
formas normales. Después, confirmar que se tiene una lista completa de las
restricciones. A continuación, asegurarnos que las restricciones están expresadas en
términos de restricciones de dominios y de claves. Revisar las claves primarias para
confirmar que sean únicas; y que se han capturado todas las relaciones muchos a
muchos. Comprobar que no haya reglas ocultas ni dependencias. Establecer relaciones
con claves foráneas para imponer las reglas de existencia y para hacer coincidir los
datos en las otras tablas.
La denormalización es el proceso de procurar optimizar el desempeño de una base de

datos por medio de agregar datos redundantes. A veces es necesaria porque los
actuales Sistemas Gestores de Bases de Datos (SGBD) implementan el modelo relacional
pobremente. Un verdadero SGBD relacional debe permitir una base de datos
completamente normalizada a nivel lógico, mientras proporciona el almacenamiento
físico de los datos afinado para alto rendimiento.
Un diseño normalizado almacenará información en tablas lógicas separadas. Si estas

relaciones están almacenadas físicamente como archivos de disco separados, puede ser
lento realizar una consulta de la base de datos que obtenga información de varias
relaciones. Por otro lado, si muchas relaciones se unen en una tabla, se pueden producir
redundancias y anomalías.
Hay dos estrategias para tratar esto:
Mantener normalizado el diseño lógico, pero permitir al Gestor de Base de Datos

almacenar en el disco información redundante adicional para optimizar la
respuesta a la consulta. En este caso, es responsabilidad del software del SGBD
asegurarse de que cualquier copia redundante se mantenga consistente. Este
método es a menudo implementado en SQL como vistas indexadas (MS-SQL) o

vistas materializadas (Oracle).
Una segunda opción es denormalizar el diseño de datos lógico, pero en este caso
le trasladamos al programador la responsabilidad de que la base de datos de no
llegue a ser inconsistente. Esto se hace creando reglas en la base de datos
llamadas restricciones, que especifican cómo las copias redundantes de
información se deben mantener sincronizadas. En este caso, el rendimiento en las
consultas es bueno, pero peor que la versión normalizada en las actualizaciones
debido a la evaluación de restricciones.
Es importante recalcar que un modelo de datos denormalizado no es lo mismo que

un modelo de datos que no ha sido normalizado, y que la denomarlización debe
realizarse después de que hayamos normalizado (hasta un nivel aceptable) y de que
hayan sido definidas las restricciones y/o reglas requeridas para ocuparse de las
anomalías inherentes en el diseño.
El álgebra relacional fue introducida por E.F. Codd como un conjunto de operaciones
que actúan sobre las tablas produciendo como resultado otras tablas. Este conjunto
de operaciones permite actuar sobre una base de datos para pasar de un estado inicial a
un estado final. El álgebra relacional constituye la parte dinámica del modelo relacional.
En este apartado, se muestran diferentes tipos de operaciones de consulta que se

pueden realizar con las tablas. Estas operaciones están basadas en el álgebra relacional.
Los operandos de cada operación los constituyen una o varias tablas y el resultado es
otra tabla. Esta tabla resultante puede ser, a su vez, operando en otra peración.
El álgebra relacional presentado por Codd contenía ocho operadores, aunque el paso
del tiempo ha introducido numerosos cambios, proponiéndose nuevos operadores y
cambios en los primitivos.
Las operaciones presentadas por Codd son:
Selección
Operaciones Unarias
Proyección
Operaciones Básicas Unión
Operaciones Binarias Diferencia
Producto cartesiano
Intersección
Operaciones Derivadas División o Cociente
Reunión, Combinación o Join
En las operaciones unarias se utiliza una tabla de entrada para obtener el resultado. En
las binarias se emplean dos tablas.
Las operaciones derivadas son binarias que necesitan de las operaciones básicas.

Selección.- Esta operación permite obtener otra tabla formada por un subconjunto de
filas de una tabla inicial, manteniendo todas sus columnas. Las filas resultantes son las
que cumplen una condición dada. En ella se pueden utilizar los operadores booleanos
AND (Y), OR (O) y NOT (NO). Se representa por σcondición(tabla)
Ejemplo: Supongamos la siguiente tabla de ALUMNADO.
NUMERO_MATR APELLIDO1 APELLIDO2 NOMBRE CURSO

221 Álvarez González Jairo 501
222 González Palacio Marcos 502
223 Martínez Gómez Carlos 501
224 Cienfuegos García María 501
225 Herrero Llaneza Elena 503
226 Blanco Matos Rosa 503
Si ejecutamos σcurso=503(ALUMNOS) obtendremos la tabla siguiente:

Proyección.- Esta operación permite obtener una nueva tabla a partir de otra con el
subconjunto de columnas que se indiquen. Las filas duplicadas, si las hubiese sólo
aparecerán una vez. Se representa por πcolumna1, columna2, … (tabla)
Ejemplo: Supongamos la siguiente tabla de ALUMNOS.

Si ejecutamos πNUMERO_MATR, CURSO (ALUMNOS) obtendremos la tabla siguiente:
NUMERO_MATR CURSO
221 501
222 502
223 501
224 501
225 503
226 503
Podemos anidar los operadores: πNUMERO_MATR, CURSO (σcurso=503(ALUMNOS))

NUMERO_MATR CURSO
225 503
226 503
Unión.- Permite la unión de dos tablas. Dos tablas se pueden unir si tienen el mismo
número de columnas y dominios compatibles (pueden tener el mismo o distinto
nombre). El resultado de una unión es una nueva tabla con las filas de ambas tablas. Las
filas repetidas aparecen sola vez. Se representa por el símbolo U.
Tabla: GrupoASR1
Tabla: GrupoASR2
Tabla GrupoASR1 U ASR2

Diferencia.- La diferencia de dos tablas sólo es posible si tienen el mismo número de

columnas y dominios compatibles. El resultado es una nueva tabla que contiene las
tuplas que están en la primera tabla pero no están en la segunda.
Se representa por el símbolo −. Obsérvese que no da el mismo resultado Tabla1-Tabla2

que Tabla2-Tabla1.
Tabla: Alumnos

Tabla: AlumnosSuspensos
Tabla: Alumnos - AlumnosSuspensos

Producto cartesiano.- Dadas dos tablas, el producto cartesiano es una nueva tabla que
contiene las columnas de ambas tablas y como filas tiene todas las posibles
combinaciones de cada fila de la tabla 1ª con cada fila de la tabla 2ª. Se representa por
el símbolo X.
Tabla EMPLEADOS Tabla PROYECTOS

Nombre Departamento Proyecto Responsable Importe
Juan 1 A01 Antón 6000
Luis 2 A02 María 9000
Fernando 3
Tabla EMPLEADOS X PROYECTOS

Nombre Departamento Proyecto Responsable Importe
Juan 1 A01 Antón 6000
Juan 1 A02 María 9000
Luis 2 A01 Antón 6000
Luis 2 A02 María 9000
Fernando 3 A01 Antón 6000
Fernando 3 A02 María 9000
En el ejemplo anterior, la tabla primera tiene 3 filas y la segunda 2, por tanto la tabla
resultante del producto cartesiano tendrá 3 x 2 = 6 filas.
Intersección.- La intersección de dos tablas sólo es posible si tienen el mismo número

de columnas y dominios compatibles. El resultado es una nueva tabla que contiene el
conjunto de todas las tuplas que están en ambas tablas. Se representa por el símbolo .
Tabla: Tabla1

Tabla: Tabla2
Tabla: Tabla 1 Tabla2

División o Cociente.- La división se debe realizar sobre dos tablas que cumplen las
siguientes condiciones:
a) La tabla que actúa de dividendo debe tener columnas que se encuentran en la

tabla que actúa de divisor y el número de columnas de la tabla dividendo debe
ser mayor que el de la tabla divisora.
b) La tabla que actúa como divisora debe tener, al menos, una fila (tupla).
c) Los atributos coincidentes están definidos en el mismo dominio.
Esta operación es útil para simplificar algunas consultas y se representa por el símbolo
÷.
El resultado es una nueva tabla formada por:

• Cabecera: Los atributos de la tabla dividendo excluidos los atributos de la tabla
divisora.
• Cuerpo: Un conjunto de tuplas, que concatenadas con la tabla divisora permiten
obtener la tabla dividendo.
Se puede expresar en función de la proyección del producto cartesiano y la diferencia de

la siguiente manera:
Tabla1 : Tabla2 = πc(Tabla1) -πc(Tabla2 x πc (Tabla1) – Tabla1)
Donde c representa el conjunto de atributos de la Tabla1 menos los atributos de

la Tabla 2.
Supongamos que tenemos dos relaciones A(x, y) y B(y) donde el dominio de y en A y B,

es el mismo. El operador división A ÷ B retorna todos los distintos valores de x tales que
para todo valor y en B existe una tupla (x,y) en A.
Ejemplo:
TABLA1: EMP_PROY TABLA2: PROYECTOS

EMPLEADO PROYECTO PROYECTO
1 101 101
1 102 103
2 101

2 103
2 104
3 105
Queremos obtener EMP_PROY : PROYECTOS, o lo que es lo mismo: todos los

empleados que trabajan en todos los proyectos (contenidos en la tabla
PROYECTOS).
Solución:
TABLA (EMP_PROY : PROYECTOS)

EMPLEADO
2
Procedemos con el desarrollo del problema, para ver su resolución paso a paso.
πEMPLEADO(EMP_PROY)
EMPLEADO
1
2
3
PROYECTOS x πEMPLEADO (EMP_PROY)

PROYECTO EMPLEADO
101 1
101 2
101 3
103 1
103 2
103 3
PROYECTOS x πEMPLEADO (EMP_PROY) – EMP_PROY

PROYECTO EMPLEADO
101 3
103 1
103 3
πEMPLEADO (PROYECTOS x πEMPLEADO (EMP_PROY) – EMP_PROY)

EMPLEADO
3
1
πEMPLEADO(EMP_PROY)- πEMPLEADO (PROYECTOS x πEMPLEADO (EMP_PROY ) – EMP_PROY)

EMPLEADO
2

Reunión, combinación o join de dos tablas.- Existen diferentes tipos de combinación,

siendo la más común la conocida por reunión theta (ф). Supongamos dos tablas o
relaciones compatibles respecto al producto cartesiano. La combinación de dos tablas
consiste en una nueva tabla que se obtiene del producto cartesiano de ambas tablas,
pero sólo aquellas filas que cumplen una determinada condición.
Se representa por (TABLA1 * TABLA2) condición
FACTURAS
NFACTURA CLIENTE FECHA
10001 12 10/09/2010
10002 14 12/09/2010
LINEAS-FACTURAS
FACTURA LINEA PRODUCTO IMPORTE
10001 1 10212 100
10001 2 41331 20
10001 3 45233 45
10002 1 11023 1456
10002 2 18133 44
(FACTURAS * LINEAS-FACTURAS)NFACTURA=FACTURA
(FACTURAS * LINEAS-FACTURAS)NFACTURA=FACTURA
NFACTURA CLIENTE FECHA FACTURA LINEA PRODUCTO IMPORTE
10001 12 10/09/2010 10001 1 10212 100
10001 12 10/09/2010 10001 2 41331 20
10001 12 10/09/2010 10001 3 45233 45
10002 14 12/09/2010 10002 1 11023 1456
10002 14 12/09/2010 10002 2 18133 44
Es posible escribir expresiones algebraicas que sirvan para:
Definir los datos que se van a obtener de una base de datos en una consulta.
Definir los datos que se van a insertar, modificar o eliminar en un proceso de
actualización.
Definir vistas de la base de datos.
Definir restricciones de integridad y de acceso.
Mediante la expresión algebraica el usuario especificará qué quiere hacer, el sistema la

optimizará, traducirá de acuerdo con reglas del álgebra relacional y ejecutará la orden
obteniendo los datos.
Ejemplo:

CLIENTES (CODIGO, CIF, NOMBRE, DIRECCION, LOCALIDAD, PROVINCIA, CP)
FACTURAS (NUM_FACTURA, FECHA, CLIENTE, OBSERVACIONES)
LINEAS_FACTURAS (FACTURA, LINEA, REFERENCIA, CANTIDAD, PRECIO)
Obtener los nombres de los clientes que nos han hecho alguna compra (tiene facturas)
ΠNOMBRE ((CLIENTES * FACTURAS)CLIENTES.CODIGO=FACTURAS.CLIENTE)
Con la finalidad de evitar ambigüedades se suele poner el nombre de la tabla antes del
nombre del atributo separándolos por un punto: TABLA.ATRIBUTO
Por otro lado, algunos autores han propuesto incorporar operadores nuevos que doten de
mayor flexibilidad a las operaciones algebraicas. Los más comunes son:
RENOMBRAR.- Permite cambiar el nombre de un atributo de una tabla. Esto puede

ser necesario para realizar alguna operación algebraica de las señaladas. Este
operador devuelve una copia de la tabla con algún nombre de atributo cambiado.
CLIENTES RENOMBRAR CLIENTE COMO ID_CLIENTE, LOCALIDAD COMO CIUDAD
AMPLIAR.- El operador de ampliación toma como operando una relación y

devuelve otra semejante a la original pero con atributos añadidos. Estos atributos
nuevos se obtienen de la evaluación de expresiones de cálculo.
LINEAS_FACTURAS AMPLIAR (PRECIO*CANTIDAD) COMO IMPORTE
AGRUPAR.- Permite agrupar en subconjuntos tuplas con valores comunes de

ciertos atributos y aplicar a estos subconjuntos funciones de grupo como SUMA,
CUENTA, PROMEDIO, MAXIMO, MÍNIMO, etc.
LINEAS_FACTURAS AMPLIAR (PRECIO*CANTIDAD) COMO IMPORTE

AGRUPAR POR FACTURA, SUMA (IMPORTE COMO TOTAL_FACTURA
Obtiene tuplas con el mismo número de factura (resultado de agrupar cada línea de la
factura) y con el total de la factura (resultado de obtener la suma del precio*cantidad de
cada línea).

Tema 05 - Normalizacion y Algebra Relacional - P3.1

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema 05 - Normalizacion y Algebra Relacional - P3.1

Cargado por

Copyright:

Formatos disponibles

Tema 5: Normalización y álgebra

Esta obra está bajo una licencia de Reconocimiento-

Para ver una copia de esta licencia visite:

Cuando se diseña un determinado software o una aplicación informática, al principio no

Esas tablas obtenidas en el modelo relacional, pueden presentar ciertas anomalías,

La normalización es una técnica de diseño de bases de datos relacionales a partir de los

La normalización busca agrupar los atributos en relaciones de modo que se minimice la

Las actualizaciones de los datos almacenados en la BD pueden llevarse a cabo con un

En el proceso de normalización se debe ir comprobando que

Joaquín Alvarez García y Pilar García López Página 2

Vamos a ver las fases de la normalización una base de datos

La Teoría de Normalización se basa en el concepto de dependencias funcionales entre

Las dependencias funcionales son de primordial importancia a la hora de encontrar y

La dependencia funcional es una noción semántica. Si hay o no dependencias

Joaquín Alvarez García y Pilar García López Página 3

Restricciones de integridad establecidas por el usuario que permiten conocer las

Supongamos el siguiente ejemplo:

Tenemos un tabla (o relación) EMPLEADO cuyos atributos son DNI, NOMBRE,

DNI NOMBRE, DIRECCION, TELEFONO, DEPARTAMENTO.

Hemos de tener en cuenta que una dependencia funcional puede cumplirse en un

Ahora bien, si en nuestro problema necesitáramos almacenar (o quisiéramos

Consideramos un esquema de relación general R(A), con A el conjunto de sus atributos,

Se dice que un conjunto de atributos (Y) depende funcionalmente de otro conjunto de

Joaquín Alvarez García y Pilar García López Página 4

X se conoce como determinante o implicante e Y como implicado.

En una dependencia funcional X Y, cuando X es un conjunto de atributos,

Por ejemplo, si el descriptor X es compuesto, X(X1, X2), se dice que Y tiene

Y depende funcionalmente de manera completa de X,

Una dependencia funcional completa se representa como:

Si la dependencia funcional no fuese completa se diría parcial.

Una dependencia funcional X → Y es una dependencia parcial si existe algún atributo

Supongamos la relación PEDIDOS (Cod_Cliente, Cod_Producto, Cantidad), el conjunto de

Cod_Cliente + Cod_Producto Cantidad

Joaquín Alvarez García y Pilar García López Página 5

Veamos ahora otro ejemplo:

NOTAS (codEstudiante, nombre, mediaExamenes, asignatura, nota)

codEstudiante nombre mediaExamenes asignatura nota

La clave primaria de la tabla viene determinada por codEstudiante + asignatura.

Además, codEstudiante + asignatura mediaExamenes

y codEstudiante + asignatura nota

Consideramos la relación R(X, Y, Z) con las siguientes dependencias funcionales:

NOMBRE_ALUMNO DIRECCION POBLACION

NOMBRE_ALUMNO determina su DIRECCION y su DIRECCION determina la POBLACION en

Joaquín Alvarez García y Pilar García López Página 6

Sean X e Y dos descriptores, se dice X multidetermina a Y (X Y) si para cada

Por ejemplo, supongamos una tabla como la siguiente:

La teoría de la normalización ayuda a los diseñadores a prevenir problemas de

Joaquín Alvarez García y Pilar García López Página 7

DNI NOMBRE ASIGNATURA NOTA

DNI NOMBRE ASIGNATURA1 ASIGNATURA2 NOTA1 NOTA2

DNI NOMBRE ASIGNATURA NOTA

Joaquín Alvarez García y Pilar García López Página 8

En ambos casos la tabla ya estaría en la Primera Forma Normal, aunque podemos

Supongamos la relación siguiente:

ALUMNADO (DNI, COD_ASIG, NOMBRE, APELLIDOS, NOTA, CURSO, AULA)

DNI COD_ASIG NOMBRE APELLIDOS NOTA CURSO AULA

Si analizamos las dependencias funcionales tendremos:

DNI NOMBRE, APELLIDOS

La clave de la relación es DNI+COD_ASIG. Como no todos los atributos que no forman

¿Qué problemas conlleva que no esté en la Segunda Forma Normal?

Anomalías en la inserción de tuplas: Tenemos anomalías de inserción ya que no se

Anomalías en el borrado de tuplas: Igualmente aparecen anomalías en el borrado

Anomalías en la actualización de tuplas: Si se hace un cambio de aula para una