Bases de Datos Avanzadas

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

Bloque asignaturas BDs
Ficheros y BD (troncal) Diseño de BD Relacionales (opt.) BD Avanzadas (opt.) Sistemas de Información (opt.) Interacción Hombre-Máquina (opt.) Problemas detectados DBDR debería ser troncal el diseño de BDs es fundamental para un informático proyección laboral Interacción Hombre-Máquina poco relacionada con BDs FBD DBDR IHM BDA SI

¿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%) 50%: Práctica
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) SQL es NO PROCEDURAL select nombre from persona where edad > 23 En IMS (jerárquico) el lenguaje de interrogación es PROCEDURAL gu persona where (edad > 23) (obtener el primero) mientras existan “persona” gn persona where (edad > 23) (obtener el siguiente) En CODASYL (red) el lenguaje de interrogación es PROCEDURAL find first persona record in current S1 set si edad > 23 entonces “obtener nombre” mientras existan “persona” hacer find next persona record in current S1 set En SQL no hace falta decir que se utilicen determinados índices o que no. Es el optimizador de preguntas quien decide si hay que hacerlo o no.

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) Dadas las tablas: S(S#, SNAME) 100 SP(S#,P#) (50) La pregunta es “Obtener el nombre de los suministradores que venden el producto P2” select S.SNAME from S, SP where S.S#=SP.S# and SP.P#=‘P2’ Por simplicidad, sólo medidos los accesos a disco (nº lecturas, nº escrituras) Estrategia 1: Join entre S y SP (sobre S#) (100x10.000, ); las no caben en memoria. Seleccionar las tuplas con P2 (10.000, 50); las 50 caben en memoria. Proyectar SNAME (0, 0); están en memoria). Total I/Os: Estrategia 2: Seleccionar de SP aquellas con P2 (10.000, 0); las 50 caben en memoria. Join con S (sobre S#) (100, 0); tanto la segunda relación como las 50 del resultado caben en memoria. Proyectar SNAME. Total I/O:

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 Ejemplo de conversión de una pregunta SQL en una representación interna. En este caso el álgebra relacional. La pregunta en el álgebra relacional es más apropiada para realizar transformaciones sintácticas y semánticas. Dada la pregunta SQL (que es la misma utilizada anteriormente donde se han renombrado las tablas y atributos que son: D(N,C,D), CR(C,N,T) y CF(C,N,E,F)) select D.N from D, CF, CR where D.N=CF.N and CR.C=CF.C and D.C=´Zaragoza´ and CR.N=´SGBD´ La pregunta expresada en el álgebra relacional correspondiente es: p D.N (s D.C=´Zaragoza´ & CR.N=´SGBD´ (D |><| N CF |><| C CR))

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 Operaciones de idempotencia: A U A = A, A U 0 = A, ... Propagar constantes: s A=3 y A=B (C) > s A=3 y 3=B (C) Operación de selección se baja en el árbol: p D.N (s D.C=´Zaragoza´ y CR.N=´SGBD´ (D |><| N CF |><| C CR)) p D.N (s D.C=´Zaragoza´ (D) |><| N CF |><| C s CR.N=´SGBD´ (CR) )) Operación de proyección se baja en el árbol: p D.N ( p D.N (s D.C=´Zaragoza´ (D)) |><| N p D.N, C (CF) |><| C p C (s CR.N=´SGBD´ (CR))) Agrupar proyecciones y selecciones. Por ejemplo: p D.N (s D.C=´Zaragoza´ (D)) se calculará en una pasada.

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. Hay veces que se pueden aplicar transformaciones semánticas si se utiliza conocimiento específico de la base de datos. Por ejemplo, probablemente preguntar por los alumnos de Bases de Datos Avanzadas que ganan menos de diez millones de pesetas es preguntar por todos los alumnos de BDA. s SALARIO< (ALUMNOS_BDA)  ALUMNOS_BDA La siguiente transformación evitaría incluso acceder a las bases de datos !! s SALARIO>= (ALUMNOS_BDA)  “cjto. vacío” Posibles tipos de conocimiento semántico útil para estas transformaciones: 1) Restricciones de integridad: ALUMNOS_BDA.SALARIO <= 2) Dependencias funcionales: ALUMNOS_BDA.DNI  ALUMNOS_BDA.NOM s DNI=17 y NOM=´Pepe´ y NOM=´Luis´ (ALUMNOS_BDA)  “cjto.vacío” 3) Restricciones de integridad referencial (claves ajenas): ALUMNOS_BDA.TUTOR REFERENCES PROFESOR.DNI (and NOT NULL) p ALUMNOS.NOM (ALUMNOS_BDA |><| TUTOR=DNI PROFESOR) --> p ALUMNOS.NOM (ALUMNOS_BDA) (Se evitaría ejecutar un join!!!) NOTA: Estos son sólo unos ejemplos. Hay más posibilidade. Ej: Introducción de índices, eliminaciones de joins, reducciones de scan e incluso introducciones de join. Oracle no realiza optimización semática (al menos hasta Oracle 8, incluido)

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 Estos algoritmos SON INDEPENDIENTES DEL SGBD.

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) Ejemplo: suponiendo que existe índice para “sexo” select * from persona where sexo=´M´ Opt.. basada en reglas: dice que se utilice el índice para hacer la selección Opt. basada en costo: como sólo hay 2 valores distintos para sexo  No usa índice Si se supiera que hay pocos hombres en la tabla  es mejor usar índice En las preguntas SQL no se puede decir que se utilice o no determinado índice durante su procesamiento (sería muy interesante para usuarios expertos). Sin embargo, al consultar los manuales del SGBD concreto que se esté utilizando se pueden encontrar trucos (guarrerías) como las siguientes: 1) Indicar directamente que use un índice: select /*+ INDEX(sex_indice) */ from persona where sexo=´M´ 2) Suponiendo que exista un índice sobre el campo comisión, con la pregunta A el optimizador no usará el índice pero con la B sí lo hará. A) select nombre from cliente where comision is not null B) select nombre from cliente where comision > 0 3) Suponiendo que existan índices sobre dept_num y nombre, y que se supiera que es más selectivo el índice sobre nombre, entonces, en vez de dejar que el optimizador decida qué índice usar (y que escoga dept_num) select nombre, dept_nombre, salario from empleado where dept_num=20 and nombre=´Smith´ Se podría hacer la pregunta de esta otra manera (ya que ORACLE no utiliza índices sobre campos donde se realizan cálculos) where dept_num + 0 = 20 and nombre=´Smith´

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. El diseño físico de BD forma parte importante del ciclo de vida de un sistema de BDs (en todas sus fases: creación, desarrollo y explotación). ANALISIS DE REQUERIMIENTOS: etapa en la que se estudia el sistema de información actual y se decide cuáles son los requerimientos de datos y de funciones. DISEÑO CONCEPTUAL: Con los requerimientos de datos (que se necesitan por todas las funciones/aplicaciones) se construye el esquema conceptual utilizando un modelo semántico como el E/R que no depende de ningún SGBD concreto (ni de sistemas de ficheros). DISEÑO LÓGICO: se realiza tras escoger el SGBD que se va a utilizar (o al menos el modelo). Para esta tarea sí existen metodologías. En el modelo relacional hay reglas para pasar de entidades y relaciones a tablas relacionales, y un proceso de normalización donde se obtiene una descripción lógica de tablas en las que se asegura que no existe redundancia ni que se producirán anomalías de inserción, actualización o borrado. Esta descripción lógica no es siempre la más adecuada. DISEÑO FISICO: Toma de decisiones para ajustar el rendimiento a los requerimiento.

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. Ejemplo de información a recopilar: Transacción / Operación 1 select nombre, nomasig from profesores, asignaturas, matriculas where profesores.dni=matriculas.cod_prof and asignaturas.codasig=matriculas.codasig and profesores.dept=‘IIS’ {En general una constante ( ‘IIS’)} a) Tipo: SELECT b) Tablas: profesores (300), asignaturas (1000), matriculas (10000) c) Conds. selección: dept=‘IIS’ (30 profesores) (10%) d) Condiciones join: profesores.dni=matriculas.cod_prof (10000) (100%) asignaturas.cod_asig=matriculas.cod_asig (10000) (100%) e) Atributos a proyectar: nombre, nomasig f) Frecuencia: 3 veces/día g) Restricciones: que nunca tarde más de unos segundos Transacción / Operación 2 update profesores set dept = ‘IIS’ {En general una constante} where dni = 18 {En general una constante} a) Tipo: UPDATE b)Tablas: profesores (300) c) Conds. selec.: dni=18 (0.3%) d) Conds. Join: no hay e) Atributos a modificar: dept f) Frecuencia 10 veces/año g) Restricciones: no hay

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. Supongamos que tenemos las tablas siguientes: MATRICULA(COD_ASIG,COD_ALUM) ASIGNATURAS(COD, NOMBRE, CREDITOS,...) donde ASIGNATURAS.COD toma valores 1, 2, 3, 4 ... Al hacer la operación que nos diga el número de personas matriculadas en una asignatura en concreto (por ej. BASES DE DATOS AVANZADAS), hay que realizar una pregunta con un join: select COUNT(COD_ALUM) from MATRICULA, ASIGNATURAS where COD=COD_ASIG and NOMBRE=´BASES DE DATOS AVANZADAS´ en vez de la siguiente (sin join) donde se utiliza un código más intuitivo para cada asignatura. from MATRICULA where COD_ASIG=´BDA´

