La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Bases de Datos Avanzadas Eduardo Mena D.0.17, tutorías 13:00-15:00 (M, X, J)

Presentaciones similares


Presentación del tema: "Bases de Datos Avanzadas Eduardo Mena D.0.17, tutorías 13:00-15:00 (M, X, J)"— Transcripción de la presentación:

1 Bases de Datos Avanzadas Eduardo Mena D.0.17, tutorías 13:00-15:00 (M, X, J)

2 Bloque asignaturas BDs yAsignaturas xFicheros y BD (troncal) xDiseño de BD Relacionales (opt.) xBD Avanzadas (opt.) xSistemas de Información (opt.) xInteracción Hombre-Máquina (opt.) yProblemas detectados xDBDR debería ser troncal el diseño de BDs es fundamental para un informático proyección laboral xInteracción Hombre-Máquina poco relacionada con BDs FBD DBDR BDASI IHM

3 ¿Cómo enfocar el aprendizaje ? yTeorí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ón con otras materias yFicheros xson TADs: implementación de operaciones: funciones hash, índices (árboles B,...). Interesante estudiar la complejidad. xunidades mínimas de información en el SO. yTransacciones sobre BDs Progr. concurrente (excl. mut, sinc) yDiseño de BDs Ingeniería del Software yBDA LPOO + SO + Redes + IA +... ySI Redes + Web + IA +...

5 BDA: Objetivos zSGBD relacionales otras alternativas zConocer las tendencias futuras (I+D) zDesarrollo de prototipos en entornos heterogéneos (y distribuidos) zDiseñar e implementar un sistema multibase de datos zSaber aplicar todos nuestros conocimientos a casos reales

6 BDA: Evaluación z50%: Examen teórico-práctico (40%, 60%) yNo hay que empollar z50%: Práctica yLibertad de diseño yHeterogeneidad yImaginación yAutosuficiencia zHay que aprobar ambas pruebas

7 Optimización de Preguntas

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

9 Ejemplo motivador zLa optimización es posible y necesaria zLas distintas estrategias requieren costes muy distinto zDebe ser un proceso automático ydepende del momento concreto en la vida de la BD yes complicado saber qué estrategia es mejor yNunca se esta seguro (estimaciones)

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

11 Optimización sintáctica zEntrada: expresión álgebra relacional zSalida: expr. álgebra relacional equivalente yoperaciones de idempotencia, propagar ctes. yoperación selección se baja en el árbol yoperación proyección se baja en el árbol yagrupar selecciones y proyecciones yIdea: reducir tamaño de las relaciones a combinar con la operación join

12 Optimización semántica zTransformar la pregunta en otra que devuelve las misma tuplas zUtilizar conocimiento semántico de la BD yrestr. integridad, dependencias funcionales, claves extranjeras, reglas semánticas z 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 zAlgoritmos yBúsqueda lineal yBúsqueda binaria yEmpleo de índices (de distintos tipos) zSelectividad de una condición y% de la relación que satisface la condición yEjecutar primero las selecciones de mayor selectividad

14 Optimización física: Join zAlgoritmos yCiclo anidado (Nested Loops) o fuerza bruta ySort-Join (Sort Merge) yJoin con índice en una de las relaciones yJoin con índice para cada relación yHash-Join

15 Optimización física: otras op. zProyecciones: fácil de implementar (hay que recorrer todas las tuplas) zProducto cartesiano: muy costosa yEvitarla zUnión, Intersección, Diferencia yPrimero se ordenan las dos relaciones

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

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

18 Optimización en Oracle zOptimización basada en reglas o basada en costes (seleccionado por el usuario) zEXPLAIN PLAN: ver como se ejecutará una sentencia SQL zNo hay optimización semántica yhasta Oracle 8, incluido zSe puede influir en el uso o no de índices (no recomendado)

19 Conclusiones yLos SGBD realizan optimización de preguntas son inútiles algunas reformulaciones de preguntas yAlgunas optimizaciones (todavía) no son realizadas por los SGBD (ej. optimización semántica) hay que reformular algunas preguntas yEl proceso de optimización de preguntas es complejo y cada SGBD lo hace distinto. hay que consultar el manual del SGBD concreto. yEs 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

21 Diseño Físico

22 yEl diseño físico de BD forma parte importante del ciclo de vida de un sistema de BDs. yConsiste en escoger las estructuras de almacenamiento y caminos de acceso que x1) cumplan los objetivos del sistema x2) 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...). yNo existen metodologías para realizar el diseño físico. Es muy dependiente del SGBD concreto.

23 Diseño Físico: Recopilar información. zPor cada op. (preg. SQL) con la BD indicar: xTipo: INSERT, SELECT, UPDATE, DELETE xTablas que se van a acceder (cardinalidad) xCondiciones de selección (selectividad de cada una) xCondiciones de combinación-join (selectividad) xAtributos a ser proyectados / modificados xFrecuencia esperada de que se realice la operación. xRestricciones importantes de ejecución (si las hay) zRegla 80-20: El 80% del procesamiento se realiza por el 20% de las transacciones.

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

25 Desnormalización yEl proceso de normalización consiste en dividir una tabla R en R1 y R2 si R=R1 R1.K=R2.K R2 xEvita redundancia y anomalías (ins./bor./mod.) xProblema: Para obtener R hay que hacer el join ySi (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!!) xHay que controlar que no haya anomalías xHabrá redundancia pero estará controlada xSe evitará ejecutar joins (según las frecuencias def.)

