UMA AVALIAC ¸ ˜ AO DE ALGORITMOS N ˜ AO EXAUSTIVOS PARA A OTIMIZAC ¸ ˜ AO DE JUNC ¸ ˜ OES

UMA AVALIAC ¸ ˜ AO DE ALGORITMOS N ˜ AO EXAUSTIVOS PARA A OTIMIZAC ¸ ˜ AO DE JUNC ¸ ˜ OES

Disserta¸c˜ ao apresentada como requisito par- cial ` a obten¸c˜ ao do grau de Mestre. Pro- grama de P´ os-Gradua¸c˜ ao em Inform´ atica, Setor de Ciˆ encias Exatas, Universidade Fe- deral do Paran´ a.

Orientador: Prof. Dr. Marcos Sfair Sunye.

CURITIBA

2010

UMA AVALIAC ¸ ˜ AO DE ALGORITMOS N ˜ AO EXAUSTIVOS PARA A OTIMIZAC ¸ ˜ AO DE JUNC ¸ ˜ OES

Disserta¸c˜ ao aprovada como requisito parcial ` a obten¸c˜ ao do grau de Mestre no Programa de P´ os-Gradua¸c˜ ao em Inform´ atica da Universidade

Federal do Paran´ a, pela Comiss˜ ao formada pelos professores:

Orientador: Prof. Dr. Marcos Sfair Sunye.

Departamento de Inform´ atica, UFPR Prof. Dr. F´ abio Andr´ e Machado Porto

Laborat´ orio Nacional de Computa¸c˜ ao Cient´ıfica, LNCC, membro externo.

Prof. Dr. Fabiano Silva

Departamento de Inform´ atica, UFPR, membro interno.

Curitiba, 26 de Agosto de 2010

AGRADECIMENTOS

Agrade¸co primeiramente a Deus, pela vida, sa´ ude e oportunidade de realizar este estudo.

Ao meu orientador, principalmente pelo apoio, compreens˜ ao e paciˆ encia.

Agrade¸co tamb´ em ao corpo docente do Departamento de Inform´ atica da UFPR, do qual tive a oportunidade de aprender muito.

Aos meus pais, por estarem sempre prontos a me ajudar.

Aos in´ umeros amigos que tive a oportunidade de conhecer durante a minha estada em Curitiba, dos quais agrade¸co pela companhia e pelas valiosas contribui¸c˜ oes.

A Universidade Estadual de Mato Grosso do Sul e a todos os colegas Divis˜ ao de

Inform´ atica, pelo valioso apoio e amizade.

SUM ´ ARIO

LISTA DE FIGURAS vi

LISTA DE TABELAS vii

RESUMO viii

ABSTRACT ix

1 INTRODUC ¸ ˜ AO 1

1.1 A Ordena¸c˜ ao de Jun¸c˜ oes . . . . 2

1.2 O SGBD PostgreSQL . . . . 3

1.3 Motiva¸c˜ ao e Objetivo . . . . 4

1.4 Organiza¸c˜ ao da Disserta¸c˜ ao . . . . 6

2 O PROCESSAMENTO DE CONSULTAS EM SISTEMAS DE BAN- COS DE DADOS RELACIONAIS 8 2.1 Fundamentos . . . . 8

2.1.1 Algebra Relacional . . . . ´ 9

2.1.1.1 Arvore de Consulta . . . . ´ 11

2.1.1.2 Operador de Jun¸c˜ ao . . . . 12

2.1.2 A Linguagem de Consultas SQL . . . . 14

2.2 Arquitetura de Processamento de Consultas . . . . 15

2.2.1 O Planejamento . . . . 17

2.2.1.1 Restri¸c˜ oes do Espa¸co de Busca . . . . 18

3 ALGORITMOS DE OTIMIZAC ¸ ˜ AO DE JUNC ¸ ˜ OES 22 3.1 Algoritmos Exaustivos . . . . 23

3.2 Algoritmos N˜ ao Exaustivos . . . . 25

3.2.1 Algoritmos Determin´ısticos . . . . 26

3.2.2 Algoritmos Aleat´ orios . . . . 26

3.2.2.1 Melhoria Iterativa (II) . . . . 28

3.2.2.2 Tˆ empera Simulada (SA) . . . . 28

3.2.2.3 Aplica¸c˜ ao dos Algoritmos Aleat´ orios na Otimiza¸c˜ ao de Jun¸c˜ oes . . . . 29

3.2.2.4 Two Phase Optimization (2PO) . . . . 32

3.2.3 Algoritmos Gen´ eticos . . . . 34

3.2.3.1 Arvores em Profundidade ` ´ a Esquerda . . . . 35

3.2.3.2 Arvores Fechadas de Jun¸c˜ ´ oes . . . . 36

4 OTIMIZAC ¸ ˜ AO DE JUNC ¸ ˜ OES NO POSTGRESQL 38 4.1 Arquitetura . . . . 38

4.1.1 A Estrutura RelOptInfo . . . . 40

4.1.2 Contrato e Opera¸c˜ oes B´ asicas de um Otimizador . . . . 41

4.2 O Algoritmo GEQO . . . . 43

4.2.1 Espa¸co de Busca . . . . 43

4.2.2 Sele¸c˜ ao, Crossover e Evolu¸c˜ ao . . . . 45

4.3 A Implementa¸c˜ ao do Algoritmo 2PO . . . . 48

4.3.1 Espa¸co de Busca . . . . 48

4.3.2 Movimentos . . . . 50

4.3.3 Encapsulamento do 2PO na Forma de Plugin . . . . 51

5 METODOLOGIAS DE AVALIAC ¸ ˜ AO ENCONTRADAS NA LITERA- TURA 53 5.1 A Ausˆ encia de Padr˜ oes Definidos de Avalia¸c˜ ao . . . . 53

5.2 A Compara¸c˜ ao de Algoritmos Aleat´ orios e o Uso da Escala de Custo . . . . 54

5.3 A Compara¸c˜ ao Entre 2PO, SA e II . . . . 56

5.4 A Compara¸c˜ ao de Algoritmos Determin´ısticos e N˜ ao Destermin´ısticos . . . 57

5.5 Propostas Determin´ısticas de Avalia¸c˜ ao . . . . 59

5.6 O Uso de Benchmarks Tradicionais . . . . 62

5.7 Principais Elementos Encontrados nas Metodologias Apresentadas . . . . . 63

6 METODOLOGIA UTILIZADA 65 6.1 Defini¸c˜ ao dos Parˆ ametros de Constru¸c˜ ao . . . . 65

6.2 Constru¸c˜ ao do Esquema de Dados . . . . 68

6.3 Constru¸c˜ ao das Consultas . . . . 68

6.3.1 Sele¸c˜ ao dos Conjuntos de Rela¸c˜ oes . . . . 69

6.3.2 Combina¸c˜ ao das Rela¸c˜ oes na Consulta SQL . . . . 69

6.4 Transitividade de Predicados . . . . 71

7 RESULTADOS EXPERIMENTAIS 74 7.1 Performance dos Otimizadores . . . . 76

7.2 Qualidade dos Planos Gerados . . . . 80

7.3 Varia¸c˜ ao das Cardinalidades das Rela¸c˜ oes . . . . 86

7.4 An´ alise dos Resultados Apresentados . . . . 88

8 CONCLUS ˜ AO 91

REFER ˆ ENCIAS BIBLIOGR ´ AFICAS 98

LISTA DE FIGURAS

2.1 Exemplo de uma ´ arvore de consulta. . . . . 11

2.2 Exemplo de uma ´ arvore de consulta usando um operador de jun¸c˜ ao. . . . . 12

2.3 Exemplo de um grafo de jun¸c˜ oes. Os nodos representam as rela¸c˜ oes e as arestas os predicados sobre essas rela¸c˜ oes. . . . 14

2.4 Tipos de grafos de jun¸c˜ oes. . . . 14

2.5 Mapeamento de equivalˆ encia entre uma consulta SQL em seus respectivos planos f´ısicos. . . . 16

2.6 Exemplos de ´ arvores de jun¸c˜ oes. . . . 19

2.7 Tipos de ´ arvores de jun¸c˜ oes. . . . 21

3.1 Otimiza¸c˜ ao local do II versus SA [43]. . . . 30

3.2 Exemplo de constru¸c˜ ao de uma ´ arvore em profundidade ` a esquerda equi- valente a lista de rela¸c˜ oes (A, C, D, B). . . . 31

3.3 Forma do espa¸co de busca de ´ arvores fechadas de jun¸c˜ oes apresentada por Ioannidis e Kang [29]. . . . 33

3.4 Exemplo (a) grafo e (b) ´ arvore de jun¸c˜ oes utilizado por Bennett et al. [13] para representar cromossomos em um ambiente de ´ arvores fechadas. . . . . 37

4.1 Arquitetura de processamento de consultas do PostgreSQL [1]. . . . 39

4.2 Exemplo de uma estrutura RelOptInfo utilizada pelo PostgreSQL para agregar v´ arios planos de execu¸c˜ ao de um mesmo conjunto de rela¸c˜ oes. . . . 40

4.3 Exemplo de uma ´ arvore alternativa utilizada pelo GEQO para representar cromossomos que contenham falhas em sua sequˆ encia normal de combina¸c˜ oes. 45 4.4 Forma de representa¸c˜ ao de estados utilizada pelo 2PO implementado neste estudo. . . . 49

4.5 Regras de transforma¸c˜ ao utilizadas na implementa¸c˜ ao do algoritmo 2PO. . 51