DNI--> CIUDAD, CIUDAD --/-> DNI
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.) Ejemplo: Supongamos que tenemos la tabla PERSONAS(DNI, NOMBRE, DIR, CODP,CIUDAD) Durante el proceso de normalización se habrá detectado que no está en 3FN DNI--> CODP, CODP --/-> DNI, COD_POSTAL -->CIUDAD, DNI--> CIUDAD, CIUDAD --/-> DNI por lo que se habrá normalizado y descompuesto en las siguientes tablas: PERSONAS(DNI,NOMBRE,DIR,CODP) COD_POSTALES(CODP,CIUDAD) Sin embargo, al recopilar la información sobre las operaciones a realizar sobre la base de datos nos damos cuenta de que EN TODA OPERACIÓN DONDE SE OBTIENE EL CÓDIGO POSTAL PARA UNA PERSONA SE OBTIENE TAMBIÉN LA CIUDAD. select NOMBRE, DIR, CODP, CIUDAD from PERSONAS, COD_POSTALES where PERSONAS.CODP = COD_POSTALES.CODP En ese caso parece razonable añadir CIUDAD a la tabla de PERSONAS, a pesar de que la tabla PERSONAS ya no esté en 3FN, ya que la pregunta anterior será “select NOMBRE, DIR, CODP, CIUDAD from PERSONAS” NOTA: La tabla COD_POSTALES se puede seguir manteniendo para asegurar que no existen inconsistencias en la BDs. En ese caso si se inserta una persona se comprueba que la ciudad correspondiente al código postal es la misma de la tabla COD_POSTALES (o no se pregunta por la ciudad sino que automáticamente se obtiene de dicha tabla, a no ser que no aparezca). Si existiera una operación de cambio de un código postal por otro (o de ciudad) entonces habría que cambiarla en PERSONAS --> Triggers !!

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 !! Si tenemos PERSONAS(DNI,NOM,STATUS,DPTO,CURSO,CAT,TRAB) de tal manera que cuando STATUS=‘alumno’ entonces DPTO, CAT y TRAB son NULL, si STATUS=‘profesor’ --> CURSO y TRAB son NULL y si STATUS=‘pas’ --> CURSO y CAT son NULL y se cumple que PERSONAS = s status=‘alumnos’(PERSONAS) U .... entonces es mejor tener las tablas ALUMNOS(DNI,NOM,CURSO), PROFESORES(DNI,NOM,DPTO,CAT) y PAS(DNI,NOM,DPTO,TRAB). Se puede definir una vista para PERSONAS create view PERSONAS(DNI,NOM,STATUS,DPTO,CURSO,CAT,TRAB) as select dni,nom,’alumno’,NULL,curso,NULL,NULL from alumnos union select dni,nom,’profesor’,dpto,NULL,cat,NULL)from profesores select dni, nom, ‘pas’, dpto, NULL, NULL, trab from pas En realidad se puede ver esto como diseño lógico ya que deberían haberse detectado la entidad PERSONAS con atributos DNI y NOM y dos subentidades ALUMNOS (con atributo CURSO) y TRABAJADORES (con atributo DPTO), y esta última con dos subentidades PROFESORES y PAS (con atributos CAT y TRAB respectivamente). Sin embargo, también se puede ver como diseño físico: se fragmenta horizontalmente una tabla en varias ya que se accede a ellas individualmente de manera más frecuente. En general si tenemos la tabla EMPLEADOS(DNI,NOM,CARGO,...) y se accede muy a menudo a aquellos empleados con cargo director, entonces se puede guardar en una tabla aparte DIRECTORES(DNI,NOM...). Las consultas sobre directores serán: (select * from directores where...) Si más adelante se decide que no se necesita dicha tabla entonces para que no cambien los programas (independencia física) se podrá definir la vista DIRECTORES (create view directores as select dni,nombre from empleados where cargo=´dir’) Existe redundancia entre EMPLEADOS y DIRECTORES (ex. dep. inclus.) directores.dni <= empleados.dni), que se puede controlar usando triggers.

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. Si tenemos la tabla EMPLEADOS(DNI,NOM,CARGO,DIR,TEL,FEC_NAC,LUG,SEXO) donde se usan generalmente los atributos DNI, NOM, CARGO (que ocupan 50 bytes) y los otros (que ocupan 300 bytes) apenas se utilizan. Se puede conseguir más eficiencia en las consultas si se crea una nueva tabla EMPLEADOS_PEQ(DNI,CARGO,DIR) donde los registros son de 50 bytes en vez de 350 bytes y por tanto caben 7 veces más registros en un mismo bloque y las consultas son más rápidas (accediendo así: select * from EMPLEADOS_PEQ where ...) Como inconveniente habrá redundancia que hay que controlar (mediante triggers o bien asegurándonos de que en la parte de las aplicaciones donde se insertan o modifican empleados introducir los datos en ambas tablas). Si más adelante se decide no realizar esta fragmentación vertical los programas de aplicación no habrá que cambiarlos si se proporciona EMPLEADOS_PEQ como una vista: create view EMPLEADOS_PEQ as select DNI,NOM,CARGO from EMPLEADOS

