Unidad 3. Sistemas Multibase de Datos

3.1 Características y Clasificación

Un sistema multibase de datos (SMulBD) soporta operaciones en múltiples sistemas de base de datos componentes (SBDC). Cada SBDC es manejado por un sistema manejador de base de datos (SMBD). Un SBDC en un SMulBD puede ser centralizado o distribuido y puede residir en la misma computadora o en múltiples computadoras conectadas por un subsistema de comunicación. Un SMulBD es llamado homogéneo si todos los SMBD componentes son iguales; si son diferentes entonces es llamado un SMulBD heterogéneo.

Un SMulBD puede ser clasificado en dos tipos basados en la autonomía de la SBDCs: sistemas de base de datos no-federada y sistemas de base de datos federada.

Sistema de Base de Datos No-Federada

Un sistema de base de datos no federado es una integración de SMBDs componentes que no son autónomos. Esto significa que los SBDCs al participar en una federación pierden su autonomía y cualquier operación debe hacerse sobre la base de datos global. Un sistema de este tipo no distingue entre usuarios locales y usuarios no-locales. Un tipo particular de sistema de base de datos no-federado en el cual todas las bases están completamente integradas para proveer un esquema global simple puede ser llamado SMulBD unificado. Esto lógicamente parece a los usuarios como un sistema de base de datos distribuida.

3.2 Arquitectura de Sistema Multibase de Datos

Un esquema global en los SBDFs fuertemente acoplados es el resultado de la integración de los esquemas de exportación de las bases de datos componentes. Un lenguaje de consulta global es utilizado por los usuarios del sistema de base de datos federada para especificar consultas contra el esquema global.

Para procesar una consulta global, la consulta primero es analizada y después descompuesta en unidades de consulta las cuales son representadas en la forma de un grafo de unidades de consulta. El Generador del Plan de Ejecución construye subconsultas a partir del grafo de unidades de consulta y estima su costo de ejecución. El plan de consulta con el costo estimado mínimo será enviado al despachador el cual será el encargado de coordinar la ejecución de las consultas. Por ultimo los resultados de las consultas son combinados para construir los resultados de la consulta global. 

3.3 Procesamiento de operaciones de actualización

Todas las operaciones financieras relativas a la gestión de un pedido se almacenan temporalmente en un fichero de pagos hasta que se lleva a cabo su procesamiento. Es en este momento cuando los datos se actualizan en los campos correspondientes de los ficheros del sistema y todas las transacciones realizadas pasan al fichero histórico de pagos. Asimismo, al procesar las operaciones toda la información relativa a ellas debe imprimirse necesariamente. 

El procesamiento de las operaciones (que se realizará de forma centralizada en los Servicios Centrales), tiene una importancia, pues, fundamental para la correcta gestión de las adquisiciones, por lo que hemos decidido dedicarle un apartado independiente. 

3.4 Procesamiento de Consultas

El proceso de consultas en bases de datos relacionales deja al programador de aplicaciones en  un escenario distinto al anterior; la razón es el empleo de lenguajes de especificación: “si se utiliza un lenguaje de especificación el programador no tiene que diseñar ni generar  un método para ejecutar la especificación o consulta requerida”, es decir el  programador es introducido en un escenario “no procedural”, “no está obligado a crear  métodos ni procedimientos para obtener los datos, sólo a especificar los datos que  requiere”. Ejemplo: si en un programa de aplicación se inserta una instrucción SQL del tipo: 

SELECT NºMatricula,Nombre,Asignatura,Nota FROM notas WHERE curso= “3º”. 

Lo único que está aportando el programador es la especificación de los datos requeridos  (¿qué datos requiere?), pero a diferencia de la obtención de datos en un ambiente de archivos  convencionales no especifica el algoritmo o método de obtención (¿cómo o por qué camino obtenerlos?).

3.5 Aplicaciones multibase de datos

Las BD’s Heterogéneas o Multibase de Datos son aquellas donde Sitios diferentes utilizan diferentes DBMS’s, siendo cada uno esencialmente autónomo. Es posible que algunos sitios no sean conscientes de la existencia de los demás y quizás proporcionen facilidades limitadas para la cooperación en el procesamiento de transacciones

En las bases de datos distribuidas heterogéneas 

Puede que los diferentes sitios utilicen esquemas y software de gestión de sistemas de bases de datos diferentes. Puede que algunos sitios no tengan información de la existencia del resto y que sólo proporcionen facilidades limitadas para la cooperación en el procesamiento de las transacciones. La heterogeneidad se debe a que los datos de cada BD son de diferentes tipos o formatos. El enfoque heterogéneo es más complejo que el enfoque homogéneo. Hoy en día existe la tendencia a crear software que permita

Tener acceso a diversas bases de datos autónomas preexistentes almacenadas en SGBD heterogéneos.

La Heterogeneidad de las BD es inevitable cuando diferentes tipos de BD coexisten en una organización que trata de compartir datos entre éstas.BDD heterogéneamente:

El tratamiento de la información ubicada en bases de datos distribuidas heterogéneas exige una capa de software adicional por encima de los sistemas de bases de datos ya existentes. Esta capa de software se denomina sistema de bases de datos múltiples. Puede que los sistemas locales de bases de datos empleen modelos lógicos y lenguajes de definición y de tratamiento de datos diferentes, y que difieran en sus mecanismos de control de concurrencia y de administración de las transacciones.