4.6 Diagrama de componentes representando a interface de conex˜ ao do plugin LJQO com o PostgreSQL. . . . 52 6.1 Aumento da conectividade nas consultas do tipo grade e estrela devido a

transitividade de seus predicados de jun¸c˜ ao. . . . 73 7.1 M´ edia da quantidade de planos gerados pelos otimizadores 2PO, GEQO e

GEQO+ em fun¸c˜ ao do n´ umero de rela¸c˜ oes e do grafo de jun¸c˜ oes. . . . 77 7.2 Tempo m´ edio de otimiza¸c˜ ao apresentado pelos otimizadores 2PO, GEQO

e GEQO+ em fun¸c˜ ao do n´ umero de rela¸c˜ oes e do grafo de jun¸c˜ oes. . . . 78 7.3 M´ edia de planos gerados por segundo obtida pelos otimizadores 2PO,

GEQO e GEQO+ em fun¸c˜ ao do n´ umero de rela¸c˜ oes e do grafo de jun¸c˜ oes. 79 7.4 M´ edia e varia¸c˜ ao das escalas de custo obtidas pelos otimizadores 2PO,

GEQO e GEQO+ em fun¸c˜ ao da quantidade de rela¸c˜ oes e do grafo de jun¸c˜ oes. Os gr´ aficos nesta figura agrupam os dados de acordo com os grafos de jun¸c˜ oes. Cada retˆ angulo representa a m´ edia das escalas de custo, enquanto que o intervalo apresentado em seu topo ou interior representa o 5

e o 95

percentis. . . . 82 7.5 M´ edia e varia¸c˜ ao das escalas de custo obtidas pelos otimizadores 2PO,

GEQO e GEQO+ em fun¸c˜ ao da quantidade de rela¸c˜ oes e do grafo de jun¸c˜ oes. Os gr´ aficos nesta figura agrupam os dados de acordo com a quan- tidade de rela¸c˜ oes. Cada retˆ angulo representa a m´ edia das escalas de custo, enquanto que o intervalo apresentado em seu topo ou interior representa o 5

e o 95

percentis. . . . 83 7.6 M´ edia e varia¸c˜ ao das escalas de custo obtidas pelos otimizadores 2PO,

GEQO e GEQO+ em fun¸c˜ ao da quantidade de rela¸c˜ oes, grafo de jun¸c˜ oes

e LOGRATIO. Cada retˆ angulo representa a m´ edia das escalas de custo,

enquanto que o intervalo apresentado em seu topo ou interior representa o

5

e o 95

percentis. . . . 87

LISTA DE TABELAS

2.1 Rela¸c˜ ao Departamento (D) . . . . 11 2.2 Rela¸c˜ ao Funcion´ ario (F) . . . . 11 2.3 N´ umero de tipos de ´ arvores de jun¸c˜ oes e quantidade de poss´ıveis solu¸c˜ oes

para consultas entre 1 e 12 rela¸c˜ oes. [39, 47]. . . . 20 4.1 Parˆ ametros de configura¸c˜ ao utilizados pelo 2PO em cada uma de suas fases,

conforme proposto por Ioannidis e Kang [29]. . . . 49 5.1 Cat´ alogos de rela¸c˜ oes utilizados por Ioannidis e Kang [29]. . . . 56 5.2 Distribui¸c˜ ao das cardinalidades das rela¸c˜ oes utilizadas por Steinbrunn et

al. [43]. . . . 58 5.3 Distribui¸c˜ ao dos dom´ınios dos atributos utilizados por Steinbrunn et al. [43]. 58 6.1 Comparativo entre os parˆ ametros utilizados por Vance e Maier e por Sha-

piro et al. em rela¸c˜ ao a metodologia adotada. . . . . 66 6.2 Compara¸c˜ ao da quantidade de arestas do grafo de jun¸c˜ oes de uma consulta

SQL, antes e depois da reescrita. . . . . 72 7.1 M´ edia de planos gerados por segundo obtida pelos otimizadores 2PO,

GEQO e GEQO+ em fun¸c˜ ao do n´ umero de rela¸c˜ oes e do grafo de jun¸c˜ oes. 80 7.2 M´ edia das escalas de custo obtidas pelos otimizadores 2PO, GEQO e

GEQO+ em fun¸c˜ ao da quantidade de rela¸c˜ oes e do grafo de jun¸c˜ oes. . . . . 84

RESUMO

Os sistemas gerenciadores de bancos de dados (SGBDs) relacionais proporcionam atu-

almente uma ambiente bastante produtivo para a manipula¸c˜ ao de informa¸c˜ oes. A partir

de uma linguagem de alto n´ıvel, tais sistemas permitem que seus usu´ arios descrevam con-

sultas de uma maneira simples e r´ apida, sem definir com isso detalhes relacionados ao seu

processamento. Tais detalhes s˜ ao de responsabilidade do pr´ oprio SGBD, o qual deve es-

colher, atrav´ es de um sofisticado processo de otimiza¸c˜ ao e planejamento, uma alternativa

eficiente para a obten¸c˜ ao dessas informa¸c˜ oes. A otimiza¸c˜ ao de jun¸c˜ oes ´ e uma das mais

importantes e complexas dentre todas as fases que comp˜ oem este processo. A defini¸c˜ ao da

melhor ordem de jun¸c˜ oes somente pode ser realizada em condi¸c˜ oes relativamente simples,

atrav´ es do uso de algoritmos de busca exaustiva fortemente baseados na programa¸c˜ ao

dinˆ amica. Para os demais casos, espera-se que apenas uma aproxima¸c˜ ao desta melhor

ordem seja encontrada, utilizando para isso t´ ecnicas n˜ ao exaustivas de busca. Este estudo

concentra-se na avalia¸c˜ ao de dois algoritmos n˜ ao exaustivos de otimiza¸c˜ ao de jun¸c˜ oes im-

plementados para o SGBD de c´ odigo aberto PostgreSQL: o Genetic Query Optimization

(GEQO) e o Two Phase Optimization (2PO). Atrav´ es de um esquema de testes multidi-

mensional, este estudo apresenta diversos dados relevantes sobre o comportamento desses

algoritmos. Estes resultados servem tanto para o processo de melhoria dos algoritmos

avaliados como para a elabora¸c˜ ao de novas abordagens de otimiza¸c˜ ao de jun¸c˜ oes.

ABSTRACT

Relational Database Management Systems (RDBMS) currently provide a very pro-

ductive environment for data manipulation. Using a high level language, these systems

allow their users describe queries in a simple and fast manner without defining how these

data will be retrieved. These details need to be supplied by RDBMS itself, through a

sophisticated process of optimizing and planning. The join ordering optimization is one

of the most important and complex phases that involve this process. The definition of the

optimal join order can only be realized in simple conditions, by using exhaustive search

techniques. For the other cases, it is expected that an approximation of the optimal join

order should be found by a non-exhaustive search algorithm. This study concentrates

on the evaluation of two non-exhaustive algorithms applied to an open source DBMS

named PostgreSQL: Genetic Query Optimization (GEQO) and Two Phase Optimization

(2PO). Through a multidimensional test schema, this study demonstrates several relevant

information about the behavior of these algorithms. These results can be used both for

improvement of such algorithms and for elaboration of new join ordering techniques.

CAP´ ITULO 1 INTRODUC ¸ ˜ AO

Os sistemas gerenciadores de bancos de dados (SGBDs) s˜ ao ferramentas de fundamen- tal importˆ ancia para o meio social em que vivemos. ´ E atualmente dif´ıcil de se imaginar que qualquer pessoa ou empresa n˜ ao utilize, direta ou indiretamente, informa¸c˜ oes forne- cidas por algum SGBD, seja pelo simples uso de servi¸cos banc´ arios, pela submiss˜ ao de uma pesquisa em um site de busca na Internet ou at´ e mesmo pela gera¸c˜ ao de complexas informa¸c˜ oes gerenciais fornecidas por sistemas de apoio a decis˜ ao de grandes corpora¸c˜ oes.

O objetivo principal de um SGBD ´ e abstrair a complexidade do armazenamento, con- trole de acesso e recupera¸c˜ ao de informa¸c˜ oes, visando com isso aumentar a produtividade no desenvolvimento de aplica¸c˜ oes ou mesmo facilitar o acesso aos dados por usu´ arios finais inexperientes. Segundo Jarke e Koch [32], existem duas principais ´ areas de interesse na pesquisa e desenvolvimento de SGBDs. A primeira delas, compete ` a an´ alise dos modelos conceituais de dados nos quais pode-se representar elementos do mundo real. Tais concei- tos incluem, por exemplo, os modelos hier´ arquico, em rede e relacional. A segunda ´ area de interesse consiste em implementar tais modelos de forma que sejam computacionalmente eficientes.

Dentre os modelos de bancos de dados existentes, o modelo relacional, definido por

Codd em 1970 [17], possui uma s´ olida fundamenta¸c˜ ao te´ orica [32]. A caracter´ıstica b´ asica

deste modelo ´ e proporcionar uma clara distin¸c˜ ao entre os aspectos l´ ogicos e f´ısicos de um

banco de dados, considerando para isso tanto sua representa¸c˜ ao como os m´ etodos compu-

tacionais utilizados para a manipula¸c˜ ao e recupera¸c˜ ao de seus dados [19]. A partir deste

modelo, diversas pesquisas foram desenvolvidas nos anos subsequentes ` a sua defini¸c˜ ao, de

modo que prot´ otipos de SGBDs relacionais come¸caram a surgir a partir da segunda me-

tade da d´ ecada de 70, como por exemplo o System R [11], desenvolvido nos laborat´ orios

da IBM, e o INGRES [26], desenvolvido pela University of California, em Berkeley.

A partir da abstra¸c˜ ao proporcionada pelo modelo relacional, algumas linguagens de alto n´ıvel foram propostas durante o desenvolvimento desses SGBDs como forma de repre- sentar consultas submetidas a eles. A linguagem SQL (Structured Query Language) [12], por exemplo, foi proposta inicialmente para o System R, enquanto que o INGRES foi equipado com uma linguagem chamada QUEL [26]. Tanto a linguagem SQL como a lin- guagem QUEL eram n˜ ao procedurais, as quais permitiam aos seus usu´ arios descreverem os dados desejados em uma consulta sem a necessidade de especificar como eles deveriam ser obtidos.

A forma descritiva de suas linguagens de consulta proporciona aos SGBDs relacionais um ambiente de utiliza¸c˜ ao muito mais produtivo que os antigos m´ etodos de consulta ado- tados nos modelos hier´ arquico e em rede. Por outro lado, seu alto n´ıvel de abstra¸c˜ ao exigiu dos SGBDs relacionais um mecanismo de processamento de consultas muito mais sofisti- cado. Internamente, esses SGBDs implementam um conjunto de m´ etodos de manipula¸c˜ ao de dados que derivam da ´ algebra relacional [18]. Tais m´ etodos podem ser combinados em um plano de execu¸ c˜ ao para produzirem o resultado esperado pelo usu´ ario. O principal problema, neste caso, ´ e que uma consulta descrita por este tipo de linguagem de alto n´ıvel pode ser representada por diversos planos de execu¸c˜ ao diferentes. Embora cada um desses planos seja equivalente do ponto de vista de seu resultado final, a quantidade de recursos computacionais e de tempo exigido para o processamento de cada um deles pode variar consideravelmente. A partir deste fato, a tarefa mais cr´ıtica de um SGBD relacional ao receber uma consulta, consiste em determinar um plano de execu¸c˜ ao eficiente, atrav´ es de etapas que envolvem sua otimiza¸c˜ ao e planejamento.

1.1 A Ordena¸ c˜ ao de Jun¸ c˜ oes

Desde o projeto dos primeiros SGBDs relacionais, o problema da otimiza¸c˜ ao de con- sultas foi e continua sendo um dos mais complexos dentre todas as ´ areas que envolvem sua pesquisa e desenvolvimento. Neste contexto, diversos estudos foram realizados ao longo dos ´ ultimos 30 anos com o objetivo de tornar este processo cada vez mais eficiente.

O processo de otimiza¸c˜ ao de consultas concentra-se geralmente em uma tarefa chamada

ordena¸ c˜ ao de jun¸ c˜ oes ou otimiza¸ c˜ ao de jun¸ c˜ oes. Como ser´ a descrito no cap´ıtulo seguinte, jun¸ c˜ ao ´ e uma opera¸c˜ ao da ´ algebra relacional que permite combinar duas rela¸ c˜ oes, ou tabelas, de um banco de dados relacional, usando para isso uma condi¸c˜ ao l´ ogica sobre seus atributos. A ordena¸c˜ ao de jun¸c˜ oes ´ e uma tarefa importante porque apresenta um impacto significativo sobre a eficiˆ encia de SGBDs relacionais. Segundo Ibaraki e Kameda [27], encontrar a melhor ordem de jun¸c˜ oes de uma consulta ´ e um problema NP-Completo, visto que a quantidade de poss´ıveis solu¸c˜ oes para este problema ´ e no m´ınimo exponencialmente proporcional ` a quantidade de rela¸c˜ oes existentes na mesma.

Existem diversos algoritmos propostos na literatura que buscam lidar com o problema da ordena¸c˜ ao de jun¸c˜ oes. Estes algoritmos podem ser divididos em duas categorias prin- cipais: exaustivos e n˜ ao exaustivos. Os algoritmos exaustivos sempre retornam a melhor ordem de jun¸c˜ oes poss´ıvel para o problema. Esses algoritmos tamb´ em s˜ ao chamados de algoritmos de programa¸ c˜ ao dinˆ amica, devido a utiliza¸c˜ ao desta t´ ecnica, introduzida inici- almente para o System R em 1979 por Selinger et al. [41]. Os algoritmos de programa¸c˜ ao dinˆ amica est˜ ao presentes em praticamente todos os SGBDs relacionais existentes atual- mente. Sua aplica¸c˜ ao se restringe, contudo, a condi¸c˜ oes relativamente simples, quando o n´ umero de rela¸c˜ oes de uma consulta n˜ ao ultrapassa 10 ou 15. Acima deste limite, a quantidade de tempo e de mem´ oria exigidos por estes algoritmos ´ e grande o suficiente para tornar sua utiliza¸c˜ ao impratic´ avel. Os algoritmos n˜ ao exaustivos, por sua vez, s˜ ao aqueles aplic´ aveis em condi¸c˜ oes onde os algoritmos de busca exaustiva n˜ ao s˜ ao capazes de atuar. Tais algoritmos apresentam uma abordagem de aproxima¸c˜ ao sobre o que poderia ser uma poss´ıvel melhor ordem de jun¸c˜ oes. Embora apresentem uma degrada¸c˜ ao em sua qualidade de otimiza¸c˜ ao, a quantidade de tempo e consumo de mem´ oria desses algoritmos

´ e significativamente menor que o exigido pela busca exaustiva.

1.2 O SGBD PostgreSQL

O PostgreSQL ´ e um SGBD objeto-relacional de c´ odigo aberto, o qual ´ e resultado de

um longo processo evolutivo que teve in´ıcio na University of California, em Berkeley. O

desenvolvimento deste SGBD deriva diretamente de um projeto chamado POSTGRES,

que quer dizer p´ os-INGRES, iniciado em 1986 pelo professor Michael Stonebraker [45]

ap´ os v´ arias retrospectivas feitas com rela¸c˜ ao ao seu predecessor, o INGRES [44].

Atualmente em sua vers˜ ao 8.4, o PostgreSQL ´ e amplamente conhecido como um dos mais avan¸cados SGBDs de c´ odigo aberto existentes, sendo este mantido deste 1996 por uma comunidade global de desenvolvedores [5]. Ao contr´ ario do INGRES e de suas pri- meiras vers˜ oes, ainda com o nome POSTGRES, a vers˜ ao atual deste SGBD utiliza a SQL como linguagem de consulta em lugar da antiga linguagem QUEL. Al´ em disso, o PostgreSQL apresenta uma s´ erie caracter´ısticas que s˜ ao bastante desej´ aveis em ambientes empresariais, como o controle de concorrˆ encia baseado por m´ ultiplas vers˜ oes (MVCC, Multi-Version Concurrency Control), a utiliza¸c˜ ao de v´ arios esquemas por banco de da- dos, incluindo sua distribui¸c˜ ao em diversos dispositivos de armazenamento (tablespaces), replica¸c˜ ao ass´ıncrona, transa¸c˜ oes aninhadas (savepoints) e backup online.

1.3 Motiva¸ c˜ ao e Objetivo

Devido aos diversos recursos oferecidos pelo PostgreSQL, bem como pela maturidade alcan¸cada ao longo de v´ arios anos de desenvolvimento, este SGBD tem sido alvo de uma aten¸c˜ ao crescente no sentido de ser uma alternativa de baixo custo vi´ avel para diversas

´

areas onde somente SGBDs comerciais eram capazes de atuar [22]. Por consequˆ encia, esta aten¸c˜ ao tem demandado novas melhorias, as quais seus desenvolvedores tˆ em se esfor¸cado em atendˆ e-las de modo a tornar este SGBD cada vez mais completo e eficiente.

Uma das demandas encontrados no PostgreSQL est´ a relacionada com sua capacidade

em lidar com situa¸c˜ oes que requerem consultas complexas, principalmente aquelas que

agregam um grande n´ umero de rela¸c˜ oes. Tais tipos de consultas s˜ ao frequentemente

encontradas em sistemas de apoio ` a decis˜ ao (DSS, Decision Support System), os quais

s˜ ao geralmente compostos por ferramentas de gera¸c˜ ao de complexos relat´ orios gerenciais

(OLAP, Online Analytical Processing) e por ferramentas dedutivas de minera¸c˜ ao automa-

tizada de dados (Data Mining ). Tais ferramentas s˜ ao respons´ aveis por extrair informa¸c˜ oes

armazenadas em grandes bases de dados, chamadas Data Warehouses, sendo estas muitas

vezes capazes de gerar consultas com dezenas ou at´ e centenas de rela¸c˜ oes. Al´ em disso, duas

outras fontes potenciais para este tipo de consulta s˜ ao os utilit´ arios gr´ aficos de gera¸c˜ ao autom´ atica de consultas e os recentes frameworks de persistˆ encia de dados. Nesses casos, tanto usu´ arios como programadores podem vincular dados contidos em diversas rela¸c˜ oes, sem com isso terem ciˆ encia da complexidade exigida para seu processamento.

No PostgreSQL, o suporte a consultas com grande n´ umero de rela¸c˜ oes foi introduzido em 1997, por Martin Utesch, com o desenvolvimento de um algoritmo n˜ ao exaustivo de otimiza¸c˜ ao de jun¸c˜ oes chamado Genetic Query Optimization (GEQO) [52]. Este algoritmo foi desenvolvido dentro da University of Mining and Technology, em Freiberg, Alemanha, a qual estava enfrentando alguns problemas ao tentar utilizar o PostgreSQL como base de um sistema de apoio ` a decis˜ ao direcionado a um ambiente de transmiss˜ ao e distribui¸c˜ ao de energia el´ etrica. Como era de se esperar, algumas consultas produzidas neste sistema eram complexas demais para serem otimizadas pelo ent˜ ao algoritmo de programa¸c˜ ao dinˆ amica deste SGBD.

Como seu pr´ oprio nome sugere, o GEQO ´ e um algoritmo gen´ etico, o qual teve boa parte de seu c´ odigo fonte derivado de um projeto chamado GENITOR [54]. Em sua abordagem de otimiza¸c˜ ao, este algoritmo ´ e fortemente inspirado no problema do Caixeiro Viajante (TSP, Travelling Salesman Problem) [20], considerando cidades como rela¸c˜ oes e o caminho entre essas cidades como as opera¸c˜ oes de jun¸c˜ ao. Desde sua implementa¸c˜ ao at´ e a mais recente vers˜ ao est´ avel do PostgreSQL, este algoritmo n˜ ao sofreu grandes modifica¸c˜ oes, sendo este utilizado como ´ unica alternativa para a otimiza¸c˜ ao de consultas com grande n´ umero de rela¸c˜ oes.

Embora seja um algoritmo que esteja em uso a v´ arios anos, o GEQO tem gerado uma certa insatisfa¸c˜ ao por parte dos usu´ arios e desenvolvedores do PostgreSQL. Tais fatos podem ser observados da seguinte forma:

1. A lista de discuss˜ ao dos desenvolvedores do PostgreSQL [2] possui v´ arios t´ opicos relacionados com o comportamento insatisfat´ orio deste algoritmo. Por este motivo, a substitui¸c˜ ao do GEQO ´ e atualmente um item da lista de tarefas pendentes deste projeto [3];

2. A partir da vers˜ ao 8.3, o PostgreSQL apresenta algumas funcionalidades que visam

minimizar o uso do GEQO, como por exemplo os parˆ ametros join collapse limit e from collapse limit. Esses parˆ ametros permitem que uma consulta seja dividida em v´ arios blocos com quantidades iguais de rela¸c˜ oes, o que possibilita ao algoritmo exaustivo de programa¸c˜ ao dinˆ amica otimizar esses blocos de forma iterativa;

3. Existem ainda problemas de regularidade nos planos apresentados pelo GEQO. Con- forme relatado por Bini et al. [14], em alguns casos os planos gerados s˜ ao impra- tic´ aveis, o que diminui significativamente a confiabilidade deste SGBD.

O objetivo deste estudo ´ e apresentar informa¸c˜ oes que possam contribuir para a me- lhoria do processo de otimiza¸c˜ ao de jun¸c˜ oes do PostgreSQL. A partir de um levantamento sobre as caracter´ısticas que envolvem este processo, e de uma retrospectiva sobre diver- sos tipos de algoritmos propostos na literatura, este estudo buscou implementar outro algoritmo n˜ ao exaustivo de otimiza¸c˜ ao, chamado Two Phase Optimization (2PO) [29].

Este algoritmo foi adequado ` as estruturas internas do PostgreSQL, possibilitando assim uma compara¸c˜ ao com o algoritmo GEQO. A metodologia utilizada nesta avalia¸c˜ ao se- gue um esquema sistem´ atico e multidimensional, a qual deriva de diversos outros estudos relacionados a este assunto [29, 42, 43, 46, 53].

1.4 Organiza¸ c˜ ao da Disserta¸ c˜ ao

Este estudo est´ a organizado da seguinte forma. No Cap´ıtulo 2, s˜ ao apresentados os fundamentos do modelo relacional e como suas caracter´ısticas implicam no problema da otimiza¸c˜ ao de jun¸c˜ oes. Em seguida, o Cap´ıtulo 3 apresenta v´ arios algoritmos de oti- miza¸c˜ ao de jun¸c˜ oes encontrados na literatura, destacando principalmente a forma repre- sentativa adotada por cada um deles. O Cap´ıtulo 4 apresenta como o PostgreSQL realiza a otimiza¸c˜ ao de jun¸c˜ oes. Neste cap´ıtulo ´ e descrito o algoritmo GEQO e o algoritmo 2PO, implementado durante a realiza¸c˜ ao deste estudo. Como forma de avaliar tais algoritmos, os trˆ es cap´ıtulos seguintes apresentam diversas quest˜ oes que foram consideradas neste pro- cesso. O Cap´ıtulo 5 apresenta uma revis˜ ao liter´ aria sobre as poss´ıveis formas de avalia¸c˜ ao.

O Cap´ıtulo 6 descreve a metodologia adotada neste estudo e o Cap´ıtulo 7 os resultados

experimentais obtidos nesta avalia¸c˜ ao. Por fim, o Cap´ıtulo 8 conclui este estudo.

CAP´ ITULO 2

O PROCESSAMENTO DE CONSULTAS EM SISTEMAS DE BANCOS DE DADOS RELACIONAIS

2.1 Fundamentos

O modelo relacional de banco de dados, definido por Codd em 1970 [17], pode ser con- siderado como o principal fundamento para a maioria dos SGBDs existentes atualmente.

A caracter´ıstica b´ asica deste modelo ´ e proporcionar uma clara distin¸c˜ ao entre os aspectos l´ ogicos e f´ısicos de um banco de dados, considerando para isso tanto sua representa¸c˜ ao como os m´ etodos utilizados para a manipula¸c˜ ao e recupera¸c˜ ao de seus dados [19].

Na ´ epoca em que este modelo foi proposto, os SGBDs existentes eram baseados nos modelos hier´ arquico e em rede. Para estes modelos, os usu´ ario eram obrigados a escrever rotinas de acesso a seus dados. Essas rotinas eram altamente dependentes das carac- ter´ıstica nas quais os dados estavam armazenados, incluindo sua ordena¸c˜ ao e a poss´ıvel presen¸ca de ponteiros e ´ındices. Desta forma, tais SGBDs apresentavam um baixo grau de isolamento a mudan¸cas, de modo que programas escritos para eles eram frequentemente pass´ıveis de altera¸c˜ ao caso alguma caracter´ıstica f´ısica do banco de dados fosse alterada.

No modelo relacional, os dados podem ser representados em sua forma natural, sem

qualquer imposi¸c˜ ao proveniente de suas estruturas f´ısicas de armazenamento ou de qual-

quer algoritmo utilizado para acess´ a-los. Para isso, os dados s˜ ao representados por meio

de rela¸ c˜ oes. Uma rela¸c˜ ao pode ser considerada como um conjunto de dados dispostos em

uma tabela bidimensional, onde cada coluna representa um atributo e cada linha uma

instˆ ancia, ou tupla, desta rela¸c˜ ao. A quantidade de atributos que uma rela¸c˜ ao possui ´ e

denominada grau da rela¸ c˜ ao e sua quantidade de tuplas ´ e denominada cardinalidade. Para

este modelo, n˜ ao existe qualquer imposi¸c˜ ao quanto a forma ou ordem em que os atribu-

tos devem estar dispostos, nem qualquer imposi¸c˜ ao quanto a ordem de suas respectivas

tuplas.

2.1.1 Algebra Relacional ´

Os SGBDs relacionais utilizam conjuntos de rela¸c˜ oes para representar seus esquemas de dados. As rela¸c˜ oes que comp˜ oem um banco de dados s˜ ao denominadas rela¸ c˜ oes b´ asicas.

Cada uma dessas rela¸c˜ oes deve possuir um nome ´ unico que a identifique dentro deste banco de dados. Do mesmo modo, cada um de seus atributos deve possuir um nome ´ unico que o identifique dentro de sua pr´ opria rela¸c˜ ao.

Para que os dados possam ser recuperados a partir das rela¸c˜ oes b´ asicas, esses SGBDs implementam internamente um conjunto de opera¸c˜ oes derivadas da ´ algebra relacional [18].

O princ´ıpio b´ asico desta ´ algebra ´ e produzir rela¸c˜ oes que s˜ ao obtidas a partir de rela¸c˜ oes j´ a existentes. Para isso, cada uma de suas opera¸c˜ oes (ou operadores) deve assumir como entrada (ou operandos) uma ou mais rela¸c˜ oes, produzindo como resultado uma nova rela¸c˜ ao. Existem cinco opera¸c˜ oes principais que comp˜ oem a ´ algebra relacional:

Sele¸ c˜ ao (σ

(R)): O operador de sele¸c˜ ao (σ), aplicado a uma rela¸c˜ ao de entrada R, pro- duz uma nova rela¸c˜ ao S com os mesmos atributos de R, onde as tuplas de S s˜ ao um subconjunto de R que satisfazem uma condi¸c˜ ao l´ ogica C sobre seus atributos.

Ou seja:

S = { t ∈ R | t satisfaz C } (2.1) A raz˜ ao entre a cardinalidade de S, denotada por | S | , pela cardinalidade de R ( | R | )

´ e denominada seletividade.

Proje¸ c˜ ao (π

(R)): O operador de proje¸c˜ ao (π) ´ e usado para modificar os atributos re-

tornados por uma rela¸c˜ ao. Dada uma rela¸c˜ ao R qualquer com A

, A

, A

, ..., A

atributos, a express˜ ao π

(R) produzir´ a como resultado uma nova rela¸c˜ ao S,

com as mesmas tuplas

de R mas com apenas os atributos A

, A

e A

.

S = π

(R) (2.2)

Produto Cartesiano (R × S): O produto cartesiano ( × ) ´ e um operador bin´ ario que, dadas duas rela¸c˜ oes R e S, produz uma nova rela¸c˜ ao T de modo que suas tuplas s˜ ao a combina¸c˜ ao de cada tupla de R por cada tupla de S. O grau da nova rela¸c˜ ao T ´ e igual a soma dos graus de R e S, enquanto que sua cardinalidade ´ e igual ao o produto das respectivas cardinalidades de R e S.

T = R × S (2.3)

Uni˜ ao (R ∪ S) e Diferen¸ ca (R − S): Estas s˜ ao opera¸c˜ oes muito parecidas com o que se utiliza para conjuntos matem´ aticos, exceto pelo fato de poderem ou n˜ ao permitirem a repeti¸c˜ ao de tuplas com os mesmos valores em seus atributos. As opera¸c˜ oes que permitem a repeti¸c˜ ao de tuplas utilizam uma nota¸c˜ ao de sacolas

ao inv´ es de conjuntos [49].

O que torna a ´ algebra relacional uma ferramenta poderosa para o processamento de rela¸c˜ oes em um banco de dados relacional ´ e a capacidade de combina¸c˜ ao desses operadores, como ´ e o caso do exemplo a seguir:

π

(σ

(D × σ

(F ))) (2.4) onde D e F representam, respectivamente, as rela¸c˜ oes Departamento e Funcion´ ario das Tabelas 2.1 e 2.2.

1No modelo relacional puro, as rela¸c˜oes s˜ao tratadas como conjuntos matem´aticos, de modo que n˜ao s˜ao permitidas tuplas que tenham exatamente os mesmos valores em seus respectivos atributos. Contudo, em implementa¸c˜oes de SGBDs relacionais, esta repeti¸c˜ao ´e permitida por quest˜oes de performance [49].

Por isso, a opera¸c˜ao de proje¸c˜ao descrita aqui segue esta permiss˜ao.

2O termo original em inglˆes ´eBag [49].

Tabela 2.1: Rela¸c˜ ao Departamento (D) id nome

1 Contabilidade 3 RH

2 Vendas

Tabela 2.2: Rela¸c˜ ao Funcion´ ario (F) id nome sal´ ario id dep

1 Joaquim $80,00 2

2 Francisco $200,00 1

4 Camila $150,00 2

2.1.1.1 Arvore de Consulta ´

As express˜ oes feitas por meio da ´ algebra relacional tamb´ em podem ser representadas na forma de um grafo, chamado ´ arvore de consulta, ou query tree. Nesta nota¸c˜ ao, os nodos folha representam as rela¸c˜ oes b´ asicas de um banco de dados. Os nodos internos, por sua vez, representam opera¸c˜ oes alg´ ebricas sobre essas rela¸c˜ oes b´ asicas ou sobre rela¸ c˜ oes intermedi´ arias, que s˜ ao o resultado de outras opera¸c˜ oes. Por fim, as arestas representam os fluxos dos dados, que partem das folhas at´ e chegarem ao nodo raiz. A Figura 2.1 exibe um exemplo de ´ arvore de consulta equivalente ao exemplo da Express˜ ao 2.4.

Figura 2.1: Exemplo de uma ´ arvore de consulta.

2.1.1.2 Operador de Jun¸ c˜ ao

Al´ em dos operadores b´ asicos j´ a apresentados, a ´ algebra relacional ´ e composta por diversos outros operadores especializados [49]. O mais importante deles para o proces- samento de consultas em um SGBD relacional ´ e o operador de jun¸ c˜ ao ou join (s´ımbolo o

n ). Basicamente, este ´ e um operador bin´ ario que agrega para si um produto cartesiano seguido de uma sele¸c˜ ao. Ou seja:

R o n

S ≡ σ

(R × S) (2.5)

onde R e S s˜ ao rela¸c˜ oes e C uma express˜ ao l´ ogica (ou predicado de jun¸ c˜ ao) sobre atri- butos de ambas as rela¸c˜ oes. A nota¸c˜ ao apresentada acima ´ e uma representa¸c˜ ao gen´ erica de um operador de jun¸c˜ ao. Em [49], os autores definem algumas de suas varia¸c˜ oes. Neste estudo, o operador de jun¸c˜ ao utilizado refere-se ao equi-join, o qual assume que C seja uma condi¸c˜ ao de igualdade entre atributos de R e S.

Usando o operador de jun¸c˜ ao, a ´ arvore de consulta da Figura 2.2 representa uma ex- press˜ ao alg´ ebrica equivalente ao apresentado na Figura 2.1. Embora ambas as express˜ oes sejam equivalentes em resultado, o uso de operadores de jun¸c˜ ao por SGBDs relacionais ´ e mais eficiente do ponto de vista computacional. O principal motivo disso ´ e que um algo- ritmo que implementa um produto cartesiano entre duas rela¸c˜ oes tamb´ em pode realizar simultaneamente uma sele¸c˜ ao sem aumentar significativamente seu custo computacio- nal [49]. Al´ em disso, esta sele¸c˜ ao agregada neste operador pode descartar o mais cedo poss´ıvel as tuplas que n˜ ao satisfazem sua condi¸c˜ ao de jun¸c˜ ao, o que evita um esfor¸co desnecess´ ario por parte do SGBD.

Figura 2.2: Exemplo de uma ´ arvore de consulta usando um operador de jun¸c˜ ao.

Quanto a equivalˆ encia de express˜ oes alg´ ebricas, os operadores de jun¸c˜ ao possuem duas propriedades principais, as quais s˜ ao derivadas de propriedades existentes nos operadores de sele¸c˜ ao e produto cartesiano [50]:

Comutativa:

R o n

S ≡ S o n

R (2.6)

Associativa:

R o n

(S o n

T ) ≡ (R o n

S) o n

T (2.7) A propriedade associativa apresentada acima somente ´ e v´ alida se o predicado de jun¸c˜ ao C

puder referenciar atributos de R e S. Caso contr´ ario, a jun¸c˜ ao R o n

S n˜ ao pode ser considerada v´ alida, cabendo assim apenas um produto cartesiano entre R e S ou a reescrita desta express˜ ao usando a rela¸c˜ ao T ao inv´ es de S:

R o n

(S o n

T ) ≡ (R × S) o n

T (2.8) ou

R o n

(S o n

T ) ≡ (R o n

T ) o n

S (2.9) Note que no caso da Express˜ ao 2.8 o predicado de jun¸c˜ ao C

foi deslocado para junto de C

de forma conjuntiva, pois ambos os predicados somente poder˜ ao ser avaliados ap´ os o produto cartesiano entre R e S [50].

Uma forma bastante comum de expressar graficamente quais as rela¸c˜ oes de uma con- sulta possuem predicados de jun¸c˜ ao ´ e atrav´ es do uso de um grafo n˜ ao orientado, denomi- nado grafo de jun¸ c˜ oes (ou join graph [43]

). Neste grafo, os nodos representam as rela¸c˜ oes presentes em uma consulta e as arestas representam os predicados de jun¸c˜ ao entre suas respectivas rela¸c˜ oes. A Figura 2.3 ´ e um exemplo deste tipo de grafo para uma consulta com apenas trˆ es rela¸c˜ oes e dois predicados de jun¸c˜ ao.

A representa¸c˜ ao de consultas na forma de grafos de jun¸c˜ oes permite que algumas an´ alises provenientes da teoria de grafos sejam aplicadas, como por exemplo a verifica¸c˜ ao

3object graph [32],query graph [13, 30]

de poss´ıveis ciclos ou ´ arvores [32]. Quanto ` as poss´ıveis formas de um grafo de jun¸c˜ oes, a Figura 2.4 apresenta cinco tipos geralmente encontrados na literatura, sendo estes os tipos corrente, c´ırculo, grade, estrela e clique (ou grafo completo) [29, 37, 42, 43, 53].

Figura 2.3: Exemplo de um grafo de jun¸c˜ oes. Os nodos representam as rela¸c˜ oes e as arestas os predicados sobre essas rela¸c˜ oes.

(a) Corrente (b) C´ırculo (c) Grade (d) Estrela

(e) Clique

Figura 2.4: Tipos de grafos de jun¸c˜ oes.

2.1.2 A Linguagem de Consultas SQL

Embora a ´ algebra relacional seja uma nota¸c˜ ao eficiente para a elabora¸c˜ ao de consultas, sua aplica¸c˜ ao se restringe, de um modo geral, aos mecanismos internos de um SGBD. J´ a para seus usu´ arios, os SGBDs relacionais disponibilizam uma forma mais simples e produ- tiva de elabor´ a-las. A SQL (Structured Query Language) [12], ´ e um exemplo de linguagem de consulta que est´ a dispon´ıvel em grande parte dos SGBDs existentes atualmente. Esta linguagem permite que uma consulta seja elaborada de forma descritiva, sem definir com isso a sequˆ encia de opera¸c˜ oes relacionais necess´ arias para a obten¸c˜ ao deste resultado [32].

Uma consulta SQL t´ıpica possui trˆ es partes b´ asicas: (1) a lista de atributos que devem

ser obtidos; (2) a lista de rela¸c˜ oes b´ asicas que fazem parte da consulta; e (3) as condi¸c˜ oes

l´ ogicas sobre os atributos das rela¸c˜ oes listadas em (2). O C´ odigo 2.1 apresenta em nota¸c˜ ao

SQL o mesmo exemplo da Express˜ ao 2.4, sendo tamb´ em equivalente ` a ´ arvore de consulta

da Figura 2.1.

Comparando com a ´ algebra relacional, a lista de atributos no C´ odigo 2.1 representa as opera¸c˜ oes de proje¸c˜ ao que devem ser aplicadas. A cl´ ausula “FROM”, por sua vez, indica quais as rela¸c˜ oes s˜ ao participantes da consulta. Caso haja mais de uma rela¸c˜ ao, deve ser considerado o uso de produtos cartesianos ou de jun¸c˜ oes, o que tamb´ em depende das condi¸c˜ oes de sele¸c˜ ao contidas na cl´ ausula “WHERE” [50].

C´ odigo 2.1 Exemplo de consulta SQL.

SELECT F.nome, D.nome -- 1. lista de atributos FROM F, D -- 2. lista de rela¸ c~ oes do

-- banco de dados

WHERE F.id_dep = D.id -- 3. condi¸ c~ oes l´ ogicas da AND F.salario >= 100 -- consulta

2.2 Arquitetura de Processamento de Consultas

Basicamente, os SGBDs relacionais precisam lidar com formas bastante distintas de representa¸c˜ oes de consultas. Como mencionado anteriormente, as consultas s˜ ao recebi- das por esses SGBDs na forma de uma linguagem declarativa, geralmente a SQL. Por outro lado, seu mecanismo interno de processamento ´ e composto por diversos m´ etodos que representam as opera¸c˜ oes da ´ algebra relacional. Existe uma grande variedade de m´ etodos utilizados pelos SGBDs relacionais para o processamento de consultas, sendo que os principais s˜ ao apresentados a seguir [51]:

M´ etodos de Jun¸ c˜ ao: S˜ ao m´ etodos de processamento de jun¸c˜ oes ou produtos cartesi- anos. Esses m´ etodos s˜ ao geralmente baseados em loops aninhados (nested-loop- join), baseados em tabelas hash (hash-join) ou baseados em ordena¸c˜ ao e jun¸c˜ ao (merge-join ou sort-merge-join). Cada um desses m´ etodos podem apresentar diver- sas varia¸c˜ oes, o que depende da arquitetura de armazenamento e processamento do SGBD. Em [36], os autores Mishra e Eich apresentam uma vis˜ ao detalhada de cada um desses m´ etodos.

M´ etodos de Acesso: S˜ ao m´ etodos que definem a forma de acesso a cada rela¸c˜ ao b´ asica

da consulta. Esses podem ser sequenciais (seq-scan) ou baseados em ´ındices (index- scan). Tanto os m´ etodos sequenciais como os m´ etodos baseados em ´ındices tamb´ em dependem das caracter´ısticas f´ısicas de armazenamento do SGBD.

Uma vez que a linguagem SQL simplesmente descreve quais os dados precisam ser obtidos em uma consulta, um plano de execu¸ c˜ ao, ou plano f´ısico,

descreve a sequˆ encia de m´ etodos necess´ aria para a obten¸c˜ ao da mesma. A Figura 2.5 exemplifica, atrav´ es de um modelo gen´ erico de entidade-relacionamento, o contexto de equivalˆ encia de cada uma das representa¸c˜ oes de consultas utilizadas por um SGBD. De um modo geral, existem v´ arias express˜ oes alg´ ebricas que correspondem a uma mesma consulta SQL, do mesmo modo que existem diversos planos de execu¸c˜ ao para uma mesma express˜ ao alg´ ebrica.

Consulta SQL Equivale Expressão Algébrica Equivale Plano Físico

1 N 1 N

Figura 2.5: Mapeamento de equivalˆ encia entre uma consulta SQL em seus respectivos planos f´ısicos.

Para que uma consulta SQL possa ser transformada em um plano de execu¸c˜ ao, os SGBDs relacionais implementam uma s´ erie de verifica¸c˜ oes e transforma¸c˜ oes. Embora n˜ ao seja um padr˜ ao bem definido, o mecanismo de processamento de consultas desses SGBDs

´ e geralmente composto pelas seguintes fases [28, 50]:

Parse: E respons´ ´ avel por transformar a consulta SQL em uma representa¸c˜ ao interna, de modo que ela possa ser manipulada pelo SGBD. Al´ em disso, uma an´ alise sint´ atica tamb´ em ´ e feita para garantir a corretude da consulta submetida. O resultado deste processo pode ser representado na forma de uma ´ arvore, chamada parse tree, ou em qualquer outra representa¸c˜ ao que descreva melhor a forma declarativa desta consulta.

Reescrita: A fase de reescrita analisa quest˜ oes semˆ anticas da consulta com rela¸c˜ ao ao esquema de dados. Al´ em disso, esta fase tenta reescrever a consulta submetida em

4query evaluation plan (QEP) [46],physical plan [50] ouaccess plan [28]

uma forma mais eficiente do ponto de vista declarativo. O resultado obtido consiste em uma representa¸c˜ ao simplificada da consulta.

Planejamento: Diferente da fase de reescrita, onde a consulta ´ e analisada usando o ponto de vista declarativo, a fase de planejamento consiste em enumerar e avaliar os poss´ıveis planos de execu¸c˜ ao que correspondem a esta consulta. Uma vez que existem v´ arios planos equivalentes, o objetivo principal desta fase ´ e encontrar um plano de execu¸c˜ ao que seja computacionalmente mais eficiente que os demais. O resultado desta fase ´ e o plano de execu¸c˜ ao utilizado pelo SGBD para a execu¸c˜ ao da consulta.

Execu¸ c˜ ao: Nesta fase, o plano selecionado na fase anterior ´ e interpretado e executado, de modo que cada m´ etodo descrito por ele seja ent˜ ao acionado em sua ordem deter- minada. Al´ em disso, s˜ ao realizadas requisi¸c˜ oes dos recursos de hardware necess´ arios para o seu processamento, como por exemplo a reserva de mem´ oria principal e as requisi¸c˜ oes de leituras e escritas aos dispositivos de armazenamento secund´ ario. O resultado desta fase ´ e a consulta processada pelo SGBD.

2.2.1 O Planejamento

A fase de planejamento ´ e a mais complexa dentre todas as fases do processamento de consultas. Basicamente, para transformar uma representa¸c˜ ao declarativa em um plano de execu¸c˜ ao, esta fase utiliza dois espa¸cos de busca principais: o espa¸ co alg´ ebrico e o espa¸ co de m´ etodos e estruturas [28]. O espa¸co alg´ ebrico de busca corresponde ao conjunto de poss´ıveis express˜ oes de ´ algebra relacional equivalentes a uma consulta, de modo que essas express˜ oes s˜ ao geralmente representadas por ´ arvores de consulta. A partir de cada ´ arvore de consulta, o espa¸co de m´ etodos e estruturas corresponde aos poss´ıveis m´ etodos internos do SGBD que podem ser aplicados a cada opera¸c˜ ao alg´ ebrica.

Do ponto de vista computacional, cada plano de execu¸c˜ ao que corresponde a uma mesma consulta difere na quantidade de esfor¸co exigido ao SGBD para seu processamento.

A partir do conjunto de poss´ıveis planos, o objetivo da fase de planejamento ´ e determinar

qual deles ´ e mais eficiente em sua execu¸c˜ ao, ou seja [13]:

c(s

) = min

s∈S

c(s) (2.10)

onde S representa o conjunto de poss´ıveis planos de execu¸c˜ ao para uma mesma consulta e s

o plano desejado. A fun¸c˜ ao c(s), por sua vez, corresponde ao custo de cada plano avaliado, o qual serve de compara¸c˜ ao entre os planos. Este custo ´ e calculado com base nas estimativas de custo de cada m´ etodo utilizado, as quais s˜ ao obtidas a partir do modelo de custo e das estat´ısticas fornecidas pelo SGBD. O modelo de custo representa os diversos fatores que comp˜ oem esfor¸co computacional de cada m´ etodo implementado, como o tempo de CPU, a quantidade exigida de mem´ oria principal e o n´ umero de acessos aleat´ orios e sequenciais ao dispositivo de armazenamento secund´ ario. J´ a as estat´ısticas do SGBD fornecem informa¸c˜ oes aproximadas sobre a cardinalidade e a seletividade das rela¸c˜ oes referenciadas na consulta.

2.2.1.1 Restri¸ c˜ oes do Espa¸ co de Busca

A tarefa de encontrar o melhor plano poss´ıvel, considerando todo o espa¸co alg´ ebrico de busca, ´ e computacionalmente intrat´ avel mesmo para um pequeno conjunto de rela¸c˜ oes b´ asicas [32]. Neste sentido, se fossem considerados todos os poss´ıveis arranjos entre sele¸c˜ oes, proje¸c˜ oes, produtos cartesianos e jun¸c˜ oes, a fase de planejamento de consultas poderia facilmente levar mais tempo enumerando esses poss´ıveis planos do que o tempo gasto por todas as outras fases juntas. Por outro lado, existem ainda diferen¸cas signifi- cativas entre os custos de cada plano de execu¸c˜ ao. Em alguns casos, diferen¸ca de custo entre dois planos para uma mesma consulta pode ser de centenas de milhares de vezes, o que impede que um SGBD simplesmente escolha um plano de forma arbitr´ aria, sem qualquer avalia¸c˜ ao pr´ evia.

Para restringir o espa¸co de busca em n´ıveis que sejam trat´ aveis computacionalmente, os

SGBDs utilizam diversas heur´ısticas. A primeira e mais importante delas, ´ e n˜ ao considerar

as sele¸c˜ oes e proje¸c˜ oes como opera¸c˜ oes alg´ ebricas separadas, de modo que elas n˜ ao possam

gerar, por si s´ o, rela¸c˜ oes intermedi´ arias [28]. As opera¸c˜ oes de sele¸c˜ ao devem sempre estar agregadas ou a um produto cartesiano, na forma de jun¸c˜ ao, ou a uma rela¸c˜ ao b´ asica, de modo que sua posi¸c˜ ao deva ser sempre a mais baixa poss´ıvel na ´ arvore de consulta [50].

As proje¸c˜ oes tamb´ em podem ser agregadas da mesma forma que as sele¸c˜ oes, de modo a descartar atributos desnecess´ arios sempre que poss´ıvel [46]. Em outros casos, essas proje¸c˜ oes s˜ ao executadas apenas no final do plano de execu¸c˜ ao [28].

Uma forma especial de ´ arvore de consulta que deriva da restri¸c˜ ao sobre os operadores de sele¸c˜ ao e proje¸c˜ ao ´ e a chamada de ´ arvore de jun¸ c˜ oes, ou join tree

. Esta ´ arvore apresenta apenas dois tipos de nodos: as rela¸c˜ oes b´ asicas e as opera¸c˜ oes de jun¸c˜ ao. Nesta nota¸c˜ ao, os nodos correspondentes ` as opera¸c˜ oes de jun¸c˜ ao tamb´ em podem significar um produto cartesiano, sendo que a ´ unica diferen¸ca entre eles ´ e a presen¸ca ou n˜ ao de um predicado de jun¸c˜ ao

. A Figura 2.6 apresenta dois exemplos de ´ arvores de jun¸c˜ oes, onde a ´ arvore da direita possui um produto cartesiano entre as rela¸c˜ oes A e B.

Figura 2.6: Exemplos de ´ arvores de jun¸c˜ oes.

O uso de ´ arvores de jun¸c˜ oes para representar as poss´ıveis express˜ oes alg´ ebricas a serem avaliadas na fase de planejamento permite restringir o espa¸co de busca a ser explorado.

Contudo, esta restri¸c˜ ao n˜ ao altera a natureza combinat´ oria do problema. Devido ` as propriedades comutativa e associativa dos operadores de jun¸c˜ ao e de produto cartesiano, uma consulta com N rela¸c˜ oes pode ser representada por

(

N−1

) tipos diferentes de

´

arvores de jun¸c˜ oes, sendo que cada uma delas pode assumir N ! arranjos diferentes de rela¸c˜ oes. Desta forma, o n´ umero total de solu¸c˜ oes para uma consulta com N rela¸c˜ oes ´ e de (

N−1

) (N − 1)! [35, 46]. A Tabela 2.3 apresenta n´ umero de tipos de ´ arvores de jun¸c˜ oes

5Ou ainda´arvore bin´aria de jun¸c˜oes(binary join tree) [46].

6Note que o s´ımbolo “on”, sem predicado de jun¸c˜ao, ´e definido na literatura comojun¸c˜ao natural [49].

A utiliza¸c˜ao desta nota¸c˜ao para indicar produtos cartesianos serve apenas para simplificar a defini¸c˜ao de uma ´arvore de jun¸c˜oes.

e a quantidade de poss´ıveis solu¸c˜ oes para consultas entre 1 e 12 rela¸c˜ oes.

Tabela 2.3: N´ umero de tipos de ´ arvores de jun¸c˜ oes e quantidade de poss´ıveis solu¸c˜ oes para consultas entre 1 e 12 rela¸c˜ oes. [39, 47].

Rela¸c˜ oes Tipos de ´ Arvores N´ umero de Solu¸c˜ oes Alg´ ebricas N

(

N−1

) (

N−1

) (N − 1)!

1 1 1

2 1 2

3 2 12

4 5 120

5 14 1.680

6 42 30.240

7 132 665.280

8 429 17.297.280

9 1.430 518.918.400

10 4.862 17.643.225.600

11 16.796 670.442.572.800

12 58.786 28.158.588.057.600

... ... ...

A partir dessas poss´ıveis ´ arvores de jun¸c˜ oes, existem ainda duas outras t´ ecnicas de restri¸c˜ ao que opcionalmente s˜ ao aplicadas para reduzir ainda mais o espa¸co de busca a ser avaliado:

Restri¸ c˜ ao do uso de produtos cartesianos: Geralmente, a presen¸ca de produtos car- tesianos em uma consulta ´ e um fator indesejado, visto que este pode aumentar sig- nificativamente a cardinalidade das rela¸c˜ oes intermedi´ arias. Por causa disso, em muitos SGBDs o seu uso ´ e evitado sempre que poss´ıvel. Esta restri¸c˜ ao est´ a forte- mente relacionada com a conectividade dos grafos de jun¸c˜ oes que correspondem a cada consulta, conforme foi apresentado na Figura 2.4. Quanto menor a conectivi- dade desses grafos, maior ser´ a a restri¸c˜ ao imposta.

Restri¸ c˜ ao dos tipos de ´ arvores de jun¸ c˜ oes: O conjunto de ´ arvores fechadas de

jun¸ c˜ oes (bushy trees ) refere-se ao n´ umero de solu¸c˜ oes apresentado na Tabela 2.3, o

qual n˜ ao imp˜ oe qualquer restri¸c˜ ao quanto ao tipo de ´ arvore a ser utilizado. Con-

tudo, alguns dos m´ etodos de jun¸c˜ oes implementados em SGBDs (como o nested-loop)

apresentam uma distin¸c˜ ao entre as rela¸c˜ oes recebidas como operandos, sendo que a

rela¸c˜ ao da esquerda ´ e denominada outer e a rela¸c˜ ao da direita denominada inner.

Esses m´ etodos podem apresentar um desempenho maior quando a rela¸c˜ ao da direita (inner) for uma rela¸c˜ ao b´ asica [13, 41, 46]. Por isso, algumas t´ ecnicas de planeja- mento consideram como espa¸co de busca apenas o tipo de ´ arvore de jun¸c˜ oes onde todas as rela¸c˜ oes da direita s˜ ao obrigatoriamente rela¸c˜ oes b´ asicas. Este conjunto de solu¸c˜ oes ´ e denominado ´ arvores em profundidade ` a esquerda (left-deep trees), o qual corresponde a apenas um tipo de ´ arvore de jun¸c˜ oes e consequentemente a N ! poss´ıveis solu¸c˜ oes alg´ ebricas. A Figura 2.7 ilustra os dois conjuntos de solu¸c˜ oes apresentados aqui.

(a) ´arvores em profundidade

`

a esquerda

(b) ´arvores fechadas

Figura 2.7: Tipos de ´ arvores de jun¸c˜ oes.

CAP´ ITULO 3

ALGORITMOS DE OTIMIZAC ¸ ˜ AO DE JUNC ¸ ˜ OES

Um algoritmo de otimiza¸ c˜ ao de jun¸ c˜ oes, ou simplesmente otimizador, ´ e a parte do pla- nejamento de consultas respons´ avel por definir qual a melhor ordem alg´ ebrica de jun¸c˜ oes a ser utilizada para uma determinada consulta. Al´ em dessa ordem, um otimizador deve ainda discriminar quais m´ etodos internos do SGBD s˜ ao necess´ arios para cada uma de suas opera¸c˜ oes, definindo assim o seu plano de execu¸c˜ ao.

Conforme demonstrado por Ibaraki e Kameda [27], a tarefa ordena¸c˜ ao de jun¸c˜ oes

´ e de modo geral um problema NP-Completo. Mesmo considerando as restri¸c˜ oes sobre as ´ arvores de jun¸c˜ oes apresentadas no Cap´ıtulo 2, a quantidade de poss´ıveis solu¸c˜ oes ´ e no m´ınimo exponencialmente proporcional ` a quantidade de rela¸c˜ oes presentes em uma consulta. Devido a este fato, os algoritmos propostos na literatura para a otimiza¸c˜ ao de jun¸c˜ oes se enquadram em duas categorias principais:

Algoritmos Exaustivos: Este tipo de algoritmo aplica t´ ecnicas de busca exaustiva apoi- adas por podas dinˆ amicas sobre partes de planos equivalentes. Para seu respec- tivo espa¸co de busca, um algoritmo exaustivo ´ e capaz de retornar o melhor plano poss´ıvel, ou plano ´ otimo. Contudo, devido a complexidade desse espa¸co de busca, sua aplica¸c˜ ao se restringe a consultas com poucas quantidades de rela¸c˜ oes.

Algoritmos N˜ ao Exaustivos: Os algoritmos n˜ ao exaustivos s˜ ao geralmente aplicados para consultas em que a utiliza¸c˜ ao da busca exaustiva se torna proibitiva. Esses algoritmos s˜ ao geralmente apoiados por heur´ısticas ou por componentes aleat´ orios, os quais podem produzir apenas aproxima¸c˜ oes do plano ´ otimo.

As se¸c˜ oes a seguir apresentam os principais algoritmos encontrados na literatura para

cada uma dessas categorias.

3.1 Algoritmos Exaustivos

Um dos primeiros algoritmos para a otimiza¸c˜ ao de jun¸c˜ oes encontrado na literatura foi proposto por Selinger et al. [41] para o System R [15], um prot´ otipo de banco de dados relacional desenvolvido nos laborat´ orios da IBM durante a d´ ecada de 70. O algoritmo de programa¸ c˜ ao dinˆ amica, como geralmente ´ e chamado por causa da aplica¸c˜ ao desta t´ ecnica, ´ e um algoritmo de busca exaustiva que explora propriedades f´ısicas de rela¸c˜ oes intermedi´ arias que possam influenciar no custo de opera¸c˜ oes subsequentes em um plano de execu¸c˜ ao.

Em sua proposta original, o algoritmo de programa¸c˜ ao dinˆ amica considera como pro- priedade f´ısica unicamente a ordem das rela¸c˜ oes intermedi´ arias. Esta ordem ´ e denominada pelos autores como “interesting order”. Embora a ordem das rela¸c˜ oes n˜ ao seja parte do espa¸co de busca alg´ ebrico, esta caracter´ıstica ´ e muito importante para m´ etodos de jun¸c˜ ao baseados em ordena¸c˜ ao, como ´ e o exemplo do sort-merge-join. Este m´ etodo de jun¸c˜ ao primeiramente ordena as rela¸c˜ oes pelos atributos contidos no predicado de jun¸c˜ ao antes combin´ a-los. Caso uma ou ambas as rela¸c˜ oes j´ a estejam ordenadas, tal opera¸c˜ ao pode ser perfeitamente desconsiderada, o que diminui significativamente o custo deste m´ etodo de jun¸c˜ ao.

De um modo geral, o algoritmo de programa¸c˜ ao dinˆ amica funciona de acordo com os seguintes passos:

P.1 Para cada rela¸c˜ ao na consulta, todas as formas de acesso, por exemplo, acesso sequen-

cial e por ´ındice se existir, s˜ ao obtidas. Os planos parciais (neste caso as rela¸c˜ oes

b´ asicas) s˜ ao particionados em classes de equivalˆ encia baseadas na ordena¸c˜ ao que

seus resultados possam produzir. Uma classe de equivalˆ encia adicional ´ e formada

para os planos parciais que n˜ ao produzirem resultados ordenados. As estimativas

de custo s˜ ao obtidas do modelo de custo e o plano mais barato de cada classe de

equivalˆ encia ´ e mantido para os passos seguintes. Contudo, o plano mais barato da

classe sem ordena¸c˜ ao n˜ ao ´ e mantido se ele n˜ ao for mais barato do que todos os

outros planos ordenados.

P.2 Para cada par de rela¸c˜ oes da consulta, todas as formas poss´ıveis de jun¸c˜ ao s˜ ao ava- liadas usando todos os planos de acesso ` as rela¸c˜ oes b´ asicas mantidos no passo P.1.

Novamente, os planos parciais produzidos neste passo tamb´ em s˜ ao classificados con- forme P.1, mantendo apenas os planos mais baratos de cada classe de equivalˆ encia.

P.i Para cada conjunto de i − 1 rela¸c˜ oes da consulta, o passo anterior mant´ em o plano mais barato para “junt´ a-los”, incluindo suas respectivas ordena¸c˜ oes. Desta forma, este passo avalia todas as poss´ıveis formas de adicionar mais uma rela¸c˜ ao a esses planos parciais, sem introduzir com isso produtos cartesianos. Para cada conjunto de i rela¸c˜ oes, todos os planos parciais s˜ ao classificados e “podados” como no passo P.1.

P.N Neste ponto, todos os planos de execu¸c˜ ao relevantes (contidos em um ´ unico conjunto de N rela¸c˜ oes) foram gerados e mantidos no passo anterior. O plano de menor custo

´ e finalmente escolhido e retornado pelo otimizador para ser usado na execu¸c˜ ao da consulta.

Este algoritmo sempre encontra melhor plano de seu espa¸co de busca, sendo que este espa¸co pode ser facilmente adaptado. Por exemplo, no passo P.i da descri¸c˜ ao anterior, o algoritmo de programa¸c˜ ao dinˆ amica somente pode gerar ´ arvores em profundidade ` a esquerda (left-deep trees ), visto que apenas uma rela¸c˜ ao de cada vez ´ e adicionada aos planos parciais. Na maioria dos SGBDs que implementam este algoritmo, este passo ´ e alterado para considerar todos as combina¸c˜ oes n˜ ao sobrepostas de planos intermedi´ arios entre 1 e i − 1 que formem um plano com i rela¸c˜ oes. O objetivo desta altera¸c˜ ao ´ e permitir que este otimizador trabalhe sobre o conjunto de ´ arvores fechadas de jun¸c˜ oes (bushy trees).

Outra considera¸c˜ ao importante para este algoritmo ´ e a forma de constru¸c˜ ao dos planos

intermedi´ arios. O algoritmo original, possui uma abordagem iterativa que constr´ oi os

planos de baixo para cima (bottom-up), onde o passo P.i somente pode ser realizado se

todos os planos intermedi´ arios entre 1 e i − 1 j´ a estiverem formados. Uma outra abordagem

foi proposta por Graefe e McKenna [24] como parte do projeto Volcano. Neste algoritmo,

os planos s˜ ao constru´ıdos recursivamente, ou seja, de cima para baixo (top-down ). Uma

das vantagens desta ´ ultima abordagem ´ e que o otimizador pode conhecer o custo de planos completos de execu¸c˜ ao muito antes que na abordagem bottom-up. Isto possibilita que o otimizador, durante seu processo de enumera¸c˜ ao, descarte planos parciais t˜ ao logo seu custo ultrapasse o custo do melhor plano completo encontrado at´ e o momento [42, 53].

3.2 Algoritmos N˜ ao Exaustivos

Para a maioria dos SGBDs, a aplica¸c˜ ao do algoritmo de programa¸c˜ ao dinˆ amica ´ e restrita para consultas com at´ e 10 ou 15 rela¸c˜ oes. At´ e este limite, esta t´ ecnica possui um rendimento consider´ avel. Contudo, se aplicado para consultas maiores, a quantidade de tempo e de mem´ oria principal exigida por esse algoritmo para a avalia¸c˜ ao de planos parciais cresce exponencialmente em fun¸c˜ ao da quantidade de rela¸c˜ oes.

Os algoritmos n˜ ao exaustivos s˜ ao geralmente aplicados para consultas com um grande n´ umero de rela¸c˜ oes. O objetivo deste tipo de algoritmo ´ e encontrar boas aproxima¸c˜ oes do plano ´ otimo, usando com isso um esfor¸co computacional muito menor. Existem v´ arios algoritmos propostos na literatura para esta classe de problema, os quais podem ser classificados em trˆ es grupos principais:

Determin´ısticos: S˜ ao algoritmos geralmente guiados por alguma fun¸c˜ ao heur´ıstica, os quais se beneficiam de caracter´ısticas importantes, relacionadas a algumas classes de consultas ou aos m´ etodos de jun¸c˜ ao utilizados em seu processamento.

Aleat´ orios: Para os algoritmos aleat´ orios, os poss´ıveis planos de execu¸c˜ ao s˜ ao vistos como pontos em um grafo n˜ ao orientado. Esses pontos s˜ ao conectados entre si por arestas que representam as transforma¸c˜ oes entre esses planos. O objetivo deste tipo de algoritmo ´ e realizar s´ eries de movimentos entre os nodos desse grafo em busca de solu¸c˜ oes que sejam cada vez melhores em rela¸c˜ ao ao seu custo.

Gen´ eticos: Os algoritmos gen´ eticos utilizam uma estrat´ egia de busca muito similar

ao processo biol´ ogico de evolu¸c˜ ao. Em sua representa¸c˜ ao, os poss´ıveis planos de

execu¸c˜ ao s˜ ao chamados indiv´ıduos. A partir de uma popula¸ c˜ ao, este tipo de al-

goritmo aplica diversas combina¸c˜ oes e muta¸c˜ oes sobre seus indiv´ıduos por v´ arias gera¸ c˜ oes, simulando com isso um processo de sele¸c˜ ao natural.

3.2.1 Algoritmos Determin´ısticos

Os algoritmos determin´ısticos de busca n˜ ao exaustiva utilizam t´ ecnicas de heur´ıstica que permitem tratar de forma eficiente casos espec´ıficos do problema de otimiza¸c˜ ao de jun¸c˜ oes, tomando por base as caracter´ısticas de certos tipos de consulta ou o mesmo comportamento dos m´ etodos de jun¸c˜ ao utilizados em seu processamento. Em [27], os autores Ibaraki e Kameda analisaram este processo de otimiza¸c˜ ao usando exclusivamente o nested-loop como m´ etodo de jun¸c˜ ao. Mesmo neste caso, os autores demonstraram ser um problema NP-Completo a escolha do melhor plano. Contudo, em casos mais espec´ıficos, onde as consultas n˜ ao apresentavam ciclos em seus grafos de jun¸c˜ oes, os autores conseguiram apresentar um algoritmo heur´ıstico capaz de encontrar planos ´ otimos em tempo O(N

logN ). J´ a para as consultas c´ıclicas, os autores propuseram outro algoritmo capaz de encontrar apenas uma aproxima¸c˜ ao do plano ´ otimo em tempo O(N

).

No estudo realizado por Krishnamurthy, Boral e Zaniolo [33], foram analisadas certas caracter´ısticas pertencentes aos m´ etodos de jun¸c˜ ao baseados em nested-loop e hash. Com base nos resultados de sua an´ alise, os autores propuseram um algoritmo, chamado KBZ, capaz de encontrar o plano ´ otimo de consultas ac´ıclicas em tempo O(N

).

Em [25], os autores Guttoski et al. analisaram a aplica¸c˜ ao do algoritmo de Kruskal [34]como forma de orientar a constru¸c˜ ao de ´ arvores de jun¸c˜ oes. Com base nesta t´ ecnica de constru¸c˜ ao, os autores propuseram um algoritmo que usava como heur´ıstica os custos de jun¸c˜ ao associados a cada par de rela¸c˜ oes de uma consulta. Em sua avalia¸c˜ ao, os autores demonstraram um bom comportamento desta heur´ıstica para consultas utilizadas em ambientes de apoio ` a decis˜ ao.

3.2.2 Algoritmos Aleat´ orios

Os algoritmos aleat´ orios s˜ ao geralmente t´ ecnicas de busca aplicadas a problemas com-

binat´ orios de otimiza¸c˜ ao. Para esses algoritmos, o conjunto de poss´ıveis solu¸c˜ oes ´ e re-