Sistema de base de datos federada

Un sistema de base de datos federada ( FDBS ) es un tipo de sistema de gestión de bases de datos (DBMS) meta , que mapea de forma transparente múltiples sistemas de bases de datos autónomos en una única base de datos federada . Las bases de datos constituyentes están interconectadas a través de una red informática y pueden estar geográficamente descentralizadas. Dado que los sistemas de bases de datos constituyentes permanecen autónomos, un sistema de base de datos federada es una alternativa viable a la (a veces compleja) tarea de fusionar varias bases de datos dispares. Una base de datos federada, o base de datos virtual , es una composición de todas las bases de datos constituyentes en un sistema de base de datos federada. No existe una integración real de datos en las bases de datos dispares constituyentes como resultado de la federación de datos.

Mediante la abstracción de datos , los sistemas de bases de datos federadas pueden proporcionar una interfaz de usuario uniforme , lo que permite a usuarios y clientes almacenar y recuperar datos de múltiples bases de datos no contiguas con una sola consulta , incluso si las bases de datos constituyentes son heterogéneas . Para ello, un sistema de bases de datos federadas debe ser capaz de descomponer la consulta en subconsultas para enviarlas a los sistemas de gestión de bases de datos (DBMS) constituyentes correspondientes , tras lo cual el sistema debe combinar los conjuntos de resultados de las subconsultas. Dado que los distintos sistemas de gestión de bases de datos emplean diferentes lenguajes de consulta , los sistemas de bases de datos federadas pueden aplicar adaptadores a las subconsultas para traducirlas a los lenguajes de consulta apropiados .

Definición

McLeod y Heimbigner ^{[ 1 ]} fueron de los primeros en definir un sistema de base de datos federada a mediados de la década de 1980.

Una FDBS es aquella que "define la arquitectura e interconecta bases de datos que minimizan la autoridad central, pero que permiten el intercambio parcial y la coordinación entre sistemas de bases de datos". ^{[ 1 ]} Esta descripción podría no reflejar con precisión la definición de McLeod/Heimbigner ^{[ 1 ]} de una base de datos federada. Más bien, esta descripción se ajusta a lo que McLeod/Heimbigner denominaron una base de datos compuesta . La base de datos federada de McLeod/Heimbigner es una colección de componentes autónomos que ponen sus datos a disposición de otros miembros de la federación mediante la publicación de un esquema de exportación y operaciones de acceso; no existe un esquema central unificado que abarque la información disponible de los miembros de la federación.

Entre otras encuestas, ^{[ 2 ]} los profesionales definen una base de datos federada como una colección de sistemas componentes cooperativos que son autónomos y posiblemente heterogéneos .

Los tres componentes importantes de un FDBS son autonomía, heterogeneidad y distribución. ^{[ 2 ]} Otra dimensión que también se ha considerado es el entorno de red de la red informática , por ejemplo, muchos DBS sobre una LAN o muchos DBS sobre una WAN actualizan las funciones relacionadas de los DBS participantes (por ejemplo, sin actualizaciones, transiciones no atómicas, actualizaciones atómicas ).

Arquitectura FDBS

Un sistema de gestión de bases de datos ( DBMS ) puede clasificarse como centralizado o distribuido. Un sistema centralizado gestiona una única base de datos, mientras que uno distribuido gestiona varias. Un componente de base de datos en un DBMS puede ser centralizado o distribuido. Un sistema de bases de datos múltiples (MDBS) se clasifica en dos tipos según la autonomía de sus componentes: federado y no federado. Un sistema de bases de datos no federado integra componentes de DBMS que no son autónomos. Un sistema de bases de datos federado consta de componentes autónomos que participan en una federación para compartir sus datos de forma parcial y controlada.

Las arquitecturas federadas difieren según el nivel de integración con los sistemas de bases de datos componentes y el alcance de los servicios que ofrece la federación. Un sistema de bases de datos federadas (FDBS) puede clasificarse como sistemas débilmente o fuertemente acoplados.

El acoplamiento flexible requiere que las bases de datos de los componentes construyan su propio esquema federado . Normalmente, un usuario accede a otros sistemas de bases de datos de componentes mediante un lenguaje multidatabase, pero esto elimina cualquier nivel de transparencia de ubicación, obligando al usuario a tener conocimiento directo del esquema federado. El usuario importa los datos que necesita de otras bases de datos de componentes y los integra con los suyos para formar un esquema federado.
Un sistema estrechamente acoplado consta de sistemas componentes que utilizan procesos independientes para construir y divulgar un esquema federado integrado.

Los sistemas de bases de datos múltiples, de los cuales los sistemas de bases de datos de dominio completo (FDBS) son un tipo específico, pueden caracterizarse según tres dimensiones: distribución, heterogeneidad y autonomía. Otra caracterización podría basarse en la dimensión de la red, por ejemplo, bases de datos individuales o múltiples bases de datos en una LAN o WAN.

