Front-end JDBC para Dados na Web

Transcrição

1 Front-end JDBC para Dados na Web André Filipe Brito do Nascimento (Licenciado) Dissertação para obtenção do grau: Mestre em Engenharia Informática e de Computadores Comité de Avaliação Presidente: Orientador: Co-orientador: Vogáis: Professor Doutor Alberto Manuel Rodrigues da Silva Prof. Doutor Prof. Paulo Jorge Fernandes Carreira Prof. Doutor Prof. Pável Pereira Calado Professor Doutor João Dias Pereira Outubro de 2011

2 placeholder

3 placeholder

4 placeholder

5 Sumário A, Web é um repositório global distribuído que contém uma enorme quantidade de informação relevante. Para aceder a esta informação é necessário construir aplicações que consigam integrar dados de várias fontes Web. Uma forma eficaz de atingir este objectivo consiste na criação de uma abstracção das fontes para que, do ponto-de-vista da aplicação, a Web seja apresentada como uma base de dados relacional. Esta abstracção pode ser conseguida através de um driver de conectividade a base de dados. Nesta tese propõe-se construir um driver JDBC, que permitirá a aplicações Java executar consultas SQL a páginas Web. Este driver denominado WebJDBC, assegura que cada página será representada por uma tabela ou mais tabelas. O driver actua como um processador de queries embebido capaz de interagir e cruzar informação de diversas páginas Web, do mesmo site ou de sites diferentes. O âmbito do presente trabalho incidirá sobre queries SELECT-PROJECT-JOIN e não incluirá um optimizador. Keywords: Driver JDBC, Processador, SQL, Web v

6 placeholder

7 placeholder

8 placeholder

9 Agradecimentos Gostaria de agradecer ao meu orientador, o Professor Paulo Jorge Fernandes Carreira, e co-orientador, o Professor Pável Pereira Calado. Queria também agradecer todo o apoio dos meus familiares durante estes 5 anos de curso. O meu profundo agradecimento aqueles amigos mais próximos pelo apoio, paciência e compreensão, sobretudo naqueles momentos mais difíceis. Para finalizar, o meu sincero obrigado a todos aqueles que, durante o meu percurso pela faculdade, contribuíram para o bom desenrolar do meu trabalho. ix

10 placeholder

11 Conteúdo Sumário v Agradecimentos ix 1 Introdução Motivação Objectivos e Desafios Contribuições Organização Conceitos e Trabalho Relacionado Conceitos Sistemas de Gestão de Base de Dados (SGBD) Integração virtual de dados A API JDBC A linguagem SQL Analisador SQL Trabalho Relacionado Driver CSVJdbc Driver StelsXML xi

12 2.2.3 Driver de XML da AquaLogic Driver JDBC MySQL para base de dados relacionais Processadores de linguagens para a Web Sumário e Discussão Crítica Arquitectura da solução proposta Arquitectura do Processador de queries JDBC Analisador de queries Instrução Create Model Instrução Select Gestor de dados Cursores Produto Cartesiano Selecção Projecção Eliminação de duplicados Junção Set Operations Renomeação Ordenação Buffer Mecanismo de gestão de consultas SQL Gestor de expressões Operações aritméticas Operações relacionais xii

13 3.5.3 Operações lógicas Operador Between Operador Like Operador Not Operador In Operador Exists Validação Metodologia de Avaliação Resultados Grafo de dependências Métricas de qualidade de software Testes de software Conclusões Sumário das Contribuições Trabalho Futuro Bibliografia 84 xiii

14 placeholder

15 placeholder

16 Lista de Tabelas 2.1 Correspondência entre a linguagem XQuery e a linguagem SQL xvi

17 placeholder

18 placeholder

19 Lista de Figuras 1.1 Exemplo de consulta SQL Arquitectura do SGBD Sistema de integração de dados virtual Modelos de acesso à base de dados Diagrama UML da API do JDBC Árvore de análise sintáctica Diagrama UML do driver CSV Diagrama UML do driver StelsXML Contextos de uma consulta do AquaLogic Diagrama UML do driver MySQL Esquema do driver Arquitectura do Processador de queries Diagrama de classes da camada JDBC Diagrama de classes do Model Diagrama de classes do Gestor de dados Diagrama de classes do MetaData Árvore de cursores Esquema do produto cartesiano Esquema de selecção dos dados xix

20 Diagrama de classes para a selecção de dados Esquema de projecção dos dados Esquema da cláusula Distinct Diagrama de classes do Join Esquema de junção de tabelas Esquema da união entre 2 tabelas Esquema de renomeação de uma tabela Esquema de ordenação da tabela Diagrama de classes do Order By Diagrama de classes do cursor de buffer Diagrama de classes das expressões Padrão de desenho Strategy do In Grafo de dependências Métrica de qualidade DIT Métrica de qualidade NOC Métrica de qualidade LCOM Métrica de qualidade MLOC

21 placeholder

22 Capítulo 1 Introdução Existe uma grande necessidade, por parte de empresas e organizações, de efectuar consultas a páginas Web para obter informação junto de várias páginas de forma simples e rápida. A Web é um enorme repositório de informação, que se encontra de forma semi-estruturada e não estruturada [Guan et al. (1998); Halevy et al. (2006); Mendelzon et al. (1997); Spertus & Stein (2000)]. Enquanto as páginas semiestruturadas contêm um esquema onde se encontram os dados, através de tags, que funcionam como delimitadores do conteúdo da página; as páginas não-estruturadas não contêm qualquer esquema e o conteúdo da página é tratado como simples texto. Desta forma, uma das grandes dificuldades na construção de uma consulta SQL para a Web prende-se no facto de não conhecermos o esquema de uma página Web [Mendelzon et al. (1997)]. No entanto, é possível criar um esquema da estrutura implícita da página através de diversos algoritmos de extracção de dados. O JDBC, é uma API para a linguagem de programação Java que tem como objectivo aceder a base de dados relacionais. Contudo, a mesma interface é utilizada para aceder a outras fontes de informação pouco estruturadas, tais como ficheiros CSV, XML, entre outros. A criação de um driver JDBC para a Web é de certa forma natural e reveste-se de um elevado interesse prático, uma vez que permitirá reduzir drásticamente o custo de desenvolvimento de aplicações Java que necessitem de integrar dados da Web. Devido à linguagem Java ser multi-plataforma, um driver JDBC será largamente reutilizável 3

