Upload
kio-seijero
View
578
Download
0
Embed Size (px)
Citation preview
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