ÍNDICE

Introducción

1. Base de Datos Federada ……………………………………………. 5

1.1. Autonomía de la Base de Datos Federada …………………….. 5

1.2. Propiedades ……………………………………………………. 5

1.3. Niveles de un Manejador de Base de Datos Federada ………… 6

1.4. Clasificación …………………………………………………… 7

1.4.1. Débilmente acoplado ……………………………………. 7

1.4.2. Fuertemente acoplado …………………………………… 7

1.5. Sistema Distribuidos Vs Sistemas Federados ………………….. 7

1.5.1. Semejanzas ………………………………………………. 7

1.5.2. Diferencias ……………………………………………….. 7

1.5.2.1. En cuanto a Diseño …………………………….. 7

1.5.2.2. En cuanto a Niveles ……………………………. 8

1.5.2.3. En cuanto a autonomía …………………………. 8

1.5.2.4. En cuanto a transparencia ………………………. 8

1.6. Arquitectura ……………………………………………………… 8

1.6.1. Arquitectura de 3 niveles ………………………………… 9

1.7. Problemática para la implementación de Sistemas de

Bases de Datos Federada ……………………………………….. 9

1.7.1. Soluciones comerciales ………………………………….. 10

2. Estrategia de procesamiento de un Sistema de Base de Datos

Federada ……………………………………………………………… 11

2.1. Arquitectura de construcción ……………………………………. 12

2.2. Arquitectura de ejecución ……………………………………….. 13

2.2.1. Descomposición de la Consulta Federada ………………… 14

2.2.1.1. Fase 1. Parser y modificación de la consulta

global …………………………………… 15

2.2.1.2. Fase 2. Descomposición en Subconsultas ………. 18

2.2.1.3. Fase 3. Localizar Base de Datos Componentes

(sitios) …………………………………… 22

2.2.1.3.1. Consolidación de resultados ………… 22

2.2.2. Optimización de la Consulta Federada ………………….. 25

Técnicas Heurísticas para optimizar la Fase 2. ………….. 27

- Referencias

INTRODUCCIÓN

Existe una idea que podría mejorar muchas cosas y entre otras se sugiere la integración de las bases de datos para crear una base de datos mundiales, con el fin de contar con información de todo tipo. Muestra de ello son lo enormes esfuerzos que realiza la comunidad económica europea para compartir información, idealmente esto es genial, pero en la practica surgen mucho problemas mas, por ejemplo no se puede compartir toda la información y menos la que tiene que ver con la seguridad nacional y la autonomía, por esta razón se han venido desarrollando en las ultimas décadas nuevos esquemas y a razón de esto surgen los manejadores de bases de datos federadas.

Los sistemas de manejadores de bases de datos surgen en los 60 y en los 90 surgen los manejadores de base 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 manejadores de bases de datos federados, tienen la funcione 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 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 si embargo es algo muy útil.

Cuánta información hay en el mundo?"

De acuerdo a Michael Lesk, quien abordó esta pregunta en su paper del mismo nombre de 1997, la enorme cantidad de datos tomaría varios miles de millones de gigabytes o varios miles de petabytes de almacenamiento [1]. La tecnología de las modernas bases de datos provee los medios para almacenar, administrar y acceder a semejantes cantidades de información. Sin embargo, las bases de datos no son un fenómeno nuevo. De hecho, Herman Hollerith mecanizó el almacenamiento del Censo de EE.UU. de 1890 en lo que de alguna forma se considera la primera base de datos significativa "computarizada" [2].

Hoy, la importancia e impacto de las bases de datos es incuestionable a medida que organizaciones gubernamentales, instituciones académicas, y entidades comerciales crean y mantienen importantes bases de datos que contienen toda clase de información desde documentos de texto en lenguaje natural, tablas estadísticas, datos financieros y objetos multimediales hasta datos de naturaleza técnica y científica.

