Uma máquina extensível para suporte a novos modelos de execução de consultas

Uma Máquina Extensível para Suporte a Novos Modelos de Execução de Consultas Fausto V. M. Ayres1*, Fabio A. M. Porto2, Rubens N. Melo1 1

Dep. de Informática, Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) 2

Dep. de Engenharia de Sistemas, Instituto Militar de Engenharia (IME)

e-mail: [email protected], [email protected], [email protected] Abstract Querying processing in traditional Database Management Systems (DBMS) has been extensively studied in the literature and adopted in industry. Such success is, in part, due to the performance of their Query Execution Engine (QEE) for supporting the execution of traditional queries. The advent of the web and its semi-structured data model brings new query scenarios, suggesting new execution models such as: adaptive, continuous, and stream based. To support this models, the traditional QEE must be extended, resulting in a great development effort as the one recently seen to support the XML data model. This paper propose the design and construction of an extensible QEE adapted to new execution models. For each scenario we consider that an execution model is the combination of the scenario’s execution characteristics. Therefore, our approach is to implement each execution characteristic as a module and each execution model as a combination of this modules. Thus, by extending this QEE through designing new modules, new execution models are supported. To achieve this goal, we use a software framework technique to produce the QEEF (Query Execution Engine Framework). With the best of our knowledge we did not find similar work in the literature.

1. Introdução A adoção de Sistemas de Gerência de Banco de Dados (SGBDs) Relacionais no gerenciamento de banco de dados é uma realidade na indústria. O sucesso desses sistemas se deu, em parte, pela eficiência no processamento de consultas que tem sido largamente estudado pela comunidade de banco de dados [20]. Essa eficiência deve-se ao otimizador de consultas, que produz Planos de Execução de Consultas (PECs) otimizados, e à Máquina de Execução de Consultas (MEC) que recebe e executa um PEC segundo um modelo de execução de consultas. Consideramos um modelo de execução de consultas como um conjunto de características capturadas a partir de um certo cenário. Por exemplo, no cenário tradicional, as características de execução são: paralelismo, distribuição e fluxo de controle direcionado a demanda. Com o surgimento do modelo computacional baseado na Internet e de novos modelos de dados (p.ex. semi-estruturados [1]), novos cenários de execução de consultas foram produzidos, tais como: 1. Consultas que precisam lidar com variações nas condições de execução, tais como: tempo de acesso às fontes de dados, seletividade e falta de memória ([2], [3], [6], [7] e [18]). *

Professor do CEFET-RJ (parcialmente licenciado)

2. Consultas do tipo publish/subscribe que precisam ser reavaliadas de tempos em tempos, de acordo com a necessidade do usuário ([9], [10]). 3. Consultas sobre streams de dados, nas quais os dados precisam ser processados à medida que chegam ([11], [19] e [21]). Tais cenários suscitaram novas características de execução, tais como: adaptabilidade do PEC e fluxo de controle direcionado a dados, ambas não suportadas pelas MECs tradicionais. Por outro lado, a extensão das MECs tradicionais pode requerer um esforço considerável de desenvolvimento [22], como o visto recentemente nos SGBDs comerciais para o suporte ao modelo de dados XML. A proposta deste artigo consiste em projetar e construir uma MEC extensível que implemente um modelo de execução. Nossa abordagem consiste em utilizar módulos de execução para implementar as características de execução. A combinação destes módulos em um PEC permite que a MEC suporte a um determinado modelo de execução de consultas. Portanto, a especificação de novos módulos provê a extensão da MEC para suportar novos modelos de execução. A idéia de usar módulos de execução como operadores de um PEC não é nova, a exemplo dos operadores Exchange [16] e Eddies [3], que encapsulam respectivamente, o paralelismo e a adaptabilidade entre operadores algébricos. Porém, não conhecemos na literatura uma MEC que possa combinar e estender módulos de maneira uniforme e flexível visando o suporte a diferentes modelos de execução. Para projetar a MEC extensível utilizamos a técnica de framework de software [14] produzindo o QEEF (Query Execution Engine Framework) [4]. A partir de uma instanciação do QEEF, obtemos a MEC AQEE (Adaptive Query Execution Engine) que suporta o modelo de execução do cenário 1 acima. Este trabalho está organizado nas seguintes seções: a seção 2 descreve os cenários de execução mencionados; a seção 3 apresenta as características de execução; a seção 4 especifica a arquitetura da MEC extensível; a seção 5 mostra um estudo de caso e, finalmente, na seção 6 apresentamos as conclusões deste trabalho. 2. Cenários de Execução de Consultas Nesta seção detalharemos os cenários apresentados na introdução deste trabalho bem como os principais trabalhos relacionados a estes cenários. 2.1. Preliminares Uma máquina de execução de consultas (MEC) é responsável pela execução de um plano de execução de consultas (PEC) fornecido, em geral, pelo otimizador de um SGBD. Um PEC é composto por um conjunto de operadores que se relacionam de forma a produzir o resultado de uma consulta enviada à máquina de execução. A maioria dos SGBDs representam um PEC através de uma árvore onde nós são operadores, as folhas são as fonte de dados, e arcos são os relacionamentos entre os operadores na forma produtorconsumidor. Árvores de execução podem apresentar a topologia linear ou ramificada (bushy). 2.2. Cenário de Execução Tradicional O estado d’arte sobre MECs tradicionais se baseia na interface iterador (iterator) [17], na qual os operadores implementam as operações:

Open: prepara o operador para produzir dados; Next: produz um dado sob demanda do operador consumidor ; Close: finaliza a execução do operador. A chamada a uma dessas operações sobre o operador raiz de um PEC propagará a mesma pelos seus respectivos operadores filhos e assim por diante, até atingir as fontes de dados (folhas). A chamada next retorna uma tupla por vez e é executada sob demanda, ou seja, cada operador só produzirá dados quando solicitado por um operador consumidor impedindo alocação desnecessária de recursos computacionais. Como resultado, conectando-se cada par de operadores relacionados num plano, pode-se executar qualquer plano em linha (pipeline), aumentando o desempenho e produzindo resultados para o usuário o mais cedo possível (first-tuple first). Dentre as vantagens desta técnica está a extensibilidade em relação a novos operadores e entre diferentes implementações de um mesmo operador [5]. Outra característica do modelo execução tradicional é o uso do operador Exchange [16] para permitir a execução paralela e dos operadores Send e Receive [20] para permitir a execução distribuída. 2.3. Cenário de Execução Adaptativa Neste cenário, a MEC adapta a execução conforme condições em tempo de execução. As variações dinâmicas ocorrem uma vez que os operadores em um PEC: a) têm seu desempenho prejudicado devido à imprevisibilidade de acesso às fontes de dados envolvidas na consulta, principalmente em se tratando de fontes web. b) detectam um problema interno, por exemplo, falta de memória. Considera-se um sistema de processamento de consultas adaptativo se (i) recebe informações do seu ambiente, (ii) usa estas informações para determinar o seu comportamento e (iii) processa de forma contínua, gerando uma interação entre o ambiente e o sistema. Desta forma, a execução adaptativa oferece uma otimização em tempo de execução (dinâmica), em contraste com o processo tradicional de otimização que é estático. A execução adaptativa sobre um conjunto de operadores de um PEC pode ser feita a nível de tupla ou a nível de fragmento. No primeiro caso, cada tupla é direcionada para o operador de maior desempenho, até completar todas as operações necessárias e ser enviada para a saída. No segundo caso, a execução ocorrerá de forma tradicional dentro de um fragmento do PEC até que seja detectado algum problema, e neste caso, a execução do fragmento é interrompida e o otimizador é chamado para gerar outro fragmento alternativo para ser executado. Entre as principais soluções encontradas na literatura estão: Query Scrambling [2], Eddies [3], Dynamic Query Scheduling [6], Hybrid [7] e Tukwila [18]. 2.4. Cenário de Execução Contínua A execução de consultas de forma contínua permite aos usuários obterem novos resultados de um banco de dados sem que a mesma consulta seja submetida repetidamente. Em geral, o fluxo de controle é direcionado a dados, ou seja, com a chegada de novos dados, novos resultados são produzidos. Além disso, a duração de uma consulta pode ser muito longa. Exemplos de trabalhos relacionados são: TelegraphCQ [9] e NiagaraCQ [10].

