Tema 7: Otros conceptos de diseo de bases de datos relacionales

n Aseveraciones n Disparadores (triggers) n Seguridad n Autorizacin n NORMALIZACIN

H H H H H H H H

Primera forma normal Problemas en el diseo lgico relacional Dependencias funcionales Descomposicin Forma normal de Boyce-Codd Tercera forma normal Otras formas normales y dependencias multivaluadas Proceso global de diseo de bases de datos

Bases de datos

Aseveraciones
n Una aseveracin es un predicado que expresa una condicin

que queremos que se cumpla siempre en la base de datos.

n Cuando se hace una aseveracin, el sistema comprueba su

validez, y la comprueba de nuevo en cada actualizacin que puede violar la aseveracin

H Esta comprobacin puede introducir una sobrecarga importante; por tanto las aseveraciones se deben utilizar con mucho cuidado.
n Aseverar

para todo X, P(X) se consigue de manera indirecta con no existe X tal que no P(X)

Bases de datos

Ejemplo de aseveracin
n La suma de todos los prstamos de cada sucursal debe ser

menor que la suma de todos los saldos de cuentas de esa sucursal. create assertion restriccion-suma check (not exists (select * from sucursal where (select sum(cantidad) from prestamo where prestamo.-nombre-sucursal = sucursal.nombre-sucursal) >= (select sum(saldo) from cuenta where cuenta.nombre-sucursal = sucursal. nombre-sucursal)))

Bases de datos

Disparadores
n Un disparador es una sentencia que se ejecuta

automticamente por el sistema como efecto lateral de una modificacin de la base de datos.
n Para especificar un disparador debemos:

H Especificar las condiciones par a su ejecucin. H Especificar las acciones a realizar cuando se ejecuta.
n Los disparadores se introdujeron en el estndar SQL en

SQL:1999, pero eran soportados antes por la mayora de los gestores de bases de datos mediante sintaxis no estndar.

Bases de datos

Ejemplo de disparador
n Supongamos que en vez de permitir saldos de cuenta negativos,

el banco trata los descubiertos de la siguiente manera:

H poniendo el saldo de la cuenta a cero H creando un prstamo por la cantidad del descubierto H dando a ese prstamo un nmero de prstamo idntico al nmero de cuenta de la cuenta al descubierto
n La condicin para ejecutar el disparador ser una actualizacin

de la relacin cuenta que d lugar a un valor de saldo negativo.

Bases de datos

Ejemplo de disparador en SQL:1999

create trigger descubierto after update on cuenta referencing new row as nrow for each row when nrow.saldo < 0 begin atomic insert into prestatario (select nombre-cliente, numero-cuenta from depositante where nrow.numero-cuenta = depositante.numero-cuenta); insert into prestamo values (n.row.numero-cuenta, nrow.nombre-sucursal, nrow.saldo); update cuenta set saldo = 0 where cuenta.numero-cuenta = nrow.numero-cuenta end

Bases de datos

Eventos y acciones de disparadores en SQL

n Los eventos de disparo pueden ser: insertar, eliminar o actualizar n Los disparadores sobre actualizaciones se pueden restringir a

determinados atributos
H P.e. create trigger descubierto after update of saldo on cuenta
n Se pueden referenciar los valores anteriores y posteriores a una

actualizacin
n Los disparadores se pueden activar antes de un evento, con lo que

pueden servir como restricciones adicionales. P.e. convertir blancos a nulos: create trigger ponernulos before update on r referencing new row as nrow for each row when nrow.numero-telefono= set nrow.numero-telefono= null
Bases de datos 7

Disparadores a nivel de sentencia

n En vez de ejecutar una accin separada para cada fila afectada,

se puede ejecutar una sola accin para todas las filas afectadas por una transaccin
H Utilizar for each statement en vez de for each row H Utilizar referencing old table o referencing new table para referirse a tablas temporales (llamadas tablas de transicin) que contengan las filas afectadas H Puede ser ms eficiente cuando tratamos sentencias SQL que afectan a muchas filas

Bases de datos

Seguridad
n Seguridad proteccin frente a intentos maliciosos de robar o

modificar datos.
H Nivel de sistema de bases de datos
4

Mecanismos de autentificacin y autorizacin permiten a determinados usuarios acceder slo a los datos requeridos Los superusuarios del sistema operativo pueden hacer cualquier cosa en las bases de datos! Se necesita una buena seguridad a nivel de sistema operativo. Escuchas (lecturas no autorizadas de mensajes) Suplantaciones (pretender ser un usuario autorizado o enviar mensajes supuestamente de usuarios autorizados)

H Nivel de sistema operativo

4

H Nivel de red: debemos utilizar cifrado para prevenir

4 4

Bases de datos

Seguridad (Cont.)
H Nivel fsico
4 4

El acceso fsico a los servidores permite que los intrusos destruyan datos; se necesita seguridad fsica tradicional Las mquinas deben protegerse tambin contra lquidos, fuego, etc. Nos debemos asegurar de que los usuarios no den acceso a intrusos Uso adecuado de password

