Unidad III. Sistemas de 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.

Sheth y Larson [1990] proponen la taxonomía mostrada en la siguiente figura para comparar las arquitecturas de diversos esfuerzos de investigación y desarrollo. Esta taxonomía se enfoca en la dimensión de autonomía.

Clasificación de los Sistemas Multibase de Datos

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.

1. 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.
2. Sistema de Base de Datos Federada: Un sistema de base de datos federada (SBDF) consiste de SBDCs que son autónomos, participan en una federación para permitir compartición parcial y controlada de sus datos. El concepto de autonomía implica que los SBDCs tienen control sobre los datos que ellos manejan. Ellos cooperan para permitir diversos grados de integración. No hay control centralizado en una arquitectura federada debido a que los SBDCs (y sus administradores de base de datos) controlan el accesos a sus datos. Para permitir la compartición controlada de datos mientras preserva la autonomía de los SBDCs y continuar con la ejecución de aplicaciones existentes, un SBDF soporta dos tipos de operaciones: local y global (federación). Esta división de operaciones globales y locales es una característica esencial de un SBDF. Las operaciones globales involucran acceso a los datos usando un sistema manejador de base de datos federado y puede involucrar manejar datos por múltiples SBDCs. Los SBDCs deben dar permisos de accesar los datos que ellos manejan. Las operaciones locales son sometidas aun SBDC directamente. En la mayoría de los ambientes los SBDF también serán heterogéneos, es decir, consistirán de SBDCs heterogéneos.

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.

Arquitectura de un sistema de multibase de datos Federada

Arquitectura de un Sistema de Base de Datos Federada

Sheth y Larson [1990] proponen una arquitectura de 5 niveles de esquemas para un SBDF: esquema local, esquema componente, esquema de exportación, esquema federado y esquema externo:

• Esquema Local. Un esquema local es el esquema conceptual del SBDC.
• Esquema Componente. Un esquema componente es derivado de trasladar el esquema local en un modelo de datos llamado canónico o modelo de datos común.
• Esquema de Exportación. Un esquema de exportación representa un subconjunto de un esquema componente que está disponible para el SBDF.
• Esquema Federado. Un esquema federado es una integración de múltiples esquemas de exportación. Este esquema también incluye la información de la distribución de datos que es generada cuando se integran los esquemas de exportación.
• Esquema Externo. Un esquema externo define un esquema para un usuario y/o aplicación. Este esquema puede ser usado para especificar un subconjunto de la información en el esquema federado.

Arquitectura de un SBDF con 5 niveles de esquemas [ Sheth y Larson 1990]

Un SBDF puede ser categorizado como débilmente acoplado o fuertemente acoplado basado en la idea de quien maneja la federación y como los componentes son integrados.

Sistemas de Base de Datos Federada Débilmente Acoplados

Un SBDF es débilmente acoplado si la responsabilidad de crear y mantener la federación recae en el usuario y no hay control por parte del sistema federado y sus administradores. Litwin et al. [1990] se refiere a este mismo concepto como multibases de datos o bases de datos interoperables. Asumen que los usuarios necesitan accesar múltiples datos sin el beneficio de un esquema global y que el componente esencial de un sistema de este tipo es el lenguaje usado para manejar las bases de datos participantes. Otro requerimiento importante es que el usuario debe ser capaz de formular manipulaciones multibase de datos no procedurales en la ausencia de un esquema global. El usuario es responsable de comprender la semántica de los objetos en los esquemas de exportación y resolver la heterogeneidad de los SMBDs y de la semántica.

El lenguaje multibase de datos debe permitir a los usuarios definir y manipular una colección de bases de datos autónomas en una forma no procedural. Tal lenguaje necesita características que no son parte de lenguajes de bases de datos, esto debido a que los SMBDs clásicos fueron desarrollados para una sola base de datos. En Litwin y Abdellalit [1987] se describen las características de MDSL un lenguaje de manipulación multibase de datos.

Sistemas de Base de Datos Federada Fuertemente Acoplados

Una Federación es fuertemente acoplada si su administrador (es) tiene la responsabilidad de crear y mantener la federación y el control de acceso a los SBDCs. Una federación está compuesta por una integración selectiva y controlada de sus componentes. La actividad de desarrollar un SBDF fuertemente acoplado consiste en la creación de un esquema federado sobre el cual las operaciones (consultas y/o actualizaciones) son ejecutadas.

Un SBDF fuertemente acoplado puede tener uno o más esquemas federados. Un SBDF fuertemente acoplado se dice que tiene una federación sencilla si permite la creación y manejo de solamente un esquema federado. Tener un esquema federado sencillo ayuda a mantener la uniformidad en la interpretación semántica de los datos integrados. Un SBDF fuertemente acoplado se dice que tiene una federación múltiple si permite la creación y manejo de múltiples federaciones. Las restricciones involucradas en múltiples SBDCs, sin embargo, puede ser difícil de imponer.

Un SBDF fuertemente acoplado provee localización, duplicación y transparencia de distribución. Esto es llevado a cabo al desarrollar un esquema federado que integra múltiples esquemas de exportación. Las transparencias son manejadas por los mapeos entre el esquema federado y los esquemas de exportación, y un usuario de la federación puede hacer consultas a través de un lenguaje de consultas clásico contra el esquema federado con la ilusión de que se está accesando un solo sistema [Sheth y Larson 1990].

Debido a que un esquema federado es creado al integrar todos los esquemas de exportación y porque este esquema federado soporta los requerimientos de datos de todos los usuarios, este puede llegar a ser demasiado grande y por tanto difícil de crear y mantener.

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 cuandolos 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 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 delresto 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 BDs 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.