2.5. Cenário de Execução baseada em Streams Este cenário de execução é caracterizado pelos seguintes elementos: • Os dados da stream chegam online; • A MEC não tem controle sobre a ordem na qual os elementos da stream chegam para serem processados; • Uma stream pode ter tamanho ilimitado; • Os dados são processados uma única vez devido às limitações de espaço na memória. Exemplos de aplicações para este cenário incluem: aplicações financeiras, aplicações de gerência do tráfego de rede; aplicações de personalização na web utilizando click-streams e aplicações que processam dados de chamadas telefônicas. Exemplos de trabalhos relacionados com este cenário são: [11], TurboPath [18] e Continuous Eddies [21]. Usaremos estes cenários como exemplos de extensibilidade necessários para que uma MEC possa suportar, de maneira incremental, diferentes e novos requisitos de aplicações. Na próxima seção apresentamos as características de execução. 3. Características de Execução de Consultas A partir de uma análise das máquinas de execução que suportam os cenários descritos na seção anterior, observamos algumas abstrações, que denominamos de características de execução de consultas, que podem estar presentes em um ou mais modelos de execução e que podem assumir diferentes estados dependendo do modelo considerado. Algumas destas características foram introduzidas por [17]. São elas: • Sincronismo – define o estado da execução de um operador quando ele requer serviços ou dados de um outro operador. Existem três possíveis estados: wait (pipeline síncrono), wait-all (seqüencial síncrono) e no-wait (assíncrono); • Paralelismo – ocorre quando dois operadores processam dados de forma independente, ou seja, o consumo do dado não está sincronizado com a sua produção. Existem dois tipos: intra e inter operador; • Distribuição – diz respeito a localização distribuída dos operadores em um PEC de modo a suportar o consumo de dados a partir de um operador remoto; • Fluxo de Dados – especifica a ordem na qual os dados são processados. Existem dois tipos: Fixed, onde os dados percorrem o mesmo caminho através dos operadores, e Adaptive, onde os dados percorrem caminhos diferentes através dos operadores dependendo do desempenho desses operadores; • Fluxo de Controle – refere-se ao tipo de controle entre operadores formando um encadeamento de execução entre operadores consumidores e produtores (ver Figura 1). As alternativas são: (a) Demand-Driven (b) Data-Driven. Esses fluxos podem ser combinados através dos operadores de controle (c) PassiveScheduler e (d) Active-Scheduler • Tempo de Resposta – refere-se ao momento no qual os resultados da consulta estarão disponíveis para a aplicação do usuário. Existem dois tipos: First Tuple, requer que os dados sejam enviados para o usuário imediatamente à medida que sejam produzidos, e Last Tuple, requer que os dados sejam enviados para o usuário somente quando todos tiverem sido produzidos.

op get

op put

op get

op get

op put

op put

op put

op get

op

op

op

op

a)

b)

c)

d)

Figura 1. Fluxos de Controle

A Tabela 1 sugere os relacionamentos mais comuns entre os cenários e as características de execução encontradas. Observe que os cenários permitem vários estados alternativos de uma mesma característica. A associação de um cenário às características de execução nele presentes, determina a funcionalidade a ser implementada (ou oferecida) pela MEC no suporte ao respectivo cenário. Tabela 1. Combinação de Características de Execução Características Estados Cenários de Execução Trad. 1 2 3 Sincronismo wait X X wait-all X X * no-wait * * * X Distribuição yes * X X X no X * X X Paralelismo inter X * X intra * X X Fluxo de Dados Fixed * * adaptive * X * Fluxo de Controle demand-driven * X X data-driven X X * Tempo de Resposta first tuple * * * * last tuple X X Legenda: (*)=configuração mais relevante, (X)=configuração possível

4. Arquitetura da MEC Extensível 4.1. Definição Embora diferentes arquiteturas de MECs sejam encontradas na literatura, não é conhecida um estudo que as classifique segundo essas características. Adicionalmente, não é fácil encontrarmos uma separação nítida entre as MECs e os demais componentes de um sistema de processamento de consultas. No entanto, a arquitetura da MEC extensível pode ser definida pelos seguintes elementos: • Unidade de Execução – são os operadores: algébricos, de controle e módulos de execução; • Modelo de execução – diz respeito a um conjunto de características de execução implementadas pelos módulos;

