ROL DE LAS BASES DE DATOS EN EL SISTEMA DELTA-PENSUM Prof. María Esther Vidal mvidal@ldc.usb.ve

Que vamos a considerar: Que se quiere llegar: Seleccion de una tecnologia que permita implantar de la mejor manera la base de datos del sistema de Delta-Pensum. Que se ha considerado: JDBC. XML Comparacion de DBMS. Comparacion entre JDBC y XML. Que vamos a considerar: Diferentes tecnicas para el diseno e implantacion de bases de datos. Serializacion. Arquitectura de Wrappers-Mediators.

Que es un Manejador de Bases de Datos? Que es un Base de Datos? Que es un Manejador de Bases de Datos? Funcionalidades de un Manejador de Bases de Datos: Recuperacion. Integridad. Concurrencia. Seguridad. Manejo Eficiente de los datos. Optimizacion de Consultas. Cuando se requieren las funcionalidades de un Manejador de Bases de Datos?

Base de Datos de los expedientes academicos: Propiedades. Implementaciones. Problemas. Sistemas que interactuan con la BD. Transacciones.(Recomendacion-Modificacion del Pensum)

BASE DE DATOS DE LOS EXPEDIENTES ACADEMICOS PROPIEDADES No es estática, evoluciona constantemente. Al ocurrir ciertos eventos puede cambiar. Rica en restricciones de integridad. Acceso restringido a los datos. Resultados de transacciones debe ser Perdurable.

BASE DE DATOS DE EXPENDIENTE ACADEMICO IMPLEMENTACIONES En este momento existen dos bases de datos que mantienen algunos de los datos del universo de discurso de los expedientes académicos. BD1: Ofertas y Pensum de las diferentes Ofertas. Implementado sobre BD2: Historial de los estudiantes. Implementado con archivos planos

BASE DE DATOS DE EXPEDIENTES ACADEMICOS PROBLEMAS Modificaciones Costosas. Captura de solo algunas de las Restricciones de Integridad. Facilmente violable. Conflictos estructurales y semánticos entre BD1 y BD2. No se garantiza la persistencia de los datos. Acceso no eficiente a los datos. La especificación de las consultas podría ser más legible.

Sistemas que interactúan con la Base de Datos de Expediente Académico Delta Pensum CAPSULA

TRANSACCIONES: (Propiedades ACID) Atomicidad. Consistencia. aIslamiento. Durabilidad Como se garantiza el control de las transacciones en Delta-Pensum?

JDBC: XML: Qué es? Propiedades. Por qué puede ser relevante para resolver los problemas existentes en la implantación de la Base de Datos de los expedientes académicos? XML:

Seralización (Manejo de Objetos Persistentes): Almacenar y Recuperar el estado de los objetos de una cierta clase. No ofrece: mecanismos eficientes de busqueda de objetos Recuperación. Concurrencia. Integridad

Ventajas y Desventajas de cada solución propuesta: Manejar la BD haciendo uso de un Manejador de BD. El manejador puede ser Relacional, Orientado por Objetos, Semi-estructurado. Acceder la BD via OBDC o JDBC. Acceder las BD’s haciendo uso de servidor de aplicaciones.(WebLogic) Acceder las BD’s haciendo un mediador. Especificar la BD haciendo uso de XML. Manipular la BD haciendo uso de las interfaces de manipulacion de documentos XML. (DOM y SAX)

Serialización: No existe discordancia entre la implementación de la aplicación y la implementación de la base de datos. Se deben implementar librerías para manejar los datos: Recuperación. Concurrencia. Integridad. Seguridad. Optimizacion de su acceso.

Arquitectura de Mediators-Wrappers: Consulta Mediador Mediador FD:Fuente de Datos Wrapper Wrapper Wrapper FD FD FD

INTEGRACION DE FUENTES DE DATOS HETEROGENEAS FD1: Programación de todos los canales ofrecidos por alguna compañía de cable. Fuente de Datos en el Web, resultado ofrecido como documento HTML. FD2: Los precios de los diferentes planes que ofrecen las diferentes compañías de cable. Fuente de Datos almacenada en archivos planos FD3: Para cada canal las compañías de cable que lo ofrecen. Fuente de Datos almacenada en un manejador de BD relacional.

Se desea responder consultas del tipo: “Los programas que serán transmitidos por los canales ofrecidos por CABLEVEN en le plan básico el día 26-01-2001 a las 7:30pm” Alternativas para resolver este tipo de requerimiento funcional: Integración de las fuentes de datos FD1, FD2, FD3 (DatawareHouse). Implementación de un programa que sea capaz: Acceder FD1,FD2,FD3 Integrar la información que proviene de FD1,FD2,FD3.

Implementar un componente de software basado en la arquitectura de Mediators-Wrappers. Cada mediator maneja un esquema de datos común capaz de representar los datos ofrecidos por cada fuente de datos. Por cada fuente de datos existe un wrapper: Conoce el esquema de datos de su correspondiente fuente de datos. Traduce los datos almacenados en la fuente de datos en el esquema de datos existente en el mediator. Ofrece una interfaz común al mediator la cual es independiente de la fuente de datos que esté envolviendo. Es transparente para el mediador el modelo de datos, lenguaje de interrogación y el esquema de datos, utilizado por cada fuente de datos. Es transparente para wrapper los problemas de integración de los datos que provienen de cada fuente de datos.

Arquitectura de Mediators-Wrappers. Cada mediator: Determina las fuentes a ser consultadas para responder una consulta. Determina las sub-consultas a ser enviadas a cada fuente. Optimiza los planes de ejecución de las consultas que requieren consultar varias fuentes. Integra los datos provenientes de las fuentes de datos (resolución de conflictos semánticos). Cada wrapper: Optimiza las consultas a ser enviadas a una fuente. Traduce las consultas enviadas por el mediador en consultas que puedan ser ejecutadas por la fuente de datos.

REFERENCIAS BIBLIOGRAFICAS: 1) Sun Microsystems The JDBC database access API. Disponible en: http://splash.javasoft.com/jdbc 2) W3C. Extensible Markup Language (XML) 1.0. W3C Recommendation. Disponible en: http://www.w3.org/TR/1998/REC-xml-19980210. 3) G. Wiederhold. “Mediators in the architecture of future information systems” IEEE Computer, 25(3):38-39, Marzo 1992. 4) Raghu Rama