Precomputar joins en tablas
Si existe una consulta R1 R 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 Si tenemos las tablas: EMP(DNI,NOMBRE) ASIG(DNI,CODEQUIP,JEFE), donde JEFE=‘S’ o ‘N’ EQUIPO(CODEQUIP,NOMEQUIP) y queremos obtener el nombre de cada empleado junto con el de su jefe y el del equipo al que pertenece hay que hacer un join entre 5 tablas: select EMP1.NOMBRE, EMP2.NOMBRE, EQUIPO1.NOMEQUIP from EMP EMP1, EMP EMP2, ASIG ASIG1, ASIG ASIG2, EQUIPO where EMP1.DNI=ASIG1.DNI and ASIG1.JEFE=‘N’ {Emp1 es empleado} and ASIG1.CODEQUIP=EQUIPO.CODEQUIP {para acceder a nomequip} and ASIG1.CODEQUIP=ASIG2.CODEQUIP and ASIG2.JEFE=‘S’ {las 2 lín. son para saber quién es el jefe del Emp1} and EMP2.DNI=ASIG2.DNI {para acceder al nombre del jefe Emp2} 1) Para evitar teclear la consulta se puede crear una vista CREATE VIEW NOM_EMP_JEF_EQUIP (NOME,NOMJ,NOMEQ) AS ... y realizar consultas: SELECT * FROM NOM_EMP_JEF_EQUIP El problema es que la consulta es muy costosa si se ejecuta todos los días. Además puede ser que las tablas EMP, ASIG y EQUIPO no cambien tanto. 2) Entonces es mejor hacer CREATE TABLE NOM_EMP_JEF_EQUIP ... y después ejecutar INSERT INTO NOM_EMP_JEF_EQUIP SELECT ... Para mantener la consistencia se puede: A) añadir triggers que controlen cambios en las tablas. Problemas: la pregunta con 5 joins se ejecuta con cada actualización !!!!. B) ejecutar un DROP TABLE NOM_EMP_JEF_EQUIP, luego el CREATE TABLE y el INSERT correspondientes todas las noches.

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) Ej. 1: Como primary key: (dni se utilizará para hacer joins y es clave) create table personas (dni number primary key, nombre ...) Ej. 2: Como índice cluster: (se accede por orden a nombres, y no es clave !!) create cluster cluper (nom char(10)); create table personas (num number, nombre char(10)...) cluster cluper(nombre); Ej. 3: Tenemos tablas profesores(dni,nom,...) y asignaturas(cod,dniprof,...) y suponemos que se ejecuta frecuentemente (select * from profesores, asignaturas where dni=dniprof ...). Se pueden definir en un cluster: create cluster profasig (num number); create table profesores (dni number primary key, nom char(10),...) cluster profasig(dni); create table asignaturas (cod number, dniprof number references profesores(dni),...) cluster profasig(dniprof); Ej. 4: Si se pregunta frecuentemente por nombre (y dni es primary key) create (unique) index on personas (nombre); {en tabla de Ej. 1) create (unique) index on personas (apellidos, nombre); {Primero el campo por el que más se pregunte, en este caso apellidos} No definir índices create index on personas (sexo); Sólo 2 valores !!! No definir índices sobre tablas muy volátiles ni sobre tablas pequeñas. Ej. 5: Si se accediera a personas dando un dni (y no hubiera joins con dni) create cluster cper (num number) hashkeys ; create table pers (dni number primary key,...) cluster cper (dni); donde hashkeys es el número diferente de valores. Esto es bueno para contestar (select * from personas where dni=xxx). No es bueno para dni>= xxx.

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) Lo importante es mantener documentadas todas las decisiones de carácter físico tomadas sobre la BD que estarán asociadas a determinadas consultas. Una de las cosas que puede ayudar para replantearse continuamente el diseño físico a lo largo de la vida del sistema es “escuchar las quejas de los usuarios” que indican qué transacciones son demasiado lentas, etc. Algunas de las decisiones tomadas pueden hacer peligrar la independencia física de los programas. Es decir, si se crea una nueva tabla, habrá que utilizarla dentro de las aplicaciones. Sin embargo, si lo que se definen son índices, etc. entonces en principio los programas no cambian ya que las preguntas SQL no hacen referencia a índices, excepto si se utilizan “hints” para el procesador de preguntas tal y como permite ORACLE 7. Ejemplos: select /*+ INDEX(ind_a) */ ... para que utilice el índice ind_a select /*+ FULL(pers) */ ... para que no use índices sobre pers select /*+ ORDERED */ ... para que haga los joins tal y como vienen las tablas en el “from” Debido a que los requerimientos del sistema pueden ir cambiando se pueden tomar nuevas decisiones que revoquen algunas de las anteriores. Habrá que tener cuidado y ver si la independencia física peligra. Si se borra una tabla entonces se puede arreglar definiendo una vista en vez de ella. Después de los diseños conceptual y lógico donde la metodología es relativamente clara viene el diseño físico donde parece que se toman decisiones contrarias a las que eran importantes durante el diseño conceptual y lógico. Esto, que se asemeja a un “caos”, no lo es tanto si se sabe por qué se hacen las cosas.

Transacciones, Recuperación y Control de Concurrencia