Distribución

La distribución de datos en un sistema de bases de datos distribuidas (FDBS) se debe a la existencia de múltiples sistemas de bases de datos (DBS) previos a su construcción. Los datos pueden distribuirse entre varias bases de datos, las cuales pueden almacenarse en uno o varios ordenadores. Estos ordenadores pueden estar ubicados geográficamente en diferentes lugares, pero interconectados por una red. Las ventajas de la distribución de datos incluyen una mayor disponibilidad y fiabilidad, así como tiempos de acceso mejorados.

Heterogeneidad

Las heterogeneidades en las bases de datos surgen debido a factores como diferencias en las estructuras, la semántica de los datos, las restricciones admitidas o el lenguaje de consulta . Las diferencias en la estructura ocurren cuando dos modelos de datos proporcionan primitivas diferentes, como los modelos orientados a objetos (OO) que admiten especialización y herencia y los modelos relacionales que no. Las diferencias debidas a las restricciones ocurren cuando dos modelos admiten dos restricciones diferentes. Por ejemplo, el tipo de conjunto en el esquema CODASYL puede modelarse parcialmente como una restricción de integridad referencial en un esquema de relación. CODASYL admite inserción y retención que no se capturan solo con la integridad referencial. El lenguaje de consulta admitido por un DBMS también puede contribuir a la heterogeneidad entre otros DBMS componentes . Por ejemplo, las diferencias en los lenguajes de consulta con los mismos modelos de datos o diferentes versiones de lenguajes de consulta podrían contribuir a la heterogeneidad .

Las heterogeneidades semánticas surgen cuando existe un desacuerdo sobre el significado, la interpretación o el uso previsto de los datos . A nivel de esquema y datos, la clasificación de las posibles heterogeneidades incluye:

Conflictos de nombres, por ejemplo, bases de datos que utilizan nombres diferentes para representar el mismo concepto.
Conflictos de dominio o conflictos de representación de datos , por ejemplo, bases de datos que utilizan valores diferentes para representar el mismo concepto.
Conflictos de precisión, por ejemplo, bases de datos que utilizan los mismos valores de datos de dominios de diferentes cardinalidades para los mismos datos .
Conflictos de metadatos , por ejemplo, los mismos conceptos están representados a nivel de esquema y a nivel de instancia.
Conflictos de datos, por ejemplo, atributos faltantes
Conflictos de esquema, por ejemplo, conflicto entre tablas, que incluye conflictos de nombres, conflictos de datos, etc.

Al crear un esquema federado, es necesario resolver dichas heterogeneidades antes de integrar los esquemas de bases de datos componentes.

Coincidencia de esquemas, mapeo de esquemas

Lidiar con tipos de datos o sintaxis de consulta incompatibles no es el único obstáculo para una implementación concreta de un FDBS. En sistemas que no se planifican de arriba hacia abajo, un problema genérico radica en hacer coincidir partes semánticamente equivalentes , pero con nombres diferentes, de diferentes esquemas (=modelos de datos) (tablas, atributos). Un mapeo por pares entre n atributos daría como resultado $n(n-1) \over 2$ Reglas de mapeo (mapeos de equivalencia dados): un número que rápidamente se vuelve demasiado grande para fines prácticos. Una solución común es proporcionar un esquema global que comprenda las partes relevantes de todos los esquemas miembros y proporcionar mapeos en forma de vistas de base de datos . Dos enfoques principales dependen de la dirección del mapeo:

Global como Vista (GaV): el esquema global se define en términos de los esquemas subyacentes.
Local como Vista (LaV): los esquemas locales se definen en términos del esquema global.

Ambos son ejemplos de integración de datos , lo que se conoce como el problema de la coincidencia de esquemas .

Autonomía

Fundamental para la diferencia entre un MDBS y un FDBS es el concepto de autonomía. Es importante comprender los aspectos de autonomía para las bases de datos componentes y cómo se pueden abordar cuando una base de datos componente participa en un FDBS. Se abordan cuatro tipos de autonomía:

Autonomía de diseño, que se refiere a la capacidad de elegir su diseño independientemente de los datos, el lenguaje de consulta o la conceptualización, funcionalidad de la implementación del sistema.

Las heterogeneidades en un FDBS se deben principalmente a la autonomía del diseño.

La autonomía de comunicación se refiere al funcionamiento general del sistema de gestión de bases de datos (DBMS) para comunicarse o no con otros sistemas de gestión de bases de datos .
La autonomía de ejecución permite que un componente del sistema de gestión de bases de datos (DBMS) controle las operaciones solicitadas por las operaciones locales y externas.
La autonomía de la asociación otorga a los DBS componentes la facultad de desvincularse de una federación, lo que significa que los FDBS pueden operar independientemente de cualquier DBS individual .