23 4 CAPÍTULO 1. INTRODUÇÃO [Henry (2001)]. A API JDBC é uma interface padrão conhecida, usada em todos os drivers JDBC que utiliza as bibliotecas java.sql e, opcionalmente, a javax.sql [Fisher et al. (2003)]. Dado que a Web consiste num conjunto de fontes heterogéneas de dados, é desejável encarar o problema do processamento de consultas sobre múltiplas páginas Web como um problema de integração de dados de fontes heterogéneas solucionável, recorrendo a uma arquitectura wrapper-mediator [Wiederhold (1992)]. A função do mediador é fazer com que cada wrapper aceda a uma fonte de dados e mapeie os dados do esquema da fonte de dados para um esquema global, conhecido por todas as fontes. Com isto, é criada uma camada de abstracção de modo a que a aplicação faça pedidos SQL pensando que está a aceder a uma base de dados. Para realizar consultas SQL a páginas Web é útil usar um driver, pois permite criar um Sistema de Gestão de Base de Dados (SGBD) embebido que contém informação estruturada. Assim sendo, surge o driver WebJDBC que permite realizar consultas a páginas Web. Este driver é composto por dois módulos: o Processador de consultas SQL, que analisa e processa as instruções SQL, retornando o resultado à aplicação; e o Extractor de dados da Web, que permite extrair os dados de páginas Web através de diversos algoritmos de extracção supervisionada e não supervisionada, utilizadas de acordo com atécnica que está especificada na instrução SQL. Uma aplicação que prentenda integrar dados da Web deve estar isolada dos diferentes algoritmos de extracção. Esta tese descreve o processador de consultas e a integração com o Extractor de dados da Web. 1.1 Motivação Enquanto os drivers para ficheiros CSV ou XML conseguem aceder facilmente e manipular os dados das fontes de dados, uma vez que a estrutura dos ficheiros é conhecida, as páginas Web não têm uma estrutura conhecida e regular. Para efectuar consultas a páginas Web, é necessário aprender, através de algoritmos de extracção de dados, o esquema da página para posteriormente se extrair os seus dados. Suponhamos que pretendemos aceder a duas páginas Web que apresentam diversos

24 1.2. OBJECTIVOS E DESAFIOS 5 computadores. Através do driver WebJDBC consegue-se executar uma consulta SQL que acede aos dados das 2 páginas e integra a informação de acordo com a condição da cláusula WHERE. A cláusula USING MODEL é uma cláusula opcional que contém o nome do ficheiro modelo onde se encontram os dados a serem acedidos pelo Extractor Web, que extrai os dados das páginas através de uma técnica supervisionada. O driver WebJDBC irá processar a consulta recebida e envia a url de cada página ao Extractor Web. A função do Extractor é extrair os dados de cada página e retorná-los ao driver num formato conhecido por ambos. Desta forma, o driver consegue analisar a consulta e sintetizar o seu resultado. De seguida é apresentada a consulta SQL para este exemplo. (SELECT computador, preco FROM url AS t1 USING MODEL model1 WHERE t.preco < 400) NATURAL INNER JOIN (SELECT computador, preco FROM url AS t2 USING MODEL model2 WHERE t.preco < 400) Figura 1.1: Exemplo de integração de 2 páginas Web do mesmo site. À esquerda um exemplo de consulta SQL para integrar os dados. À direita um exemplo das páginas a serem processadas. 1.2 Objectivos e Desafios Este trabalho pretende desenvolver um driver JDBC que consiga responder a consultas SQL a páginas Web, criando a abstracção de que a Web é uma base de dados relacional. O grande desafio centra-se na implementação de um Processador de consultas SQL, assim como a sua integração com o Extractor de dados Web, que utiliza diversos algoritmos de extracção. Uma vez que o acesso às páginas Web é efectuado remotamente, será ainda necessário lidar com as falhas de comunição, com a indisponibilidade do site e com a lentidão da comunicação.

25 6 CAPÍTULO 1. INTRODUÇÃO 1.3 Contribuições As contribuições desta tese são as seguintes: (i) implementação de um Analisador SQL de consultas SELECT-PROJECT-JOIN, (ii) implementação de um Processador de consultas SQL, (iii) integração do Processador de consultas SQL com o Extractor de dados Web, (iv) gestão de cache de instruções SELECT e (v) implementação de um mecanismo para lidar com falhas de comunicação. 1.4 Organização Este documento encontra-se organizado como se segue: no Capítulo 2 são apresentados os conceitos subjacentes a um driver JDBC e o trabalho relacionado. O Capítulo 3 apresenta a arquitectura da solução, enquanto o Capítulo 4 expõe a arquitectura da solução e o Capítulo 5 descreve a metodologia de avaliação do trabalho desenvolvido. Por último, o Capítulo 6 apresenta as conclusões e discute direcções acerca do trabalho futuro.

26 placeholder

27 placeholder

28 Capítulo 2 Conceitos e Trabalho Relacionado Neste Capítulo apresenta os conceitos inerentes à integração de dados e aos drivers JDBC e analisa drivers open-source. 2.1 Conceitos Uma aplicação JAVA comunica com uma fonte de dados através um driver JDBC. Quando se trata de uma base de dados, o driver pode comunicar com o Sistemas de Gestão de Base de Dados (SGBD), que acede à base de dados. Porém, se a fonte de dados não for uma base de dados relacional é necessário o driver conter um Sistemas de Gestão de Base de Dados (SGBD) embebido de modo a aceder à fonte de dados e tratar dos dados, guardando-os numa estrutura de dados auxiliar (tipicamente em memória). A funcionalidade deste SGBD embebido poderá não ser completa por comparação com os Sistemas de Gestão de Base de Dados (SGBD) comuns, mas terá de implementar um analisador e um processador de consultas SQL. No driver que propomos o esquema será inferido Sistemas de Gestão de Base de Dados (SGBD) Um SGBD é um software capaz de criar e gerir grandes quantidades de dados de forma eficiente, isolando as aplicações da forma de representação e de armazenamento dos 9