26 Particionamiento horizontal Si existe tabla R = C1 (R) U... U Cn (R) donde muchas operaciones con la BD son con Ci (R) algunos atributos son inaplicables (NULL) según Ci entonces cada Ci (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 Ci (R) es muy frecuente, con Ci muy selectivo y R muy grande: almacenar Ci (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 ySi existe una tabla R (A1,...An,B1,...Bm) donde xmuchas de las operaciones afectan sólo a atributos A1,...,An y muy pocas veces a atributos B1,...Bm xesas operaciones son muy frecuentes xR(..Ai,...,Bj...) es mucho más grande que R(..Ai...) yEntonces almacenar R(...Ai...) en una tabla S xcontrolar redundancia / integridad. Fácil si hay mecanismo de triggers. Si no, controlar la parte de las aplicaciones que insertan / modifican R. xinconveniente: las inserciones en R(...Ai...). Hay que valorar su frecuencia para ver si merece la pena.

28 Precomputar joins en tablas ySi 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. xHabrá 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. xValorar: frecuencia de cambios en Ri, tamaño del resultado, tiempo de ejecución de la consulta inicial

29 Organización física para tablas zSi 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!! yalgunos SGBD permiten almacenar tablas juntas (en un mismo cluster). Útil para ejecutar joins (alternativa a desnormalizar) zSi hay otros atributos que se usan en condiciones de selección o en joins entonces se definen como índices. yconveniente si se seleccionan pocas tuplas ( 100 tuplas) zSi la tabla se actualiza con gran frecuencia hay que definir un número mínimo de índices (coste de actual.) zSi 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 zRealizar el diseño físico inicial xObtener información de las operaciones esperadas xResolver operaciones con mayores restricciones (aplicando algunos de los métodos explicados) xResolver el resto de las opers. sin perjudicar a otras añadir índices para favorecer consultas perjudica a operaciones de inserción / borrado zReplantearse continuamente dicho diseño (Tunning) xanalizar/auditar el sistema actual xtomar 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 yTransacción: colección de operaciones que forman una única unidad lógica de trabajo en una BD yControl concurrencia xSistemas multiusuario: ejecución intercalada yRecuperación xPara cuando una transacción falla yVida de una transacción xInicio xLecturas/escrituras de elementos de la BD xFinal (pueden hacer falta algunas verificaciones) xConfirmación (COMMIT) o anular (ROLLBACK)

33 Transacciones yToda transacción debe cumplir el principio ACID xAtómica: se ejecuta todo (commit) o nada (rollback) Debe garantizarlo el método de recuperación del SGBD xConsistente: pasa de un estado consistente a otro Debe garantizarlo el programador y el SGBD (restr. int.) xaIslada: 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). xDuradera: 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 yCaídas del sistema durante una transacción yErrores de ejecución: overflow, división por 0... yErrores lógicos que violan alguna regla de integridad (definida explícitamente o no) y que dejan inconsistente la BD -> programador/ABD yProblemas de concurrencia de transacciones yFallos de lectura/escritura en disco yProblemas físicos y catástrofes: fuego, robos, sabotajes, fallos humanos,... --> medidas de seguridad informática en la empresa.

35 Recuperación yPara que el sistema se pueda recuperar ante fallos se necesita grabar cada operación con la BD en un fichero LOG (bitácora). Checkpoints. xse escribe en el fichero LOG antes que en la BD xel fichero LOG debe estar en memoria estable yPor cada operación se escribe un reg. en LOG x

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

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

38 Control de concurrencia: planes serializables yDadas las transacciones T1, T2,... Tn, –T1 compuesto por operaciones O 11,O 12,..O 1 m1 –T2 compuesto por operaciones O 21,O 22,..O 2 m2 –... Tn compuesto por operaciones O n1, O n2..O n mn yUn plan de ejecución concurrente de las transacciones sería: Ej: O 11, O 21, O n1, O n2, O 12, O 22, …, O 1 m1, O 2 m2, …, O n mn Una intercalación de todas las operaciones O ij donde para todo i, O i1 se ejecuta antes que O i2... antes que O i mi yUn 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 zAparte de ACID, queremos que las transacciones sean serializables. zDeterminar si un determinado plan es serializable es un problema NP-completo. zSolución: Imponer restricciones a la libre intercalación de operaciones entre transacciones xTécnicas pesimistas: se impide realizar ciertas operaciones si son sospechosas de producir planes no serializables: BLOQUEOS (lock) y MARCAS DE TIEMPO (time-stamping) xTécnicas optimistas: no imponen restricciones pero después se comprueba si ha habido interferencias

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

41 Protocolo de Bloqueo en dos fases zUna transacción sigue el protocolo de bloqueo en dos fases si nunca hace un lock después de haber hecho algún unlock. xFase de crecimiento: se solicitan locks xFase de devolución: se realizan unlocks zSolamente este protocolo de bloqueo garantiza la serializabilidad de transacciones zSin embargo, existe riesgo de deadlock !! xPrevención de deadlocks xDetección y recuperación de deadlocks

42 Deadlocks zDeadlock (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. zPrevención de deadlocks yCada 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) yLos elementos de la BD están ordenados de alguna manera y los lock hay que obtenerlos en dicho orden. Los programadores deben controlarlo !! zDetección y recuperación de deadlocks. yA 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) yUn 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)) ySi 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) yUna 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)) yGarantiza serializabilidad y ausencia de deadlocks. Puede haber livelock (si se aborta siempre a la misma transacción)

44 Técnicas optimistas zNo se realizan comprobaciones ANTES de ejecutar las operaciones (pedir locks, comprobar timestamps), sino al acabar toda la transacción (fase validación) zDurante la ejecución de la transacción se trabaja con copias zHay tres fases en un protocolo optimista: yFase de lectura yFase de validación yFase de escritura zEs bueno cuando no hay muchas interferencias entre transacciones (por eso son optimistas)

45 Recuperación en Oracle zRedo logs (cíclicos) zArchive logs (consolidación de redo logs) zBackups yMirrors yExport: Incremental, acumulativo (colección de incrementales), total zRecuperación basada en cambios, tiempo, paso-a-paso (basado en archive logs), completa

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

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

48 Control de concurrencia en ORACLE (y 3) zNo hay UNLOCK explícitos en ORACLE!! ySe realiza un UNLOCK implícito de todos los LOCK con cada COMMIT o ROLLBACK (implícitos o explícitos) zPregunta: ¿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 zAcceso básico. Casos Especiales zSQL embebido zUso de un API xTipos de API xODBC. Drivers zBases de datos en la Web

51 Acceso Básico zNormalmente suministrado por el SGBD y sus aplicaciones adjuntas zPuede no existir. SGBOO zPrompt (SQL). Oracle: SQL-Plus z4GL. Informix, Oracle (PL/SQL) yForms, reports, menus zEntornos completos. MS Access