H Nivel humano
4 4

Bases de datos

10

Autorizacin
Formas de autorizacin sobre partes de la base de datos:
n Autorizacin de lectura se permite leer, pero no modificar los

datos.
n Autorizacin de insercin se permite introducir nuevos datos,

pero no modificar los existentes.

n Autorizacin de actualizacin se permite modificar, pero no

borrar datos.
n Autorizacin de eliminacin se permite eliminar datos.

Bases de datos

11

Autorizacin (Cont.)
Formas de autorizacin para modificar el esquema de la base de datos:
n Autorizacin de ndexado se permite crear y eliminar ndices. n Autorizacin de recursos se permite crear nuevas relaciones. n Autorizacin de alteracin se permite aadir o eliminar atributos

de una relacin.
n Autorizacin de borrado se permite borrar relaciones.

Bases de datos

12

Autorizacin y vistas
n Los usuarios pueden obtener autorizaciones sobre vistas, sin

tener ninguna autorizacin sobre las relaciones utilizadas en la definicin de la vista

n La caracterstica de las vistas de ocultar datos sirve tanto para

simplificar el uso del sistema como para aumentar la seguridad permitiendo a los usuarios que slo accedan a los datos que necesitan para su trabajo
n Se puede utilizar una combinacin de seguridad a nivel

relacional y seguridad a nivel de vista para limitar los accesos de los usuarios a los datos que necesitan.

Bases de datos

13

Ejemplo de vista
n Supongamos que un cajero necesita conocer los nombres de los

clientes de cada sucursal, pero no est autorizado para ver informacin especfica sobre los crditos.
H Aproximacin: Denegar el acceso directo a la relacin prestamo, pero permitir el acceso a la vista cliente-prestamo, que est formada solamente por los nombres de los clientes y las sucursales en las que tienen un prstamo. H La vista cliente-prestamo en SQL se define as:

create view cliente-prestamo as select nombre-sucursal, nombre-cliente from prestatario, prestamo where prestatario.numero.prestamo = prestamo.numeroprestamo

Bases de datos

14

Ejemplo de vista (Cont.)

n El cajero estar autorizado a ver el resultado de la consulta: select * from cliente-prestamo n Cuando el procesador de consultas transforme el resultado en

una consulta de las relaciones de la base de datos, obtendremos una consulta sobre prestatario y prestamo.
n Las autorizaciones se deben comprobar sobre la consulta del

cajero antes de que el procesador de consultas reemplace una vista por la definicin de la vista.

Bases de datos

15

Autorizacin sobre vistas

n La creacin de vistas no requiere autorizacin de recursos dado

que no se est creando ninguna relacin real

n El creador de la vista obtiene solo aquellos privilegios que

suponen que no exista autorizacin adicional sobre la que ya tena.

n P.e. si el creador de la vista cliente-prestamo slo tena

autorizacin de lectura sobre prestatario y prestamo, slo obtiene autorizacin de lectura sobre cliente-prestamo

Bases de datos

16

Concesin de privilegios
n El paso de autorizacin de un usuario a otro se puede

representar mediante un grafo de autorizacin.

n Los nodos del grafo representan usuarios. n La raz del grafo es el administrador de la base de datos. n Consideremos el grafo para autorizaciones de actualizacin

sobre prestamo.
n Una flecha Ui Uj indica que el usuario Ui ha concedido

autorizacin de actualizacin sobre prestamo a Uj.

U1

U4

DBA

U2

U5

Bases de datos

U3

17

Grafo de concesin de privilegios

n Requisito: Todas las flechas de un grafo de autorizacin deben partir de

un camino que tenga su origen en el administrador de bases de datos

n Si el DBA revoca el privilegio para U1:

H Se debe revocar la concesin de U4 dado que U1 ya no tiene autorizacin H No se debe revocar la autorizacin de U5 dado que U5 tiene otro camino de
autorizacin desde DBA a travs de U2 n Se deben prevenir ciclos de concesiones sin camino desde la raz:

H DBA concede autorizacin a U7 H U7 concede autorizacin a U8 H U8 concede autorizacin a U7 H DBA revoca la autorizacin a U7 H Se debe revocar la concesin de U7 a U8 y de U8 a U7 dado que no queda
ningn camino desde DBA a U7 o a U8.

Bases de datos

18

Roles
n Los roles permiten especificar slo una vez privilegios comunes a

varios usuarios. n Los privilegios se conceden o revocan a los roles igual que para usuarios individuales n Los roles se pueden asignar a usuarios o a otros roles n SQL:1999 soporta roles
create role cajero create role gestor grant select on sucursal to cajero grant update (saldo) on cuentas to cajero grant all privileges on cuentas to gestor grant cajero to gestor grant cajero to alicia, juan grant gestorr to ana
Bases de datos 19

NORMALIZACIN

Bases de datos

Manuel Ramos Cabrer

20

Primera forma normal

