Bases de Datos Avanzadas

Eduardo Mena

D.0.17, tutoras 13:00-15:00 (M, X, J)

emena@posta.unizar.es
http://www.cps.unizar.es/~mena/

Bloque asignaturas BDs

Asignaturas

Ficheros y BD (troncal)
Diseo de BD Relacionales (opt.)
BD Avanzadas (opt.)
Sistemas de Informacin (opt.)
Interaccin Hombre-Mquina (opt.)

FBD
DBDR

IHM
BDA

Problemas detectados
DBDR debera ser troncal
el diseo de BDs es fundamental para un informtico
proyeccin laboral

Interaccin Hombre-Mquina poco relacionada

con BDs

SI

Cmo enfocar el aprendizaje ?

Teora de BDs vs. Profundizar en un SGBD

concreto

DISEO CONCEPTUAL --> Indpte. modelo y SGBD

DISEO LGICO --> Dpte. modelo e indpte. SGBD
DISEO FSICO --> Dpte. SGBD (+/- reglas generales)
Por supuesto: administracin 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 Programacin en pseudocdigo vs. Lenguaje

de programacin concreto

Repeticin / Relacin
con otras materias
Ficheros
son TADs: implementacin de operaciones: funciones
hash, ndices (rboles B,...). Interesante estudiar la
complejidad.

unidades mnimas de informacin en el SO.

Transacciones sobre BDs

Progr. concurrente (excl. mut, sinc)
Diseo de BDs Ingeniera 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
heterogneos (y distribuidos)
Disear e implementar un sistema
multibase de datos
Saber aplicar todos nuestros
conocimientos a casos reales

BDA: Evaluacin
50%: Examen terico-prctico (40%, 60%)
No hay que empollar

50%: Prctica

Libertad de diseo
Heterogeneidad
Imaginacin
Autosuficiencia

Hay que aprobar ambas pruebas

Optimizacin de
Preguntas

Optimizacin de preguntas
Optimizacin: 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 cmo obtenerlo (algoritmo, uso
de ndices...)
sistemas con lenguajes procedurales: ej. IMS
(jerrquico) o CODASYL (en red)

Ejemplo motivador
La optimizacin es posible y necesaria
Las distintas estrategias requieren costes
muy distinto
Debe ser un proceso automtico
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 optimizacin
Convertir la pregunta en una representacin
interna (lgebra relacional, rbol sintctico)
Transformar la pregunta en una forma
cannica (reglas sintcticas y semnticas)
Escoger los procedimientos de bajo nivel
candidatos (para cada operador)
ndices? clustering? rango y nm. valores?

Generar los planes y escoger el ms barato

usar heursticos para reducir bsqueda

Optimizacin sintctica
Entrada: expresin lgebra relacional
Salida: expr. lgebra relacional
equivalente

operaciones de idempotencia, propagar ctes.

operacin seleccin se baja en el rbol
operacin proyeccin se baja en el rbol
agrupar selecciones y proyecciones
Idea: reducir tamao de las relaciones a
combinar con la operacin join

Optimizacin semntica
Transformar la pregunta en otra que
devuelve las misma tuplas
Utilizar conocimiento semntico de la BD
restr. integridad, dependencias funcionales,
claves extranjeras, reglas semnticas

En general, la opt. sem. es un proceso

caro, por lo que los SGBD comerciales no la
aplican. Se suele basar en tcnicas de Int.
Artificial.

Optimizacin fsica: Seleccin

Algoritmos
Bsqueda lineal
Bsqueda binaria
Empleo de ndices (de distintos tipos)

Selectividad de una condicin

% de la relacin que satisface la condicin
Ejecutar primero las selecciones de mayor
selectividad

Optimizacin fsica: 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 relacin
Hash-Join

Optimizacin fsica: otras op.

Proyecciones: fcil de implementar (hay
que recorrer todas las tuplas)
Producto cartesiano: muy costosa
Evitarla

Unin, Interseccin, Diferencia

Primero se ordenan las dos relaciones

Generar los planes y escoger

el ms 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
tamaos de resultados intermedios (estadsticas de
la BD, en el catlogo).
Calcular el orden ptimo de ejecucin de joins
N! posibilidades de ejecutar un join entre N relaciones

Evitar resultados intermedios (subir selecciones)

Usar heursticos para reducir la bsqueda

Optimizacin del costo:

CPU + I/O + COM
BD centralizadas
generalmente se tiene en cuenta slo costo I/O

BD distribuidas en Redes Area Amplia (WAN)

generalmente, slo 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.

Optimizacin en Oracle
Optimizacin basada en reglas o basada
en costes (seleccionado por el usuario)
EXPLAIN PLAN: ver como se ejecutar una
sentencia SQL
No hay optimizacin semntica
hasta Oracle 8, incluido

Se puede influir en el uso o no de ndices

