BASE DE DATOS FEDERADAS

Bases de Datos Federadas

El avance espectacular de las comunicaciones y la creciente necesidad de cooperar con otras  entidades independientes, obligan a replantear  los conceptos fundamentales de las bases de  datos, dirigiéndose  de forma directa a la reciente tendencia de crear software para tener acceso  a varias bases de datos autónomas preexistentes almacenadas en SGBD heterogéneos.

Pero el acceso a varias bases de datos como si de una sola se tratara viene acompañado de problemas como la integración, seguridad, control, etc. Para poner solución a estos problemas y ofrecer un adecuado acceso a varias bases de datos se han desarrollado nuevos esquemas como los Sistemas Gestores de Bases de Datos Federadas (SGBDF)

Un sistema de bases de datos federadas es una colección de sistemas de bases de datos cooperativos y autónomos. 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.

Las bases de datos federadas son vistas unificadas de bases de datos independientes aparentan ser una sola base de datos, pero son una colección de sistemas de bases de datos independientes, cooperativos, heterogéneos, que son autónomos y que permiten compartir todos o algunos de sus datos. Una BDF aparenta ser una BD normal y corriente, pero no tiene existencia física, es una vista lógica.

Los primeros sistemas gestores de bases de datos surgen en los 60, pero no es hasta los 90 cuando aparecen los sistemas gestores de bases de datos federados. Aunque el concepto de bases de datos federadas viene de Hammer y McLeod en 1979 y luego retomado en 1985 por Heimbigner y McLeod y posteriormente en 1990 y 1991 por Sheth y Larson y luego por Saltor. En general los sistemas gestores de bases de datos federados, tienen la función de compartir solo la información que quieran compartir las entidades participantes, además de que los usuarios locales podrán acceder de forma transparente a los demás datos compartidos y ver los suyos, como si fuera una sola base de datos, esto sin embargo no es algo sencillo pero es algo muy útil.

Se debe remarcar que una base de datos federada no es una base de datos única distribuida, más bien son soluciones para acceder a la información depositada en distintas bases de datos. Un sistema de bases de datos federadas es una colección de sistemas de bases de datos cooperativos y autónomos.

La importancia principal de las bases de datos federadas radica principalmente en su biprocesamiento. Es decir, en su capacidad de atender consultas globales, al mismo tiempo que permite que la base de datos componente siga atendiendo a sus aplicaciones locales.

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.

La autonomía o la integración de los componentes la controla el administrador del sistema
global en colaboración con los administradores de las bases de datos componente. Este nivel de integración se da de acuerdo a las necesidades propias de cada componente.

Es posible agrupar/desagrupar componentes para formar una federación, pudiendo entrar/salir componentes de la federación.

AUTONOMÍA DE BASES DE DATOS

1. Diseño: modelo, lenguaje, implementación.
2. Comunicación: como, cuando se responde a otros sistemas.
3. Ejecución: Criterio a seguir en la toma de decisiones.
4. Asociación: decisión de que datos se comparten y a quien.

Forma en que opera un SBDF

Los componentes de un SBDF(Sistema de base de datos federadas) pueden efectuar operaciones locales o bien ejecutar consultas sobre los datos de la federación y pueden también ser usadas por otros componentes de la federación.

La autonomía o la integración de los componentes la controla el administrador del sistema global en colaboración con los administradores de las bases de datos componente. Este nivel de integración se de de acuerdo a las necesidades propias de cada componente.

Es posible también la agrupación en una federación o la misma desincorporación de la misma, y de igual forma es posible que entren o salgan componentes.

Para poder lograr esto se establecen diferentes esquemas en el nivel federal.

Se debe remarcar que una base de datos federada no es una base de datos única distribuida, más bien son soluciones para acceder información depositada en diferentes bases de datos.

1. Integración manual, todo queda a cargo de unas pocas personas. Implica muchos cambios

2. Integración de datos. Se crea una nueva base de datos.

3. Acceso integrado. DBMF(Data base manager federated) o SGBDF(Sistema gestor de bases datos federadas) o SMBDF(Sistema manejador de bases de datos federadas).

Enfoque federado

La forma en que cooperan se basa fundamentalmente en dos esquemas:

• Esquema de exportación
• Esquema de importación.

El esquema de exportación.