• •

Estruturas de Dados – correspondem às estruturas voláteis e persistentes necessárias para suportar a implementação dos operadores (ex: listas, sacolas, conjuntos e árvores); Unidade de Dados – correspondem aos tipos de instâncias de dados processadas pelos operadores (p.ex: tupla).

Quanto aos operadores, eles são classificados em algébricos, de controle e em módulos. Os operadores algébricos implementam uma determinada álgebra. Os operadores de controles são meta-operadores [16] que exercem a comunicação inter-operadores. Os módulos são operadores que implementam as características de execução. A combinação de dois módulos resultará na combinação de duas características de execução Sob o ponto de vista de otimização de um PEC, os módulos são operadores “reais” e fazem parte da descrição do PEC submetido para a execução. Sob o ponto de vista de execução, os módulos são operadores “virtuais” pois eles não são executados como os demais operadores do PEC (algébricos e controle). Ao invés disso, os módulos são usados pela MEC na etapa de instanciação dos operadores do PEC. Quanto ao modelo de execução, ele reúne todas as características de execução apresentadas na seção anterior. Além disso, a extensibilidade do modelo se dá na adição de novas características de execução. Quanto às estruturas de dados, elas devem suportar a implementação dos operadores de controle e dos módulos. Por exemplo, o módulo de execução adaptativa deve possuir uma fila de instâncias ordenadas segundo a prioridade de execução. Quanto às unidades de dados, a nossa abordagem permite construir uma MEC que combine diferentes unidade de dados (p.ex: tuplas, no modelo relacional, e dados XML) desde que processadas pelos seus respectivos operadores algébricos através de módulos distintos, um para cada unidade de dados. Desta forma poderíamos ter dentro de um PEC um fragmento de execução para processar dados relacionais e um fragmento para processar dados XML. O uso combinado dos dois modelos é particularmente útil em aplicações de integração de dados na web, tais como, Agora [23] e Silkroute [12]. Adicionalmente, do ponto de vista de uso, uma MEC pode ser especificada segundo uma interface que apresente os métodos necessários para a sua utilização, incluindo a submissão de um PEC. Uma mesma MEC pode apresentar diferentes interfaces. 4.2. Especificação Nesta seção, especificamos a arquitetura da MEC extensível utilizando a técnica de framework de software. Como resultado, produzimos o framework QEEF (Query Execution Engine Framework) apresentado no diagrama UML da Figura 2. A classe QEEF implementa o padrão de projeto facade [15] responsável pela interface da máquina de execução com a aplicação usuária que submete um Plano de Execução de Consulta (PEC). A descrição de um PEC contém os operadores algébricos, com as respectivas configurações, e as características de execução associadas a esses operadores. A classe Operador implementa uma interface comum a todos os operadores da MEC exportando os seguintes métodos: Open: prepara o operador para produzir dados Getnext: produz um dado sob demanda do consumidor Putnext: produz um dado e envia para o consumidor Close: finaliza o operador

QEEF

recebe

Gerente Plano

Fabrica fabrica

Gerente Fonte

Fonte

instancia referencia

Operador

cria manipula

Instancia

atualiza

Metadado

persiste

Algébrico Resultado Processo Acesso

Modulo

Controle

usa

Paralelismo

FControle

Leitor

Sincronismo

FDados

Coletor

Distribuicao

Estrutura inicializa

Gerente Estrutura

Distribuidor acessa

Figura 2. O Framework QEEF