n Un dominio es atmico si sus elementos se pueden considerar

unidades indivisibles
H Ejemplos de dominios no atmicos:
4 4

Nombres, atributos compuestos Nmeros de identificacin como 305010789 que se pueden dividir en partes

n Un esquema relacional R est en primera forma normal si los

dominios de todos los atributos de R son atmicos

n Los valores no atmicos complican el almacenamiento y dan

lugar a redundancia
H P.e. Conjunto de cuentas almacenado con cada cliente, y conjunto de propietarios almacenado con cada cuenta H Vamos a asumir que todas las relaciones estn en primera forma normal
Bases de datos 21

Problemas en el diseo lgico relacional

n El diseo de bases de datos relacionales requiere

encontrar un buen conjunto de esquemas de relacin. Un mal diseo puede dar lugar a:
H Repeticin de informacin (redundancia) H Imposibilidad de representar cierta informacin.
n Objetivos de diseo:

H Evitar la redundancia H Asegurar que se representan las asociaciones entre atributos H Facilitar la comprobacin de las violaciones de restricciones de integridad en las actualizaciones de las bases de datos.

Bases de datos

22

Ejemplo
n Consideremos el siguiente esquema de relacin:

Esquema-prestamo = (nombre-sucursal, ciudad-sucursal, activos, nombre-cliente, numero-prestamo, cantidad)

nombresucursal Vigo Santiago Madrid-1 Vigo ciudadsucursal Vigo Santiago Madrid Vigo activos 9000000 2100000 1700000 9000000 nombrecliente Snchez Gmez Lpez Veiga numeroprestamo L-17 L-23 L-15 L-14 cantidad 1000 2000 1500 1500

n Redundancia:

H Los datos de nombre-sucursal, ciudad-sucursal, activos se repiten para cada

prstamo que hace una sucursal

H Gasto de espacio H Se complica la actualizacin, introduciendo la posibilidad de inconsistencias

n Valores nulos:

H No se puede almacenar informacin sobre una sucursal si no existen

prstamos

H Se pueden utilizar valores nulos, pero son difciles de gestionar.

Bases de datos 23

Descomposicin
n Descompongamos el esquema de relacin Esquema-prestamo

en: Esquema-sucursal = (nombre-sucursal, ciudad-sucursal, activos) Esquema-info-prestamo = (nombre-cliente, numero-cliente, nombre-sucursal, cantidad)
n Todos los atributos del esquema original (R) deben aparecer en

la descomposicin (R1, R2): R = R1 R 2

n Descomposicin reversible por join

Para todas las posibles relaciones r en el esquema R r = R1 (r) R2 (r)

Bases de datos

24

Ejemplo de descomposicin no reversible por join

n Descomposicin de R = (A, B)

R1 = (A)
A B r 1 2 1 A A(r) A
Bases de datos

R2 = (B)
B 1 2 B(r)

A (r)

B (r)

B 1 2 1 2
25

Objetivo Una teor a para:

n Decidir cuando una determinada relacin R est en un estado

adecuado.
n En el caso de que la relacin R no sea buena, descomponerla

en un conjunto de relaciones {R1, R2, ..., R n} tales que

H Cada relacin est en estado adecuado H La descomposicin sea reversible por join
n Nuestra teora est basada en:

H Dependencias funcionales H Dependencias multivaluadas

Bases de datos

26

Dependencias funcionales
n Restricciones sobre el conjunto de relaciones permitidas en un

conjunto relacin.
n Introducen como restriccin que el valor de un conjunto

determinado de atributos determina de manera nica el valor de otro conjunto de atributos.

n El concepto de dependencia funcional es una generalizacin del

concepto de clave.

Bases de datos

27

Dependencias funcionales (Cont.)

n Dado un esquema de relacin R

R y R n La dependencia funcional se da en R si y solo si para cualquier relacin legal r(R), cuando dos tuplas cualquiera t1 y t2 de r coinciden en los valores de los atributos , entonces tambin coinciden en lso valores de los atributos . Es decir, t1[] = t2 [] t1[ ] = t2 [ ] n Ejemplo: Consideremos r(A,B) con la siguiente instancia de r. 1 1 3 4 5 7

n En esta instancia, A B NO se da, pero B A si.

Bases de datos

28

Dependencias funcionales (Cont.)

n K es una superclave del esquema de relacin R si y solo si K R n K es una clave candidata de R si y solo si

H K R, y H Para ningn K, R
n Las dependencias funcionales nos permiten expresar restricciones

que no se pueden expresar mediante superclaves. Consideremos el esquema: Esquema-info-prestamo = (nombre-cliente, numero-prestamo, nombre-sucursal, cantidad). Debemos esperar que se cumplan las siguientes dependencias funcionales: numero-prestamo cantidad numero-prestamo nombre-sucursal pero debemos esperar que no se cumpla: numero-prestamo nombre-cliente
Bases de datos 29

Uso de Dependencias Funcionales

n Utilizamos dependencias funcionales para::