52 SQL Embebido zLenguaje de Programación Host zPreprocesador + Librerias = Programa zSQL estático vs. dinámico zTipos de datos distintos. Equivalencias zVariables Host zLimitaciones (¿transacciones?, ¿actividad?, etc)

53 SQL Dinámico: Oracle 4 Métodos: elegir siempre el más sencillo posible según el caso zMétodo 1 (no selects, no placeholders) Ej: EXEC SQL EXECUTE ´delete from emp where dpto=20´ zMétodo 2 (no selects, # placeholders conocido) Ej: EXEC SQL PREPARE s FROM ´delete from emp where dpto=:dpto_num´ EXEC SQL EXECUTE s USING :departamento

54 SQL Dinámico: Oracle (2) zMétodo 3 (acepta selects, # proyecciones, placeholders conocido) Ej: Select nombre, apellidos from emp where dpto=:dpto_num Prepare, declare cursor, open cursor using..., fetch cursor, close cursor zMétodo 4 (sin restricciones) Ej: select ???? from ???? where ???....

55 Uso de un API zAPI: Aplication Program Interface zProtocolos y funcionalidades zTipos de API´s yPropietarios. Ej: OCI (Oracle Call Interface) yInteroperables xCLI (Call Level Interface) xODBC (Open Data Base Connectivity). xIDAPI

56 ODBC zDesarrollado por Microsoft zNO es un protocolo de comunicación zDriver ODBC: programa que interactua con un SGBD concreto y ofrece un API según los dictados ODBC. yImplementado con SQL embebido yImplementado con un API propietario zJDBC. Drivers JDBC. Driver JDBC-ODBC

57 Bases de datos en la Web zPáginas Web: puntos de interrogación a Bases de datos zForms y CGI´s zPerdemos el acceso directo al SGBD: no disponemos de SQL !!! zSolución: Encapsulación. Acceso limitado por el CGI.

58

59 Bases de Datos Orientadas a Objetos (BDOO)

60 BDOO: Motivación zAplicaciones tradicionales de BD donde xexisten muchos datos almacenados en registros (pocos tipos de registros) gen. de longitud fija con campos atómicos (en 1FN) y de tamaño pequeño xesquemas de BD casi no cambian y están en 1FN xlas transacciones son generalmente cortas zExisten nuevas aplicaciones de BD xAplicaciones de diseño: CAD, CASE,... xOfimática xSistemas de Información Geográfica (GIS) xBD multimedia xSistemas expertos de BD (manejar conocimiento)

61 BDOO: Motivación (2) zLas nuevas aplicaciones de BD necesitan: yesquemas dinámicos ymás entidades distintas con probablemente menos datos (ocurrencias) en dichas entidades ycampos de longitud variable y que contengan más tipos de datos: gráficos, sonidos, textos... ymeta conocimiento ydistintas versiones de los datos ymanejar transacciones largas

62 BDOO: Motivación (3) Tendencias nuevas (post-relacionales) en investigación. ¿Triunfarán comercialmente? –Modelos semánticos de datos –Bases de datos históricas (temporales) –Bases de datos no en 1FN (multievaluación) –Sistemas expertos de BD (integr. IA - BD) –Lenguajes de programación de BD: DB + LP BD deductivas: fusión leng. progr. lógica + SGBD BD funcionales: progr. funcional + SGBD BDOO: progr. orientada a objetos + persistencia

63 Herramientas Modelo Relacional yLos SGBD Relacionales proporcionan xforms para hacer entrada de datos xinterfaces (simil. a hojas de cálculo) para ver datos xgeneradores de informes xfacilidades para escribir SQL embebido desde LP ySQL embebido (a utilizar desde un Leng. Prog.) xDefinir tipos, conocidos por el SGBD distintos a LP xConexión a la BD xCaptura de excepciones (errores) xSeleccionar tuplas simples desde una BD xSeleccionar varias tuplas (uso de cursores) xEjecutar sentencias SQL dinámico (en tiempo ejec.)

64 Problemas Modelo Relacional ySQL no es computacionalmente completo. Se necesitan LP > Mismatch impedance xcon los tipos: el SGBD y el LP tienen distintos tipos Los LP no ofrecen un tipo primitivo relación que tome como valor un CONJUNTO DE VALORES ! –Es necesario utilizar CURSORES para tratamiento secuencial dentro de un programa !! Los tipos abstractos de datos que se pueden crear con LP habría que guardarlos en tablas para darles persistencia. xcon la estrategia de evaluación El LP hace una pregunta SQL, el SGBD obtiene la respuesta y la guarda en un lugar intermedio para dársela al LP (traducida). Tal vez éste NO PIDA MÁS DATOS !!

65 Problemas Modelo Relacional (2) zPoder limitado de modelado yEl modelo relacional tiene como único tipo de datos a las TABLAS con ATRIBUTOS. ySin embargo nos gustaría poder definir xEntidades con sus propiedades (multivaluadas) xGeneralización / Especialización de entidades xRelaciones entre entidades (con restricciones) xUn determinado orden de los datos almacenados

66 Problemas Modelo Relacional (3) zComplejidad del entorno yLos programadores deben saber programar con el SGBD (SQL) y con el LP yHacer que programas YA existentes que trabajan con ficheros lo hagan con BDs es duro yPara añadir interfaces a los programas de BDs hay que manipular otros tipos de objetos gráficos que no pueden ser guardados en la BD. yPara cambiar de una plataforma a otra, todos los distintos componentes usados deben ser soportados de manera consistente en la nueva.

67 Qué son las Bases de Datos Orientadas a Objetos (BDOO) zBDOO = BD + OO zCaracterísticas BD yPersistencia + Concurrencia + Transacciones + Recuperación + Lenguajes de Interrogación / Definición / Manipulación + Integridad + Seguridad + Eficiencia (+ Versiones) zCaracterísticas OO yTipos Abstractos de Datos (TAD) + Herencia + Identidad de Objetos [TAD = Tipos + Operaciones + Encapsulación]

68 Conceptos básicos OO yObjetos complejos xUn objeto es un elemento con una estructura (atrs. de ciertos tipos) (que pueden ser simples, listas, conjuntos,..) y un comportamiento (operaciones o métodos) que corresponden a la definición de la CLASE de la cual el objeto es una INSTANCIA. CLASE define unos ATRIBUTOS y MÉTODOS La clase agrupa a una serie de OBJETOS o INSTANCIAS yIdentidad de objetos xCada objeto tiene un identificador único (OID) Inalterable y dado por el sistema al crearse. Ej: 25#cine o bien sin indicar la clase: #35

69 Conceptos básicos OO (2) zIdentidad de objetos (cont.) yA diferencia del modelo relacional puede haber objetos distintos con los mismos valores. yPredicados de igualdad yo1 idéntico a o2 si contienen el mismo OID yo1 igual de manera superficial a o2 si el contenido de los objetos es identico. yo1 igual de manera profunda a o2 si el contenido de los valores escalares es igual y, si los valores son OIDs, si son iguales de manera profunda. yOperaciones de copia de objetos yCopia superficial: devuelve un nuevo objeto con los mismos valores (escalares y OIDs) yCopia profunda: crea un nuevo objeto con los mismos valores escalares y si son OIDs con copias profundas de dichos objetos.

70 Conceptos básicos OO (3) zEncapsulación yCada objeto tiene una parte que constituye su INTERFAZ y otra que constituye su IMPLEMENTACIÓN. ySólo se puede acceder a cada objeto a través de su INTERFAZ, o lo que es lo mismo, enviando órdenes para que ejecute MÉTODOS. xExcepción: el procesador de preguntas sí puede !!! yEl objetivo es encapsular los DATOS y los PROGRAMAS dentro de los OBJETOS.

71 Conceptos básicos OO (4) zDiferencia entre tipos y clases yUn tipo define una estructura que se utiliza para comprobar que no hay errores en tiempo de compilación. Todo valor de los que aparece en un programa DEBE SER de algún tipo. yUna clase está formada por un tipo(s), unas operaciones y un conjunto de instancias de dicho tipo(s). yTAD = tipo + operaciones + encapsulación yclase = TAD + herencia + cjto de instancias

72 Conceptos básicos OO (5) zHerencia yUna clase A se puede definir como subclase de otra clase B. yEn ese caso, todos los atributos y métodos de la clase B son heredados por la clase A. yAlgunos SGBDOO permiten herencia múltiple, esto es, que una clase sea subclase de más de una clase. En ese caso, hereda las propiedades de todas sus super-clases (problemas). xNOTA: Nos referimos a subclase directa en el árbol.

73 Conceptos básicos OO (6) zOverloading (sobrecarga), overriding (imposición), late binding (asociación retardada) yUn sistema soporta overloading si distintas clases pueden tener propiedades con el mismo nombre. ySi se producen conflictos con los nombres de una subclase y sus superclases entonces prevalece el de la subclase (overriding) yCuando se invoca un método de un objeto, en tiempo de ejecución, se busca el código en la clase a la que pertenece y si no se encuentra, entonces se va buscando transitivamente por sus superclases (late binding).

74 Persistencia: C++ persistente zEs posible escribir programas C++ con todas las características de OO comentadas (ver conceptos básicos de OO). zProblema: las características de BD no se conseguirían (ver definición BDOO) zIntento de solución: extender C++ para que permita definir clases persistentes. xpersistent class A: public B,..D {.....} xNOTA: Las clases persistentes no deben contener punteros a clases no persistentes !

75 Persistencia: C++ persistente (2) zSin embargo, el resto de características BD siguen sin obtenerse (ver definición BDOO = BD + OO) yLo peor: el lenguaje de interrogación es navegacional o procedural (es mejor el del modelo relacional que es asercional) yLo mejor: no hay mismatch impedance ni el resto de problemas señalados en (problemas modelo relacional).

76 Diseño de BDOO zPara diseñar BDs generalmente se usa un modelo de BDs semántico llamado Entidad- Relación (extendido) de Chen. zLos pasos que se pueden seguir son: yObtener el esquema E-R extendido yNormalizar dicho esquema E-R xObtener las tablas correspondientes al E-R xNormalizar las tablas relacionales. xObtener el E-R al que corresponderían dichas tablas yTraducir el esquema E-R a un esquema OO

77 Traducción E-R a OO zLas entidades y relaciones del E-R se pueden traducir a clases y atributos OO. yEntidad -----> Clase yEntidad especialización -----> Subclase yRelación 1:1, 1:N > Atributo sobre Clase yRelación N:M > 2 atributos sobre Clases yRelaciones de grado mayor que 2 o de tipo N:M con atributos > Clase yNo olvidar que se pueden definir métodos xPara atributos calculados, realizar tareas (imprimir..)

78 ODE: Un SGBDOO zODE es un SGBDOO yDesarrollado en los laboratorios AT&T yUtiliza un lenguaje de programación de BD llamado O++ basado en C++ xOtros SGBDOOs: GemStone, Iris, O2, ORION, ObjectStore (basado en C++), Vbase. yO++ extiende C++ para incluir características propias de BDs: xPersistencia, transacciones, lenguaje de preguntas... yArtículos ODE: ftp://research.att.com/dist/db

79 Lenguaje O++ zPersistencia yUna clase C++ se puede declarar como persistente. Apuntadores de objetos también xpersistent class personas {.... } xpersistent personas * pe; xUtilizamos el método pnew (pdelete) para crear (destruir) objetos persistentes pe = pnew personas( ); pdelete pe; xSe usa pthis en vez de this para referirnos a un objeto persistente en la implementación de métodos

80 Lenguaje O++ (2) zTransacciones ySe puede utilizar protocolo bloqueo en 2 fases yToda interacción con la BD debe ocurrir dentro de la definición de una transacción. trans {...../* lectura escritura en la BD..... */ } ySe puede hacer commit y rollback. COMMIT: Al terminar el bloque trans {....} COMMIT: Al ejecutar un break o un continue ROLLBACK: al ejecutar tabort y al fallar.

81 Lenguaje O++ (3) zOperaciones de abrir / cerrar BDs x#include x xmain () { database * db; if ((db = database::open(nombre_BD)) = = NULL) cout Error al abrir la BD nombre_BD<close(); }

82 Lenguaje O++ (4) zLenguaje de preguntas yfor (vars. que recorren clases) (FROM) y[ suchthat (condiciones) ] (WHERE) y{ /* instrucciones C++ */ } (SELECT y +) yEjemplos: xfor (pe in empleado) suchthat (pe->salario > 20000) cout Nombre: nombre; xfor (pp in all persona; pc in coche) suchthat (strcmp(pp->pais,pc->pais)==0) {....} xfor (pe in empleado) suchthat (pe->padre->edad() > 50) {.....}

83 Lenguaje O++ (5) zODE proporciona listas persistentes (plist.h) zEs posible definir índices o hash. xdatabase::BuildIndex(persona,persona::nombre, punt_db,1,BTREE_TYPE) xPuede ser BTREE_TYPE o HASH_TYPE xEl 1 significa índice único (0 si no es único). xExisten funciones IndexDelete e IndexExists yNO SE INDICA EN LAS PREGUNTAS QUE SE USE UN ÍNDICE/HASH. LO DECIDE EL OPTIMIZADOR zSe pueden definir triggers zSe pueden crear versiones de objetos.

84 Crítica a los SGBDOO: limitaciones zLenguaje de preguntas: yNo son compatibles con ANSI-SQL yNo incluyen preguntas anidadas, union, intersección, funciones de agregación, group by... zNo soportan creación de vistas (Como en SQL) zNo permiten que los usuarios controlen privilegios yEn SQL se puede hacer GRANT, REVOKE,... zNo dejan cambiar clases dinámicamente (añadir atrs...) yEn SQL se puede hacer ALTER TABLE...

85 Crítica a los SGBDOO: limitaciones zGen. los usuarios deben manejar los locks (transacc.) zCapacidades limitadas para hacer tuning de la BD zDistintos OIDs en distintas BDOOs zRelacional: operaciones cerradas (resultados son rel.) OO: operaciones sobre clases dan cjtos de OIDs !!!

86 Crítica a los SGBDOO: mitos zLos SGBDOO son mucho más rápidos que los relacionales yEn realidad sucede si la aplicación navega entre objetos (OIDs) que están cargados en memoria principal. zSe elimina la necesidad de ejecutar joins yNo eliminan. Reducen el nº de joins (al navegar por atributos) zSe elimina la necesidad de usar claves. (No, DNI es clave)

87 Crítica a los SGBDOO: mitos zNo se necesitan lenguajes asercionales. No, eso viene porque al principio NO OFRECÍAN dichos lenguajes! zEl procesamiento de preguntas viola encapsulación yAcceder atributo [pepe.nombre] vs. método [pepe.get_nom()] zPueden soportar mejor versiones y transacciones de larga duración. No, en BD relac. no se ha tratado lo suficiente. zSoportan datos multimedia. En principio mejor que con relacionales. Quedan muchas cuestiones que resolver.

88

89 Bases de Datos Distribuidas (BDD)

90 BD Distribuidas zTecnología de Bases de Datos (tradicional) yCentralización de datos xVarios Ficheros Una Base de Datos zRedes de Computadores yDistribución/compartición de recursos xBD centralizada BD distribuida (¿varias BDs?) zBD Distribuidas: unión de estas dos aproximaciones (aparentemente opuestas) yLa tecnología de BD busca la INTEGRACIÓN de los datos y no la CENTRALIZACIÓN

91 Definición de BD Distribuida zUn sistema de BD distribuidas es una colección de varias BDs que se encuentran lógicamente inter-relacionadas y distribuidas sobre una red de ordenadores. zUn sistema de gestión de bases de datos distribuidas (SGBDD) es el software que permite el manejo de sistemas de BDs distribuidas y que hace dicha distribución transparente al usuario.

92 Definición de BD Distribuida zNo son Sistemas de BD Distribuidas: yUn sistema de ordenador de tiempo compartido yUn sistema de multiprocesadores (BD Paralelas) yUn sistema de BD que reside en uno de los nodos de una red. Eso es una BD centralizada accesible a través de la red.

93 Transparencia en entornos Distribuidos zTransparencia de red yel usuario no debe ser consciente del uso de la red ytransparencia de localización: dónde están los datos, lenguajes locales necesarios ytransparencia de nombres: nombres únicos en todo el sistema distribuido, independientes de la localización zTransparencia de fragmentación yel usuario no debe ser consciente de la existencia de varios depósitos de datos zTransparencia de replicación yel usuario no debe ser consciente de la existencia de varias copias de los datos

94 Ventajas de las BDD (I) zLa distribución puede ser la organización más natural zMayor fiabilidad y disponibilidad (puede haber replicación) zAutonomía local (establecer políticas locales de acceso a datos) zMás eficiencia al acceder a los datos locales (frente a una centralizada)

95 Ventajas de las BDD (y II) zEconomía (mejor varios PCs en red que un mainframe) zMás posibilidades de expansión (añadir más recursos a la red) zCompartición de datos (debido a que se encuentran en red)

96 Desventajas de las BDD zFalta de experiencia en el diseño de SBDD zComplejidad ytodos los problemas de las BD centralizadas y otros) zCosto (hardware / software de comunicaciones) zDistribución de control ytambién era ventaja: autonomía) zSeguridad yse añaden los problemas de seguridad en redes zDificultad de cambio ylas empresas ya tienen BD centralizadas