Muchas bases de datos están compuestas de metadatos, lo cual significa que los registros guardan "datos acerca de los datos" tales como información acerca del tamaño y carácter de otra base de datos en lugar de ser la fuente primaria de contenido tal como nombre y domicilio de una persona. Las tecnologías de bases de datos, incluyendo métodos de arquitectura y acceso, se están desarrollando rápidamente para mantenerse al día con esta demanda de mecanismos de administración de la información.

Los diseñadores y administradores de bases de datos enfrentan muchos desafíos que reflejan la complejidad del floreciente entorno de la información. Las tecnologías de bases de datos deben manejar masivas cantidades de datos, extraer información útil desde estos repositorios, y tener la habilidad para reflejar las relaciones entre los datos mantenidos en diferentes bases de datos. Además de la arquitectura y sistema deben proveer integridad, recuperación, concurrencia, y seguridad.

Para responder a estos desafíos, los tres modelos fundamentales de bases de datos (jerárquico, red y relacional) [3], han servido como la base para desarrollar modelos de datos más potentes y flexibles, tales como los modelos relacional extendido y el relacional de objetos [4]. Un esquema de datos y una arquitectura bien definida aseguran almacenamiento de datos lógico y eficiente lo cual incrementa la capacidad de la base de datos y extiende las capacidades de los lenguajes de consulta y otros métodos de acceso. Además, la minería de datos crea información útil al identificar datos relacionados dentro de los vastos almacenamientos [5]. Los investigadores ahora luchan con las complejidades de los temas relacionales y la interoperabilidad [6]. Por ejemplo los investigadores son capaces ahora de usar metadatos de manera más eficiente para la diseminación mejorada de datos. Los investigadores son capaces también de usar estrategias federadas para bases de datos distribuidas [7].

Forma en que operan.

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, mas 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 lo 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.

Arquitectura propuesta por(Sheth y Larson)

Esquema local.

Es el esquema conceptual de un sistema de bases de datos componente de la federación.

Esquema componente.

Este resulta al transformar un esquema local a un modelo canónico o común de datos del sistema manejador de bases de datos federadas.

Esquema federado.

Pueden existir varios esquemas federados en el sistema, dependiendo de cada tipo de usuarios dentro de la federación. Las clases de usuarios son los que tienen funciones similares, ejemplo ventas, justicia, compras, bibliotecas, etc.. Al esquema federado también se le conoce como empresarial o también de importación.

1. BASES DE DATOS FEDERADA

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

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

1.2. 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 esta 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.

1.3. 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 base 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

- Fig. No.1. 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

1.4. CLASIFICACIÓN.

· Débilmente acoplados

· Fuertemente acoplados

1.4.1. Débilmente acoplados

· Los usuarios deben de tratar explícitamente con las base de datos ej: Omnibase, MRDSM.

1.4.2. Fuertemente acoplados

· Los administradores de la federación controlan el acceso y mantienen el sistema.

· Esquema federado único. SIRIUS-DELTA, DDTS.

· Múltiples esquemas federados: Mermaid, MULTIBASE.

1.5. SISTEMAS DISTRIBUIDOS CONTRA SISTEMAS FEDERADOS

1.5.1. Semejanzas

· Los datos están en diversas ubicaciones.

· Las instalaciones están interconectadas

· Ambos tienen dos componentes: global/local y federado/componente.

· Reciben peticiones que son resueltas en una sola respuesta.

1.5.2. Diferencias

1.5.2.1. En cuanto a diseño.

· SMDBD(Sistema manejador de bases de datos distribuidas). Manejan un diseño top – down, existe una sola base de datos y se distribuye en diferentes ubicaciones. Se fragmenta o se replica.

· SMBDF,. Maneja un diseño Botton – up, las bases de datos ya existen y se identifica como se formaran las federaciones.

1.5.2.2. En cuanto a Niveles.

· SMBDD. Local y global.

· SMBDF. Federado y componente.

1.5.2.3. En cuanto a autonomía.