Além disso, um operador pode se relacionar com outros operadores através do papel de produtor ou de consumidor de instâncias de dados. Essas instâncias são objetos da classe Instancia, especializada de acordo com o modelo de dados da MEC (por exemplo, a classe Tupla para dados relacionais). A classe Algebrico generaliza todos os operadores algébricos da MEC que devem ser especializados através das classes Acesso, Resultado e Processo de acordo com as suas funcionalidades que são: (i) acesso às fontes de dados, (ii) formatação dos resultados e (ii) processamento intermediário. Exemplos das classes desses operadores são respectivamente: Scan, Project e Join. As fontes de dados são especializações da classe Fonte, implementadas através do padrão de projeto adapter. A classe Controle representa todos os operadores de controle da MEC e tem a importante função de desacoplar os operadores algébricos. O framework permite instanciar vários tipos de controle. No entanto, alguns controles necessários para a construção dos módulos básicos foram instanciados, tais como Leitor, Coletor e Distribuidor, que utilizaremos na próxima seção. Os controles podem ser executadas através de linhas de execução (threads) e podem possuir estruturas de dados (classe Estrutura) para a persistência de instâncias de dados durante a execução. O GerenteEstrutura é responsável pela criação de estruturas de dados (buffer, queue, stack, bag, etc). Essas podem apresentar versões voláteis e persistentes. A classe Modulo é especializada para cada característica de execução (classes Paralelimo, Síncronismo, Fcontrole, etc). Ela implementa o padrão de projeto decorator permitindo a composição de operadores. A classe GerentePlano gerencia a construção de um PEC da seguinte forma: ao receber a descrição de um PEC (baseada em XML) os módulos são criados e combinados segundo o modelo de execução descrito na especificação do PEC. Para cada módulo: (i) os operadores algébricos são fabricados através da classe Fabrica e (ii) os operadores de controle são criados e inseridos entre os operadores algébricos do PEC, de acordo com a lógica de composição de cada módulo. A classe Fabrica se comunica com o GerenteFonte para selecionar as fontes usadas pelos operadores de acesso A execução do PEC é iniciada a partir da invocação do método open do operador raiz do PEC. A execução dos operadores é feita através de invocação dos métodos getnext

(fluxo demand-driven) ou putnext (fluxo data-driven), podendo gerar instâncias de dados para aplicação, imediatamente (first-tuple) ou tardiamente (last-tuple). As instâncias produzidas podem ser manipuladas pelos métodos de acesso getX(), para cada tipo X, e de serialização (p.ex: toString()). As instâncias de dados nascem nas fontes de dados com seus respectivos metadados (classe Metadado) que podem sofrer atualizações durante o processamento. A ordem destas atualizações pode não ser a mesma para todas as instâncias, pois, no caso da execução adaptativa, as instâncias percorrem caminhos diferentes através dos operadores do PEC. 5. Estudo de Caso Apresentamos nesta seção um estudo de caso motivado pelo cenário 1 descrito na introdução deste trabalho. Consideramos uma fonte de dados local (representado por L1) contendo a lista inicial de produtos e três sites de supermercados com informações publicadas na web (representados aqui pelas fontes S1, S2 e S3). O esquema relacional exportado é composto das relações: L1(cod, nome), S1(cod, preco), S2(cod, preco) e S3(cod, preco). Uma aplicação de integração que objetiva recuperar os preços de produtos dos três sites seria expressa pela consulta SQL abaixo: Select L1.nome, S1.preco, S2.preco, S3.preco From L1, S1, S2, S3 Where L1.cod = S1.cod and L1.cod = S2.cod and L1.cod = S3.cod O predicado p=(L1.cod=Si.cod) exemplifica a necessidade do fornecimento de um critério de busca para acesso aos dados publicados pelo site Si. Neste caso, cada site requer a associação de um código de produto para que se tenha acesso ao preço deste produto. Sendo assim, a fonte L1 deve ser a primeira a ser acessada para obtenção da lista inicial de produtos. Define-se então, uma ordem parcial entre os operadores que irão compor o PEC. Tem-se, para árvores profundas à esquerda, as seguintes possíveis ordens de avaliação dos predicados: O1= L1
S1
S2
S3, O2= L1→ S1→ S3→ S2, O3= L1→ S2→ S1→ S3, O4= L1→ S2→ S3→ S1 , O5= L1→ S3→ S1→ S2 e O6= L1→ S3→ S2→ S1. Outros planos possíveis incluiriam versões para planos bushy. A determinação do melhor plano a ser executado neste cenário é uma tarefa difícil considerando-se as grandes variações no tempo de resposta aos sites envolvidos, característico do cenário 1. Estratégias puramente estáticas não são capazes de modelar tais variações. Já estratégias adaptativas podem combinar os diversos planos possíveis durante a execução de uma consulta recorrendo aos operadores que estejam mais disponíveis a cada instante. Para este exemplo, uma MEC executará o PEC equivalente à O1 ∪ O2 ∪ O3 ∪ O4 ∪ O5 ∪ O6. De acordo com esse cenário, produzimos a MEC AQEE (Adaptive Query Execution Engine) que incorpora as seguintes características de execução: sincronismo = (no wait); paralelismo = (inter-operator); distribuição = (no); fluxo de dados = (adaptive); fluxo de controle = (demand-driven) e tempo de resposta = (first tuple). A máquina AQEE instancia QEEF da seguinte forma: as classes Acesso, Processo e Resultado são especializadas nas classes Scan, BindJoin e Project, respectivamente, correspondendo aos seus operadores algébricos homônimos. A classe Instancia foi especializada para a classe Tupla e a classe Estrutura foi especializada na classe Fila. As demais classes são reutilizadas a partir do framework. A Figura 3 apresenta todos os operadores do PEC para o exemplo. O módulo 1 implementa o fluxo de dados fixed, e contém o operador Scan, que acessa a fonte local L1,