97 Factores que influyen en las arquitecturas de BDDs (I) zDistribución yUna BD es distribuida si esta dividida en distintos componentes (integrados) yBDD <> varias BDs no integradas yLos componentes distribuidos que constituyen una BD distribuida son a su vez bases de datos (BDs componentes o locales) yLas BDs componentes tendrán un grado de autonomía local determinado

98 Factores que influyen en las arquitecturas de BDDs (II) zAutonomía Tipo de control que los SGBD tienen sobre cada BD local xAutonomía de diseño : existe si los administradores de la BD (ABD) pueden cambiar el esquema conceptual de sus BDs independientemente de si forman parte de un sistema distribuido o no. xAutonomía de comunicación : si se puede decidir localmente cuándo comunicarse con los otros SGBD locales. xAutonomía de ejecución : si se pueden ejecutar transacciones globales y locales en el orden en que se quiera. xAutonomía de participación : si puede decidir cómo participar en el sistema distribuido.

99 Factores que influyen en las arquitecturas de BDDs (III) zHeterogeneidad yDistinto hardware, SO, software comunicaciones. yDistinto modelo de datos (rel., jerárquico, red, OO,..) yDistintos SGBDs (aunque sean del mismo modelo) yHeterogeneidad semántica (aun con el mismo SGBD) xsinonimia: elementos iguales con distintos nombres xhomonimia: elementos distintos con igual nombre xotras relaciones semánticas (hiperonimia, hiponimia, agregación, etc,…) xel mismo elemento del mundo real puede ser representado como entidad o atributo, atributos con tipos diferentes, etc. xPuede existir tanto a nivel intensional como extensional

