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

AsignaturasFicheros y BD (troncal)

Diseño de BD Relacionales (opt.)

BD Avanzadas (opt.) Sistemas de Información (opt.)

Interacción Hombre-Máquina (opt.)

Problemas detectadosDBDR 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

BDA SI

IHM

¿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

Repetición / Relacióncon otras materias

Ficherosson 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 + ...

BDA: Objetivos

SGBD relacionales otras alternativasConocer las tendencias futuras (I+D)Desarrollo de prototipos en entornos

heterogéneos (y distribuidos)Diseñar e implementar un sistema

multibase de datosSaber aplicar todos nuestros

conocimientos a casos “reales”

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

Optimización de Preguntas

Optimización de preguntas

Optimización: pregunta plan costo ópt.costo = CPU + I/O + COMUNICACIONES

Necesario para responder eficientementePosible 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)

Ejemplo motivador

La optimización es posible y necesariaLas distintas estrategias requieren

costes muy distintoDebe 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)

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

Optimización sintáctica

Entrada: expresión álgebra relacionalSalida: 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

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.

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

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

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

Generar los planes y escoger el más barato

Planes para responder a la pregunta, y su costoCada 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

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.

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)

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.

Diseño Físico

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 que1) cumplan los objetivos del sistema2) 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.

Diseño Físico: Recopilar información.

Por cada op. (preg. SQL) con la BD indicar:Tipo: INSERT, SELECT, UPDATE, DELETETablas 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.

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.

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íasHabrá redundancia pero estará controladaSe evitará ejecutar joins (según las frecuencias def.)

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

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,...Bmesas operaciones son muy frecuentesR(..Ai,...,Bj...) es mucho más grande que R(..Ai...)

Entonces almacenar R(...Ai...) en una tabla Scontrolar 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.

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

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)

Conclusiones

Realizar el diseño físico inicialObtener información de las operaciones esperadasResolver 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 actualtomar nuevas decisiones (añadir/borrar índices o tablas (crear

vistas y triggers si es necesario)

Transacciones, Recuperación y Control de Concurrencia

Transacciones

Transacción: colección de operaciones que forman una única unidad lógica de trabajo en una BD

Control concurrenciaSistemas multiusuario: ejecución intercalada

RecuperaciónPara cuando una transacción falla

Vida de una transacciónInicioLecturas/escrituras de elementos de la BDFinal (pueden hacer falta algunas verificaciones)Confirmación (COMMIT) o anular (ROLLBACK)

Transacciones

Toda transacción debe cumplir el principio ACIDAtó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.

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.

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 BDel 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>

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

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 vezHay que intercalar acciones pero que el

resultado sea como en exclusión mutua

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

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

Técnicas de bloqueo (lock)

A cada elemento de datos o gránulo X de la BD se le asocia una variableoperación lock_exclusivo(X): deja bloqueado al que

lo pide si otro ya tiene cualquier lock sobre Xoperación lock_compartido(X): deja bloqueado al

que lo pide si otro ya tiene un lock exclusivo sobre Xoperació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)

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 deadlocksDetección y recuperación de deadlocks

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!

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)

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

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

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ónNo permitirá hacer ningún INSERT, DELETE o UPDATE en

dicha transacción

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

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?

Interacción de Aplicaciones con BDs

Interacción de Aplicaciones con Bases de Datos

Acceso básico. Casos EspecialesSQL embebidoUso de un API

Tipos de APIODBC. Drivers

Bases de datos en la Web

Acceso Básico

Normalmente suministrado por el SGBD y sus aplicaciones adjuntas

Puede no existir. SGBOOPrompt (SQL). Oracle: SQL-Plus4GL. Informix, Oracle (PL/SQL)

Forms, reports, menusEntornos completos. MS Access

SQL Embebido

Lenguaje de Programación Host Preprocesador + Librerias = ProgramaSQL estático vs. dinámicoTipos de datos distintos. EquivalenciasVariables HostLimitaciones (¿transacciones?,

¿actividad?, etc)

