Tema 4: Otros conceptos de diseño de bases de datos relacionales Aseveraciones Disparadores (triggers) Seguridad Autorización NORMALIZACIÓN Primera forma normal Problemas en el diseño lógico relacional Dependencias funcionales Descomposición Forma normal de Boyce-Codd Tercera forma normal Otras formas normales y dependencias multivaluadas Proceso global de diseño de bases de datos Aseveraciones Una aseveración es un predicado que expresa una condición que queremos que se cumpla siempre en la base de datos. Cuando se hace una aseveración, el sistema comprueba su validez, y la comprueba de nuevo en cada actualización que puede violar la aseveración Esta comprobación puede introducir una sobrecarga importante; por tanto las aseveraciones se deben utilizar con mucho cuidado. Aseverar para todo X, P(X) se consigue de manera indirecta con no existe X tal que no P(X) Bases de datos Bases de datos Ejemplo de aseveración Disparadores La suma de todos los préstamos 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))) Un disparador es una sentencia que se ejecuta automáticamente por el sistema como efecto lateral de una modificación de la base de datos. Para especificar un disparador debemos: Especificar las condiciones par a su ejecución. Especificar las acciones a realizar cuando se ejecuta. Los disparadores se introdujeron en el estándar SQL en SQL:999, pero eran soportados antes por la mayoría de los gestores de bases de datos mediante sintaxis no estándar. Bases de datos 3 Bases de datos 4 Ejemplo de disparador Supongamos que en vez de permitir saldos de cuenta negativos, el banco trata los descubiertos de la siguiente manera: poniendo el saldo de la cuenta a cero creando un préstamo por la cantidad del descubierto dando a ese préstamo un número de préstamo idéntico al número de cuenta de la cuenta al descubierto La condición para ejecutar el disparador será una actualización de la relación cuenta que dé lugar a un valor de saldo negativo. Ejemplo de disparador en SQL:999 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 5 Bases de datos 6
Eventos y acciones de disparadores en SQL Disparadores a nivel de sentencia Los eventos de disparo pueden ser: insertar, eliminar o actualizar Los disparadores sobre actualizaciones se pueden restringir a determinados atributos P.e. create trigger descubierto after update of saldo on cuenta Se pueden referenciar los valores anteriores y posteriores a una actualizació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 En vez de ejecutar una acción separada para cada fila afectada, se puede ejecutar una sola acción para todas las filas afectadas por una transacción Utilizar for each statement en vez de for each row Utilizar referencing old table o referencing new table para referirse a tablas temporales (llamadas tablas de transición) que contengan las filas afectadas Puede ser más eficiente cuando tratamos sentencias SQL que afectan a muchas filas Bases de datos 7 Bases de datos 8 Seguridad Seguridad (Cont.) Seguridad protección frenet a intentos maliciosos de robar o modificar datos. Nivel de sistema de bases de datos Mecanismos de autentificación y autorización permiten a determinados usuarios acceder sólo a los datos requeridos Nivel de sistema operativo Los superusuarios del sistema operativo pueden hacer cualquier cosa en las bases de datos! Se necesita una buena seguridad a nivel de sistema operativo. Nivel de red: debemos utilizar cifrado para prevenir Escuchas (lecturas no autorizadas de mensajes) Suplantaciones (pretender ser un usuario autorizado o enviar mensajes supuestamente de usuarios autorizados) Nivel físico El acceso físico a los servidores permite que los intrusos destruyan datos; se necesita seguridad física tradicional Las máquinas deben protegerse también contra líquidos, fuego, etc. Nivel humano Nos debemos asegurar de que los usuarios no den acceso a intrusos Uso adecuado de password Bases de datos 9 Bases de datos 0 Autorización Autorización (Cont.) Formas de autorización sobre partes de la base de datos: Autorización de lectura se permite leer, pero no modificar los datos. Autorización de inserción se permite introducir nuevos datos, pero no modificar los existentes. Autorización de actualización se permite modificar, pero no borrar datos. Autorización de eliminación se permite eliminar datos. Formas de autorización para modificar el esquema de la base de datos: Autorización de índexado se permite crear y eliminar índices. Autorización de recursos se permite crear nuevas relaciones. Autorización de alteración se permite añadir o eliminar atributos de una relación. Autorización de borrado se permite borrar relaciones. Bases de datos Bases de datos
Autorización y vistas Ejemplo de vista Los usuarios pueden obtener autorizaciones sobre vistas, sin tener ninguna autorización sobre las relaciones utilizadas en la definición de la vista La característica de las vistas de ocultar datos sirve tanto para simplificar el uso del sistema como para aumentar la seguridad permitiendo a los usuarios que sólo accedan a los datos que necesitan para su trabajo Se puede utilizar una combinación de seguridad a nivel relacional y seguridad a nivel de vista para limitar los accesos de los usuarios a los datos que necesitan. Supongamos que un cajero necesita conocer los nombres de los clientes de cada sucursal, pero no está autorizado para ver información específica sobre los créditos. Aproximación: Denegar el acceso directo a la relación 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 préstamo. 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 3 Bases de datos 4 Ejemplo de vista (Cont.) Autorización sobre vistas El cajero estará autorizado a ver el resultado de la consulta: select * from cliente-prestamo 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. Las autorizaciones se deben comprobar sobre la consulta del cajero antes de que el procesador de consultas reemplace una vista por la definición de la vista. La creación de vistas no requiere autorización de recursos dado que no se está creando ninguna relación real El creador de la vista obtiene solo aquellos privilegios que suponen que no exista autorización adicional sobre la que ya tenía. P.e. si el creador de la vista cliente-prestamo sólo tenía autorización de lectura sobre prestatario y prestamo, sólo obtiene autorización de lectura sobre cliente-prestamo Bases de datos 5 Bases de datos 6 Concesión de privilegios El paso de autorización de un usuario a otro se puede representar mediante un grafo de autorización. Los nodos del grafo representan usuarios. La raíz del grafo es el administrador de la base de datos. Consideremos el grafo para autorizaciones de actualización sobre prestamo. Una flecha U i U j indica que el usuario U i ha concedido autorización de actualización sobre prestamo a U j. U U 4 Grafo de concesión de privilegios Requisito: Todas las flechas de un grafo de autorización deben partir de un camino que tenga su origen en el administrador de bases de datos Si el DBA revoca el privilegio para U : Se debe revocar la concesión de U 4 dado que U ya no tiene autorización No se debe revocar la autorización de U 5 dado que U 5 tiene otro camino de autorización desde DBA a través de U Se deben prevenir ciclos de concesiones sin camino desde la raíz: DBA concede autorización a U 7 U 7 concede autorización a U 8 U 8 concede autorización a U 7 DBA U U 5 DBA revoca la autorización a U 7 Se debe revocar la concesión de U 7 a U 8 y de U 8 a U 7 dado que no queda ningún camino desde DBA a U 7 o a U 8. Bases de datos U 3 7 Bases de datos 8
Roles Los roles permiten especificar sólo una vez privilegios comunes a varios usuarios. Los privilegios se conceden o revocan a los roles igual que para usuarios individuales Los roles se pueden asignar a usuarios o a otros roles SQL:999 soporta roles create role cajero create role gestor NORMALIZACIÓN 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 9 Bases de datos Manuel Ramos Cabrer 0 Primera forma normal Problemas en el diseño lógico relacional Un dominio es atómico si sus elementos se pueden considerar unidades indivisibles Ejemplos de dominios no atómicos: Nombres, atributos compuestos Números de identificación como 30500789 que se pueden dividir en partes Un esquema relacional R esté en primera forma normal si los dominios de todos los atributos de R son atómicos Los valores no atómicos complican el almacenamiento y dan lugar a redundancia P.e. Conjunto de cuentas almacenado con cada cliente, y conjunto de propietarios almacenado con cada cuenta Vamos a asumir que todas las relaciones están en primera forma normal El diseño de bases de datos relacionales requiere encontrar un buen conjunto de esquemas de relación. Un mal diseño puede dar lugar a: Repetición de información (redundancia) Imposibilidad de representar cierta información. Objetivos de diseño: Evitar la redundancia Asegurar que se representan las asociaciones entre atributos Facilitar la comprobación de las violaciones de restricciones de integridad en las actualizaciones de las bases de datos. Bases de datos Bases de datos Ejemplo Consideremos el siguiente esquema de relación: Esquema-prestamo = (nombre-sucursal, ciudad-sucursal, activos, nombre-cliente, numero-prestamo, cantidad) ciudadsucursal nombresucursal nombrecliente activos numeroprestamo cantidad Vigo Vigo 9000000 Sánchez L-7 000 Santiago Santiago 00000 Gómez L-3 000 Madrid- Madrid 700000 López L-5 500 Vigo Vigo 9000000 Veiga L-4 500 Redundancia: Los datos de nombre-sucursal, ciudad-sucursal, activos se repiten para cada préstamo que hace una sucursal Gasto de espacio Se complica la actualización, introduciendo la posibilidad de inconsistencias Valores nulos: No se puede almacenar información sobre una sucursal si no existen préstamos Se pueden utilizar valores nulos, pero son difíciles de gestionar. Bases de datos 3 Descomposición Descompongamos el esquema de relación 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 descomposición (R, R ): R = R R Descomposición reversible por join Para todas las posibles relaciones r en el esquema R r = R (r) R (r) Bases de datos 4
Ejemplo de descomposición no reversible por join Objetivo Una teoría para: Descomposición de R = (A, B) R = (A) R = (B) A (r) A r B (r) B A A (r) A B Bases de datos 5 B B(r) Decidir cuando una determinada relación R está en un estado adecuado. En el caso de que la relación R no sea buena, descomponerla en un conjunto de relaciones {R, R,..., R n } tales que Cada relación esté en estado adecuado La descomposición sea reversible por join Nuestra teoría está basada en: Dependencias funcionales Dependencias multivaluadas Bases de datos 6 Dependencias funcionales Dependencias funcionales (Cont.) Restricciones sobre el conjunto de relaciones permitidas en un conjunto relación. Introducen como restricción que el valor de un conjunto determinado de atributos determina de manera única el valor de otro conjunto de atributos. El concepto de dependencia funcional es una generalización del concepto de clave. Dado un esquema de relación R R y R La dependencia funcional se da en R si y solo si para cualquier relación legal r(r), cuando dos tuplas cualquiera t yt de r coinciden en los valores de los atributos, entonces también coinciden en lso valores de los atributos. Es decir, t [] = t [] t [ ] = t [ ] Ejemplo: Consideremos r(a,b) con la siguiente instancia de r. 4 5 3 7 En esta instancia, A B NO se da, pero B A si. Bases de datos 7 Bases de datos 8 Dependencias funcionales (Cont.) Uso de Dependencias Funcionales K es una superclave del esquema de relación R si y solo si K R K es una clave candidata de R si y solo si K R, y Para ningún K, R 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 9 Utilizamos dependencias funcionales para:: Comprobar las relaciones para ver si son legales bajo un conjunto dado de dependencias funcionales. Si una relación r es legal bajo un conjunto F de dependencias funcionales, decimos que r satisface F. Especificar restricciones sobre un conjunto de relaciones legales Decimos que F se da en R si todas las relaciones legales sobre R satisfacen el conjunto de dependencias funcionales F. Nota: Una instancia específica de un esquema de relación puede satisfacer una dependencia funcional aun cuando la dependencia funcional no se dé en todas las instancias legales. Por ejemplo, una instancia específica de Esquema-prestamo puede, por tanto, satisfacer numero-prestamo nombre-cliente. Bases de datos 30
Dependencias funcionales (Cont.) Una dependencia funcional es trivial si se satisface para todas las instancias de una relación P.e. nombre-cliente, numero-prestamo nombre-cliente nombre-cliente nombre-cliente En general, es trivial si Cierre de un conjunto de dependencias funcionales Dado un conjunto F de dependencias funcionales, hay otras dependencias funcionales que se pueden inferir de F. P.e. Si A B y B C, entonces podemos inferir que A C El conjunto de todas las dependencias funcionales que se pueden inferir de F forman el cierre de F. Denotaremos el cierre de F por F +. Podemos calcular F + aplicando los Axiomas de Armstrong: si, entonces si, entonces γ γ (reflexividad) (aumentación) si, y γ, entonces γ (transitividad) Estas reglas son consistentes (generan solo dependencias funcionales que se dan) y completas (generan todas las dependencias funcionales que se dan) Bases de datos 3 Bases de datos 3 R = (A, B, C, G, H, I) F = { A B A C CG H CG I B H} Algunos miembros de F + A H Ejemplo Por transitividad de A B y B H AG I por aumentación de A C con G, que da AG CG y después por transitividad con CG I CG HI de CG H y CG I : la regla de la unión se puede inferir de La definición de dependencia funcional, o Por aumentación de CG I para inferir CG CGI, aumentación de CG H para inferir CGI HI, y entonces transitividad Bases de datos 33 Procedimiento de cálculo de F + 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 aumentación a f añadir las dependencias funcionales resultantes a F + para cada par de dependencias funcionales f y f en F + si f y f se pueden combinar por transitividad entonces añadir la dependencia funcional resultante a F + hasta que F + no cambie Bases de datos 34 Cierre de dependencias funcionales (Cont.) Podemos simplificar el cálculo manual de F + utilizando las siguientes reglas adicionales. Si se da y γse da, entonces γ se da (unión) Si γ se da, entonces se da y γse da (decomposición) Si se da y γ δ se da, entonces γ δse da (pseudotransitividad) Estas reglas (y otras) se pueden inferir de los axiomas de Armstrong. Cierre de un conjunto de atributos 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 + + Algoritmo para calcular +, el cierre de bajo F resultado := ; mientras (cambie resultado) hacer para cada γen F hacer begin si resultado entonces resultado := resultado γ end Bases de datos 35 Bases de datos 36
Ejemplo de cierre de un conjunto de atributos R = (A, B, C, G, H, I) F = {A B A C CG H CG I B H} (AG) +. resultado = AG. resultado = ABCG (A C y A B) 3. resultado = ABCGH (CG H y CG AGBC) 4. resultado = ABCGHI (CG I y CG AGBCH) AG es una clave candidata?. AG es una superclave?. AG R? == (AG) + R. Algún subconjunto de AG es una superclave?. A R? == (A) + R. G R? == (G) + R Bases de datos 37 Utilidad del cierre de atributos Hay varias utilidades del algoritmo de cierre de atributos Comprobar una superclave: Para comprobar si es una superclave, calculamos +, y comprobamos si + contiene todos los atributos de R. Comprobar dependencias funcionales Para comprobar si una dependencia funcional se da (o, en otras palabras, está en F + ), se comprueba si +. Es decir, calculamos + utilizando el cierre de atributos, y entonces comprobamos si contiene. Es una comprobación simple y poco costosa, y muy útil Cálculo del cierre de F Para cada γ R, buscamos el cierre γ +, y para cada S γ +, generamos la dependencia funcional γ S. Bases de datos 38 Objetivos de la normalización Decidir cuando una determinada relación R está en un estado adecuado. En el caso de que la relación R no sea buena, descomponerla en un conjunto de relaciones {R, R,..., R n } tales que Cada relación esté en estado adecuado La descomposición sea reversible por join Nuestra teoría está basada en: Dependencias funcionales Dependencias multivaluadas Descomposición Descompongamos el esquema de relación 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 descomposición (R, R ): R = R R Descomposición reversible por join Para todas las posibles relaciones r en el esquema R r = R (r) R (r) Una descomposición de R en R y R es reversible por join si y sólo si al menos una de las siguientes dependencias funcionales está en F + : R R R R R R Bases de datos 44 Bases de datos 45 Ejemplo de descomposición no reversible por join Las descomposiciones no reversibles por join dan lugar a alteraciones de la información. Ejemplo: Descomposición de R = (A, B) R = (A) R = (B) A (r) A r B (r) B A A (r) A B Bases de datos 46 B B(r) Normalización utilizando dependencias funcionales Cuando descomponemos un esquema de relación R con un conjunto de dependencias funcionales F en R, R,.., R n queremos: Descomposición reversible por join: Si no la descomposición puede suponer alteraciones de la información. Sin redundancia. Preservación de dependencias: Dado F i como el conjunto de dependencias F + que incluya sólo atributos de R i. La descomposición debería preservar las dependencias, es decir, (F F F n ) + = F + Si no perdemos dependencias, que son restricciones introducudas en la fase de diseño para modelar adecuadamente la aplicación. No es deseable. Bases de datos 47
R = (A, B, C) F = {A B, B C) Ejemplo Se puede descomponer de dos maneras diferentes R = (A, B), R = (B, C) Descomposición reversible por join: R R = {B} y B BC Preserva las dependencias R = (A, B), R = (A, C) Descomposición reversible por join: R R = {A} y A AB No preserva las dependencias (se pierde B C) Bases de datos 48 Comprobación de preservación de dependencias Para comprobar si una dependencia se preserva en una descomposición de R en R, R,, R n aplicamos la siguiente comprobación simplificada (con el cierre de atributos realizado respecto a F) resultado = while (cambie resultado) do for each R i en la descomposición t = (resultado R i ) + R i resultado = resultado t Si resultado contiene todos los atributos de, entonces se preserva la dependencia funcional. Debemos aplicar el test a todas las dependencias de F para comprobar si la descomposición preserva las dependencias Este procedimiento tiene una complejidad temporal polinomial, frente a la complejidad exponencial de calcular F + y (F F F n ) + Bases de datos 49 Forma Normal de Boyce-Codd Ejemplo Un esquema de relación 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: es trivial (es decir, ) es una superclave de R R = (A, B, C) F = {A B B C} Clave = {A} R no está en FNBC Descomposición R = (A, B), R = (B, C) R y R en FNBC Reversible por join Preserva las dependencias Bases de datos 50 Bases de datos 5 Comprobación de la FNBC Algoritmo de descomposición en FNBC Para comprobar si una dependencia no trivial cumple la FNBC. calcular + (el cierre de atributos de ), y. verificar que incluye todos los atributos de R, es decir, es una superclave de R. Comprobación simplificada: Para comprobar si un esquema de relación R está en FNBC, es suficiente comprobar las dependencias del conjunto F, en vez de comprobar todas las dependencias de F +. Si ninguna de las dependencias de F viola la FNBC, entonces ninguna de las dependencias de F + violará la FNBC. Pero, es incorrecto utilizar sólo F cuando se comprueba una relación de una descomposición de R P.e. Consideremos R (A, B, C, D), con F = { A B, B C} Descomponemos R en R (A,B) y R (A,C,D) Ninguna de las dependencias de F contiene sólo atributos de (A,C,D) por eso podríamos cometer el error de pensar que R está en FNBC. De hecho, la dependencia A C de F + indica que R no está en FNBC. Bases de datos 5 resultado := {R}; hecho := false; calcular F + ; while (not hecho) do if (hay un esquema R i en resultado que no está en FNBC) then begin dada una dependencia funcional no trivial que se da en R i tal que R i no está en F +, y = ; resultado := (resultado R i ) (R i ) (, ); end else hecho := true; Nota: cada R i está en FNBC, y la descomposición es sin pérdidas. Bases de datos 53
Ejemplo de descomposición en FNBC Comprobación de descomposición en FNBC 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} Decomposición R = (nombre-sucursal, ciudad-sucursal, activos) R = (nombre-sucursal, nombre-cliente, numero-prestamo, cantidad) R 3 = (nombre-sucursal, numero-prestamo, cantidad) R 4 = (nombre-cliente, numero-prestamo) Descomposición final R, R 3, R 4 Para comprobar si una relación R i de una descomposición de R está en FNBC, o bien comprobar si R i está en FNBC con respecto a la restricción de F a R i (es decir, todas las DFs de F + que contienen sólo atributos de R i ) o utilizar el conjunto original de dependencias F que se dan en R, pero con la siguiente comprobación: para cada conjunto de atributos R i, comprobar que + (el cierre de atributos de ) o bien no incluye ningún atributo de R i -, o incluye todos los atributos de R i. Si la condición se viola por algún de F, la dependencia ( + - ) R i se da en R i, y R i viola la FNBC. Utilizaremos la dependencia anterior para descomponer R i Bases de datos 54 Bases de datos 55 FNBC y preservación de dependencias Tercera Forma Normal: Motivación No siempre es posible llegar a una descomposición en FNBC que preserve las dependencias R = (J, K, L) F = {JK L L K} Dos claves candidatas = JK y JL R no está en FNBC Cualquier descomposición de R no preserva Hay algunas situaciones en las que La FNBC no preserva las dependencias Solución: definir una forma normal más débil, denominada Tercera Forma Normal. Permite cierta redundancia (con los problemas consabidos) Pero siempre existe una descomposición a 3FN que es reversible por join y que preserva las dependencias: JK L Bases de datos 56 Bases de datos 57 Tercera Forma Normal 3FN (Cont.) Un esquema de relación R está en tercera forma normal (3FN) si para todas las: de F + se cumple am menos una de las siguientes condiciones: es trivial (es decir, ) es una superclave de R Cada atributo A de está contenido en una clave candidata de R. (NOTA: cada atributo puede estar en una clave candidata diferente) Si una relación está en FNBC entonces también está en 3FN (dado que en FNBC se debe dar una de las dos primeras condiciones). La tercera condición es una relajación mínima de la FNBC que asegura la preservación de dependencias funcionales. Ejemplo R = (J, K, L) F = {JK L, L K} Dos claves candidatas: JK y JL R está en 3FN JK L L K JK es una superclave K está contenida en una clave candidata La descomposición en FNBC da (JL) y (LK) Se pierde JK L Hay cierta redundancia en este esquema Bases de datos 58 Bases de datos 59
Comprobación de la 3FN Optimización: Sólo es necesario comprobar las dependencias funcionales de F, no todas las de F +. Utilizar el cierre de atributos para comprobar en cada dependencia, si es una superclave. Si no es superclave, tenemos que verificar si cada atributo de está contenido en una clave candidata de R Esta comprobación es bastante más costosa, dado que supone encontrar las claves candidatas Se ha demostrado que comprobar la 3FN es NP-hard Por suerte, descomponer a 3FN se puede hacer con una complejidad polinomial Algoritmo de descomposición a 3FN Dado el conjunto de dependencias funcionales F; i := 0; for each dependencia funcional de F do if ninguno de los esquemas R j, j i contiene then begin i := i + ; R i := end if ninguno de los esquemas R j, j i contiene una clave candidata de R then begin i := i + ; R i := cualquier clave candidata de R; end return (R, R,..., R i ) Bases de datos 60 Bases de datos 6 Algoritmo de descomposición a 3FN (Cont.) Ejemplo El algoritmo anterior asegura: que cada esquema de relación R i está en 3FN La descomposición es reversible por join y preserva las dependencias Esquema de relación: Esquema-info-banquero = (nombre-sucursal, nombre-cliente, nombre-banquero, numero-despacho) Las dependencias funcionales para este esquema de relación son: nombre-banquero nombre-sucursal numero-despacho nombre-cliente nombre-oficina nombre-banquero La clave es: {nombre-cliente, nombre-sucursal} Bases de datos 6 Bases de datos 63 Aplicando 3FN a Esquema-info info-banquero Comparación de FNBC y 3FN El bucle for del algoritmo hace que incluyamos los siguientes esquemas en nuestra descomposición: Esquema-despacho-banquero = (nombre-banquero, nombre-oficina, numero-despacho) Esquema-banquero = (nombre-cliente, nombre-sucursal, nombre-banquero) Dado que Esquema-banquero contiene una clave candidata para Esquema-info-banquero, hemos terminado el proceso de descomposición. Siempre es posible descomponer una relación en relaciones en 3FN y La descomposición es reversible por join Se preservan las dependencias Siempre es posible descomponer una relación en relaciones en FNBC y La descomposición es reversible por join Puede que no se preserven las dependencias Bases de datos 64 Bases de datos 65
Comparación de FNBC y 3FN (Cont.) Objetivos de diseño Ejemplo de problemas debidos a la redundancia en la 3FN R = (J, K, L) F = {JK L, L K} J j j j 3 null L l l l l K k k k k Un esquema que está en 3FN pero no en FNBC tiene problemas de Repetición de información (p.e., la asociación l, k ) Necesidad de utilizar valores nulos (p.e., para representar la asociación l, k que no tiene valor para J). Bases de datos 66 El objetivo de un diseño de base de datos relacional es: FNBC. Descomposición reversible por join. Preservación de dependencias. Si no se puede conseguir, podemos aceptar o bien perder la preservación de dependencias, o bien la existencia de redundancia debida al uso de la 3FN (suele ser la opción preferible) 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 Aunque tengamos una descomposición 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 Dependencias multivaluadas Existen otras formas normales que es deseable que se den en una relación: Cuarta Forma Normal (4FN), Quinta Forma Normal (5FN), La 3FN es la forma ideal en lo referente a dependencias funcionales. Por qué existen entonces otras formas normales? Pues porque pueden existir otras dependencias en una base de datos además de las dependencias funcionales, aunque estas últimas son las más habituales. Las dependencias no funcionales más habituales son las dependencias multivaluadas. Dado un esquema de relación R y dados R y R. La dependencia multivaluada se da en R si en cualquier relación posible r(r), para todos los pares de tuplas t y t de r tales que t [] = t [], existen en r las tuplas t 3 y t 4 tales que: t [] = t [] = t 3 [] = t 4 [] t 3 [] = t [] t 3 [R ] = t [R ] t 4 [] = t [] t 4 [R ] = t [R ] Bases de datos 68 Bases de datos 69 Dependencias multivaluadas (Cont.) Dependencias multivaluadas Representación gráfica de t t t 3 t 4 a a i a i+ a j a a i b i+ b j a a i a i+ a j a a i b i+ b j R- - a j+ a n b j+ b n b j+ b n a j+ a n Definición alternativa: Dado un esquema de relación R con un conjunto de atributos particionado en tres subconjuntos no vacíos Y, Z, W Decimos que Y Z (Y multidefine a Z) si y sólo si para todas las relaciones posibles r(r) si < y, z, w > r y < y, z, w > r entonces < y, z, w > r y < y, z, w > r Bases de datos 70 Bases de datos 7
Proceso global de diseño de bases de datos El modelo E-A E A y la normalización Hemos asumido que un esquema R viene dado por R puede haber sido generado por el paso de un diagrama E-A a un conjunto de relaciones. R puede ser una única relación que contiene todos los atributos de interés (se denomina relación universal). La normalización divide R en relaciones más pequeñas. R puede ser el resultado de algún otro proceso de diseño de relaciones, el cual comprobamos/convertimos a forma normal. Cuando un diagrama E-A se diseña adecuadamente, identificando todas las entidades correctamente, las relaciones generadas a partir del diagrama E-A no deberían necesitar normalización adicional. No obstante, en un diseño real (imperfecto) puede haber dependencias funcionales desde atributos que no sean clave de una entidad hacia otros atributos de la entidad. P.e. La entidad empleado con atributos numero-despacho y localizacion-despacho, y una dependencia funcional numero-despacho localización-despacho En un buen diseño se debería haber creado una entidad despacho Es posible encontrar dependencias funcionales desde atributos de un conjunto asociación que no sean clave, pero no es frecuente --- la mayoría de los conjuntos asociación son binarios Bases de datos 7 Bases de datos 73 Otros aspectos de diseño La normalización no se ocupa de algunos aspectos del diseño de bases de datos. Ejemplos de malos diseños de bases de datos que se deben evitar: En vez de beneficios(id-empresa, año, cantidad), utilizar beneficios-000, beneficios-00, beneficios-00, etc., todos con el esquema (id-empresa, beneficios). Las relaciones anteriores están en FNBC, pero hacer consultas que afecten a varios años es difícil y además se necesita una tabla nueva para cada año. empresa-año(id-empresa, beneficios-000, beneficios-00, beneficios-00) También está en FNBC, pero también es difícil hacer consultas que afecten a varios años y necesita un atributo nuevo cada año. Es un ejemplo de una tabla cruzada, en la que los valores de un atributo se utilizan como nombres de columnas. Se utiliza sobre todo en hojas de cálculo, y en herramientas de análisis de datos. Fin del tema 4 Bases de datos 74 Bases de datos Manuel Ramos Cabrer 75