NORMALIZACION

DE BASES DE DATOS
-DEPENDENCIAS FUNCIONALES-

Diseño y Administración de Base de Datos I

Ing. Luis Reyes
NORMALIZACIÓN DE LAS BASES DE DATOS
 La normalización es el proceso de organizar los datos
en una base de datos.

 Esto incluye la creación de tablas y que establece

relaciones entre aquellas tablas según reglas
diseñadas para proteger los datos y hacer la base de
datos que es más flexible al eliminar redundancia y
dependencia incoherente.
DEPENDENCIA INCOHERENTE ?
 Aunque para un usuario puede resultar intuitivo buscar
la dirección de un determinado cliente en la tabla
Clientes, es posible que no tenga sentido buscar en
esa misma tabla el sueldo del empleado que atiende a
dicho cliente.
 El salario del empleado está relacionado con el
empleado (es decir, existe una dependencia entre
ambos), por lo que debe moverse a la tabla
Empleados.
 Las dependencias incoherentes pueden dificultar el
acceso a los datos, ya que la ruta de acceso a los
mismos puede estar rota o no encontrarse.
NORMALIZACIÓN DE LAS BASES DE DATOS
 Los datos redundantes desperdician espacio en disco
y crean problemas de mantenimiento.
 Si es necesario cambiar datos que aparecen en más
de un sitio, el cambio deberá ser exactamente igual en
todos estos sitios.
 Por ejemplo, un cambio de dirección de un cliente es
mucho más fácil de implementar si los datos sólo se
almacenan en la tabla Clientes y en ningún otro lugar
de la base de datos.
EL PROCESO DE NORMALIZACIÓN
 Consiste en la aplicación de reglas para definir
adecuadamente los datos que compondrán las
tablas, observando:
 Minimizar redundancias
 Eliminar anomalías de actualización
 Proveer mejor acceso a cualquier dato
 Asegurar resistencia al mantenimiento en el modelo
de datos
 TERMINOLOGÍA RELACIONAL EQUIVALENTE

 Relación = tabla o archivo

 Tupla = registro, fila o renglón
 Atributo = columna o campo
 Clave = llave o código de identificación
 Clave Candidata = superclave mínima
 Clave Primaria = clave candidata elegida
 Clave Ajena = clave externa o clave foránea
 Clave Alternativa = clave secundaria
 Dependencia Multivaluada = dependencia multivalor
 RDBMS = Del inglés Relational Data Base Manager System que significa,
Sistema Gestor de Bases de Datos Relacionales.
 1FN = Significa, Primera Forma Normal o 1NF del inglés First Normal Form.
 Los términos Relación, Tupla y Atributo derivan del álgebra y cálculo
relacional, que constituyen la fuente teórica del modelo de base de datos
relacional.
LAS REGLAS DE LA NORMALIZACIÓN
 Existen unas cuantas reglas para la normalización de
bases de datos.
 Cada regla se denomina "forma normal"

 Si se cumple la primera regla, se dice que la base de

datos está en la "primera forma normal"
 Si se cumplen las tres primeras reglas, se considera
que la base de datos está en la "tercera forma normal"
 Aunque existen otros niveles de normalización, se
considera que la tercera forma normal es el máximo
nivel necesario para la mayoría de las aplicaciones.
QUÉ HAY QUE NORMALIZAR ?
Cuatro medidas informales de calidad para el
diseño de un esquema de relación:

1. La semántica de los atributos

2. La reducción de información redundante en las tuplas

3. La reducción de los valores NULL en la tuplas

4. Prohibición de la posibilidad de generar tuplas falsas

 NORMALIZACIÓN DE LAS BASES DE DATOS
EJEMPLO 1
EMPLEADO
NombreE Dni FechaNac Dirección NumeroDpto

DEPARTAMENTO
NombreDpto NumeroDpto DniDirector

LOCALIZACIONES_DPTO
NumeroDpto Ubicación_DPTO

PROYECTO
NombreProyecto NumProyecto UbicacionProyecto Dirección NumeroDpto