(no recomendado)

Conclusiones
Los SGBD realizan optimizacin de preguntas
son intiles algunas reformulaciones de preguntas

Algunas optimizaciones (todava) no son realizadas

por los SGBD (ej. optimizacin semntica)
hay que reformular algunas preguntas

El proceso de optimizacin de preguntas es

complejo y cada SGBD lo hace distinto.
hay que consultar el manual del SGBD concreto.

Es necesario conocer cmo se procesan las

preguntas para realizar el DISEO FSICO.
cundo es til usar ndices o hash o no utilizarlos.
saber que el join es costoso --> reducir nmero de joins.

Diseo Fsico

Diseo Fsico
El diseo fsico 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, nmero de
transacciones por minuto...) y el costo (espacio utilizado,
reorganizaciones de datos...).

No existen metodologas para realizar el diseo

fsico. Es muy dependiente del SGBD concreto.

Diseo Fsico:
Recopilar informacin.
Por cada op. (preg. SQL) con la BD indicar:

Tipo: INSERT, SELECT, UPDATE, DELETE

Tablas que se van a acceder (cardinalidad)
Condiciones de seleccin (selectividad de cada una)
Condiciones de combinacin-join (selectividad)
Atributos a ser proyectados / modificados
Frecuencia esperada de que se realice la operacin.
Restricciones importantes de ejecucin (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 cdigos que toman
valores numricos 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.

Desnormalizacin
El proceso de normalizacin consiste en dividir una
tabla R en R1 y R2 si R=R1
R1.K=R2.K R2
Evita redundancia y anomalas (ins./bor./mod.)
Problema: Para obtener R hay que hacer el join

Si (casi) siempre que se recuperan los valores de

R1 se utilizan tambin los de un mismo atributo(s)
R2.Atr, entonces se puede aadir el atributo R2.Atr
a la tabla R1 --> (No estara en 3FN!!)
Hay que controlar que no haya anomalas
Habr redundancia pero estar controlada
Se evitar ejecutar joins (segn 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) segn Ci
entonces cada s Ci (R) se guarda en una tabla y se define una
vista sobre R (diseo lgico? fsico?)

En general si una operacin 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 debern usar la nueva tabla S
si despus se suprime tabla S --> crear vista para S
para mantener indep. fsica. Esto s es diseo fsico !!

Particionamiento vertical
Si existe una tabla R (A1,...An,B1,...Bm) donde
muchas de las operaciones afectan slo a atributos
A1,...,An y muy pocas veces a atributos B1,...Bm
esas operaciones son muy frecuentes
R(..Ai,...,Bj...) es mucho ms grande que R(..Ai...)

Entonces almacenar R(...Ai...) en una tabla S

controlar redundancia / integridad. Fcil 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 relacin 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 algn Ri
o bien 2) Ejecutando peridicamente algunos scripts (ej. a las
noches). Se puede si no es obligatorio que la consulta devuelva
los valores ms actuales.

Valorar: frecuencia de cambios en Ri, tamao del

resultado, tiempo de ejecucin de la consulta inicial

Organizacin fsica 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). Slo 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 seleccin

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

nmero mnimo 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 diseo fsico inicial
Obtener informacin de las operaciones esperadas
Resolver operaciones con mayores restricciones
(aplicando algunos de los mtodos explicados)
Resolver el resto de las opers. sin perjudicar a otras
aadir ndices para favorecer consultas perjudica a operaciones
de insercin / borrado

Replantearse continuamente dicho diseo

(Tunning)

analizar/auditar el sistema actual