Ejemplo motivador: transferencia bancaria
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) Ejemplo motivador: transferencia bancaria Comienzo de transacción. update cuentas set saldo=saldo where num=17 update cuentas set saldo=saldo where num=20 Fin de transacción Queremos que se ejecuten las 2 operaciones con la BD a la vez ya que si sólo se ejecutara la primera el titular de la cuenta 17 perdería ptas. que no pasarían a la cuenta 20. Si después de ejecutarse el primer update se produce un fallo (se apaga el ordenador) y por tanto la transacción FALLA queremos que al iniciarse de nuevo el sistema se deshaga automáticamente el primer cambio. Después ya se ejecutará la transacción de nuevo (el sistema no lo hará de manera automática). A la entidad bancaria tampoco le gustaría que se ejecutara solamente el segundo update. Las causas de posibles fallos pueden ser muchas: el saldo del primero es menor que (el programador debe controlarlo ya que suponemos que eso no sería un estado consistente en la BD), ocurre una operación incorrecta (overflow en la cuenta 20 !!, o en general divisiones por cero, etc.), hay problemas porque otra transacción ha leído a la vez el valor del saldo de la cuenta 20 y al actualizar ambas entonces se pierde una de las actualizaciones, ocurren fallos de disco al leer/escribir, o aún peor, catástrofes naturales (fuego), sabotajes, robos, etc. En realidad esto último lo deberían garantizar las medidas de seguridad informática adoptadas por la empresa (backups, discos RAID (Redundant Array of Inexpensive/Independent Disks), etc). La seguridad total no existe sino que depende de cuánto dinero/recursos nos gastemos en ella.

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. Respecto a los errores lógicos, es responsabilidad de los programadores de BDs y/o del administrador el definir las reglas de integridad (cuya violación haría que el sistema automáticamente invalidara la transacción) y el realizar las comprobaciones correspondientes en los programas y escribir los ROLLBACK que sean necesarios. Por supuesto hay que indicar DÓNDE EMPIEZAN Y TERMINAN LAS TRANSACCIONES !!! El resto de problemas (excepto los dos últimos) son solucionados por el método de recuperación del SGBD.

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> Comienzo de transacción. update cuentas set saldo=saldo where num=17 update cuentas set saldo=saldo where num=20 Fin de transacción. En el fichero de LOG se han podido grabar los siguientes registros: <comienza-transacción, t1> <lectura, t1, <nom_bd,cuentas,saldo,row_id=1.0.5>, > <escritura, t1, <nom_bd,cuentas,saldo,row_id=1.0.5>, , > Supongamos que aquí se cae el sistema. Al reinicializarse y analizarse el fichero de LOG se puede ver que la transacción t1 ha empezado pero no terminado por lo que deben deshacerse los cambios (basta con poner los valores viejos de las escrituras comenzando por el final). Supongamos que no se ha caído el sistema. <lectura, t1, <nom_bd,cuentas,saldo,row_id=1.0.8>, > <escritura, t1, <nom_bd,cuentas,saldo,row_id=1.0.8>, , > <termina-transacción-con-éxito, t1> Entonces ya tenemos almacenada toda la información que nos permitiría rehacer esta transacción t1 si fuera necesario a partir de un backup anterior de la BD y el fichero de LOG. Los checkpoints permiten, en caso de ciertos problemas, no deshacer toda la transacción, sino solamente hasta el último checkpoint.

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 Problema de la actualización perdida: update cuentas (T1) update cuentas (T2) set saldo=saldo set saldo=saldo+2000 where num=17 where num=17 Secuencia: T1 lee saldo=5000, T2 lee saldo=5000, T1 escribe 6000, T2 escr (machaca el 6000). Sin embargo el resultado final debería ser 8000 !!! Problema de la actualización temporal: Usando las mismas transacciones. Secuencia: T1 lee saldo=5000, T1 escribe 6000, T2 lee saldo=6000, T1 falla y hace un ROLLBACK y deshace los cambios, T2 escribe Debería. ser 7000 !!!! Problema del resumen incorrecto: select sum(saldo) (T3) update cuentas (T4) from cuentas set saldo=saldo+1000 where num=17 update cuentas set saldo=saldo-1000 where num=25 Secuencia: T3 lee el saldo de la cuenta 17 después de que T4 incremente pero lee el de la cuenta 25 antes de decrementar. Por tanto la suma da 1000 ptas. más !!! Si se ejecutan todas las transacciones en exclusión mutua no hay problemas. Problema de la lectura no repetible: update cuentas (T5) update cuentas (T6) set saldo=saldo+1000 set saldo=0 where num=17 where num=17 update cuentas where num=17 Secuencia: T5 lee el saldo de la cuenta 17 dos veces pero si T6 se ejecuta en medio, no lee dos veces el mismo valor !!!

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 T1: select * from personas where color_pelo=‘RUBIO’ T2: update personas set salario=salario*1.1 T3: update personas set salario=0 where color_pelo=‘RUBIO’ update personas set salario=20000 where color_pelo=‘NEGRO’ Tabla personas (DNI, SALARIO,COLOR_PELO) RUBIO MORENO RUBIO NEGRO Planes SERIALES (los únicos válidos) y después únicos resultados válidos: T1, T2, T3 T1, T3, T2 T2, T1, T3 T2, T3, T1 T3, T1, T2 T3, T2, T1 (DNI, SALARIO,COLOR_PELO) (DNI, SALARIO,COLOR_PELO) RUBIO RUBIO MORENO MORENO RUBIO RUBIO NEGRO NEGRO Todo plan SERIALIZABLE deberá dejar la tabla de personas con una de las dos extensiones anteriores (y además la transacción T1 devolverá las tuplas de personas de pelo RUBIO correspondientes a una de las 3 extensiones posibles: la inicial, una de las 2 finales o una de las 2 intermedias (tras hacer solamente T2 o T3). Ejemplo de plan serializable: T1 lee tupla 1, T2 escribe tuplas 1 y 2, T3 escribe tupla 1, T1 lee tupla 3, T2 escribe tuplas 3 y 4, T3 escribe 3 y 4 Ejemplo de plan no serializable: T1 lee la tupla 1, T2 escribe tuplas 1, 2 y 3, T1 lee 2 !!

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 NOTA: Vendría bien que el problema no fuera NP-completo ya que en ese caso sería posible recibir las N transacciones a ejecutar y encontrar un plan (que además fuera serializable, claro) y que optimizara las N. Se trataría de optimizar la ejecución de N pregunta en vez de optimizar sólo una pregunta cada vez.

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) Dadas las dos transacciones siguientes: T1 T2 lock_compartido(Y) X=20, Y=30 lock_compartido(X) read(Y) | read(X) unlock(Y) | unlock(X) lock_exclusivo(X) | lock_exclusivo(Y) read(X) | read(Y) X:=X+Y X=50, Y=50 Y:=Y+X write(X) | write(Y) unlock(X) !!!!!!!! unlock(Y) Resultados válido: si T1 se ejecuta antes que T2 entonces X=50, Y=80. Si T2 se ejecuta antes que T1 entonces X=70, Y=50 Sin embargo: Puede ocurrir que ambos dejen X=50 y Y=50 debido a que cada uno de ellos hace unlock(Y) y unlock(X) permitiendo al otro conseguir el lock_exclusivo de ambas variables. Si vamos alternando las operaciones de T1 y T2, PLAN NO SERIALIZABLE !!! El problema estriba en hacer UNLOCK antes de tiempo. El protocolo de bloqueo en dos fases impide hacer UNLOCK si todavía faltan LOCKs por hacer. Ese protocolo garantiza la serializabilidad.

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 El protocolo de bloqueo en dos fases GARANTIZA la serializabilidad PERO IMPIDE ALGUNO DE LOS PLANES SERIALIZABLES. Ya dijimos que era restrictivo y que impedía algunas de las operaciones sospechosas de hacer no serializable el plan. Qué se le va a hacer ! T1 T2 T3 read(X) X:=5 read(X) X:=X+1 write(X) X:=X+5 write(X) write(X) Inic: X=10 T1 (X=11) T2 (X=5) T3 (X=10) (****) T2 (X=5) T1 (X=6) T3 (X=11) T1 (X=11) T3 (X=16) T2 (X=5) (igual que T3 T1 T2) T2 (X=5) T3 (X=10) T1 (X=11) T3 (X=15) T2 (X=5) T1 (X=6) Sin embargo el siguiente plan es serializable pero no es permitido por el protocolo de bloqueo en dos fases: 1.- T1 hace read(X) X=10 (Suponemos que las X donde se hace X:=X+1, X:=5, ... son locales a cada transacción). 2.- T2 hace write(X) escribe X=5 (NO SERÍA POSIBLE. Se necesitaría haber obtenido el lock_exclusivo(X) !!) 3.- T3 hace read (X) y lee X=5 4.- T1 hace write(X) y escribe X=11 5.- T3 hace write(X) y escribe X=10 (SERIALIZABLE !!!! igual a ****)