SQL Dinámico: Oracle

4 Métodos: elegir siempre el más sencillo posible según el caso

Método 1 (no selects, no placeholders)Ej: EXEC SQL EXECUTE ´delete from emp where

dpto=20´

Mé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

SQL Dinámico: Oracle (2)

Mé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

Método 4 (sin restricciones)Ej: select ???? from ???? where ??? ....

Uso de un API

API: Aplication Program InterfaceProtocolos y funcionalidadesTipos de API´s

Propietarios. Ej: OCI (Oracle Call Interface) Interoperables

CLI (Call Level Interface)ODBC (Open Data Base Connectivity).IDAPI

ODBC

Desarrollado por MicrosoftNO es un protocolo de comunicaciónDriver ODBC: programa que interactua

con un SGBD concreto y ofrece un API según los dictados ODBC. Implementado con SQL embebido Implementado con un API propietario

JDBC. Drivers JDBC. Driver JDBC-ODBC

Bases de datos en la Web

Páginas Web: puntos de interrogación a Bases de datos

Forms y CGI´sPerdemos el acceso directo al SGBD:

no disponemos de SQL !!!Solución: Encapsulación. Acceso

limitado por el CGI.

Bases de Datos Orientadas a Objetos(BDOO)

BDOO: MotivaciónAplicaciones “tradicionales” de BD donde

existen 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

esquemas de BD casi no cambian y están en 1FNlas transacciones son generalmente cortas

Existen nuevas aplicaciones de BDAplicaciones de diseño: CAD, CASE,...OfimáticaSistemas de Información Geográfica (GIS)BD multimediaSistemas expertos de BD (manejar conocimiento)

BDOO: Motivación (2)

Las nuevas aplicaciones de BD necesitan: esquemas dinámicos más entidades distintas con probablemente

menos datos (ocurrencias) en dichas entidades campos de longitud variable y que contengan

más tipos de datos: gráficos, sonidos, textos ... meta conocimiento distintas versiones de los datos manejar transacciones largas

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

Herramientas Modelo Relacional Los SGBD Relacionales proporcionan

forms para hacer entrada de datosinterfaces (simil. a hojas de cálculo) para ver datosgeneradores de informesfacilidades para escribir SQL embebido desde LP

SQL embebido (a utilizar desde un Leng. Prog.)Definir tipos, conocidos por el SGBD distintos a LPConexión a la BDCaptura de excepciones (errores) Seleccionar tuplas simples desde una BDSeleccionar varias tuplas (uso de cursores)Ejecutar sentencias SQL dinámico (en tiempo ejec.)

Problemas Modelo Relacional

SQL no es computacionalmente completo. Se necesitan LP ------------> Mismatch impedancecon 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 .

con 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 !!

Problemas Modelo Relacional (2)

Poder limitado de modelado El modelo relacional tiene como único tipo de

datos a las TABLAS con ATRIBUTOS. Sin embargo nos gustaría poder definir

Entidades con sus propiedades (multivaluadas)Generalización / Especialización de entidadesRelaciones entre entidades (con restricciones)Un determinado orden de los datos almacenados

Problemas Modelo Relacional (3)Complejidad del entorno

Los programadores deben saber programar con el SGBD (SQL) y con el LP

Hacer que programas YA existentes que trabajan con ficheros lo hagan con BDs es duro

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

Para cambiar de una plataforma a otra, todos los distintos componentes usados deben ser soportados de manera consistente en la nueva.

Qué son las Bases de Datos Orientadas a Objetos (BDOO)

BDOO = BD + OOCaracterísticas BD

Persistencia + Concurrencia + Transacciones + Recuperación + Lenguajes de Interrogación / Definición / Manipulación + Integridad + Seguridad + Eficiencia (+ Versiones)

Características OO Tipos Abstractos de Datos (TAD) + Herencia +