H Comprobar las relaciones para ver si son legales bajo un conjunto dado de dependencias funcionales.
4

Si una relacin r es legal bajo un conjunto F de dependencias funcionales, decimos que r satisface F. Decimos que F se da en R si todas las relaciones legales sobre R satisfacen el conjunto de dependencias funcionales F.

H Especificar restricciones sobre un conjunto de relaciones legales

4

n Nota: Una instancia especfica de un esquema de relacin puede

satisfacer una dependencia funcional aun cuando la dependencia funcional no se d en todas las instancias legales.
H Por ejemplo, una instancia especfica de Esquema-prestamo puede, por tanto, satisfacer numero-prestamo nombre-cliente.

Bases de datos

30

Dependencias funcionales (Cont.)

n Una dependencia funcional es trivial si se satisface para todas

las instancias de una relacin

H P.e.
4 4

nombre-cliente, numero-prestamo nombre-cliente nombre-cliente nombre-cliente

H En general, es trivial si

Bases de datos

31

Cierre de un conjunto de dependencias funcionales

n Dado un conjunto F de dependencias funcionales, hay otras

dependencias funcionales que se pueden inferir de F.

H P.e. Si A B y B C, entonces podemos inferir que A C
n El conjunto de todas las dependencias funcionales que se pueden

inferir de F forman el cierre de F.

n Denotaremos el cierre de F por F+. n Podemos calcular F+ aplicando los Axiomas de Armstrong:

H si , entonces H si , entonces H si , y , entonces

n Estas reglas son

(reflexividad) (aumentacin) (transitividad)

H consistentes (generan solo dependencias funcionales que se dan) y H completas (generan todas las dependencias funcionales que se dan)
Bases de datos 32

Ejemplo
n R = (A, B, C, G, H, I)

F={ AB AC CG H CG I B H}
n Algunos miembros de F+

H AH
4 Por transitividad de A B y B H

H AG I
4 por aumentacin de A C con G, que da AG CG

y despus por transitividad con CG I

H CG HI
4 de CG H y CG I : la regla de la unin se puede inferir de

La definicin de dependencia funcional, o Por aumentacin de CG I para inferir CG CGI, aumentacin de CG H para inferir CGI HI, y entonces transitividad
Bases de datos 33

Procedimiento de clculo de F+
n Para calcular el cierre de un conjunto de dependencias

funcionales F: F+ = F repetir para cada dependencia funcional f en F+ aplicar las reglas de reflexividad y aumentacin a f aadir las dependencias funcionales resultantes a F+ para cada par de dependencias funcionales f1y f2 en F+ si f1 y f2 se pueden combinar por transitividad entonces aadir la dependencia funcional resultante a F+ hasta que F+ no cambie

Bases de datos

34

Cierre de dependencias funcionales (Cont.)

n Podemos simplificar el clculo manual de F+ utilizando las

siguientes reglas adicionales.

H Si se da y se da, entonces se da (unin) H Si se da, entonces se da y se da (decomposicin) H Si se da y se da, entonces se da (pseudotransitividad)
Estas reglas (y otras) se pueden inferir de los axiomas de Armstrong.

Bases de datos

35

Cierre de un conjunto de atributos

n Dado un conjunto de atributos , definimos el cierre de bajo F

(denotado por +) como el conjunto de atributos funcionalmente determinados por bajo F: est en F+ + resultado := ; mientras (cambie resultado) hacer para cada en F hacer begin si resultado entonces resultado := resultado end

n Algoritmo para calcular +, el cierre de bajo F

Bases de datos

36

Ejemplo de cierre de un conjunto de atributos

n R = (A, B, C, G, H, I) n F = {A B

AC CG H CG I B H} n (AG)+
1. resultado = AG 2. resultado = ABCG 3. resultado = ABCGH 4. resultado = ABCGHI (A C y A B) (CG H y CG AGBC) (CG I y CG AGBCH)

n AG es una clave candidata?

1. AG es una superclave?
1. AG R? == (AG)+ R

2. Algn subconjunto de AG es una superclave?

1. A R? == (A)+ R 2. G R? == (G)+ R Bases de datos 37

Utilidad del cierre de atributos

Hay varias utilidades del algoritmo de cierre de atributos
n Comprobar una superclave:

H Para comprobar si es una superclave, calculamos +, y comprobamos si + contiene todos los atributos de R.
n Comprobar dependencias funcionales

H Para comprobar si una dependencia funcional se da (o, en otras palabras, est en F+), se comprueba si +. H Es decir, calculamos + utilizando el cierre de atributos, y entonces comprobamos si contiene . H Es una comprobacin simple y poco costosa, y muy til
n Clculo del cierre de F

H Para cada R, buscamos el cierre +, y para cada S +, generamos la dependencia funcional S.

Bases de datos

38

Cubricin cannica
n Un conjunto de dependencias funcionales puede tener

dependencias redundantes que se pueden inferir de las dems

