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.
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 los 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 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.
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 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:
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.
REFERENCIAS
http://tbdmontalvogil.blogspot.mx/2013/12/unidad-3-sistemas-multibase-de-datos.html y http://fridafabiolah.galeon.com/smb.htm
No hay comentarios:
Publicar un comentario