Bases de Datos Avanzadas

1. Bases de Datos Avanzadas Eduardo Mena D.0.17, tutorías 13:00-15:00 (M, X, J) emena@posta.unizar.es http://www.cps.unizar.es/~mena/

2. Bloque asignaturas BDs • Asignaturas • Ficheros y BD (troncal) • Diseño de BD Relacionales (opt.) • BD Avanzadas (opt.) • Sistemas de Información (opt.) • Interacción Hombre-Máquina (opt.) • Problemas detectados • DBDR debería ser troncal • el diseño de BDs es fundamental para un informático • proyección laboral • Interacción Hombre-Máquina poco relacionada con BDs FBD DBDR IHM BDA SI

3. ¿Cómo enfocar el aprendizaje ? • Teoría de BD´s vs. Profundizar en un SGBD concreto • DISEÑO CONCEPTUAL --> Indpte. modelo y SGBD • DISEÑO LÓGICO --> Dpte. modelo e indpte. SGBD • DISEÑO FÍSICO --> Dpte. SGBD (+/- reglas generales) • Por supuesto: administración de BDs, etc. es dpte. SGBD • Los SGBD son caros y hay varios distintos. • Los alumnos esperan aprender ORACLE (o Access...): hay ofertas de trabajo que lo exigen. Similar a Programación en pseudocódigo vs. Lenguaje de programación concreto

4. Repetición / Relacióncon otras materias • Ficheros • son TADs: implementación de operaciones: funciones hash, índices (árboles B,...). Interesante estudiar la complejidad. • unidades mínimas de información en el SO. • Transacciones sobre BDs Progr. concurrente (excl. mut, sinc) • Diseño de BDs Ingeniería del Software • BDA LPOO + SO + Redes + IA + ... • SI  Redes + Web + IA + ...

5. BDA: Objetivos • SGBD relacionales  otras alternativas • Conocer las tendencias futuras (I+D) • Desarrollo de prototipos en entornos heterogéneos (y distribuidos) • Diseñar e implementar un sistema multibase de datos • Saber aplicar todos nuestros conocimientos a casos “reales”

6. BDA: Evaluación • 50%: Examen teórico-práctico (40%, 60%) • No hay que empollar • 50%: Práctica • Libertad de diseño • Heterogeneidad • Imaginación • Autosuficiencia • Hay que aprobar ambas pruebas

7. Optimización de Preguntas

8. Optimización de preguntas • Optimización: pregunta  plan costo ópt. costo = CPU + I/O + COMUNICACIONES • Necesario para responder eficientemente • Posible con lenguajes no procedurales (ej. SQL) • leng. no procedural: se dice qué se quiere obtener y no cómo obtenerlo (algoritmo, uso de índices...) • sistemas con lenguajes procedurales: ej. IMS (jerárquico) o CODASYL (en red)

9. Ejemplo motivador • La optimización es posible y necesaria • Las distintas estrategias requieren costes muy distinto • Debe ser un proceso automático • depende del momento concreto en la vida de la BD • es complicado saber qué estrategia es mejor • Nunca se esta seguro (estimaciones)

10. Etapas en la optimización • Convertir la pregunta en una representación interna (álgebra relacional, árbol sintáctico) • Transformar la pregunta en una forma canónica (reglas sintácticas y semánticas) • Escoger los procedimientos de bajo nivel candidatos (para cada operador) • ¿índices? ¿clustering? ¿rango y núm. valores? • Generar los planes y escoger el más barato • usar heurísticos para reducir búsqueda

11. Optimización sintáctica • Entrada: expresión álgebra relacional • Salida: expr. álgebra relacional equivalente • operaciones de idempotencia, propagar ctes. • operación selección se baja en el árbol • operación proyección se baja en el árbol • agrupar selecciones y proyecciones • Idea: reducir tamaño de las relaciones a combinar con la operación join

12. Optimización semántica • Transformar la pregunta en otra que devuelve las misma tuplas • Utilizar conocimiento semántico de la BD • restr. integridad, dependencias funcionales, claves extranjeras, reglas semánticas • En general, la opt. sem. es un proceso caro, por lo que los SGBD comerciales no la aplican. Se suele basar en técnicas de Int. Artificial.