tomar nuevas decisiones (aadir/borrar ndices o tablas (crear
vistas y triggers si es necesario)

Transacciones,
Recuperacin y Control de
Concurrencia

Transacciones
Transaccin: coleccin de operaciones que forman
una nica unidad lgica de trabajo en una BD
Control concurrencia
Sistemas multiusuario: ejecucin intercalada

Recuperacin
Para cuando una transaccin falla

Vida de una transaccin

Inicio
Lecturas/escrituras de elementos de la BD
Final (pueden hacer falta algunas verificaciones)
Confirmacin (COMMIT) o anular (ROLLBACK)

Transacciones
Toda transaccin debe cumplir el principio ACID
Atmica: se ejecuta todo (commit) o nada (rollback)
Debe garantizarlo el mtodo de recuperacin 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 mtodo 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 mtodo de recuperacin.

Recuperacin
Cadas del sistema durante una transaccin
Errores de ejecucin: overflow, divisin por 0...
Errores lgicos que violan alguna regla de
integridad (definida explcitamente o no) y que
dejan inconsistente la BD -> programador/ABD
Problemas de concurrencia de transacciones
Fallos de lectura/escritura en disco
Problemas fsicos y catstrofes: fuego, robos,
sabotajes, fallos humanos,... --> medidas de
seguridad informtica en la empresa.

Recuperacin
Para que el sistema se pueda recuperar ante fallos
se necesita grabar cada operacin con la BD en un
fichero LOG (bitcora). Checkpoints.
se escribe en el fichero LOG antes que en la BD
el fichero LOG debe estar en memoria estable

Por cada operacin se escribe un reg. en LOG

<comienza-transaccin, numt>
<escritura, numt, id_dato, val_viejo, val_nuevo>
<lectura, numt, id_dato, valor>
<termina_transaccin_con_xito, numt>
<punto_comprobacin, numt, numc>

Problemas de concurrencia
La ejecucin concurrente de transacciones
puede dar lugar a problemas:
Problema de la actualizacin perdida
Problema de leer una actualizacin temporal
(lectura sucia)
Problema del resumen incorrecto
Problema de la lectura no repetible

Problemas de Concurrencia
Sol. trivial: cada transaccin se ejecuta en
exclusin mutua. Cul sera la granularidad?
BD? Tabla? Tupla? Atributo?
La solucin trivial no es vlida: 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 exclusin 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 ejecucin concurrente de las

transacciones sera:
Ej: O11, O21, On1, On2, O12, O22, , O1 m1, O2 m2, , On mn
Una intercalacin 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.
Solucin: Imponer restricciones a la libre
intercalacin de operaciones entre transacciones
Tcnicas pesimistas: se impide realizar ciertas
operaciones si son sospechosas de producir planes no
serializables: BLOQUEOS (lock) y MARCAS DE
TIEMPO (time-stamping)
Tcnicas optimistas: no imponen restricciones pero
despus se comprueba si ha habido interferencias

Tcnicas de bloqueo (lock)

A cada elemento de datos o grnulo X de la BD
se le asocia una variable
operacin lock_exclusivo(X): deja bloqueado al que
lo pide si otro ya tiene cualquier lock sobre X
operacin lock_compartido(X): deja bloqueado al
que lo pide si otro ya tiene un lock exclusivo sobre X
operacin 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 ms unlock(X)

Protocolo de
Bloqueo en dos fases
Una transaccin sigue el protocolo de
bloqueo en dos fases si nunca hace un lock
despus de haber hecho algn unlock.
Fase de crecimiento: se solicitan locks
Fase de devolucin: se realizan unlocks

Solamente este protocolo de bloqueo

garantiza la serializabilidad de transacciones
Sin embargo, existe riesgo de deadlock !!
Prevencin de deadlocks
Deteccin y recuperacin de deadlocks

Deadlocks
Deadlock (o abrazo mortal o interbloqueo): cuando una transaccin
T1 est bloqueada esperando a que otra T2 libere un lock, la cual tambin
est bloqueada esperando a que T1 libere uno de sus lock. Se puede
generalizar para N transacciones.

Prevencin de deadlocks
Cada transaccin obtiene todos los locks al principio y si no puede entonces no
obtiene ninguno. Problema de livelock (inanicin de algunas transacciones que
pueden no obtener todos los que necesiten)
Los elementos de la BD estn ordenados de alguna manera y los lock hay que
obtenerlos en dicho orden. Los programadores deben controlarlo !!

Deteccin y recuperacin de deadlocks.

A medida que se piden y conceden los lock se construye un grafo de las
transacciones que estn 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!

Tcnicas de marcas de tiempo

(time-stamping)
Un timestamp es un identificador asignado a cada transaccin
TS(T). Indica la hora de comienzo de la transaccin T. A cada
elemento X de la BD se le asigna el timestamp de la ltima
transaccin que lo ha ledo (TS_lect(X)) y escrito (TS_escr(X))

Si una transaccin 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 transaccin 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):=mximo(TS(T),TS_lect(X))

Garantiza serializabilidad y ausencia de deadlocks.

Puede haber livelock (si se aborta siempre a la misma transaccin)

Tcnicas optimistas
No se realizan comprobaciones ANTES de ejecutar las
operaciones (pedir locks, comprobar timestamps), sino al
acabar toda la transaccin (fase validacin)
Durante la ejecucin de la transaccin se trabaja con
copias
Hay tres fases en un protocolo optimista:
Fase de lectura
Fase de validacin
Fase de escritura
Es bueno cuando no hay muchas interferencias entre
transacciones (por eso son optimistas)

Recuperacin en Oracle
Redo logs (cclicos)
Archive logs (consolidacin de redo logs)
Backups
Mirrors
Export: Incremental, acumulativo (coleccin de
incrementales), total

Recuperacin 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 transaccin, sin
impedir que otras transacciones los cambien.
Implcitamente con SELECT .. FROM T,R ... (lo
garantiza sobre las tuplas de T,R,...)
Explcitamente con SET TRANSACTION READ ONLY;
(lo garantiza sobre las tuplas de todas las tablas
hasta el fin de transaccin.)
Debe ser la primera instruccin de la transaccin
No permitir hacer ningn INSERT, DELETE o UPDATE en
dicha transaccin