H P.e.: A C es redundante en: {A B, B C, A C} H Partes de una dependencia funcional pueden ser redundantes
4 4

P.e. en RHS: {A B, B C, A CD} se puede simplificar a {A B, B C, A D} P.e. en LHS: {A B, B C, AC D} se puede simplificar a {A B, B C, A D}

n Intuitivamente, una cubricin cannica de F es un conjunto

mnimo de dependnecias funcionales equivalente a F, que no tenga dependnecias o partes de dependencias redundantes

Bases de datos

39

Atributos superfluos
n Dado un conjunto F de dependencias funcionales y la

dependencia funcional perteneciente a F

H El atributo A es superfluo en si A y F implica (F { }) {( A) }. H El atributo A es superfluo en si A y el conjunto de dependencias funcionales (F { }) { ( A)} implica F.

n Nota: la implicacin en la direccin opuesta es trivial en cada

uno de los casos anteriores, dado que una dependencia funcional ms fuerte siemple implica una ms dbil
n Ejemplo: Dado F = {A C, AB C } H B es superfluo en AB C ya que {A C, AB C} implica A C (es decir, eI resultado de eliminar B de AB C). n Ejemplo: Dado F = {A C, AB CD} H C es superfluo en AB CD dado que AB C se puede inferir an despus de eliminar C
Bases de datos 40

Comprobacin de atributos superfluos

n Dado un conjunto F de dependencias funcionales y la

dependencia funcional perteneciente a F

n Para comprobar si el atributo A es superfluo en

1. calculamos ({} A)+ utilizando las dependencias de F 2. comprobamos si ({} A)+ contiene a A; si es as, A es superfluo
n Para comprobar si el atributo A es superfluo en

1. Calculamos + utilizando solo las dependencias de F = (F { }) { ( A)}, 2. comprobamos si + contiene a A; si es as, A es superfluo

Bases de datos

41

Cubrimiento cannico
n Un cubrimiento cannico de F es un conjunto de dependencias Fc tal que

H F implica todas las dependencias de Fc, y H Fc implica todas las dependencias de F, y H Ninguna dependencia funcional de Fc contiene un atributo superfluo, y H Cada parte izquierda de dependencia funcional de Fc es nica.
n Para calcular el cubrimiento cannico de F:

repetir Aplicar la regla de la unin para reemplazar cualquier dependencia de F 1 1 y 1 1 por 1 1 2 Encontrar una dependencia funcional con un atributo superfluo o bien en o en Si se encuentra algn atributo superfluo, borrarlo de hasta que F no cambie
n Nota: La regla de la unin puede hacerse aplicable despus de eliminar

algunos atributos superfluos, por tanto tiene que ser re-aplicada

Bases de datos

42

Ejemplo de c lculo de un cubrimiento cannico

n R = (A, B, C)

F = {A BC BC AB AB C} n Combinamos A BC y A B en A BC H El conjunto resultante es {A BC, B C, AB C} n A es superfluo en AB C H Comprobamos si el resultado de eliminar A de AB C puede implicarse a partir
de otras dependencias
4 S: de hecho, B C ya est en el conjunto

H El conjunto resultante es {A BC, B C}

n C es superfluo en A BC

H Comprobamos si A C se implica de A B ylas otras dependencias

4 S: utilizando transitividad sobre A B y B C.

En casos ms complejos podemos utilizar el cierre de A n El cubrimiento cannico es:

Bases de datos

AB BC
43

Objetivos de la normalizacin
n Decidir cuando una determinada relacin R est en un estado

adecuado. n En el caso de que la relacin R no sea buena, descomponerla en un conjunto de relaciones {R1, R2, ..., R n} tales que
H Cada relacin est en estado adecuado H La descomposicin sea reversible por join
n Nuestra teora est basada en:

H Dependencias funcionales H Dependencias multivaluadas

Bases de datos

44

Descomposicin
n

Descompongamos el esquema de relacin Esquema-prestamo en: Esquema-sucursal = (nombre-sucursal, ciudad-sucursal, activos) Esquema-info-prestamo = (nombre-cliente, numero-cliente, nombre-sucursal, cantidad)

Todos los atributos del esquema original (R) deben aparecer en la descomposicin (R1, R2): R = R1 R2 Descomposicin reversible por join Para todas las posibles relaciones r en el esquema R r = R1 (r) R2 (r) Una descomposicin de R en R1 y R2 es reversible por join si y slo si al menos una de las siguientes dependencias funcionales est en F+: H R1 R2 R1 H R1 R2 R2

Bases de datos

45

Ejemplo de descomposicin no reversible por join

n n

Las descomposiciones no reversibles por join dan lugar a alteraciones de la informacin. Ejemplo: Descomposicin de R = (A, B) R1 = (A) R2 = (B)

A B r 1 2 1

A A(r) A B 1 2 1 2

B 1 2 B(r)

A (r)

B (r)

Bases de datos

46

Normalizacin utilizando dependencias funcionales

n Cuando descomponemos un esquema de relacin R

