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

Ing. Luis Reyes

NORMALIZACION

DE BASES DE DATOS

-DEPENDENCIAS FUNCIONALES-

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

NombreE Dni FechaNac Dirección NumeroDpto

EMPLEADO

NombreDpto NumeroDpto DniDirector

DEPARTAMENTO

NumeroDpto Ubicación_DPTO

LOCALIZACIONES_DPTO

NombreProyecto NumProyecto UbicacionProyecto Dirección NumeroDpto

PROYECTO

Dni NumeroProyecto Horas

TRABAJA_EN

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

NombreE Dni FechaNac Dirección NumeroDpto NombreDpto DniDirector

EMP_DEPT

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

NombreE Dni FechaNac Dirección NumeroDpto NombreDpto DniDirector

EMP_DEPT

EMP_PROY

Dni NumProyecto Horas NombreE NumeroDpto NombreProyecto UbicacionProyecto

NombreE UbicaciónProyecto

EMP_LOCS

Dni NumProyecto Horas NombreProyecto UbicacionProyecto

EMP_PROY1

TABLAS ALTERNAS A EMP_PROY

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 tuplasresultantes que no pertenecen a esta tabla se les llama tuplasfalsas.

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 Y y Y Z.

Entonces las siguientes reglas se cumplen:

A1 Reflexibilidad X X se verifica siempre

A2 Aumento X Y X U Z Y

A3 Transitividad { X Y , Y Z } X Z

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

A5 Descomposición X Y X Z con Z Y

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