Control de concurrencia en
ORACLE (2)
LOCKs
Explcitamente con LOCK TABLE T IN x MODE
x indica si sobre todas/algunas tuplas de T en
modo compartido/exclusivo)

Implcitamente con cada operacin (segn

clusula WHERE)
UPDATE, DELETE, INSERT. Se bloquean las tuplas
insertadas, borradas o actualizadas (al ser una
transaccin no finalizada)
SELECT...FROM T FOR UPDATE OF atr. Se
bloquean las tuplas seleccionadas

Control de concurrencia en
ORACLE (y 3)
No hay UNLOCK explcitos en ORACLE!!
Se realiza un UNLOCK implcito de todos los
LOCK con cada COMMIT o ROLLBACK
(implcitos o explcitos)

Pregunta: Cmo conseguir que las

transacciones en ORACLE sigan el
protocolo en dos fases, o lo que es lo
mismo, sean serializables?

Interaccin de
Aplicaciones con BDs

Interaccin de Aplicaciones
con Bases de Datos
Acceso bsico. Casos Especiales
SQL embebido
Uso de un API
Tipos de API
ODBC. Drivers

Bases de datos en la Web

Acceso Bsico
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 Programacin Host

Preprocesador + Librerias = Programa
SQL esttico vs. dinmico
Tipos de datos distintos. Equivalencias
Variables Host
Limitaciones (transacciones?, actividad?,
etc)

SQL Dinmico: Oracle

4 Mtodos: elegir siempre el ms sencillo
posible segn el caso
Mtodo 1 (no selects, no placeholders)
Ej: EXEC SQL EXECUTE delete from emp where
dpto=20

Mtodo 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 Dinmico: Oracle (2)

Mtodo 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

Mtodo 4 (sin restricciones)

Ej: select ???? from ???? where ??? ....

Uso de un API
API: Aplication Program Interface
Protocolos y funcionalidades
Tipos de APIs
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 comunicacin
Driver ODBC: programa que interactua
con un SGBD concreto y ofrece un API
segn los dictados ODBC.
Implementado con SQL embebido
Implementado con un API propietario

JDBC. Drivers JDBC. Driver JDBC-ODBC

Bases de datos en la Web

Pginas Web: puntos de interrogacin a
Bases de datos
Forms y CGIs
Perdemos el acceso directo al SGBD: no
disponemos de SQL !!!
Solucin: Encapsulacin. Acceso limitado
por el CGI.

Bases de Datos
Orientadas a Objetos
(BDOO)

BDOO: Motivacin
Aplicaciones tradicionales de BD donde
existen muchos datos almacenados en registros
(pocos tipos de registros) gen. de longitud fija con
campos atmicos (en 1FN) y de tamao pequeo
esquemas de BD casi no cambian y estn en 1FN
las transacciones son generalmente cortas

Existen nuevas aplicaciones de BD

Aplicaciones de diseo: CAD, CASE,...

Ofimtica
Sistemas de Informacin Geogrfica (GIS)
BD multimedia
Sistemas expertos de BD (manejar conocimiento)

BDOO: Motivacin (2)

Las nuevas aplicaciones de BD necesitan:
esquemas dinmicos
ms entidades distintas con probablemente
menos datos (ocurrencias) en dichas entidades
campos de longitud variable y que contengan
ms tipos de datos: grficos, sonidos, textos ...
meta conocimiento
distintas versiones de los datos
manejar transacciones largas

BDOO: Motivacin (3)

Tendencias nuevas (post-relacionales) en
investigacin. Triunfarn comercialmente?

Modelos semnticos de datos

Bases de datos histricas (temporales)
Bases de datos no en 1FN (multievaluacin)
Sistemas expertos de BD (integr. IA - BD)
Lenguajes de programacin de BD: DB + LP
BD deductivas: fusin leng. progr. lgica + 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 clculo) 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

Conexin a la BD
Captura de excepciones (errores)
Seleccionar tuplas simples desde una BD
Seleccionar varias tuplas (uso de cursores)
Ejecutar sentencias SQL dinmico (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 relacin 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
habra que guardarlos en tablas para darles persistencia .

con la estrategia de evaluacin

El LP hace una pregunta SQL, el SGBD obtiene la respuesta y
la guarda en un lugar intermedio para drsela al LP
(traducida). Tal vez ste NO PIDA MS 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 gustara poder definir

Entidades con sus propiedades (multivaluadas)

Generalizacin / Especializacin 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 aadir interfaces a los programas de BDs hay que
manipular otros tipos de objetos grficos 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
Caractersticas BD
Persistencia + Concurrencia + Transacciones +
Recuperacin + Lenguajes de Interrogacin /
Definicin / Manipulacin + Integridad +
Seguridad + Eficiencia (+ Versiones)

Caractersticas OO
Tipos Abstractos de Datos (TAD) + Herencia +
Identidad de Objetos
[TAD = Tipos + Operaciones + Encapsulacin]

Conceptos bsicos 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
mtodos) que corresponden a la definicin de la
CLASE de la cual el objeto es una INSTANCIA.
CLASE define unos ATRIBUTOS y MTODOS
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 bsicos OO (2)