TRABAJA_EN
Dni NumeroProyecto Horas
 En el caso de la diapositiva precedente observamos
que se cumple con una buena semántica de los
atributos por que base de datos se puede explicar con
bastante facilidad.
DIRECTRIZ 1:
 Diseñar un programa de relación que sea fácil explicar
su significado.
 NO combine atributos de varios tipos de entidad y de
relación en una única relación.
 Intuitivamente, si un esquema de la relación se
corresponde con un tipo de entidad o de relación , es
correcto interpretar y explicar su significado.
 Por el contrario, si la relación está compuesta por una
mezcla de múltiples entidades y relaciones, se
producirá un ambigüedad semántica y la relación no
podrá explicarse con claridad.
 NORMALIZACIÓN DE LAS BASES DE DATOS:
EJEMPLO 2

EMP_DEPT
NombreE Dni FechaNac Dirección NumeroDpto NombreDpto DniDirector

EMP_PROY
Dni NumProyecto Horas NombreE NumeroDpto NombreProyecto UbicacionProyecto
EL EJEMPLO 2, ES UN DISEÑO POBRE
 Aunque desde el punto de vista lógico no existe nada
ilógico no existe nada erróneo en estas dos relaciones.
 Se considera que tienen un diseño pobre porque violan
la directriz 1 al mezclar atributos de dos entidades del
mundo real:
 EMP_DEPT combina atributos de empleados y
departamentos,
 Mientras que EMP_PROY combina atributos de empleados
y proyectos y la relación TRABAJA_EN.
 Deberían utilizarse como vistas, aunque esto provocaría
problemas cuando se usasen como relaciones base.
EVITAR INFORMACIÓN REDUNDANTE EN
TUPLAS Y ANOMALÍAS EN LA ACTUALIZACIÓN

 Uno de los objetivos de un esquema de diseño es reducir

el espacio de almacenamiento utilizado por las relaciones
base (y, por tanto , por los ficheros correspondientes).
 El agrupamiento de atributos en esquemas de relación
tiene un efecto significativo sobre el espacio de
almacenamiento.
 Por ejemplo, si comparamos el espacio empleado por las
dos relaciones base EMPLEADO y DEPARTAMENTO del
ejemplo 1 con el necesario para EMPT_DEPT, los valores
de atributo pertenecientes a un departamento particular
(Numerodpto, NombredDpto, DniDirector) están repetidos
para cada empleado que trabaja en ese departamento.
EVITAR INFORMACIÓN REDUNDANTE EN
TUPLAS Y ANOMALÍAS EN LA ACTUALIZACIÓN

 Por el contrario, la información de cada departamento

sólo aparece una vez en la relación DEPARTAMENTO
del ejemplo 1.
 Por cada empleado que trabaja en ese departamento,
solo se repite el número de departamento
(NumeroDpto) en la relación empleado como una clave
fóranea.
 Lo mismo sucede con la relación EMP_PROY, que
aumenta la relación TRABAJA_EN con atributos
adicionales procedentes de EMPLEADO Y
PROYECTO.
ANOMALÍAS DE ACTUALIZACIÓN
Deberemos entender por Actualización al
hecho que una tabla en base de datos, se
ve afectada o alterada ya sea agregando,
borrando o cambiando datos.

1. Anomalías de Inserción

2. Anomalías de Borrado

3. Anomalías de Modificación
ANOMALÍAS DE INSERCIÓN (1)
 En el ejemplo 2 en la relación EMP_DEPT, si
introducimos una tupla, tendremos dos situaciones:
a) Si introducimos un empleado y este no esta asignado a un
departamento entonces el atributo NombreDpto deberá
ser llenado con NULL,
b) En el segundo caso es decir que el empleado tenga
asignado un departamento entonces cuando se escriba
este dato se tendrá que volver a escribir el nombre
completo de departamento cuantas veces sea necesario
teniendo a la vez cuidado de que esté identicamente
escrito a como se encuentra guardado en las demás
tuplas que se refieren a empleados del mismo
departamento.
ANOMALÍAS DE INSERCIÓN (2)
 Es complicado insertar un nuevo departamento que aún no