Identidad de Objetos [TAD = Tipos + Operaciones + Encapsulación]

Conceptos básicos OO

Objetos complejosUn 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

Identidad de objetosCada objeto tiene un identificador único (OID)

• Inalterable y dado por el sistema al crearse.• Ej: 25#cine o bien sin indicar la clase: #35

Conceptos básicos OO (2)

Identidad de objetos (cont.) A diferencia del modelo relacional puede haber

objetos distintos con los mismos valores. Predicados de igualdad o1 idéntico a o2 si contienen el mismo OID o1 igual de manera superficial a o2 si el contenido de los objetos es identico. o1 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.

Operaciones de copia de objetos Copia superficial: devuelve un nuevo objeto con los mismos valores (escalares

y OIDs) Copia profunda: crea un nuevo objeto con los mismos valores escalares y si

son OIDs con copias profundas de dichos objetos.

Conceptos básicos OO (3)

Encapsulación Cada objeto tiene una parte que constituye su

INTERFAZ y otra que constituye su IMPLEMENTACIÓN.

Só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.Excepción: el procesador de preguntas sí puede !!!

El objetivo es encapsular los DATOS y los PROGRAMAS dentro de los OBJETOS.

Conceptos básicos OO (4)

Diferencia entre tipos y clases Un 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.

Una clase está formada por un tipo(s), unas operaciones y un conjunto de instancias de dicho tipo(s).

TAD = tipo + operaciones + encapsulación clase = TAD + herencia + cjto de instancias

Conceptos básicos OO (5)

Herencia Una clase A se puede definir como subclase de

otra clase B. En ese caso, todos los atributos y métodos de la

clase B son heredados por la clase A. Algunos 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).NOTA: Nos referimos a subclase directa en el árbol.

Conceptos básicos OO (6)

Overloading (sobrecarga), overriding (imposición), late binding (asociación retardada) Un sistema soporta “overloading” si distintas clases

pueden tener propiedades con el mismo nombre. Si se producen conflictos con los nombres de una

subclase y sus superclases entonces prevalece el de la subclase (“overriding”)

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

Persistencia: C++ persistente

Es posible escribir programas C++ con todas las características de OO comentadas (ver conceptos básicos de OO).

Problema: las características de BD no se conseguirían (ver definición BDOO)

Intento de solución: extender C++ para que permita definir clases persistentes.

persistent class A: public B,..D { .....}NOTA: Las clases persistentes no deben contener

punteros a clases no persistentes !

Persistencia: C++ persistente (2)

Sin embargo, el resto de características BD siguen sin obtenerse

(ver definición BDOO = BD + OO) Lo peor: el lenguaje de interrogación es

navegacional o procedural (es mejor el del modelo relacional que es asercional)

Lo mejor: no hay mismatch impedance ni el resto de problemas señalados en (problemas modelo relacional).

Diseño de BDOO

Para diseñar BDs generalmente se usa un modelo de BDs semántico llamado Entidad-Relación (extendido) de Chen.

Los pasos que se pueden seguir son: Obtener el esquema E-R extendido Normalizar dicho esquema E-R

Obtener las tablas correspondientes al E-RNormalizar las tablas relacionales.Obtener el E-R al que corresponderían dichas tablas

Traducir el esquema E-R a un esquema OO

Traducción E-R a OO

Las entidades y relaciones del E-R se pueden traducir a clases y atributos OO. Entidad -----> Clase Entidad especialización -----> Subclase Relación 1:1, 1:N --------> Atributo sobre Clase Relación N:M ------> 2 atributos sobre Clases Relaciones de grado mayor que 2 o de tipo N:M con

atributos ------> Clase No olvidar que se pueden definir métodos

Para atributos calculados, realizar tareas (imprimir..)

ODE: Un SGBDOO

ODE es un SGBDOO Desarrollado en los laboratorios AT&T Utiliza un lenguaje de programación de BD

llamado O++ basado en C++Otros SGBDOOs: GemStone, Iris, O2, ORION,