13. Optimización física: Selección • Algoritmos • Búsqueda lineal • Búsqueda binaria • Empleo de índices (de distintos tipos) • Selectividad de una condición • % de la relación que satisface la condición • Ejecutar primero las selecciones de mayor selectividad

14. Optimización física: Join • Algoritmos • Ciclo anidado (Nested Loops) o fuerza bruta • Sort-Join (Sort Merge) • Join con índice en una de las relaciones • Join con índice para cada relación • Hash-Join

15. Optimización física: otras op. • Proyecciones: fácil de implementar (hay que recorrer todas las tuplas) • Producto cartesiano: muy costosa • Evitarla • Unión, Intersección, Diferencia • Primero se ordenan las dos relaciones

16. Generar los planes y escoger el más barato • Planes para responder a la pregunta, y su costo • Cada plan se construye combinando el conjunto de procedimientos candidatos posibles. • Calcular el costo es complicado  hay que estimar tamaños de resultados intermedios (estadísticas de la BD, en el catálogo). • Calcular el orden óptimo de ejecución de joins • N! posibilidades de ejecutar un join entre N relaciones • Evitar resultados intermedios (subir selecciones) • Usar heurísticos para reducir la búsqueda

17. Optimización del costo:CPU + I/O + COM • BD centralizadas • generalmente se tiene en cuenta sólo costo I/O • BD distribuidas en Redes Area Amplia (WAN) • generalmente, sólo costo COM. • BD distribuidas en Redes de Area Local (LAN) • generalmente, costos I/O y COM. • BD en servidores paralelos • influyen los tres: CPU, I/O y COM.

18. Optimización en Oracle • Optimización basada en reglas o basada en costes (seleccionado por el usuario) • EXPLAIN PLAN: ver como se ejecutará una sentencia SQL • No hay optimización semántica • hasta Oracle 8, incluido • Se puede influir en el uso o no de índices (no recomendado)

19. Conclusiones • Los SGBD realizan optimización de preguntas • son inútiles algunas reformulaciones de preguntas • Algunas optimizaciones (todavía) no son realizadas por los SGBD (ej. optimización semántica) • hay que reformular algunas preguntas • El proceso de optimización de preguntas es complejo y cada SGBD lo hace distinto. • hay que consultar el manual del SGBD concreto. • Es necesario conocer cómo se procesan las preguntas para realizar el DISEÑO FÍSICO. • cuándo es útil usar índices o hash o no utilizarlos. • saber que el join es costoso --> reducir número de joins.

21. Diseño Físico

22. Diseño Físico • El diseño físico de BD forma parte importante del ciclo de vida de un sistema de BDs. • Consiste en escoger las estructuras de almacenamiento y caminos de acceso que • 1) cumplan los objetivos del sistema • 2) proporcionen un balance óptimo entre el rendimiento (tiempos de respuesta de transacciones, número de transacciones por minuto...) y el costo (espacio utilizado, reorganizaciones de datos...). • No existen metodologías para realizar el diseño físico. Es muy dependiente del SGBD concreto.

23. Diseño Físico: Recopilar información. • Por cada op. (preg. SQL) con la BD indicar: • Tipo: INSERT, SELECT, UPDATE, DELETE • Tablas que se van a acceder (cardinalidad) • Condiciones de selección (selectividad de cada una) • Condiciones de combinación-join (selectividad) • Atributos a ser proyectados / modificados • Frecuencia esperada de que se realice la operación. • Restricciones importantes de ejecución (si las hay) • Regla 80-20: El 80% del procesamiento se realiza por el 20% de las transacciones.

24. Reconsiderar algunas de las claves utilizadas • Las claves escogidas deben asegurar que no haya elementos repetidos. • A veces se asignan códigos que toman valores numéricos sucesivos: 1,2,3,... • Problema: esto puede implicar realizar consultas con varios joins. • Si es posible hay que intentar usar claves con significado siempre que aseguren la unicidad.

25. Desnormalización • El proceso de normalización consiste en dividir una tabla R en R1 y R2 si R=R1 R1.K=R2.K R2 • Evita redundancia y anomalías (ins./bor./mod.) • Problema: Para obtener R hay que hacer el join • Si (casi) siempre que se recuperan los valores de R1 se utilizan también los de un mismo atributo(s) R2.Atr, entonces se puede añadir el atributo R2.Atr a la tabla R1 --> (No estaría en 3FN!!) • Hay que controlar que no haya anomalías • Habrá redundancia pero estará controlada • Se evitará ejecutar joins (según las frecuencias def.)