100 Factores que influyen en las arquitecturas de BDDs (y IV) zExistencia o no de esquema global ySi se proporciona un esquema global entonces es como si se trabajara con una única base de datos. Las preguntas se realizan sobre dicho esquema global: –SELECT * –FROM VUELOREAL, BILLETES –WHERE VUELOREAL.ID=BILLETES.ID xEn el esquema global se sabrá que VUELOREAL está en BD1 y BILLETES en BD2 pero es transparente al usuario ySi no, se necesita un lenguaje de acceso a distintas BDs. –SELECT * –FROM –WHERE VUELOREAL.ID=BILLETES.ID

101 Arquitecturas de BD distribuidas zSistemas de BDs Distribuidas (SBDD) yFormados por BDs no autónomas. yProporcionan un esquema global. yEl esquema global se obtiene de arriba a abajo: primero se define el esquema conceptual global y luego se fragmenta en varias BDs. zSistemas de BDs Interoperantes (SBDI) yFormados por BDs autónomas. yNo proporcionan esquema global sino lenguajes de acceso a BDs. yEl usuario es consciente de que trabaja con varias BDs. zSistemas de BDs Federadas (SBDF) yFormados por BDs autónomas. yProporcionan un esquema global. yEl esquema global se obtiene de abajo a arriba: los esquemas locales son pre-existentes y se integran en un esquema global. No se decide fragmentar: la redundancia probablemente ya existe.