o operador Project, que produz as tuplas resultantes da consulta e o módulo 2, que implementa o fluxo de dados adaptive. O modulo 2 contém os operadores (1) BindJoin 1, 2 e 3, os quais submetem, em paralelo, bindings[13] às fontes S1 , S2 e S3, respectivamente, simulando o acesso aos três sites; (2) os operadores Coletor, os quais coletam dados de seus produtores e os envia a seus consumidor agindo como active-scheduler; (3) os operadores Leitor, os quais solicitam dados ao (4) operador Distribuidor que envia as tuplas ainda não processadas. As tuplas, processadas pelos Bindjoin, retornam ao Distribuidor e são armazenadas na Fila com uma prioridade para garantir que estejam disponíveis ao usuário assim que sejam processadas por todos os operadores do PEC. As classes do QEEF e da AQEE foram implementadas na plataforma Java. A Figura 4 mostra a interface da aplicação para o exemplo do estudo de caso, implementada utilizando-se de Servlets. Modulo 1 L1

Modulo2

Scan 1

Project 1

get

put

put

Coletor1

Coletor2

put

Coletor3

get S2

S1

Bind Join1 get

S3

Bind Join2

Bind Join3

get

Leitor1 get

get

Leitor2 get

Leitor3 get

Distribuidor1 Fila1

Figura 3. Diagrama de Objetos

6. Conclusões Neste trabalho, apresentamos uma máquina de execução de consultas (MEC) extensível para suportar novos modelos de execução de consultas. Definimos um modelo de execução de consultas como sendo um conjunto de características de execução obtidas a partir de um cenário. A especificação desta MEC foi feita através da técnica de framework de software, bastante utilizada na construção de sistemas com maior flexibilidade e que possam ser adaptados com maior rapidez e facilidade para atender aos requisitos de novas aplicações, sendo, portanto, adequada ao nosso contexto. Desenvolvemos um estudo de caso simulando uma consulta de integração de dados a sites web, onde a adaptabilidade está associada a imprevisibilidade do tempo de acesso a estes sites. Aplicações como essas apresentam desafios na medida em que o tempo de acesso às fontes de dados registram grandes variações e as informações estatísticas são escassas.

Figura 4. Interface da Aplicação

As principais contribuições deste trabalho são: • uma análise dos diferentes cenários de consultas; • uma análise das características de execução e o seus relacionamentos com os cenários; • uma análise das arquitetura de MECs; • a especificação da MEC extensível através do framework QEEF e • a instanciação da máquina AQEE. Além disso, não encontramos na literatura uma MEC extensível com suporte a novos modelos de execução. Como trabalhos futuros, instanciaremos o QEEF para novos estudos de casos tais como, a combinação de diferentes características de execução com diferentes modelos de dados.