29 10 CAPÍTULO 2. CONCEITOS E TRABALHO RELACIONADO dados [Garcia-Molina et al. (2008); Ramakrishnan & Gehrke (2003)]. Utilizando uma linguagem de definição de dados (DDL), são definidos os esquemas dos dados armazenados na base de dados do SGDB para que, seja possível aceder e manipular os dados através de uma linguagem de manipulação de dados (DML). Em relação à arquitectura do SGBD, podemos destacar 3 níveis de abstracção: o nível de aplicação, o nível lógico e o nível físico [Ramakrishnan & Gehrke (2003)]. Tal como apresentado na Figura 2.2, onível mais elevado éonível de aplicação que representa a interface de acesso à base de dados. Uma aplicação pode aceder à base de dados enviando um pedido SQL (i.e. uma consulta) ao SGBD. Em termos de programação, a ligação ao SGBD é estabelecida através de conectores, que são API s que permitem isolar o código da aplicação das especificações de comunicação com o SGBD. Existem conectores para várias linguagens de programação, sendo que os mais conhecidos são os drivers ODBC e JDBC para as linguagens C/C++ e Java, respectivamente. A principal vantagem na utilização de adaptadores ou API s consiste no desacoplamento das fontes de dados, isto é, uma aplicação pode ligar-se a fontes de dados distintas sem precisar de alterar a sua implementação. Onível lógico consiste na arquitectura do SGBD, variando a sua implementação com base no fornecedor. Existe uma camada de avaliação da consulta SQL, onde é feita a análise e a optimização da instrução SQL de modo a produzir um plano de execução eficiente para a avaliação da consulta, como se pode ver na Figura 2.2. Após a avaliação da consulta, um módulo conhecido como gestor de recursos acede aos ficheiros efectuando pedidos a outro módulo conhecido como gestor de buffer, tratando-os como uma colecção de páginas ou de registos. Além de manter um registo das páginas de um ficheiro, esta camada também organiza as informações de uma página. O gestor de buffer transporta os dados do disco para a memória principal, enquanto o módulo gestor de espaço em disco permite que as camadas mais elevadas consigam alocar, desalocar, ler e escrever nas páginas. O SGBD embebido que esta tese expõe não implementa ainda estão módulos. O nível físico apresentado na Figura 2.2 especifica os detalhes de armazenamento, descrevendo como é que os dados são armazenados em dispositivos de armazenamento

30 2.1. CONCEITOS 11 Nível de Aplicação Utilizadores simples Formulários Web Aplicações Front- end Interface SQL Comandos SQL Utilizadores sofisticados, programadores, administradores da BD SGBD Executor do plano Avaliador de Operador Analisador Optimizador Avaliador de query Nível Lógico Gestor de Transacção Gestor de Bloqueio Gestor de Recursos Gestor de Buffer Gestor de Espaço do Disco Gestor de Recuperação Nível Físico Ficheiros de índice Ficheiros de dados Catálogo do Sistema Base de dados Figura 2.2: Arquitectura de um SGBD dividida em 3 níveis: o nível de aplicação, o nível lógico e o nível físico. O nível de aplicação representa a interface do utilizador de acesso ao SGBD, enquanto no nível lógico a query SQL é recebida pelo SGBD e é processada, comunicando com o nível físico para aceder aos dados [Ramakrishnan & Gehrke (2003)]. secundário. Este nível guarda os dados relacionais e os índices para aceder aos dados das tabelas, assim como armazena metadados com a estrutura da base de dados. No caso do driver WebJDBC, quem fica responsável por este nível de abstracção é o Extractor de dados Web, uma vez que aprende as estruturas das páginas Web, extrai os dados e guarda-os em memória primária. Um driver que aceda a uma fonte de dados que não uma base de dados pode conter um SGBD embebido que funcionará de modo semelhante ao SGBD normal, pois trata os dados da fonte de dados e guarda-os numa estrutura, em memória.

31 12 CAPÍTULO 2. CONCEITOS E TRABALHO RELACIONADO Integração virtual de dados A integração de dados possibilita o acesso e a integração dos dados de várias fontes de dados distribuídas e heterogéneas, criando a ilusão de que se trata de um sistema homogéneo [Halevy et al. (2006); Ives et al. (1999)]. O XML adquiriu uma grande importância na integração de dados pela facilidade de representar dados estruturados e semi-estruturados [Halevy et al. (2006)]. Através dele foi possível integrar os dados de várias fontes heterogéneas, por causa da sua forma sintáctica comum de partilha de dados entre as fontes, possibilitando representar os dados de diversas fontes de uma forma comum. No caso da integração de dados virtual, a informação é extraída das fontes sempre que é feita uma consulta. É necessário ser construído um esquema global dos dados a partir das fontes heterogéneas, para que a informação extraída seja convertida para o mesmo formato de dados. Como se pode verificar na Figura 2.3, um Sistema de integração de dados virtual recebe uma consulta e decompõe-a em sub-consultas que serão enviadas às fontes de dados. É nessário especificar a ordem correcta de acesso às fontes, de forma a optimizar o pedido. O acesso às fontes é efectuado através de wrappers que acedem às fontes de dados e convertem os resultados das consultas para o esquema global. Os resultados provenientes do wrapper devem ser integrados para que uma aplicação consiga aceder aos dados de um modo uniforme. A integração de dados virtual é vantajosa quando os dados são frequentemente actualizados e as consultas resultam do acesso aos dados de uma grande quantidade de fontes distribuídas. Para colmatar o facto das fontes encontrarem-se indisponíveis e lentas, existe a integração de dados materializados. Este tipo de integração permite recuperar, integrar e armazenar os dados num repositório. Desta forma, os dados podem ser acedidos directamente através do repositório, perdendo-se menos tempo a aceder aos dados. Em casos mais complexos de integração de dados virtual é vantajoso materializar parte da informação proveniente das fontes. O Sistema de integração de dados deve fornecer metadados com informação relacionada com as fontes, que devem incluir a identidade da fonte de dados, descrições do seu conteúdo, assim como informação acerca do esquema.