ObjectStore (basado en C++), Vbase.

O++ extiende C++ para incluir características propias de BDs:Persistencia, transacciones, lenguaje de preguntas...

Artículos ODE: ftp://research.att.com/dist/db

Lenguaje O++

Persistencia Una clase C++ se puede declarar como

persistente. Apuntadores de objetos tambiénpersistent class personas { .... }persistent personas * pe;Utilizamos el método pnew (pdelete) para crear

(destruir) objetos persistentes• pe = pnew personas(.......);• pdelete pe;

Se usa “pthis” en vez de “this” para referirnos a un objeto persistente en la implementación de métodos

Lenguaje O++ (2)

Transacciones Se puede utilizar protocolo bloqueo en 2

fases Toda interacción con la BD debe ocurrir

dentro de la definición de una transacción.trans { ...../* lectura escritura en la BD ..... */ }

Se puede hacer commit y rollback.COMMIT: Al terminar el bloque trans {....}COMMIT: Al ejecutar un break o un continueROLLBACK: al ejecutar tabort y al fallar.

Lenguaje O++ (3)

Operaciones de abrir / cerrar BDs#include <ode.h>......main () {

• database * db;• .......• if ((db = database::open(“nombre_BD”)) = =

NULL)• cout “Error al abrir la BD nombre_BD”<<endl;• else {...... trans {..................} ..........};• db->close(); }

Lenguaje O++ (4)

Lenguaje de preguntas for (“vars. que recorren clases”) (FROM)

[ suchthat (“condiciones”) ] (WHERE)

{ /* instrucciones C++ */ } (SELECT y +)

Ejemplos:for (pe in empleado) suchthat (pe->salario > 20000)

cout “Nombre:” << pe->nombre;for (pp in all persona; pc in coche) suchthat

(strcmp(pp->pais,pc->pais)==0) { ....}for (pe in empleado) suchthat (pe-

>padre->edad() > 50) { .....}

Lenguaje O++ (5)

ODE proporciona listas persistentes (plist.h)

Es posible definir índices o hash.database::BuildIndex(“persona”,”persona::nombre”,

punt_db,1,BTREE_TYPE)Puede ser BTREE_TYPE o HASH_TYPEEl 1 significa índice único (0 si no es único).Existen funciones IndexDelete e IndexExists

NO SE INDICA EN LAS PREGUNTAS QUE SE USE UN ÍNDICE/HASH. LO DECIDE EL OPTIMIZADOR

Se pueden definir triggersSe pueden crear versiones de objetos.

Crítica a los SGBDOO: limitaciones

Lenguaje de preguntas: No son compatibles con ANSI-SQL No incluyen preguntas anidadas, union,

intersección, funciones de agregación, group by... No soportan creación de vistas (Como en SQL) No permiten que los usuarios controlen privilegios

En SQL se puede hacer GRANT, REVOKE,... No dejan cambiar clases dinámicamente (añadir

atrs...) En SQL se puede hacer ALTER TABLE ...

Crítica a los SGBDOO: limitaciones

Gen. los usuarios deben manejar los locks (transacc.)

Capacidades limitadas para hacer “tuning” de la BD

Distintos OIDs en distintas BDOOs Relacional: operaciones cerradas (resultados son

rel.)OO: operaciones sobre clases dan cjtos de OIDs !!!

Crítica a los SGBDOO: mitos

Los SGBDOO son mucho más rápidos que los relacionales En realidad sucede si la aplicación navega entre

objetos (OIDs) que están cargados en memoria principal.

Se elimina la necesidad de ejecutar joins No eliminan. Reducen el nº de joins (al navegar por

atributos) Se elimina la necesidad de usar claves. (No, DNI

es clave)

Crítica a los SGBDOO: mitos

No se necesitan lenguajes asercionales. No, eso viene porque al principio NO OFRECÍAN dichos lenguajes!