con un conjunto de dependencias funcionales F en R1, R2,.., Rn queremos:

H Descomposicin reversible por join: Si no la descomposicin puede suponer alteraciones de la informacin. H Sin redundancia. H Preservacin de dependencias: Dado Fi como el conjunto de dependencias F+ que incluya slo atributos de Ri.
4 4

La descomposicin debera preservar las dependencias, es decir, (F1 F2 Fn)+ = F+ Si no perdemos dependencias, que son restricciones introducudas en la fase de diseo para modelar adecuadamente la aplicacin. No es deseable.

Bases de datos

47

Ejemplo
n R = (A, B, C)

F = {A B, B C)
H Se puede descomponer de dos maneras diferentes

n R1 = (A, B), R2 = (B, C)

H Descomposicin reversible por join:

R1 R2 = {B} y B BC

H Preserva las dependencias

n R1 = (A, B), R2 = (A, C)

H Descomposicin reversible por join:

R1 R2 = {A} y A AB

H No preserva las dependencias (se pierde B C)

Bases de datos

48

Comprobacin de preservacin de dependencias

n Para comprobar si una dependencia se preserva en una

descomposicin de R en R1, R2, , Rn aplicamos la siguiente comprobacin simplificada (con el cierre de atributos realizado respecto a F)
H resultado = while (cambie resultado) do for each Ri en la descomposicin t = (resultado Ri)+ Ri resultado = resultado t H Si resultado contiene todos los atributos de , entonces se preserva la dependencia funcional .
n Debemos aplicar el test a todas las dependencias de F para

comprobar si la descomposicin preserva las dependencias

n Este procedimiento tiene una complejidad temporal polinomial,

frente a la complejidad exponencial de calcular F+ y (F1 F2 Fn)+

49

Bases de datos

Forma Normal de Boyce-Codd

Un esquema de relacin est en FNBC con respecto a un conjunto de dependencias funcionales F si para todas las dependencias funcionales de F+, , donde R y R, se cumple al menos una de las siguientes condiciones:
n n

es trivial (es decir, ) es una superclave de R

Bases de datos

50

Ejemplo
n R = (A, B, C)

F = {A B B C} Clave = {A}

n R no est en FNBC n Descomposicin R1 = (A, B), R2 = (B, C)

H R1 y R2 en FNBC H Reversible por join H Preserva las dependencias

Bases de datos

51

Comprobacin de la FNBC
n Para comprobar si una dependencia no trivial cumple la FNBC 1. calcular + (el cierre de atributos de ), y 2. verificar que incluye todos los atributos de R, es decir, es una superclave de R. n Comprobacin simplificada: Para comprobar si un esquema de relacin R

est en FNBC, es suficiente comprobar las dependencias del conjunto F, en vez de comprobar todas las dependencias de F+. H Si ninguna de las dependencias de F viola la FNBC, entonces ninguna de las
dependencias de F+ violar la FNBC. n Pero, es incorrecto utilizar slo F cuando se comprueba una relacin de

una descomposicin de R H P.e. Consideremos R (A, B, C, D), con F = { A B, B C}

4 Descomponemos R en R1(A,B) y R2(A,C,D) 4 Ninguna de las dependencias de F contiene slo atributos de

(A,C,D) por eso podramos cometer el error de pensar que R2 est en FNBC.
4 De hecho, la dependencia A C de F+ indica que R 2 no est en FNBC. Bases de datos 52

Algoritmo de descomposicin en FNBC

resultado := {R}; hecho := false; calcular F+; while (not hecho) do if (hay un esquema Ri en resultado que no est en FNBC) then begin dada una dependencia funcional no trivial que se da en Ri tal que Ri no est en F+, y = ; resultado := (resultado Ri ) (Ri ) (, ); end else hecho := true; Nota: cada Ri est en FNBC, y la descomposicin es sin prdidas.

Bases de datos

53

Ejemplo de descomposicin en FNBC

n R = (nombre-sucursal, ciudad-sucursal, activos,

nombre-cliente, numero-prestamo, cantidad) F = {nombre-sucursal activos ciudad-sucursal numero-prestamo cantidad nombre-sucursal} Clave = {numero-prestamo, nombre-cliente} n Decomposicin

H R1 = (nombre-sucursal, ciudad-sucursal, activos) H R2 = (nombre-sucursal, nombre-cliente, numero-prestamo, cantidad) H R3 = (nombre-sucursal, numero-prestamo, cantidad) H R4 = (nombre-cliente, numero-prestamo)
n Descomposicin final

R1, R3, R4
Bases de datos 54

Comprobacin de descomposicin en FNBC

n Para comprobar si una relacin Ri de una descomposicin de R est en

FNBC, H o bien comprobar si Ri est en FNBC con respecto a la restriccin de F a Ri

(es decir, todas las DFs de F+ que contienen slo atributos de Ri) siguiente comprobacin: para cada conjunto de atributos Ri, comprobar que + (el cierre de atributos de ) o bien no incluye ningn atributo de R i- , o incluye todos los atributos de Ri.
4 Si la condicin se viola por algn de F, la dependencia