Identidad de objetos (cont.)
A diferencia del modelo relacional puede haber
objetos distintos con los mismos valores.
Predicados de igualdad

o1 idntico 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 bsicos OO (3)

Encapsulacin
Cada objeto tiene una parte que constituye su
INTERFAZ y otra que constituye su
IMPLEMENTACIN.
Slo se puede acceder a cada objeto a travs
de su INTERFAZ, o lo que es lo mismo,
enviando rdenes para que ejecute MTODOS.
Excepcin: el procesador de preguntas s puede !!!

El objetivo es encapsular los DATOS y los

PROGRAMAS dentro de los OBJETOS.

Conceptos bsicos OO (4)

Diferencia entre tipos y clases
Un tipo define una estructura que se utiliza
para comprobar que no hay errores en tiempo
de compilacin. Todo valor de los que aparece
en un programa DEBE SER de algn tipo.
Una clase est formada por un tipo(s), unas
operaciones y un conjunto de instancias de
dicho tipo(s).
TAD = tipo + operaciones + encapsulacin
clase = TAD + herencia + cjto de instancias

Conceptos bsicos OO (5)

Herencia
Una clase A se puede definir como subclase de
otra clase B.
En ese caso, todos los atributos y mtodos de
la clase B son heredados por la clase A.
Algunos SGBDOO permiten herencia mltiple,
esto es, que una clase sea subclase de ms 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 bsicos OO (6)

Overloading (sobrecarga), overriding
(imposicin), late binding (asociacin 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 mtodo de un objeto, en tiempo de
ejecucin, se busca el cdigo 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 caractersticas de OO comentadas
(ver conceptos bsicos de OO).
Problema: las caractersticas de BD no se
conseguiran (ver definicin BDOO)
Intento de solucin: 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 caractersticas
BD siguen sin obtenerse
(ver definicin BDOO = BD + OO)
Lo peor: el lenguaje de interrogacin es
navegacional o procedural (es mejor el
del modelo relacional que es asercional)
Lo mejor: no hay mismatch impedance
ni el resto de problemas sealados en
(problemas modelo relacional).

Diseo de BDOO
Para disear BDs generalmente se usa un
modelo de BDs semntico llamado EntidadRelacin (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 corresponderan dichas tablas

Traducir el esquema E-R a un esquema OO

Traduccin E-R a OO
Las entidades y relaciones del E-R se
pueden traducir a clases y atributos OO.
Entidad -----> Clase
Entidad especializacin -----> Subclase
Relacin 1:1, 1:N --------> Atributo sobre Clase
Relacin 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 mtodos

Para atributos calculados, realizar tareas (imprimir..)

ODE: Un SGBDOO
ODE es un SGBDOO
Desarrollado en los laboratorios AT&T
Utiliza un lenguaje de programacin de BD
llamado O++ basado en C++
Otros SGBDOOs: GemStone, Iris, O2, ORION,
ObjectStore (basado en C++), Vbase.

O++ extiende C++ para incluir caractersticas

propias de BDs:
Persistencia, transacciones, lenguaje de preguntas...

Artculos ODE: ftp://research.att.com/dist/db

Lenguaje O++
Persistencia
Una clase C++ se puede declarar como
persistente. Apuntadores de objetos tambin
persistent class personas { .... }
persistent personas * pe;
Utilizamos el mtodo 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 implementacin de mtodos

Lenguaje O++ (2)

Transacciones
Se puede utilizar protocolo bloqueo en 2
fases
Toda interaccin con la BD debe ocurrir
dentro de la definicin de una transaccin.
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.

Crtica a los SGBDOO:

limitaciones
Lenguaje de preguntas:
No son compatibles con ANSI-SQL
No incluyen preguntas anidadas, union, interseccin,
funciones de agregacin, group by...
No soportan creacin de vistas (Como en SQL)
No permiten que los usuarios controlen privilegios
En SQL se puede hacer GRANT, REVOKE,...
No dejan cambiar clases dinmicamente (aadir atrs...)
En SQL se puede hacer ALTER TABLE ...

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

Crtica a los SGBDOO: mitos

Los SGBDOO son mucho ms rpidos que los
relacionales
En realidad sucede si la aplicacin navega entre objetos
(OIDs) que estn 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)

Crtica a los SGBDOO: mitos

No se necesitan lenguajes asercionales. No, eso viene
porque al principio NO OFRECAN dichos lenguajes!

El procesamiento de preguntas viola encapsulacin

Acceder atributo [pepe.nombre] vs. mtodo
[pepe.get_nom()]

Pueden soportar mejor versiones y transacciones de

larga duracin. 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
Tecnologa de Bases de Datos (tradicional)
Centralizacin de datos
Varios Ficheros

Una Base de Datos

Redes de Computadores
Distribucin/comparticin de recursos
BD centralizada

BD distribuida (varias BDs?)

BD Distribuidas: unin de estas dos

aproximaciones (aparentemente opuestas)
La tecnologa de BD busca la INTEGRACIN de
los datos y no la CENTRALIZACIN

Definicin de BD Distribuida
Un sistema de BD distribuidas es una
coleccin de varias BDs que se encuentran
lgicamente inter-relacionadas y
distribuidas sobre una red de ordenadores.
Un sistema de gestin de bases de datos
distribuidas (SGBDD) es el software que
permite el manejo de sistemas de BDs
distribuidas y que hace dicha distribucin
transparente al usuario.

Definicin 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 travs de la red.

Transparencia en entornos
Distribuidos
Transparencia de red
el usuario no debe ser consciente del uso de la red
transparencia de localizacin: dnde estn los datos, lenguajes
locales necesarios
transparencia de nombres: nombres nicos en todo el sistema
distribuido, independientes de la localizacin

Transparencia de fragmentacin
el usuario no debe ser consciente de la existencia de varios
depsitos de datos

Transparencia de replicacin
el usuario no debe ser consciente de la existencia de varias
copias de los datos

Ventajas de las BDD (I)

La distribucin puede ser la organizacin
ms natural
Mayor fiabilidad y disponibilidad (puede
haber replicacin)
Autonoma local (establecer polticas locales
de acceso a datos)
Ms eficiencia al acceder a los datos locales
(frente a una centralizada)

Ventajas de las BDD (y II)

Economa (mejor varios PCs en red que
un mainframe)
Ms posibilidades de expansin (aadir
ms recursos a la red)
Comparticin de datos (debido a que se
encuentran en red)

Desventajas de las BDD

Falta de experiencia en el diseo de SBDD
Complejidad
todos los problemas de las BD centralizadas y otros)