tenga ningún empleado en la relación EMP_DEPT.
 La única forma de hacerlo es colocando valores NULL en
los atributos correspondientes al empleado.
 Esto genera un problema, ya que el DNI es la clave
principal de EMP_DEPT, y se supone que cada tupla
representa a una entidad empleado, no a una entidad
departamento.
 Además, cuando se asigna el primer empleado a ese
departamento, ya no necesitaremos nunca más esta tupla
con valores NULL.
 Este problema no se da en el diseño del ejemplo 1, por que
un departamento se introduce en la relación departamento
independientemente de que existan empleados en el.
ANOMALÍAS DE BORRADO
 Siguiendo con el ejemplo 2, si eliminamos una tupla
perteneciente a la relación EMP_DEPT, y esta tupla tiene
la característica de que en el atributo NombreDpto el valor
que tiene es único en toda la tabla
 Es decir ese empleado es el único que pertenece a ese
departamento, entonces resultaremos perdiendo ese
departamento, por que no se encuentra repetido en ninguna
tupla, por lo que al hacer un proyección que contenga
solamente a NombreDpto con el objeto de tener la lista de
departamentos de la empresa
 El que pertenecía a la tupla eliminada no aparecerá y la
relación EMP_DEPT, nos esta demostrando que no es
fiable para obtener la información exacta de los
departamentos.
ANOMALÍAS DE MODIFICACIÓN
 En EMP_DEPT, si cambiamos el valor de uno de los
atributos de un departamento particular ( por ejemplo,
el director del departamento 5), debemos actualizar las
tuplas de todos los empleados que trabajan en ese
departamento;
 En caso de no hacerlo, la base de datos se volverá
inconsistente.
 Si falla la actualización de alguna tupla, el mismo
departamento tendrá dos valores diferentes como
director en distintas tuplas de empleado, lo que será
incorrecto.
DIRECTRIZ 2
 Diseñar los esquemas de la relación base de forma
que no se presenten anomalías de inserción, borrado o
actualización en las relaciones.
 En caso de que aparezca alguna de ellas, anótela
claramente y asegúrese de que los programas que
actualizan la base de datos operarán correctamente.
ANOMALÍAS DE VALORES NULL
 En algunos diseños podemos agrupar muchos
atributos en una relación muy “grande”.
 Si muchos de los atributos no se aplican a todas las
tuplas de la relación, nos encontraremos con muchos
valores NULL en esas tuplas.
 Esto puede desperdiciar espacio de almacenamiento
y puede inducir a problemas a la hora de entender el
significado de los atributos, como por ejemplo:
a) El atributo no se aplica a esta tupla
b) El valor de atributo de esta tupla es desconocido.
c) El valor es conocido pero esta ausente, es decir, aún
no se ha grabado.
DIRECTRIZ 3
 Hasta donde sea posible, evite situar en una relación base atributos
cuyos valores sean NULL frecuentemente. En caso de no poderse
evitar, asegúrese de que se aplican sólo en casos excepcionales y no
los aplique a la mayor parte de las tuplas de la relación.
 Utilizar el espacio eficientemente y evitar concatenaciones son los
dos criterios principales que determinan si incluir las columnas que
pueden tener valores NULL en una relación o tener una relación
separada para esas columnas (con las columnas clave apropiadas).
 Por ejemplo, si sólo el 10 por ciento de los empleados tienen oficinas
individuales, no es razón suficiente para la inclusión de un atributo
NumeroOficina en la relación EMPLEADO; en lugar de ello, se puede
crear una relación OFICINAS_EMPS(DniEmpleado , NumeroOficina)
que incluya las tuplas de los empleados con oficinas individuales.
NORMALIZACIÓN DE LAS B.D.
GENERACIÓN DE TUPLAS FALSAS
EMP_DEPT
NombreE Dni FechaNac Dirección NumeroDpto NombreDpto DniDirector

EMP_PROY
Dni NumProyecto Horas NombreE NumeroDpto NombreProyecto UbicacionProyecto

