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
Estructura 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 Base de Datos
Diseño: modelo,
lenguaje, implementación.
Comunicación:
como, cuando se responde a otros sistemas.
Ejecución:
Criterio a seguir en la toma de decisiones.
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 está conformado por un conjunto
de bases de datos heterogéneas. Esto significa que pueden o no tener diferentes
sistemas operativos, diferente equipo de cómputo(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 un 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
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.
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 ROLLBACK está basada en el uso de una
bitácora. 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 correspondiente de
la bitácora para restaurar el valor original del objeto restaurado. PUNTO DE
SINCRONIZACIÓN 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 está (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 un 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 transacciones, no el programa.
El procesamiento de consultas en
un sistema multibase de datos es la pieza mas importante para la operación del
sistema. En este capítulo se describe la arquitectura general de un procesador
de consultas multibase de datos. Se mencionan los módulos que integran un
procesador de este tipo y la función que deben llevar a cabo. A grandes rasgos
tres pasos son necesarios para procesar una consulta global [Evrendilek y Dogac
1995]:
Primero una consulta global es
descompuesta en subconsultas de manera que los datos necesitados por cada
subconsulta estén disponibles desde cada SBDC (sistema de base de
datos componente). Después cada
subconsulta es trasladada a una consulta o consultas de el SBDC y enviada (s)
al SBDC. Tercero, los resultados retornados por las subconsultas son combinados
para dar respuesta a la consulta global. El procesamiento de consultas es uno
de los aspectos mas complejos dentro de un sistema multibase de datos. Aunque
esto debiera parecerse
a un sistema de bases de datos
distribuido existen diferencias debido a que los SBDCs de un
sistema multibase de datos
normalmente son heterogéneos y poseen distintas capacidades de procesamiento.
De esta manera el procesamiento y la optimización de consultas resulta mas
difícil que en un sistema de base
de datos distribuido. Las capacidades de procesamiento de
consultas de los sistemas de base
de datos componentes (SBDCs) pueden variar grandemente, las cuales van desde sistemas
de bases de datos orientadas a objetos y sistemas de base de datos relaciónales
hasta sistemas de archivos. El optimizador de consultas global debe descomponer
una consulta global en consultas componentes para ser procesadas por los SBDCs.
Este también debe determinar cómo y donde ejecutar algún procesamiento de integración
que sea necesario. Para llevar a cabo operaciones de optimización el procesador
de la consulta debe de conocer las
capacidades de cada SBDC para
elegir el mejor plan de ejecución [Attaluriet al. 1995]
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.
PACHECO BOLAINA IVÁN MANUEL
GUZMAN OLAN ALEJANDRO
CHULIN LARA JOEL
VITE LURIA GENARO
PACHECO BOLAINA IVÁN MANUEL
GUZMAN OLAN ALEJANDRO
CHULIN LARA JOEL
VITE LURIA GENARO
