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.
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.
PROPIEDADES
- Este tipo de manejadores, tiene un manejo transparente para los usuarios.
- Se aprecia como una sola base de datos. A esto se le conoce como ínter operar y existen tres formas: Distribuidas, federadas o multibase.
- El sistema esta conformado por un conjunto de bases de datos heterogéneas. Esto significa que pueden o no tener diferentes sistemas operativos, diferente equipo de computo(hardware), diferentes manejadores de bases de datos, diferente modelo de datos(J, red, Relacional, orientada a objetos), diferente estructura de datos.
- Las bases de datos que participan en la BDF mantienen su autonomía. Esto quiere decir que cada elemento de la federación decide con quien, que y como compartir sus datos, además de que cada una cuenta con su respectivo diseño de acuerdo con las necesidades del usuario.
- El MBDF(Manejador de Bases de Datos Federadas) recibe una consulta sencilla y este a su vez la descompone en varia consultas parciales.
- El MBDF deberá tener una optimizador de recursos para aprovechar correctamente todos los componentes.
- Pueden ser físicamente distribuidas en diferentes lugares e incluso en lugares muy lejanos.
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 Sistema Multibase de Datos
Los DBMS individuales son totalmente autónomos (en BD distribuidas o no). No tienen idea de la existencia del otro o cómo hablar el uno al otro .
BDF
Son vistas unificadas de bases de datos independientes aparentan ser una sola base de datos, pero son una colección de sistemas de bases de datos independientes, cooperativos, heterogéneos, que son autónomos y que permiten compartir todos o algunos de sus datos.
Se dice que son heterogéneos debido a que los sistemas de bases de datos pueden tener cualquier arquitectura.
Autonomía es que cada sistema de bases de datos funcione por sí mismo y de forma local.
Está formado por varios gestores de bases de datos que pueden ser para bases de datos centralizadas o distribuidas, además pueden ser también sistemas de bases de datos federados.
Problemas:
• Incompatibilidad entre sistemas de consulta diferentes.
• Diferente codificación en los componentes del SGBD.
• Dificultades para establecer un control de las concurrencias en distintas transacciones.
GCS
En DDBMS la GCS define la visión conceptual de la base de datos
°En DMulti-DBMS: - el GCS representa sólo la parte o parte de la base de datos local que debe ser compartida.
°Algunos C / SDBMS ejemplo SYBASE admite consultas y actualizaciones a muchos servidores de bases de datos.
un sistema multi-base de datos es una colección interconectada de bases de datos autónomas.
3.3 Procesamiento de operaciones de actualización
Una transacción es una unidad lógica de trabajo, la cual no necesariamente consta de una sola operación en la base de datos; más bien, es en general una secuencia de varias de esas operaciones mediante la cual un estado consistente de la base de datos se transforma en otro estado consistente, sin conservar por fuerza la consistencia en todos los puntos intermedios. El punto importante aquí es asegurar que la base de datos regresa a un estado consistente al fin de la ejecución de una transacción. Una transacción es también la invocación a un procedimiento remoto (RPC) que ejecuta un conjunto de operaciones sobre una base de datos bajo el principio de todo o nada.
El concepto fundamental aquí es la noción de "ejecución consistente" o "procesamiento confiable" asociada con el concepto de una consulta. El concepto transacción es usado dentro del dominio de la base de datos como una unidad básica de cómputo consistente y confiable
Una transacción posee cuatro propiedades fundamentales
Atomicidad.
Una Transacción es una unidad de trabajo indivisible; la totalidad de sus acciones son un éxito un fracaso ("todo o nada"). Consistencia. Después de ejecuta una Transacción debe dejar al sistema en estado correcto o debe abortarlo. Si la Transacción no puede alcanzar un estado final debe regresar al sistema a su estado original. Aislamiento. El comportamiento de una Transacción no se ve afectado por el hecho de que otras Transacciones puedan estar ejecutándose de manera concurrente; dicho de otra manera, una Transacción no puede revelar sus resultados a otras Transacciones concurrentes antes de su commit. La Transacción debe serializar todos los accesos a recursos compartidos y garantizar que ningún programa concurrente interferirá con sus operaciones respectivas.
Durabilidad.
Los efectos de una Transacción son permanentes después de su grabación. Sus cambios deben sobrevivir a fallas del sistema. (Persistencia). BITÁCORA La operación ROLLBACKesta basada en el uso de una ?bitacora?. El DBMS (Sistema Manejador de Bases de Datos) mantiene una bitácora o diario en cinta o en disco (mas comúnmente), en el cual se registran los detalles de todas las operaciones de actualización, en particular, los valores inicial y final del objeto modificado. Por tanto, si resulta necesario anular alguna modificación específica, el sistema puede utilizar la entrada correspondientede la bitácora para restaurar el valor original del objeto restaurado. PUNTO DE SINCRONIZACION Las operaciones COMMIT y ROLLBACK establecen lo que se le conoce como punto de sincronización lo cual representa el límite entre dos transacciones consecutivas, o el final de una unidad lógica de trabajo, y por tanto al punto en el cual la base de datos esta (o debería estar) en un estado de consistencia. Las únicas operaciones que establecen un punto de sincronización son COMMIT, ROLLBACK y el inicio de una programa. Cuando se establece un punto de sincronización:
Se comprometen o anulan todas las modificaciones realizadas por el programa desde el punto de sincronización anterior. Se pierde todo posible posicionamiento en la base de datos. Se liberan todos los registros bloqueados.
Es importante advertir que COMMIT y ROLLBACK terminan las transacción, no el programa
3.4 Procesamiento de Consultas
OBJETIVOS DEL PROCESAMIENTO DE CONSULTAS
Los objetivos del procesamiento de consultas son transformar una consulta escrita en un lenguaje de alto nivel, normalmente SQL, en una estrategia de ejecución correcta y eficiente expresada en un lenguaje de bajo nivel, por ejemplo, el álgebra relacional, y ejecutar dicha estrategia para extraer los datos solicitados.
¿En qué sentido difiere el procesamiento de consultas en los sistemas relacionales del procesamiento de lenguajes de consultas de bajo nivel para sistemas de red jerárquicos?
En los sistemas de bases de datos en red y jerárquicos de primera generación, el sistema de consulta procedimental de bajo nivel está generalmente incrustado en un lenguaje de programación de alto nivel tal como COBOL, y es responsabilidad del programador seleccionar la estrategia de ejecución más apropiada.
FASES DEL PROCESAMIENTO DE CONSULTAS
El procesamiento de consultas puede dividirse en cuatro fases principales: Descomposición. Optimización. Generación de código. Ejecución.
La descomposición de consultas transforma una consulta d alto nivel en una consulta de álgebra relacional y comprueba que dicha consulta sea sintáctica y semánticamente correcta. Las etapas típicas de la descomposición de consultas son:
ETAPAS DE LA DESCOMPOSICIÓN DE CONSULTAS
Análisis Normalización. Análisis semántico. Simplificación. Reestructuración de la consulta.
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.
No hay comentarios:
Publicar un comentario