Costo (hardware / software de comunicaciones)

Distribucin de control
tambin era ventaja: autonoma)

Seguridad
se aaden los problemas de seguridad en redes

Dificultad de cambio
las empresas ya tienen BD centralizadas

Factores que influyen en las

arquitecturas de BDDs (I)
Distribucin
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 tendrn un grado de
autonoma local determinado

Factores que influyen en las

arquitecturas de BDDs (II)
Autonoma
Tipo de control que los SGBD tienen sobre cada BD local

Autonoma de diseo: 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.

Autonoma de comunicacin: si se puede decidir

localmente cundo comunicarse con los otros SGBD locales.

Autonoma de ejecucin: si se pueden ejecutar

transacciones globales y locales en el orden en que se quiera.

Autonoma de participacin: si puede decidir cmo

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., jerrquico, red, OO,..)
Distintos SGBDs (aunque sean del mismo modelo)
Heterogeneidad semntica (aun con el mismo SGBD)
sinonimia: elementos iguales con distintos nombres
homonimia: elementos distintos con igual nombre
otras relaciones semnticas (hiperonimia, hiponimia,
agregacin, 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 autnomas.
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 autnomas.
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 autnomas.
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.

Diseo de BDs Distribuidas

Hay que decidir en qu nodos deben residir
los datos Diseo 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 residirn las aplicaciones que

trabajan con los datos

Diseo de BDs Distribuidas

Es necesario un sistema de gestin de BD
Distribuidas que realice lo siguiente:
procesamiento de preguntas
mantenimiento de la consistencia si hay
replicacin de datos
control de transacciones
etc...

En algunos casos (determinados SBDD, SBDI)

se podr comprar, pero no siempre (SBDF)

Diseo top-down de BDD

Esquema Global

Informacin de Acceso
(transacciones)

FRAGMENTACIN

Esquema Global Fragmentado

ASIGNACIN

Esquema Local 1

Esquema Local N

DISEO FSICO

DISEO FSICO

Esquema Fsico 1

Esquema Fsico N

Fragmentacin (I)
El problema de obtener los esquemas locales a
partir del global se divide en dos:
Fragmentacin: dividir el esquema global en fragmentos.
Asignacin: 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 degradarn si
tienen que trabajar con varios fragmentos.

Fragmentacin (II)
Fragmentacin horizontal: basada en
encontrar condiciones de seleccin

Fragmentacin vertical: basada en encontrar

conjuntos de atributos a proyectar

Fragmentacin hbrida (y III)

Primero horizontal

... y luego vertical a cada fragmento

Correccin de la
fragmentacin
Completitud
Todo elemento de la relacin debe estar en
alguno de los fragmentos.

Reconstruccin
La relacin inicial debe poder reconstruirse
aplicando operadores sobre los fragmentos

Interseccin vaca (disjointness)

Interseccin de los fragmentos debe ser vaca
Nota: a excepcin de las claves (para poder reconstruir
la relacin inicial a partir de los fragmentos)

Asignacin (I)
Asignar fragmentos a los esquemas locales
Sin replicacin: todo fragmento reside en un
nico nodo
bueno para actualizaciones, malo para preguntas

Con replicacin total: todos los fragmentos

residen en todos los nodos

bueno para preguntas, malo para actualizaciones

Con replicacin parcial: algunos fragmentos

pueden residir en ms de un nodo
compromiso entre actualizaciones y preguntas

Asignacin (y II)
REPLICACIN REPLICACIN
SIN
COMPLETA
PARCIAL REPLICACIN
PROCESAMIENTO
DE PREGUNTAS

Ms fcil

Ms difcil

Ms difcil

CONTROL DE
CONCURRENCIA

Difcil

Ms difcil

Ms fcil

DISPONIBILIDAD
DE LOS DATOS

Muy alta

Alta

Baja

Formulacin del problema

de la asignacin
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 mximo para cada pregunta
existe un almacenamiento mximo en cada nodo
no superar la carga de procesamiento en cada nodo
El problema es NP-completo. Pero se pueden usar
heursticos: problema de la mochila, tcnicas de
ramificar y acotar, algoritmos genticos, etc...

Diseo bottom-up de BDD

Esquema Global en
un modelo cannico
INTEGRACIN

Esquema Local 1 en
un modelo cannico

Esquema Local N en
un modelo cannico

TRADUCCIN

TRADUCCIN

Esquema Local 1

Esquema Local N

Obtencin del
Esquema Global (I)
El problema de obtener un esquema
global a partir de N esquemas locales se
divide en dos:
Traduccin: cada esquema local se traduce a
un modelo cannico
Integracin: los esquemas locales se integran
en uno solo

Este es un tema de investigacin. Todava

no resuelto por productos comerciales

Modelo cannico
El modelo de datos (cannico) utilizado
para expresar el esquema global es muy
importante.
No hay que olvidar que las bases de datos
locales pueden ser heterogneas (distintos
modelos de datos)
Se utilizan modelos ms ricos
semnticamente que el relacional: OO,
modelos funcionales, semnticos, etc...

Obtencin del
Esquema Global (y II)
Supongamos que los esquemas locales son relacionales y se
usa como modelo cannico el modelo semntico EntidadRelacin Extendido de Chen

Traduccin
A partir de tablas y atributos relacionales (esquema
exportado) se identifican entidades, relaciones y atributos
(enriquecimiento semntico)
Pueden aparecer nuevas entidades
(especializaciones/generalizaciones, etc.)

Integracin
Aplicacin de las propiedades semnticas entre las entidades
y relaciones de distintos esquemas locales cannicos
(sinonimia, unin, generalizacin/especializacin, etc.)

Uso del esquema global

Procesamiento de preguntas
Las preguntas realizadas sobre el esquema
global deben responderse sobre los
esquemas locales

Informacin de enlace
Relacin entre los elementos de datos del
esquema global y los elementos de datos
de los esquemas locales
Necesaria para poder responder a las
preguntas

Optimizacin de pregs. en BDD

Pregunta sobre relaciones distribuidas

DESCOMPOSICIN

Esquema Global

Pregunta en lgebra relacional sobre relaciones distribuidas

LOCALIZACIN DE DATOS

Esquema
de Fragmentos

Pregunta sobre fragmentos

Estadsticas sobre
Fragmentos
Pregunta sobre fragmentos y operaciones de comunicacin
OPTIMIZACIN GLOBAL

OPTIMIZACIN LOCAL
Preguntas locales optimizadas

Esquema Local

Transacciones en BDDs:
protocolo de commit en 2 fases
Se desea ejecutar una transaccin T compuesta por
varias transacciones T1, ... Tn sobre varias BDs:
BD1,...BDn. Para ejecutar un COMMIT global:

Fase de votacin
Cada transaccin Ti no hace COMMIT sino que dice al
nodo coordinador si puede hacerlo y espera a que
ste le conteste

Fase de decisin
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: Motivacin
Los SGBD convencionales son pasivos. Slo
ejecutan preguntas o transacciones realizadas por
los usuarios o por los programas de aplicacin.
Para representar la semntica 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 slo si los
usuarios o aplicaciones lo solicitan explcitamente

BD Activas: Motivacin (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 ms. Para implementarlo:
1) En toda aplicacin que modifique el stock de algn
producto hay que aadir cdigo que compruebe si se baja
del umbral para solicitar ms.
La semntica est distribuida por las aplicaciones.
Posiblemente es una fuente de errores.
2) Realizando un programa que peridicamente sondee
todas las condiciones ( stock(i) < umbral(i) ?)
Frecuencia de sondeo alta --> INEFICIENCIA
Frecuencia de sondeo baja --> INCONSISTENCIAS