Deadlocks Prevención de 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! Prevención de deadlocks: A) lock_exclusivo(X,Y,...) OBTIENE TODOS O NINGUNO !! B) Ejemplo de pedir los lock en un orden: siempre pedir X antes que Y. El programador debe controlarlo. Demasiado pedir a los programadores !! lock_exclusivo(X) lock_exclusivo(X) lock_exclusivo(Y) lock_exclusivo(Y) read(X); read(Y); read(X); read(Y),… Detección de deadlocks: lock_exclusivo(X) lock_exclusivo(Y) lock_exclusivo(Y) lock_exclusivo(X) T1 consigue el lock exclusivo para X. T2 consigue el lock exclusivo para Y. Luego T2 solicita el lock exclusivo para X. Como lo tiene T1 entonces se añade arista al grafo: T > T1 (T2 está esperando a T1) Luego T1 solicita el lock exclusivo para Y. Como lo tiene T2 entonces se añade arista al grafo: T > T2 En ese momento se puede comprobar que en el grafo HAY UN CICLO !!! (detectar un ciclo en un grafo de N nodos ---> O(N*N) ) ORACLE proporciona DETECCIÓN AUTOMÁTICA DE INTERBLOQUEOS (deadlocks) y lo resuelve abortando a algunos de los procesos. El programador por tanto no debe controlarlo.

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) Como el protocolo en 2 fases: hay planes que son serializables pero que ni las técnicas de time-stampìng ni el protocolo de bloqueo en 2 fases los permiten.

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”) Fase de lectura: ejecución de la transacción. Se leen los valores y se escriben en copias locales. Fase de validación: antes de que Ti haga commit se comprueba si hay interferencias. No las hay en cualquiera de los casos siguientes Tj ha terminado su fase de escritura antes de que Ti haya comenzado su fase de lectura. Ti comienza su fase de escritura después de que Tj complete su fase de escritura y Ti no lee elementos escritos por Tj. No hay elementos en común entre los que lee y escribe Ti con los que escribe Tj, y Tj ha terminado su fase de lectura antes de que Ti termine su fase de lectura. Fase de escritura: si ha habido problemas se hace rollback y si no, se escriben todos los cambios en la BD (commit).

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 ORACLE garantiza que ninguna instrucción SELECT de una transacción LEE RESULTADOS DE ACTUALIZACIÓN DE OTRAS TRANSACCIONES sobre las que no se ha hecho COMMIT. Con la lectura consistente es posible no ver dichos cambios incluso después de que hayan hecho COMMIT. Ej: Si se quiere conocer el número de billetes libres en total (suponiendo que se encuentran en dos tablas distintas), entonces hay que hacer: set transaction read only; select count(*) from billetes_iberia where estado=‘Libre’; from billetes_aviaco commit; Así se asegura que podemos saber el número de billetes libres justo en el momento de iniciarse la transacción. No hay que olvidar que mientras se ejecuta es posible que alguno de los billetes de cualquiera de las tablas pase de ‘Libre’ a ‘Reservado’ o de ‘Reservado’ a ‘Libre’ (pero esto no cambia los datos manejados por la 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 Si se quiere reservar un billete antes hay que ver cuáles son los billetes que están libres. Por lo tanto, antes de ESCRIBIR hay que LEER. Para estar seguros de que lo que se está leyendo NO SE CAMBIA concurrentemente por alguna transacción, entonces según el protocolo de bloqueo en dos fases, hay que hacer: select * from billetes where estado=‘Libre’ for update of estado /* Necesario para conseguir el lock exclusivo sobre billetes libres */ /* Se ven los libres. Supongamos que el num 17 lo está.*/ update billetes set estado=‘Reservado’ where num=17 commit Si no, podría suceder que mientras se ejecuta el primer SELECT, alguna otra transacción reservara a la vez el num 17. Otra posible solución si no se pone FOR UPDATE OF estado: update billetes set estado=‘Reservado’ where num=17 and estado=‘Libre’ En ese caso, si lo han reservado mientras tanto, dirá que ninguna cumplía las condiciones (num=17 and estado=‘Libre’).

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? En principio en ORACLE no se puede pedir un LOCK después de hacer un UNLOCK dentro de una transacción, ya que se hace UNLOCK SIEMPRE DESPUÉS DE TERMINAR LAS TRANSACCIONES (con commit o rollback) Con cualquier operación de escritura: INSERT, UPDATE o DELETE, se nos asegura que ORACLE obtiene LOCKs exclusivos. La única pega es con las operaciones de lectura, ya que ORACLE no obtiene LOCKS compartidos. Es posible leer a la vez que otra transacción está escribiendo en la tabla/s que estamos leyendo. En algunos casos de lectura será necesario colocar: 1) SELECT ...FOR UPDATE OF … cuando antes de escribir queramos leer para ver si se puede o no escribir en las tuplas seleccionadas. Esta operación espera a obtener un LOCK EXCLUSIVO sobre la columna indicada.. 2) SET TRANSACTION READ ONLY que nos asegura que esta transacción lee los valores de todas las tablas en el momento inicial de la transacción. Habrá que ponerla si vamos a leer de dos tablas: select * from A where ... select * from B where ... y no queremos ver los valores que otra transacción haya hecho (con commit) sobre B mientras leíamos A.

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 [43] sisf00 > sqlplus SQL*Plus: Release Production on Thu Feb 26 14:09: Copyright (c) Oracle Corporation 1979, All rights reserved. Introduzca el nombre de usuario: jirgbd Introduzca su clave: Conectado a: Oracle7 Server Release Production Release PL/SQL Release Production SQL> select table_name from user_tables; TABLE_NAME ALUMNOS ESTUDIAN P PLAN_TABLE PRUEBA TEST 6 filas seleccionadas. SQL>

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 Funcionalidad de ODBC Definición del Driver ODBC getConnection(fuente de datos) createStatement getResultSet getMetadata getColumnCount getColumnLabel getString Close

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.) Definir tipos (conocidos por el SGBD que son distintos a los del leng. prog.): EXEC SQL BEGIN DECLARE SECTION; VARCHAR nombre[25]; int edad; EXEC SQL END DECLARE SECTION; Conexión y desconexión a la BD: EXEC SQL CONNECT <us> IDENTIFIED BY <pass> EXEC SQL RELEASE Captura de excepciones: EXEC SQL WHENEVER SQLERROR GOTO etiqueta; Seleccionar tuplas simples desde una BD: EXEC SQL SELECT nom INTO :nombre FROM personas WHERE dni=17 Seleccionar varias tuplas (uso de cursores): EXEC SQL DECLARE c1 CURSOR FOR SELECT * FROM personas ... EXEC SQL OPEN c1; (dentro de un bucle) EXEC SQL FETCH c1 INTO :nombre, :edad; EXEC SQL CLOSE c1; Fin de transacciones EXEC SQL COMMIT WORK (ROLLBACK WORK)

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 !! Se desea hacer un programa que RESERVE UN BILLETE. select * from billetes where estado = ‘libre’ and fecha = ... LP SGBD Varios datos !!! B1, libre, ... B3, libre,.... Solución: definir CURSOR define después de hacer open LP open SGBD fetch B1, libre, ... close B3, libre,.... Al hacer OPEN CURSOR se rellena el resultado y después el LP hace un FETCH para obtener el primer billete libre y lo pone a reservado. Sin embargo, ¿para qué se han almacenado todos los datos de la pregunta SQL si sólo se estaba interesado en uno de ellos?

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] Abstracción funcional (Programación estructurada). Los LP de alto nivel proporcionan instrucciones que permiten cierta abstracción funcional: 1) Permiten definir expresiones de la forma a + (b* c * d) + h / f. Se consigue abstracción del orden de ejecución (primero b * c y luego d, etc...) 2) Las estructuras de control (while ... do), (if then else),... permiten abstracción de saltos. 3) Los LP permiten definir procedimientos y funciones. Al decir calcular_raices_cuadradas(a,b,c,r1,r2,...) nos abstraemos de cómo lo hace--> Progr. estructurada Abstracción de datos (Tipos Abstractos de Datos). Si queremos hacer un programa que controle la venta de entradas de un CINE: for i:=1 to NUM do cine[i]:=LIBRE; while “se quiera comprar entradas” and “no lleno” do j:=“obtener localidad a ocupar”; cine[j]:=OCUPADO;... Lamentablemente el programa cambia según sea la estructura de datos utilizada para representar el cine. Mejor crear un TAD llamado cine donde por un lado tengamos su estructura (los TIPOS), y por otro lado las operaciones (PONER_LIBRES, RESERVAR1(i,...), RESERVAR_N(....), LIBERAR, BUSCAR_SITIO, VISUALIZAR_CINE,...). Es importante que NO SE ACCEDA a la estructura de datos directamente --> encapsulación (public & private). ¿Qué sucede si ahora queremos hacer una aplicación “similar” para un TEATRO, o para un ACUARIUM? Algunas de las operaciones serán similares y por lo tanto en teoría podríamos REUTILIZAR SOFTWARE. Pueden cambiar algunas si suponemos que los sitios en el teatro o en el cine son sillas y en el acuarium no. En ese caso RESERVAR_N, VISUALIZAR, etc serán diferentes. Herencia (Orientación a Objetos). Se puede definir una jerarquía donde se heredan las operaciones (llamadas métodos). Por ejemplo la clase ESPECTÁCULO con subclases CON_ASIENTOS y SIN_ASIENTOS. CINE y TEATRO serían subclases de CON_ASIENTOS. ACUARIUM sería subclase de SIN_ASIENTOS. Se especializarían los métodos correspondientes.