El Grupo de Estudio ANSI/X3/SPARC definió una arquitectura de descripción de datos de tres niveles, cuyos componentes son el esquema conceptual, el esquema interno y el esquema externo de las bases de datos. Sin embargo, esta arquitectura de tres niveles resulta insuficiente para describir las arquitecturas de un sistema de bases de datos distribuidas (FDBS). Por consiguiente, se amplió para dar soporte a las tres dimensiones del FDBS: distribución, autonomía y heterogeneidad. La arquitectura de esquema de cinco niveles se explica a continuación.

Control de concurrencia

Los requisitos de heterogeneidad y autonomía plantean desafíos especiales en lo que respecta al control de concurrencia en un FDBS, que es crucial para la correcta ejecución de sus transacciones concurrentes (véase también Control de concurrencia global ). Lograr la serializabilidad global , el principal criterio de corrección, bajo estos requisitos se ha caracterizado como muy difícil y aún no resuelto. ^{[ 2 ]}

Arquitectura de esquema de cinco niveles para FDBS

La arquitectura de esquema de cinco niveles incluye lo siguiente:

El esquema local es básicamente el modelo conceptual de una base de datos de componentes expresado en un modelo de datos nativo. ^{[ 3 ]}
El esquema de componentes es el subconjunto del esquema local que la organización propietaria está dispuesta a compartir con otros usuarios del FDBS y se traduce en un modelo de datos común . ^{[ 3 ]}
El esquema de exportación representa un subconjunto de un esquema de componente disponible para una federación específica. ^{[ 3 ]} Puede incluir información de control de acceso relativa a su uso por parte de un usuario específico de la federación. El esquema de exportación ayuda a gestionar el flujo de control de los datos.
El esquema federado es una integración de múltiples esquemas de exportación. Incluye información sobre la distribución de datos que se genera al integrar los esquemas de exportación. ^{[ 3 ]}
El esquema externo se extrae de un esquema federado y se define para los usuarios/aplicaciones de una federación en particular. ^{[ 3 ]}

Si bien la arquitectura de esquema de cinco niveles descrita anteriormente representa con precisión el estado del arte en la integración de datos, presenta una desventaja importante: la apariencia impuesta por el departamento de TI. Los usuarios de datos modernos exigen control sobre cómo se presentan los datos; sus necesidades entran en conflicto, en cierta medida, con este tipo de enfoques ascendentes para la integración de datos.

Véase también

Referencias

1 2 3 " McLeod y Heimbigner (1985). "Una arquitectura federada para la gestión de la información" . ACM Transactions on Information Systems, Volumen 3, Número 3. págs. 253–278 .
1 2 3 " Sheth y Larson (1990). "Sistemas de bases de datos federadas para la gestión de bases de datos distribuidas, heterogéneas y autónomas" . ACM Computing Surveys, vol. 22, n.º 3 , págs. 183-236 .
1 2 3 4 5 Masood, Nayyer; Eaglestone, Barry (diciembre de 2003). "Modelos de conceptos de componentes y federación en un sistema de base de datos federada" (PDF) . Revista Malasia de Ciencias de la Computación . 16 (2): 47– 57. Archivado del original (PDF) el 7 de marzo de 2016. Recuperado el 3 de marzo de 2016 .

Enlaces externos

DB2 y bases de datos federadas
Cuestiones relativas a dónde realizar la unión, también conocida como "empuje hacia abajo", y otras características de rendimiento.
Ejemplo práctico de federación de Oracle, Informix, DB2 y Excel.
Freitas, André, Edward Curry, João Gabriel Oliveira y Sean O'Riain. 2012. "Consulta de conjuntos de datos heterogéneos en la web de datos vinculados: desafíos, enfoques y tendencias". Computación de Internet IEEE 16 (1): 24–33.
Base de datos IBM Gaian: una base de datos federada distribuida dinámica.
Sistema federado y métodos y mecanismos para implementar y utilizar dicho sistema.

[reftwo-1] 1 2 3 " McLeod y Heimbigner (1985). "Una arquitectura federada para la gestión de la información" . ACM Transactions on Information Systems, Volumen 3, Número 3. págs. 253–278 .

[refone-2] 1 2 3 " Sheth y Larson (1990). "Sistemas de bases de datos federadas para la gestión de bases de datos distribuidas, heterogéneas y autónomas" . ACM Computing Surveys, vol. 22, n.º 3 , págs. 183-236 .

[:0-3] 1 2 3 4 5 Masood, Nayyer; Eaglestone, Barry (diciembre de 2003). "Modelos de conceptos de componentes y federación en un sistema de base de datos federada" (PDF) . Revista Malasia de Ciencias de la Computación . 16 (2): 47– 57. Archivado del original (PDF) el 7 de marzo de 2016. Recuperado el 3 de marzo de 2016 .

[ 1 ]

[ 2 ]