· SMBDD. Carece de esta ya que la base esta bajo las reglas del global.

· SMBDF. Cada base que compone al sistema federado, es autónoma y por tanto tiene sus propios privilegios.

1.5.2.4. En cuanto a transparencia.

· SMBDD. Los usuarios ven a la base como una sola y no sabe como se encuentra distribuida.

· SMBDF. Existen dos tipos de usuarios, el primero es el que ve la base de datos como si fuera única, y otros ven un componente de la base de datos y así no pueden ver lo demás

1.6. ARQUITECTURA.

En el caso de las bases de datos federadas. Debemos identificar dos partes:

1. La parte de software

2. La parte de arquitectura de esquema.

La segunda esta encargada de resolver las heterogeneidades sintácticas y semánticas de los distintos componentes de la base de datos

La heterogeneidad sintáctica se da por la autonomía de los componentes de la base de datos y con ello por su diferencias en sus diseños.

La heterogeneidad semántica se da por le diferente concepción que se tiene de los elementos por parte de las diferentes bases de datos.

Para poder resolver esto se debe de contar con capas, aquí se conocen como capas de esquemas.

Un sistema federado debe cumplir 3 aspectos.

· Autonomía.

· Heterogeneidad.

· Sistema distribuido

1.6.1. Arquitectura de 3 niveles (ANSI/SPARC)

· Físico (esquema interno).

· Lógico(Esquema conceptual)

· Externo(Esquema externo)

Esta arquitectura es muy usada en el diseño de bases de datos relacionales mas no así en diseño de bases de datos orientadas a objetos

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.

1.7. PROBLEMÁTICA PARA LA IMPLEMENTACIÓN DE BASES DE DATOS FEDERADAS.

Uno de los principales problemas es la incompatibilidad entre los sistemas de consulta entre los diferentes fabricantes, aunque existen estándares para el SQL por ejemplo el SQL 92, normalmente los fabricantes construyen dialectos, o finalmente una instrucción no es la misma es un manejador que en otro, o simplemente tipos de datos.

Otro problema es la codificación por ejemplo unos usan ASCII otros ASCII extendido o el EBCDIC.

Otro aspecto importante, son los códigos de error generados por los distintos fabricantes, que normalmente no son compatibles.

Problemas en transacciones.

· Control de concurrencia. El SMBDF no conoce las transacciones a nivel de componentes y lo SMBD componentes no siempre pueden distinguir entre transacciones propias y externas.

· Heterogeneidad. Cada SMBD mantiene su autonomía.

· La autonomía total es incompatible con la atomicidad.

1.7.1. Soluciones comerciales