32 2.1. CONCEITOS 13 Consulta SQL Reformulação da consulta Optimização da consulta Execução da consulta Wrapper Wrapper Wrapper Fonte de dados Fonte de dados Fonte de dados Figura 2.3: Sistema de integração de dados virtual. A Reformulação da consulta SQL decompõe a consulta em sub-consultas. A Optimização selecciona a ordem que as subconsultas devem ser acedidas. A Execução da consulta acede às fontes de dados através de wrappers A API JDBC A API JDBC é uma API Java que consiste num conjunto de classes e interfaces em Java através da qual é possível uma aplicação aceder a qualquer fonte de dados [Fisher et al. (2003)]. Isto permite que uma aplicação consiga aceder às várias fontes de dados de modo uniforme, não sendo necessário criar um programa para aceder a cada fonte de dados. Esta interface permite a integração entre o código JAVA e o SGBD e oferece suporte para a aplicação consultar, actualizar e remover os dados da fonte de dados através das instruções SELECT, UPDATE e DELETE do SQL, respectivamente Modelos de acesso A API JDBC suporta dois modelos de acesso à base de dados [Guan et al. (1998)]. Como se pode ver na Figura 2.4 a) um primeiro modelo é o modelo de 2 camadas, em que uma aplicação Java comunica directamente com a fonte de dados. Isso requer um driver JDBC que pode comunicar a uma fonte de dados específica. As instruções SQL de uma aplicação são enviados à fonte de dados, e os resultados desses pedidos são enviados de volta à aplicação. A fonte de dados pode estar localizada noutra máquina que não a máquina cliente. O outro modelo é o modelo de 3 camadas representado na Figura 2.4 b), em que a comunicação entre a aplicação e a fonte de dados é feita por uma camada intermédia de serviços. As instruções SQL são enviadas para esta

33 14 CAPÍTULO 2. CONCEITOS E TRABALHO RELACIONADO Aplicação Java Máquina cliente Aplicação Java JDBC Máquina cliente Servidor da aplicação JDBC Protocolo SGBD Protocolo SGBD SGBD Servidor da base de dados SGBD Servidor da base de dados Figura 2.4: Modelos de API JDBC. a) À esquerda temos o modelo de 2 camadas no qual a aplicação Java comunica directamente com a base de dados. b) À direita temos o modelo de 3 camadas. camada, que por sua vez envia o pedido à fonte de dados. A fonte recebe o pedido e envia o resultado para a camada intermediária, que depois retorna o resultado à aplicação. As vantagens do modelo de 3 camadas consistem em manter o controlo sobre o acesso e os tipos de actualizações que podem ser feitas aos dados, assim como simplificar a implementação de aplicações. Contudo, do ponto de vista do driver JDBC, os dois modelos são equivalentes Tipos de drivers Os drivers JDBC suportam quatro tipos de drivers que permitem aceder à base de dados de forma diferente [Fisher et al. (2003)]. 1. Ponte JDBC/ODBC: Este tipo de driver é acedido através da API JDBC. O driver JDBC converte as chamadas JDBC em chamadas ODBC, passando estas ao driver ODBC de modo a aceder ao SGBD com o uso da API nativa desta. O driver deve estar instalado na máquina cliente, juntamente com a aplicação escrita em Java. Este tipo de driver é apropriado para um modelo de 3 camadas. 2. Driver parcialmentede em Java/API Nativa: O driver JDBC é construído uma parte em linguagem Java e outra parte em linguagem C/C++. A camada implementada

34 2.1. CONCEITOS 15 em C/C++ é necessária para efectuar as chamadas às APIs nativas do SGBD. Estas APIs convertem as funções JDBC para uma linguagem aceite pelo SGBD. Este driver requer que algum código seja instalado na máquina cliente. 3. Driver totalmente em Java/Protocolo de Rede: Este tipo de driver utiliza um modelo de 3 camadas. O driver JDBC é um driver simples cujo único objectivo consiste em converter as chamadas JDBC num protocolo de rede (independente da base de dados) e enviar as queries SQL ao servidor intermediário, que converte as chamadas em chamadas para as APIs nativas do SGBD. 4. Driver totalmente em Java/Protocolo Nativo: O driver é implementado unicamente em Java e converte as chamadas JDBC para o protocolo de rede utilizado pelo SGBD. Destes diferentes tipos de drivers apresentados, verificamos que o driver mais adequado para o problema que pretendemos resolver é o driver do tipo 4. Este driver é implementado apenas em Java e consegue aceder directamente à Web através do protocolo de rede Instanciação de um driver JDBC Para que uma aplicação consiga aceder a uma fonte de dados através de um driver JDBC, é necessária a sua instanciação. Para isso, é apresentada uma pequena aplicação em Java que mostra os passos essenciais desde que o driver é carregado em memória até à execução da consulta SQL e à manipulação do seu resultado. 1 import java. sql. * ; 2 3 public class ExemploDriverJDBC 4 { 5 public static void main( String [] args) 6 { 7 try 8 { 9 // carregar o driver na memoria

35 16 CAPÍTULO 2. CONCEITOS E TRABALHO RELACIONADO 10 Class. forname ( nome da classe ); / / c r i a uma conexao. O parametro e assumido 13 / / como sendo o d i r e c t o r i o no qual os f i c h e i r o s sao acedidos 14 Connection conn= DriverManager. getconnection ( jdbc : caminho + args [ 0 ] ) ; / / c r i a um objecto statement para executar as queries SQL 17 Statement stmt = conn. createstatement ( ) ; / / Selecciona as colunas ID e NAME da t a b e l a exemplo 20 ResultSet r e s u l t s = stmt. executequery ( SELECT ID,NAME FROM exemplo ) ; / / acede aos r e s u l t a d o s 23 while ( r e s u l t s. next ( ) ) 24 { 25 System. out. p r i n t l n ( ID = + r e s u l t s. g e t S t r i n g ( ID ) + 26 NAME= + r e s u l t s. g e t S t r i n g ( NAME ) ) ; 27 } / / l i m p a r 30 r e s u l t s. close ( ) ; 31 stmt. close ( ) ; 32 conn. close ( ) ; 33 } 34 catch ( Exception e ) 35 { 36 System. out. p r i n t l n ( Oops > + e); 37 } 38 } 39 } Listagem 2.1: Exemplo de como uma aplicação JAVA pode comunicar e aceder aos dados do SGBD através da API JDBC. Uma aplicação que deseje conectar-se a uma base de dados precisa de registar o driver que irá utilizar (linha 10). Depois do driver ser carregado na memória, a aplicação pode criar uma conexão do driver ao SGBD (linha 14) através do objecto Connection. Ao visualizar a Figura 2.5 percebe-se que a classe DriverManager carrega o objecto Driver, que por sua vez consegue instanciar um objecto Connection. A informação