Conceptos básicos OO Objetos complejos Identidad de objetos
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 Ejemplo: la clase CINE con atributos NOMBRE (string), AFORO (integer), ASIENTOS (array bidimensional de booleanos),... y con métodos PONER_LIBRES, RESERVAR_N, ... clase CINE NOMBRE: Golem1 NOMBRE: Golem2 AFORO: AFORO: 350 ASIENTOS: TFTTT.. ASIENTOS: FTF..... FTTFF TFF.... OID: 1#cine OID: 2#cine o bien ASIENTOS tiene de tipo la clase ASIENTO con atributos ESTADO (booleano), FILA y COLUMNA y con métodos LIBERAR y RESERVAR. Por lo tanto los valores para 1#cine en ASIENTOS: 1#asiento 3#asiento .... donde tendríamos clase ASIENTO ESTADO: T FILA:3 COLUMNA:3 ESTADO: F OID: 1#asiento OID: 3# asiento

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. Podríamos tener 2 cines con igual nombre, aforo y estado de los asientos y ser distintos !!!! En Pamplona y en Logroño hay cines Golem. Supongamos que tengan igual aforo y que los identificadores de ambos sean 1#cine y 75#cine. 1#cine NO ES IDÉNTICO A 75#cine 1#cine NO ES IGUAL DE MANERA SUPERFICIAL A 75#cine, si obviamente la lista de asientos se refiere a distintos objetos (con distinto oid) Es posible que en un momento determinado 1#cine sea IGUAL DE MANERA PROFUNDA A 75#cine El problema es filosófico: decimos que dos sillas son iguales, a pesar de que no sea la misma, si tienen los mismos atributos (altura, color, forma,...)

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. IMPLEMENTACIÓN INTERFAZ (API) OID: 1#cine NOMBRE: Golem PONER_LIBRES() AFORO: RESERVAR_N(n) -> lista - asientos ASIENTOS: 1#asiento, 3#asiento,... El objeto se crearía al ejecutar CREAR_CINE(‘Golem1’,250), que en realidad es un método de la CLASE. Dicha llamada devolvería el OID asignado, que en este caso sería 1#cine. Al definir dicho método habría que crear tantos objetos de la clase asientos como diga aforo. Para ello habría que llamar al método CREAR_ASIENTO(...).

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

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. Ej: clase persona con atributos NOMBRE, DIR y métodos NACER, COMER, DORMIR, ... alumno is-a person con atributos CURSO y método ESTUDIAR (y que hereda los de persona) profesor is-a person con atributos ASIGNAT y método ENSEÑAR alumno-profesor is-a alumno, profesor (y que hereda los de alumno y los de profesor) si tuviéramos catedrático is-a person NO SE CONSIDERA QUE HAY HERENCIA MÚLTIPLE (aunque sea subclase de profesor y de persona, ya que no es subclase directa de persona en el árbol). Problema 1 Problema 2 Problema 3 Vehículos.ruedas A.a B.a A.a=3 coches.ruedas=4 motos.ruedas=2 C.a ? B.a=5 isocarro.ruedas=3

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”). Ejemplos: figuras geométricas, tipos de profesores

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

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

Diseño de BDOO Para diseñar BDs generalmente se usa un modelo de BDs semántico llamado Entidad-Relación (extendido) de Chen. Los pasos que se pueden seguir son: Obtener el esquema E-R extendido Normalizar dicho esquema E-R Obtener las tablas correspondientes al E-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 > ) cout “Nombre:” << pe->nombre; for (pp in all persona; pc in coche) suchthat (strcmp(pp->pais,pc->pais)==0) { ....} for (pe in empleado) suchthat (pe->padre->edad() > 50) { .....} for (pe in empleado) suchthat (pe->salario > ) cout “Nombre:” << pe->nombre; Sería equivalente a: SELECT nombre FROM empleado WHERE salario > 20000 for (pp in all persona; pc in coche) suchthat (strcmp(pp->pais,pc->pais)==0) { ....} Equivalente al JOIN: SELECT * FROM persona, coche WHERE persona.pais = coche.pais Nota: persona devuelve los objetos de todas las subclases por haber puesto all (pp in all persona). for (pe in all persona) suchthat (pe->padre->edad() > 50) { .....} Notas: 1.-) Se llama al método edad() de persona 2.-) Se puede navegar mediante los atributos que toman valores en clases. En este caso el atributo padre de persona toma valores en la clase persona y por lo tanto se puede acceder a los métodos y atributos de persona. En este caso: pe->padre->edad() 3.-) Se usan caminos en vez de joins

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. Índices o Hash: hay 2 prototipos para database::BuildIndex int BuildIndex(const char *typeName, const char * memberName, database *, int unique=0, Index_type type=HASH_TYPE) crea un índice en el cluster por defecto para el tipo/clase “typeName” int BuildIndex(const char * clusterName, const char * typeName, const char * memberName, database *, int unique, Index_type=HASH_TYPE) Index_type puede ser NOINDEX_TYPE, HASH_TYPE o BTREE_TYPE Se puede borrar un índice: int IndexDelete(const char typeName,const char *memberName, database *, int uniq=0); int IndexDelete(const char *clusterName, const char *typeName, const char *memberName, database *, int uniq=0); Se puede preguntar si existe índice, hash o no: Index_type IndexExists(const char *typeName, const char *memberName, database *, int unique=0); Index_type IndexExists(const char *clusterName, const char *memberName, database *, int unique=0); Triggers: se pueden definir triggers con eventos básicos y compuestos Versiones: persistent empleado *p, *v1; v1 = newvers (p); Crea una nueva versión de p v2 = newvers(v1); v3=newvers(p); vdprev(v1) devuelve p que es de quien es versión vlatest(p) devuelve v3 que es la última versión de p vroot(v2) devuelve p que es el objeto inic. de quien deriva

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) Más rápido para obtener el nombre del abuelo de ‘Pepe Sala’ En OO: si sabemos que su OID está almacenado en la variable pepe: persistent persona * pepe; pepe->padre->padre->nombre Si no conocemos el OID correspondiente a Pepe Sala: for (e in persona) suchthat (strcmp(e->nombre,’Pepe Sala’)!=0) { cout << e->padre->padre->nombre; } En relacional: select p2.nombre from persona p1, padre_de e1, padre_de e2, persona p2 where p1.dni=e1.dni_hijo and e1.dni_padre=e2.dni_hijo and e2.dni_padre=p2.dni and p1.nombre=‘Pepe Sala’ No se eliminan todos los joins. En la pregunta anterior sí pero no en la siguiente: obtener los empleados que se llaman igual que algún jefe. for (e in empleado; j in jefe) suchthat (strcmp(e->nombre,j->nombre)!=0) { ... } -> SELECT * FROM EMPLEADO e, JEFE j WHERE e.nombre=j.nombre Se elimina la necesidad de usar claves DNI necesario en aplicaciones: for (e in persona) suchthat (e->dni = = 18) ... Probablemente será muy interesante definirlo como HASH_TYPE

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. El procesamiento de preguntas viola la encapsulación ya que se acceden a estructuras de datos de la clase. En este caso: nombre de persona. Parece mejor: for (e in persona) suchthat(strcmp(e->nombre,’Pepe’)!=0) ... que: for (e in persona) suchthat(strcmp(e->get_nombre(),’Pepe’)!=0)

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 La tecnología de los sistemas de bases de datos distribuidos es la unión de dos aproximaciones aparentemente opuestas como son los sistemas de bases de datos y las redes de ordenadores. Tradicionalmente se ha entendido que los objetivos fundamentales de los sistemas de bases de datos eran: 1) el control centralizado de los datos y 2) la independencia de datos. Con un control centralizado de los datos es más fácil reducir la redundancia, evitar inconsistencias y mantener la integridad de los datos. Así mismo favorece el segundo gran objetivo que es el proporcionar independencia de datos a las aplicaciones. Aunque debe quedar claro que el control centralizado no garantiza por sí solo todas estas propiedades. El objetivo fundamental de las redes de ordenadores es interconectar ordenadores autónomos para que puedan compartir sus recursos. Uno de los recursos más importante a compartir son los datos. Es posible unir las dos aproximaciones anteriores si se relaja el primero de los objetivos de las bases de datos y se permite un control distribuido de los datos. De esta manera podrá existir redundancia de datos con el fin de aumentar la eficiencia de algunas aplicaciones, pero se deberá controlar el que no haya inconsistencias y que se mantenga la integridad de los datos. Con respecto a la independencia de datos, la centralización de los datos no es un requisito para que las aplicaciones tengan independencia de datos, sino que lo que es un requisito es la integración de los datos, y puede haber integración de datos sin que estén centralizados.

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. Transparencia: separación del nivel más alto (semántico) del nivel más bajo (detalles de implementación), para ocultar los detalles de implementación a los niveles más altos (y a los usuarios). Transparencia  Independencia de datos Independencia de datos: inmunidad de las aplicaciones de usuario respecto a cambios en la definición y/o organización de los datos, y viceversa.

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) Fiabilidad: probabilidad de que un sistema esté en funciones en un momento determinado. Disponibilidad: probabilidad de que el sistema esté disponible continuamente durante un intervalo de tiempo. En un sistema distribuido, si algún nodo falla, los demás no tienen porqué dejar de funcionar.

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 La heterogeneidad semántica puede existir tanto a nivel intensional como a nivel extensional: Ej. sinónimos a nivel intensional: La tabla “alumnos” en BD1 representa la misma abstracción que “estudiantes” en BD2. El atributo ”alumnos.id” es equivalente al atributo “estudiantes.dni” Ej. sinónimos a nivel extensional: El valor “J. Pérez” de “alumnos.nombre” es equivalente al valor “Pérez, J.” de “estudiantes.nombre” La heterogeneidad semántica a nivel extensional nos lleva al difícil problema de la identidad entre objetos de distintas BDs. A veces es imposible según qué campos (ej. nombre, “Javier Pérez” y “J. Pérez”) o difícil de implementar (ej. DNI y #SS).

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. FROM Tanto si existe un esquema global como si no, ofrecemos una visión común al usuario. Solamente que en el primer caso ofrecemos una mayor transparencia de localización que en el segundo caso.

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) 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. Combinando los factores anteriores: distribución, autonomía, distintos tipos de heterogeneidad y existencia o no de un esquema global tenemos diferentes arquitecturas de BD distribuidas. Aquí presentamos tres arquitecturas que consideramos características, pero no son las únicas !!!! Tampoco lo vemos desde un punto de vista comercial. SBDD, SBDI  puede haber sistemas comerciales. Oracle permite ambas arquitecturas, aunque habrá que comprar SQL*Net SBDF  en investigación. Pueden ser muy interesantes porque son apropiadas para trabajar con sistemas legados. Las empresas no tienen que tirar sus BDs sino que se construyen otras BD federadas sobre ellas. Para ello son interesantes las arquitecturas Cliente/Servidor.

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

