Un sistema de base de datos federado ( FDBS ) es un tipo de sistema de gestión de metabases de datos (DBMS), que asigna 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 descentralizadas geográficamente. Dado que los sistemas de bases de datos constituyentes siguen siendo autónomos, un sistema de base de datos federado es una alternativa contrastable a la tarea (a veces abrumadora) 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 federado. No hay una integración de datos real 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 los usuarios y clientes almacenar y recuperar datos de múltiples bases de datos no contiguas con una única consulta , incluso si las bases de datos constituyentes son heterogéneas . Para ello, un sistema de bases de datos federadas debe poder descomponer la consulta en subconsultas para enviarlas a los DBMS constituyentes pertinentes , después de lo cual el sistema debe componer los conjuntos de resultados de las subconsultas. Debido a que varios sistemas de administración de bases de datos emplean diferentes lenguajes de consulta , los sistemas de bases de datos federadas pueden aplicar envoltorios a las subconsultas para traducirlas a los lenguajes de consulta adecuados .
McLeod y Heimbigner [1] estuvieron entre los primeros en definir un sistema de base de datos federado a mediados de la década de 1980.
Una FDBS es una que "define la arquitectura e interconecta bases de datos que minimizan la autoridad central pero admiten el uso compartido y la coordinación parciales 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. En cambio, esta descripción se ajusta a lo que McLeod/Heimbigner llamó 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 a través de 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 de componentes cooperativos que son autónomos y posiblemente heterogéneos .
Los tres componentes importantes de un FDBS son la autonomía, la heterogeneidad y la distribución. [2] Otra dimensión que también se ha considerado es el entorno de red de computadoras , 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 ).
Un DBMS puede clasificarse como centralizado o distribuido. Un sistema centralizado administra una única base de datos, mientras que uno distribuido administra varias bases de datos. Un DBS componente en un DBMS puede ser centralizado o distribuido. Un DBS múltiple (MDBS) puede clasificarse en dos tipos según la autonomía del DBS componente: federado y no federado. Un sistema de base de datos no federado es una integración de DBMS componentes que no son autónomos. Un sistema de base de datos federado consta de DBS componentes que son autónomos pero participan en una federación para permitir el intercambio parcial y controlado de sus datos.
Las arquitecturas federadas difieren en función de los niveles de integración con los sistemas de bases de datos de componentes y el alcance de los servicios ofrecidos por la federación. Un FDBS puede clasificarse como sistemas acoplados de forma flexible o acoplados de forma estrecha.
Los sistemas de bases de datos múltiples, de los cuales los sistemas de bases de datos de múltiples fuentes son un tipo específico, se pueden caracterizar en 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.
La distribución de datos en un FDBS se debe a la existencia de múltiples bases de datos antes de que se construya un FDBS. Los datos se pueden distribuir entre múltiples bases de datos que podrían almacenarse en una sola computadora o en varias computadoras. Estas computadoras podrían estar ubicadas geográficamente en diferentes lugares, pero interconectadas por una red. Los beneficios de la distribución de datos ayudan a aumentar la disponibilidad y la confiabilidad, así como a mejorar los tiempos de acceso.
Las heterogeneidades en las bases de datos surgen debido a factores como las diferencias en las estructuras, la semántica de los datos, las restricciones admitidas o el lenguaje de consulta . Las diferencias en la estructura se producen cuando dos modelos de datos proporcionan primitivos diferentes, como los modelos orientados a objetos (OO) que admiten la especialización y la herencia y los modelos relacionales que no lo hacen. Las diferencias debidas a las restricciones se producen 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 la inserción y la retención que no se capturan solo mediante 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 hay un desacuerdo sobre el significado, la interpretación o el uso previsto de los datos . A nivel de esquema y de datos, la clasificación de las posibles heterogeneidades incluye:
Al crear un esquema federado, es necesario resolver dichas heterogeneidades antes de integrar los esquemas de bases de datos componentes.
El manejo de 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 están planificados 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 reglas de mapeo (dadas las asignaciones de equivalencia), un número que rápidamente se vuelve demasiado grande para fines prácticos. Una salida común es proporcionar un esquema global que comprenda las partes relevantes de todos los esquemas miembros y proporcionar asignaciones en forma de vistas de base de datos . Dos enfoques principales dependen de la dirección del mapeo:
Ambos son ejemplos de integración de datos , llamado problema de coincidencia de esquemas .
El concepto de autonomía es fundamental para la diferencia entre una base de datos de múltiples bases de datos y una base de datos de múltiples bases de datos. Es importante comprender los aspectos de la autonomía de las bases de datos de componentes y cómo se pueden abordar cuando una base de datos de componentes participa en una base de datos de múltiples bases de datos. Existen cuatro tipos de autonomías abordadas:
Las heterogeneidades en un FDBS se deben principalmente a la autonomía del diseño.
El grupo de estudio ANSI/X3/SPARC describió 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, la arquitectura de tres niveles es inadecuada para describir las arquitecturas de una FDBS. Por lo tanto, se amplió para admitir las tres dimensiones de la FDBS, a saber, distribución, autonomía y heterogeneidad. La arquitectura del esquema de cinco niveles se explica a continuación.
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 serialización global , el principal criterio de corrección, bajo estos requisitos se ha caracterizado como muy difícil y sin solución. [2]
La arquitectura del esquema de cinco niveles incluye lo siguiente:
Si bien representa con precisión el estado del arte en la integración de datos, la arquitectura de esquema de cinco niveles anterior sufre un inconveniente importante: la apariencia impuesta por la TI. Los usuarios de datos modernos exigen control sobre cómo se presentan los datos; sus necesidades entran en conflicto con estos enfoques ascendentes de integración de datos.