Denota las partes de la base de datos que va a compartir o que va a poner a disposición de los demás miembros de la federación. Así también es un subconjunto de un esquema componente ya que no todos los datos deberán de ser disponibles para la federación.

El esquema de importación.

Son vistas de la base de datos que proporcionan lo que desea el esquema de exportación.

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 computo(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 una optimizador de recursos para aprovechar correctamente todos los componentes.

• Pueden ser físicamente distribuidas en diferentes lugares e incluso en lugares muy lejanos.

NIVELES DE UN MBDF (Manejador de base de datos federada)

• Nivel componente. Bases de datos existentes.
• Nivel federado. Conjunto de bases de datos que ínter operan

Se dice que las bases de datos se federan para dar lugar a un MBDF. A continuación se muestra una gráfica con la idea de un esquema de manejadores de datos federados.

- Sistema manejador de Base de Datos Federada.

Las federaciones se forman y desaparecen

• No existe un esquema conceptual único
• Un componente puede ser de varios sistemas federados
• Un componente puede ser otro sistema de bases de datos federados

TIPOS DE SGBDF

Los SGBDF se pueden clasificar en 2 grandes categorías: fuertemente acoplados y débilmente acoplados. Antes de detallar ambas categorías, se muestra un esquema que específica los diferentes tipos de bases de datos federadas.

Taxonomía de los SGBDF

Como se puede apreciar, vuelve a aparecer el concepto de autonomía como elemento diferenciador entre sistemas federados y sistemas que no lo son. En cuanto a los otros 2 conceptos,heterogeneidad y distribución, ambos se cumplen debido a que la propia definición de sistema federado lo hace posible, al estar compuesto éste de varios SGBD separados en localizaciones diferentes y con distinta arquitectura.

SGBDF FUERTEMENTE ACOPLADOS

Este tipo de sistema federado posee un esquema conceptual global que está formado por un subconjunto de los esquemas conceptuales locales, compuesto de los datos que cada sistema local decide compartir. El esquema conceptual global en un sistema fuertemente acoplado implica la integración de partes de los esquemas conceptuales locales o de los esquemas externos locales.
En la figura siguiente se ilustra una arquitectura de referencia para un sistema gestor de base de datos federado estrechamente acoplado, es decir, que tiene un esquema conceptual global.

Arquitectura de referencia para un SGBDF fuertemente acoplado

Características de un SGBDF fuertemente acoplado:

• El administrador global del sistema federado tiene todo el control sobre la creación y el acceso a los sistemas de bases de datos componente.
• Soporta uno o más esquemas federados.

Ventajas de la utilización SGBDF fuertemente acoplado:

• Capacidad de soportar actualizaciones.
• La interpretación de la semántica de los múltiples datos integrados en el sistema federado es uniforme.

Desventajas de la utilización SGBDF fuertemente acoplado:

• Debido a la libertad que disfrutan los administradores globales se puede llegar a violar la autonomía que poseen los sistemas componente.
• No soporta la evolución dinámica de los esquemas de exportación o componentes.

SGBDF DÉBILMENTE ACOPLADOS

Existe otro tipo de sistema federado, débilmente acoplado, que se basa en no tener un esquema conceptual global. En este caso, los esquemas externos están compuestos por uno o más esquemas conceptuales locales.

Características SGBDF débilmente acoplados.

-Los usuarios son los responsables de la creación y el mantenimiento de las federaciones mediante la utilización de vistas.
-Soporta sistemas de bases de datos altamente autónomos, los cuales los usuarios deben tratar.

Ventajas de utilizar SGBDF débilmente acoplados:

• Dispone de gran flexibilidad para mapear diferentes semánticas de los mismos objetos en distintos esquemas de exportación.
• Se tiene mayor facilidad para soportar la evolución de los componentes.

Desventajas de utilizar SGBDF débilmente acoplados:

• Resulta de gran dificultad la comprensión de grandes cantidades de esquemas de exportación.
• Los esfuerzos para gestionar este tipo de sistema se duplican.
• Existen problemas para actualizar las vistas que utilizan los usuarios.

ARQUITECTURA

En esta oportunidad se demostraran dos tipos de arquitecturas para el manejo de bases de datos federadas. Existen muchas otras, pero nos vamos a centrar en la arquitectura de Sheth A.P. and Larson, J.A. y la arquitectura propuesta por ANSI/SPARC.

Arquitectura de 5 niveles por Seth y Larson

La arquitectura porpuesta por Sheth y Larson se trata de una arquitectura con cinco niveles de esquemas para un SBDF: esquema local, esquema componente, esquema de exportación, esquema federado y esquema externo.

1. Esquema Local. Un esquema local es el esquema conceptual de los componentes.

2. 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.

3. Esquema de Exportación. Representa un subconjunto de la totalidad de los datos que contiene el esquema componente. Este subconjunto de datos es el que se quiere compartir en la base de datos federada.

4. Esquema Federado. Un esquema federado es una integración de múltiples esquemas de exportación de cada base de datos componente.

5. Esquema Externo. Representa una vista hacia un usuario o conjunto de usuarios determinado. No necesariamente este esquema contiene todos los datos que forman el esquema federado, sino que puede ser un subconjunto de estos.

Arquitectura de 5 niveles de Sheth y Larson

Arquitectura de 3 niveles (ANSI/SPARC)

Este tipo de arquitectura es muy utilizada en el diseño de bases de datos relacionales. Está formada por los siguientes niveles:

Nivel Físico: Está compuesto por el esquema interno. Dicho esquema contiene las diferentes bases de datos componente que forman la base de datos federada.

Nivel Lógico: Corresponde al esquema conceptual. Este nivel contiene el modelo global de datos, es decir, el conjunto de datos compartido por todas las bases de datos componente.

Nivel Externo: Está representado por el esquema externo. Este esquema está compuesto por las diferentes vistas que poseen los usuarios a los datos compartidos.
Para mostrar de forma más clara esta arquitectura se sugiere la siguiente figura:

Arquitectura de 3 niveles (ANSI/SPARC)

Existen muchas otras arquitecturas para el manejo de las bases de datos federadas, un ejemplo puede ser la arquitectura de 8 niveles o por ejemplo la de esquemas de data warehouse.

Aplicaciones Comerciales

Existen multitud de aplicaciones comerciales que soportan bases de datos federadas. Todos los sistemas gestores de bases de datos conocidos poseen la posibilidad de crear este tipo de bases de datos. Por ejemplo, IBM, ORACLE, MySQL, SQL Server, etc., permiten la creación de bases de datos federadas. El problema que surge es cuando se desea realizar una base de datos federada que consulta los datos de otra base de datos con una tecnología diferente, es decir, de otro fabricante. En este caso las posibilidades se reducen, y es necesaria la incorporación de algún componente extra que incrementa el coste considerablemente.

Caso de Uso: MySQL.

A continuación se va a realizar un ejemplo sencillo de base de datos federada.

Para ello se va a utilizar el SGBD MySQL, que dispone de una versión gratuita que permite crear bases de datos federadas.

En primer lugar se va a definir la tabla cliente que será consultada por la tabla federada. Notar que pertenece a la base de datosbbdd1.

CREATE DATABASE IF NOT EXISTS bbdd1;
USE bbdd1;
DROP TABLE IF EXISTS `cliente`;
CREATE TABLE `cliente` (
`idCliente` int(10) unsigned NOT NULL auto_increment,
`Nombre` varchar(45) NOT NULL,
`Apellidos` varchar(45) NOT NULL,
PRIMARY KEY (`idCliente`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Ahora, nuestra base de datos federada va a contener otra tabla que va a tener una federación a esta primera tabla definida.

CREATE DATABASE IF NOT EXISTS bbdd_federada;
USE bbdd_federada;
DROP TABLE IF EXISTS `cliente_federada`;
CREATE TABLE `cliente_federada` (
`idCliente` int(10) unsigned NOT NULL auto_increment,
`Nombre` varchar(45) NOT NULL,
`Apellidos` varchar(45) NOT NULL,
PRIMARY KEY (`idCliente`)
) ENGINE=FEDERATED DEFAULT CHARSET=utf8
COMMENT:’mysql://root@remote_host:9306/bbdd1/cliente’;

La tabla federada que se acaba de crear muestra los mismos datos que la tabla remota a la que consulta. Notar que con referencia a la definición de la primera tabla existen 2 diferencias:

El motor de consulta cambia de MyISAM a FEDERATED.

Se añade el atributo COMMENT donde se especifica la dirección de la tabla remota a la que tiene que consultar.