Transcript BDA
Bases de Datos Avanzadas
Eduardo Mena
D.0.17, tutorías 13:00-15:00 (M, X, J)
[email protected]
http://www.cps.unizar.es/~mena/
Bloque asignaturas BDs
Asignaturas
Ficheros y BD (troncal)
Diseño de BD Relacionales (opt.)
BD Avanzadas (opt.)
Sistemas de Información (opt.)
Interacción Hombre-Máquina (opt.)
FBD
DBDR
IHM
BDA
Problemas detectados
DBDR debería ser troncal
• el diseño de BDs es fundamental para un informático
• proyección laboral
Interacción Hombre-Máquina poco relacionada
con BDs
SI
¿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ón
con otras materias
Ficheros
son TADs: implementación de operaciones: funciones
hash, índices (árboles B,...). Interesante estudiar la
complejidad.
unidades mínimas de información en el SO.
Transacciones sobre BDs
Progr. concurrente (excl. mut, sinc)
Diseño de BDs Ingeniería del Software
BDA LPOO + SO + Redes + IA + ...
SI Redes + Web + IA + ...
BDA: Objetivos
SGBD relacionales otras alternativas
Conocer las tendencias futuras (I+D)
Desarrollo de prototipos en entornos
heterogéneos (y distribuidos)
Diseñar e implementar un sistema
multibase de datos
Saber aplicar todos nuestros
conocimientos a casos “reales”
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 eficientemente
Posible con lenguajes no procedurales (ej.
SQL)
leng. no procedural: se dice qué se quiere
obtener y no cómo obtenerlo (algoritmo, uso
de índices...)
sistemas con lenguajes procedurales: ej. IMS
(jerárquico) o CODASYL (en red)
Ejemplo motivador
La optimización es posible y necesaria
Las distintas estrategias requieren costes
muy distinto
Debe ser un proceso automático
depende del momento concreto en la vida de
la BD
es complicado saber qué estrategia es mejor
Nunca se esta seguro (estimaciones)
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 relacional
Salida: expr. álgebra relacional
equivalente
operaciones de idempotencia, propagar ctes.
operación selección se baja en el árbol
operación proyección se baja en el árbol
agrupar selecciones y proyecciones
Idea: reducir tamaño de las relaciones a
combinar con la operación join
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 costo
Cada plan se construye combinando el conjunto
de procedimientos candidatos posibles.
Calcular el costo es complicado hay que estimar
tamaños de resultados intermedios (estadísticas de
la BD, en el catálogo).
Calcular el orden óptimo de ejecución de joins
• N! posibilidades de ejecutar un join entre N relaciones
Evitar resultados intermedios (subir selecciones)
Usar heurísticos para reducir la búsqueda
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 que
1) cumplan los objetivos del sistema
2) proporcionen un balance óptimo entre el rendimiento
(tiempos de respuesta de transacciones, número de
transacciones por minuto...) y el costo (espacio utilizado,
reorganizaciones de datos...).
No existen metodologías para realizar el diseño
físico. Es muy dependiente del SGBD concreto.
Diseño Físico:
Recopilar información.
Por cada op. (preg. SQL) con la BD indicar:
Tipo: INSERT, SELECT, UPDATE, DELETE
Tablas que se van a acceder (cardinalidad)
Condiciones de selección (selectividad de cada una)
Condiciones de combinación-join (selectividad)
Atributos a ser proyectados / modificados
Frecuencia esperada de que se realice la operación.
Restricciones importantes de ejecución (si las hay)
Regla 80-20: El 80% del procesamiento se
realiza por el 20% de las transacciones.
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ías
Habrá redundancia pero estará controlada
Se evitará ejecutar joins (según las frecuencias def.)
Particionamiento horizontal
Si existe tabla R = sC1(R) U ... U sCn(R) donde
• muchas operaciones con la BD son con s Ci (R)
• algunos atributos son inaplicables (NULL) según Ci
• entonces cada s 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 sCi (R) es muy
frecuente, con Ci muy selectivo y R muy grande:
almacenar sCi (R) en una tabla S
• hay que controlar la redundancia / integridad (triggers)
– inconveniente: inserciones en S o R (ver frecuencias)
• los programas deberán usar la nueva tabla S
• si después se suprime tabla S --> crear vista para S
– para mantener indep. física. Esto sí es diseño físico !!
Particionamiento vertical
Si existe una tabla R (A1,...An,B1,...Bm) donde
muchas de las operaciones afectan sólo a atributos
A1,...,An y muy pocas veces a atributos B1,...Bm
esas operaciones son muy frecuentes
R(..Ai,...,Bj...) es mucho más grande que R(..Ai...)
Entonces almacenar R(...Ai...) en una tabla S
controlar redundancia / integridad. Fácil si hay
mecanismo de triggers. Si no, controlar la parte de las
aplicaciones que insertan / modifican R.
inconveniente: las inserciones en R(...Ai...). Hay que
valorar su frecuencia para ver si merece la pena.
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 inicial
Obtener información de las operaciones esperadas
Resolver operaciones con mayores restricciones
(aplicando algunos de los métodos explicados)
Resolver el resto de las opers. sin perjudicar a otras
• añadir índices para favorecer consultas perjudica a operaciones
de inserción / borrado
Replantearse continuamente dicho diseño
(Tunning)
analizar/auditar el sistema actual
tomar nuevas decisiones (añadir/borrar índices o tablas (crear
vistas y triggers si es necesario)
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 concurrencia
Sistemas multiusuario: ejecución intercalada
Recuperación
Para cuando una transacción falla
Vida de una transacción
Inicio
Lecturas/escrituras de elementos de la BD
Final (pueden hacer falta algunas verificaciones)
Confirmación (COMMIT) o anular (ROLLBACK)
Transacciones
Toda transacción debe cumplir el principio ACID
Atómica: se ejecuta todo (commit) o nada (rollback)
• Debe garantizarlo el método de recuperación del SGBD
Consistente: pasa de un estado consistente a otro
• Debe garantizarlo el programador y el SGBD (restr. int.)
aIslada: no lee resultados intermedios de otras
transacciones que no han terminado
• Debe garantizarlo el método de control de concurrencia y el
programador (ej: usando protocolo bloqueo en 2 fases).
Duradera: si se termina con éxito (commit), los
cambios en la BD son estables aunque luego falle otra
• Debe garantizarlo el método de recuperación.
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 BD
el fichero LOG debe estar en memoria estable
Por cada operación se escribe un reg. en LOG
<comienza-transacción, numt>
<escritura, numt, id_dato, val_viejo, val_nuevo>
<lectura, numt, id_dato, valor>
<termina_transacción_con_éxito, numt>
<punto_comprobación, numt, numc>
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 vez
Hay 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 variable
operación lock_exclusivo(X): deja bloqueado al que
lo pide si otro ya tiene cualquier lock sobre X
operación lock_compartido(X): deja bloqueado al
que lo pide si otro ya tiene un lock exclusivo sobre X
operación unlock(X): libera su lock sobre X
Antes de leer X lock_compartido(X)
Antes de escribir (leer) X lock_exclusivo(X)
Si no se va a leer o escribir más unlock(X)
Protocolo de
Bloqueo en dos fases
Una transacción sigue el protocolo de
bloqueo en dos fases si nunca hace un lock
después de haber hecho algún unlock.
Fase de crecimiento: se solicitan locks
Fase de devolución: se realizan unlocks
Solamente este protocolo de bloqueo
garantiza la serializabilidad de transacciones
Sin embargo, existe riesgo de deadlock !!
Prevención de deadlocks
Detección y recuperación de deadlocks
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ón
No 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 Especiales
SQL embebido
Uso de un API
Tipos de API
ODBC. Drivers
Bases de datos en la Web
Acceso Básico
Normalmente suministrado por el SGBD y
sus aplicaciones adjuntas
Puede no existir. SGBOO
Prompt (SQL). Oracle: SQL-Plus
4GL. Informix, Oracle (PL/SQL)
Forms, reports, menus
Entornos completos. MS Access
SQL Embebido
Lenguaje de Programación Host
Preprocesador + Librerias = Programa
SQL estático vs. dinámico
Tipos de datos distintos. Equivalencias
Variables Host
Limitaciones (¿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 Interface
Protocolos y funcionalidades
Tipos de API´s
Propietarios. Ej: OCI (Oracle Call Interface)
Interoperables
CLI (Call Level Interface)
ODBC (Open Data Base Connectivity).
IDAPI
ODBC
Desarrollado por Microsoft
NO es un protocolo de comunicación
Driver 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´s
Perdemos 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ón
Aplicaciones “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 1FN
las transacciones son generalmente cortas
Existen nuevas aplicaciones de BD
Aplicaciones de diseño: CAD, CASE,...
Ofimática
Sistemas de Información Geográfica (GIS)
BD multimedia
Sistemas 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 datos
interfaces (simil. a hojas de cálculo) para ver datos
generadores de informes
facilidades para escribir SQL embebido desde LP
SQL embebido (a utilizar desde un Leng. Prog.)
Definir tipos, conocidos por el SGBD distintos a LP
Conexión a la BD
Captura de excepciones (errores)
Seleccionar tuplas simples desde una BD
Seleccionar 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 impedance
con 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 entidades
Relaciones 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 + OO
Caracterí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 complejos
Un 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 objetos
Cada 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 EntidadRelació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-R
Normalizar 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én
persistent 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 continue
ROLLBACK: 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)
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_TYPE
El 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 triggers
Se 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 SBDD
Complejidad
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ía
Tipo 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 nombres
homonimia: elementos distintos con igual nombre
otras 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 Global Fragmentado
ASIGNACIÓN
Esquema Local 1
Esquema Local N
DISEÑO FÍSICO
DISEÑO FÍSICO
Esquema Físico 1
Esquema Físico N
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 distribuir
puede 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 horizontal: basada en
encontrar condiciones de selección
Fragmentación vertical: basada en encontrar
conjuntos de atributos a proyectar
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 nodo
bueno para actualizaciones, malo para preguntas
Con replicación total: todos los fragmentos
residen en todos los nodos
bueno 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)
REPLICACIÓN REPLICACIÓN
SIN
COMPLETA
PARCIAL REPLICACIÓN
PROCESAMIENTO
DE PREGUNTAS
Más fácil
Más difícil
Más difícil
CONTROL DE
CONCURRENCIA
Difícil
Más difícil
Más fácil
DISPONIBILIDAD
DE LOS DATOS
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 total
suma 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 pregunta
existe un almacenamiento máximo en cada nodo
no 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...
Diseño bottom-up de BDD
Esquema Global en
un modelo canónico
INTEGRACIÓN
Esquema Local 1 en
un modelo canónico
Esquema Local N en
un modelo canónico
TRADUCCIÓN
TRADUCCIÓN
Esquema Local 1
Esquema Local N
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 solo
Este 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 EntidadRelació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
Esquema Global
Pregunta en álgebra relacional sobre relaciones distribuidas
LOCALIZACIÓN DE DATOS
Esquema
de Fragmentos
Pregunta sobre fragmentos
Estadísticas sobre
Fragmentos
Pregunta sobre fragmentos y operaciones de comunicación
OPTIMIZACIÓN GLOBAL
OPTIMIZACIÓN LOCAL
Preguntas locales optimizadas
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 Datos
Operadores para trabajar con las estructuras
Reglas de integridad
MODELO DE TRANSACCIONES
Posibilidad 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 --> INEFICIENCIA
Frecuencia 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ón
THEN 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ón
suceso temporal: es primer día de mes
suceso 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
EVENTO
[ [REFERENCING { OLD [AS] old [NEW [AS] new]
| NEW [AS] new [OLD [AS] old] } ]
[FOR EACH ROW
[WHEN (condición)] ]
bloque_PL/SQL
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ón
añadir un operador de clausura transitiva
Realizar SGBDD desde cero. Ej: DATALOG
¿Y cuál es el
futuro de los
SGBD?
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.?
Es difícil predecir...
...especialmente el futuro
N. Boehr
En cualquier caso...
gracias por aguantarme
y suerte...