Diseño de BDs Distribuidas
Es necesario un sistema de gestión de BD Distribuidas que realice lo siguiente: procesamiento de preguntas mantenimiento de la consistencia si hay replicación de datos control de transacciones etc... En algunos casos (determinados SBDD, SBDI) se podrá comprar, pero no siempre (SBDF)

Diseño top-down de BDD Esquema Global Información de Acceso
(transacciones) FRAGMENTACIÓN Esquema Local 1 Esquema Local N Esquema Físico 1 Esquema Físico N DISEÑO FÍSICO ASIGNACIÓN Esquema Global Fragmentado Se obtienen los esquemas locales a partir del esquema global en dos pasos: Fragmentación Asignación Se distribuyen (o asignan) los fragmentos y no las tablas enteras (aunque puede haber fragmentos compuestos de una tabla entera).

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 horizontal: basada en encontrar condiciones de selección
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) Regla del puzzle:

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 Si hay más actualizaciones que preguntas, entonces la replicación será menos ventajosa.

Asignación (y II) REPLICACIÓN COMPLETA REPLICACIÓN PARCIAL SIN
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 N en un modelo canónico Esquema Local 1 en un modelo canónico En realidad, en los SBDF se habla de una arquitectura de cinco niveles: Vista 1 del esq.global Vista j del esq. global Esquema global Esquema canónico 1 Esquema canónico i Esquema exportado 1 Esquema exportado i Esquema local 1 Esquema local i TRADUCCIÓN TRADUCCIÓN Esquema Local N Esquema Local 1

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 Entidad-Relación Extendido de Chen Traducción A partir de tablas y atributos relacionales (esquema exportado) se identifican entidades, relaciones y atributos (enriquecimiento semántico) Pueden aparecer nuevas entidades (especializaciones/generalizaciones, etc.) Integración Aplicación de las propiedades semánticas entre las entidades y relaciones de distintos esquemas locales canónicos (sinonimia, unión, generalización/especialización, etc.)

Uso del esquema global Procesamiento de preguntas
Las preguntas realizadas sobre el esquema global deben responderse sobre los esquemas locales Información de enlace Relación entre los elementos de datos del esquema global y los elementos de datos de los esquemas locales Necesaria para poder responder a las preguntas La información de enlace se contruye durante las fases de traducción e integración: Traducción: se describe la relación del esquema local con el esquema local canónico. Integración: se combina la información de enlace de cada esquema local canónico según la semántica con la que se combinan los elementos de datos durante la integración. Ejemplo Esquemas locales: BD1.estudiantes(nombre, dni, curso) BD2.alumnos(id, nombre, tutor) Esquemas canónicos en E/R Extendido: estudiantes (Inf. enlace: BD1.estudiantes) alumnos (Inf. enlace BD2.alumnos) est-2ºciclo (Inf. enlace: SELECT * FROM BD1.estudiantes WHERE curso>3) Esquema global o integrado (estudiantes se ha definido como sinónimo de alumnos): estudiantes (Inf. enlace: SELECT nombre, dni, curso, NULL from BD1.estudiantes UNION SELECT nombre, id, NULL, tutor from BD2.alumnos) est-2ºciclo (Inf. enlace: SELECT * FROM BD1.estudiantes WHERE curso>3)

