Está en la página 1de 5

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