102 Diseño de BDs Distribuidas zHay que decidir en qué nodos deben residir los datos Diseño de BDs Distribuidas yEn los SBDF no se hace porque las BDs ya existen. Hay que integrarlas para obtener el esquema global yEn los SBDD, tras obtener el esquema conceptual global se debe fragmentar y asignar zY donde residirán las aplicaciones que trabajan con los datos

103 Diseño de BDs Distribuidas zEs necesario un sistema de gestión de BD Distribuidas que realice lo siguiente: yprocesamiento de preguntas ymantenimiento de la consistencia si hay replicación de datos ycontrol de transacciones yetc... zEn algunos casos (determinados SBDD, SBDI) se podrá comprar, pero no siempre (SBDF)

104 Diseño top-down de BDD Esquema Global Información de Acceso (transacciones) FRAGMENTACIÓN Esquema Local 1 Esquema Local N Esquema Físico 1Esquema Físico N DISEÑO FÍSICO ASIGNACIÓN Esquema Global Fragmentado

105 Fragmentación (I) zEl problema de obtener los esquemas locales a partir del global se divide en dos: yFragmentación: dividir el esquema global en fragmentos. yAsignación: distribuir los fragmentos entre los esquemas locales. zEl fragmento es la unidad a distribuir xpuede ser parte de un tabla o un cjto. de ellas. xventaja: incrementa el nivel de concurrencia de transacciones. xdesventaja: algunas transacciones se degradarán si tienen que trabajar con varios fragmentos.

106 Fragmentación (II) Fragmentación vertical: basada en encontrar conjuntos de atributos a proyectar Fragmentación horizontal: basada en encontrar condiciones de selección

107 Fragmentación híbrida (y III) Primero horizontal... y luego vertical a cada fragmento

108 Corrección de la fragmentación zCompletitud yTodo elemento de la relación debe estar en alguno de los fragmentos. zReconstrucción yLa relación inicial debe poder reconstruirse aplicando operadores sobre los fragmentos zIntersección vacía (disjointness) yIntersección de los fragmentos debe ser vacía Nota: a excepción de las claves (para poder reconstruir la relación inicial a partir de los fragmentos)

109 Asignación (I) zAsignar fragmentos a los esquemas locales ySin replicación: todo fragmento reside en un único nodo xbueno para actualizaciones, malo para preguntas yCon replicación total : todos los fragmentos residen en todos los nodos xbueno para preguntas, malo para actualizaciones yCon replicación parcial: algunos fragmentos pueden residir en más de un nodo xcompromiso entre actualizaciones y preguntas

110 Asignación (y II) PROCESAMIENTO DE PREGUNTAS CONTROL DE CONCURRENCIA DISPONIBILIDAD DE LOS DATOS REPLICACIÓN COMPLETA REPLICACIÓN PARCIAL SIN REPLICACIÓN Más fácilMás difícil Difícil Más difícilMás fácil Muy altaAltaBaja

111 Formulación del problema de la asignación zDados N fragmentos y M nodos, encontrar la matriz X y(X ij = true) el fragmento i se aloja en el nodo j tal que minimiza el costo total xsuma de los costos de procesamiento de todas las preguntas, actualizaciones (multiplicando cada costo por el nº de veces que se pregunta / actualiza) y costos de almacenar todos los fragmentos ysujeto a las siguientes restricciones: xtiempo de respuesta máximo para cada pregunta xexiste un almacenamiento máximo en cada nodo xno superar la carga de procesamiento en cada nodo El problema es NP-completo. Pero se pueden usar heurísticos: problema de la mochila, técnicas de ramificar y acotar, algoritmos genéticos, etc...

112 Esquema Local N en un modelo canónico Esquema Local 1 Esquema Local N Esquema Local 1 en un modelo canónico TRADUCCIÓN INTEGRACIÓN Esquema Global en un modelo canónico Diseño bottom-up de BDD

113 Obtención del Esquema Global (I) zEl problema de obtener un esquema global a partir de N esquemas locales se divide en dos: yTraducción: cada esquema local se traduce a un modelo canónico yIntegración: los esquemas locales se integran en uno solo zEste es un tema de investigación. Todavía no resuelto por productos comerciales