Existen varias opciones y varias instituciones y compañías que trabajan para solucionar estos problemas de interoperabilidad, mas sin embargo muy pocos trabajan para la administración global, algunas de las compañías que trabajan en soluciones son augsoft(http://odbcrouter.com/), Oracle, Sybase, y ha usado distintas opciones por ejemplo ODBC(open Data Base Conectivity) y JDBC el conector de Java, en general los grandes manejadores de bases de datos contienen alguna herramienta para poder hacer esto lo malo es que tienen un producto para conectarse con otros manejadores, pero cada uno se vende aparte además de que los costos son exorbitantes.

2. ESTRATEGIA DE PROCESAMIENTO DE UN SISTEMA GESTOR DE BASE DE DATOS

Diferentes Tipos de bases de datos (BD) se han desarrollado e implementado con el propósito de satisfacer las demandas de los usuarios, estas bases de datos pueden ser diseñadas en forma independiente por una organización. Como resultado, la heterogeneidad de las BD es necesaria cuando estas coexisten en una organización que requiere compartir datos entre ellas. Por lo cual se ha creado un enfoque de integración llamado Sistema de base de datos Federado (SBDF) para soportar la interoperabilidad de las BD heterogéneas.

Cuando la Federación ha sido creada, se crea una nueva arquitectura diferente llamada Arquitectura de ejecución, en la cual se crean capas de software (módulos) que gestionan el flujo de datos y procesan la consulta global. Esto permite que subconsultas se procesen sobre las Bases de Datos Componentes (BDC) donde la información es extraída, combinándose resultados parciales para construir un único resultado final, como lo muestra la figura No.2.

El buen desempeño del procesamiento de consultas en sistemas Federados depende de la optimización de planes de ejecución de la consulta global. Existen varias técnicas para la optimización de una consulta federada antes y después de la descomposición de la misma consulta como procesos algorítmicos.

A continuación se describe una técnica de procesamiento, en la cual se diseñan e implementan los submódulos de Descomposición de consultas y Consolidación de resultados dentro del Gestor de consultas Federadas. El mecanismo de desarrollo establece la construcción de un árbol cuyos nodos se descomponen inicialmente en join explícitos y posteriormente en join implícitos. Hecho lo anterior, algoritmos son aplicados a las subconsultas intermedias sobre predicados y proyecciones. Una vez ejecutados los algoritmos que cubren el proceso de descomposición, entran en función diferentes técnicas de optimización afectando a los dos submódulos. Diferentes técnicas heurísticas se presentan para optimizar la optimización basada en una búsqueda exhaustiva de planes de ejecución apoyado por estadísticas de la BDC, las cuales se procesan con un modelo del costo. Finalmente, la consodilación de resultados parciales se lleva a cabo manteniendo la respuesta federada en el nodo raíz.

Como función objetiva, se busca optimizar los recursos y el tiempo de respuesta, por lo tanto, se pretende buscar el mejor plan de ejecución con el mínimo costo de recursos y menor tiempo de respuestas.

- Fig. No.2. Arquitectura de ejecución de un sistema manejador de Base de Datos Federada.

Consulta federada
		Resultado federado
	Controlador de seguridad
	Query Transformador

2.1. ARQUITECTURA DE CONSTRUCCIÓN

Construir un sistema que soporte el acceso integrado es de suma importancia. Por lo que antes de que un SBDF opere, se tienen que resolver varios problemas relacionados con la heterogeneidad, tal como, la heterogeneidad semántica y sintáctica, así como, los problemas de distribución. Por esta razón, el SBDF debe tener une arquitectura adecuada de esquema y un conveniente modelo de datos global llamado, Modelo de Datos Canónico (MDC).

2.2. ARQUITECTURA DE EJECUCIÓN

El flujo de datos comienza con una consulta planeada por el usuario de la federación llamada consulta federada. El sistema por módulos es el siguiente:

Controlador de Seguridad

Pasa por el módulo llamado Controlador de Seguridad, autorizando la consulta dada.

Traductor de subresultados

Consolidador de resultados

Transformaciónde resultados

Descomposición de consultas

Transformador de consultas

Continúa con el transformador de consultas generando

una consulta equivalente expresada en términos del Esquema Federado (EF) etiquetado con un nivel de seguridad.

Query Descomposer (QD). Este módulo es el responsable de descomponer la consulta global en subconsultas contra las DBC.

Traductor de consultas

Posteriormente del traductor de consultas da una subconsulta equivalente en el Modelo de Datos Nativo de la BDC expresado en términos del correspondiente Esquema Nativo (EN) y etiquetado con un nivel de seguridad federado.

Traductor de nivel de seguridad

Este etiqueta las subconsultas con el nivel de seguridad componente (nv) de su BDC que corresponde a este nivel federado. Ahora, se esta en condiciones de ejecutar las correspondientes consultas bajo el control de gestión de transacciones.

Una vez que se tiene la consulta hecha, los resultados llegan al Traductor de Subresultados donde son convertidos al MDC.

Se produce el resultado final usando las correspondencias de los Esquemas Federados (EF) y Esquemas Componentes (EC).

Usando las correspondencias del Esquema Federado y el Esquema de Usuario, presenta el resultado final en el modelo del usuario, expresado en términos de su Esquema del Usuario.

2.2.1. Descomposición de la Consulta federada

Una vez que el transformador de consultas ha generado una consulta equivalente en términos del EF, el módulo de descomposición de consultas obtiene como entrada una consulta global con clases virtuales, las cuales fueron creadas por el proceso de integración de esquema después de aplicar los operadores de integración.

Después del punto anterior, la consulta global puede mantener datos referenciados de más de una BD, por lo que ninguna de estas consultas puede ser evaluada directamente por una BDC, es por esto que debe crearse un algoritmo (parte de la capa de software) que apoye la descomposición consolidación de la consulta global. A continuación se describen los puntos estratégicos a tomar en cuenta para iniciar la descomposición.

Una consulta global consiste de tres partes importantes (Select, From y Where):

Select [atributos]

From [Serie de clases]

Where [Predicados]

El módulo encargado de la descomposición de la consulta global, se divide a su vez en 3 fases relevantes, la primera inicia inmediatamente después del proceso que ejecuta el módulo de transformación de la consulta, por lo que tiene como entada a una consulta equivalente expresada en términos del EF y etiquetado con un nivel de seguridad, como lo muestra la figura No.3.

La primera fase del Query de Descomposición (QD) es un Parser y modificación de la consulta global, la cual analiza la carga de clases que ésta mantiene y obtiene directamente de la sentencia From, con lo cual construye un árbol para joins explícitos; la segunda fase es la más importante ya que en ella se examina cada clase virtual y posteriormente se detectan los Esquemas Componentes y Clases Virtuales, lógicamente esto se debe a la integración de esquemas realizado en la fase de resolución.

Una vez hecho lo anterior, entra el proceso de Descomposición en Subconsultas dependiendo de los EC participantes, es aquí donde el número de subconsultas permanece igual al número de EC, pero son diferencias en la sentencia from donde contiene ahora una expresión de mapeo que corresponde al EC.

Después se procesa cada subconsulta y se detectan las clases que componen la clase virtual, formando un número de subconsultas igual a las clases que forman la clase virtual.

Cuando el conjunto de nodos se haya reunido, estos estarán en el nivel más bajo del árbol y se aplicará un proceso donde la participación de las sentencias Where y Select toman una matiz importante. Finalmente en la tercera etapa se detectan las BDC y se etiquetan las consultas para su regreso buen funcionamiento del módulo encargado de la consolidación de resultados.

- Fig. No.3. Módulo de Descomposición de Consultas Globales (Query Descomponer-QD).

2.2.1.1. Fase 1: Parser y modificación de la consulta global

Analiza si mas de una serie de clases están especificadas en la sentencia From para sus joins explícitos, si es así, la consulta global debe ser descompuesta en una colección de subconsultas, las cuales contienen solo una serie de clase. Lo anterior da lugar a una consulta global modificada para procesar los joins, el objetivo es integrar los resultados de las subconsultas (Creación del árbol de la consulta global).

- ALGORITMO 1. Modificación de la consulta global

La explicación del algoritmo es el siguiente:

Dada una consulta global, se toma en cuenta el esquema integrado, realizado por las fases de detección y resolución, con estas fases ya terminadas se crean también los mappings (correspondencias). Una vez hecho lo anterior, se resuelve el número total de las clases virtuales (si son dadas) y se envían a un procesamiento para generar un árbol, en donde las subconsultas quedan registradas en forma de nodos con una clase virtual única, por lo que ahora se envía a la siguiente fase para analizar cada una de éstas, y seguir con la descomposición, comos e muestra en la figura No.4.

CV: Clase Virtual

- Fig. No.4. Parser y Modificación de la Consulta Federada (Fase 1).

2.2.1.2. Fase 2: Descomposición en subconsultas

Un punto a considerar después de la primera fase, es que, a pesar de una consulta modificada contenga una clase virtual global, esta pueda ser una clase virtual de la forma: CV={C₁, …, C_n} donde C es una clase implícita de la CV, la cual corresponde a una BDC,l en esta situación la clase virtual es el resultado de una operación de integración, y por tal motivo se construye un algoritmo dentro de este submódulo que descompone cada consulta modificada, la cual fue sometida a la fase 1, y que ahora mantiene una clase virtual única. Esta descomposición es apoyada por operadores de correspondencias, controlados por un mappings (Creación de un algoritmo para las correspondencias).

- ALGORITMO 2. Descomposición en subconsultas

A continuación se explica el algoritmo anterior:

Dada una Consulta Global con una Clase Virtual o una consulta modificada (obtenida de la fase 1) se examinan las correspondencias de las clases para determinar el número de las clases contra los esquemas componentes que mantiene la clase virtual ya sea de la consulta global o de la consulta modificada, esto se apoya directamente con los atributos de discriminación formulados en la integración de esquemas.

Si se observa que la clase virtual esta compuesta de varias clases, entonces la consulta es descompuesta en subconsultas, dependiendo de los ECs que haya, si hay 2, da lugar a 2 descomposiciones iguales, pero cabe señalar que la sentencia From correlacionada a cada EC ahora es diferente, ya que cuenta con un conjunto de clases en el intervalo de c=1…n.

Donde: c = Clases a materializar

Esta correlación permite dar a conocer las clases atómicas correlacionadas y por lo tanto su EC, Esto ayuda a dividir la búsqueda y reorganizar las subconsultas en los nodos correspondientes con sus funciones correspondientes.

Una vez hecho lo anterior, el submódulo de descomposición procesa cada una de las subconsultas y detecta las clases atómicas que componen la clase virtual constituyendo un número de subconsultas iguales a las clases que forman la clase virtual. Es así como se crean los nodos que comprendes a estas subconsultas, para posteriormente considerar las sentencias Where y Select con e objeto de tomar sus atributos derivados y procesar los predicados y en consecuencia depurar las consultas, esta depuración consiste en:

§ Eliminar nodos

§ Crear nuevos nodos

§ Modificar subconsultas

§ Analizar atributos

§ Analiza Path expresión (en predicados y proyección)

§ Analiza variables de referencia

§ Analiza Métodos de referencia

§ Stand’By de subconsultas

2.2.1.3. Fase 3: Localizar BDC (sitios)

Después que el QD termine, la clase de cada subconsulta resultante debe ser localizada en una BDC única, y es entonces cuando las subconsultas son enviadas al módulo de traducción de la subconsulta, si la BDC mantiene un mismo lenguaje, la subconsulta pasa directamente a la BDC, de otra forma necesita el traductor de consultas.

- ALGORITMO 3. Descomposición en subconsultas

2.2.1.3.1. Consolidación de resultados

Una vez que las subconsultas son procesadas, se procede a regresar los resultados a la raíz, por lo que los subresultados son ahora ensamblados en el submódulo de Consolidación de Resultados, el cual pertenece al Gestor de Consultas. Los subresultados son enviados al nodo padre (forma ascendente) al sitio de consolidación de resultados. Este es apoyado por el módulo de transacciones. El árbol de ejecución de la consulta proyecta esta consolidación. Durante la consolidación los resultados son leídos con el conjunto de objetos de clases y sus respectivas correspondencias.

- ALGORITMO 4. Integración de resultados

A continuación se explica el funcionamiento del algoritmo anterior:

En este algoritmo se propone integrar la respuesta global de tal forma que los nodos hojas mantengan las respuestas de las subconsultas y realizar y proceso de identificación de nodos por clase virtual y subir al nodo N_Final-1 con la información por cada clase virtual a ese nivel, esto quiere decir que un conjunto de objetos permanecen en espera para ser unidos en un nivel contra los Esquemas Componentes. Pero antes de este paso, los resultados son analizados para saber si estos objetos son los mismos, directamente identificados por su oid, si es así, seguirán identificados hasta la respuesta final, y presentados como objetos idénticos.

El siguiente paso es la unión basada en sus EC y la unión correspondiente a las clase virtuales (Clases Federadas). Finalmente, el resultado se coloca en el nodo raíz como lo muestra el algoritmo 4.

2.2.2. Optimización de la consulta federada

Existen algunas técnicas empleadas para la optimización de consultas federadas, sin embargo, es un reto que sigue latente debido a los problemas que presentan la autonomía y la heterogeneidad de las BDC.

Generar excelentes planes de ejecución es un trabajo que empieza durante la descomposición global y las técnicas empleadas para realizar ésta.

Para determinar el plan de ejecución optimo de la consulta global es necesaria información importante que llega de la BDC y que en algunas ocasiones es imposible obtenerla y en otras solo una parte de ella (parcialmente) debido a la autonomía de la BDC. Esta es fundamental para el optimizador de la consulta global. Este problema puede ser solucionado coleccionando estadísticas sobre la BDC.

A continuación se presenta y propone el módulo de descomposición y optimización de la consulta global del Gestor de Consultas (figura No.5.).

- Fig. No.5. Módulo de Descomposición y Optimización de Consultas Globales (Query Descomponer – QD)

2.2.2.1. Técnicas heurísticas para optimizar la fase 2

Antes de iniciar la explicación de la optimización para la fase 2, debe quedar claro que la fase 1 correspondiente a la ejecución de un Parser permanece tal y como esta.

El algoritmo 2 toma una Consulta Global Modificada de la fase 1 y realiza una descomposición en subconsultas, la cual procesa una consulta con a lo más una clase virtual global y que a su vez pueda contener varias clases en diferentes bases de datos componentes, resultado de una operación de integración. Este algoritmo corresponde a la fase 2 y para efectos de optimización de la consulta, en esta sección nos centramos en los siguientes puntos:

§ Eliminar nodos

§ Crear nuevos nodos

§ Modificar subconsultas

§ Analizar atributos

§ Analiza Path expresión

§ Analiza variables de referencia

§ Analiza Métodos de referencia

Para observar las estrategias de optimización presentamos un ejemplo, el cual es una consulta federada hecha por un usuario u, en un sitio s:

REFERENCIAS

· Yolanda López Pedrosa., http://alarcos.inf-cr.uclm.es/doc/bbddavanzadas/federadas.pdf, Jul - 2004

· Dr. Leopoldo Galindo Soria, “Temas selectos de sistemas de bases de datos”, IPN, ESIMEZ, Maestría en ingeniería de sistemas. Feb –2003.

· Dr. Leopoldo Galindo Soria, “Conceptos sobre bases de datos federadas y múltiples BDA”. IPN-CENAC. México. 1994

1 Lesk, M. "How much information is there in the world?" http://www.lesk.com/mlesk/ksg97/ksg.html

2 Schneider, G.M. and Gersting, J.L. An invitation to computer science, 2nd ed. PWS Publishing , Pacific Grove, CA., 1998.

3 Encyclopedia Britannica. "Database". http://www.britannica.com/bcom/eb/article/8/0,5716,29888+1+29424,00.html

4 O'Neill, P. and O'Neil E. Databases: principles, programming and performance. 2nd ed., Morgan Kaufman Publishers, San Francisco, CA., 2000.

5 Weiss, S. and Indurkhya, N. (contributor). Predictive data mining: A practical guide. Morgan Kaufman Publishers, LOC, 1997.

6 Payette, S., Blanchi, C. and Lagoze, C., "Interoperability for digital objects and repositories". D-Lib Magazine 5(5): http://www.dlib.org/dlib/may99/payette/05payette.html

7 Mechanized Reasoning Group, Dipartimento di Informatica e Studi Aziendali Universit degli Studi, "Federated Databases", http://mrg.cs.unitn.it/~mrg/distributed-intelligence/research-topics/fdb.html