BD Activas: Definicin y
Modelo de Conocimiento
Un Sistema de Bases de Datos Activas es un
sistema que monitoriza situaciones de inters y
que, cuando ocurren, dispara o activa la ejecucin
de una serie de acciones.
El comportamiento deseado se expresa en forma
de Reglas Evento-Condicin-Accin (ECA)
ON evento
IF condicin
THEN accin
Nota: Las reglas ECA provienen del paradigma de las Reglas
de Produccin (IF condicin THEN accin) tratado en
Inteligencia Artificial (sobre todo en Sistemas Expertos)

Modelo de Conocimiento
ON evento IF condicin THEN accin
evento puede ser un suceso primitivo:

ocurre una operacin con la BD (insert, ...)

comienza / termina una transaccin (commit,..)
suceso externo: bajada de tensin
suceso temporal: es primer da 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 despus S2)

Modelo de Conocimiento (2)

ON evento IF condicin THEN accin
Se cumple una determinada condicin 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 condicin THEN accin

Se dice que se ejecute algo automticamente

un abort o rollback
mandar un mensaje al usuario
introducir / modificar datos en la base de datos
etc.

Modelo de Ejecucin
Es el comportamiento de las reglas en tiempo de
ejecucin. Se debe conocer:
1) Cundo se evalan los eventos (la frecuencia, si se
evalan dentro de transacciones, etc.)
Durante la ejecucin de una transaccin puede haber momentos en
los que la BD est inconsistente