36 2.1. CONCEITOS * 1 cria java.sql.resultset java.sql.statement java.sql.connection java.sql.databasemetadata produz cria 1 java.sql.resultmetadata java.sql.preparedstatement java.sql.driver carrega java.sql.callablestatement java.sql.drivermanager Figura 2.5: Diagrama UML da API do JDBC. O Driver carrega o DriverManager, que por sua vez consegue criar o Connection. A partir do Connection consegue-se aceder à estrutura da base de dados através do DatabaseMetaData e criar Statements. O PreparedStatement extende do Statement, enquanto o CallableStatement extende do PreparedStatement. Através do Statement consegue-se criar vários ResultSets e cada ResultSet tem um ResultMetaData que contém a informação da estrutura do ResultSet. sobre a conexão criada entre a aplicação e o driver, assim como a informação relativa à estrutura dos dados da fonte de dados pode ser acedida através do objecto DatabaseMetaData. Ométodo getconnection() recebe como parâmetro a url da fonte de dados e as credenciais que permitem o acesso à fonte de dados. Este método também pode receber como parâmetro um objecto Properties que contém várias propriedades acerca do tipo de conexão à base de dados, como por exemplo, as credenciais do utilizador para que este tenha permissões para aceder às tabelas, o tipo de separador que separa os dados ou até um conjunto de bibliotecas. É a partir do Connection que o Statement é instanciado (linha 17) e as consultas SQL são executadas. O método executequery() aceita instruções SELECT, enquanto o método executeupdate() suporta instruções INSERT, UPDATE e DELETE. De acordo com a Figura 2.5, a classe PreparedStatement, que estende do Statement, é usada para instruções SQL pré-compilados e os argumentos de entrada são enviados posteriormente, quando a instrução é executada. Por sua vez, o CallableStatement, que estende do PreparedStatement, permite executar stored procedures SQL. Ao executar uma consulta, através por exemplo do método executequery(), o driver

37 18 CAPÍTULO 2. CONCEITOS E TRABALHO RELACIONADO processa o pedido e retorna um objecto do ResultSet (linha 20). Este objecto contém um ResultSetMetaData que guarda a informação da estrutura do ResultSet, como pode ser visto na Figura 2.5. O objecto ResultSet contém um conjunto de tuplos, que podem ser percorridos através do método next() (linha 23). Deste modo, consegue-se avançar o cursor para o próximo tuplo e aceder aos dados (linhas 25 e 26) A linguagem SQL O SQL, Structured Query Language, é uma linguagem padrão que permite comunicar com bases de dados relacionais. Esta linguagem permite criar, manipular e consultar SGBD relacionais [Chamberlin et al. (1981); Ramakrishnan & Gehrke (2003)]. A linguagem SQL pode ser dividida em 2 sub-linguagens: a DML e a DDL. A DML, linguagem de manipulação de dados, é um subconjunto da linguagem SQL para consultar, inserir, remover ou actualizar dados das tabelas. Utiliza os seguintes classes de manipulação de dados: o SELECT, que serve para consultar os dados; o INSERT, que serve para inserir um registo numa tabela existente; o DELETE, para remover um registo de uma tabela; e o UPDATE, que altera os valores dos dados de uma ou mais linhas de numa tabela. A DDL, linguagem de definição de dados, é um subconjunto do SQL que permite criar, remover e modificar as tabelas e vistas definidas. Para isso, utiliza as seguintes classes: CREATE, que cria um objecto na base de dados, e DROP que remove um objecto na base de dados. É através da linguagem SQL que os pedidos de consulta efectuados ao driver WebJDBC serão efectuados. O driver aceitará consultas SQL do tipo SELECT. Assim sendo, o driver suportará uma parte restrita da linguagem DML. Inicialmente espera-se que o driver suporte apenas a classe de queries SELECT-PROJECT-JOIN (SPJ), sendo que a expressão básica de consulta em álgebra relacional é representada do seguinte modo: c 1,c 2,...,c n (σ p (t 1 t 2... t m )) Esta expressão selecciona (σ) os registos que satisfazem a condição P e apresenta as respectivas colunas das tabelas relacionais através da projecção ( ) do resultado.

38 2.1. CONCEITOS 19 As expressões de álgebra relacional podem ser convertidas para a linguagem SQL. No caso da expressão mencionada, a instrução SQL toma a seguinte sintaxe: SELECT c 1,c 2,...,c n FROM t 1,t 2,...,t m WHERE P em que c i são as colunas, t i as tabelas ou outras relações e P as condições lógicas de selecção. A cláusula SELECT do SQL especifica quais são as colunas que devem ser apresentadas como resultado, a cláusula FROM contém as tabelas usadas como produto, enquanto o WHERE especifica as condições de selecção para as tabelas apresentadas na cláusula FROM Analisador SQL Quando o driver recebe uma instrução SQL é efectuada a sua análise. Esta análise, tipicamente, é efectuada em 3 etapas: a etapa de análise lexical, a etapa de análise sintáctica e a etapa de análise semântica [Buehrer et al. (2005); Cao & Bai (2010); Holub (2004)] Análise lexical A instrução SQL é percorrida da esquerda para a direita e o pedido é separado em tokens, de forma a gerar um fluxo de tokens usado na análise sintáctica como é apresentado do Figura 2.6. A análise lexical termina quando o símbolo do tipo EOF é encontrado, que representa o fim da query SQL. Os tokens são definidos através de expressões regulares. Num gerador de análise como o JavaCC, os tokens são definidos da seguinte forma: < [nome do token] : [expressão] >, como a definição do token SELECT através da forma < SELECT : SELECT >. Os símbolos podem ser ignorados através do SKIP, como por exemplo SKIP :, que ignora