El procesamiento de preguntas viola encapsulación Acceder atributo [pepe.nombre] vs. método

[pepe.get_nom()]Pueden soportar mejor versiones y transacciones de

larga duración. No, en BD relac. no se ha tratado lo suficiente.

Soportan datos multimedia. En principio mejor que con relacionales. Quedan muchas cuestiones que resolver.

Bases de Datos Distribuidas(BDD)

BD Distribuidas

Tecnología de Bases de Datos (tradicional) Centralización de datos

Varios Ficheros Una Base de Datos

Redes de Computadores Distribución/compartición de recursos

BD centralizada BD distribuida (¿varias BDs?)

BD Distribuidas: unión de estas dos aproximaciones (aparentemente opuestas) La tecnología de BD busca la INTEGRACIÓN de los

datos y no la CENTRALIZACIÓN

Definición de BD Distribuida

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

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

Definición de BD Distribuida

No son Sistemas de BD Distribuidas: Un sistema de ordenador de tiempo

compartido Un sistema de multiprocesadores (BD

Paralelas) Un 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.

Transparencia en entornos Distribuidos

Transparencia de red el usuario no debe ser consciente del uso de la red transparencia de localización: dónde están los datos, lenguajes

“locales” necesarios transparencia de nombres: nombres únicos en todo el sistema

distribuido, independientes de la localización

Transparencia de fragmentación el usuario no debe ser consciente de la existencia de varios

depósitos de datos

Transparencia de replicación el usuario no debe ser consciente de la existencia de varias

copias de los datos

Ventajas de las BDD (I)

La distribución puede ser la organización más natural

Mayor fiabilidad y disponibilidad (puede haber replicación)

Autonomía local (establecer políticas locales de acceso a datos)

Más eficiencia al acceder a los datos locales (frente a una centralizada)

Ventajas de las BDD (y II)

Economía (mejor varios PCs en red que un mainframe)

Más posibilidades de expansión (añadir más recursos a la red)

Compartición de datos (debido a que se encuentran en red)

Desventajas de las BDD

Falta de experiencia en el diseño de SBDDComplejidad

todos los problemas de las BD centralizadas y otros)

Costo (hardware / software de comunicaciones)Distribución de control

también era ventaja: autonomía)

Seguridad se añaden los problemas de seguridad en redes

Dificultad de cambio las empresas ya tienen BD centralizadas

Factores que influyen en las arquitecturas de BDDs (I)

Distribución Una BD es distribuida si esta dividida en

distintos componentes (integrados) BDD <> varias BDs no integradas Los componentes distribuidos que constituyen

una BD distribuida son a su vez bases de datos (BDs componentes o locales)

Las BDs componentes tendrán un grado de autonomía local determinado

Factores que influyen en las arquitecturas de BDDs (II)

AutonomíaTipo de control que los SGBD tienen sobre cada BD local

Autonomí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.

Autonomía de comunicación: si se puede decidir localmente cuándo comunicarse con los otros SGBD locales.

Autonomía de ejecución: si se pueden ejecutar transacciones globales y locales en el orden en que se quiera.

Autonomía de participación: si puede decidir cómo participar en el sistema distribuido.

Factores que influyen en las arquitecturas de BDDs (III)

Heterogeneidad Distinto hardware, SO, software comunicaciones. Distinto modelo de datos (rel., jerárquico, red, OO,..) Distintos SGBDs (aunque sean del mismo modelo) Heterogeneidad semántica (aun con el mismo SGBD)

sinonimia: elementos iguales con distintos nombreshomonimia: elementos distintos con igual nombreotras relaciones semánticas (hiperonimia, hiponimia,

agregación, etc,…)el mismo elemento del mundo real puede ser representado

como entidad o atributo, atributos con tipos diferentes, etc. Puede existir tanto a nivel intensional como extensional

Factores que influyen en las arquitecturas de BDDs (y IV)Existencia o no de esquema global

Si 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