26. Particionamiento horizontal • Si existe tabla R = sC1(R) U ... U sCn(R) donde • muchas operaciones con la BD son con sCi (R) • algunos atributos son inaplicables (NULL) según Ci • entonces cada sCi (R) se guarda en una tabla y se define una vista sobre R (¿diseño lógico? ¿físico?) • En general si una operación sCi (R) es muy frecuente, con Ci muy selectivo y R muy grande: almacenar sCi (R) en una tabla S • hay que controlar la redundancia / integridad (triggers) • inconveniente: inserciones en S o R (ver frecuencias) • los programas deberán usar la nueva tabla S • si después se suprime tabla S --> crear vista para S • para mantener indep. física. Esto sí es diseño físico !!

27. Particionamiento vertical • Si existe una tabla R (A1,...An,B1,...Bm) donde • muchas de las operaciones afectan sólo a atributos A1,...,An y muy pocas veces a atributos B1,...Bm • esas operaciones son muy frecuentes • R(..Ai,...,Bj...) es mucho más grande que R(..Ai...) • Entonces almacenar R(...Ai...) en una tabla S • controlar redundancia / integridad. Fácil si hay mecanismo de triggers. Si no, controlar la parte de las aplicaciones que insertan / modifican R. • inconveniente: las inserciones en R(...Ai...). Hay que valorar su frecuencia para ver si merece la pena.

28. Precomputar joins en tablas • Si existe una consulta R1 R2 ... Rn que se ejecuta frecuentemente, cuyo coste es elevado (los joins son costosos) y donde cada relación Ri no se actualiza frecuentemente entonces se puede crear una tabla donde se almacene el resultado de dicha consulta. • Habrá que controlar recomputar dicha consulta • 1) Utilizando triggers cada vez que cambie algún Ri • o bien 2) Ejecutando periódicamente algunos scripts (ej. a las noches). Se puede si no es obligatorio que la consulta devuelva los valores más actuales. • Valorar: frecuencia de cambios en Ri, tamaño del resultado, tiempo de ejecución de la consulta inicial

29. Organización física para tablas • Si un atributo se usa a menudo para recuperar tuplas en orden o para hacer joins entonces se define como clave primaria o como índice cluster (si no puede ser clave). ¡¡Sólo UNO!! • algunos SGBD permiten almacenar tablas juntas (en un mismo cluster). Útil para ejecutar joins (alternativa a desnormalizar) • Si hay otros atributos que se usan en condiciones de selección o en joins entonces se definen como índices. • conveniente si se seleccionan pocas tuplas ( < 15% total tuplas) y si la cardinalidad de la tabla es alta ( > 100 tuplas) • Si la tabla se actualiza con gran frecuencia hay que definir un número mínimo de índices (coste de actual.) • Si un atributo se usa frecuentemente para selecciones del tipo A=c o en joins y no para recuperar por orden de A, entonces definirlo como hash (si SGBD permite)