TABLAS ALTERNAS A EMP_PROY

EMP_LOCS
NombreE UbicaciónProyecto

EMP_PROY1
Dni NumProyecto Horas NombreProyecto UbicacionProyecto
ACLARACIONES DEL MODELO
 Según los esquemas relacionales de las diapositivas anterior,
podemos observar que las tablas EMP_LOCS y EMP_PROY1 , se
pueden sacar de hacer las correspondientes operaciones de
proyección sobre EMP_PROY .
 Supongamos que utilizamos las tablas EMP_LOCS y
EMP_PROY1 como relaciones base en lugar de EMP_PROY.
Esto produce un diseño de esquema incorrecto algo peculiar por
que no podemos recuperar la información original de la tabla
EMP_PROY, utilizando las dos primeras ya que si intentamos
llevar a cabo una operación CONCATENACION NATURAL en
estas relaciones, el resultado produce muchas mas tuplas que las
existentes en el conjunto original EMP_PROY y a las tuplas
resultantes que no pertenecen a esta tabla se les llama tuplas
falsas.
 Hay que aclarar que el join natural se efectuó tomando el atributo
UbicaciónProyecto y este no es ni una clave principal ni una clave
foránea en ninguna de las dos tablas.
DIRECTRIZ 4
 Diseñar los esquemas de relación de forma que
puedan concatenarse en condiciones de igualdad en
los atributos que son parejas de clave principal y clave
foránea de forma que se garantice que no se van a
generar tuplas falsas.
 Evite las relaciones que contienen atributos
coincidentes que no son combinaciones de clave
foránea y clave principal por que la concatenación de
estos atributos puede producir tuplas falsas.
RESUMEN Y EXPLICACIÓN ACERCA DE LAS
DIRECTIVAS DE DISEÑO:

1) Anomalías que causan trabajo redundante durante la

inserción y modificación de una relación, y que
pueden causar perdidas accidentales de información
durante el borrado de la misma.

2) Desaprovechamiento del espacio de almacenamiento

debido a valores NULL y la dificultad de llevar a cabo
operaciones de selección, agregación y
concatenación debido a estos valores

3) Generación de datos incorrectos y falsos durante las

concatenaciones en relaciones base incorrectamente
relacionadas.
DEPENDENCIAS FUNCIONALES
Introducción:
 Una dependencia funcional es una restricción que se
establece entre dos conjuntos de atributos de la base
de datos.
 Supongamos que nuestro esquema de base de datos
relacional tiene n atributos A1, A2, ……..An;
pensemos que la base de datos completa esta descrita
por un único esquema de relación universal R= {A1,
A2, ……..An }
 No se sugiere que vamos a almacenar la base de
datos como una única tabla universal; usamos este
concepto sólo en el desarrollo de la teoría formal de las
dependencias de datos.
DEPENDENCIAS FUNCIONALES
Definición:
 Una dependencia funcional, denotada por
X Y, entre dos conjuntos de atributos de X e Y
que son subconjuntos de R, especifica una restricción
en las posibles tuplas que pueden formar un estado
de relación r de R.
 La restricción dice que dos tuplas t1 y t2 en r que
cumplen t1[X] = t2[X], deben cumplir también que t1[Y]
= t2[Y].
DEPENDENCIA FUNCIONAL

 Una dependencia funcional es una conexión entre uno o

más atributos. Por ejemplo si conocemos el valor de
FechaDeNacimiento podemos conocer el valor de Edad.
 Las dependencias funcionales del sistema se escriben
utilizando una flecha, de la siguiente manera:
 FechaDeNacimiento Edad
 Aquí a FechaDeNacimiento se le conoce como un
determinante. Se puede leer de dos formas
FechaDeNacimiento determina a Edad o Edad es
funcionalmente dependiente de FechaDeNacimiento.
DEPENDENCIAS FUNCIONALES
 Esto significa que los valores del componente Y de una
tupla de r dependen de, o están determinadas por los
valores del componente X;
 alternativamente, los valores del componente X de una