En el esquema global se sabrá que VUELOREAL está en BD1 y BILLETES en BD2 pero es transparente al usuario

Si no, se necesita un lenguaje de acceso a distintas BDs.– SELECT *– FROM BD1@VUELOREAL, BD2@BILLETES– WHERE VUELOREAL.ID=BILLETES.ID

Arquitecturas de BD distribuidas

Sistemas de BDs Distribuidas (SBDD) Formados por BDs no autónomas. Proporcionan un esquema global. El esquema global se obtiene de arriba a abajo: primero se define el esquema

conceptual global y luego se fragmenta en varias BDs.

Sistemas de BDs Interoperantes (SBDI) Formados por BDs autónomas. No proporcionan esquema global sino lenguajes de acceso a BDs. El usuario es consciente de que trabaja con varias BDs.

Sistemas de BDs Federadas (SBDF) Formados por BDs autónomas. Proporcionan un esquema global. El 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.

Diseño de BDs Distribuidas

Hay que decidir en qué nodos deben residir los datos Diseño de BDs Distribuidas En los SBDF no se hace porque las BDs ya

existen. Hay que integrarlas para obtener el esquema global

En los SBDD, tras obtener el esquema conceptual global se debe fragmentar y asignar

Y donde residirán las aplicaciones que trabajan con los datos

Diseño de BDs Distribuidas

Es necesario un sistema de gestión de BD Distribuidas que realice lo siguiente: procesamiento de preguntas mantenimiento de la consistencia si hay

replicación de datos control de transacciones etc...

En algunos casos (determinados SBDD, SBDI) se podrá comprar, pero no siempre (SBDF)

Diseño top-down de BDD

Esquema Global Información de Acceso(transacciones)

FRAGMENTACIÓN

Esquema Local 1 Esquema Local N

Esquema Físico 1 Esquema Físico N

DISEÑO FÍSICODISEÑO FÍSICO

ASIGNACIÓN

Esquema Global Fragmentado

Fragmentación (I)

El problema de obtener los esquemas locales a partir del global se divide en dos: Fragmentación: dividir el esquema global en fragmentos. Asignación: distribuir los fragmentos entre los esquemas

locales.

El fragmento es la unidad a distribuirpuede ser parte de un tabla o un cjto. de ellas.ventaja: incrementa el nivel de concurrencia de

transacciones.desventaja: algunas transacciones se degradarán si tienen

que trabajar con varios fragmentos.

Fragmentación (II)

Fragmentación vertical: basada en encontrar conjuntos de atributos a proyectar

Fragmentación horizontal: basada en encontrar condiciones de selección

Fragmentación híbrida (y III)

Primero horizontal

... y luego vertical a cada fragmento

Corrección de la fragmentación

Completitud Todo elemento de la relación debe estar en

alguno de los fragmentos.Reconstrucción

La relación inicial debe poder reconstruirse aplicando operadores sobre los fragmentos

Intersección vacía (disjointness) Intersecció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)

Asignación (I)

Asignar fragmentos a los esquemas locales Sin replicación: todo fragmento reside en un

único nodobueno para actualizaciones, malo para preguntas

Con replicación total: todos los fragmentos residen en todos los nodosbueno para preguntas, malo para actualizaciones

Con replicación parcial: algunos fragmentos pueden residir en más de un nodo compromiso entre actualizaciones y preguntas

Asignación (y II)

PROCESAMIENTODE PREGUNTAS

CONTROL DECONCURRENCIA

DISPONIBILIDADDE LOS DATOS

REPLICACIÓNCOMPLETA

REPLICACIÓNPARCIAL

SINREPLICACIÓN

Más fácil Más difícil Más difícil

Difícil Más difícil Más fácil

Muy alta Alta Baja

Formulación del problema de la asignación

Dados N fragmentos y M nodos, encontrar la matriz X (Xij = true) el fragmento i se aloja en el nodo j

tal que minimiza el costo totalsuma 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

