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.
*Bases de Datos Federada
Un sistema de bases de datos federadas es una colección de sistemas de bases de
datos cooperativos y autónomos [Bhavani99]. En un sistema federado los usuarios
tienen acceso a los datos, de los distintos sistemas, a través de una interfaz
común sin embargo, no existe un esquema global que describa a todos los datos
de las distintas bases de datos, en su lugar hay varios esquemas unificados,
cada uno describiendo porciones de bases de datos y archivos para el uso de
cierta clase de usuarios [Larson90].
AUTONOMÍA
DE BASES DE DATOS.
1. Diseño: modelo, lenguaje,
implementación.
2. Comunicación: como, cuando
se responde a otros sistemas.
3. Ejecución: Criterio a
seguir en la toma de decisiones.
4. Asociación: decisión de que
datos se comparten y a quien.
*Base de
Datos No Federado
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 un sistema de 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 último, 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 NoMatricula, 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 de Multibase de Datos.
Las BDs 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.
Referencia:
- Introducción
a los Sistemas de Bases de Datos. C. J. Date. Pearson Educación. 2001.
[Date, 2001]
- Database
Systems. The Complete Book. H. García-Molina, J.D. Ullman y J. Widom.
Prentice-Hall. 2002. [García-Molina y otros, 2002]
- Fundamentos
de Sistemas de Bases de Datos. R.A. Elmasri y S.B. Navathe. Pearson
Educación. 2002. [Elmasri y Navathe, 2002]