39 20 CAPÍTULO 2. CONCEITOS E TRABALHO RELACIONADO os símbolos de espaçamento e de nova linha [Holub (2004)] Análise Sintáctica Existem 2 tipos de analisadores sintácticos: o ascendente e o descendente. No analisador ascendente a consulta SQL é lida da esquerda para a direita e quando é detectada uma sequência de tokens idêntica a uma regra sintáctica, é produzida uma derivação mais à direita. A análise sintáctica termina quando já não existirem mais derivações a fazer. A nível da árvore sintáctica, esta é construída a partir das folhas e termina na raiz. No analisador descendente, a análise sintáctica é feita pela expansão das regras gramaticais, onde a expansão das regras é feita da esquerda para a direita. A análise termina quando todos os tokens de entrada forem emparelhados com sucesso e não houver mais regras por expandir. Do ponto de vista da árvore sintáctica, esta começa a ser construída a partir da raiz e termina nas folhas. Existem ferramentas de geração de analisadores sintácticos para aplicações em Java, como o ANTLR 1 eojavacc 2, que são usados nos drivers JDBC. O ANTLR usa uma gramática LL(*), uma vez que não tem um número de tokens definido para escolher as regras sintácticas, enquanto o JavaCC utiliza uma gramática LL(K), que lê e deriva a consulta SQL da esquerda para a direita. Esta gramática precisa de verificar os k tokens seguintes paratomar decisões na análise de forma a seleccionar a regra sintáctica a expandir. O JavaCC define métodos Java que executam a análise da query SQL a partir das regras sintácticas, como é apresentado a seguir. void select() : { } { < SELECT > select_list() < FROM > tables() ( where_list())?

40 2.2. TRABALHO RELACIONADO 21 } < EOF > Esta definição contém uma parte delimitada por {} onde são declaradas as variáveis e outra parte, também delimitada por {}, que contém sequências de tokens. SELECT * FROM url pag1 USING MODEL model1 WHERE id = 1 SELECT Select_list FROM table_list WHERE where_cond identifier url AS identifier USING MODEL identifier identifier = integer * url pag1 id id 1 Figura 2.6: Sequência de tokens gerados na análise lexical da query SQL, que são usados na análise sintáctica Análise semântica Durante a análise sintáctica a informação contida na consulta SQL é guardada e o analisador pode gerar código relativo às tabelas e às condições da cláusula WHERE. Numa linguagem como o SQL, a análise semântica passa por verificar se as tabelas e colunas especificadas na query existem, pelo que é necessário conhecer a estrutura das tabelas da base de dados. Através dos metadados do driver, é possível conhecer a estrutura da base de dados, das tabelas e das suas colunas [Hellerstein et al. (2007)]. 2.2 Trabalho Relacionado Esta secção é apresenta o trabalho relacionado com o driver JDBC. No âmbito deste trabalho foram analisados alguns drivers JDBC open-source, nomeadamente drivers para ficheiros CSV, documentos XML e para base de dados relacionais. Existem várias linguagens declarativas semelhantes ao SQL que foram estudadas e serão apresentadas nesta secção.

41 22 CAPÍTULO 2. CONCEITOS E TRABALHO RELACIONADO java.sql.resultmetadata java.sql.resultset java.sql.statement java.sql.connection java.sql.databasemetadata CsvResultSetMetaData 1 1 CsvResultSet 0..* 1 CsvStatement cria CsvConnection CsvDataBaseMetaData java.sql.drivermanager CsvReaderAdapter SqlParser cria cria java.sql.driver CsvReader CsvScrollableReader CsvDriver Figura 2.7: Diagrama UML do driver CSV. As classes CsvDriver, CsvConnection, CsvDatabaseMetaData, CsvStatement, CsvResultSet e CsvResultSetMetaData implementam as interfaces da API do JDBC. A classe Parser é responsável pela análise sintáctica da consulta SQL e é usado o padrão Abstract Factory para se aceder aos ficheiros CSV, através da classe abstracta CsvReaderAdapter e as classes concretas CsvReader e CsvScrollableReader [Holub (2004)] Driver CSVJdbc O driver CsvJdbc 1 é um driver JDBC simples de leitura, que apresenta uma directoria contendo ficheiros CSV como uma base de dados. Cada ficheiro CSV corresponde a uma tabela. Sendo o driver CSVJdbc um driver de leitura, não suporta comandos do tipo INSERT, UPDATE e DELETE enquanto a cláusula WHERE usa apenas um campo e só suporta funções de igualdade. O driver implementa a API JDBC simplificada. A implementação da interface Driver encontra-se na classe CsvDriver, que permite criar uma ligação à directoria onde se encontram os ficheiros CSV, criando deste modo um objecto CsvConnection, como se pode ver na Figura 2.7. Esta classe guarda o caminho do directório, assim como um conjunto de propriedades com a informação acerca da ligação, a extensão dos ficheiros e os separadores entre os atributos. A classe CsvConnection, que implementa o código do interface Connection, contém 1 CsvJdbc version 0.10,

42 2.2. TRABALHO RELACIONADO 23 um objecto CsvDatabaseMetaData, que estende do DatabaseMetabase. Enquanto o CsvDatabaseMetaData contém um metadados da base de dados com informação acerca das tabelas da base de dados, da gramática SQL suportada, dos procedimentos armazenados e dos recursos da conexão. É através do CsvConnection que os objectos CsvStatements são criados, através do método CreateStatement(). OCsvStatement implementa a interface Statement, como mostra a Figura 2.7, e aceita consultas SQL que são executadas através do método executequery(). Neste método é feita a análise sintáctica da consulta SQL através do objecto SQLParser. O analisador lê a consulta da esquerda para a direita e verifica se esta está bem formada, isto é, se contém as cláusulas SELECT, FROM e, opcionalmente, o WHERE. De seguida, guarda o nome da tabela e, se for caso disso, o nome da coluna da condição WHERE. Para isso, separa as colunas especificadas na projecção do resultado da consulta SQL em tokens, através do separador,. Ao percorrer os tokens, verifica se existe alguma coluna da condição WHERE, guardando a coluna em caso afirmativo. Ainda no método executequery() do Statement, a consulta SQL é processada de forma a construir o resultado, do tipo ResultSet. Para a construção do resultado, o driver acede aos ficheiros correspondentes às tabelas especificadas na consulta através da classe CsvReaderAdapter. Como esta representado na Figura 2.7, é utilizado o padrão Abstract Factory, em que a classe CsvReaderAdapter declara uma interface genérica para a criação de objectos com comportamentos específicos, como as classes concretas CsvReader e CsvScrollableReader [Holub (2004)]. Na classe CsvReader, consegue-se aceder a uma tabela através da leitura do seu ficheiro correspondente. O método parsecsvline() lê uma linha do ficheiro e guarda os nomes das colunas, que se encontram na primeira linha ou os dados de uma linha, sendo que os dados do ficheiro encontram-se separados por um separador, normalmente por vírgulas. Por sua vez, o CsvScrollableReader possibilita que o ResultSet manipule facilmente o cursor de forma a aceder à linha da tabela que deseja. A classe CsvResultSetMetaData implementa a interface ResultSetMetaData, contém informação da estrutura do ResultSet, como por exemplo o nome das colunas. O driver faz uma análise semântica rudimentar, sendo que apenas é verificada a existência da tabela especificada na query quando se tenta abrir o ficheiro nas classes CsvReader

43 24 CAPÍTULO 2. CONCEITOS E TRABALHO RELACIONADO e CsvScrollable. OResulSet é construído com todas as colunas da tabela, mesmo que a query especifique quais as colunas a retornar. Os metadados são lidos a partir da primeira linha de cada ficheiro Driver StelsXML O driver StelsXML 1 é um driver JDBC para documentos XML, que apresenta uma directoria com documentos XML como uma base de dados. Cada documento XML corresponde a uma tabela e tem um esquema da estrutura do documento (ficheiro XSD). Este driver executa as consultas de 2 modos: pode executar a consulta armazenando os dados dos documentos XML na memória principal, onde é atingido o desempenho máximo; ou pode executar as consultas SQL através da manipulação de dados, armazenandoos na memória secundária. Este modo de execução é o mais adequado para processar documentos XML grandes. O driver StlesXML suporta a execução de vários tipos de consultas SQL. Ao nível da linguagem DDL do SQL, consegue-se criar tabelas através da criação de documentos XML com a construção do seu esquema, a partir do comando CREATE e remover tabelas com o comando DROP, removendo o ficheiro XML. Também são suportados consultas SQL da DML, usando as classes SELECT, INSERT, UPDATE e DELETE. Para melhor se perceber a arquitectura do diagrama, será descrito como o driver funciona de acordo com o diagrama UML apresentado na Figura 2.8. A classe CommonDriver, que implementa a interface Driver, efectua a ligação à directoria onde se encontram os documentos XML, instanciando um objecto Connection. A classe CommonConnection implementa a interface Connection e contém um objecto CommonMetaData, que por sua vez implementa a interface DatabaseMetaData. Através deste objecto é possível aceder a todos os esquemas dos documentos XML, através da classe Catalog. A classe CommonStatement, que implementa o Statement, é instanciada a partir da classe Connection e é através do método executequery() que são executadas as instruções SELECT. Para realizar consultas de INSERT, UPDATE e DELETE, é utilizado ométodo executeupdate(). 1 xml jdbc.htm

44 2.2. TRABALHO RELACIONADO 25 java.sql.drivermanager carrega java.sql.driver java.sql.connection java.sql.databasemetadata CommerDriver cria CommonConnection CommonMetaData XMLDriver XMLConnection XMLMetaData java.sql.statement SQLParser SQL java.sql.preparedstatement CommonStatement Catalog DMLParser CommonPreparedStatement2 XMLStatement java.sql.resultset java.sql.resultmetadata XMLPreparedStatement SQLTableResultSet CsvResultSetMetaData Figura 2.8: Diagrama UML do driver StelsXML. As classes CommonDriver, CommonConnection, CommonMetaData, CommonStatement, CommonPreparedStatement2, SQLTableResultSet e SQLTableMetaData implementam interfaces da API do JDBC. A classe Catalog contém os esquemas dos documentos XML, enquanto o DMLParser é responsável pela análise sintáctica da query SQL. No PreparedStatement, implementado no CommonPreparedStatement2, uma consulta é actualizada com todos os argumentos necessários e é executada como se se tratasse do Statement. Quando o Statement recebe a consulta, é feita a sua análise através da classe DMLParser, que cria um objecto SQL com toda a informação necessária para processar a consulta. O ResultSet encontra-se implementado no SQLTableResultSet que contém um objecto do tipo SQLTable, que representa uma tabela com o resultado do pedido. Cada linha dessa tabela é um objecto Record, que guarda os atributos desse registo. Para

45 26 CAPÍTULO 2. CONCEITOS E TRABALHO RELACIONADO se conhecer a estrutura do ResultSet, osqltablemetadata implementa a interface ResultSetMetaData Driver de XML da AquaLogic O Data Service Platform (DSP) da Aqualogic, actualmente denominado por Oracle Data Service Integrator 1, é uma ferramenta que permite aceder aos dados de diferentes fontes de dados, como a base de dados relacionais e serviços Web, através de documentos XML [Jigyasu et al. (2006)]. Esta ferramenta é composta por dois módulos: o driver JDBC que converte as expressões SQL em XQuery; e o processador de XQuery que acede aos dados das fontes de dados através de documentos XML, utilizando a linguagem XQuery. O driver recebe a instrução SQL da aplicação e converte-a numa expressão XQuery, que será enviada ao processador de XQuery. Este módulo processa a expressão e obtém como resposta um documento XML com o resultado. Desta forma, o driver converte o resultado do pedido para a linguagem SQL, retornando à aplicação um objecto ResultSet. O driver aceita apenas operações de leitura às fontes de dados e suporta sub-consultas, operações de união, intersecção, diferença, funções de agregação, ordenação, quantificadores existenciais e universais, expressões condicionais e funções definidas pelo utilizador. O mapeamento de expressões SQL para XQuery pode ser efectuado de forma sintáctica, como é mostrado na Tabela 2.1. Esta tabela apresenta a correspondência entre as construções sintácticas das duas linguagens. Cláusula XQuery FLWOR for let WHERE ORDER BY RETURN Cláusula SQL SELECT-FROM-WHERE-ORDER BY FROM vistas temporárias WHERE ORDER BY SELECT Tabela 2.1: Correspondência entre a linguagem XQuery e a linguagem SQL. 1

46 2.2. TRABALHO RELACIONADO 27 O processador de XQuery usa ficheiros que definem funções em XQuery como tabelas relacionais. Estas funções retornam uma estrutura em XML definida no ficheiro.xsd, que contém o esquema do XML. O mapeamento de SQL para XQuery é efectuado, progressivamento em 3 fases. Na 1ª fase, é feita a análise sintáctica da instrução SQL e é construída uma árvore de análise sintáctica abstracta de nós (AST), que representa a instrução. A 2ª fase modifica a árvore construída na 1ª fase, alterando a posição dos nós para facilitar a geração da expressão XQuery. Na 3ª e última fase, é gerada a expressão XQuery por partes. As partes da instrução traduzidas são armazenadas em buffers intermédios como produtos de tradução, aplicando as regras XQuery. Se a consulta SQL for complexa, a expressão XQuery será gerada por contextos. Como se pode ver na Figura 2.9, a conversão de SQL para XQuery é feita por níveis. As sub-consultas com maior nível de profundidade são geradas em primeiro, sendo que o processo de conversão da consulta é efectuado do maior para o menor nível de profundidade. Figura 2.9: Contextos da consulta de [Jigyasu et al. (2006)]. A geração da expressão da consulta é feita do nível de contexto de maior profundidade para o de menor profundidade. Após ser gerada a expressão XQuery, o driver pode executar a consulta à fonte de dados XML para obter o resultado do pedido. Verificou-se que, materializar e analisar o XML com o resultado da consulta era uma sobrecarga desnecessária. Assim sendo, o resultado da expressão XQuery é um formato mais compacto, em que os dados do resultado encontram-se separados por linhas, e os valores das colunas estão entre separadores. Desta forma, facilmente se consegue aceder aos dados e construir o resultado em SQL, do tipo ResultSet.

47 28 CAPÍTULO 2. CONCEITOS E TRABALHO RELACIONADO Driver JDBC MySQL para base de dados relacionais Os drivers de base de dados relacionais são driver capazes de aceder à base de dados através de consultas SQL [Bannon et al. (2002)]. Por exemplo, o MySql 1 suporta os comandos da linguagem DDL, como o CREATE eodrop, e define vistas e stored procedures, enquanto a linguagem DML aceita os comandos INSERT, UPDATE e DELETE. Tipicamente são os drivers do tipo 4 que delegam os comandos no SGBD propriamente dito. De seguida apresentamos a estrutura do driver do MySQL. De acordo com o diagrama UML apresentado na Figura 2.10, quando uma aplicação cria uma conexão ao driver MySQL, a classe RegisterDriver permite instanciar dois tipos de Connection: o Connection primário e vários Connection secundários. Enquanto o driver usa os Connection secundários para operações de leitura à base de dados, o Connection primário é usado para operações de escrita, de forma a manter a consistência da base de dados. Um objecto Connection representa uma sessão com uma base de dados específica e é construído um objecto Log com as credenciais do utilizador. Este driver utiliza o padrão Abstract Method em que a classe LogFactory declara um método abstracto que retorna um objecto do tipo Log. Ainterface Log define uma interface para os objectos criados pela classe LogFactory [Holub (2004)]. É dentro do contexto do Connection que os comandos são executados e os resultados são retornados. A classe ConnectionProperties contém as propriedades configuráveis para as conexões e fontes de dados. Quando o driver recebe uma consulta SQL, é feita a sua pré-compilação. O método escapesql() da classe EscapeProcessor divide a consulta em tokens, através do objecto EscapeTokenizer, para posteriormente a consulta ser reconstruída de forma a estar num formato aceite pelo servidor MySQL. Esta nova consulta pode ser enviada à SGBD com o método execsql() do Connection e é enviada e executada no servidor, onde é realizada a análise e a optimização da consulta. O SGDB retorna o resultado através do objecto ResultSet. Os dados de cada tuplo 1

48 2.2. TRABALHO RELACIONADO 29 java.sql.connection java.sql.driver ReplicationConnection NonRegisteringDriver java.sql.databasemetadata cria Driver NonRegisteringReplicationDriver DatabaseMetaData Connection MysqlIO ReplicationDriver 1 LogFactory ConnectionProperties java.sql.statement Log java.sql.preparedstatement Statement NullLogger Log4JLogger StandardLogger Jdk14Logger 1 Field java.sql.statement PreparedStatement EscapeProcessor java.sql.resultset ResultSet RowData CallableStatement ServerPreparedStatement EscapeTokenizer * java.sql.resultmetadata UpdatableResultSet RowDataDynamic RowDataStatic ResultMetaData Figura 2.10: Diagrama UML do driver MySQL. A classe ReplicationDriver permite criar uma conexão primária e várias secundárias através da classe ReplicationConnection. O driver comunica com o SGBD atráves da classe MysqlIO. As classes Statement, PreparedStatement e CallableStatement executam os comandos SQL e recebem um ResultSet com o resultado. Cada tuplo de uma tabela é um objecto RowData e cada campo da coluna é um Field. A classe Connection cria um objecto do tipo Log com as credenciais do utilizador.