Sistema de base de datos federada

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 un único base de datos federada. Las bases de datos que las componen 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 bases de datos federado es una alternativa contrastable a la (a veces desalentadora) tarea de fusionar varias bases de datos dispares. Una base de datos federada, o base de datos virtual, es una combinación de todas las bases de datos que constituyen un sistema de base de datos federado. Como resultado de la federación de datos, no existe una verdadera integración de datos en las distintas bases de datos que la componen.

A través de la abstracción de datos, los sistemas de bases de datos federados 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 sola consulta, incluso si las bases de datos constituyentes son heterogéneas. Para este fin, un sistema de base de datos federado debe poder descomponer la consulta en subconsultas para enviarlas a los DBMS constituyentes relevantes, después de lo cual el sistema debe componer los conjuntos de resultados de las subconsultas. Debido a que varios sistemas de gestión de bases de datos emplean diferentes lenguajes de consulta, los sistemas de bases de datos federados pueden aplicar contenedores a las subconsultas para traducirlas a los lenguajes de consulta apropiados.

Definición

McLeod y Heimbigner estuvieron entre los primeros en definir un sistema de base de datos federado a mediados de los años 1980.

Un FDBS es aquel que "define la arquitectura e interconecta las bases de datos que minimizan la autoridad central pero apoyan el intercambio parcial y la coordinación entre los sistemas de bases de datos". Es posible que esta descripción no refleje con precisión la definición de McLeod/Heimbigner de una base de datos federada. Más bien, esta descripción se ajusta a lo que McLeod/Heimbigner llamaron 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, 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 autonomía, heterogeneidad y distribución. Otra dimensión que también se ha considerado es la red informática del entorno de red, por ejemplo, muchas DBS a través de una LAN o muchas DBS a través de una WAN actualizan las funciones relacionadas de las DBS participantes (por ejemplo, sin actualizaciones, transiciones no atómicas, actualizaciones atómicas).

Arquitectura FDBS

Un DBMS se puede clasificar como centralizado o distribuido. Un sistema centralizado administra una única base de datos, mientras que un sistema distribuido administra múltiples bases de datos. Un componente DBS en un DBMS puede estar centralizado o distribuido. Una DBS múltiple (MDBS) se puede clasificar en dos tipos dependiendo de la autonomía del componente DBS en federada y no federada. Un sistema de base de datos no federado es una integración de componentes DBMS que no son autónomos. Un sistema de base de datos federado consta de componentes DBS que son autónomos pero participan en una federación para permitir el intercambio parcial y controlado de sus datos.

Las arquitecturas federadas difieren según 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 se puede clasificar como sistemas estrechamente acoplados o débilmente acoplados.

• Loosely Pared requiere bases de datos de componentes para construir su propio esquema federado. Un usuario normalmente accederá a otros sistemas de bases de datos de componentes utilizando un lenguaje multidatabase pero esto elimina cualquier nivel de transparencia de ubicación, obligando al usuario a tener conocimiento directo del esquema federado. Un usuario importa los datos que necesitan de otras bases de datos de componentes y lo integra con su propio para formar un esquema federado.
• El sistema ajustado consiste en sistemas de componentes que utilizan procesos independientes para construir y difundir un esquema federado integrado.

Múltiples DBS de los cuales los FDBS son un tipo específico se pueden caracterizar 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 únicas o múltiples bases de datos en una LAN o WAN.

Distribución

La distribución de datos en una FDBS se debe a la existencia de varias DBS antes de que se construya una 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 confiabilidad, así como a mejorar los tiempos de acceso.

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 soportadas o el lenguaje de consulta. Las diferencias en estructura ocurren cuando dos modelos de datos proporcionan primitivas diferentes, como modelos orientados a objetos (OO) que admiten especialización y herencia, y modelos relacionales que no lo hacen. Las diferencias debidas a restricciones ocurren cuando dos modelos soportan 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 únicamente mediante la integridad referencial. El lenguaje de consulta soportado 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 datos, la clasificación de posibles heterogeneidades incluye:

• Nombrar conflictos, por ejemplo, bases de datos que utilicen nombres diferentes para representar el mismo concepto.
• Conflictos de dominio o conflictos de representación de datos, por ejemplo, bases de datos que utilizan diferentes valores 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 cardenalidades para los mismos datos.
• Los conflictos de metadatos, por ejemplo, los mismos conceptos están representados a nivel de esquemas y instancias.
• Conflictos de datos, por ejemplo, atributos perdidos
• Conflictos de esquemas e.g. mesa versus conflicto de mesa que incluye la designación de conflictos, conflictos de datos, etc.

Al crear un esquema federado, uno tiene que resolver tales heterogeneidades antes de integrar el componente de esquemas DB.

Schema matching, schema mapping

Tratar con tipos de datos incompatibles o sintaxis de consultas no es el único obstáculo para una implementación concreta de un FDBS. En sistemas que no están planificados, un problema genérico radica en igualar semánticamente equivalente, pero diferentes partes llamadas de diferentes esquemas (= modelos de datos) (tablas, atributos). Una asignación de pares entre n atributos resultaría en ${\displaystyle n(n-1) \over 2}$ Reglas de mapeo (con asignaciones de equivalencia dadas) - un número que rápidamente se vuelve demasiado grande para fines prácticos. Una manera común de salir es proporcionar un esquema global que comprende las partes pertinentes de todos los esquemas miembros y proporcionar mapas en forma de puntos de vista de la base de datos. Dos enfoques principales dependen de la dirección de la asignación:

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

Ambos son ejemplos de integración de datos, llamado problema de 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 de las bases de datos de componentes y cómo se pueden abordar cuando un componente DBS participa en un FDBS. Se abordan cuatro tipos de autonomías:

• Diseño Autonomía que se refiere a la capacidad de elegir su diseño independientemente de datos, lenguaje de consulta o 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 las comunicaciones se refiere a la operación general del DBMS para comunicarse con otros DBMS o no.
• La autonomía de ejecución permite que un componente DBMS controle las operaciones solicitadas por operaciones locales y externas.
• La autonomía de la asociación da poder al componente DBS para disociarse de una federación que significa que FDBS puede operar independientemente de cualquier DBS único.

El Grupo de Estudio ANSI/X3/SPARC esbozó 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 un FDBS. Por lo tanto, se amplió para respaldar 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.

Control de concurrencia

Los requisitos de Heterogeneidad y Autonomía plantean desafíos especiales en relación con el control de concurrencia en un FDBS, que es crucial para la correcta ejecución de sus transacciones concurrentes (ver 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 resolver. El orden de compromiso, introducido en 1991, ha proporcionado una solución general para este problema (consulte Serialización global; consulte Orden de compromiso también para conocer los aspectos arquitectónicos de la solución).

Arquitectura de esquema de cinco niveles para FDBS

La arquitectura del 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.
• El esquema de componentes es el subconjunto del esquema local que la organización propietario está dispuesta a compartir con otros usuarios del FDBS y se traduce en un modelo de datos común.
• El esquema de exportación representa un subconjunto de un esquema de componente que está disponible para una federación particular. Puede incluir información de control de acceso sobre su uso por un usuario de federación específico. El esquema de exportación ayuda a gestionar el flujo de control de 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 esquemas de exportación.
• El esquema externo se extrae de un esquema federado, y se define para los usuarios/applicaciones de una federación particular.

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 de un inconveniente importante, a saber, la apariencia impuesta por TI. Los usuarios de datos modernos exigen control sobre cómo se presentan los datos; sus necesidades están en cierto modo en conflicto con estos enfoques ascendentes para la integración de datos.