Sunteți pe pagina 1din 4

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.

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.

S-ar putea să vă placă și