30. Conclusiones • Realizar el diseño físico inicial • Obtener información de las operaciones esperadas • Resolver operaciones con mayores restricciones (aplicando algunos de los métodos explicados) • Resolver el resto de las opers. sin perjudicar a otras • añadir índices para favorecer consultas perjudica a operaciones de inserción / borrado • Replantearse continuamente dicho diseño (Tunning) • analizar/auditar el sistema actual • tomar nuevas decisiones (añadir/borrar índices o tablas (crear vistas y triggers si es necesario)

31. Transacciones, Recuperación y Control de Concurrencia

32. Transacciones • Transacción: colección de operaciones que forman una única unidad lógica de trabajo en una BD • Control concurrencia • Sistemas multiusuario: ejecución intercalada • Recuperación • Para cuando una transacción falla • Vida de una transacción • Inicio • Lecturas/escrituras de elementos de la BD • Final (pueden hacer falta algunas verificaciones) • Confirmación (COMMIT) o anular (ROLLBACK)

33. Transacciones • Toda transacción debe cumplir el principio ACID • Atómica: se ejecuta todo (commit) o nada (rollback) • Debe garantizarlo el método de recuperación del SGBD • Consistente: pasa de un estado consistente a otro • Debe garantizarlo el programador y el SGBD (restr. int.) • aIslada: no lee resultados intermedios de otras transacciones que no han terminado • Debe garantizarlo el método de control de concurrencia y el programador (ej: usando protocolo bloqueo en 2 fases). • Duradera: si se termina con éxito (commit), los cambios en la BD son estables aunque luego falle otra • Debe garantizarlo el método de recuperación.

34. Recuperación • Caídas del sistema durante una transacción • Errores de ejecución: overflow, división por 0... • Errores lógicos que violan alguna regla de integridad (definida explícitamente o no) y que dejan inconsistente la BD -> programador/ABD • Problemas de concurrencia de transacciones • Fallos de lectura/escritura en disco • Problemas físicos y catástrofes: fuego, robos, sabotajes, fallos “humanos”,... --> medidas de seguridad informática en la empresa.

35. Recuperación • Para que el sistema se pueda recuperar ante fallos se necesita grabar cada operación con la BD en un fichero LOG (bitácora). Checkpoints. • se escribe en el fichero LOG antes que en la BD • el fichero LOG debe estar en memoria estable • Por cada operación se escribe un reg. en LOG • <comienza-transacción, numt> • <escritura, numt, id_dato, val_viejo, val_nuevo> • <lectura, numt, id_dato, valor> • <termina_transacción_con_éxito, numt> • <punto_comprobación, numt, numc>

36. Problemas de concurrencia • La ejecución concurrente de transacciones puede dar lugar a problemas: • Problema de la actualización perdida • Problema de leer una actualización temporal (lectura sucia) • Problema del resumen incorrecto • Problema de la lectura no repetible

37. Problemas de Concurrencia • Sol. trivial: cada transacción se ejecuta en exclusión mutua. ¿Cuál sería la granularidad? ¿BD? ¿Tabla? ¿Tupla? ¿Atributo? • La solución trivial no es válida: muy restrictiva • Se supone que las BDs se pensaron para que varios usuarios/aplicaciones accedieran a la vez • Hay que intercalar acciones pero que el resultado sea como en exclusión mutua

38. Control de concurrencia: planes serializables • Dadas las transacciones T1, T2, ... Tn, • T1 compuesto por operaciones O11,O12,..O1 m1 • T2 compuesto por operaciones O21,O22,..O2 m2 • ... Tn compuesto por operaciones On1, On2..On mn • Un plan de ejecución concurrente de las transacciones sería: • Ej: O11, O21, On1, On2, O12, O22, …, O1 m1, O2 m2, …, On mn • Una intercalación de todas las operaciones Oij donde para todo i, Oi1 se ejecuta antes que Oi2 ... antes que Oi mi • Un plan es serializable si su resultado es el mismo que el producido por alguno de los posibles planes seriales de T1, T2,...Tn • Ej:opers. de T2, opers. T1, opers. Tn, ...., opers. de T3

39. Serializabilidad • Aparte de ACID, queremos que las transacciones sean serializables. • Determinar si un determinado plan es serializable es un problema NP-completo. • Solución: Imponer restricciones a la libre intercalación de operaciones entre transacciones • Técnicas pesimistas: se impide realizar ciertas operaciones si son sospechosas de producir planes no serializables: BLOQUEOS (lock) y MARCAS DE TIEMPO (time-stamping) • Técnicas optimistas: no imponen restricciones pero después se comprueba si ha habido interferencias

40. Técnicas de bloqueo (lock) • A cada elemento de datos o gránulo X de la BD se le asocia una variable • operación lock_exclusivo(X): deja bloqueado al que lo pide si otro ya tiene cualquier lock sobre X • operación lock_compartido(X): deja bloqueado al que lo pide si otro ya tiene un lock exclusivo sobre X • operación unlock(X): libera su lock sobre X • Antes de leer X  lock_compartido(X) • Antes de escribir (leer) X  lock_exclusivo(X) • Si no se va a leer o escribir más  unlock(X)

41. Protocolo deBloqueo en dos fases • Una transacción sigue el protocolo de bloqueo en dos fases si nunca hace un lock después de haber hecho algún unlock. • Fase de crecimiento: se solicitan locks • Fase de devolución: se realizan unlocks • Solamente este protocolo de bloqueo garantiza la serializabilidad de transacciones • Sin embargo, existe riesgo de deadlock !! • Prevención de deadlocks • Detección y recuperación de deadlocks

42. Deadlocks • Deadlock (o abrazo mortal o interbloqueo): cuando una transacción T1 está bloqueada esperando a que otra T2 libere un lock, la cual también está bloqueada esperando a que T1 libere uno de sus lock. Se puede generalizar para N transacciones. • Prevención de deadlocks • Cada transacción obtiene todos los locks al principio y si no puede entonces no obtiene ninguno. Problema de livelock(inanición de algunas transacciones que pueden no obtener todos los que necesiten) • Los elementos de la BD están ordenados de alguna manera y los lock hay que obtenerlos en dicho orden. Los programadores deben controlarlo !! • Detección y recuperación de deadlocks. • A medida que se piden y conceden los lock se construye un grafo de las transacciones que están esperando a otras. Si existe un ciclo en dicho grafo: deadlock. Hay que proceder a abortar a alguna de las transacciones. Problema de livelock si se aborta siempre a la misma!

43. Técnicas de marcas de tiempo (time-stamping) • Un timestamp es un identificador asignado a cada transacción TS(T). Indica la hora de comienzo de la transacción T. A cada elemento X de la BD se le asigna el timestamp de la última transacción que lo ha leído (TS_lect(X)) y escrito (TS_escr(X)) • Si una transacción T quiere escribir en X • si TS_lect(X) > TS(T) entonces abortar • si TS_escr(X) > TS(T) entonces no escribir y seguir • en otro caso escribir y TS_escr(X):=TS(T) • Una transacción T quiere leer de X • si TS_escr(X) > TS(T) entonces abortar • si TS_escr(X) <= TS(T) entonces leer de X y TS_lect(X):=máximo(TS(T),TS_lect(X)) • Garantiza serializabilidad y ausencia de deadlocks. Puede haber livelock (si se aborta siempre a la misma transacción)

44. Técnicas optimistas • No se realizan comprobaciones ANTES de ejecutar las operaciones (pedir locks, comprobar timestamps), sino al acabar toda la transacción (fase validación) • Durante la ejecución de la transacción se trabaja con copias • Hay tres fases en un protocolo optimista: • Fase de lectura • Fase de validación • Fase de escritura • Es bueno cuando no hay muchas interferencias entre transacciones (por eso son “optimistas”)

45. Recuperación en Oracle • Redo logs (cíclicos) • Archive logs (consolidación de redo logs) • Backups • Mirrors • Export: Incremental, acumulativo (colección de incrementales), total • Recuperación basada en cambios, tiempo, paso-a-paso (basado en archive logs), completa

46. Control de concurrencia en ORACLE (1) • Lectura consistente: garantiza que se lean los datos tal y como estaban al inicio de la transacción, sin impedir que otras transacciones los cambien. • Implícitamente con SELECT .. FROM T,R ... (lo garantiza sobre las tuplas de T,R,...) • Explícitamente con SET TRANSACTION READ ONLY; (lo garantiza sobre las tuplas de todas las tablas hasta el fin de transacción.) • Debe ser la primera instrucción de la transacción • No permitirá hacer ningún INSERT, DELETE o UPDATE en dicha transacción

47. Control de concurrencia en ORACLE (2) • LOCKs • Explícitamente con LOCK TABLE T IN x MODE • x indica si sobre todas/algunas tuplas de T en modo compartido/exclusivo) • Implícitamente con cada operación (según cláusula WHERE) • UPDATE, DELETE, INSERT. Se bloquean las tuplas insertadas, borradas o actualizadas (al ser una transacción no finalizada) • SELECT...FROM T FOR UPDATE OF atr. Se bloquean las tuplas seleccionadas

48. Control de concurrencia en ORACLE (y 3) • No hay UNLOCK explícitos en ORACLE!! • Se realiza un UNLOCK implícito de todos los LOCK con cada COMMIT o ROLLBACK (implícitos o explícitos) • Pregunta: ¿Cómo conseguir que las transacciones en ORACLE sigan el protocolo en dos fases, o lo que es lo mismo, sean serializables?

49. Interacción de Aplicaciones con BDs

50. Interacción de Aplicaciones con Bases de Datos • Acceso básico. Casos Especiales • SQL embebido • Uso de un API • Tipos de API • ODBC. Drivers • Bases de datos en la Web