H o utilizar el conjunto original de dependencias F que se dan en R, pero con la

( + - ) Ri se da en Ri, y Ri viola la FNBC.

4 Utilizaremos la dependencia anterior para descomponer Ri

Bases de datos

55

FNBC y preservacin de dependencias

No siempre es posible llegar a una descomposicin en FNBC que preserve las dependencias
n R = (J, K, L)

F = {JK L L K} Dos claves candidatas = JK y JL

n R no est en FNBC n Cualquier descomposicin de R no preserva

JK L

Bases de datos

56

Tercera Forma Normal: Motivacin

n Hay algunas situaciones en las que

H La FNBC no preserva las dependencias

n Solucin: definir una forma normal ms dbil, denominada Tercera

Forma Normal.
H Permite cierta redundancia (con los problemas consabidos) H Pero siempre existe una descomposicin a 3FN que es reversible por join y que preserva las dependencias:

Bases de datos

57

Tercera Forma Normal

n Un esquema de relacin R est en tercera forma normal (3FN) si

para todas las: de F+ se cumple am menos una de las siguientes condiciones:

H es trivial (es decir, ) H es una superclave de R

H Cada atributo A de est contenido en una clave candidata de R. (NOTA: cada atributo puede estar en una clave candidata diferente)
n Si una relacin est en FNBC entonces tambin est en 3FN

(dado que en FNBC se debe dar una de las dos primeras condiciones). n La tercera condicin es una relajacin mnima de la FNBC que asegura la preservacin de dependencias funcionales.

Bases de datos

58

3FN (Cont.)
n Ejemplo

H R = (J, K, L) F = {JK L, L K} H Dos claves candidatas: JK y JL H R est en 3FN

JK L LK JK es una superclave K est contenida en una clave candidata

n La descomposicin en FNBC da (JL) y (LK) n Se pierde JK L

n Hay cierta redundancia en este esquema

Bases de datos

59

Comprobacin de la 3FN
n Optimizacin: Slo es necesario comprobar las dependencias

funcionales de F, no todas las de F+.

n Utilizar el cierre de atributos para comprobar en cada

dependencia , si es una superclave.

n Si no es superclave, tenemos que verificar si cada atributo de

est contenido en una clave candidata de R

H Esta comprobacin es bastante ms costosa, dado que supone encontrar las claves candidatas H Se ha demostrado que comprobar la 3FN es NP-hard H Por suerte, descomponer a 3FN se puede hacer con una complejidad polinomial

Bases de datos

60

Algoritmo de descomposicin a 3FN

Dado el conjunto de dependencias funcionales F; i := 0; for each dependencia funcional de F do if ninguno de los esquemas Rj, 1 j i contiene then begin i := i + 1; Ri := end if ninguno de los esquemas Rj, 1 j i contiene una clave candidata de R then begin i := i + 1; Ri := cualquier clave candidata de R; end return (R1, R2, ..., Ri)

Bases de datos

61

Algoritmo de descomposicin a 3FN (Cont.)

n El algoritmo anterior asegura:

H que cada esquema de relacin Ri est en 3FN H La descomposicin es reversible por join y preserva las dependencias

Bases de datos

62

Ejemplo
n Esquema de relacin: Esquema-info-banquero = (nombre-sucursal, nombre-cliente, nombre-banquero, numero-despacho) n Las dependencias funcionales para este esquema de relacin

son:

nombre-banquero nombre-sucursal numero-despacho nombre-cliente nombre-oficina nombre-banquero {nombre-cliente, nombre-sucursal}

n La clave es:

Bases de datos

63

Aplicando 3FN a Esquema-info-banquero

n El bucle for del algoritmo hace que incluyamos los

siguientes esquemas en nuestra descomposicin: Esquema-despacho-banquero = (nombre-banquero, nombre-oficina, numero-despacho) Esquema-banquero = (nombre-cliente, nombre-sucursal, nombre-banquero)
n Dado que Esquema-banquero contiene una clave

candidata para Esquema-info-banquero, hemos terminado el proceso de descomposicin.

Bases de datos

64

Comparacin de FNBC y 3FN

n Siempre es posible descomponer una relacin en relaciones en

3FN y
H La descomposicin es reversible por join H Se preservan las dependencias
n Siempre es posible descomponer una relacin en relaciones en

FNBC y
H La descomposicin es reversible por join H Puede que no se preserven las dependencias

Bases de datos

65

Comparacin de FNBC y 3FN (Cont.)

n Ejemplo de problemas debidos a la redundancia en la 3FN

H R = (J, K, L) F = {JK L, L K}
J j1 j2 j3 null L l1 l1 l1 l2 K k1 k1 k1 k2

Un esquema que est en 3FN pero no en FNBC tiene problemas de n Repeticin de informacin (p.e., la asociacin l1, k1) n Necesidad de utilizar valores nulos (p.e., para representar la asociacin l2, k2 que no tiene valor para J).
Bases de datos 66