Optimización de pregs. en BDD
Pregunta sobre relaciones distribuidas DESCOMPOSICIÓN Esquema Global Pregunta en álgebra relacional sobre relaciones distribuidas Esquema de Fragmentos LOCALIZACIÓN DE DATOS Pregunta sobre fragmentos Estadísticas sobre Fragmentos OPTIMIZACIÓN GLOBAL DESCOMPOSICIÓN --> La pregunta se normaliza, analiza, simplifica y finalmente se expresa como una pregunta en términos del álgebra relacional. En este momento se pueden aplicar reglas de transformación sintácticas que eviten ciertas evaluaciones de la pregunta que serían poco eficientes. LOCALIZACIÓN DE DATOS --> Las relaciones que aparecen en la pregunta expresada en el álgebra relacional están distribuidas y fragmentadas en distintos nodos. Si se le añade a la pregunta la información de dónde se encuentra cada relación o qué fragmentos tiene cada relación entonces se obtiene la pregunta fragmentada. OPTIMIZACIÓN GLOBAL --> El objetivo es encontrar una estrategia de ejecución cercana a la óptima para dicha pregunta fragmentada. Es importante encontrar el mejor orden de ejecución de las operaciones en la pregunta fragmentada y operaciones de comunicación (enviar y recibir) de resultados intermedios entre los distintos nodos en los que se encuentran los fragmentos. La función de costo a optimizar tiene que tener en cuenta diversos factores como son el espacio en disco necesario, disponibilidad de buffers, costo de E/S, costo de CPU y costo de comunicación. Para ello hay que tener información sobre estadísticas de los fragmentos y sobre los resultados (sus tamaños) de operaciones intermedias. Esto último es importante fundamentalmente para calcular el orden óptimo de ejecución de los joins o para decidir ejecutar los joins mediante la técnica de semijoins. 1) Orden óptimo de joins: T1 JOIN T2 ... JOIN TN. Depende de los tamaños de TODOS LOS JOINS INTERMEDIOS (Ti JOIN Tj JOIN Tk) que pueden crecer o decrecer, esto es, no dependen totalmente del tamaño de los operandos. 2) Ejecutar joins mediante semijoins: Para ejecutar AB = A JOIN B con A.a=B.a 1.- Ejecutar R = PROYECTAR A.a (A) y mandarlo al nodo de B 2.- Ejecutar en nodo de B el semijoin S = R JOIN B y mandarlo al nodo de A 3.- Ejecutar finalmente el join SR = S JOIN A equivalente a A JOIN B Es mejor si: Ccpu(R)+Ccom(R)+Ccpu(S)+Ccom(S)+Ccpu(SR) < Ccom(B) + Ccpu(AB) OPTIMIZACIÓN LOCAL --> Cada subpregunta que forma parte de la pregunta fragmentada se puede optimizar en cada nodo local de la misma manera que se optimizan las preguntas en sistemas centralizados (índices, etc...) Pregunta sobre fragmentos y operaciones de comunicación OPTIMIZACIÓN LOCAL Esquema Local Preguntas locales optimizadas

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 El coordinador generalmente es el nodo donde se lanza la transacción distribuida inicial. Si se cae alguno de los nodos cuando el coordinador ha ordenado un commit global, entonces, el coordinador no recibirá todos los acknowledge finales. En ese caso, él se tendrá que encargar de ordenar que se ejecute la transacción que no se terminó de ejecutar. Además hay que tener en cuenta que hay que recuperarse en el caso en que CAIGA EL COORDINADOR!! Supongamos que el coordinador se cae mientras está ordenando que definitivamente se haga el commit. Entonces es posible que algunos se hayan enterado pero que otros no. Entonces aquellos nodos que no reciban respuesta del coordinador podrían preguntar a los otros nodos a ver si saben qué ha dicho el coordinador. Además habría que escoger un nuevo coordinador. Hay distintas técnicas para escoger un nuevo coordinador. Existe también un protocolo de commit en 3 fases que evita que tras la fase de votación se queden esperando los procesos a ver qué es lo que dice el coordinador. Todavía este problema es objeto de investigación.

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 Tenemos una BD con información sobre productos: BD productos Cod Nombre Stock Stock_min H3 Lavadora ACME Si se desea que cuando se cumpla Stock < Stock_min se pidan más, entonces: 1) Hacerlo en todas las aplicaciones que modifiquen el stock. Aplicación: Venta si para el producto vendido se cumple Stock < Stock_min entonces “pedir más” Aplicación: Envío de productos a otra tienda (de la misma cadena) si para el producto enviado se cumple Stock < Stock_min 2) O si no, realizar un programa que sondee esas condiciones: para todo producto si Stock < Stock_min entonces “pedir más” Si el programa de sondeo se ejecuta cada minuto es posible que se ralentice todo el sistema. ¡Una operación de venta podría tener que esperar! Si el programa de sondeo se ejecuta a las noches entonces no se ralentizará el sistema (la tienda estará cerrada) pero... ¡ igual se quedan sin lavadoras para vender a la tarde !

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) En Sistemas Expertos: BASE DE HECHOS BASE DE REGLAS Reglas: IF condición THEN acción las cuales modifican la Base de Hechos. Existe un motor de inferencia que aplica las reglas y que decide qué regla hay que aplicar cuando existe un conjunto conflicto de reglas que se pueden aplicar a la vez. Cuando queremos expresar secuencialidad en las reglas (primero que se ejecute una y luego otra, etc.) hay que añadir condiciones en las reglas para conseguirlo. Podemos meternos en ciclos infinitos de reglas que se activan, etc. Programar BIEN con reglas puede ser complicado ya que unas disparan a otras. Ahora volvemos a algo parecido: BASE DE DATOS BASE DE REGLAS ECA que modifican la BASE DE DATOS. Existirá el problema de que ciertas modificaciones activarán otras reglas ECA (o triggers). En ORACLE tendremos el problema de las tablas mutantes.

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. 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 Ejemplos: ON acceso al salario de los empleados IF usuario no autorizado THEN rechazar el acceso ON cambio en el salario de un empleado IF el nuevo salario es menor que el que existía THEN rechazar la operación ON último día de mes IF true THEN imprimir las nóminas ON cambio en la tarea asignada a un empleado THEN introducir datos en una tabla histórica

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

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

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

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

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

Bases de Datos Deductivas

BD Deductivas: Motivación
La lógica como lenguaje de preguntas. Los predicados corresponderían a relaciones. vuelo(1,‘Madrid’,’París’,’13:30’,’15:30’). Las reglas corresponderían a defs. de vistas. vuelo_Mad_tarde(N,S,L,HS,HL) :- vuelo(N,’Madrid’,L,HS,HL), HS > ‘14:00’. La conjunción de predicados a demostrar serían las preguntas. :- vuelo(N,’Madrid’,L,HS,HL), HS > ‘14:00’. Se puede utilizar encadenamiento hacia delante o hacia atrás 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) Para hacerlo en un programa: vuelo_compuesto <-- 0 vuelos <-- SELECT ciudadsal FROM VUELOS mientras NO_VACIO(vuelos) hacer v <-- PRIMERO(vuelos) {Y sacarlo de vuelos} sale_de <-- ciudad_sal(v) x <-- SELECT ciudadlleg FROM VUELOS WHERE ciudadsal=:sale_de quitar de x las ciudades tales que x está en escalas(v) {Para evitar ciclos} para cada ciudad c en x hacer AÑADIR(vuelos_compuestos,concatena(v,c)) AÑADIR(vuelos, concatena(v,c)) fmientras En vuelo_compuesto tenemos todos los vuelos compuestos.

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 Un ejemplo de lo de clausura transitiva podría ser: Tabla: ES_PADRE(Chijo,Cpadre) Pregunta: obtener los antepasados del hijo núm. 75 SELECT Cpadre FROM ES_PADRE p1, ES_PADRE p2 WHERE p1.Chijo=75 and IgualRec(p1.Cpadre,p2.Chijo)

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

Bases de Datos Avanzadas

Presentaciones similares

Presentación del tema: "Bases de Datos Avanzadas"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Bases de Datos Avanzadas

Presentaciones similares

Presentación del tema: "Bases de Datos Avanzadas"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback