THIAGO FERNANDO GREGOLON

Transcrição

1 THIAGO FERNANDO GREGOLON EXPANSÃO DO CONJUNTO DE CLÁUSULAS SQL-92 SUPORTADAS PELO BANCO DE DADOS H2 JOINVILLE SC 2011

2 UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS CCT DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO DCC THIAGO FERNANDO GREGOLON EXPANSÃO DO CONJUNTO DE CLÁUSULAS SQL-92 SUPORTADAS PELO BANCO DE DADOS H2 Trabalho apresentado à disciplina de Trabalho de Conclusão de Curso II, como requisito para a obtenção do título de Bacharel em Ciência da Computação. Orientador: Fabiano Baldo JOINVILLE SC 2011

3 3 THIAGO FERNANDO GREGOLON EXPANSÃO DO CONJUNTO DE CLÁUSULAS SQL-92 SUPORTADAS PELO BANCO DE DADOS H2 Trabalho aprovado como requisito parcial para obtenção do grau de bacharel, no curso de graduação em Ciência da Computação da Universidade do Estado de Santa Catarina UDESC. Banca Examinadora: Orientador: Fabiano Baldo, Doutor. Universidade do Estado de Santa Catarina UDESC Membro: Cristiano Damiani Vasconcellos, Doutor. Universidade do Estado de Santa Catarina UDESC Membro: Marco Aurélio Wehrmeister, Doutor. Universidade do Estado de Santa Catarina UDESC JOINVILLE SC, 04/11/2011

4 4 Dedico este trabalho aos meus pais e minha irmã pelo apoio e incentivo incondicionais durante todas as etapas da minha vida e por mais esse passo dado, sem vocês nada disso seria possível.

5 5 RESUMO Sistemas computacionais comumente manipulam grandes volumes de dados. Para auxiliar nessa tarefa são utilizados sistemas de gerenciamento de banco de dados (SGBDs). A escolha do SGBD pela empresa costuma ser uma situação crítica dentro do seu planejamento estratégico, pois envolvem custos financeiros. Muitas vezes, a utilização de SGBDs comerciais são inviáveis para pequenas empresas e a solução implica na utilização de software livre. Algumas soluções de SGBDs de código livre incluem: PostgreSQL, MySQL, Firebird, SQLite e H2. O SGBD H2 se destaca pela crescente popularização. Parte disso, se deve ao fato de ser na maioria dos casos mais rápido que outros SGBDs de código livre disponíveis no mercado. Entretanto, por estar ainda em desenvolvimento, ele não implementa completamente o padrão SQL. Neste trabalho foram levantadas as necessidades dos usuários ao realizar consultas no H2. Diante disso, foram determinadas as duas cláusulas SQL que não faziam parte do conjunto de comandos do H2, o Using e o Full Outer Join. Portanto, este trabalho visa aprimorar as implementações das consultas do SGBD H2, a fim de possibilitar melhorias na busca de dados armazenados na base de dados. Palavras-chave: Banco de dados, padrões SQL-92, sistema de gerenciamento de banco de dados, SGBD H2.

6 6 ABSTRACT Computer systems commonly handle large volumes of data. To support this task it has been used database management systems (DBMS). The choice of the right DBMS by a company is often a critical situation when considering its strategic planning because this involves financial costs. Sometimes, the usage of commercial DBMSs are not suitable for small companies and thus the solution involves the use of free software. Some solutions of open source DBMSs include: PostgreSQL, MySQL, Firebird, SQLite and H2 database. The H2 database is growing its popularity. Part of that growth is due to the fact that it is faster than the other open source DBMSs available on the market. However, it is still under development because it does not entirely implement the SQL standard specification. This paper assesses the needs of users to perform queries in H2. After this assessment, it was identifyed two SQL clauses that are not part of the H2 SQL command set. Therefore, this paper aims to improve the implementation of H2, in order to enable improvements in data queries. Keywords: Databases, SQL-92 standards, management database, H2.

7 7 LISTA DE FIGURAS Figura 1: IDE NetBeans...22 Figura 2: Configurações de acesso no browser...23 Figura 3: Página de acesso a base de dados no browser...23 Figura 4: Inner Join (MOFFATT, 2009)...24 Figura 5: Seleção utilizando o operador On...24 Figura 6: Seleção utilizando o operador Using...25 Figura 7: União da junção Left Join e Right Join (MOFFATT, 2009)...25 Figura 8: Seleção utilizando as funções Left Outer Join união Right Outer Join...26 Figura 9: Seleção utilizando a função Full Outer Join...26 Figura 10: Interpretação da consulta recebida pelo parser...27 Figura 11: Função readjoin...27 Figura 12: Pseudocódigo da implementação do Using...27 Figura 13: Junção left outer join Figura 14: Função prepare...28 Figura 15: Pseudocódigo da implementação do Full Outer Join...28 Figura 16 Leitura das tabelas Figura 17: Flags para armazenar as tabelas...30 Figura 18: Verifica a execução do Using...31 Figura 19: Executa a operação do On conforme ajustes realizados...31 Figura 20: Implementação do Full Outer Join...32 Figura 21: Esquema da base de dados...34 Figura 22: Aviso de alerta na seleção utilizando a cláusula Using...35 Figura 23: Aviso de alerta na seleção utilizando a cláusula Full Outer Join...35 Figura 24: Resultado obtido da seleção utilizando a cláusula on...36 Figura 25: Resultado obtido da seleção utilizando a cláusula Using...37 Figura 26: Resultado obtido da seleção utilizando a união das cláusulas Left Outer Join e Right Outer Join...38 Figura 27: Resultado obtido da seleção utilizando a cláusula Full Outer Join...38 Figura 28: Consulta aos registros da tabela VEICULO...39 Figura 29: Consulta de baixa complexidade (Using)...40 Figura 30: Consulta de média complexidade (Using)...41

8 8 Figura 31: Consulta de alta complexidade (Using)...41 Figura 32: Consulta de baixa complexidade (On)...42 Figura 33: Consulta de média complexidade (On)...42 Figura 34: Consulta de alta complexidade (On)...43 Figura 35: Consulta de baixa complexidade (Full Outer Join)...44 Figura 36: Consulta de média complexidade (Full Outer Join)...45 Figura 37: Consulta de alta complexidade (Full Outer Join)...45 Figura 38: Consulta de baixa complexidade (Left Outer Join união Right Outer Join)...46 Figura 39: Consulta de média complexidade (Left Outer Join união Right Outer Join)...46 Figura 40: Consulta de alta complexidade (Left Outer Join união Right Outer Join)...47

9 9 LISTA DE TABELAS Tabela 1: Comparativo entre os SGBDs (H2 DATABASE, 2011)...13 Tabela 2: Tempo de Execução das Consultas (Using/On)...43 Tabela 3: Tempo de Execução das Consultas (Full/Left e Right Join)...47

10 10 SUMÁRIO 1. INTRODUÇÃO OBJETIVOS Objetivos Específicos JUSTIFICATIVA METODOLOGIA ESTRUTURA DO TRABALHO REVISÃO BIBLIOGRÁFICA SQL Evolução dos Padrões SQL SQL SGBD H História e características gerais do H Cláusulas ainda não implementadas no H CONSIDERAÇÕES FINAIS DESENVOLVIMENTO ETAPA 1: CONFIGURAÇÃO DO AMBIENTE ETAPA 2: MÉTODOS UTILIZADOS NA IMPLEMENTAÇÃO Operação equivalente ao Using Operação equivalente ao Full Outer Join ETAPA 3: ANÁLISE DO CÓDIGO ETAPA 4: IMPLEMENTAÇÃO Using Full Outer Join ANÁLISE DOS RESULTADOS AMBIENTE DE TESTE TESTE CAIXA-PRETA NA IMPLEMENTADO DO USING...36

11 TESTE CAIXA-PRETA NA IMPLEMENTAÇÃO DO FULL OUTER JOIN AVALIAÇÃO DE DESEMPENHO DO USING E DO FULL OUTER JOIN Performance do Using Performance Full Outer Join CONCLUSÕES...49 REFERÊNCIAS ANEXO A... 52

12 12 1. INTRODUÇÃO Com o uso cada vez maior de dispositivos eletrônicos por parte da população mundial, vem aumentando significativamente o volume de informações digitais sendo manipuladas por esses dispositivos. Isso acarreta também dificuldades no armazenamento e gerenciamento adequado dessas informações. Um dos meios existentes, e de fundamental importância, são os Sistemas Gerenciadores de Banco de Dados (SGBDs). Os SGBDs são sistemas computacionais responsáveis pelos armazenamento confiável dos dados, e também pela disponibilização adequada deles para as aplicações que necessitem manipulá-los ou transformá-los. Segundo Date (2004), o conceito de SGBD é definido como um software que manipula todos os acessos a um banco de dados. O SGBD funciona como uma interface entre o usuário e o banco de dados, ou seja, todas as solicitações dos usuários, como criação de tabelas, inserção de dados e recuperação de dados, são manipuladas pelo SGBD. Ainda, Date define que os dados podem ser qualquer atributo que tenha algum significado a um indivíduo, ou a uma organização, a qual o sistema deva servir. Ou seja, qualquer atributo que seja necessário para auxiliar no processo geral das atividades desse indivíduo ou dessa organização. Segundo Korth (2005), um SGBD é constituído por um conjunto de dados associados a um conjunto de programas para acesso a esses dados. Ainda segundo o mesmo autor, o conjunto de dados, comumente chamado Banco de Dados, contém informações sobre uma empresa em particular. Além disso, Silberschatz et al. (1999) salienta que o principal objetivo de um SGBD é proporcionar um ambiente conveniente e eficiente para a recuperação e armazenamento dos dados. Na adoção e implantação de SGBDs por empresas que precisam desse suporte, existe o problema do custo financeiro que estas ferramentas podem acarretar, principalmente às empresas de pequeno e médio porte. Muitas vezes, a utilização de SGBDs comerciais são inviáveis para essas empresas e a solução implica na utilização de software livre. Essa iniciativa promove a redução de custos, o que é muito importante para muitas várias empresas e deve estar constantemente presente em uma administração, independente do momento ou situação que a empresa se encontre. Sendo assim, o uso de software livre está em ascensão em

13 13 várias corporações, incluindo os SGBDs, como, por exemplo, PostgreSQL, MySQL, Firebird, SQLite e o H2. Entre os bancos de dados citados, merecem destaque os SGBDs em memória, como por exemplo, o SQLite e o H2. Esses SGBDs em memória têm uma abordagem diferente da utilizada pelos bancos de dados tradicionais. São SGBDs onde toda a massa de dados é armazenada em memória principal e em tempo de execução. Diferentemente, nos SGBDs tradicionais os dados são armazenados nos discos rígidos. A principal vantagem dos SGBDs em memória é que o acesso aos dados na memória principal é mais rápido do que o acesso ao disco (GARCIA; SALEM, 2011). O SGBD H2 se destaca pela crescente popularização. Parte disso, se deve ao fato de ser na maioria dos casos mais rápido que outros SGBDs de código livre disponíveis no mercado. A Tabela 1 a seguir, retirada do site oficial (H2 DATABASE, 2011), mostra o resultado de testes realizados com o benchmark Pole Position. Nele são demonstrados os comparativos do H2 com bancos em memória (HSQLDB e Derby) e bancos de dados tradicionais com armazenamento em disco (PostgreSQL e MySQL). Un. H2 HSQLDB Derby PostgreSQL MySQL Inicialização ms Seleção (Select) ms Atualização (Update) ms Exclusão (Delete) ms Uso de Memória mb Tempo Total ms Tabela 1: Comparativo entre os SGBDs (H2 DATABASE, 2011). Na Tabela 1 são demonstradas algumas atividades comuns na utilização de banco de dados. Entre essas atividades, estão a inicialização do SGBD, operações de seleção, atualização, exclusão e também uso de memória. Com exceção da seleção, na qual o H2 tem o segundo melhor tempo de resposta, nas demais operações ele obteve o melhor tempo de resposta. Entre os SGBDs de memória, o H2 tem a menor taxa de uso da memória principal. O H2 é considerado um SGBD recente se comparado com os demais, pois foi concebido em dezembro de Ele é um SGBD relacional escrito em Java. Uma estatística relevante relacionada a ele diz respeito a seu número crescente de usuários. Isso pode ser constatado através do seu fórum oficial de discussão, onde em 2007 eram contabilizados em torno de 400 membros e menos de 80 postagens por mês. Já em 2011 ele conta com quase

14 membros e 400 postagens por mês. Um aumento em torno de 500% em 4 anos. Outro dado importante é a possibilidade de incorporá-lo em aplicações Java ou executá-lo no modo cliente-servidor. Entretanto, com a crescente popularização do H2, as exigências de seus usuários também têm aumentado. Porém, por se tratar de um SGBD ainda em desenvolvimento, existe uma considerável quantidade de comandos SQL de consulta que até o momento ainda não foram implementados no SGBD (H2 DATABASE, 2011). O Structured Query Language (SQL) é a linguagem padrão de banco de dados relacional, criada em A versão da SQL disponibilizada em 1992, conhecida como SQL92, é o padrão até hoje mais seguido pelos SGBD. Alterações significativas como domínios, tabelas temporárias, novos tipos de junção (left, right e natural join), expressões nomeadas (cláusula AS), valores únicos (unique), expressões na cláusula from, entre outras, foram incluídas nesse padrão de 1992(LIMA, 2004). O SGBD H2, apesar de realizar a maioria das consultas seguindo o padrão SQL-92, ainda não contempla de forma completa o conjunto de comandos SQL especificados na versão SQL-92. Porém, por se tratar de um software de código aberto, há a possibilidade de se implementar novos comandos SQL em seu código original. As implementações ainda não inclusas estão disponíveis no site oficial do H2. (H2 ROADMAP, 2011). Pelos argumentos apresentados acima, onde pode-se destacar as limitações existentes no SGBD e a possibilidade de se alterar o seu código original, o problema de pesquisa deste trabalho se caracteriza por: Como tornar o conjunto de comandos de consulta do SGBD H2 mais aderente ao padrão SQL-92? 1.1 OBJETIVOS Este trabalho tem como objetivo implementar cláusulas de consulta SQL-92 ainda não suportadas pelo SGBD H Objetivos Específicos Identificação das cláusulas de consulta SQL-92 ainda não suportadas pelo H2; Análise e seleção das cláusulas que serão implementadas; Implementação das cláusulas identificadas.

15 JUSTIFICATIVA O SGBD H2 está em franca expansão no que diz respeito a sua utilização. Entretanto, é possível constatar, através de uma pesquisa no seu site oficial, que comandos SQL largamente utilizados em outros SGBDs ainda não estão disponíveis no H2. Algumas das operações que necessitam ser implementadas são os comandos Using e Full Outer Join. A falta de implementação desses operações é amplamente questionadas nos fóruns de discussões da ferramenta, e também é mencionada no roadmap do site do SGBD. Essa deficiência no código do H2 serviu de motivação para a realização do trabalho, pois entende-se que qualquer iniciativa que venha a agregar mais operações a linguagem SQL utilizada pelo banco irá contribuir também ao estímulo para sua utilização. Assim, pretende-se disponibilizar a implementação feita ao responsável pelo site oficial do H METODOLOGIA Os passos que conduzem o presente trabalho, de forma incremental, é dividido em etapas. Primeiramente, é realizada uma revisão bibliográfica sobre a evolução dos padrões SQL, dando ênfase ao padrão SQL-92, assim como é feita uma breve introdução sobre o SGBD H2. Efetuado o levantamento inicial, será realizado um levantamento, em manuais, artigos, entre outros, das características fundamentais do SGBD H2, dando uma atenção especial as cláusulas de consultas implementadas nele. Tendo um entendimento inicial do padrão SQL-92, assim como das implementações das consultas no H2, será possível identificar cláusulas de consulta SQL ainda não suportadas pelo H2, e assim iniciar o processo de análise e seleção das consultas a serem implementadas. Após a escolha das cláusulas, será realizada a implementação de forma a utilizar todo o suporte já oferecido pela H2 em termos de estruturas internas e bibliotecas de procedimentos e funções existentes. Após a implementação das melhorias, será possível realizar a avaliação dos resultados, através da comparação das novas implementações com a distribuição oficial do H2.

16 ESTRUTURA DO TRABALHO Os próximos capítulos do documento estão estruturados da seguinte forma. No Capítulo 2 é inicialmente apresentada há revisão bibliográfica sobre a evolução do padrão SQL e em específico do padrão SQL-92. Também são contextualizados os motivos que levam o padrão SQL-92 a ser o mais importante na evolução dos padrões SQL. Seguindo, são apresentados os principais aspectos relacionados ao SGBD H2, partindo inicialmente da sua história, características gerais de funcionamento e estrutura. Por fim, são detalhadas as cláusulas de consultas que ainda não estão presentes na implementação do SGBD H2. No Capítulo 3 são apresentadas as implementações realizadas para suportar os comandos SQL selecionados dentre os ainda não implementados. Inicialmente é apresentada a configuração do ambiente e a execução do SGBD através da interface do navegador. Então é realizada a análise do código e, por fim, as implementações das cláusulas SQL. No Capítulo 4 são demonstrados os resultados obtidos, comparando o SGBD com as novas implementações e o SGBD original. Dessa forma, é possível verificar a integridade dos resultados, através do uso das cláusulas que satisfaçam igualmente os resultados das implementações. No Capítulo 5 é apresentada a conclusão. Neste sentido, é resgatado o objetivo geral e os objetivos específicos, demonstrando como eles foram obtidos. Além disso, são apresentadas as realizações adicionais e impactos positivos que as alterações propostas nesse trabalho podem agregar ao usuário do SGBD.

17 17 2. REVISÃO BIBLIOGRÁFICA A compreensão da proposta do trabalho depende do entendimento dos tópicos que o fundamentam. Diante disso, esse capítulo é realizada uma revisão bibliográfica da linguagem SQL, apresentando a evolução de seus padrões. Além disso, são apresentadas as características fundamentais do SGBD H2, assim como, os fatores que foram decisivos para a escolha das novas cláusulas de consulta SQL ainda não implementados no SGBD. 2.1 SQL O nome SQL é a abreviação de Structured Query Language (Linguagem de Consulta Estruturada). A principal função da linguagem SQL é suportar a manipulação e controle dos dados de um banco de dados (DATE et al., 1997). Atualmente, a SQL é a linguagem de consulta padrão utilizada para interação com bancos de dados relacionais. Essa padronização foi motivada pela rápida popularização da SQL no final dos anos de Assim, em um esforço conjunto de organizações como ANSI (American National Standards Institute Instituto Americano de Padrões) e ISO (International Standards Organization Organização Internacional de Padrões) iniciou-se a definição da linguagem padrão para a SQL (MELTON; SIMON, 1993). A padronização da SQL teve início em meados de 1986, com a versão SQL-86 e evoluiu até a versão SQL Por se tornar padrão para banco de dados relacionais, a linguagem SQL pode ser considerada uma das maiores razões para o sucesso dos bancos de dados no mundo comercial. Outro benefício dessa padronização é que os usuários têm pouca preocupação ao migrar suas aplicações de um banco de dados para outro. Assim, quando usuários se sentem insatisfeitos com o seu SGBD, eles têm a opção de substituí-lo sem que haja custo e tempo excessivo para migração, uma vez que ambos os SGBDs devem seguir os mesmos padrões de linguagem (ELMASRI et al., 2005) Evolução dos Padrões SQL Certamente, a SQL tem representado o padrão para linguagens de banco de dados relacionais. Ao longo de seus mais de 30 anos de existência, diversas versões da SQL foram

18 18 propostas para adequá-la às necessidades emergentes. A versão original foi desenvolvida pela IBM. Essa linguagem, originalmente chamada de Sequel, foi implementada como parte do projeto Sistema R no início dos anos de Desde então, a linguagem Sequel foi evoluindo e seu nome foi alterado para SQL (SILBERSCHATZ et. al., 1999). A SQL foi inicialmente padronizado pela ANSI em 1986 (SQL-86) e seu escopo incluía inserção, consultas, exclusão, atualização, criação de esquemas e controle de acesso aos dados. A primeira revisão ocorreu em 1989, com o surgimento da versão (SQL-89). Nesse padrão SQL foram adicionados novos recursos como valores nulos, chave primária e chave estrangeira (FORTIER, 1999). O padrão SQL-92, criado em 1992, é o padrão até hoje mais utilizado pelos SGBDs. Alterações significativas como domínios, tabelas temporárias, novos tipos de junção (left, right e natural join), expressões nomeadas (cláusula AS), valores únicos (unique), expressões na cláusula from, entre outras, foram incluídas nesse padrão. Em 1999 foi lançado o padrão SQL-99 (SQL3). Essa versão foi muito mais ambiciosa, introduzindo novos tipos de dados, consultas recursivas, gatilhos e o conceito de orientação a objetos. O SQL:2003 traz recursos para XML, instrução merge e colunas identidade (LIMA, 2004). A última versão, de 2008 (SQL:2008), conta com aprimoramento do merge, ajustes no truncate da tabela, rotinas em Java, entre outros melhorias (PAULLEY, 2011) SQL-92 O padrão SQL-92 foi desenvolvido entre 1989 até 1992 pelo comitê X3H2 National Database aos cuidados da ANSI e também pelo comitê International Database Language (DBL) aos cuidados da ISO. O resultado do padrão SQL-92, tanto para ANSI e ISO, foram idênticos (FORTIER, 1999). O SQL-92 agregou soluções como a inclusão de novos tipos e operadores como On, Using, e também o Left, Right, Inner, Full e Natural Join, expressões nomeadas com a cláusula as, valores únicos (Unique), expressões na cláusula From, além de alterações significativas como domínios e tabelas temporárias (LIMA, 2004). Uma listagem mais detalhada das alterações concebidas no padrão SQL-92 pode ser vista a seguir (FORTIER, 1999): Funcionalidades de verificação da integridade, através do Check Constraint.

19 19 Novas definições para os tipos de dados: Data, Time, Timestamp, Interval, string Bit, strings Varchar. Novas operações no SET (SET DIFFERENCE, SET INTERSECTION...) Novos conjuntos de operações, tais como Union, Natural Join, Left Outer Join, Right Outer Join, Full Outer Join. Suporte a cursores de rolagem. Suporte a linguagem SQL dinâmica. Suporte a tabelas derivadas da cláusula FROM. Suporte a tabelas temporárias. Suporte ao acesso de dados remoto. Suporte para alterações nas definições de esquema através do Alter e Drop. Devido a várias atribuições concebidas no padrão SQL-92, até hoje, é amplamente utilizado em aplicações que utilizam banco de dados. Grande parte das operações SQL são provenientes desse padrão. 2.2 SGBD H2 Essa seção tem por objetivo apresentar alguns aspectos importantes do H2. Inicialmente, é apresentada a história do SGBD e suas características gerais. Em seguida, são apresentadas as cláusulas ainda não implementadas e, por fim, as considerações acerca o referido banco de dados História e características gerais do H2 O desenvolvimento do H2 começou em 2004, mas sua primeira publicação foi em dezembro de O principal autor do H2, Thomas Mueller, é também o desenvolvedor original do Hypersonic SQL. Em 2001, ele se uniu a PointBase Inc. onde escreveu o PointBase Micro, um banco de dados comercial em Java. Naquela época, ele se desligou do Hypersonic SQL. Então, o grupo HSQL (que é a atual equipe responsável pelo desenvolvimento e manutenção do Hypersonic SQL) assumiu a continuidade do desenvolvimento do Hypersonic SQL. O nome H2 vem de Hypersonic 2, porém, o H2 não

20 20 compartilha código com o Hypersonic SQL ou com o HSQL. Portanto, o H2 foi construído a partir do zero (THE CODIST, 2011). O H2 é um banco de dados considerado rápido (Tabela 1), de código livre, escrito em Java. Além disso, várias outras características positivas podem ser citadas, tais como: Suporta padrões SQL e JDBC1. As APIs de programação principais são SQL e JDBC, no entanto, o banco também oferece suporte usando o driver PostgreSQL ODBC, agindo como um servidor PostgreSQL (POSTGRESQL ODBC, 2011). Tem ferramentas de segurança. O password de autenticação do usuário usa SHA2562 e os dados usam o AES3. Os recursos de criptografia estão disponíveis como funções dentro do banco de dados (H2 CLUSTERING, 2011). Controle de concorrência. Esse é o método comumente usado pelos sistemas de gerenciamento de banco de dados para fornecer acesso simultâneo ao banco de dados e em linguagens de programação para implementar memória transacional (H2 DATABASE, 2011). Acesso ao banco de dados usando um navegador através de um servidor web embutido. Outros bancos de dados com suporta a API JDBC também podem acessar o servidor web do H2. Por se tratar de uma aplicação cliente/servidor, é necessário um servidor e um cliente para executá-lo (H2 DATABASE, 2011) Cláusulas ainda não implementadas no H2 O H2 tem um conjunto consolidado de instruções de segurança, suportes SQL e JDBC, controle de concorrência entre outros. Entretanto, conforme Thomas Mueller (THE CODIST, 2011), o SGBD ainda não está completamente implementado e, portanto, está em constante aprimoramento. No site oficial do H2 (2011), é apresentado um roadmap (Anexo A) onde requisições e correções levantadas pelo desenvolvedor ou por usuários são postadas. Também existem níveis de prioridades das implementações. Assim é, definida a ordem que serão realizadas as novas atualizações do H2. 1 Responsável pelo envio de instruções SQL para o banco de dados. 2 Método para criptografia com 256 bits. 3 Método para criptografia de dados.

21 21 Na busca em melhorar as consultas do H2, inicialmente foi realizado uma pesquisa no roadmap do H2, procurando por cláusulas de consulta SQL ainda não implementadas no conjunto de comandos do H2. Foi identificado como prioridade de implementação para as próximas atualizações do SGBD a cláusula Full Outer Join. Em pesquisa realizada no fórum de discussão oficial do H2, foi levantado que vários usuários tinham a necessidade de utilizar o Full Outer Join em suas aplicações, e que a mesma estava sendo solucionada com uma operação equivalente (Seção 3.2) e de maior complexidade de especificação pelo usuário. Ao se realizar testes no SGBD, foi constatado que o operador Using, amplamente utilizado no relacionamento entre tabelas, não estava implementado. Mais uma vez, no fórum de discussão do H2 foram encontrados usuários discutindo a possibilidade da utilização do operador Using em suas aplicações. Com o levantamento das necessidades de melhorias no código do H2 realizado, foram selecionadas as cláusulas de consulta SQL-92 Full Outer Join e Using para serem implementadas conforme apresentado no próximo capítulo. 2.3 CONSIDERAÇÕES FINAIS Foram apresentadas nesse capítulo a revisão bibliográfica do SQL e a evolução dos padrões SQL, com destaque ao padrão SQL-92. Também foram apresentados nesse capítulo, as características do SGBD H2, assim como, demonstrada as cláusulas de consultas SQL ainda não implementadas. O H2 é um SGBD relativamente novo em comparação aos demais SGBDs no mercado. Ele está em crescente popularização e se destaque por ter um desempenho na maioria dos casos mais veloz que seus concorrentes conforme visto na Tabela 1. Entretanto, ainda está em fase de aperfeiçoamento e não conta com a implementação de algumas cláusulas importante provenientes do padrão SQL-92. Por fim, após a revisão do SQL e das características do H2, foram identificadas duas cláusulas SQL que não faziam parte dos comandos SQL implementadas no H2. Diante disso, no próximo capítulo são detalhadas as implementações do Full Outer Join e do Using.