114 Modelo canónico zEl modelo de datos (canónico) utilizado para expresar el esquema global es muy importante. –No hay que olvidar que las bases de datos locales pueden ser heterogéneas (distintos modelos de datos) –Se utilizan modelos más ricos semánticamente que el relacional: OO, modelos funcionales, semánticos, etc...

115 Obtención del Esquema Global (y II) Supongamos que los esquemas locales son relacionales y se usa como modelo canónico el modelo semántico Entidad- Relación Extendido de Chen zTraducción yA partir de tablas y atributos relacionales (esquema exportado) se identifican entidades, relaciones y atributos (enriquecimiento semántico) yPueden aparecer nuevas entidades (especializaciones/generalizaciones, etc.) zIntegración yAplicación de las propiedades semánticas entre las entidades y relaciones de distintos esquemas locales canónicos (sinonimia, unión, generalización/especialización, etc.)

116 Uso del esquema global zProcesamiento de preguntas yLas preguntas realizadas sobre el esquema global deben responderse sobre los esquemas locales zInformación de enlace yRelación entre los elementos de datos del esquema global y los elementos de datos de los esquemas locales yNecesaria para poder responder a las preguntas

117 Optimización de pregs. en BDD Pregunta sobre relaciones distribuidas DESCOMPOSICIÓN Pregunta en álgebra relacional sobre relaciones distribuidas LOCALIZACIÓN DE DATOS Pregunta sobre fragmentos OPTIMIZACIÓN GLOBAL OPTIMIZACIÓN LOCAL Pregunta sobre fragmentos y operaciones de comunicación Preguntas locales optimizadas Esquema Global Esquema de Fragmentos Estadísticas sobre Fragmentos Esquema Local

118 Transacciones en BDDs: protocolo de commit en 2 fases zSe desea ejecutar una transacción T compuesta por varias transacciones T 1,... T n sobre varias BDs: BD 1,...BD n. Para ejecutar un COMMIT global: zFase de votación yCada transacción T i no hace COMMIT sino que dice al nodo coordinador si puede hacerlo y espera a que éste le conteste zFase de decisión ySi todas las T i han respondido diciendo que pueden hacer COMMIT el coordinador ordena que se ejecute. En otro caso ordena un ROLLBACK a todas ellas. El coordinador debe recibir acknowledge de todos

119 Bases de Datos Activas

120 BD Activas: Motivación zLos SGBD convencionales son pasivos. Sólo ejecutan preguntas o transacciones realizadas por los usuarios o por los programas de aplicación. zPara representar la semántica del mundo real proporcionan: yMODELO DE DATOS xEstructuras de Datos xOperadores para trabajar con las estructuras xReglas de integridad yMODELO DE TRANSACCIONES xPosibilidad de definir transacciones pero sólo si los usuarios o aplicaciones lo solicitan explícitamente

121 BD Activas: Motivación (2) zLos SGBD pasivos NO SON BUENOS para modelar comportamiento dirigido por sucesos. zEjemplo: si el stock de un producto baja de un cierto umbral entonces solicitar más. Para implementarlo: y1) En toda aplicación que modifique el stock de algún producto hay que añadir código que compruebe si se baja del umbral para solicitar más. xLa semántica está distribuida por las aplicaciones. xPosiblemente es una fuente de errores. y2) Realizando un programa que periódicamente sondee todas las condiciones (¿ stock(i) < umbral(i) ?) xFrecuencia de sondeo alta --> INEFICIENCIA xFrecuencia de sondeo baja --> INCONSISTENCIAS

122 BD Activas: Definición y Modelo de Conocimiento zUn Sistema de Bases de Datos Activas es un sistema que monitoriza situaciones de interés y que, cuando ocurren, dispara o activa la ejecución de una serie de acciones. zEl comportamiento deseado se expresa en forma de Reglas Evento-Condición-Acción (ECA) xON evento xIF condición xTHEN acción zNota: Las reglas ECA provienen del paradigma de las Reglas de Producción (IF condición THEN acción) tratado en Inteligencia Artificial (sobre todo en Sistemas Expertos)

123 Modelo de Conocimiento zON evento IF condición THEN acción yevento puede ser un suceso primitivo: xocurre una operación con la BD (insert,...) xcomienza / termina una transacción (commit,..) xsuceso externo: bajada de tensión xsuceso temporal: es primer día de mes xsuceso abstracto: violada una regla de integridad yo un suceso compuesto: xS1 OR S2 (sucede el suceso S1 o el S2) xS1 AND S2 (suceden ambos sucesos) xS1 ; S2 (sucede S1 y después S2)

124 Modelo de Conocimiento (2) ON evento IF condición THEN acción –Se cumple una determinada condición en la BD el valor de un atributo es uno determinado el valor nuevo a insertar es menor que el viejo etc. ON evento IF condición THEN acción –Se dice que se ejecute algo automáticamente un abort o rollback mandar un mensaje al usuario introducir / modificar datos en la base de datos etc.

125 Modelo de Ejecución zEs el comportamiento de las reglas en tiempo de ejecución. Se debe conocer: y1) Cuándo se evalúan los eventos (la frecuencia, si se evalúan dentro de transacciones, etc.) xDurante la ejecución de una transacción puede haber momentos en los que la BD está inconsistente y2) A qué reglas ECA se les evalúa antes la condición de entre las activadas por los eventos x¿Los eventos que ya han activado reglas pueden seguir activando otras? Ej: el evento es el primer día del mes y3) Qué regla ECA se ejecutará la primera de entre las que cumplen la condición. xRelacionado con el problema del conjunto conflicto detectado por el motor de inferencia en S. Expertos