2) A qu reglas ECA se les evala antes la condicin de

entre las activadas por los eventos
Los eventos que ya han activado reglas pueden seguir activando
otras? Ej: el evento es el primer da del mes

3) Qu regla ECA se ejecutar la primera de entre las que

cumplen la condicin.
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 (condicin)] ]
bloque_PL/SQL

CONDICIN
ACCIN

Triggers en ORACLE 7 (2)

OR REPLACE --> Reemplaza el trigger si ya existe
BEFORE/AFTER DELETE, INSERT, ... ON tabla
Indica si la accin (PL/SQL) se debe ejecutar antes o
despus de que se produzca el borrado, insercin o
modificacin de la tabla.
FOR EACH ROW indica que se ejecute la accin (si se
cumple la condicin) para cada tupla insertada, borrada,...
WHEN --> Es una condicin SQL. No puede contener una
pregunta SQL. Slo SE PUEDE PONER la parte WHEN en
triggers del tipo FOR EACH ROW
El bloque PL/SQL es la parte accin que ORACLE ejecuta
cuando se produce el evento y se cumple la condicin

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 segn 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 accin no puede contener
sentencias como COMMIT o ROLLBACK (ni CREATE...,
ALTER...)
No se pueden crear triggers sobre tablas del sistema que
forman el catlogo. Sera 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 restriccin 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 restriccin 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 todava por Oracle)
ON DELETE / UPDATE SET NULL,
ON DELETE / UPDATE SET DEFAULT

No construir triggers recursivos.

Bases de Datos
Deductivas

BD Deductivas: Motivacin
La lgica como lenguaje de preguntas.
Los predicados corresponderan a relaciones.
vuelo(1,Madrid,Pars,13:30,15:30).
Las reglas corresponderan a defs. de vistas.
vuelo_Mad_tarde(N,S,L,HS,HL) :vuelo(N,Madrid,L,HS,HL), HS > 14:00.
La conjuncin de predicados a demostrar seran las
preguntas.
:- vuelo(N,Madrid,L,HS,HL), HS > 14:00.

Ventaja: la definicin de vistas es mucho ms potente

en lgica ya que puede utilizarse la recursin

Lgica como leng. de

preguntas
SELECCIN
vuelo_mediodia(N,S,L,HS,HL):vuelo(N,S,L,HS,HL),HS>=12:00,HL<=15:00.
PROYECCIN
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)
Combinacin 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)

Lgica es ms 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 Programacin de BD: BD + LP
Orientacin a Objetos: BD + OO = BDOO
Programacin Lgica: 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 deduccin
aadir un operador de clausura transitiva

Realizar SGBDD desde cero. Ej: DATALOG

Y cul es el
futuro de los
SGBD?
SGBD Relacionales + OO
- Tecnologa Object-Relational
- Definicin 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 difcil predecir...
...especialmente el futuro

N. Boehr

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