22 22 3 DESENVOLVIMENTO O desenvolvimento foi realizado em etapas com a finalidade de proporcionar o seu melhor entendimento. Na primeira etapa é apresentada a configuração do ambiente utilizado para a implementação das novas cláusulas no código do H2. Nessa seção é demonstrada a interface do navegador, a qual é utilizada para a manipulação do SGBD e, posteriormente, para realização dos testes das novas implementações. Após a configuração da ferramenta, são apresentados os métodos utilizados na implementação das consultas SQL-92 no SGBD H2, conforme Seção 3.2. Na seção 3.3 é realizada a análise do código fonte, para compreensão e entendimento do funcionamento das funções implementadas no H2. Na última seção são apresentadas as implementações das cláusulas SQL selecionadas na seção ETAPA 1: CONFIGURAÇÃO DO AMBIENTE O SGBD H2, por ser escrito em java, conta com um boa gama de ferramentas que podem auxiliar e facilitar no seu desenvolvimento. Para esse trabalho foi escolhido o ambiente de desenvolvimento integrado IDE4 NetBeans conforme Figura 1. O NetBeans é uma IDE gratuita que conta com recursos que facilitam no desenvolvimento de aplicações (NETBEANS, 2011). Com o NetBeans é possível criar, testar e depurar aplicações codificadas em Java. Figura 1: IDE NetBeans. 4 Ambiente integrado para desenvolvimento de software

23 23 Ao executar o projeto no NetBeans é então carregada no navegador a tela de autenticação de acesso a base de dados, conforme Figura 2. Figura 2: Configurações de acesso no browser. Para executar o H2 na IDE NetBeans, antes é necessário adicionar algumas bibliotecas padrão do H2. Após a inclusão das bibliotecas e ajustes eventuais ao projeto, é possível então executar a aplicação. Quando estabelecida a conexão com a base de dados, é carregado o ambiente para execução dos comandos SQL, conforme Figura 3. Figura 3: Página de acesso a base de dados no browser. Nessa tela é possível executar consultas, inserções, atualizações, exclusões, entre outros comandos SQL.

24 ETAPA 2: MÉTODOS UTILIZADOS NA IMPLEMENTAÇÃO Para melhor compreensão do desenvolvimento das próximas etapas, nessa seção são apresentados os métodos utilizados nas implementações do Using e do Full Outer Join. O primeiro passo apresentado é a equivalência de operações SQL que proporcionam resultados iguais aos obtidos pela utilização do Using e Full Outer Join. A escolha dessa solução, deve-se ao fato de que o código permite adaptações em alto nível (nível de interpretação da consulta SQL), o que resulta em poucas alterações de código. Com isso não há necessidade de alterações na estrutura interna (baixo nível) do código, o que evita a introdução de novas erros de codificação Operação equivalente ao Using O funcionamento do operador Using é equivalente ao operador On. Isso é aplicável para os casos em que os campos utilizados nos relacionamentos entre as tabelas tenham o mesmo nome. Na Figura 4 é demonstrada uma junção Inner Join entre a tabela A e tabela B usando conjuntos. Figura 4: Inner Join (MOFFATT, 2009). O campo chave desse relacionamento nas duas tabelas é chamado de key. Utilizando a especificação SQL-92, existem duas formas possíveis para se escrever essa seleção. A primeira utilizando o operador On (on A.key=B.key) e a seguinte utilizando o Using (using Key), conforme Figuras 5 e 6. SELECT <select_list> FROM A INNER JOIN B ON A.Key = B.Key Figura 5: Seleção utilizando o operador On.

25 25 SELECT <select_list> FROM A INNER JOIN B USING Key Figura 6: Seleção utilizando o operador Using. Ambas as consultas podem ser aplicadas para a junção apresentada na Figura 4, pois são consideradas equivalentes. Quanto a operação de junção ocorre em campos com nomes distintos, como no caso de on A.key1=B.key2, o operador Using não pode ser aplicado Operação equivalente ao Full Outer Join A realização da operação Full Outer Join também apresenta a combinação de um conjunto de operações equivalente. Esse conjunto de operações é composto pela união da junção Left Outer Join com a junção Right Outer Join. Na Figura 7 são demonstradas as equivalências entre a operação Full Outer Join e a união do Left Outer Join com o Right Outer Join sobre as tabelas A e B. Isso se deve ao fato de que ao se unir os resultados da junção do Left Outer Join com o Right Outer Join, são retornados todos os resultados encontrados em cada junção externa, tendo ou não ligação entre as tabelas em questão. O mesmo ocorre ao executar o Full Outer Join. U = Figura 7: União da junção Left Join e Right Join (MOFFATT, 2009).

26 26 SELECT <select_list> FROM A LEFT OUTER JOIN B ON A.Key = B.Key UNION SELECT <select_list> FROM A RIGHT OUTER JOIN B ON A.Key = B.Key Figura 8: Seleção utilizando as funções Left Outer Join união Right Outer Join. SELECT <select_list> FROM A FULL OUTER JOIN B ON A.Key = B.Key Figura 9: Seleção utilizando a função Full Outer Join. Ambas as consultas retornam todos os valores das duas tabelas, independente da existência de campos relacionados entre as tabelas A e B. Dessa maneira, é realizada a adequação da consulta recebida para a sua junção equivalente. Com isso, é efetuada a nova implementação da operação do Full Outer Join. 3.3 ETAPA 3: ANÁLISE DO CÓDIGO O SGBD H2 é formado por um conjunto de aproximadamente 400 classes, com mais de funções implementadas, somando em torno de linhas de código fonte até o momento (CODE ANALYSIS, 2011). Para melhor compreensão do código do SGBD, nessa etapa é demonstrada uma análise geral das funções do H2. Assim, são destacados os trechos de código onde são efetuadas as alterações para implementar as cláusulas SQL propostas anteriormente. A seguir na Figura 10 é apresentado um pseudocódigo com parte da estrutura utilizada na execução de uma consulta SQL. Executa ConsultaSQL no navegador; Chama classe Parser.java Lê ConsultaSQL; Se (existe Join > 0) então chama função readjoin(); fim; Figura 10: Interpretação da consulta recebida pelo parser.

27 27 Dentre as classes do H2, será destacada a classe parser.java. Essa classe é responsável pela leitura da consulta codificada no navegador. Também nessa classe são efetuadas as análises no código e posteriormente as alterações para inclusão dos novos operadores SQL. Após a leitura da consulta pelo parser, é então executada a função readjoin, caso exista junção entre as tabelas. O readjoin é responsável pela leitura e processamento das junções nas consultas (Figura 11). Figura 11: Função readjoin. Essa é a parte do código (Figura 11) responsável pela leitura das estruturas das junções left outer join, right outer join, inner join, natural join, etc. Para a implementação do Using, é criada uma nova função dentro das junções para suportar consultas que utilizem o Using. Similar ao funcionamento já incluso no H2 da função on. O pseudocódigo (Figura 12) a seguir demonstra a interpretação das junções. Nelas são verificados os operadores utilizados nas consultas SQL do On ou do Using. Dentro da função readjoin(); se (existe InnerJoin > 0 ) então se (existe on > 0 ) então chama readexpression(); fim; se (existe using > 0 ) então chama readexpression(); fim; fim; se (existe LeftJoin > 0 ) então se (existe on > 0 ) então chama readexpression(); fim; se (existe using > 0 ) então chama readexpression(); fim; fim; Figura 12: Pseudocódigo da implementação do Using.

28 28 Conforme apresentado no pseudocódigo e na Figura 13, dentro da junção left (e demais junções) existe a leitura do operador On. Igualmente ao On, é criada uma função que efetua a leitura da cláusula Using nas consultas. Figura 13: Junção left outer join. Na outra proposta do trabalho, a implementação da cláusula Full Outer Join, é realizada através de uma reestruturação do código na função prepare, conforme Figura 14. Essa é a primeira estrutura de verificação da cláusula SQL submetida ao SGBD. A função prepare é responsável por validar se a consulta recebida está no padrão SQL. Figura 14: Função prepare. O seguinte pseudocódigo demonstra parte da alteração efetuada na implementação do Full Outer Join. Chama função Prepare Lê ConsultaSQL; Se (existe FULL > 0) então Substitui FULL por LEFT em ConsultaSQL União Substitui FULL por RIGHT em ConsultaSQL fim; fim; Figura 15: Pseudocódigo da implementação do Full Outer Join. Para a implementação da nova operação, conforme visto na Etapa 2, o Full Outer Join, corresponde a união da junção Left Outer Join com a junção Right Outer Join. Dessa forma,

29 29 conforme pseudocódigo (Figura 15), a adequação da consulta para as junções equivalentes possibilita a execução da nova operação Full Outer Join no SGBD. Após a conclusão da análise do código e definição dos novos métodos a serem agregados no conjunto de cláusulas do SGBD H2, é então iniciado o processo de implementação. 3.4 ETAPA 4: IMPLEMENTAÇÃO A implementação das novas cláusulas SQL-92 foram fortemente baseadas nos levantamentos realizados nas Etapas 2 e 3, seções 3.2 e 3.3, respectivamente. Neste sentido, foram realizadas as implementações do Using e do Full Outer Join conforme detalhado nas próximas Seções Using Como foi visto na Figura 13, a implementação do Using será realizada de forma similar a implementação do On. Isso significa que é necessário implementar o tratamento do Using em cada uma das forma de junção (left join, right join, full outer join, etc.). Na implementação do Using foram adotadas as seguintes estratégias: 1. Armazenar as tabelas envolvidas na junção; 2. Armazenar o campo recebido na operação do Using; 3. Adaptar a função readexpression() para receber as tabelas e campos armazenados. Ao iniciar o processo da junção, conforme Figura 16, é executada a função readtablefilter. Essa função é a responsável pela leitura das tabelas envolvidas na junção.

30 30 Figura 16 Leitura das tabelas. Para realizar o armazenamento das tabelas do relacionamento, conforme Figura 17, foram criadas flags que são responsáveis por tratar e obter as tabelas que estão envolvidas no relacionamento da junção. Figura 17: Flags para armazenar as tabelas. As flags são processadas e salvas após a execução do from e após a execução join, sendo assim possível trabalhar posteriormente com essas tabelas. Com a informação das tabelas, quando ocorre a execução da função de leitura das condições no readcondition(), é então adicionada a verificação do Using e também uma flag, conforme apresentado na Figura 18.

31 31 Figura 18: Verifica a execução do Using. Seguindo do ponto onde está sendo executada o Join, conforme Figura 16, é então chamada a função readexpression(). Essa função é a mesma utilizada na implementação do operador On. Nela são incluídas as tabelas armazenadas nas flags, assim como o campo de filtro utilizado no Using (Figura 19). Figura 19: Executa a operação do On conforme ajustes realizados. Com as implementações descritas acima, é possível então a execução da operação do Using no SGBD Full Outer Join Na implementação do Full Outer Join foi desenvolvido um algoritmo que reestrutura a consulta de seleção recebida para outra seleção equivalente (conforme apresentado na seção 3.2.2). Para essa implementação foi adotada a seguinte estratégia: 1. Tratar o recebimento da consulta, verificando se existe a junção Full Outer Join; 2. Se sim, substituir a junção Full Outer Join pela união das junções Left Outer Join e Right Outer Join. Na Figura 20 é apresentada a implementação da junção Full Outer Join, seguindo a estratégia definida anteriormente.

32 32 Figura 20: Implementação do Full Outer Join. Na linha 223 foi reconhecida a junção Full Outer Join. A partir desse ponto foi iniciada a leitura da seleção (do final da seleção até o início, respeitando a ordem de prioridade em que são processada as consultas), marcando as posições das últimas operações do full, select e ) nas linhas 224, 225 e 226, respectivamente. Essas estruturas são necessárias para a reestruturação da seleção, que é reescrita a partir do select mais externo até o mais interno. Entre as linhas 232 e 239 são realizados ajustes nos parênteses para seleções que possivelmente utilizem várias junções. Isso se deve ao fato de que a adequação no código é feita do ponto inicial da última seleção, até o ponto do primeiro parênteses de fechamento da SQL. Da linha 242 até a 246, é reescrita a operação do Full Outer Join para uma equivalente utilizando o Left Outer Join união com o Right Outer Join. Essa operação é repetida para todas as operações do Full Outer Join até que estejam substituídas por sua operação equivalente.

33 33 4. ANÁLISE DOS RESULTADOS As implementações das consultas SQL desenvolvidas no trabalho são avaliadas através das análises dos resultados propostas nesse capítulo. Primeiramente, são apresentados os métodos escolhidos para realizar as análises. Diante disso, são apresentados os resultados obtidos nas implementações das novas cláusulas Using e Full Outer Join. De acordo com Sommerville (2007), um conjunto de testes deve ser projetado para que um observador consiga verificar se o requisito foi satisfeito. Esse processo pode ser realizado através de teste do release do sistema. A meta principal desse processo é aumentar a confiança do fornecedor de que o sistema atende aos requisitos. Se sim, ele poderá ser liberado como um produto ou ser entregue ao cliente. Para demonstrar que o sistema atende aos requisitos, deve-se mostrar que o sistema fornece a funcionalidade, o desempenho e a confiabilidade especificados, e que não apresenta falhas durante o uso normal. O teste de releases pode ser realizado em um processo de teste caixa-preta no qual os testes são derivados da especificação do sistema. O sistema é tratado como uma caixa-preta, cujo comportamento pode ser somente determinado por meio do estudo de suas entradas e as saídas relacionadas. Outro nome para isso é teste funcional, pois o testador concentra-se na funcionalidade, e não na implementação do software (SOMMERVILLE, 2007). Além do método de caixa-preta, outro forma de avaliação dos resultados é garantir que as melhorias aplicadas no SGBD não depreciam o desempenho da execução das consultas. Com isso, foi adicionada a base uma quantidade relevante de dados para verificar o tempo de resposta nas consultas com as novas implementações. Esse resultado é então comparado com as seleções equivalentes. O intuito dessas comparações é identificar se as implementações apresentam resultados iguais as suas operações equivalentes, e também verificar se essas implementações provocaram queda no desempenho do SGBD. Nas seção 4.1 serão demonstrados os resultados obtidos conforme normas regidas pela engenharia de software através do processo de teste de caixa-preta e de desempenho das consultas.

34 AMBIENTE DE TESTE Durante e depois do processo de implementação, o programa em desenvolvimento deve ser verificado para certificar-se que ele atende a sua especificação e funcionamento esperados (SOMMERVILLE, 2007). Para iniciar o processo de avaliação dos resultados, a Figura 21 apresenta o esquema lógico do banco de dados utilizado na realização dos testes. Figura 21: Esquema da base de dados. A base de dados criada cumpre os requisitos necessários para a realização dos testes propostos para a avaliação dos resultados. Nessa base de dados é possível realizar as junções necessárias para apresentação das novas implementações. Inicialmente, nas Figuras 22 e 23 são demonstradas as tentativas de execução das seleções com os operadores Using e Full Outer Join no SGBD original (disponível no site H2 (2011), versão do SGBD , do dia ).