sujeto a las siguientes restricciones:tiempo de respuesta máximo para cada preguntaexiste un almacenamiento máximo en cada nodono 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...

Esquema Local N en un modelo canónico

Esquema Local 1 Esquema Local N

Esquema Local 1 en un modelo canónico

TRADUCCIÓN TRADUCCIÓN

INTEGRACIÓN

Esquema Global en un modelo canónico

Diseño bottom-up de BDD

Obtención del Esquema Global (I)

El problema de obtener un esquema global a partir de N esquemas locales se divide en dos: Traducción: cada esquema local se traduce a

un modelo canónico Integración: los esquemas locales se integran

en uno soloEste es un tema de investigación. Todavía

no resuelto por productos comerciales

Modelo canónico

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

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

Traducción A partir de tablas y atributos relacionales (esquema exportado) se

identifican entidades, relaciones y atributos (enriquecimiento semántico)

Pueden aparecer nuevas entidades (especializaciones/generalizaciones, etc.)

Integración Aplicació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.)

Uso del esquema global

Procesamiento de preguntas Las preguntas realizadas sobre el esquema

global deben responderse sobre los esquemas locales

Información de enlace Relación entre los elementos de datos del

esquema global y los elementos de datos de los esquemas locales

Necesaria para poder responder a las preguntas

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

Transacciones en BDDs: protocolo de commit en 2 fases

Se desea ejecutar una transacción T compuesta por varias transacciones T1, ... Tn sobre varias BDs: BD1,...BDn. Para ejecutar un COMMIT global:

Fase de votación Cada transacción Ti no hace COMMIT sino que dice al

nodo coordinador si puede hacerlo y espera a que éste le conteste

Fase de decisión Si todas las Ti 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

Bases de Datos Activas

BD Activas: Motivación

Los SGBD convencionales son “pasivos”. Sólo ejecutan preguntas o transacciones realizadas por los usuarios o por los programas de aplicación.

Para representar la semántica del mundo real proporcionan: MODELO DE DATOS

Estructuras de DatosOperadores para trabajar con las estructurasReglas de integridad

MODELO DE TRANSACCIONESPosibilidad de definir transacciones pero sólo si los usuarios o

aplicaciones lo solicitan explícitamente

BD Activas: Motivación (2)Los SGBD “pasivos” NO SON BUENOS para modelar

comportamiento dirigido por sucesos. Ejemplo: si el stock de un producto baja de un cierto umbral entonces

solicitar más. Para implementarlo: 1) 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. La semántica está distribuida por las aplicaciones.Posiblemente es una fuente de errores.

2) Realizando un programa que periódicamente “sondee” todas las condiciones (¿ stock(i) < umbral(i) ?)Frecuencia de sondeo alta --> INEFICIENCIAFrecuencia de sondeo baja --> INCONSISTENCIAS

BD Activas: Definición y Modelo de Conocimiento

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

El comportamiento deseado se expresa en forma de Reglas Evento-Condición-Acción (ECA)

ON evento IF condiciónTHEN acción

Nota: 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)

Modelo de Conocimiento

ON evento IF condición THEN acción evento puede ser un suceso primitivo:

ocurre una operación con la BD (insert, ...)comienza / termina una transacción (commit,..)suceso externo: bajada de tensiónsuceso temporal: es primer día de messuceso abstracto: violada una regla de integridad

o un suceso compuesto:S1 OR S2 (sucede el suceso S1 o el S2)S1 AND S2 (suceden ambos sucesos)S1 ; S2 (sucede S1 y después S2)

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.

Modelo de Ejecución

Es el comportamiento de las reglas en tiempo de ejecución. Se debe conocer: 1) Cuándo se evalúan los eventos (la frecuencia, si se evalúan

dentro de transacciones, etc.)Durante la ejecución de una transacción puede haber momentos en los que

la BD está inconsistente

2) A qué reglas ECA se les evalúa antes la condición de entre las activadas por los eventos