tupla únicamente ( o funcionalmente) determinan los valores
del componente Y.
 Decimos también que existe una dependencia funcional de
X hacia Y, o que Y es funcionalmente dependiente de X. La
abreviatura de dependencia funcional es DF, o FD o f.d (del
inglés, Functional dependency).
 El conjunto de atributos X recibe el nombre de lado
izquierdo de la DF, mientras que Y es el lado derecho.
 Por tanto, X determina funcionalmente Y si para toda
instancia r del esquema de relación R, no es posible que r
tenga dos tuplas que coincidan en los atributos de X y no lo
hagan en los atributos de Y.
OBSERVAR LO SIGUIENTE:
a) Si una restricción de R indica que no puede haber
más de una tupla con un valor X concreto en
cualquier instancia de relación r(R) , es decir que X
es una clave candidata de R, se cumple que
X Y para cualquier subconjunto de atributos Y
de R [ya que la restricción de clave implica que dos
tuplas en cualquier estado legal r(R) no tendrán el
mismo valor de Y.

a) Si X Y en R, esto no supone que Y X en R

REFLEXIÓN SOBRE LAS DEPENDENCIAS
FUNCIONALES
Reflexión sobre la dependencia funcional:
 Una dependencia funcional es una propiedad de la
semántica o significado de los atributos. Los diseñadores
de la base de datos utilizarán primero su comprensión de la
semántica de los atributos de R ( estos es, cómo se
relacionan unos con otros) para especificar las
dependencias funcionales que deben mantenerse en todos
los estados de relación (extensiones) r de R.
 Ciertas DF pueden especificarse sin hacer referencias a
una relación específica. Por ejemplo, {Provincia,
NumPermisoConducir} Dni debe mantenerse
para cualquier adulto que viva en España.
 Considérese el esquema de la relación EMP_PROY del
ejemplo 2: desde el punto de vista de la semántica de los
atributos sabemos que deben mantenerse las siguientes
dependencias funcionales:
REFLEXIÓN SOBRE LAS DEPENDENCIAS
FUNCIONALES
Reflexión sobre la dependencia funcional:
 Una dependencia funcional es una propiedad de la
semántica o significado de los atributos. Los
diseñadores de la base de datos utilizarán primero su
comprensión de la semántica de los atributos de R (
estos es, cómo se relacionan unos con otros) para
especificar las dependencias funcionales que deben
mantenerse en todos los estados de relación
(extensiones) r de R.
 Ciertas DF pueden especificarse sin hacer referencias
a una relación específica. Por ejemplo, {Provincia,
NumPermisoConducir} Dni debe
mantenerse para cualquier adulto que viva en España.
... REFLEXIONES
 Considérese el esquema de la relación EMP_PROY
del ejemplo 2: desde el punto de vista de la semántica
de los atributos sabemos que deben mantenerse las
siguientes dependencias funcionales:
a) Dni NombreE
b) Numproyecto {NombreProyecto, UbicaciónProyecto}
c) {Dni, NumerpDpto} Horas
REGLAS DE INFERENCIA DE LAS
DEPENDENCIAS FUNCIONALES:

 Decimos que F es el conjunto de dependencias

funcionales especificadas en un esquema de relación
R. Entonces definimos lo siguiente:
 Formalmente, el conjunto de todas las dependencias
que incluyen F, junto con las dependencias que
pueden inferirse de F, reciben el nombre de
cerraduras (o clausuras) de F y esta designada
mediante la notación F+ .
Axiomas de inferencia de Amstrong para cerraduras:
 Sean X, Y, Z subconjuntos de atributos de una relación
R, en donde se verifican las dependencias funcionales
X Yy Y Z.
  Entonces las siguientes reglas se cumplen:

A1 Reflexibilidad X X se verifica siempre

A2 Aumento X Y XU Z Y

A3 Transitividad {X Y,Y Z} X Z

A4 Unión {X Y y X Z} X YU Z

A5 Descomposición X Y X Z con Z Y

A6 Pseudotransitividad { X Y y Y U Z W} XUZ W