126 Triggers en ORACLE 7 CREATE [OR REPLACE] TRIGGER nombre_de_trigger {BEFORE | AFTER} {DELETE | INSERT | UPDATE [OF nom_atr [, nom_atr]...]} [OR {DELETE | INSERT | UPDATE [OF nom_atr [, nom_atr]...]}]... ON nom_tabla [ [REFERENCING { OLD [AS] old [NEW [AS] new] | NEW [AS] new [OLD [AS] old] } ] [FOR EACH ROW [WHEN (condición)] ] bloque_PL/SQL EVENTO CONDICIÓN ACCIÓN

127 Triggers en ORACLE 7 (2) zOR REPLACE --> Reemplaza el trigger si ya existe zBEFORE/AFTER DELETE, INSERT,... ON tabla yIndica si la acción (PL/SQL) se debe ejecutar antes o después de que se produzca el borrado, inserción o modificación de la tabla. zFOR EACH ROW indica que se ejecute la acción (si se cumple la condición) para cada tupla insertada, borrada,... zWHEN --> Es una condición SQL. No puede contener una pregunta SQL. Sólo SE PUEDE PONER la parte WHEN en triggers del tipo FOR EACH ROW zEl bloque PL/SQL es la parte acción que ORACLE ejecuta cuando se produce el evento y se cumple la condición

128 Triggers en ORACLE 7 (3) Cuando los triggers son del tipo FOR EACH ROW, dentro del bloque PL/SQL se pueden utilizar las variables: –:NEW que contiene el NUEVO valor INSERTADO o MODIFICADO –El valor de :NEW se puede cambiar en triggers del tipo BEFORE INSERT/UPDATE pero no en triggers del tipo AFTER así se podrá controlar el valor que se va a introducir. –:OLD que es el valor BORRADO o el valor viejo MODIFICADO. –Con REFERENCING OLD AS mi_old... podemos renombrar OLD para que no haya problemas de nombres. Ej: una tabla se llama OLD Dentro del bloque PL/SQL se pueden realizar distintas acciones según se esté insertando, borrando o actualizando: –IF INSERTING THEN... END IF; –IF DELETING THEN... END IF; –IF UPDATING (nom_atr) THEN... END IF;

129 Restricciones en triggers Oracle zEl bloque PL/SQL que forma la parte acción no puede contener sentencias como COMMIT o ROLLBACK (ni CREATE..., ALTER...) zNo se pueden crear triggers sobre tablas del sistema que forman el catálogo. Sería bueno para realizar acciones cada vez que se creara, borrara, etc. una tabla en la BD !! zDentro de un trigger no se puede ni hacer SELECT de una tabla mutante, ni se puede cambiar la clave primaria, una clave ajena o claves únicas de una tabla restringida. yUna tabla mutante es aquella sobre la que se está haciendo un INSERT, un DELETE, un UPDATE o una tabla que puede ser afectada debido a una restricción DELETE CASCADE. yUna tabla restringida es aquella que es usada dentro de un trigger, por una sentencia SQL o para mantener una integridad referencial. yUna tabla no es considerada mutante ni restringida para triggers que NO SON del tipo FOR EACH ROW (excepto si el trigger se ha lanzado debido a una restricción DELETE CASCADE).

130 Consejos sobre Triggers Oracle zNo definir triggers para definir restricciones de integridad que es posible definir de manera declarativa como REFERENCES, atributos NOT NULL, UNIQUE, etc. ySí pueden servir para implementar los siguientes (no soportados todavía por Oracle) xON DELETE / UPDATE SET NULL, xON DELETE / UPDATE SET DEFAULT zNo construir triggers recursivos.

131 Bases de Datos Deductivas

132 BD Deductivas: Motivación zLa lógica como lenguaje de preguntas. yLos predicados corresponderían a relaciones. xvuelo(1,Madrid,París,13:30,15:30). yLas reglas corresponderían a defs. de vistas. xvuelo_Mad_tarde(N,S,L,HS,HL) :- vuelo(N,Madrid,L,HS,HL), HS > 14:00. yLa conjunción de predicados a demostrar serían las preguntas. x:- vuelo(N,Madrid,L,HS,HL), HS > 14:00. Ventaja: la definición de vistas es mucho más potente en lógica ya que puede utilizarse la recursión

133 Lógica como leng. de preguntas zSELECCIÓN yvuelo_mediodia(N,S,L,HS,HL):- vuelo(N,S,L,HS,HL),HS>=12:00,HL<=15:00. zPROYECCIÓN ynum_vuelo(N) :- vuelo(N,_,_,_,_). zJOIN yvuelo_inf_completo(N,S,L,HS,HL,Fec,Av,Pr):- vuelo(N,S,L,HS,HL),vueloreal(N,Av,Fec,Pr) zCombinación de los operadores del álgebra relacional. ynum_vuelo_barato(N) :- vuelo(N,_,_,_,_),vueloreal(N,_,_,P),P<10000 Se parece al lenguaje relacional QBE (Query By Example)

134 Lógica es más potente que QBE zYa que permite definir vistas recursivas yvuelo_compuesto(S,L):-vuelo(_,S,L,_,_). yvuelo_compuesto(S,L):- vuelo(_S,L1,_,_),vuelo_compuesto(L1,L). yNota: falta controlar que no se produzcan ciclos zEn QBE y en SQL no se pueden definir preguntas recursivas. yPara obtener todos los vuelos compuestos hay que escribir un programa (LP + SQL embebido)

135 Bases de Datos Deductivas zLenguajes de Programación de BD: BD + LP yOrientación a Objetos: BD + OO = BDOO yProgramación Lógica: BD + PL = BDD zVarias aproximaciones yExtender PROLOG para que incluya capacidades de BDs (persistencia, concurrencia,...) yExtender los sistemas de BDs para que incluyan capacidades de deducción xañadir un operador de clausura transitiva yRealizar SGBDD desde cero. Ej: DATALOG

136 ¿Y cuál es el futuro de los SGBD? Es difícil predecir......especialmente el futuro SGBD Relacionales + OO - Tecnología Object-Relational - Definición SQL3 SGBD Relacionales + Actividad - Triggers ya existen en algunos SGBD - Def. SQL3 intenta estandarizar SGBD Cliente/Servidor y Distribuidos Tal vez SGBD Relacionales + Deduct.? N. Boehr

137 En cualquier caso... gracias por aguantarme y suerte...


Descargar ppt "Bases de Datos Avanzadas Eduardo Mena D.0.17, tutorías 13:00-15:00 (M, X, J)"

Presentaciones similares


Anuncios Google