ROL DE LAS BASES DE DATOS EN EL SISTEMA DELTA-PENSUM

Prof. María Esther Vidal [email protected]

• 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 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: – 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: – 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?

• 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 FD FD Wrapper 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