Objetivos de diseo
n El objetivo de un diseo de base de datos relacional es:

H FNBC. H Descomposicin reversible por join. H Preservacin de dependencias.

n Si no se puede conseguir, podemos aceptar

H o bien perder la preservacin de dependencias, H o bien la existencia de redundancia debida al uso de la 3FN (suele ser la
opcin preferible) n Sorprendentemente, SQL no proporciona un mecanismo directo de

especificar dependencias funcionales distintas de las superclaves. Se pueden especificar DFs como aseveraciones, pero son costosas de comprobar
n Aunque tengamos una descomposicin que preserve las dependencias,

utilizando SQL no podremos comprobar de manera eficiente una dependencia funcional cuya parte izquierda no sea una clave.
Bases de datos 67

Otras formas normales

n Existen otras formas normales que es deseable que

se den en una relacin: Cuarta Forma Normal (4FN), Quinta Forma Normal (5FN),
n La 3FN es la forma ideal en lo referente a

dependencias funcionales. Por qu existen entonces otras formas normales?

H Pues porque pueden existir otras dependencias en una base de datos adems de las dependencias funcionales, aunque estas ltimas son las ms habituales. H Las dependencias no funcionales ms habituales son las dependencias multivaluadas.

Bases de datos

68

Dependencias multivaluadas
n Dado un esquema de relacin R y dados R y R.

La dependencia multivaluada se da en R si en cualquier relacin posible r(R), para todos los pares de tuplas t1 y t2 de r tales que t1[] = t2 [], existen en r las tuplas t3 y t4 tales que: t1[] = t2 [] = t3 [] = t4 [] t3[] = t1 [] t3[R ] = t2[R ] t4 [] = t2[] t4[R ] = t1[R ]

Bases de datos

69

Dependencias multivaluadas (Cont.)

n Representacin grfica de

t1 t2 t3 t4

a a1 ai a1 ai a1 ai a1 ai

ai+1 aj bi+1 bj ai+1 aj bi+1 bj

R- a- aj+1 an bj+1 bn bj+1 bn aj+1 an

Bases de datos

70

Dependencias multivaluadas
n Definicin alternativa: H Dado un esquema de relacin R con un conjunto de atributos particionado en tres subconjuntos no vacos
Y, Z, W

H Decimos que Y Z (Y multidefine a Z) si y slo si para todas las relaciones posibles r(R) si
< y1, z1, w1 > r y < y2, z2, w2 > r entonces < y1, z1, w2 > r y < y2, z2, w1 > r
Bases de datos 71

Proceso global de diseo de bases de datos

n Hemos asumido que un esquema R viene dado por

H R puede haber sido generado por el paso de un diagrama E-A a un conjunto de relaciones. H R puede ser una nica relacin que contiene todos los atributos de inters (se denomina relacin universal). H La normalizacin divide R en relaciones ms pequeas. H R puede ser el resultado de algn otro proceso de diseo de relaciones, el cual comprobamos/convertimos a forma normal.

Bases de datos

72

El modelo E-A y la normalizacin

n Cuando un diagrama E-A se disea adecuadamente, identificando

todas las entidades correctamente, las relaciones generadas a partir del diagrama E-A no deberan necesitar normalizacin adicional. n No obstante, en un diseo real (imperfecto) puede haber dependencias funcionales desde atributos que no sean clave de una entidad hacia otros atributos de la entidad. n P.e. La entidad empleado con atributos numero-despacho y localizacion-despacho, y una dependencia funcional numero-despacho localizacin-despacho
H En un buen diseo se debera haber creado una entidad despacho
n Es posible encontrar dependencias funcionales desde atributos de un

conjunto asociacin que no sean clave, pero no es frecuente --- la mayora de los conjuntos asociacin son binarios

Bases de datos

73

Otros aspectos de diseo

n La normalizacin no se ocupa de algunos aspectos del diseo de bases

de datos. n Ejemplos de malos diseos de bases de datos que se deben evitar: En vez de beneficios(id-empresa, ao, cantidad), utilizar H beneficios-2000, beneficios-2001, beneficios-2002, etc., todos con el
esquema (id-empresa, beneficios).
4 Las relaciones anteriores estn en FNBC, pero hacer consultas que

afecten a varios aos es difcil y adems se necesita una tabla nueva para cada ao.

H empresa-ao(id-empresa, beneficios-2000, beneficios-2001,

beneficios-2002)
4 Tambin est en FNBC, pero tambin es difcil hacer consultas que

afecten a varios aos y necesita un atributo nuevo cada ao.

4 Es un ejemplo de una tabla cruzada, en la que los valores de un

atributo se utilizan como nombres de columnas.

4 Se utiliza sobre todo en hojas de clculo, y en herramientas de anlisis

de datos.

Bases de datos

74

Fin del tema 4

Bases de datos

Manuel Ramos Cabrer

75