1 / 137

Bases de Datos Avanzadas

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/. Bloque asignaturas BDs. Asignaturas Ficheros y BD (troncal) Diseño de BD Relacionales (opt.) BD Avanzadas (opt.) Sistemas de Información (opt.)

Gabriel
Télécharger la présentation

Bases de Datos Avanzadas

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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.

  20. Diseño Físico

  21. 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.

  22. 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.

  23. 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.

  24. 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.)

  25. 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 !!

  26. 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.

  27. 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

  28. 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)

  29. 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)

  30. Transacciones, Recuperación y Control de Concurrencia

  31. 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)

  32. 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.

  33. 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.

  34. 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>

  35. 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

  36. 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

  37. 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

  38. 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

  39. 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)

  40. 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

  41. 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!

  42. 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)

  43. 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”)

  44. 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

  45. 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

  46. 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

  47. 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?

  48. Interacción de Aplicaciones con BDs

  49. 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

More Related