You are on page 1of 37

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
Anomalías de Modificación

3.

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 EMP_PROY1
Dni NumProyecto Horas NombreProyecto UbicacionProyecto

UbicaciónProyecto

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:
Dni NombreE

a)

b)
c)

Numproyecto
{Dni, NumerpDpto}

{NombreProyecto, UbicaciónProyecto}
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:
X X se verifica siempre

A1 Reflexibilidad

A2 Aumento
A3 Transitividad A4 Unión

X
{X {X

Y
Y,Y Y y X Y

XU Z
Z} Z} X

Y
X X Z con Z W} Z YU Z Y XUZ W

A5 Descomposición X A6 Pseudotransitividad { X

Y y Y U Z