¿Los eventos que ya han activado reglas pueden seguir activando otras? Ej: el evento “es el primer día del mes”

3) Qué regla ECA se ejecutará la primera de entre las que cumplen la condición.

Relacionado con el problema del conjunto conflicto detectado por el motor de inferencia en S. Expertos

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

Triggers en ORACLE 7 (2)

OR REPLACE --> Reemplaza el trigger si ya existe BEFORE/AFTER DELETE, INSERT, ... ON tabla

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

FOR EACH ROW indica que se ejecute la acción (si se cumple la condición) para cada tupla insertada, borrada,...

WHEN --> 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

El bloque PL/SQL es la parte acción que ORACLE ejecuta cuando se produce el evento y se cumple la condición

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;

Restricciones en triggers Oracle

El bloque PL/SQL que forma la parte acción no puede contener sentencias como COMMIT o ROLLBACK (ni CREATE..., ALTER...)

No 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 !!

Dentro 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. Una 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. Una tabla restringida es aquella que es usada dentro de un trigger, por una sentencia SQL o

para mantener una integridad referencial. Una 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).

Consejos sobre Triggers Oracle

No definir triggers para definir restricciones de integridad que es posible definir de manera declarativa como REFERENCES, atributos NOT NULL, UNIQUE, etc. Sí pueden servir para implementar los

siguientes (no soportados todavía por Oracle)ON DELETE / UPDATE SET NULL, ON DELETE / UPDATE SET DEFAULT

No construir triggers recursivos.

Bases de Datos Deductivas

BD Deductivas: Motivación

La lógica como lenguaje de preguntas. Los predicados corresponderían a relaciones.

vuelo(1,‘Madrid’,’París’,’13:30’,’15:30’). Las reglas corresponderían a defs. de vistas.

vuelo_Mad_tarde(N,S,L,HS,HL) :- vuelo(N,’Madrid’,L,HS,HL), HS > ‘14:00’.

La conjunción de predicados a demostrar serían las preguntas.:- 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

Lógica como leng. de preguntas SELECCIÓN

vuelo_mediodia(N,S,L,HS,HL):- vuelo(N,S,L,HS,HL),HS>=‘12:00’,HL<=‘15:00’.

PROYECCIÓN num_vuelo(N) :- vuelo(N,_,_,_,_).

JOIN vuelo_inf_completo(N,S,L,HS,HL,Fec,Av,Pr):-

vuelo(N,S,L,HS,HL),vueloreal(N,Av,Fec,Pr) Combinación de los operadores del álgebra relacional.

num_vuelo_barato(N) :- vuelo(N,_,_,_,_),vueloreal(N,_,_,P),P<10000

Se parece al lenguaje relacional QBE (Query By Example)

Lógica es más potente que QBE

Ya que permite definir vistas recursivas vuelo_compuesto(S,L):-vuelo(_,S,L,_,_). vuelo_compuesto(S,L):-

vuelo(_S,L1,_,_),vuelo_compuesto(L1,L). Nota: falta controlar que no se produzcan ciclos

En QBE y en SQL no se pueden definir preguntas recursivas. Para obtener todos los vuelos compuestos

hay que escribir un programa (LP + SQL embebido)

Bases de Datos Deductivas

Lenguajes de Programación de BD: BD + LP Orientación a Objetos: BD + OO = BDOO Programación Lógica: BD + PL = BDD

Varias aproximaciones Extender PROLOG para que incluya

capacidades de BDs (persistencia, concurrencia,...)

Extender los sistemas de BDs para que incluyan capacidades de deducciónañadir un operador de clausura transitiva

Realizar SGBDD desde cero. Ej: DATALOG

¿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 SQL3SGBD Relacionales + Actividad - Triggers ya existen en algunos SGBD - Def. SQL3 intenta estandarizarSGBD Cliente/Servidor y DistribuidosTal vez SGBD Relacionales + Deduct.?

N. Boehr

En cualquier caso...

gracias por aguantarme

y suerte...