Referências 1. S. Abiteboul, P. Buneman, and D. Susciu. Data on the Web. Morgan Kaufman, 1999. 2. L. Amsaleg, M. J. Franklin, A. Tomasic and T. Urhan, Scrambing Query Plans to Cope with Unexpected Delays, In Proc. PDIS Conf., Miami, USA, 1996. 3. R. Avnur, J. Hellerstein, Eddies: Continuously Adaptive Query Processing, In Proc. ACM Intl. Conf. on Management of Data (SIGMOD), Dallas, Texas, 2000. 4. F. Ayres, et al, Um Framework para construção de Máquinas de Execução de Consultas Relacionais, In Proc. Congresso Argentino de Ciencias de la Computacion CACIC´02, Buenos Aires, Argentina, 2002. 5. J. Bercken, et al. XXL- A Library Aproach to Supporting Efficient Implementations of Advanced Database Queries. In Proc. Intl. Conf. on Very Large Databases (VLDB), Roma, Italy, 2001.

6. L. Bouganim, F. Fabret, C. Mohan, P. Valduriez, Dynamic Query Scheduling in Data Integration Systems. In Proc. 16o ACM. Intl. Conf. on Data Engineering (ICDE), San Diego, CA, March, 2000. 7. L. Bouganim, F. Fabret, F. Porto e P. Valduriez, Processing Queries with Expensive Functions and Large Objects in Distributed Mediator Systems, In Proc. 17o ACM. Intl. Conf. on Data Engineering (ICDE), Heidelberg, Alemanha, Abril 2001. 8. S. Babu, and J. Widom, Continuous Queries Over Data Streams. ACM SIGMOD Record, Setembro, 2001. 9. S. Chandrasekaran, et al. TelegraphCQ: Continuous Dataflow Processing for an Uncertain World. In Proc. Intl. Conf. on Innovative Database Research (CIDR), 2003. 10. J. Chen, et al. NiagaraCQ: A Scalable Continuous Query System for Internet Databases. In Proc. ACM Intl. Conf. on Management of Data (SIGMOD), 2000. 11. A. Dobra et al. Processing Complex Aggregate Queries over Data Streams. In Proc. ACM Intl. Conf. on Management of Data (SIGMOD), p61-73, Madison, Wisconsin, USA,2002. 12. M. Fernandez, Y. Kadiyska, D. Suciu, A. Morishima and W-C. Tan. SilkRoute: A Framework for Publishing Relational Data in XML. In Transactions on Database Systems (TODS), v27, n4, p438-493, 2002. 13. D. Florescu, I. Monolescu, A. Levy and D. Suciu, Query optimization in the Presence of Limited Access Patterns, In Proc. ACM Intl. Conf. on Management of Data (SIGMOD), Filadelfia, USA, Junho, 1999. 14. M. Fayad, D. Schmidt, and R. Johnson, Building Application Frameworks – ObjectOriented Foundations of Frameworks. John Wiley & Sons, Inc. 1999. 15. E. Gamma, R. Helm, R. Johnson and J. Vlissides, Design Patterns, Addison-Wesley pub., 1995. 16. G. Graefe, and W. McKenna. The Volcano Optmizer Generator: Extensibility and Eficient Search. In Proc. ACM Intl. Conf. on Database Engineering (ICDE)., Vienna, 1993. 17. G. Graef, Query Evaluation Techniques for Large Databases, In ACM Computing Surveys, 25(2), Junho, 1993. 18. Z. G. Ives, D. Florescu, M. Friedman, A. Levy and D. Weld, An Adaptive Query Execution System for Data Integration, In Proc. ACM Intl. Conf. on Management of Data, Filadelfia (SIGMOD), USA, Junho, 1999. 19. V. Josifovski, M. Fontoura, and A. Barta. Querying XML Streams, In Proc. ACM. Intl. Conf. on Data Engineering (ICDE), 2002. 20. D. Kossmann, The State of the Art in Distributed Query Processing. In ACM Computing Survey, v32, n4, Dec, 2000. 21. S. Madden et al. Continously Adaptive Continuous Query over Streams. In Proc. ACM Intl. Conf. on Management of Data (SIGMOD), p171-183, Madison, Wisconsin, USA, 2002. 22. J. McCann. The Database Machine: Old Story, New Slant. In Proc. Intl. Conf. on Innovative Database Research (CIDR), 2003. 23. I. Manolescu, D. Florescu., D. Kossmann, F. Xhumari and D. Olteanu. Agora: Living with XML and Relational. In Proc. Intl. Conf. on Very Large Databases (VLDB), Cairo, Egypt, 2000.