<?xml version="1.0" encoding="ISO-8859-1"?><article xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<front>
<journal-meta>
<journal-id>0378-1844</journal-id>
<journal-title><![CDATA[Interciencia]]></journal-title>
<abbrev-journal-title><![CDATA[INCI]]></abbrev-journal-title>
<issn>0378-1844</issn>
<publisher>
<publisher-name><![CDATA[ASOCIACIÓN INTERCIENCIA]]></publisher-name>
</publisher>
</journal-meta>
<article-meta>
<article-id>S0378-18442008000300006</article-id>
<title-group>
<article-title xml:lang="es"><![CDATA[Preoptimización de consultas en fuentes de datos con capacidades limitadas]]></article-title>
<article-title xml:lang="en"><![CDATA[Query preoptimization in data sources with limited capabilities]]></article-title>
<article-title xml:lang="pt"><![CDATA[Preotimização de consultas em fontes de dados com capacidades limitadas]]></article-title>
</title-group>
<contrib-group>
<contrib contrib-type="author">
<name>
<surname><![CDATA[Tovar]]></surname>
<given-names><![CDATA[Elsa]]></given-names>
</name>
<xref ref-type="aff" rid="A01"/>
</contrib>
<contrib contrib-type="author">
<name>
<surname><![CDATA[Vidal]]></surname>
<given-names><![CDATA[María Esther]]></given-names>
</name>
<xref ref-type="aff" rid="A02"/>
</contrib>
</contrib-group>
<aff id="A01">
<institution><![CDATA[,Universidad de Carabobo  ]]></institution>
<addr-line><![CDATA[ Carabobo]]></addr-line>
<country>Venezuela</country>
</aff>
<aff id="A02">
<institution><![CDATA[,Universidad Simón Bolívar  ]]></institution>
<addr-line><![CDATA[ ]]></addr-line>
<country>Venezuela</country>
</aff>
<pub-date pub-type="pub">
<day>00</day>
<month>03</month>
<year>2008</year>
</pub-date>
<pub-date pub-type="epub">
<day>00</day>
<month>03</month>
<year>2008</year>
</pub-date>
<volume>33</volume>
<numero>3</numero>
<fpage>179</fpage>
<lpage>185</lpage>
<copyright-statement/>
<copyright-year/>
<self-uri xlink:href="http://ve.scielo.org/scielo.php?script=sci_arttext&amp;pid=S0378-18442008000300006&amp;lng=en&amp;nrm=iso"></self-uri><self-uri xlink:href="http://ve.scielo.org/scielo.php?script=sci_abstract&amp;pid=S0378-18442008000300006&amp;lng=en&amp;nrm=iso"></self-uri><self-uri xlink:href="http://ve.scielo.org/scielo.php?script=sci_pdf&amp;pid=S0378-18442008000300006&amp;lng=en&amp;nrm=iso"></self-uri><abstract abstract-type="short" xml:lang="es"><p><![CDATA[Tecnologías emergentes tales como Web Semántica, P2P y Grid Semántico han hecho accesible una gran cantidad de fuentes de datos, caracterizadas por propiedades que impactan en la complejidad de la optimización tradicional de consultas y en las tareas de procesamiento. En este trabajo se describe el efecto de las capacidades de consulta limitadas en el proceso de encontrar un buen plan para evaluar una consulta. Este problema es NP-Completo y diferentes enfoques han sido utilizados para encontrar soluciones aproximadas. Se considera el proyecto WebSrcMed, que implementa una estrategia de optimización de dos fases para encontrar planes de ejecución buenos en términos de bajo costo y seguros ya que, al menos, una combinación de fuentes de datos puede responder la consulta. En la primera fase, las descripciones de capacidades limitadas son consideradas para particionar el espacio de búsqueda en conjuntos de preplanes donde las capacidades de la consulta son satisfechas y se selecciona un buen preplán entre ellos. En la fase, el espacio de planes inducidos por el preplán es explorado y se produce un buen plan de ejecución. Debido a que espacio de búsqueda de los preplanes puede ser grande, se requieren técnicas eficientes para explorarlo adecuadamente. Se presenta un algoritmo evolutivo que encuentra eficientemente preplanes seguros y buenos. En un estudio experimental se observó que la solución encuentra buenos preplanes para consultas complejas. La eficiencia del algoritmo utilizado (número de soluciones diferentes respecto al número de soluciones encontradas) es superior a la eficiencia mostrada en técnicas aleatorias existentes]]></p></abstract>
<abstract abstract-type="short" xml:lang="en"><p><![CDATA[Emerging technologies such as Semantic Web, P2P and Semantic Grid have made available a huge number of sources, usually characterized by properties that touch on the complexity of traditional query optimization and processing tasks. In this paper, the effect of limited query capabilities during the process of identifying a good plan to evaluate a query is described. This problem has been found to be NP-Complete and different approaches have been proposed to generate an approximated solution to the problem. The WebSrcMed project, which implements a two-step cost-based optimization strategy to identify a good and safe execution plan, is considered. In a first step, descriptions of the limited query capabilities are considered to partition the space of plans into sets of pre-plans where the query capabilities of the selected sources are satisfied and a good pre-plan is selected among them. In a second step, the space of plans induced by the selected pre-plan is explored, and a good execution plan produced. Since the size of the pre-plans’ solution space may be large, efficient exploration techniques to solve the problem are required. An evolutive algorithm that finds good and safe preplans efficiently is presented. An experimental study led to observe that the solution is able to efficiently identify good pre-plans for complex queries. The efficiency of the algorithm used (number of different solutions related to the total number of solutions found) is better than the efficiency shown by existing randomized techniques]]></p></abstract>
<abstract abstract-type="short" xml:lang="pt"><p><![CDATA[Tecnologias emergentes tais como Web Semântica, P2P e Gris Semântico tem facilitado o acesso a uma grande quantidade de fontes de dados, caracterizadas por propriedades que impactam na complexidade da otimização tradicional de consultas e nas tarefas de processamento. Neste trabalho se descreve o efeito das capacidades de consulta limitadas no processo de encontrar um bom plano para avaliar uma consulta. Este problema é NP-Completo e diferentes enfoques têm sido utilizados para encontrar soluções aproximadas. Se considera o proyecto WebSrcMed, que implementa uma estratégia de otimização de duas fases para encontrar planos de execução bons em termos de baixo custo e seguros já que, ao menos, uma combinação de fontes de dados pode responder a consulta. Na primeira fase, as descrições de capacidades limitadas são consideradas para particionar o espaço de busca em conjuntos de pré-planos onde as capacidades da consulta são satisfeitas e se seleciona um bom pré-plano entre eles. Na fase, o espaço de planos induzidos pelo pré-plano é explorado e se produz um bom plano de execução. Devido a que espaço de busca dos pré-planos pode ser grande, se requerem técnicas eficientes para explorá-lo adequadamente. Apresenta-se um algoritmo evolutivo que encontra eficientemente pré-planos seguros e bons. Em um estudo experimental se observou que a solução encontra bons pré-planos para consultas complexas. A eficiência do algoritmo utilizado (número de soluções diferentes em relação ao número de soluções encontradas) é superior à eficiência mostrada em técnicas aleatórias existentes]]></p></abstract>
<kwd-group>
<kwd lng="es"><![CDATA[Algoritmos Evolutivos]]></kwd>
<kwd lng="es"><![CDATA[Capacidades de Consulta]]></kwd>
<kwd lng="es"><![CDATA[Consultas Limitadas]]></kwd>
<kwd lng="es"><![CDATA[Fuentes de Datos Web]]></kwd>
<kwd lng="es"><![CDATA[Optimización de Consultas]]></kwd>
</kwd-group>
</article-meta>
</front><body><![CDATA[   <B>     <p style="word-spacing: 0; line-height: 100%" align="center"><font face="Verdana" size="3">Preoptimización de consultas en fuentes de datos con capacidades limitadas.</font></p>     <P style="word-spacing: 0; line-height: 100%" align="center"><font face="Verdana" size="2">Elsa Tovar y Mar&iacute;a Esther Vidal</font></P>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Elsa Liliana Tovar Fl&oacute;rez. </font> </B><font face="Verdana" size="2">Licenciada en Computaci&oacute;n, Universidad Central de Venezuela (UCV). Magister y doctorando en Ciencia de la Computaci&oacute;n, USB, Venezuela. Profesora, Universidad de Carabobo, Venezuela. Direcci&oacute;n: Departamento de Computaci&oacute;n, Facultad Experimental de Ciencia y Tecnolog&iacute;a, Universidad de Carabobo, Sector B&aacute;rbula, Naguanagua 2005. Edo. Carabobo, Venezuela. e-mail: eltovar@uc.edu.ve</font></P> <B>    <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Mar&iacute;a Esther Vidal Merodio</font></B><font face="Verdana" size="2">. Ingeniera en Computaci&oacute;n, Magister y Doctora en Ciencia de la Computaci&oacute;n, Universidad Sim&oacute;n Bol&iacute;var (USB), Venezuela. Profesora, USB, Venezuela. e-mail: mvidal@ldc.usb.ve</font></P>      <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2"><b>RESUMEN</b></font></P>      <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Tecnolog&iacute;as emergentes tales como Web Sem&aacute;ntica, P2P y Grid Sem&aacute;ntico han hecho accesible una gran cantidad de fuentes de datos, caracterizadas por propiedades que impactan en la complejidad de la optimizaci&oacute;n tradicional de consultas y en las tareas de procesamiento. En este trabajo se describe el efecto de las capacidades de consulta limitadas en el proceso de encontrar un buen plan para evaluar una consulta. Este problema es NP-Completo y diferentes enfoques han sido utilizados para encontrar soluciones aproximadas. Se considera el proyecto WebSrcMed, que implementa una estrategia de optimizaci&oacute;n de dos fases para encontrar planes de ejecuci&oacute;n buenos en t&eacute;rminos de bajo costo y seguros ya que, al menos, una combinaci&oacute;n de fuentes de datos puede responder la consulta. En la primera fase, las descripciones de capacidades limitadas son consideradas para particionar el espacio de b&uacute;squeda en conjuntos de preplanes donde las capacidades de la consulta son satisfechas y se selecciona un buen prepl&aacute;n entre ellos. En la fase, el espacio de planes inducidos por el prepl&aacute;n es explorado y se produce un buen plan de ejecuci&oacute;n. Debido a que espacio de b&uacute;squeda de los preplanes puede ser grande, se requieren t&eacute;cnicas eficientes para explorarlo adecuadamente. Se presenta un algoritmo evolutivo que encuentra eficientemente preplanes seguros y buenos. En un estudio experimental se observ&oacute; que la soluci&oacute;n encuentra buenos preplanes para consultas complejas. La eficiencia del algoritmo utilizado (n&uacute;mero de soluciones diferentes respecto al n&uacute;mero de soluciones encontradas) es superior a la eficiencia mostrada en t&eacute;cnicas aleatorias existentes.</font></P>  <B>    <P style="word-spacing: 0; line-height: 100%" align="center"><font face="Verdana" size="2">Query preoptimization in data sources with limited capabilities</font></P> </B>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2"><b>SUMMARY</b></font></P>      <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Emerging technologies such as Semantic Web, P2P and Semantic Grid have made available a huge number of sources, usually characterized by properties that touch on the complexity of traditional query optimization and processing tasks. In this paper, the effect of limited query capabilities during the process of identifying a good plan to evaluate a query is described. This problem has been found to be NP-Complete and different approaches have been proposed to generate an approximated solution to the problem. The WebSrcMed project, which implements a two-step cost-based optimization strategy to identify a good and safe execution plan, is considered. In a first step, descriptions of the limited query capabilities are considered to partition the space of plans into sets of pre-plans where the query capabilities of the selected sources are satisfied and a good pre-plan is selected among them. In a second step, the space of plans induced by the selected pre-plan is explored, and a good execution plan produced. Since the size of the pre-plans’ solution space may be large, efficient exploration techniques to solve the problem are required. An evolutive algorithm that finds good and safe preplans efficiently is presented. An experimental study led to observe that the solution is able to efficiently identify good pre-plans for complex queries. The efficiency of the algorithm used (number of different solutions related to the total number of solutions found) is better than the efficiency shown by existing randomized techniques.</font></P>      ]]></body>
<body><![CDATA[<p style="word-spacing: 0; line-height: 100%" align="center"><b><font face="Verdana" size="2">Preotimização de consultas em fontes de dados com capacidades limitadas.</font></b></p>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2"><b>RESUMO</b></font></P>      <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Tecnologias emergentes tais como Web Sem&acirc;ntica, P2P e Gris Sem&acirc;ntico tem facilitado o acesso a uma grande quantidade de fontes de dados, caracterizadas por propriedades que impactam na complexidade da otimiza&ccedil;&atilde;o tradicional de consultas e nas tarefas de processamento. Neste trabalho se descreve o efeito das capacidades de consulta limitadas no processo de encontrar um bom plano para avaliar uma consulta. Este problema &eacute; NP-Completo e diferentes enfoques t&ecirc;m sido utilizados para encontrar solu&ccedil;&otilde;es aproximadas. Se considera o proyecto WebSrcMed, que implementa uma estrat&eacute;gia de otimiza&ccedil;&atilde;o de duas fases para encontrar planos de execu&ccedil;&atilde;o bons em termos de baixo custo e seguros j&aacute; que, ao menos, uma combina&ccedil;&atilde;o de fontes de dados pode responder a consulta. Na primeira fase, as descri&ccedil;&otilde;es de capacidades limitadas s&atilde;o consideradas para particionar o espa&ccedil;o de busca em conjuntos de pr&eacute;-planos onde as capacidades da consulta s&atilde;o satisfeitas e se seleciona um bom pr&eacute;-plano entre eles. Na fase, o espa&ccedil;o de planos induzidos pelo pr&eacute;-plano &eacute; explorado e se produz um bom plano de execu&ccedil;&atilde;o. Devido a que espa&ccedil;o de busca dos pr&eacute;-planos pode ser grande, se requerem t&eacute;cnicas eficientes para explor&aacute;-lo adequadamente. Apresenta-se um algoritmo evolutivo que encontra eficientemente pr&eacute;-planos seguros e bons. Em um estudo experimental se observou que a solu&ccedil;&atilde;o encontra bons pr&eacute;-planos para consultas complexas. A efici&ecirc;ncia do algoritmo utilizado (n&uacute;mero de solu&ccedil;&otilde;es diferentes em rela&ccedil;&atilde;o ao n&uacute;mero de solu&ccedil;&otilde;es encontradas) &eacute; superior &agrave; efici&ecirc;ncia mostrada em t&eacute;cnicas aleat&oacute;rias existentes.</font></P>  <B>    <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">PALABRAS CLAVE / </font> </B><font face="Verdana" size="2"> Algoritmos Evolutivos / Capacidades de Consulta / Consultas Limitadas / Fuentes de Datos Web / Optimizaci&oacute;n de Consultas /</font></P> <FONT SIZE=2>    <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2"><b>Recibido:</b> 16/04/2007. <b> Modificado:</b> 28/01/2008. <b> Aceptado: </b> 29/01/2008.</font></FONT></P>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Las tecnolog&iacute;as emergentes tales como la Web Sem&aacute;ntica, P2P y el Grid Sem&aacute;ntico han hecho accesible una cantidad enorme de fuentes de datos, extendidas a lo largo del planeta en universidades, laboratorios, institutos, bibliotecas, centros de investigaci&oacute;n y otras instituciones privadas o p&uacute;blicas. Adicionalmente, la Internet se ha extendido como una plataforma efectiva para la telecomunicaci&oacute;n, adem&aacute;s de ser un escenario de gran potencialidad para el intercambio y la b&uacute;squeda de informaci&oacute;n. La complejidad de las tareas propias de los sistemas de gesti&oacute;n de datos como la optimizaci&oacute;n de consultas y el procesamiento de datos (Ramakrishnan y Gehrke, 2000) se pueden ver afectadas por ciertos elementos de la Internet.</font></P>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Usualmente, las fuentes de datos que pueden ser accedidas a trav&eacute;s de la Internet tienen capacidades de procesamiento de consultas diferentes, por lo que algunas pueden tener limitaciones en el tipo de operaci&oacute;n a ejecutar. Adem&aacute;s, muchas de estas fuentes suelen tener interfaces que requieren de la instanciaci&oacute;n de alg&uacute;n atributo para retornar otros atributos requeridos en la consulta. Estas caracter&iacute;sticas de las fuentes de datos conforman las llamadas capacidades limitadas de las fuentes de datos consideradas en este trabajo.</font></P>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">V&iacute;a Internet puede haber cientos o miles de fuentes de datos con capacidades limitadas que pudieran contestar una consulta en particular. Esta propiedad puede impactar en las tareas de optimizaci&oacute;n y evaluaci&oacute;n de consultas. Tradicionalmente, para responder una consulta se deben ejecutar las siguientes tareas: 1) el an&aacute;lisis para chequear la sintaxis y la sem&aacute;ntica (<I>parsing</I>); 2) la optimizaci&oacute;n que consiste inicialmente en la enumeraci&oacute;n de todos los planes de ejecuci&oacute;n y, en segundo lugar, la escogencia de aquel que minimice el costo de procesamiento basado en alg&uacute;n criterio de selecci&oacute;n; y 3) el plan de evaluaci&oacute;n escogido en el paso anterior es ejecutado y los elementos de la base de datos que satisfacen la consulta dada son retornados al usuario. Tradicionalmente, los planes de ejecuci&oacute;n son representados como una estructura de &aacute;rbol donde los nodos hojas representan subobjetivos base de la consulta y los nodos intermedios corresponden a los diferentes operadores que relacionan a los subobjetivos de la consulta. Los nodos internos est&aacute;n anotados con informaci&oacute;n de los algoritmos que ser&aacute;n utilizados durante la evaluaci&oacute;n de la consulta.</font></P>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">En este trabajo se presenta el efecto en la tarea de optimizaci&oacute;n de las capacidades limitadas de las fuentes de datos que pueden ser usadas para responder una consulta. Este problema de optimizaci&oacute;n ha sido abordado anteriormente por varios autores (Levy <I>et al</I>., 1996; Papakonstantionou <I>et al</I>., 1996; Haas <I>et al</I>., 1997; Florescu <I>et al</I>., 1999; Vidal, 2000), as&iacute; como en el proyecto WebSrcMed (Vidal <I>et al</I>., 1998; Zadorozhny <I>et al</I>., 2002). Estos trabajos proponen soluciones basadas en arquitecturas de mediadores y traductores (Wiederhold, 1992). Los mediadores son componentes de software que se encargan de realizar las tareas de descomponer las consultas en distintos subobjetivos (llamada tambi&eacute;n tarea de reescritura basada en la capacidad<I> </I>(CBR:<I> capability based rewritting</I>), identificar las fuentes de datos relevantes para cada subconsulta, y encontrar un buen plan de ejecuci&oacute;n. Por otra parte, los traductores est&aacute;n conectados a las fuentes de datos y tienen como objetivo adaptar las subconsultas enviadas por el mediador al lenguaje de consulta local de las fuentes de datos, y traducir las respuestas que deben ser devueltas hacia el mediador.</font></P>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">El proyecto WebSrcMed implementa una estrategia de optimizaci&oacute;n de dos fases para encontrar planes de ejecuci&oacute;n buenos en t&eacute;rminos de su bajo costo y ser seguros, ya que al menos una combinaci&oacute;n de fuentes de datos puede responder la consulta. En la primera fase de la optimizaci&oacute;n, las descripciones de las capacidades limitadas son consideradas para particionar el espacio de b&uacute;squeda en conjuntos de preplanes. Formalmente, un prepl&aacute;n es un orden parcial de ejecuci&oacute;n de los subobjetivos de la consulta. Esta fase culmina con la escogencia de un buen prepl&aacute;n. En la segunda fase, el espacio de planes inducidos por el prepl&aacute;n es explorado y se produce un buen plan de ejecuci&oacute;n. Raschid <I>et al</I>. (2000) demostraron que el tama&ntilde;o del espacio de preplanes es exponencial respecto al n&uacute;mero de subobjetivos de la consulta. Vidal <I>et al</I>. (1998) utilizaron una estrategia aleatoria llamada &quot;mejoramiento iterativo&quot; que encuentra preplanes de buen costo en un tiempo aceptable. Sin embargo, el n&uacute;mero de soluciones repetidas del total de soluciones generadas durante la preoptimizaci&oacute;n es muy grande, indicando una baja eficiencia en la manera de explorar el espacio de b&uacute;squeda.</font></P>     ]]></body>
<body><![CDATA[<P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Debido a que el espacio de b&uacute;squeda de preplanes es grande y que se requieren t&eacute;cnicas para explorarlos eficientemente, en este trabajo se presenta un algoritmo evolutivo capaz de recorrer en forma eficiente el espacio de b&uacute;squeda de preplanes y encontrar uno de costo m&iacute;nimo. Los algoritmos evolutivos son metaheur&iacute;sticas para optimizaci&oacute;n y b&uacute;squeda de soluciones en espacios no lineales.</font></P> <B>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Ejemplo</font></P> </B>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Consid&eacute;rese una arquitectura de mediadores y traductores. El<I> </I>mediador interact&uacute;a directamente con una aplicaci&oacute;n, desde la cual los usuarios interrogan al sistema a trav&eacute;s de consultas especificadas en el lenguaje SQL (Ramakrishnan y Gehrke, 2000). El mediador se encarga de descomponer las consultas en subconsultas, de determinar qu&eacute; fuentes de datos son relevantes a cada subconsulta y de identificar un plan de ejecuci&oacute;n para esa consulta. Los traductores se comunican con el mediador y se encargan de resolver los conflictos de comunicaci&oacute;n con las fuentes de datos, que designaremos como F<SUB>1</SUB>, F<SUB>2</SUB> y F<SUB>3</SUB>, aut&oacute;nomas y distribuidas por distintas regiones de Venezuela. F<SUB>1</SUB>, F<SUB>2</SUB> y F<SUB>3</SUB> son fuentes de datos de un dominio com&uacute;n relacionado con informaci&oacute;n propia de centros de investigaci&oacute;n de Venezuela. Se asume que no todas las fuentes de datos pueden ejecutar las mismas operaciones sobre los datos para una consulta dada. En la <a href="#tab1"> Tabla I </a> se describen las relaciones seg&uacute;n el modelo relacional. Seguidamente se presentan dos consultas.</font></P>      <P style="word-spacing: 0; line-height: 100%" align="center"><a name="tab1"><img border="0" src="/img/fbpe/inci/v33n3/art06tab1.jpg" width="543" height="230"></a></P>  <I>    
<P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Consulta 1</font></I><font face="Verdana" size="2">: &quot;Indique la ubicaci&oacute;n del centro de investigaci&oacute;n donde trabaja el Dr. Alonso Gamero&quot;.</font></P>      <blockquote>      <P style="word-spacing: 0; line-height: 100%; margin-top: 0; margin-bottom: 0" align="justify"><font face="Verdana" size="2">select Centro_Inv.ubicaci&oacute;n</font></P>     <P style="word-spacing: 0; line-height: 100%; margin-top: 0; margin-bottom: 0" align="justify"><font face="Verdana" size="2">from Investigador, Centro_Inv</font></P>     <P style="word-spacing: 0; line-height: 100%; margin-top: 0; margin-bottom: 0" align="justify"><font face="Verdana" size="2">where Investigador.nombre_inv=&nbsp;</font></P>      <P style="word-spacing: 0; line-height: 100%; margin-top: 0; margin-bottom: 0" align="justify"><font face="Verdana" size="2"> &quot;Alonso Gamero&quot; and</font></P>      ]]></body>
<body><![CDATA[<P style="word-spacing: 0; line-height: 100%; margin-top: 0; margin-bottom: 0" align="justify"><font face="Verdana" size="2">Investigador.lug-trabajo=</font></P>      <P style="word-spacing: 0; line-height: 100%; margin-top: 0; margin-bottom: 0" align="justify"><font face="Verdana" size="2">Centro_Inv.nombre-cen</font></P>  </blockquote>      <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Para esta consulta podr&iacute;a generarse un plan de ejecuci&oacute;n que tenga el siguiente orden del operador: Investigador <img border="0" src="/img/fbpe/inci/v33n3/art06form1.jpg" width="27" height="12">  Centro_Inv. Sin embargo, este plan no puede ser evaluado por las fuentes disponibles, ya que F2 requiere instanciar el atributo ubicaci&oacute;n de la relaci&oacute;n Centro_Inv para poder generar su informaci&oacute;n. Un optimizador de consultas debe identificar que este plan de ejecuci&oacute;n no es seguro, ya que ninguna fuente de datos puede evaluarlo, y debe entonces descartarlo o quiz&aacute;s nunca generarlo. Con este ejemplo se puede observar que las fuentes de datos con capacidades limitadas pueden llevar a generar tanto planes de ejecuci&oacute;n seguros como no seguros, situaci&oacute;n que no se presenta en los tradicionales sistemas relacionales. Otro aspecto del problema es el que trata con los distintos planes de ejecuci&oacute;n que, a&uacute;n siendo seguros, presentan diferentes costos y, por ello, deben ser estudiados a fin de escoger uno de costo menor. Para estudiar este aspecto del problema se presenta la siguiente cosnsulta.</font></P>  <I>    
<P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Consulta 2</font></I><font face="Verdana" size="2">. &quot;Dar los t&iacute;tulos de los libros publicados por todos los investigadores que nacieron el 7 de junio de 1966&quot;.</font></P>      <blockquote>      <P style="word-spacing: 0; line-height: 100%; margin-top: 0; margin-bottom: 0" align="justify"><font face="Verdana" size="2">select t&iacute;tulo-l</font></P>     <P style="word-spacing: 0; line-height: 100%; margin-top: 0; margin-bottom: 0" align="justify"><font face="Verdana" size="2">from Investigador, Libros_Pub</font></P>     <P style="word-spacing: 0; line-height: 100%; margin-top: 0; margin-bottom: 0" align="justify"><font face="Verdana" size="2">where Investigador.ci =</font></P>      <P style="word-spacing: 0; line-height: 100%; margin-top: 0; margin-bottom: 0" align="justify"><font face="Verdana" size="2">Libros_Pub. ci-autor and</font></P>      <P style="word-spacing: 0; line-height: 100%; margin-top: 0; margin-bottom: 0" align="justify"><font face="Verdana" size="2">fecha-nac = 07/06/1966</font></P>  </blockquote>      ]]></body>
<body><![CDATA[<P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Sup&oacute;ngase que, para este ejemplo, se consideran las fuentes de datos presentadas anteriormente y otras fuentes de datos m&aacute;s (F4, F5, F6, F7) que contienen informaci&oacute;n adicional sobre los investigadores venezolanos y sus publicaciones. Para responder a la consulta, el mediador hace uso de la siguiente informaci&oacute;n: a) un esquema con las relaciones en el mediador como se aprecia en la<a href="#tab2"> Tabla II</a>, y <a href="#tab2">b</a>) un conjunto de descripciones de las fuentes de datos y sus capacidades (md). Para describir las capacidades limitadas de cada fuente de datos es necesario indicar, en el mediador, c&oacute;mo pueden ser consultadas las relaciones; es decir, qu&eacute; atributos deben ser instanciados y qu&eacute; valores de atributos se retornan en cada relaci&oacute;n. Esta informaci&oacute;n puede ser llevada como</font></P>      <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Mdi: (Fi, Ri, cap)</font></P>      <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">donde Fi: identificador de la fuente de datos, Ri: identificador de la relaci&oacute;n, cap: conjunto de capacidades limitadas de la fuente de datos Fi respecto a la relaci&oacute;n Ri.</font></P>      <P style="word-spacing: 0; line-height: 100%" align="center"><a name="tab2"><img border="0" src="/img/fbpe/inci/v33n3/art06tab2.jpg" width="480" height="186"></a></P>      
<P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">El conjunto cap indica qu&eacute; atributos deben ser instanciados (atributos de entrada) en la relaci&oacute;n Ri para poder retornar otros atributos de Ri (atributos de salida). Estas limitaciones se expresan como</font> </P>      <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">atributos de entrada </font><font size="2" face="Symbol">&reg;</font><font face="Verdana" size="2"><B> </B>atributos de salida.</font></P>      <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">En este ejemplo, las capacidades de las fuentes de datos est&aacute;n expresadas en <a href="#tab3"> Tabla III</a> y de ella se obtiene que la relaci&oacute;n ‘Investigador’ de la fuente de datos F1 puede ser consultada sin ning&uacute;n tipo de restricciones mediante Md1, pues no requiere conocer el valor de ninguno de sus atributos para devolver los valores del resto de los atributos que contiene ([ ] </font><font size="2" face="Symbol">&reg;</font><font face="Verdana" size="2"> ci, nombre-inv, e-mail-inv, fecha-nac, lug-trabajo). No sucede igual con las relaciones ‘Investigador’ de las fuentes de datos F4 y F5, descritas en Md2 y Md3, respectivamente, donde se requiere conocer los valores de ‘ci’ para retornar los valores de los atributos ‘nombre-inv’, ‘e-mail-inv’, ‘fecha-nac’, ‘lug-trabajo’ (ci </font><font size="2" face="Symbol">&reg;</font><font face="Verdana" size="2"><B> </B></font><font face="Verdana" size="2"> nombre-inv, e-mail-inv, fecha-nac, lug-trabajo ) y de ‘fecha-nac’ para retornar ‘ci’, ‘nombre-inv’, ‘e-mail-inv’, ‘lug-trabajo’<I> </I>(fecha-nac </font><font size="2" face="Symbol">&reg;</font><font face="Verdana" size="2"><B> </B></font><font face="Verdana" size="2">ci,<B> </B>nombre-inv, e-mail-inv, lug-trabajo). Debido a que las relaciones ‘Investigador’ y ‘Libros Pub’ tienen varias descripciones en el mediador (Md1, Md2, Md3 y Md5, Md6, Md7), la cantidad de planes de ejecuci&oacute;n est&aacute; determinada por la combinaci&oacute;n de las relaciones involucradas en la consulta que el mediador haga respetando las capacidades de las fuentes de datos. Uno de los siete planes de ejecuci&oacute;n que se tienen para la consulta 2 es, por ejemplo, Libros_Pub <img border="0" src="/img/fbpe/inci/v33n3/art06form1.jpg" width="27" height="12">  Investigador<SUB>fecha-nac= 07/06/1966</SUB>, tomando a Libros_Pub de F3 seg&uacute;n est&aacute; indicado en Md5 y a Investigador de F1 seg&uacute;n indica Md1.</font></P>      
<P style="word-spacing: 0; line-height: 100%" align="center"><a name="tab3"><img border="0" src="/img/fbpe/inci/v33n3/art06tab3.jpg" width="526" height="213"></a></P>      
<P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">A medida que se tratan consultas con m&aacute;s relaciones involucradas en este tipo de operadores (operadores binarios como el <I>join</I>), el espacio de posibles planes de ejecuci&oacute;n crece exponencialmente. Ante la imposibilidad de recorrer exhaustivamente el espacio de b&uacute;squeda de planes de ejecuci&oacute;n, surge la necesidad de dise&ntilde;ar estrategias eficientes que gu&iacute;en la b&uacute;squeda hacia un plan de ejecuci&oacute;n seguro y bueno. Por seguro se entiende que, por lo menos, haya una combinaci&oacute;n de descripciones de las relaciones, entre aquellas que est&aacute;n disponibles en las fuentes de datos, que provea la respuesta a la consulta. Por otra parte, un plan de ejecuci&oacute;n bueno es aquel que, adem&aacute;s de seguro, tenga un costo de ejecuci&oacute;n tal que no se encarezca inadecuadamente el tiempo de respuesta de la consulta.</font></P> <B>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Antecedente: El Proyecto WebSrcMed</font></P> </B>     ]]></body>
<body><![CDATA[<P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">WebSrcMed es un proyecto que trata con capacidades limitadas en fuentes de datos accesibles v&iacute;a Internet. Tiene una arquitectura de mediadores y traductores. Sus principales caracter&iacute;sticas se centran en su enfoque de la tarea de capacidad basada en reescritura (CBR) y el optimizador de consultas de dos fases. La tarea CBR especifica qu&eacute; propiedades tiene el mediador. En WebSrcMed, la CBR es tal que el mediador solo acepta aquella consulta para la cual hay, por lo menos, una fuente de datos que pueda evaluarla. Pero la caracter&iacute;stica m&aacute;s novedosa de WebSrcMed es el enfoque de la optimizaci&oacute;n en dos fases, la preoptimizaci&oacute;n y la optimizaci&oacute;n de la consulta. En primera instancia, la preoptimizaci&oacute;n limita la b&uacute;squeda de una soluci&oacute;n a las &aacute;reas del espacio de soluciones en donde se encuentren planes de ejecuci&oacute;n seguros. Luego, en la optimizaci&oacute;n, solo se enumeran planes que est&aacute;n dentro de las porciones del espacio de soluciones identificadas en la preoptimizaci&oacute;n. En la preoptimizaci&oacute;n se identifican porciones del espacio de planes de ejecuci&oacute;n donde solo existen planes seguros. Cada porci&oacute;n est&aacute; caracterizada por un prepl&aacute;n. Formalmente, un prepl&aacute;n corresponde a un orden parcial de los subobjetivos de una consulta y un conjunto de dependencias entre estos subobjetivos que se establecen a partir de las descripciones en el mediador. Los planes de ejecuci&oacute;n corresponden a una enumeraci&oacute;n simple de los subobjetivos de una consulta. M&aacute;s espec&iacute;ficamente, los preplanes constan de dos conjuntos, uno conformado por &oacute;rdenes<B> </B>parciales de los subobjetivos de la consulta y el otro es el conjunto de &oacute;rdenes de precedencias entre los subobjetivos. Ambos componentes representan las restricciones impuestas por las capacidades de las fuentes de datos escogidas para responder a la consulta. En trabajos anteriores (Vidal, 2000) se ha mostrado que existe una correlaci&oacute;n positiva entre el promedio de costos para los preplanes de una consulta y sus correspondientes mejores planes de ejecuci&oacute;n.</font></P>  <B>    <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Modelo de Costos</font></P> </B>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">En WebSrcMed, cada prepl&aacute;n caracteriza a un sector del espacio de b&uacute;squeda donde hay planes de ejecuci&oacute;n seguros, indicando qu&eacute; fuentes de datos son relevantes para responder a la consulta y las capacidades limitadas que ellas exhiben. Adem&aacute;s, el prepl&aacute;n indica el orden de ejecuci&oacute;n (a efectuarse en las fuentes de datos correspondientes) de los subobjetivos de la consulta. Mantiene m&eacute;tricas asociadas a cada una de las capacidades de las fuentes de datos, tales como: a) costo remoto: tiempo que toma retornar la primera tupla; b) costo de descargar<I> (downloading)</I>: costo de descargar datos relevantes desde la fuente de datos, lo que puede significar acceso a m&uacute;ltiples p&aacute;ginas de memoria; y c) cardinalidad del resultado: n&uacute;mero de tuplas retornadas. El modelo de costos para los preplanes toma en consideraci&oacute;n la existencia de dependencias entre los subobjetivos de la consulta para encontrar el costo de un prepl&aacute;n. Vidal (2000) propuso un algoritmo basado en una metaheur&iacute;stica conocida como &quot;mejoramiento iterativo&quot;. Este algoritmo genera, de forma aleatoria, un prepl&aacute;n inicial al que sucesivamente se le van aplicando transformaciones que llevan a nuevos preplanes seguros. Sin embargo, el n&uacute;mero de veces que encuentra el mismo prepl&aacute;n es muy grande respecto al n&uacute;mero total de preplanes encontrados.</font></P>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Este trabajo presenta un algoritmo evolutivo, como alternativa al algoritmo que usa WebSrcMed, para realizar la fase de preoptimizaci&oacute;n. La hip&oacute;tesis consiste en establecer que la implementaci&oacute;n de conceptos como el cruce de preplanes progenitores que puedan combinar sus mejores caracter&iacute;sticas (aquellas que lo hacen tener un costo m&aacute;s bajo) para hacerlas heredar a sus descendientes (otros preplanes) y la implementaci&oacute;n del concepto evolutivo de mutaci&oacute;n, que permite explorar sectores distintos del espacio de b&uacute;squeda (evitando el riesgo de encontrar un m&aacute;ximo local como soluci&oacute;n definitiva). Ello llevar&aacute; a mejorar la eficiencia en la exploraci&oacute;n del espacio de b&uacute;squeda, encontrando buenos y seguros preplanes con un m&iacute;nimo de repeticiones.</font></P>  <B>    <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Formalizaci&oacute;n del Problema</font></P> </B>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Este trabajo aborda el problema de encontrar un orden parcial de los subobjetivos de una consulta, al cual se denomina prepl&aacute;n. Los par&aacute;metros del problema y las soluciones est&aacute;n asociados al manejo de la optimizaci&oacute;n de consultas en la arquitectura de mediadores-traductores y a la naturaleza heterog&eacute;nea y de capacidades limitadas de las fuentes de datos. Por esta raz&oacute;n, es necesario definir previamente algunos conceptos espec&iacute;ficos del contexto del problema.</font></P>  <I>    <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Descripci&oacute;n de una fuente de datos</font></I><font face="Verdana" size="2">. La descripci&oacute;n de una fuente de datos md (llamada tambi&eacute;n descripci&oacute;n del mediador) consiste en una tripleta (F, R, cap) donde F: identificador de la fuente de datos, R: identificador de la relaci&oacute;n, y cap: conjunto de capacidades limitadas de la fuente de datos F respecto a la relaci&oacute;n R. Las limitaciones se expresan como</font></P>      <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">atributos de entrada <B>-&gt; </B>atributos de salida</font></P>  <I>    <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Esquema del mediador</font></I><font face="Verdana" size="2">. Al conjunto de todas las relaciones Ri y de todas las descripciones mdj en el mediator se le conoce con el nombre de esquema del mediador MD.</font></P>  <I>    <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Consulta en el mediador</font></I><font face="Verdana" size="2">. Una consulta en el mediador mq es un conjunto de subobjetivos {C<SUB>1</SUB>,C<SUB>2</SUB>,...,Cn} donde Ci=(R,A<SUP>R</SUP>), R: identificador de una relaci&oacute;n descrita en el mediador, y A<SUP>R</SUP>: subconjunto de atributos de la relaci&oacute;n R referidos en la consulta.</font></P>  <I>    ]]></body>
<body><![CDATA[<P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">smqo</font></I><font face="Verdana" size="2">. Dada una consulta en el mediador mq={C<SUB>1</SUB>,C<SUB>2</SUB>,...,C<SUB>n</SUB>}, un ordenamiento seguro para mq es un orden parcial smqo=&lt;SetSub<SUB>1</SUB>, SetSub<SUB>2</SUB>,...,SetSub<SUB>m</SUB>&gt;, con m£n, de los subobjetivos de la consulta donde cada SetSubi es una partici&oacute;n de mq y por cada subobjetivo Ci en mq, existe una descripci&oacute;n md en el mediador y md es satisfecha por Ci en smqo. Una descripci&oacute;n en el mediador <I>md</I> es satisfecha por un subobjetivo Ci si Ci contiene constantes o valores en uno o algunos de sus atributos que instancian los atributos de entrada de md.</font></P>  <I>    <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">smqod</font></I><font face="Verdana" size="2">. Dada una consulta en el mediador mq={C<SUB>1</SUB>,C<SUB>2</SUB>,...,C<SUB>n</SUB>} y un ordenamiento seguro para mq, es un orden parcial smqo=&lt;SetSub<SUB>1</SUB>,SetSub<SUB>2</SUB>,...,SetSub<SUB>m</SUB>&gt;<I>, </I>un conjunto de dependencias del ordenamiento de la consulta en el mediador smqod es el conjunto de pares (Ci,Cj), con i</font><font size="2" face="Symbol">¹</font><font face="Verdana" size="2">j tal que Ci</font><font size="2" face="Symbol">&Icirc;</font><font face="Verdana" size="2">SetSubk y Cj</font><font size="2" face="Symbol">&Icirc;</font><font face="Verdana" size="2">SetSubl, SetSubk precede a SetSubl en smqo, y Cj contiene un atributo que es instanciado por Ci en smqo.</font></P> <I>    <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Prepl&aacute;n</font></I><font face="Verdana" size="2">. Dada una consulta en el mediador mq={C<SUB>1</SUB>,C<SUB>2</SUB>,...,C<SUB>n</SUB>}, un prepl&aacute;n pp es un par (smqo, smqod) donde smqo corresponde a un ordenamiento seguro de los subobjetivos de la consulta en el mediador y smqod es el conjunto de dependencias del ordenamiento para mq en smqo.</font></P>  <I>    <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Funci&oacute;n objetivo para los preplanes</font></I><font face="Verdana" size="2">. Sea s<SUB>opp</SUB> el espacio de soluciones o espacio de b&uacute;squeda de los preplanes en el problema de optimizaci&oacute;n combinatoria preoptimizaci&oacute;n de una consulta en ambientes de fuentes de datos con capacidades limitadas, la funci&oacute;n c/<SUB>so</SUB>: s<SUB>opp </SUB></font><font size="2" face="Symbol">&reg;</font><font face="Verdana" size="2"> <B>R</B> es aquella que asigna un valor real a cada prepl&aacute;n de s<SUB>opp</SUB> para medir en forma cuantitativa su calidad como soluci&oacute;n.</font></P>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">En el problema de la preoptimizaci&oacute;n de consultas se utiliza un modelo de costos para asignar un valor correspondiente al costo de un prepl&aacute;n (Raschid <I>et al</I>., 2000). En este trabajo se pretende encontrar un prepl&aacute;n que constituya una buena soluci&oacute;n al problema de la preoptimizaci&oacute;n. El prepl&aacute;n encontrado ser&aacute; una soluci&oacute;n &oacute;ptima, definida como</font></P>  <I>    <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Soluci&oacute;n &oacute;ptima</font></I><font face="Verdana" size="2">. Dado un conjunto de valores reales asignados por una funci&oacute;n objetivo c/<SUB>so</SUB>: s<SUB>o </SUB></font><font size="2" face="Symbol">&reg;</font><font face="Verdana" size="2"> <B>R</B> para un subconjunto de soluciones del espacio de b&uacute;squeda s<SUB>o</SUB> en una instancia de un problema de optimizaci&oacute;n combinatoria o<SUB>opt</SUB>= (o, c/<SUB>so</SUB>), la soluci&oacute;n &oacute;ptima al problema es aquella que sea el m&iacute;nimo o el m&aacute;ximo, seg&uacute;n sea el tipo de optimizaci&oacute;n, de los valores asignados por c/<SUB>so</SUB> al subconjunto considerado de s<SUB>o</SUB>.</font></P>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">El prepl&aacute;n que constituye la soluci&oacute;n &oacute;ptimal al problema de la preoptimizaci&oacute;n de consultas en fuentes de datos con capacidades limitadas, caracteriza a un conjunto de planes de ejecuci&oacute;n como seguros; es decir, planes para los cuales existe una combinaci&oacute;n de fuentes de datos que puede contestar la consulta y, adem&aacute;s, son buenos en t&eacute;rminos de bajo costo. M&aacute;s formalmente, un plan bueno y seguro se define como</font></P>  <I>    <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Plan seguro</font></I><font face="Verdana" size="2">. Dada una consulta mq={C1,…,Cn} y un conjunto de descripciones en el mediador MD={md1,…,mdn} de forma que Ci= (Ri,Ai) y mdi representa una descripci&oacute;n de capacidad sobre Ri, y sea ps(MD) un ordenamiento de los subobjetivos en mq, donde cada Ci est&aacute; asociado a su correspondiente descriptor de capacidad en MD, se dice que ps(MD) es un plan seguro si para todo Ci= (Ri,Ai) en sp(MD) se cumplen las siguientes condiciones: a) los atributos de Ri en Ai son un subconjunto de los atributos en mdi, y b) los atributos de entrada de mdi est&aacute;n instanciados.</font></P>  <I>    <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Atributo</font></I> <font face="Verdana" size="2"> <I>instanciado</I>.<B> </B>Sea ps(MD)=&lt;C1,…, Cn&gt; un ordenamiento de subobjetivos sobre un conjunto de descripciones de capacidades de fuentes de datos MD={md1,…,mdn}, sea Ci=(Ci,Ai) un subobjetivo en sp(MD) y sea Att un atributo en Ci, se dice que Att est&aacute; instanciado en ps(MD) si se cumple alguna de las siguientes condiciones:</font></P>      <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">a) Existe un par (Att,v) en Ai y v es una constante.</font></P>      ]]></body>
<body><![CDATA[<P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">b) Existe un par (Att,X) en Ai, donde X es una variable y existe un subobjetivo Cg=(Rg,Ag) en sp(MD) con g&lt;i, tal que</font></P>      <P style="word-spacing: 0; line-height: 100%; margin-top: 0; margin-bottom: 0" align="justify"><font face="Verdana" size="2">b1) Existe un par (att’, X) en Ag</font></P>      <P style="word-spacing: 0; line-height: 100%; margin-top: 0; margin-bottom: 0" align="justify"><font face="Verdana" size="2">b2) Att’ es un atributo de salida en mdg, es decir, att’ es un atributo de salida en el descriptor de capacidades asociado a Cg.</font></P>  <I>    <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Plan bueno</font></I><font face="Verdana" size="2">. Sea ps(MD) un plan seguro y sea umbral un valor real, se dice que ps(MD) es bueno si costo (ps(MD)) &lt; umbral, donde costo es la funci&oacute;n de costos de los planes.</font></P>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Con base en las definiciones presentadas anteriormente, se puede decir que:</font></P>      <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">1- La preoptimizaci&oacute;n de una consulta en un ambiente de fuentes de datos con capacidades limitadas es una instancia o<SUB>opt</SUB>= (o,c/<SUB>so</SUB>) del problema de optimizaci&oacute;n combinatoria O<SUB>opt<I> </I></SUB>, y</font></P>      <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">2- La instancia o<SUB>opt</SUB>= (o,c/<SUB>so</SUB>) se define como o= (p,s<SUB>o</SUB>), donde p= (MD,mq), siendo MD el esquema del mediador y mq un ordenamiento de los subobjetivos de la consulta que acepta el mediador, para la cual hay, por lo menos, una combinaci&oacute;n de descripciones de las fuentes de datos en el mediador que tienen los datos y las capacidades de procesamiento requeridas para responder a la consulta (Vidal, 2000).</font></P>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Adem&aacute;s, s<SUB>o</SUB>= s<SUB>opp</SUB>, donde s<SUB>opp</SUB>: espacio de b&uacute;squeda de los preplanes de la consulta que orientan hacia planes de ejecuci&oacute;n seguros, y c/<SUB>so</SUB>= c/s<SUB>opp</SUB> es la funci&oacute;n objetivo mediante la cual se le asigna un valor a cada preplan encontrado en el espacio de b&uacute;squeda. Debido a que la t&eacute;cnica mediante la cual se explorar&aacute; el espacio de b&uacute;squeda es la de un algoritmo evolutivo, esta funci&oacute;n objetivo es la funci&oacute;n de aptitud. Esta funci&oacute;n mide cu&aacute;n interesante es un prepl&aacute;n en t&eacute;rminos del costo. En el contexto de este problema, mientras menos costoso sea un prepl&aacute;n m&aacute;s apto es para su medio. En esta funci&oacute;n no aplican restricciones para garantizar soluciones que est&eacute;n en una regi&oacute;n factible del espacio de b&uacute;squeda pues solo se aplica a preplanes v&aacute;lidos. Bajo esta conceptualizaci&oacute;n de la aptitud, no son necesarias otras funciones de &quot;reparaci&oacute;n&quot; de individuos no adaptados. La funci&oacute;n objetivo es</font></P>      <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Aptitud(prepl&aacute;n)= 1/Costo(prepl&aacute;n) + K</font></P>      <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">donde K: constante conveniente para evitar resultados indeterminados de la aptitud (prepl&aacute;n) y costo (prepl&aacute;n) es un valor derivado de aplicar la extensi&oacute;n del modelo de costos usado por Predator (Seshadri, 1997) al cual se le han a&ntilde;adido las m&eacute;tricas que requiere WebSrcMed para procesar una consulta.</font></P>  <B>    ]]></body>
<body><![CDATA[<P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Algoritmo Evolutivo</font></P> </B>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">La soluci&oacute;n al problema de la preoptimizaci&oacute;n es encontrar un buen prepl&aacute;n en t&eacute;rminos de bajos costos para la consulta aceptada por el mediador. Entonces, el espacio de soluciones al problema es el espacio de los preplanes de la consulta, la poblaci&oacute;n. As&iacute;, cada prepl&aacute;n es un individuo de la poblaci&oacute;n, como se aprecia en la<a href="#fig1"> Figura 1</a>. En este caso, la preoptimizaci&oacute;n debe considerar m&uacute;ltiples descripciones de fuentes de datos para cada relaci&oacute;n en el esquema del mediador. Cada una de estas descripciones (md, <I>mediator description</I>) puede indicar un conjunto diferente de capacidades de procesamiento de consultas de la fuente de datos. Estas capacidades son expl&iacute;citamente indicadas en el prepl&aacute;n a trav&eacute;s del ordenamiento de subobjetivos de la consulta<SUB> </SUB>y del conjunto de dependencias entre esos subobjetivos, smqo y smqod respectivamente<SUB>. </SUB>Considerando el prepl&aacute;n como una estructura de datos (compuesta del smqo y el smqod) lo que diferencia a un prepl&aacute;n de otro es la asignaci&oacute;n de las mdi para cada subobjetivo de la consulta que impacta en la conformaci&oacute;n del smqo. Una vez asignadas las mdi y conformado el smqo se pueden estudiar las dependencias generadas, el smqod. De esta forma, la representaci&oacute;n de los individuos de la poblaci&oacute;n puede ser conformada por un ordenamiento de descripciones del mediador que corresponden, una a una, con el ordenamiento de los subobjetivos de la consulta.</font></P>      <P style="word-spacing: 0; line-height: 100%" align="center"><a name="fig1"><img border="0" src="/img/fbpe/inci/v33n3/art06fig1.jpg" width="429" height="251"></a></P>  <B>    
<P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Concepto de &quot;Har&eacute;n&quot;</font></P> </B>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Con la intenci&oacute;n de encontrar la forma de minimizar el n&uacute;mero de preplanes repetidos en el proceso de recorrer el espacio de b&uacute;squeda, se propone una implementaci&oacute;n novedosa, el concepto de ‘har&eacute;n’. Este har&eacute;n, es una analog&iacute;a con la organizaci&oacute;n social de ciertas especies del reino animal, basada en la existencia de alg&uacute;n progenitor dominante que se cruza con los individuos del sexo contrario, que constituyen su har&eacute;n. Si se escoge un individuo al que se llamar&aacute; el &quot;macho dominante&quot;, este individuo, que es el de mayor aptitud en la poblaci&oacute;n, se cruza con las mejores hembras para legar a sus descendientes los rasgos gen&eacute;ticos que les permitir&aacute;n adaptarse bien a su medio. Por su parte, las hembras ven temporalmente afectada su aptitud debido a la gestaci&oacute;n y cr&iacute;a de su descendiente. Para escoger, tanto al &quot;macho dominante&quot; como a las &quot;mejores hembras&quot;, se us&oacute; el mecanismo de selecci&oacute;n de la ruleta normalizada, donde la probabilidad de selecci&oacute;n de un individuo es proporcional a su aptitud, simulando as&iacute; la selecci&oacute;n natural.</font></P>  <I>    <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Mutaci&oacute;n</font></P> </I>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">La mutaci&oacute;n representa la alteraci&oacute;n de un individuo en uno de sus genes. El individuo a mutar es escogido, al azar, entre todos los individuos de la poblaci&oacute;n. Los pasos para la mutaci&oacute;n se muestran en la <a href="#fig2"> Figura 2</a>.</font></P>      <P style="word-spacing: 0; line-height: 100%" align="center"><a name="fig2"><img border="0" src="/img/fbpe/inci/v33n3/art06fig2.jpg" width="443" height="233"></a></P>  <I>    
<P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Cruce</font></P> </I>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Para comprender el criterio que gu&iacute;a a la herencia es necesario dar un vistazo a los costos asociados a cada descripci&oacute;n en el mediador. Los costos considerados son el tiempo que toma el retorno de la primera tupla y la cardinalidad. Si la asignaci&oacute;n de descripciones en el mediador, escogidas en un prepl&aacute;n, no tienen dependencias entre ellas, se presume que la estrategia de evaluaci&oacute;n de los subobjetivos en el mediador ser&aacute; la <I>bottom-up</I> que corresponde a la usada cuando se ejecuta un <I>join</I> entre dos subobjetivos, donde uno de ellos o los dos se encuentran en fuentes de datos remotas. En este caso, se establece que el tiempo que toma retornar la primera tupla (para cada descripci&oacute;n remota escogida) impacta significativamente sobre el costo del prepl&aacute;n. Por otra parte, si las descripciones escogidas tienen dependencias entre ellas, se presume que la estrategia de evaluaci&oacute;n de los subobjetivos en el mediador ser&aacute; la <I>top-down</I>. En esta estrategia, el <I>join</I> que se ejecuta entre los subobjetivos involucrados se implementa como un <I>nested loop join,</I> lo que implica que el impacto sobre el costo del prepl&aacute;n viene dado por la cardinalidad de las descripciones escogidas. Con esto presente, el cruce entre individuos de la poblaci&oacute;n lleva a considerar qu&eacute; descripciones de subobjetivos ser&aacute;n heredados por el descendiente. Si el progenitor &quot;hembra&quot; no tiene dependencias entre sus descripciones en el mediador (mdi) entonces se escoge la descripci&oacute;n que tenga el mayor tiempo de retorno de la primera tupla y se cambia por su hom&oacute;logo en el progenitor &quot;macho&quot;, si en este &uacute;ltimo ese tiempo es menor y se conservan las dem&aacute;s descripciones de la &quot;hembra&quot;. Esto hace que el descendiente tenga un genotipo diferente a sus dos padres y que sea menos costoso. Si la &quot;hembra&quot; tiene dependencias entre las descripciones que la conforman entonces se toma la descripci&oacute;n que tenga la m&aacute;s alta cardinalidad y se cambia por la descripci&oacute;n hom&oacute;loga en el otro progenitor en caso de que esta &uacute;ltima sea de menor magnitud. Cuando en ambos casos la descripci&oacute;n escogida para el intercambio tiene un costo menor, el descendiente tendr&aacute; el genotipo del progenitor cuya descripci&oacute;n tuvo costo mayor pero con esa descripci&oacute;n cambiada. En la<a href="#fig3"> Figura 3</a> se muestra c&oacute;mo se establece el criterio que rige el cruce entre dos individuos de la poblaci&oacute;n.</font></P> <B>     ]]></body>
<body><![CDATA[<P style="word-spacing: 0; line-height: 100%" align="center"><a name="fig3"><img border="0" src="/img/fbpe/inci/v33n3/art06fig3.jpg" width="454" height="360"></a></P>      
<P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Estudio Experimental</font></P> </B>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Se parte de la hip&oacute;tesis que la exploraci&oacute;n del espacio de b&uacute;squeda de preplanes mediante la implementaci&oacute;n de operadores evolutivos, como el cruce entre preplanes y la mutaci&oacute;n de preplanes, aportar&aacute; una manera eficiente de encontrar un prepl&aacute;n de costo m&iacute;nimo. Por ello, la evaluaci&oacute;n experimental del algoritmo evolutivo se contrasta con los resultados de aplicar la metaheur&iacute;stica ‘mejoramiento iterativo’ para resolver el mismo problema. En cada comparaci&oacute;n se eval&uacute;an los algoritmos para los siguientes criterios: a) costo del mejor prepl&aacute;n conseguido, el valor cuantitativo del prepl&aacute;n de menor costo; b) tiempo de ejecuci&oacute;n, que mide en milisegundos el tiempo que toma la metaheur&iacute;stica para conseguir el mejor prepl&aacute;n para una consulta dada; y c) eficiencia del algoritmo, una medida para observar el n&uacute;mero de repeticiones de la misma soluci&oacute;n en el proceso de recorrer el espacio de b&uacute;squeda. Puede verse como una medida de la cobertura del espacio de b&uacute;squeda de preplanes y se calcula como</font></P>      <blockquote>       <blockquote>         <blockquote>      <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Eficiencia= nuevas soluciones / n&uacute;mero total de soluciones generadas.</font></P>      </blockquote>   </blockquote> </blockquote>      <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">El algoritmo evolutivo fue codificado en Quintus Prolog 3.4, el cat&aacute;logo con las descripciones del mediador y las relaciones del esquema l&oacute;gico se tomaron de archivos planos generados con una herramienta llamada CEBOLLIN (Rodr&iacute;guez y G&oacute;mez, 2001). Con la finalidad de evaluar el comportamiento del algoritmo evolutivo en variados escenarios, se simul&oacute; la preoptimizaci&oacute;n de la consulta para cuando a) el conjunto de fuentes de datos se iba incrementando, a&ntilde;adiendo al cat&aacute;logo inicial descripciones de fuentes de datos nuevas mediante la aplicaci&oacute;n de transformaciones <I>addbind</I> (Vidal, 2000), y b) el conjunto de fuentes de datos se transforma al sustituir descripciones de fuentes de datos existentes por otras m&aacute;s restrictivas, aplicando transformaciones <I>bind</I> (Vidal, 2000) al cat&aacute;logo inicial. Los experimentos fueron ejecutados en una m&aacute;quina Compaq con Pentium 4 de 500MHz bajo Windows 2000 Professional, con 256MB de RAM. Para cada tipo de consultas (peque&ntilde;as, medianas y grandes) fue necesario entonar los par&aacute;metros del algoritmo evolutivo, pues la incidencia del n&uacute;mero de subobjetivos de la consulta impacta en el tama&ntilde;o del espacio de b&uacute;squeda de preplanes. Por otra parte, las transformaciones Bind van imponiendo restricciones a los preplanes, lo que implica una disminuci&oacute;n del espacio de soluciones. Esto orient&oacute; la b&uacute;squeda del tama&ntilde;o de la poblaci&oacute;n hacia un n&uacute;mero m&aacute;ximo que permitiera aceptar la consulta y favorecer la convergencia del algoritmo hacia una soluci&oacute;n buena.</font></P>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Se determin&oacute; experimentalmente que el algoritmo evolutivo presentado en este trabajo encuentra buenas soluciones en el espacio de b&uacute;squeda de los preplanes. Sin embargo, los valores medidos en el tiempo de corrida del algoritmo no son competitivos con los encontrados usando mejoramiento iterativo en consultas peque&ntilde;as y medianas. El algoritmo evolutivo ofrece la mejor soluci&oacute;n al problema cuando se preoptimizan consultas grandes y se aplican las transformaciones <I>bind</I>. La eficiencia es hasta 8,5 veces mejor a la reportada por mejoramiento iterativo y el tiempo no es significativamente mayor en el algoritmo evolutivo. Los experimentos permitieron observar que no se puede generalizar sobre el uso de una estrategia en particular para explorar el espacio de b&uacute;squeda de preplanes. Los resultados llevan a concluir que el tama&ntilde;o de la consulta y las modificaciones al cat&aacute;logo del mediador (constante dinamismo del ambiente heterog&eacute;neo y de capacidades limitadas) inciden en la calidad del prepl&aacute;n encontrado y en el tiempo que toma encontrarlo, por lo que en algunos casos ser&aacute; mejor utilizar una estrategia aleatoria y en otros un algoritmo evolutivo. En la <a href="#fig4"> Figura 4</a>, se observa el mejor comportamiento de los algoritmos evolutivos <I>vs</I> mejoramiento iterativo.</font></P>      <P style="word-spacing: 0; line-height: 100%" align="center"><a name="fig4"><img border="0" src="/img/fbpe/inci/v33n3/art06fig4.jpg" width="353" height="755"></a></P>  <B>    
]]></body>
<body><![CDATA[<P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Conclusiones</font></P> </B>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Los algoritmos evolutivos son adecuados en la exploraci&oacute;n del espacio de b&uacute;squeda de preplanes para la preoptimizaci&oacute;n de consultas en ambientes con fuentes de datos de capacidades limitadas, dado que</font></P>     <blockquote>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">1– Se logr&oacute; establecer la codificaci&oacute;n de los individuos en base a las descripciones de las fuentes de datos en el mediador que correspond&iacute;an con subobjetivos de la consulta a preoptimizar.</font></P>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">2– Fue acertado el uso de las m&eacute;tricas del tiempo que tarda en llegar la primera tupla (<I>latency)</I> y la cardinalidad del resultado (<I>cardinality</I>) presentados en (Zadorozhny <I>et al.</I>, 2002) como criterios que favorecen la evoluci&oacute;n de la poblaci&oacute;n en la implementaci&oacute;n de la operaci&oacute;n de cruce.</font></P>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">3– La implementaci&oacute;n del concepto de &quot;har&eacute;n&quot;, del cual no se tiene ninguna referencia en la bibliogr&aacute;fica revisada, permiti&oacute; mejorar la selecci&oacute;n de individuos al evitar sustancialmente la repetici&oacute;n de parejas en el cruce, factor que hubiera desmejorado la eficiencia del algoritmo al generar gran cantidad de soluciones repetidas. La eficiencia se mantuvo por encima del 40% en todos los experimentos realizados, llegando en algunos casos cerca del 90%.</font></P>  </blockquote>  <B>    <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Agradecimientos</font></P> </B>     <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Las autoras agradecen a los miembros del Grupo de Investigaci&oacute;n de Bases de Datos de la Universidad Sim&oacute;n Bol&iacute;var por sus comentarios y sugerencias.</font></P>  <B>    <P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">Referencias</font></P> </B>     <!-- ref --><P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">1. Florescu D, Levy A, Manolescu I, Suciu D (1999) Query Optimization in the Presence of Limited Access Patterns. <I>Proc. ACM SIGMOD Conf.</I> http://citeseer.ist.psu.edu/article/florescu99query. html.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=1065813&pid=S0378-1844200800030000600001&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">2. Haas L, Kossmann D, Wimmers E, Yang J (1997) Optimizing Queries across Diverse Data Sources. <I>Proc. 23<SUP>rd</SUP> Int. Conf. VLDB</I>. pp. 276-285.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=1065814&pid=S0378-1844200800030000600002&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">3. Levy AY, Rajaraman A, Ordille J (1996) Querying Heterogeneous Information Sources Using Source Descriptions. <I>Proc. 22<SUP>rd</SUP> Int. Conf. VLDB</I>. pp. 276-285.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=1065815&pid=S0378-1844200800030000600003&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">4. Papakonstantionou Y, Gupta A,  Garcia-Molina H, Ullman J (1996). <I>A Query  Translation Scheme for Rapid Implementation  of  Wrappers</I>. 4th Intl. Conf. on Deductive and Object-Oriented Databases; LNCS 1013. Singapore. Springer, Berlin, Alemania. pp. 161-186.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=1065816&pid=S0378-1844200800030000600004&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">5. Ramakrishnan R,  Gehrke J (2000).  <I>Database Management Systems</I>.  McGraw-Hill, Madison, WI, EEUU. pp. 271-347.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=1065817&pid=S0378-1844200800030000600005&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">6. Raschid L, Vidal M,  Zarodohnv V  (2000) <I>An Optimizer Strategy to Generate Good Low Cost Plans for Mediator Queries</I>. Technical Report University of Maryland,  College Park, MD, EEUU. pp. 18-28.</font> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=1065818&pid=S0378-1844200800030000600006&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">7. Rodr&iacute;guez A, G&oacute;mez A (2001) <I>CEBOLLIN: Herramienta para asistir en la evaluaci&oacute;n de t&eacute;cnicas de optimizaci&oacute;n de consultas en fuentes de el Web</I>. Tesis, Universidad Sim&oacute;n Bol&iacute;var, Caracas, Venezuela. pp. 28-60.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=1065819&pid=S0378-1844200800030000600007&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">8. Seshadri P (1997) <I>Predator: Design and Implementation</I>. Computer Sciences Department. Cornell University. http:// www.cs.cornell.edu/ Info/Projects/PREDATOR/designdoc.html</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=1065820&pid=S0378-1844200800030000600008&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">9. Seshadri P (1998) Predator: a resource for database research. <I>Sigmod Rec. 27</I>: 16-20.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=1065821&pid=S0378-1844200800030000600009&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">10. Tovar E (2004) <I>Un Algoritmo Evolutivo para la Preoptimizaci&oacute;n de Consultas en Fuentes de Datos con Capacidades Limitadas</I>. Tesis. Universidad Sim&oacute;n Bol&iacute;var. Caracas, Venezuela. pp. 15-103.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=1065822&pid=S0378-1844200800030000600010&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">11. Vidal M (2000) <I>T&eacute;cnicas de Mediaci&oacute;n en Fuentes de Datos Heterog&eacute;neas</I>. Tesis. Universidad Sim&oacute;n Bol&iacute;var. Caracas, Venezuela. pp. 10-34.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=1065823&pid=S0378-1844200800030000600011&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">12. Vidal M, Raschid L, Urhan T (1998) <I>WebSrcMed:  A Mediator for Scaling up to Multiple Web Accessible Sources (WebSources)</I>. Technical Report UMIACS, University of Maryland, College Park, MD, EEUU. pp. 31-39.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=1065824&pid=S0378-1844200800030000600012&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --><!-- ref --><P style="word-spacing: 0; line-height: 100%" align="justify"><font face="Verdana" size="2">13. Zadorozhny V, Raschid L, Vidal M, Urhan T, Bright L (2002) <I>Efficient Evaluation of Queries in a Mediator for WebSources</I>. ACM SIGMOD 2002 June 4-6, Madison, WI, EEUU. pp.85-96.</font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[&#160;<a href="javascript:void(0);" onclick="javascript: window.open('/scielo.php?script=sci_nlinks&ref=1065825&pid=S0378-1844200800030000600013&lng=','','width=640,height=500,resizable=yes,scrollbars=1,menubar=yes,');">Links</a>&#160;]<!-- end-ref --> ]]></body>
<back>
<ref-list>
<ref id="B1">
<label>1</label><nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Florescu]]></surname>
<given-names><![CDATA[D]]></given-names>
</name>
<name>
<surname><![CDATA[Levy]]></surname>
<given-names><![CDATA[A]]></given-names>
</name>
<name>
<surname><![CDATA[Manolescu]]></surname>
<given-names><![CDATA[I]]></given-names>
</name>
<name>
<surname><![CDATA[Suciu]]></surname>
<given-names><![CDATA[D]]></given-names>
</name>
</person-group>
<source><![CDATA[Query Optimization in the Presence of Limited Access Patterns]]></source>
<year>1999</year>
<publisher-name><![CDATA[Proc. ACM SIGMOD Conf]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B2">
<label>2</label><nlm-citation citation-type="confpro">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Haas]]></surname>
<given-names><![CDATA[L]]></given-names>
</name>
<name>
<surname><![CDATA[Kossmann]]></surname>
<given-names><![CDATA[D]]></given-names>
</name>
<name>
<surname><![CDATA[Wimmers]]></surname>
<given-names><![CDATA[E]]></given-names>
</name>
<name>
<surname><![CDATA[Yang]]></surname>
<given-names><![CDATA[J]]></given-names>
</name>
</person-group>
<source><![CDATA[Optimizing Queries across Diverse Data Sources]]></source>
<year>1997</year>
<conf-name><![CDATA[23rd Int. Conf. VLDB]]></conf-name>
<conf-loc> </conf-loc>
<page-range>276-285</page-range></nlm-citation>
</ref>
<ref id="B3">
<label>3</label><nlm-citation citation-type="confpro">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Levy]]></surname>
<given-names><![CDATA[AY]]></given-names>
</name>
<name>
<surname><![CDATA[Rajaraman]]></surname>
<given-names><![CDATA[A]]></given-names>
</name>
<name>
<surname><![CDATA[Ordille]]></surname>
<given-names><![CDATA[J]]></given-names>
</name>
</person-group>
<source><![CDATA[Querying Heterogeneous Information Sources Using Source Descriptions]]></source>
<year>1996</year>
<conf-name><![CDATA[22rd Conf. VLDB]]></conf-name>
<conf-loc> </conf-loc>
<page-range>276-285</page-range></nlm-citation>
</ref>
<ref id="B4">
<label>4</label><nlm-citation citation-type="confpro">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Papakonstantionou]]></surname>
<given-names><![CDATA[Y]]></given-names>
</name>
<name>
<surname><![CDATA[Gupta]]></surname>
<given-names><![CDATA[A]]></given-names>
</name>
<name>
<surname><![CDATA[Garcia-Molina]]></surname>
<given-names><![CDATA[H]]></given-names>
</name>
<name>
<surname><![CDATA[Ullman]]></surname>
<given-names><![CDATA[J]]></given-names>
</name>
</person-group>
<source><![CDATA[A Query Translation Scheme for Rapid Implementation of Wrappers]]></source>
<year>1996</year>
<conf-name><![CDATA[4th Conf. on Deductive and Object-Oriented Databases]]></conf-name>
<conf-loc>Singapore. Springer, Berlin </conf-loc>
<page-range>161-186</page-range></nlm-citation>
</ref>
<ref id="B5">
<label>5</label><nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Ramakrishnan]]></surname>
<given-names><![CDATA[R]]></given-names>
</name>
<name>
<surname><![CDATA[Gehrke]]></surname>
<given-names><![CDATA[J]]></given-names>
</name>
</person-group>
<source><![CDATA[Database Management Systems]]></source>
<year>2000</year>
<page-range>271-347</page-range><publisher-loc><![CDATA[Madison^eWI WI]]></publisher-loc>
<publisher-name><![CDATA[McGraw-Hill]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B6">
<label>6</label><nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Raschid]]></surname>
<given-names><![CDATA[L]]></given-names>
</name>
<name>
<surname><![CDATA[Vidal]]></surname>
<given-names><![CDATA[M]]></given-names>
</name>
<name>
<surname><![CDATA[Zarodohnv]]></surname>
<given-names><![CDATA[V]]></given-names>
</name>
</person-group>
<source><![CDATA[An Optimizer Strategy to Generate Good Low Cost Plans for Mediator Queries]]></source>
<year>2000</year>
<page-range>18-28</page-range><publisher-loc><![CDATA[^eMD MD]]></publisher-loc>
<publisher-name><![CDATA[Technical Report University of Maryland, College Park]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B7">
<label>7</label><nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Rodríguez]]></surname>
<given-names><![CDATA[A]]></given-names>
</name>
<name>
<surname><![CDATA[Gómez]]></surname>
<given-names><![CDATA[A]]></given-names>
</name>
</person-group>
<source><![CDATA[CEBOLLIN: Herramienta para asistir en la evaluación de técnicas de optimización de consultas en fuentes de el Web]]></source>
<year>2001</year>
<page-range>28-60</page-range><publisher-loc><![CDATA[Caracas ]]></publisher-loc>
<publisher-name><![CDATA[Universidad Simón Bolívar]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B8">
<label>8</label><nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Seshadri]]></surname>
<given-names><![CDATA[P]]></given-names>
</name>
</person-group>
<source><![CDATA[Predator: Design and Implementation]]></source>
<year>1997</year>
<publisher-name><![CDATA[Computer Sciences Department. Cornell University]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B9">
<label>9</label><nlm-citation citation-type="journal">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Seshadri]]></surname>
<given-names><![CDATA[P]]></given-names>
</name>
</person-group>
<article-title xml:lang="en"><![CDATA[Predator: a resource for database research]]></article-title>
<source><![CDATA[Sigmod Rec.]]></source>
<year>1998</year>
<volume>27</volume>
<page-range>16-20</page-range></nlm-citation>
</ref>
<ref id="B10">
<label>10</label><nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Tovar]]></surname>
<given-names><![CDATA[E]]></given-names>
</name>
</person-group>
<source><![CDATA[Un Algoritmo Evolutivo para la Preoptimización de Consultas en Fuentes de Datos con Capacidades Limitadas]]></source>
<year>2004</year>
<page-range>15-103</page-range><publisher-loc><![CDATA[Caracas ]]></publisher-loc>
<publisher-name><![CDATA[Universidad Simón Bolívar]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B11">
<label>11</label><nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Vidal]]></surname>
<given-names><![CDATA[M]]></given-names>
</name>
</person-group>
<source><![CDATA[Técnicas de Mediación en Fuentes de Datos Heterogéneas]]></source>
<year>2000</year>
<page-range>10-34</page-range><publisher-loc><![CDATA[Caracas ]]></publisher-loc>
<publisher-name><![CDATA[Universidad Simón Bolívar]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B12">
<label>12</label><nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Vidal]]></surname>
<given-names><![CDATA[M]]></given-names>
</name>
<name>
<surname><![CDATA[Raschid]]></surname>
<given-names><![CDATA[L]]></given-names>
</name>
<name>
<surname><![CDATA[Urhan]]></surname>
<given-names><![CDATA[T]]></given-names>
</name>
</person-group>
<source><![CDATA[WebSrcMed: A Mediator for Scaling up to Multiple Web Accessible Sources (WebSources)]]></source>
<year>1998</year>
<page-range>31-39</page-range><publisher-loc><![CDATA[^eMD MD]]></publisher-loc>
<publisher-name><![CDATA[University of Maryland, College Park]]></publisher-name>
</nlm-citation>
</ref>
<ref id="B13">
<label>13</label><nlm-citation citation-type="book">
<person-group person-group-type="author">
<name>
<surname><![CDATA[Zadorozhny]]></surname>
<given-names><![CDATA[V]]></given-names>
</name>
<name>
<surname><![CDATA[Raschid]]></surname>
<given-names><![CDATA[L]]></given-names>
</name>
<name>
<surname><![CDATA[Vidal]]></surname>
<given-names><![CDATA[M]]></given-names>
</name>
<name>
<surname><![CDATA[Urhan]]></surname>
<given-names><![CDATA[T]]></given-names>
</name>
<name>
<surname><![CDATA[Bright]]></surname>
<given-names><![CDATA[L]]></given-names>
</name>
</person-group>
<source><![CDATA[Efficient Evaluation of Queries in a Mediator for WebSources]]></source>
<year>2002</year>
<page-range>85-96</page-range><publisher-loc><![CDATA[Madison^eWI WI]]></publisher-loc>
<publisher-name><![CDATA[ACM SIGMOD]]></publisher-name>
</nlm-citation>
</ref>
</ref-list>
</back>
</article>
