Otimização E Disponibilização De Operadores De - SE/8

Transcrição

MINISTÉRIO DA DEFESA
EXÉRCITO BRASILEIRO
DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA
INSTITUTO MILITAR DE ENGENHARIA
AL ERIK MENDUIÑA RAMOS CABRAL
1º TEN IGOR ALVARENGA DA SILVA NASCIMENTO
OTIMIZAÇÃO E DISPONIBILIZAÇÃO DE OPERADORES DE ELIMINAÇÃO DE
DADOS USANDO O SGBD SECONDO E SERVIÇOS WEB
Rio de Janeiro
2010
OTIMIZAÇÃO E DISPONIBILIZAÇÃO DE OPERADORES DE ELIMINAÇÃO DE
DADOS USANDO O SGBD SECONDO E SERVIÇOS WEB
Monografia de Projeto de Fim de Curso apresentada
ao Curso de Engenharia de Computação do Instituto
Militar de Engenharia.
Orientador: Cap Wallace Anacleto Pinheiro – D. Sc.
Rio de Janeiro
2010
2
2010
Praça General Tibúrcio, 80 – Praia Vermelha
Rio de Janeiro – RJ
CEP 22290-270
Este exemplar é de propriedade do Instituto Militar de Engenharia, que poderá
incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar
qualquer forma de arquivamento.
É permitida a menção, reprodução parcial ou integral e a transmissão entre
bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que
esteja ou venha a ser fixado, para pesquisa acadêmica, comentários e citações,
desde que sem finalidade comercial e que seja feita a referência bibliográfica
completa.
Os conceitos expressos neste trabalho são de responsabilidade dos autores e do
orientador.
Cabral, Erik Menduiña Ramos
Nascimento, Igor Alvarenga da Silva
Otimização e disponibilização de operadores de eliminação de dados usando o
SGBD Secondo e Serviços Web. Erik Menduiña Ramos Cabral e Igor Alvarenga da
Silva Nascimento – Rio de Janeiro: Instituto Militar de Engenharia, 2010.
Monografia de Projeto de Fim de Curso – Instituto Militar de
Engenharia, 2010.
1. Formação.
3
OTIMIZAÇÃO E DISPONIBILIZAÇÃO DE OPERADORES DE
ELIMINAÇÃO DE DADOS USANDO O SGBD SECONDO E SERVIÇOS
WEB
Monografia de Projeto de Fim de Curso apresentada ao Curso de Engenharia de
Computação do Instituto Militar de Engenharia.
Orientador: Cap Wallace Anacleto Pinheiro – D. Sc.
Aprovada em 18 de agosto de 2010 pela seguinte Banca Examinadora:
_______________________________________________________________
Cap Wallace Anacleto Pinheiro – D. Sc. – Presidente
_______________________________________________________________
Professora Maria Claudia R. Cavalcanti – D. Sc.
_______________________________________________________________
Cap Anderson Fernandes P. Dos Santos – D. Sc.
Rio de Janeiro
2010
4
“Vale mais ter um bom nome do que muitas riquezas; e o ser estimado é melhor
do que a riqueza e o ouro.”(Pv. 22; 1)
5
SUMÁRIO
1 INTRODUÇÃO .............................................................................................................. 133
1.1 Finalidade ..................................................................................................................... 13
1.2 Caracterização do Problema ........................................................................................ 15
1.3 Objetivos ...................................................................................................................... 16
1.4 Organização do Trabalho ............................................................................................. 16
2 REVISÃO DA LITERATURA ........................................................................................... 17
2.1 SGBD Secondo ............................................................................................................ 17
2.2 Conceitos Voltados à Otimização ................................................................................. 19
2.2.1 Complexidade de algoritmos ..................................................................................... 19
2.2.2 Comportamento Assintótico das Funções.................................................................. 19
2.2.3 Otimizador do Secondo ............................................................................................. 20
2.3 Serviços Web ............................................................................................................... 21
2.3.1 Motivação .................................................................................................................. 21
2.3.2 Conceito de Serviço Web .......................................................................................... 22
2.3.3 Tecnologias utilizadas................................................................................................ 23
2.3.3.1 XML ......................................................................................................................... 23
2.3.3.2 SOAP ...................................................................................................................... 24
2.3.3.3 WSDL ...................................................................................................................... 27
2.3.3.4 UDDI........................................................................................................................ 29
2.4 Arcabouço Autonômico de Eliminação de Dados ....................................................... ..30
2.4.1 Visão Geral ................................................................................................................ 30
2.4.2 Padrão Dados Permitidos .......................................................................................... 33
2.4.3 Padrão Bloqueador de Dados Proibidos .................................................................... 33
2.4.4 Padrão Bloqueador de Dados Similares .................................................................... 33
2.4.5 Padrão Bloqueador de Dados Irrelevantes ................................................................ 33
2.4.6 Padrão Eliminador de Dados Proibidos ..................................................................... 34
2.4.7 Padrão Eliminador de Dados Similares...................................................................... 34
2.4.8 Padrão Eliminador de Dados Obsoletos .................................................................... 34
2.4.9 Padrão Eliminador de Dados Irrelevantes.................................................................. 35
2.5 Exemplo do tratamento de dados ................................................................................. 35
3 ESTUDO E IMPLEMENTAÇÃO DO OTIMIZADOR ......................................................... 38
3.1 Estudos para otimização................................................................................................ 39
6
3.1.1 Complexidade dos operadores ................................................................................... 39
3.1.2 Seletividade dos Operadores..................................................................................... 43
3.1.3 Ordem dos Operadores ............................................................................................. 47
3.1.4 Implementação do Otimizador ................................................................................... 51
3.1.4.1 Estudo da Viabilidade de Adaptação do Otimizador ................................................ 51
3.1.4.2 Modificações Realizadas ......................................................................................... 52
4 IMPLEMENTAÇÃO DO WEB SERVICE .......................................................................... 54
4.1 Análise da funcionalidade ............................................................................................. 54
4.2 Ferramentas e passos utilizados para o desenvolvimento ............................................ 55
4.3 Diagrama de Atividades da operação do serviço Web .................................................. 57
5 EXPERIMENTOS ............................................................................................................ 62
5.1 Experimentos relacionados à otimização ...................................................................... 62
5.2 Testes do otimizador .................................................................................................... 63
5.3 Experimento relacionado ao serviço Web ..................................................................... 67
5.3.1 Acesso ao serviço e passagem dos parâmetros ........................................................ 67
5.3.2 Análise do experimento ............................................................................................. 67
5.3.3 Forma alternativa de desenvolvimento do cliente ...................................................... 68
6 CONCLUSÃO .................................................................................................................. 70
6.1 Trabalhos Futuros ........................................................................................................ 70
7 REFERÊNCIAS ............................................................................................................... 72
8 ANEXOS ......................................................................................................................... 74
8.1 Porção do código do OptimizerServer.java relativa à otimização .................................. 74
8.2 Arquivo de Configuração do usuário ............................................................................. 78
8.3 Cliente alternativo para a invocação do serviço ............................................................ 81
7
LISTA DE ACRÔNIMOS
HTTP
Hyper Text Transfer Protocol
SGBD
Sistema de Gerenciamento de Banco de Dados
SOAP
Simple Object Access Protocol
UDDI
Universal Description Discovery and Integration
IBM
Internation Business Machines
DB
Database
OS
Operation System
GUI
Graphical User Interface
SQL
Structured Query Language
XML
Extensible Markup Language
WSDL
Web Service Description Language
URI
Uniform Resource Identifier
RPC
Remote Procedure Call
RMI
Remote Method Invocation
DCOM
Distributed Component Object Model
CORBA
Common Object Request Broker Architecture
IIS
Internet Information Services
AD
Allowed Data
DP
Discarding Prohibited
DS
Discarding Similar
BS
Blocking Similar
DI
Discarding Irrelevant
BI
Blocking Irrelevant
DO
Discarding Obsolet
BP
Blocking Prohibited
FS
Fator de Seletividade
URL
Uniform Resource Locator
RAM
Random Access Memory
IDE
Integrated Development Environment
8
LISTA DE ILUSTRAÇÕES
Fig. 2.1: Funcionamento de um Serviço Web .................................................................... 233
Fig. 2.2: Arquitetura de uma mensagem SOAP ................................................................. 255
Fig. 2.3: Arquitetura Geral do Framework de Eliminação de Dados..................................... 32
Fig. 3.1: Comportamento do Operadores .......................................................................... 466
Fig. 4.1: Representação da arquitetura conceitual............................................................... 55
Fig. 4.2: Página de apresentação dos serviços implantados no servidor ............................. 56
Fig. 4.3: Documento WSDL gerado pelo framework Axis 2 ................................................. 57
Fig. 4.4: Diagrama de seqüência do serviço Web ................................................................ 58
Fig. 4.5: Diagrama de Seqüência de interações do Web service ......................................... 60
Fig. 5.1: Interface gráfica do Secondo ................................................................................. 66
Fig. 5.2: Feeds retornados pelo Web service....................................................................... 68
9
LISTA DE TABELAS
Tab. 2.1: Cenários e significados dos padrões de eliminação de dados .............................. 31
Tab. 2.2: Tópicos e textos associados aos dados ............................................................... 36
Tab. 2.3: Parâmetros a serem utilizados pelo padrão AD .................................................... 36
Tab. 2.4: Dado descartado .................................................................................................. 37
Tab. 2.5: Dados transferidos para o repositório interno ....................................................... 37
Tab. 3.1: Complexidade dos operadores ............................................................................. 42
Tab. 3.2 : Comportamento dos Operadores AD, DP e DS ................................................... 45
Tab. 3.3: Classificação dos Operadores .............................................................................. 48
Tab. 3.4: Operadores e suas fórmulas de seletividade ........................................................ 49
Tab. 5.1: Tempos medidos para a consulta ......................................................................... 65
10
RESUMO
Este trabalho trata da implementação de um otimizador das consultas realizadas
pelos operadores de uma álgebra de eliminação de dados baseada no SGBD
Secondo, visando diminuir o tempo gasto durante a execução das mesmas. Também
faz parte do escopo deste trabalho disponibilizar estes operadores via Serviços Web,
de forma a facilitar o acesso a eles.
11
ABSTRACT
This paper discusses the implementation of an optimizer of the queries executed
by the operators of a data discarding algebra based on the database system
Secondo, aiming to reduce the time spent during their execution. It’s also part of the
scope of this work to make these operators available using Web Services, so as to
make easier the access to them.
12
1 INTRODUÇÃO
No mundo de hoje, a quantidade de informações que existe à disposição é
praticamente imensurável. E esse montante tem se tornado cada dia maior,
principalmente na Web. Sobre cada assunto há uma série de notícias obsoletas,
falsas, contraditórias, duplicadas ou muito similares, ou seja, existem muitos dados
irrelevantes circulando na Internet, que não apresentam conteúdo de interesse para o
usuário.
Imagine-se a seguinte situação: deseja-se pesquisar sobre o atentado
terrorista de 11 de setembro de 2001. Obviamente, serão encontradas na Internet
milhares de notícias similares sobre este assunto. Seria interessante a possibilidade
de eliminar algumas notícias de modo a evitar essas redundâncias. Mas para isso,
seria necessário definir critérios e uma interface para esse processo de eliminação, o
que demanda um estudo de diferentes técnicas e processos. O problema não se
restringe somente a dados similares. Dados considerados proibidos, ou seja, aqueles
que não devem estar presentes nos repositórios internos dos sistemas, pois podem
causar algum prejuízo caso sejam incluídos ou mantidos, também aparecem
frequentemente. Ainda há os dados obsoletos, que perderam a relevância com a
passagem do tempo. Todos estes tipos de dados precisam ser eliminados de alguma
forma. Exemplos práticos destes tipos de dados são os conteúdos de spams, sites de
conteúdo impróprio para certos públicos, notícias muito antigas, etc. Por outro lado,
pode-se desejar filtrar alguns dados que contêm informação de interesse do usuário.
São os chamados dados permitidos, que devem ser incorporados ao sistema. Um
exemplo prático é uma ferramenta de busca, onde se informa o assunto de interesse.
1.1 Finalidade
Em PINHEIRO (2010) foi desenvolvido um trabalho que discute os temas
relacionados ao descarte de dados, focando principalmente os chamados Padrões
Autonômicos para Eliminação de Dados. O nome autonômico vem da habilidade
desses padrões atuarem com a mínima necessidade de intervenção humana,
monitorando o ambiente em que se encontram, analisando os dados e executando
13
ações de acordo com planos formalizados previamente. Apesar da necessidade de
uma análise criteriosa do que pode ou não ser descartado, normalmente, o número
de pessoas disponíveis é insuficiente para fazer essa avaliação. Dessa forma, os
sistemas precisam ser dotados de técnicas que possam avaliar os dados de forma
coerente e descartá-los, caso seja apropriado.
Nesse trabalho, PINHEIRO (2010) também desenvolveu uma álgebra de
operadores de eliminação de dados usando o SGBD Secondo1, baseada nos
padrões de eliminação de dados propostos. Esses padrões abordam o bloqueio ou o
descarte dos tipos de dados indesejados citados anteriormente. O bloqueio consiste
em impedir que dados indesejados entrem no repositório interno do sistema,
enquanto o descarte consiste em retirar os dados indesejados deste repositório
interno. Cada um destes padrões representa um operador da álgebra de eliminação
de dados.
A otimização das consultas desta álgebra é um dos focos de estudo deste
trabalho. O tempo que leva uma consulta dos seus operadores varia de acordo com
diversos fatores, principalmente a quantidade de dados que irá ser processada pelos
mesmos. Há uma maneira de se atenuar o crescimento deste tempo de consulta
através do processo de otimização das consultas realizadas pelos usuários. Isto pode
ser feito usando o otimizador do Secondo, escrito em Prolog2. Como conseqüência
dessa otimização, haverá uma redução do tempo de processamento dos dados.
Outra contribuição deste trabalho será disponibilizar os operadores da álgebra
de eliminação de dados via serviço Web, possibilitando que diversas aplicações
possam se beneficiar desses serviços. A grande vantagem dessa estratégia é que os
operadores de eliminação de dados ficam acessíveis de um modo simples e
independente de plataforma e de localidade.
1
2
http://dna.fernuni-hagen.de/Secondo.html/
http://www.swi-prolog.org/
14
1.2 Caracterização do Problema
Durante o desenvolvimento da álgebra, o tempo de processamento das
consultas não foi considerado como um fator importante. Entretanto, isto pode ser um
requisito essencial em alguns sistemas e aplicações. Portanto, é desejável que as
consultas dos usuários sejam otimizadas para diminuir o seu tempo de
processamento.
A otimização de consultas não é um processo simples. Primeiramente, devese compreender integralmente a álgebra e os operadores utilizados na consulta,
assim como compreender o que cada operador faz e que dados ele manipula. Em
seguida, deve-se estudar a seletividade de cada operador, bem como sua
complexidade. Após alguns testes, deve-se concluir quais operadores são os mais
interessantes, ou seja, menos custosos e mais seletivos. Com esse conhecimento,
chega-se a uma ordem ótima de aplicação dos operadores em cascata sobre um
conjunto de dados que deve ser testada e explicitada na forma de regras. Seguindose esses passos, as consultas desta álgebra estarão otimizadas.
O outro problema é de que forma será disponibilizada esta otimização. Não é
interessante que cada usuário ou aplicação que deseje utilizar os operadores da
álgebra tenha que realizar os procedimentos de instalação do cliente do Secondo
para que tenha acesso aos mesmos. Uma interface mais amigável e que independa
de plataforma é mais viável neste caso. A tecnologia de serviços Web atende a estes
requisitos. Além disso, possui as vantagens de utilizar padrões abertos como HTTP,
SOAP e UDDI, ser mais flexível à alterações realizadas nos componentes e
apresentar um
custo reduzido. Por estes motivos, um serviço Web será o
responsável por essa disponibilização para seus clientes.
Segundo SILVA (2007), serviços Web consistem em uma tecnologia que
permite uma maior integração entre os diversos aplicativos e serviços disponíveis na
Internet. Sua função é disponibilizar serviços para serem acessados por uma
aplicação cliente desenvolvida para consumir o Serviço Web.
Portanto, o trabalho envolve solucionar o problema de otimizar as consultas
sobre esta álgebra, o que será feito após as conclusões teóricas e experimentais
sobre os seus operadores, e disponibilizá-la para os clientes via Serviços Web, em
razão das vantagens de se utilizar esta tecnologia.
15
1.3 Objetivos
O objetivo geral é otimizar as consultas sobre esta álgebra de eliminação de
dados proposta e disponibilizá-la via serviço Web. Como objetivos específicos podem
ser citados:
• Mensurar a seletividade e calcular a complexidade dos operadores de eliminação
de dados;
• Criar regras para otimização das consultas sobre os operadores da álgebra;
• Estender o otimizador do Secondo para a nova álgebra;
• Disponibilizar as consultas otimizadas via Serviços Web.
1.4 Organização do Trabalho
Além do presente capítulo introdutório, este trabalho contém mais 4 capítulos.
O Capítulo 2 trata dos trabalhos relacionados e revisão da literatura. O Capítulo 3,
por sua vez, é dividido em duas partes. A primeira parte se refere ao estudo e
implementação do otimizador, enquanto que a segunda parte trata da implementação
do serviço Web. No Capítulo 4 são apresentados experimentos que validam as
implementações. Por fim, o Capítulo 5 apresenta a conclusão do trabalho e a
sugestão de trabalhos futuros.
16
2 REVISÃO DA LITERATURA
A quantidade de informações recebida pelas pessoas nos dias atuais é muito
maior do que a capacidade das mesmas de assimilá-las, tornando a eliminação de
dados um trabalho árduo, fazendo-se necessárias novas técnicas e ferramentas para
esse fim, todas suportadas por computador. Neste contexto, foi desenvolvido o
Arcabouço Autonômico de Padrões para Eliminação de Dados (PINHEIRO, 2010), o
qual descreve o uso de computação autonômica, conceito introduzido pela IBM
(KEPHARD et al., 2003) e a técnica de criação de regras ativas, através do uso de
redes de Petri de alto nível.
No trabalho atual, busca-se a otimização das consultas realizadas sobre a
álgebra proposta por PINHEIRO (2010). Esta otimização é importante, pois visa
reduzir o tempo de processamento de consultas realizadas pelos usuários. Para
esse fim, foi utilizado o otimizador do SGBD Secondo e realizado um estudo sobre
a complexidade e seletividade dos algoritmos que implementam os operadores.
Após a realização da otimização, os operadores da álgebra de eliminação de
dados serão disponibilizados utilizando serviços Web. Isto permitirá que outras
aplicações utilizem esses operadores de uma maneira mais fácil e simples,
usufruindo das vantagens dos serviços Web.
Serão apresentados neste capítulo os trabalhos relacionados à otimização
das consultas e serviços Web, necessários ao entendimento do restante deste
trabalho.
2.1 SGBD Secondo
O SECONDO é um SGBD extensível capaz de suportar aplicações nãoconvencionais. Ele está sendo desenvolvido na Universidade de Fern, em Hagen,
Alemanha. Ele permite criar ou modificar álgebras existentes e também fornece um
modelo de SGBD genérico que pode ser populado com implementações de vários
tipos de dados extensíveis.
A idéia original do SECONDO foi descrita por GUTING (1993). A primeira
versão (DIEKER; GUTING, 2000) foi construída entre os anos de 1995 e 2001 e
utilizava o sistema SHORE (Scalable Heterogeneous Object REpository) (CAREY ET
17
AL., 1994) como gerenciador de armazenamento, sendo compatível com o sistema
operacional Solaris A versão atual do sistema (GÜTING ET AL., 2004, 2005) usa o
Berkeley DB como gerenciador de armazenamento e é compatível com os sistemas
operacionais Windows, Linux, Solaris e Mac OS X.
O SECONDO possui três componentes principais, que podem ser usados
juntos ou separados. São eles:
•
Núcleo (Kernel): escrito em C++, implementa modelos de dados específicos, é
extensível com o uso de módulos de álgebra e possibilita o processamento de
consultas sobre as álgebras implementadas.
•
Otimizador: escrito em PROLOG tem como funcionalidade principal é a
otimização das consultas. O algoritmo usa estimação de seleção e custo para
produzir bons planos. Adicionalmente, otimiza a parte essencial da linguagem SQL
usando uma notação adaptada ao PROLOG.
•
Javagui: escrita em Java, a Interface Gráfica do Usuário (Graphic User Interface
- GUI), é uma interface extensível a novos tipos de dados e modelos, perfeito para
Bancos de Dados extensíveis como o SECONDO. Além disso, há um visualizador
especial disponível na interface para tipos espaciais e objetos em movimento,
possibilitando uma interface para bancos de dados genérica e sofisticada, incluindo
animação para objetos em movimento.
Atualmente, o SECONDO disponibiliza um conjunto de trinta álgebras, dentro
das quais se destacam:
•
Álgebra Padrão: fornece tipos simples como inteiros, reais, booleanos e strings
junto com suas operações.
•
Álgebra Relacional: fornece tipos e operações para realizar relacionamentos
clássicos em SGBDs.
•
Álgebra Espacial: representa objetos geométricos como pontos, linhas e regiões
junto com operações espaciais.
•
Álgebra Temporal: representa objetos em movimento no BD. Ex: Pessoas ou
veículos. Possibilita que sejam formuladas consultas sobre os movimentos desses
objetos.
18
2.2 Conceitos Voltados à Otimização
2.2.1 Complexidade de algoritmos
O termo complexidade considerado a seguir pode ser interpretado como
complexidade de tempo no pior caso, no melhor caso ou no caso médio.
Deve-se supor que n é o tamanho da entrada de um problema e f é a função
que determina o esforço computacional necessário para resolver o problema usandose certo algoritmo. Se o valor de n é suficientemente pequeno, então qualquer
algoritmo de complexidade f(n) não será custoso. Se o valor de n for suficientemente
grande, pode acontecer que a complexidade f(n) seja muito grande, tornando o
algoritmo impraticável.
Para poder comparar a eficiência de algoritmos em termos de complexidade
para valores de n suficientemente grandes considera-se o comportamento assintótico
das mesmas.
2.2.2 Comportamento Assintótico das Funções
Sejam f, g: N→R, g
domina assintoticamente f, ou
f é dominada
assintoticamente por g, se existe k ≥ 0 e m ≥ 0, tal que |f(n)| ≤ m.|g(n)|, ∀ n ≥ k
O conjunto de todas as funções que são assintoticamente dominadas por uma função g é
notado por:
O(g) ={f : N→R: ∃ c ≥ 0, n0 ∈ N : 0 ≤ f(n) ≤ cg(n), ∀ n ≥ n0}
Exemplos:
a) Sejam f(n) = n e g(n) = n3. Neste caso f é O(g), mas g não é O(f).
b) Sejam f(n) = n e h(n) = 3n. Neste caso f é O(h) e h é O(f).
São classes de comportamento assintótico importantes as dadas a seguir:
1) O (1)
2) O (log2 n)
3) O (n)
4) O (n log2 n)
5) O (nk), k≥2
19
n
6) O (2 )
Dentro deste contexto, podem ser destacados os seguintes teoremas e
corolários importantes:
a) Seja a classe de todas as funções definidas anteriormente. Então para c∈
R, c > 1 e para k∈ N, k > 2, tem-se:
O(1) ⊂ O(log2 n) ⊂ O(n) ⊂ O(n log2 n) ⊂ O(nk) ⊂ O(2n), onde todas as
inclusões são próprias.
b) Sejam c, d∈ R, 0 < c < d. Então O(nc) ⊂ O(nd) e a inclusão é própria.
c) Se P(n) é um polinômio em n de grau k,então:
O((P(n)) ⊂ O(nk).
d) Sejam b, c∈ R, b e c > 1. Então :
O(logb n) = O(logc n)
e) Sejam b, c∈ R, b e c > 1. Então :
O(n logb n) = O(n logc n)
2.2.3 Otimizador do Secondo
O otimizador do Secondo foi escrito em Prolog e é executado no ambiente do
Swi-Prolog, que possui interface com programas escritos em código C. A principal
funcionalidade é a otimização de consultas conjuntivas, isto é, ele toma um conjunto
de relações e um conjunto de seleções e predicados de junção e produz um plano.
Foi comprovado que Prolog é uma excelente linguagem para implementar
otimizadores de consultas. As características de compatibilidade de padrões e a
capacidade de busca do Prolog tornam a formulação das regras de otimização
relativamente fáceis. A execução é bem rápida. Planos para consultas conjuntivas
com até 9 predicados são determinadas em menos de um segundo. A partir de 10
predicados, devido à natureza exponencial do processo, os tempos de otimização
ficam notáveis. Para um sistema experimental como o Secondo, isto é bastante
eficiente.
O otimizador implementa um novo algoritmo para otimização de consultas. Ele
usa estimação de seletividade e de custo para determinar bons planos.
20
No topo da capacidade de otimização de consultas conjuntivas, foi
implementada a parte essencial de uma linguagem do tipo SQL. A notação SQL foi
adaptada para escrever consultas diretamente como termos de Prolog. Um simples
exemplo de interação com o otimizador é mostrado abaixo. É baseado numa relação
Orte contendo 506 cidades na Alemanha e numa relação plz com 41267 pares de
código postal e nome da cidade.
2 ?- sql select count(*) from [orte as o, plz as p1, plz as p2] where [o:ort =
p1:ort, p2:plz = p1:plz + 7, (p2:plz mod 5) = 0, p1:plz > 30000, o:ort contains “o"]
selectivity : 0.000560748
selectivity : 1.6377e-005
selectivity : 0.700935
selectivity : 0.31
Destination node 31 reached at iteration 6
Height of search tree for boundary is 4
The best plan is: Orte feed {o} filter[(.Ort_o contains "o")] loopjoin[plz_Ort plz
exact-match[.Ort_o] {p1} ] filter[(.PLZ_p1 > 30000)] loopjoin[plz_PLZ plz
exactmatch[(.PLZ_p1 + 7)] {p2} ] filter[((.PLZ_p2 mod 5) = 0)] count
Estimated Cost: 66818.7
Command succeeded, result:
273
Yes
3 ?-
2.3 Serviços Web
2.3.1 Motivação
Um dos objetivos do presente trabalho é a disponibilização da álgebra do
Secondo através de Serviços Web, o que permite a utilização dos operadores de
eliminação de dados independentemente da plataforma de operação ou linguagem
utilizada para o desenvolvimento das aplicações que farão uso dos operadores.
21
Dessa forma, o arcabouço autonômico poderá ser utilizado por quaisquer tipos de
usuários, tornando-se amplamente difundido.
2.3.2 Conceito de Serviço Web
Nos últimos anos, as novas tecnologias e arcabouços de desenvolvimento
estão surgindo, permitindo uma maior integração entre os diversos aplicativos e
serviços disponíveis na internet. Este novo paradigma em desenvolvimento deve
tratar tarefas complexas, como o gerenciamento de transações através da
disponibilização de serviços distribuídos que utilizem interfaces de acesso simples e
bem definidas. Esses serviços ou aplicativos distribuídos são conhecidos como
Serviços Web.
Serviço Web pode ser definido como um sistema de software desenvolvido
para dar suporte à interação interoperável, ou seja, com padrões abertos, máquina-amáquina sobre uma rede. Ele possui uma interface descrita em um formato capaz de
ser processado pela máquina (especificamente WSDL). Outros sistemas interagem
com com o serviço Web na maneira prescrita por sua descrição utilizando
mensagens SOAP, tipicamente transportadas usando HTTP com uma serialização
XML em conjunto com outros padrões relacionados à Web (W3C, 2004).
Essencialmente, um serviço Web faz com que os recursos da aplicação do
software estejam disponíveis sobre a rede de uma forma normalizada. Utilizando a
tecnologia, uma aplicação pode invocar outra para efetuar tarefas simples ou
complexas mesmo que as duas aplicações estejam em diferentes sistemas e escritas
em linguagens diferentes. Por outras palavras, os serviços Web fazem com que os
seus recursos estejam disponíveis para que qualquer aplicação cliente possa operar
e extrair os recursos fornecidos por eles.
Os serviços Web são identificados através de uma URI (Unique Resource
Identifier) e são descritos e definidos utilizando-se XML. Um dos motivos que os
tornam atrativos é o fato de serem baseados em tecnologias padrões muito
difundidas na Web, em particular XML e HTTP. Os serviços Web são usados para
disponibilizar serviços interativos na web, podendo ser acessados por outras
aplicações. O SOAP (Simple Object Access Protocol) está se tornando padrão para a
22
troca de mensagens entre aplicações e Serviços Web, já que é uma tecnologia
construída com base em XML e HTTP.
SOAP é um protocolo projetado para invocar aplicações remotas através de
RPC (Remote Procedure Calls- Chamadas Remotas de Procedimento) ou trocas de
mensagens, em um ambiente independente de plataforma e linguagem de
programação. SOAP é, portanto, um padrão normalmente aceito para ser utilizado
com Serviços Web. Desta forma, pretende-se garantir a interoperabilidade e
intercomunicação entre diferentes sistemas, através da utilização de uma linguagem
(XML) e mecanismo de transporte (HTTP) padrões. A Fig. 2.1 representa o
funcionamento de um serviço Web, com os principais protocolos envolvidos.
3
Fig. 2.1: Funcionamento de um Serviço Web
2.3.3
Tecnologias utilizadas
2.3.3.1 XML
XML (Extensible Markup Language) é a base em que os Serviços Web são
desenvolvidos. Ele fornece a descrição, o armazenamento, o formato da transmissão
para trocar os dados através dos serviços e também para criar tais tecnologias para a
troca dos dados.
3
http://www.webmaster.pt/web-services-2694.html
23
A sintaxe XML usada nas tecnologias dos serviços Web especifica como os
dados são representados genericamente, define como e com que qualidades de
serviço os dados são transmitidos e detalha como os serviços são publicados e
descobertos. Os serviços Web descodificam as várias partes de XML para interagir
com as várias aplicações.
2.3.3.2 SOAP
Segundo (W3C, 2007), o SOAP é um protocolo elaborado para facilitar a
chamada remota de funções via Internet, permitindo que dois programas se
comuniquem de uma maneira tecnicamente muito semelhante à invocação de
páginas Web. Ele se baseia em invocação remota de método e para tal necessita
especificar o endereço do componente, o nome do método e os argumentos para
esse método. Estes dados são formatados em XML com determinadas regras e
enviados normalmente por HTTP para esse componente. O SOAP não define ou
impõe qualquer semântica, quer seja o modelo de programação, quer seja a
semântica específica da implementação. Este aspecto é extremamente importante,
pois permite que o serviço e o cliente que invocam o serviço sejam aplicações
desenvolvidas sobre diferentes linguagens de programação. Por esta razão, o SOAP
tornou-se uma norma aceita para se utilizar com Serviços Web. Desta forma,
pretende-se garantir a interoperabilidade e intercomunicação entre diferentes
sistemas, através da utilização da linguagem XML e do mecanismo de transporte
HTTP ou outro como, por exemplo, SMTP. O SOAP permite que os documentos XML
de envio e de recepção sobre a Web suportem um protocolo comum de transferência
de dados para uma comunicação de rede eficaz, ou seja, o SOAP providencia o
transporte de dados para os Serviços Web.
Em relação à Web, o SOAP é um protocolo de RPC que funciona sobre HTTP
de forma a ultrapassar as restrições de segurança(firewalls) normalmente impostas
aos sistemas clássicos de RPC (RMI, DCOM, CORBA/IIOP) suportando mensagens
XML. Em vez de usar HTTP para pedir uma página HTML para ser visualizada em
um navegador, o SOAP envia uma mensagem de XML através de um pedido HTTP e
recebe uma resposta, se existir, através da resposta do HTTP. Para assegurar
corretamente a transmissão da mensagem em XML, o servidor de HTTP, tais como
24
Apache ou IIS (Microsoft Internet Information Server), recebe mensagens SOAP e
deve validar e compreender o formato do documento XML definido na especificação
SOAP v1.1 (W3C, 2007).
Uma mensagem SOAP é constituída pelos seguintes elementos:
1.
Envelope – Presente em toda mensagem SOAP. É o elemento raiz do
documento XML. No envelope podem estar contidas as declarações de namespaces
e atributos adicionais do documento, como os que definem o estilo de codificação;
2.
Cabeçalho (Header) – Cabeçalho opcional da mensagem. Ele guarda
informações adicionais. Se for utilizado, deve ser o primeiro elemento do envelope;
3.
Corpo (Body) – Este elemento é obrigatório e contém carga da
mensagem (payload), ou a informação a ser transportada para o seu destino final.
Além disso, pode conter um elemento opcional Fault, usado para carregar
mensagens de status e erros retornadas pelos nós ao processarem a mensagem.
A Fig. 2.2 representa a arquitetura esquemática de uma mensagem SOAP.
Fig. 2.2: Arquitetura de uma mensagem SOAP
Como ilustração, tem-se a seguinte mensagem SOAP (W3C, 2007):
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
25
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
</m:reservation>
<n:passenger xmlns:n="http://mycompany.example.com/employees"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<n:name>Åke Jógvan Øyvind</n:name>
</n:passenger>
</env:Header>
<env:Body>
<p:itinerary
xmlns:p="http://travelcompany.example.org/reservation/travel">
<p:departure>
<p:departing>New York</p:departing>
<p:arriving>Los Angeles</p:arriving>
<p:departureDate>2001-12-14</p:departureDate>
<p:departureTime>late afternoon</p:departureTime>
<p:seatPreference>aisle</p:seatPreference>
</p:departure>
<p:return>
<p:departing>Los Angeles</p:departing>
<p:arriving>New York</p:arriving>
<p:departureDate>2001-12-20</p:departureDate>
<p:departureTime>mid-morning</p:departureTime>
<p:seatPreference/>
</p:return>
</p:itinerary>
<q:lodging
xmlns:q="http://travelcompany.example.org/reservation/hotels">
<q:preference>none</q:preference>
</q:lodging>
</env:Body>
</env:Envelope>
26
2.3.3.3 WSDL
WSDL (Web Service Description Language) é um documento escrito em XML
(W3C, 2001) que descreve o Serviço Web. Ele especifica a localização do serviço e
as operações (ou métodos) que o serviço disponibiliza.
O WSDL possui os seguintes elementos:
• <types> - Os tipos de dados usados pelo Serviço Web;
• <message> - As mensagens usadas pelo serviço;
• <portType> - As operações realizadas pelo serviço;
• <binding> - Os protocolos de comunicação usados pelo serviço.
Tem-se, a título de exemplo, a seguinte gramática de um documento de
WSDL:
<wsdl:definitions name="nmtoken"? targetNamespace="uri"?>
<import namespace="uri" location="uri"/>*
<wsdl:documentation .... /> ?
<wsdl:types> ?
<wsdl:documentation .... />?
<xsd:schema .... />*
<-- extensibility element --> *
</wsdl:types>
<wsdl:message name="nmtoken"> *
<part name="nmtoken" element="qname"? type="qname"?/> *
</wsdl:message>
<wsdl:portType name="nmtoken">*
<wsdl:operation name="nmtoken">*
<wsdl:input name="nmtoken"? message="qname">?
27
</wsdl:input>
<wsdl:output name="nmtoken"? message="qname">?
</wsdl:output>
<wsdl:fault name="nmtoken" message="qname"> *
</wsdl:fault>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="nmtoken" type="qname">*
<wsdl:operation name="nmtoken">*
<wsdl:input> ?
<-- extensibility element -->
</wsdl:input>
<wsdl:output> ?
</wsdl:output>
<wsdl:fault name="nmtoken"> *
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="nmtoken"> *
28
<wsdl:port name="nmtoken" binding="qname"> *
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
O documento também pode conter outros elementos, como elementos de
extensão e um elemento de serviço que torna possível reunir as definições de vários
Serviços Web em apenas um documento WSDL.
2.3.3.4 UDDI
Protocolo desenvolvido para a organização e registro de Serviços Web.
O UDDI (Universal Description Discovery and Integration) tem o objetivo de
acelerar a interoperabilidade e utilização dos Serviços Web, pela proposta de um
serviço de registro de nomes de organizações e de descrição do serviço.
Um registro UDDI contém três tipos de informação:
• informações gerais de cada organização, tais como o nome, endereço,
telefone e contatos;
• informações de organizações e serviços por categorias de negócios;
• informações técnicas sobre os serviços providenciados pelas organizações.
O UDDI providencia três funções principais, conhecidas como publicação,
descoberta e ligação:
1) Publicação: permite que uma organização divulgue o(s) seu(s) serviço(s);
2) Descoberta: permite que o cliente do serviço procure e encontre um
determinado serviço;
29
3) Ligação: permite que o cliente do serviço possa estabelecer a ligação e
interagir com o serviço.
2.4 Arcabouço Autonômico de Eliminação de Dados
2.4.1 Visão Geral
Geralmente, dentro das organizações, os dados recebem tratamento
ineficiente e são acumulados, gerando despesas e dificultando posterior análise.
Esses dados podem ser provenientes de fontes heterogêneas e apresentar formatos
conflitantes e incompletos. Neste contexto, surgiram técnicas de limpeza de dados e
data warehouses, como uma forma de organizar dados relevantes das organizações
(INMON, 1996; RAHM et al., 2000).
O descarte de dados também é comum na Web e no meio científico
(PINHEIRO, 2010), pois na primeira, além de páginas, existe a troca de mensagens
e documentos. No caso do meio científico, o descarte de dados é encontrado nos
sistemas que devem lidar com sobrecarga de informação.
As considerações anteriores possuem em comum o fato de prover dados
relevantes. A eliminação de dados possui duas estratégias principais, a de seleção e
a de eliminação.
As estratégias de seleção têm como foco os dados mais importantes,
enquanto as estratégias de eliminação têm como foco os dados com pouca ou
nenhuma importância para o contexto requerido.
O trabalho de PINHEIRO (2010) se concentra em cinco categorias de dados
que podem se apresentar em diferentes cenários e estão relacionados à poluição
informacional, sobrecarga de informação e explosão da informação. Na Tab. 1
encontram-se os diferentes cenários e seus significados.
30
Tab. 2.1: Cenários e significados dos padrões de eliminação de dados
Cenário
Significado
Dados
Dados que perderam a relevância em função da
Obsoletos
Dados
Irrelevantes
passagem do tempo
Dados que não possuem conteúdo de interesse
Dados
Dados Proibidos
que
não
devem
estar
presentes
nos
repositórios internos dos sistemas, podendo causar
algum prejuízo caso sejam incluídos ou mantidos
Dados Similares
Dados
Permitidos
Dados que podem possuir mais de uma versão
(similar ou igual)
Dados que devem ser incorporados aos repositórios
internos dos sistemas
O trabalho de PINHEIRO (2010) descreve técnicas utilizadas na descrição
dos Padrões Autonômicos de Eliminação de Dados. Foram elicitados oito padrões,
quais sejam (PINHEIRO et al., 2008b; PINHEIRO et al., 2008c; PINHEIRO et al.,
2009a; PINHEIRO et al., 2009b, PINHEIRO et al., 2010): Padrão Dados Permitidos
(Allowed Data ou AD), Padrão Bloqueador de Dados Proibidos (Blocking Prohibited
Data ou BP), Padrão, Padrão Bloqueador de Dados Similares (Blocking Similar Data
ou BS), Padrão Bloqueador de Dados Irrelevantes (Blocking Irrelevant Data ou BI),
Padrão Eliminador de Dados Proibidos (Discarding Prohibited Data ou DP), Padrão
Eliminador de Dados Similares (Discarding Similar Data ou DS), Padrão Eliminador
de Dados Obsoletos (Discarding Obsolete Data ou DO) e Padrão Eliminador de
Dados Irrelevantes (Discarding Irrelevant Data ou DI).
A criação dos padrões partiu da premissa de que os dados indesejados
podem ser descartados de duas formas:
• Impedindo a sua entrada nos repositórios de interesse, descartando-os
antes mesmo que sejam incorporados às bases de dados dos usuários;
• Eliminando esses dados dos repositórios de interesse, descartando-os
depois que os mesmos estejam incorporados às bases de dados dos usuários.
As próximas seções discutem os padrões apresentados anteriormente.
31
A Fig. 2.3 representa a arquitetura geral do Arcabouço Autonômico de
Padrões para Eliminação de Dados (PINHEIRO, 2010). Através da figura abaixo
podemos ter uma visão ampla do sistema e é possível definir em que parte da
arquitetura foram efetuadas as alterações necessárias para a otimização desejada.
O presente trabalho realizou as seguintes alterações no arcabouço
apresentado anteriormente:
• Na Camada de Comunicação, na Interface para os Padrões de Eliminação
de Dados(ou seja, os operadores), serão otimizadas as consultas sobre os
operadores que são a interface para os Padrões de Eliminação de Dados. Em outras
palavras, será executada a otimização;
• Na Camada de Interface, será desenvolvida uma nova interface (Interfaces
Futuras), para acesso à álgebra com consultas otimizadas.
Fig. 2.3: Arquitetura Geral do Framework de Eliminação de Dados
32
2.4.2 Padrão Dados Permitidos
A aplicabilidade deste padrão é a de permitir a entrada de dados de interesse
para uma organização ou sistema. Os dados não selecionados podem ser
eliminados, atenuando os efeitos da explosão de dados nos repositórios internos.
2.4.3 Padrão Bloqueador de Dados Proibidos
Este padrão impede a entrada de dados probidos ou que possam ser
prejudiciais ao repositório ou ao sistema. Os dados são comparados a alguns termos
antes de serem incorporados aos repositórios internos.
Faz-se necessária a fonte de dados contendo as características dos dados a
serem eliminados e/ou as regras a serem aplicadas na obtenção desses dados,
minimizando, assim, os efeitos da explosão e poluição de dados nos repositórios
internos.
2.4.4 Padrão Bloqueador de Dados Similares
Este padrão é usado para impedir a incorporação de dados similares ou
duplicados em repositórios internos usando certas funções e níveis de similaridade
entre os dados. Os dados que forem similares aos dados internos serão eliminados,
enquanto os demais são incorporados aos repositórios internos.
Caso haja dois dados externos similares entre si, o dado mais relevante é
escolhido. Essa relevância é determinada segundo um critério de escolha que pode
ser dado mais recente, dado contendo nome mais longo, etc. Portanto, este padrão
também minimiza os efeitos de explosão e poluição de dados nos repositórios
internos.
2.4.5 Padrão Bloqueador de Dados Irrelevantes
Este padrão bloqueia a entrada de dados irrelevantes segundo as
necessidades do sistema ou organização que o utilizam. Esses dados irrelevantes
33
podem poluir as informações existentes nos repositórios internos e sobrecarregar os
sistemas que utilizam tais informações.
Os dados são selecionados em função de seus metadados e conteúdo
associados que, por sua vez, são comparados a termos de interesse. Para a
utilização deste padrão, é necessária uma fonte de dados que contenha os dados,
metadados e/ou regras para obtenção dos dados de interesse. Assim como os
padrões vistos anteriormente, este padrão permite minimizar os efeitos da explosão e
poluição de dados nos repositórios internos.
2.4.6 Padrão Eliminador de Dados Proibidos
Este padrão elimina dados considerados proibidos ou que possam causar
algum prejuízo a um repositório, um sistema ou a uma organização. Estes dados
podem ser eliminados definitivamente ou armazenados em um repositório de
descarte. É necessária uma fonte de dados contendo textos, assinaturas, palavraschave e/ou regras que permitem obter dados a serem eliminados. Dessa forma, este
padrão possibilita minimizar os efeitos da sobrecarga e poluição de dados nos
repositórios internos.
2.4.7 Padrão Eliminador de Dados Similares
Este padrão elimina dados similares ou duplicados segundo determinadas
funções e níveis de similaridade entre estes dados. Estes dados podem ser
eliminados definitivamente ou armazenados em um repositório de descarte. Dessa
forma, este padrão possibilita minimizar os efeitos da poluição de dados nos
repositórios internos, além de a eliminação das duplicações facilitar a manutenção da
consistência do repositório, podendo aumentar a velocidade de processamento dos
dados e diminuir o tempo de processamento de consultas.
2.4.8 Padrão Eliminador de Dados Obsoletos
Este padrão pode ser utilizado para eliminar dados que não tenham mais valor
em função da passagem do tempo e do seu período de validade intrínseco. Esses
34
dados, obsoletos, podem ser descartados definitivamente ou armazenados em um
repositório secundário. Podem ser usadas regras adicionais que estabeleçam os
critérios de tempo para identificação dos dados obsoletos por determinada área ou
assunto. Dessa forma, os efeitos da sobrecarga e poluição de dados nos repositórios
internos podem ser minimizados.
2.4.9 Padrão Eliminador de Dados Irrelevantes
Este padrão, se utilizado, elimina dados que não tenham valor em função da
necessidade de um sistema ou das pessoas que o utilizam. Estes dados podem ser
descartados definitivamente ou armazenados em um repositório secundário.
Adicionalmente, podem ser usadas regras que estabeleçam os critérios de
usabilidade por área ou assunto de modo a permitir a identificação desses dados.
Estas regras são baseadas, normalmente, na seleção de valores e intervalos que
indicam os dados de interesse. Dessa forma, este padrão possibilita minimizar os
efeitos da sobrecarga e poluição de dados nos repositórios internos.
2.5 Exemplo do tratamento de dados
Esta seção aborda um exemplo de tratamento de dados tratados pelo padrão
de eliminação AD (PINHEIRO, 2010).
Suponha que o repositório externo contenha marcas que indicam quatro
instâncias de dados, cada uma composta por dois metadados e valores associados,
representando o tópico do dado (topic) e o texto associado a este tópico (text). Todos
estes dados podem conter tópicos de interesse ou não. A Tab. 2.2 fornece um
exemplo para esta situação.
35
Tab. 2.2: Tópicos e textos associados aos dados
Suponha agora que os parâmetros apresentados na Tab. 2.3 foram
declarados, definindo: o metadado que será comparado (topic), os valores de
interesse para este metadado (database e workflow), a função de similaridade a ser
usada na comparação desses valores (Jaccard) e o nível de similaridade mínimo
para que o valor seja considerado de interesse (30%).
Tab. 2.3: Parâmetros a serem utilizados pelo padrão AD
Dessa forma, o dado apresentado na Tab. 2.4 seria descartado, pois não
apresenta nenhuma similaridade com os assuntos de interesse.
36
Tab. 2.4: Dado descartado
Depois de realizado o processamento, os dados mostrados na Tab. 2.5 seriam
transferidos para o repositório interno, pois apresentam nível de similaridade maior
ou igual a 30% com qualquer dos tópicos de interesse.
Tab. 2.5: Dados transferidos para o repositório interno
A seguir, tem-se um exemplo de um tipo de consulta encadeada entre dois
operadores, AD e DP, em que o operador mais interno, AD, na consulta é aplicado
sobre uma massa de dados do Secondo e o mais externo, DP, é aplicado sobre o
resultado da primeira subconsulta realizada por AD :
query(
dp<parametersDP>(
ad<parametersAD>(<dataSecondo>)))
37
3 ESTUDO E IMPLEMENTAÇÃO DO OTIMIZADOR
A otimização de consultas tem sido um tema estudado desde o início de 1970
(CHAUDHURI, 1998). Trata-se do processo de escolha da estratégia adequada para
o processamento das mesmas. Tal estratégia gera o plano físico que é utilizado na
execução da consulta. Destacam-se as seguintes técnicas de otimização para os
SGBDs relacionais:
• Baseadas em regras heurísticas: buscam obter expressões de álgebra
relacional, equivalentes à consulta original, minimizando, não necessariamente de
modo ótimo, o tempo de execução da consulta e a utilização dos recursos de
máquina. De modo geral, procura-se diminuir os resultados intermediários obtidos
nas operações realizadas na consulta. Para isto, estas regras utilizam a reordenação
das operações de consulta. Por exemplo, aplicar as operações de seleção e projeção
antes de aplicar a junção ou outras operações envolvendo mais de uma relação.
• Baseadas em estimativas de custo: utilizam as funções objetivas de custo
para comparar diferentes planos de execução, procurando o plano de menor custo.
Normalmente, estas funções consideram os seguintes fatores: custos de acesso à
memória secundária (pesquisa, leitura, gravação), custos de armazenamento, custo
computacional (sort, merge p/ junção, etc) e custos de comunicação.
Atualmente, é utilizada a combinação das duas técnicas na otimização de
consultas.
Analogamente aos SGBDs relacionais, considerando as técnicas de
otimização apresentadas, duas características podem ser destacadas de modo a
permitir a otimização das consultas realizadas com os operadores de eliminação de
dados:
• Procurar reduzir os resultados intermediários obtidos nas operações
realizadas nas consultas;
• Utilizar antes os operadores com o menor custo de acesso à memória
secundária, custo de armazenamento e custo computacional (sort, merge p/ junção,
etc). O custo de comunicação é considerado o mesmo para todos os operadores de
eliminação de dados.
38
Em PINHEIRO (2010) foram definidos um conjunto de oito operadores de
eliminação de dados, sendo sete unários e um binário (operador Bloqueador de
Dados Similares). Será discutido como as características destacadas anteriormente
podem otimizar a ordem destes operadores quando utilizados em cascata sobre um
mesmo conjunto de dados.
Adaptar o otimizador do Secondo para a nova álgebra incluída requer um
estudo prévio e detalhado dos operadores da álgebra de eliminação de dados. Afinal,
é necessário que o otimizador implemente novas regras para que as consultas
realizadas por esses novos operadores possam ser devidamente otimizadas. A
seção seguinte realizará um estudo aprofundado sobre os operadores desta álgebra
quanto a sua complexidade e seletividade, fatores importantes para a tarefa de
otimização.
3.1 Estudos para otimização
3.1.1 Complexidade dos operadores
Tendo sido apresentadas no capítulo anterior as definições matemáticas
necessárias para o estudo da complexidade algorítmica dos operadores, passaremos
a este estudo propriamente dito.
Foi convencionado como tamanho de entrada: n (para o repositório externo),
m (para o repositório interno) e p (para a lista de parâmetros). Sendo assim,
considerando-se as operações básicas de cada operador descritas no capítulo 2 e
baseado no estudo da complexidade de algoritmos obteve-se como valor das
complexidades dos operadores:
• Operador AD (Dados Permitidos): Basicamente o que esse operador faz
é: ler uma lista de dados no repositório externo (tamanho n), ler uma lista de
parâmetros (tamanho p), comparar os dados armazenados em uma lista (tamanho n)
com os dados da outra lista (tamanho p) um a um, segundo uma função de
similaridade, e enviar os dados considerados permitidos para um repositório interno e
o restante para uma lixeira. Ou seja, a complexidade pode ser calculada pela
complexidade da comparação entre os dados das listas de dados e parâmetros e
39
pode ser expressa por O(np). Aqui é possível considerar a lista de parâmetros
pequena em relação à lista de dados, obtendo uma complexidade O(n).
• Operador BP (Bloqueador de Dados Proibidos): As operações realizadas
pelo BP são: leitura de uma lista de dados no repositório externo (tamanho n), leitura
de uma lista de parâmetros (tamanho p), comparação dos dados armazenados em
uma lista (tamanho n) com os dados da outra lista (tamanho p) um a um, segundo
uma função de similaridade, e envio dos dados considerados proibidos para uma
lixeira e o restante para um repositório interno. Ou seja, a complexidade pode ser
calculada pela complexidade da comparação entre as listas de dados e parâmetros e
pode ser expressa por O(np). Pelos mesmos motivos expostos sobre o operador AD,
pode-se considerar a complexidade sendo O(n).
• Operador BS (Bloqueador de Dados Similares): Este operador é um
pouco mais complexo que os anteriores. Em resumo, ele realiza: leitura de uma lista
de dados no repositório externo (tamanho n), leitura de uma lista de dados no
repositório interno (tamanho m), leitura de uma lista de parâmetros, comparação dos
dados do repositório externo entre si segundo uma função de similaridade,
comparação entre os dados do repositório externo e interno segundo uma função de
similaridade, envio dos dados não-similares para o repositório interno e dos dados
redundantes para a lixeira. Então a complexidade neste caso é calculada levando-se
em conta as duas comparações. É razoável aqui não levar em conta o tamanho da
lista de parâmetros, pois, no caso do operador BS, esta lista contém apenas
informações sobre funções de similaridade e sobre os metadados a serem
comparados, ou seja, a lista de parâmetros não terá nenhum objeto a ser comparado
com as demais listas de dados como ocorre nos operadores AD e BP. Por fim, a
complexidade será de O(n.n + nm)=O(n2 + nm).
• Operador BI (Bloqueador de Dados Irrelevantes): As operações
realizadas pelo BI são: leitura de uma lista de dados no repositório externo (tamanho
n), leitura de uma lista de parâmetros (tamanho p), comparação dos dados do
repositório externo com os parâmetros (como se fosse uma consulta clássica a um
banco de dados sendo que as restrições são definidas pela lista de parâmetros), e
40
envio dos dados considerados proibidos para uma lixeira e o restante para um
repositório interno. Note que esse operador é apenas um caso análogo aos
operadores AD e BP, portanto sua complexidade também é expressa por O(n).
Entretanto, neste caso, não há uso de funções de similaridade nas comparações
entre os dados, o que torna este operador menos custoso do que os que usam estas
funções.
• Operador DP (Eliminador de Dados Proibidos): Este é o primeiro
operador eliminador que será analisado e cita-se como característica de todos eles o
fato de somente se considerar um repositório interno (os dados já estão incorporados
mas precisam ser descartados). No caso do DP ocorre: leitura de uma lista de dados
no repositório interno (tamanho m), leitura de uma lista de parâmetros (tamanho p),
comparação de ambas as listas segundo uma função de comparação e envio dos
dados proibidos para a lixeira. Neste caso, basta calcular a complexidade da
comparação, que é O(mp). Considerando a lista de parâmetros pequena em relação
à lista de dados, obtém-se uma complexidade O(m).
• Operador DS (Eliminador de Dados Similares): O operador DS realiza:
leitura de uma lista de dados no repositório interno (tamanho m), leitura de uma lista
de parâmetros, comparação entre os dados do repositório interno, segundo uma
função de similaridade, e envio dos dados eliminados para a lixeira. Pelo mesmo
motivo citado na explicação sobre o operador BS será desconsiderado o tamanho da
lista de parâmetros no cálculo da complexidade, que será igual à complexidade da
comparação, ou seja, expressa por O(m.m)=O(m2).
• Operador DO (Eliminador de Dados Obsoletos): O operador DO realiza:
leitura de uma lista de dados no repositório interno (tamanho m), leitura de uma lista
de parâmetros, comparação entre os dados do repositório interno e os dados da lista
de parâmetros, e envio dos dados eliminados para a lixeira. Nesse caso a lista de
parâmetros apenas possui um dado que será efetivamente comparado com a lista de
dados do repositório interno, que é a informação sobre a partir de que instante de
tempo (timestamp) os dados passarão a ser aceitos. Então, desconsidera-se o
tamanho da lista de parâmetros e a complexidade deste operador pode ser expressa
41
por O(m). É importante ressaltar que este operador não faz uso de funções de
similaridade.
• Operador DI (Eliminador de Dados Irrelevantes): As operações que esse
operador realiza são: leitura de uma lista de dados no repositório interno (tamanho
m), leitura de uma lista de parâmetros (tamanho p), comparação entre os dados do
repositório interno e os dados da lista de parâmetros e envio dos dados eliminados
para a lixeira. A complexidade é a da comparação, que é O(mp), porém,
considerando-se a lista de parâmetros pequena em relação à lista de dados, obtémse uma complexidade O(m). Similarmente ao operadores BI e DO, este operador não
faz uso de funções de similaridade.
Na análise das complexidades foi considerada até agora uma “implementação
ingênua” para os operadores BS e DS, ou seja, não se cogitou a hipótese de
operações que diminuíssem a complexidade dos algoritmos por meio da ordenação
prévia das listas de dados. A Tab. 3.1 resume as complexidades obtidas, lembrando
que considerou-se sempre que a lista de parâmetros era pequena em relação à lista
de dados dos repositórios interno e externo, o que corresponde à realidade, já que a
massa de dados submetida aos operadores costuma ser muito grande.
Tab. 3.1: Complexidade dos operadores
Operadores
Complexidade
AD
O(n)
BP
O(n)
BS
O(n2+nm)
BI
O(n)
DP
O(m)
DS
O(m2)
42
DO
O(m)
DI
O(m)
No caso do BS e do DS, efetuando-se uma prévia ordenação das listas de
dados, são obtidas como complexidades, respectivamente: O(nlogn+mlogn) e
O(mlogm).
Com a tabela acima já é possível se ter uma noção de quais os operadores de
eliminação mais custosos, o que irá ajudar bastante na otimização, já que ela pode
ajudar a otimizar a ordem destes operadores quando utilizados em cascata sobre um
mesmo conjunto de dados.
A utilização de funções de similaridade torna um operador custoso, visto que o
mesmo deverá preparar os dados a serem comparados, podendo realizar inclusive
os processos de stemming (retorna apenas os radicais das palavras) e extração de
stopwords (palavras geralmente pequenas e de grande ocorrência), demandando
muitas operações de acesso à memória secundária e de armazenamento de
resultados parciais.
Considerando, para efeito de comparação, que tanto o repositório interno
quanto o externo tenham dados de tamanho iguais a “n”, outras considerações
podem ser feitas. Os operadores BI, DI e DO não utilizam funções de similaridade e
apresentam, normalmente, complexidade O(n), sendo por isso os menos custosos.
Os operadores AD, BP e DP podem utilizar funções de similaridade e possuem,
geralmente, complexidade O(n). Os operadores DS e BS podem utilizar funções de
similaridade e possuem complexidade O(n2) numa implementação ingênua e
O(nlogn) numa implementação otimizada, sendo considerados os operadores mais
custosos.
3.1.2 Seletividade dos Operadores
Além de analisar os custos, existe um outro fator muito importante a ser
estudado. Trata-se da seletividade dos operadores. Esta é inversamente proporcional
ao número de tuplas retornado pela consulta. Ou seja, dado um conjunto fixo de
43
tuplas de uma base de dados, a seletividade de um operador é maior quanto menor
for o número de tuplas retornada pela consulta desse operador sobre esse conjunto
de tuplas.
A seletividade influi no tempo de consulta. Para se chegar a essa conclusão,
basta supor que vários operadores sejam aplicados em cascata sobre um conjunto
de dados. Caso os operadores mais seletivos sejam aplicados antes dos menos
seletivos, os resultados intermediários serão menores, facilitando as consultas para
os próximos operadores. O exemplo a seguir ilustra este caso:
Supõe-se que existam 3 operadores e 10000 tuplas, e que os operadores
sejam aplicados em cascata. O primeiro retorna 50% das tuplas, o segundo, 10% e o
terceiro, 20%. Se for aplicado primeiramente o segundo operador, ele retornará
apenas 1000 tuplas. Depois, o terceiro é aplicado, retornando 200 tuplas e, por fim, o
primeiro é aplicado, retornando 100 tuplas. Note que qualquer outra ordem de
aplicação implicaria em resultados intermediários maiores e, como conseqüência, um
maior tempo de processamento das consultas.
Devido ao exposto, foi analisado um estudo experimental sobre o
comportamento dos operadores da álgebra, realizado por PINHEIRO (2010). Este
estudo, sumarizado na Tab. 3.2, permitiu realizar várias estimativas sobre a
seletividade dos operadores e, consequentemente, sobre como obter a redução dos
resultados intermediários.
Pode-se considerar o número de notícias retornado dos operadores como
medida dos resultados intermediários.
Os experimentos realizados fornecem informações importantes sobre três
operadores, relacionando o número de notícias retornadas e o nível de similaridade.
Estes resultados estão sumarizados na Tab. 3.2. Os dados foram obtidos a partir das
curvas características de cada um dos operadores aproximadas para funções de 1º
grau4.
4
Considera-se que as funções de 1º grau fornecem uma aproximação razoável para as curvas características dos operadores
e, ao mesmo tempo, são facilmente tratáveis.
44
Tab. 3.2 : Comportamento dos Operadores AD, DP e DS
Operador
Pontos
Representativos
das Curvas
Número de notícias retornadas
em função do nível de similaridade
y=
Dados Permitidos (1; 11) e (30; 0)
− 11x + 330
, para 0 ≤ x ≤ 30
29
y = 0, para 30 < x ≤ 100
Eliminador de
y=
(1; 90) e (30; 100)
Dados Proibidos
y = 100, para 30 < x ≤ 100
y=
Eliminador de
10 x + 2600
, para 0 ≤ x ≤ 30
29
(4; 88) e (15; 30)
58 x − 100
, para 2 ≤ x ≤ 20
11
y = 100, para 0 ≤ x < 2
Dados Similares
y = 0, para 20 < x ≤ 100 (vide5)
Os dados apresentados na Tab. 3.2 permitiram criar o gráfico comparativo da
Erro! Fonte de referência não encontrada.Fig. 3.1:
5
Na realidade o operador DS sempre retornará pelo menos 1 notícia.
45
Fig. 3.1: Comportamento do Operadores
Pode-se observar que:
• Para 0% < Nível de Similaridade < 3%, o operador DS é o mais seletivo, o
operador AD é o segundo mais seletivo e o operador DP é o menos seletivo;
• Para 3% < Nível de Similaridade < 20%, o operador AD é o mais seletivo, o
operador DS é o segundo mais seletivo e o operador DP é o menos seletivo;
• Para 20% < Nível de Similaridade < 30%, o operador AD é o mais seletivo, o
operador DP é o segundo mais seletivo e o operador DS é o menos seletivo;
• Para 30% < Nível de Similaridade < 100%, o operador AD é o mais seletivo e
os operadores DP e DS têm a mesma seletividade.
Pode-se supor que, por apresentarem comportamento semelhante, o operador
BS possui curva característica similar à curva do operador DS e que o operador BP
possui curva característica similar à curva do operador DP. Dessa forma, os
resultados apresentados anteriormente podem ser estendidos para comportar estes
dois operadores adicionais.
Os operadores DO, DI e BI podem ter suas seletividades estimadas com base
nas seguintes funções de similaridade (SELINGER, ASTRAHAN, ET AL., 1979):
(1) FS ( A = valor ) =
1
card (∏ A ( Dados ))
46
(2) FS ( A > valor ) =
max( A) − valor
max( A) − min( A)
(3) FS ( A < valor ) =
valor − min( A)
max( A) − min( A)
(4) FS ( p ( Ai ) ∧ p ( A j )) = FS ( p ( Ai )) * FS ( p ( A j ))
(5) FS ( p ( Ai ) ∨ p ( A j )) = FS ( p ( Ai )) + FS ( p ( A j )) − FS ( p ( Ai )) * FS ( p ( A j ))
(6) FS ( A ∈ {valores}) = FS ( A = valor ) * card ({valores})
Onde:
FS –
fator de seletividade, ou seja, proporção de dados retornados em
relação ao número de dados de entrada;
A, Ai, Aj – atributo ou metadado de um dado;
valor – valor a ser comparado com os valores do atributo/metadado A;
card (∏ A ( Dados)) – número médio de dados que irão satisfazer uma condição
de igualdade para o atributo/metadado A;
max(A) – valor máximo do atributo/metadado A;
min(A) – valor mínimo do atributo/metadado A;
p(Ai) e p(Aj) – predicados sobre os atributos/metadados Ai e Aj;
card ({valores}) – número de elementos do conjunto {valores}.
O operador DO, em função de suas características, tem seu fator de
seletividade dado pela expressão (2) descrita anteriormente. Os operadores DI e BI,
que possuem comportamentos semelhantes, podem utilizar qualquer das expressões
descritas anteriormente, dependendo da configuração dos seus parâmetros.
3.1.3 Ordem dos Operadores
A reordenação dos operadores é possível, pois similarmente ao operador de
seleção da álgebra relacional, os atributos dos dados operados em cascata são
mantidos, permitindo que os operadores sejam comutados.
Anteriormente, foram apresentadas duas possíveis técnicas a serem utilizadas
na ordenação dos resultados. Estas técnicas discutiram a seletividade dos
operadores (proporção de notícias de saída) e custo (complexidade) considerando
alguns fatores. Estas análises não foram exaustivas, mas forneceram uma noção
47
inicial da ordenação a ser atribuída aos operadores de forma a obter bons planos de
consulta.
A Tab. 3.3 resume a classificação dos operadores quanto à complexidade e o
uso de funções de similaridade, numa implementação não-ingênua.
Tab. 3.3: Classificação dos Operadores
Operador
AD
BP
BS
BI
DP
DS
DO
DI
Complexidade
O(n)
Usa Função de
Similaridade?
Sim
O(n)
Sim
O((n+m)logn)
O(n)
Sim
Não
O(m)
Sim
O(mlogm)
O(m)
Sim
Não
O(m)
Não
A solução visualizada seria aplicar, em cascata, primeiramente os operadores
mais seletivos e menos custosos, e depois os menos seletivos e mais custosos.
Desta forma, nas primeiras operações, como haverá uma grande massa de dados,
seria melhor retornar um número menor de dados (maior seletividade) num tempo
menor (menor custo), de forma a reduzir o custo e também o tamanho dos resultados
intermediários.
A Tabela 3.4 resume as funções que estimam a seletividade dos operadores.
48
Tab. 3.4: Operadores e suas fórmulas de seletividade
OPERADOR
FÓRMULA DE SELETIVIDADE
AD
− 11x + 330
, para 0 ≤ x ≤ 30
29
y=
y = 0, para 30 < x ≤ 100
BP
y=
10 x + 2600
, para 0 ≤ x ≤ 30
29
y = 100, para 30 < x ≤ 100
BS
y=
58 x − 100
, para 2 ≤ x ≤ 20
11
y = 100, para 0 ≤ x < 2
y = 0, para 20 < x ≤ 100
BI
(1) FS ( A = valor ) =
1
(2) FS ( A > valor ) =
max( A) − valor
max( A) − min( A)
(3) FS ( A < valor ) =
valor − min( A)
max( A) − min( A)
DP
y=
10 x + 2600
, para 0 ≤ x ≤ 30
29
y = 100, para 30 < x ≤ 100
DS
y=
58 x − 100
, para 2 ≤ x ≤ 20
11
y = 100, para 0 ≤ x < 2
y = 0, para 20 < x ≤ 100
49
DO
DI
FS ( A > valor ) =
max( A) − valor
max( A) − min( A)
(1) FS ( A = valor ) =
1
(2) FS ( A > valor ) =
max( A) − valor
max( A) − min( A)
(3) FS ( A < valor ) =
valor − min( A)
max( A) − min( A)
Resumidamente, tem-se:
• ordenando do menos complexo para o mais complexo tem-se:
DO = DI = BI < AD = DP = BP < DS < BS
• ordenando do mais seletivo para o menos seletivo:
AD > DI = BI > DO > DP = BP = DS = BS (considerando que, na maior faixa de
similaridade do gráfico de seletividades da figura X, de 30 a 100%, o operador AD é
mais seletivo que DP e DS, os quais possuem seletividades semelhantes no mesmo
intervalo)
A ordem ótima dos operadores (do mais interessante para o menos
interessante) inicialmente adotada, que priorizou o fator seletividade, foi:
AD > DI > BI > DO > DP > BP > DS > BS
Para os casos de operadores que possuem seletividade e complexidade iguais
(DI e BI; DP e BP) foram considerados mais interessantes os operadores de
descarte, que são mais simples por usarem apenas um repositório, ao invés de dois,
no caso dos operadores de bloqueio. Para operadores com seletividades iguais, o
fator complexidade foi usado como diferencial. No capítulo 5 serão feitos testes para
50
descobrir se, de fato, é melhor priorizar a seletividade ou se é melhor priorizar a
complexidade no algoritmo de otimização.
3.1.4 Implementação do Otimizador
Tendo sido definida a ordem ótima dos operadores, é necessário informar ao
otimizador através de regras que, ao ocorrer operações em cascata, a ordem em que
os operadores são aplicados deve respeitar a ordem ótima. Inicialmente foi realizado
um estudo sobre o otimizador do Secondo para verificar a viabilidade de adaptar seu
código em Prolog para que as novas regras fossem incluídas. O subtópico seguinte
apresenta o resultado desse estudo.
3.1.4.1 Estudo da Viabilidade de Adaptação do Otimizador
De acordo com GÜTING ET AL. (2004), o otimizador do Secondo suporta
apenas consultas do tipo SQL, ou seja, ele deveria ser totalmente modificado para
funcionar com a álgebra de eliminação de dados, cujas consultas não possuem uma
sintaxe SQL. Além do fato de o otimizador só trabalhar com consultas SQL-like, ele
apenas considera o fator de seletividade e ignora o fator complexidade para calcular
o melhor plano. O algoritmo usado avalia todos os possíveis planos de consulta e
calcula seus custos, retornando o de menor custo. O problema é que, quanto mais
complexa a consulta, mais planos de consulta haverá, e mais demorado será esse
processo de otimização. Como explicado no capítulo 2, para mais de 10 predicados,
devido à natureza exponencial do algoritmo utilizado, o tempo de otimização torna-se
insatisfatório. Por esse motivo, ao invés de usar ou adaptar a estratégia de
otimização utilizada pelo algoritmo de otimização existente no Secondo, decidiu-se
criar um novo algoritmo para realizar esta função. Para isto, foi feito um desvio na
chamada do algoritmo do otimizador para que seja usado o algoritmo implementado
neste trabalho, quando for utilizada a álgebra de eliminação de dados.
Portanto, na implementação do otimizador para a nova álgebra, não foi
aproveitado o algoritmo já existente do otimizador. Foi implementado um desvio no
otimizador que analisa as consultas e, caso os operadores estejam em cascata, eles
são colocados na ordem ótima já apresentada.
51
3.1.4.2 Modificações Realizadas
Após a decisão de implementar um novo algoritmo para o otimizador, foram
realizadas as alterações no arquivo que constitui o servidor do otimizador do
Secondo. Este servidor é o que recebe do cliente a consulta e a retorna otimizada e é
representado pelo arquivo OptimizerServer.java. Além dele, dois outros arquivos
foram modificados: Command Panel.java e OptimizerInterface.java. O primeiro que
compõe a interface gráfica (GUI) do Secondo e o segundo realiza a comunicação
com o servidor do otimizador. Essa interface gráfica é o cliente do servidor do
otimizador do Secondo e por isso terá que se comunicar com o próprio.
As alterações feitas foram:
1) arquivo CommandPanel.java:
linha:
while((SelectClauseInterval=findSelectClause(command,First))!=null){
alterada para:
if (findSelectClause(command,First)==null){
String opt = OptInt.optimize_execute(command,OpenedDatabase,Err,true);
}
else
while((SelectClauseInterval=findSelectClause(command,First))!=null){
2) arquivo OptimizerInterface.java:
linha:
if(!QUERY.startsWith("SQL")
&&
!QUERY.startsWith("SELECT")
&&
!
&&
!
executeFlag){
ErrorCode.value = ErrorCodes.NO_OPTIMIZATION_POSSIBLE;
return query;
}
alterada para:
if(!QUERY.startsWith("SQL")
&&
!QUERY.startsWith("SELECT")
executeFlag){
ErrorCode.value = ErrorCodes.NO_OPTIMIZATION_POSSIBLE;
52
return query;
}
executeFlag=false;
3) arquivo OptimizerServer.java: O novo código encontra-se disponibilizado na
seção 8.1 devido ao seu tamanho. Basicamente ele divide a string de consulta e a
reordena segundo a ordem ótima dos operadores.
53
4 IMPLEMENTAÇÃO DO WEB SERVICE
Serviços Web podem ser considerados uma solução para reutilização de
código e comunicação entre ambientes heterogêneos. Para que uma tecnologia seja
implementada facilmente, é necessário que sua interface seja simples, de fácil
implementação. Antes do desenvolvimento da tecnologia de serviço Web, a
reutilização de código e comunicação de aplicativos entre ambientes heterogêneos
usavam interfaces proprietárias e complexas (BOARO, 2002).
Uma das razões que tornam serviços Web atrativos, é o fato de este modelo
ser baseado em tecnologias como XML e HTTP, que nada mais são do que a troca
de mensagens em simples arquivos de texto.
Neste contexto, a tecnologia foi estudada e implementada a fim de tornar
disponíveis os operadores da álgebra de eliminação de dados. Nas seções seguintes
será feita uma análise do desenvolvimento da ferramenta.
4.1 Análise da funcionalidade
A Fig. 4.1 representa a arquitetura conceitual do arcabouço desenvolvido por
PINHEIRO (2010). O serviço Web será o responsável por realizar a comunicação
entre o ambiente externo e os componentes do arcabouço, portanto será
desenvolvido na camada de interface.
54
Fig. 4.1: Representação da arquitetura conceitual
4.2 Ferramentas e passos utilizados para o desenvolvimento
Para o desenvolvimento do serviço Web, foram utilizadas as seguintes
ferramentas:
• NetBeans, versão 6.9 – Ambiente de desenvolvimento integrado (IDE);
• Apache Tomcat, versão 6.0.18 – Servidor de aplicação;
• Apache Axis 2 – Framework OpenSource escrito em Java para
desenvolvimento de serviço Web.
55
O desenvolvimento do serviço Web foi iniciado a partir da configuração do
Axis 2 dentro do NetBeans. Este framework é instalado e configurado como um plugin da IDE, como pode ser visto em NETBEANS (2010).
Algumas classes da aplicação FeedOrganizer desenvolvida por PINHEIRO
(2010) foram modificadas a fim de serem reutilizadas para a realização de algumas
das operações do serviço Web.
Concluído o desenvolvimento do programa, é feito o deploy do web service no
servidor de aplicação e, a partir de então, o serviço Web já pode ser encontrado no
servidor, a partir da url http://localhost:8084/axis2/services/listServices, que lista
todos os serviços que foram implantados no servidor. A Fig. 4.2 mostra a página de
apresentação de serviços do Axis.
Fig. 4.2: Página de apresentação dos serviços implantados no servidor
A grande vantagem da utilização do Axis é a geração automática do
documento WSDL a partir do código Java, além do suporte à comunicação SOAP.
O WSDL possui o endereço:
http://localhost:8084/axis2/services/WSoperadores?wsdl
56
A Fig. 4.3 mostra um trecho do arquivo WSDL gerado automaticamente pelo
framework.
Fig. 4.3: Documento WSDL gerado pelo framework Axis 2
4.3 Diagrama de Atividades da operação do serviço Web
Para um melhor entendimento do funcionamento da ferramenta desenvolvida,
foi feita uma análise passo-a-passo da Fig. 4.4, onde são representados os passos
necessários para a utilização do serviço Web.
57
Fig. 4.4: Diagrama de seqüência do serviço Web
A atividade 1 da Fig. 4.4 é o primeiro passo da seqüência de funcionamento da
ferramenta.
O
cliente
invoca
o
método
que
possui
a
assinatura
OperacaoDoWS(String arquivoConfig, String urlFeeds), pertencente à classe WS,
classe de operação do serviço Web.
A seguir, tem-se os parâmetros passados para o método:
•
urlFeeds – Este parâmetro informa para o programa de onde serão
baixados os feeds sobre os quais será realizada a operação de eliminação de dados.
A seguir tem-se um exemplo da string passada como parâmetro:
“http://www.nytimes.com/2010/07/30/nyregion/3rangel.html?_r=1&partner=rss&e
m=rss; http://mediadecoder.blogs.nytimes.com/feed/ ”
No caso do exemplo, foram passados dois endereços para o método. Não há
limites para o número de endereços usados como para parâmetro, porém, tais
58
endereços devem ser separados por ponto-e-vírgula, que serve como delimitador
para que o programa saiba onde ocorre mudança de endereço.
•
arquivoConfig – Este parâmetro informa para o programa quais as
configurações do usuário: grau de similaridade, operadores utlizados, etc. Na seção
8.2 encontra-se um exemplo de arquivo de configuração de usuário. O arquivo
apresentado é serializado e convertido a uma string antes ser passado para o
método.
A atividade 2 do diagrama representa o recebimento dos parâmetros por parte
do serviço Web, logo em seguida o programa realiza o download dos feeds nos
endereços passados através de urlFeeds. Para essa operação, são utlizados
métodos da classe ClasseBaixaFeeds, mostrada na atividade 3.
A seguir, na atividade 4, a classe GeraXMLFeeds faz o tratamento dos feeds,
concatenando todos os feeds em apenas um arquivo XML e estabelecendo um ID
único para cada feed. Após esse tratamento, na atividade 5, o arquivo contendo os
feeds é gerado e enviado, juntamente com o arquivo de configuração contendo os
parâmetros dos operadores da álgebra de eliminação de dados, para o método da
classe GeraXMLUnico, que os concatena (feeds e configuração) em apenas um
arquivo XML. Na atividade 6, esse arquivo concatenado é então passado para o
método da classe ConverteXMLParaSecondo, que converte o arquivo de dados para
o formato do Secondo. Já na atividade 7, esse arquivo é então passado para o
método da classe EnviaRecebeDadosSecondo, que gera a consulta para o Secondo,
de acordo com a configuração do usuário, e recebe os IDs dos feeds filtrados após a
realização da consulta. Essa identificação dos feeds é realizada para facilitar o
retorno das consultas (retorno somente do ID ao invés de todo o feed).
Para finalizar a operação do serviço, na atividade 8, o programa remonta os
feeds, com base nos IDs, e, na atividade 9, os retorna como uma string para o
cliente, depois de serializá-los.
59
Fig. 4.5: Diagrama de Seqüência de interações do Web service
60
Na figura 4.5, tem-se uma representação simplificada da seqüência de
interações do web service. Estão representadas as principais classes na ordem
temporal em que interagem com a classe principal do web service.
61
5 EXPERIMENTOS
5.1 Experimentos relacionados à otimização
Neste experimento foi utilizado um computador com 3,31 GB de memória
RAM, processador Pentium 4, com clock de de 3 Ghz. O computador possui
instalados a interface Msys, o SGBD Secondo (contendo otimizador e interface
gráfica em Java), bem como o arquivo da rede de Petri e o programa em Java, que
realiza stemming e extração de stopwords.
Com relação à preparação do ambiente, antes de iniciar os experimentos
propriamente ditos, foram realizados os seguintes passos:
1)
3 janelas do Msys foram abertas;
2)
Na primeira delas, foi digitado cd secondo/bin e em seguida
SecondoMonitor –s. Este procedimento deixa o servidor do Secondo “ escutando ” as
requisições;
3)
Na segunda janela, foi digitado cd secondo/Optimizer, e depois
StartOptServer. Este procedimento inicia o servidor do otimizador do secondo, que
fica pronto para atender às requisições
4)
Na terceira janela, foi digitado cd secondo/Javagui e em seguida sgui.
Este procedimento abre a interface gráfica do Secondo, que será cliente do servidor
do otimizador e repassará para este as consultas a serem otimizadas. Em seguida, o
servidor do otimizador encaminhará as consultas já otimizadas para o kernel do
Secondo, que as executará;
5)
Foi aberto o arquivo *.cpn, que corresponde à rede de Petri dos
operadores da álgebra de eliminação e liga-se a rede;
6)
Foi iniciada a rede de Petri que contém os operadores de eliminação de
dados (foi usado o fast forward com um número de 100.000 passos, ou ciclos);
7)
Foi iniciado o programa que realiza stemming e extração de stopwords.
A partir daqui basta entrar com a consulta desejada, não esquecendo de abrir
primeiramente o banco de dados correspondente.
Na descrição dos passos acima, considerou-se que o algoritmo de otimização
já estava implementado. Ele pode ser modificado para priorizar seletividade ou
62
complexidade. Basta para isso editar o arquivo OptimizerServer.java localizado em
secondo/OptServer/30 e depois executar o comando make neste diretório. Em
seguida, deve-se reiniciar o servidor do otimizador e executar novamente a interface
gráfica. As ordens em que os operadores podem ser aplicados então são:
• AD > DI > BI > DO > DP > BP > DS > BS (prioridade ótima, considerando o
fator seletividade, como explicado na seção 3.1.2, atendendo à restrição de
considerar a maior faixa de similaridade do gráfico da figura 3.1);
• DI > BI > DO > AD > DP > BP > DS > BS (prioridade ótima, considerando o
fator complexidade, como explicado na seção 3.1.3);
• Ordem original da consulta (quando opta-se por não realizar a otimização).
5.2 Testes do otimizador
O teste a seguir foi realizado sobre um banco de dados que possui 49 notícias
e se encontra disponibilizado em arquivo digital anexo a este trabalho. A seguinte
consulta, contendo 7 dos 8 operadores da álgebra, foi executada:
•
(query (ad r1 (dp r3 (bp r4 (do r9 (bi r5 (ds r6 (bs r7 r2 r100))))))))
Vale ressaltar que o único operador não utilizado nesta consulta foi o DI. Não
se sabe o porquê de ter havido problemas na consulta quando se utilizava este
operador. Os parâmetros utilizados para cada operador foram, resumidamente:
• AD: Estratégia de similaridade Jaccard, com coeficiente de 1%;
Metadado comparado: title;
Palavras permitidas: nuclear, regulators, mexico, europe, school,
stories, earth, teams, books, lab, judge, gulf, oil, leak, power, student, predators,
moon, paciffic.
• DP: Estratégia de similaridade Jaccard, com coeficiente de 1%;
Palavras permitidas: forensics, spain.
• BP: Estratégia de similaridade Jaccard, com coeficiente de 1%;
Palavras permitidas: pollution, range.
63
• DO: Estratégia de similaridade Jaccard, com coeficiente de 1%;
Metadado comparado: dataTimestamp;
Period TimeStamp: 6 dias;
Current TimeStamp: 2/8/2010 12:30hrs.
• BI: Estratégia de similaridade Jaccard, com coeficiente de 1%;
Condição: title = mystery OR type = national.
• DS: Estratégia de similaridade Jaccard, com coeficiente de 15%;
Metadado comparado: title.
• BS: Estratégia de similaridade Jaccard, com coeficiente de 1%;
Repositório externo: r2.
Após a execução da consulta, para a descoberta do tempo gasto com a
mesma, executou-se outra consulta: query SEC2COMMANDS. Logo após, verificouse o campo CPUTime. A seguir são apresentados estes resultados:
1)
Pior ordem por seletividade:
Consulta:
(query (ad r1 (bi r5 (do r9 (dp r3 (bp r4 (ds r6 (bs r7 r2 r100))))))))
Tempo medido: 9,016 segundos.
2)
Melhor ordem por seletividade:
Consulta:
(query (bs r7 r2 (ds r6 (bp r4 (dp r3 (ad r1 (do r9 (bi r5 r100))))))))
Tempo medido: 3,532 segundos
3)
Pior ordem por complexidade:
Consulta:
(query (bi r5 (do r9 (ad r1 (dp r3 (bp r4 (ds r6 (bs r7 r2 r100))))))))
64
Tempo medido: 8,359 segundos.
4)
Melhor ordem por complexidade:
Consulta:
(query (bs r7 r2 (ds r6 (bp r4 (dp r3 (ad r1 (do r9 (bi r5 r100))))))))
Tempo medido: 4,297 segundos
Os tempos medidos para essas consultas, bem como o número de notícias de
entrada e saída, estão resumidos na Tab. 5.1, e a forma como eles são obtidos na
interface gráfica do Secondo está ilustrada na Fig. 5.1:
Tab. 5.1: Tempos medidos para a consulta
Número de Número de
Tempo de
Ordem dos operadores Noticias de Notícias de
Consulta
na consulta
(em segundos)
Pior ordem por
seletividade
Otimizada por
seletividade
Pior ordem por
complexidade
Otimizada por
complexidade
Entrada
Saída
49
9
9,016
49
9
3,532
49
9
8,359
49
9
4,297
65
Fig. 5.1: Interface gráfica do Secondo
Os testes realizados retornaram o esperado, ou seja, a consulta não-otimizada
levou um tempo maior que as que foram otimizadas. Os tempos de processamento
das 3 consultas foram relativamente próximos. Espera-se que para uma maior massa
de dados estes aumentem. Não foi possível concluir qual é o melhor método de
otimização: por seletividade ou por complexidade. Provavelmente o tempo gasto pela
consulta original fornecida pelo usuário foi próximo ao das consultas otimizadas pelo
fato de que a ordem dos operadores nesta consulta era já próxima de uma ordem
ótima.
66
5.3 Experimento relacionado ao serviço Web
Esta seção aborda o experimento realizado através da utilização dos
operadores de eliminação de dados disponibilizados pelo serviço Web.
Como foi visto na seção 4.3, o método principal do serviço Web recebe como
parâmetros a configuração do usuário em relação aos operadores que deseja utilizar
(assim como o coeficiente de similaridade, a estratégia de similaridade desejada,
etc) e as urls dos feeds sobre os quais realizará a operação de eliminação de dados.
5.3.1 Acesso ao serviço e passagem dos parâmetros
Para o experimento, a massa de dados utilizada foram os feeds que se
encontram hospedados nas seguintes urls:
• http://feeds1.nytimes.com/nyt/rss/Sports, e
• http://www.guardian.co.uk/business
O cliente utilizado para consumir o serviço foi o próprio navegador Web
instalado no computador, Internet Explorer 7, onde através da barra de endereços foi
passado o endereço da operação do serviço Web juntamente com seus parâmetros.
Na seção 8.2 encontra-se o arquivo utilizado como parâmetro de configuração
para este experimento.
O trecho abaixo representa a url utilizada para o consumo do serviço, onde a
palavra “textoConfig” substitui a string de configuração mostrada na seção 8.2,
apenas para facilitar o entendimento da url.
http://localhost:8084/axis2/services/WSoperadores/OperacaoDoWS?arquivoCo
nfig=textoConfig&urlFeeds=http://feeds1.nytimes.com/nyt/rss/Sports;http://www.gua
rdian. co.uk/business
67
5.3.2 Análise do experimento
Após a chamada ao método do serviço Web, com os parâmetros já citados, é
obtido o seguinte retorno, mostrado na Fig. 5.2:
Fig. 5.2: Feeds retornados pelo Web service
A massa de dados era composta, ao todo, por 49 feeds. Após a operação,
foram retornados apenas 3 feeds.
Como pode ser visto, os 3 feeds retornados possuem a palavra “Players” em
seu título, pois essa foi a palavra utilizada como configuração do usuário, a ser
buscada nos títulos dos feeds, com a aplicação do operador AD.
Portanto, pode-se constatar a correta operação do serviço Web, ao
disponibilizar os operadores da álgebra de eliminação de dados.
68
5.3.3 Forma alternativa de desenvolvimento do cliente
Como foi visto na seção 5.3.2, o cliente usado para consumir o serviço foi o
navegador instalado na máquina. Porém, os clientes podem ser aplicações
desenvolvidas em quaisquer linguagens. Na seção 8.3, encontra-se um exemplo de
cliente, desenvolvido na IDE Eclipse e que utiliza métodos de invocação de serviço
pertencentes ao framework Axis.
69
6 CONCLUSÃO
Este trabalho, após diversos estudos realizados sobre o SGBD Secondo e o
seu funcionamento, os fundamentos de Serviços Web, bem como sobre a álgebra de
eliminação de dados descrita em PINHEIRO (2010), cumpriu os objetivos definidos
inicialmente, quais sejam: otimização das consultas realizadas sobre a álgebra de
eliminação de dados e disponibilização dos seus operadores via Serviços Web.
As conclusões a que se chegou foi que os fatores seletividade e
complexidade dos operadores da álgebra realmente têm relação com a ordem ótima
dos operadores quando aplicados em cascata sobre uma massa de dados. Após
alguns testes, também foi verificado que não existe um método melhor de
otimização. Tanto complexidade quanto seletividade podem alcançar um tempo
menor de processamento da consulta, dependendo desta.
A disponibilização via Serviço Web provou ser eficaz e provê uma maior
facilidade de acesso aos operadores. Além do mais, essa tecnologia apresenta as
vantagens já apresentadas, como o fato de ser independente de plataforma e
bastante flexível a alterações.
Por fim, o produto deste trabalho é uma álgebra mais acessível e que
economiza tempo de consulta, características bastante desejáveis para qualquer
usuário.
6.1 Trabalhos Futuros
O presente trabalho consistiu em otimizar as consultas sobre a álgebra de
eliminação de dados. As heurísticas foram modeladas em Java e aplicadas para a
otimização. No futuro elas podem ser modeladas em Prolog, que era o objetivo
inicial, mas que foi modificado em razão do fato de o algoritmo de otimização já
existente ser de complexidade alta.
O otimizador adaptado para a álgebra de eliminação de dados pode ser
estendido com a criação de novas regras que busquem a redução do tempo das
consultas. Já foi visto que os fatores seletividade e complexidade influem na
ordenação dos operadores em cascata, mas pode ser descoberto um novo fator que
70
também tenha influência
nesta ordenação. Um exemplo é o coeficiente de
similaridade, pois foi visto no gráfico da figura 3.1 que a seletividade varia em função
deste coeficiente.
A álgebra pode também ser estendida com a criação de novos operadores,
mais seletivos e menos custosos que os já existentes. Obviamente, o otimizador
receberia novas regras para tratar esses novos operadores.
Já o Serviço Web deve ser atualizado com a introdução dos novos
operadores que venham a surgir na álgebra, bem como outras modificações
significativas na álgebra.
Um artigo envolvendo o estudo dos operadores da álgebra no que tange à
seletividade e complexidade está sendo desenvolvido para futura publicação.
71
7 REFERÊNCIAS
PINHEIRO, W. A. Arcabouço Autonômico de Padrões para Eliminação de
Dados. 2010. 240 f. Tese (Doutorado em Ciências em Engenharia de Sistemas e
Computação) - Programa de Pós-graduação em Engenharia de Sistemas e
Computação, COPPE, Universidade Federal do Rio de Janeiro, Rio de Janeiro.
SILVA, R. O. Estudo de Web Services. 2007. 43 f. Tese (Graduação em Sistemas
de Informação) - Instituto de Ciências Administrativas e de Informática, Faculdades
Integradas de Mineiros, Mineiros, Goiás.
KEPHARD, J., CHESS, D., 2003, The Vision of Autonomic Computing, In: IEEE
Computer Society.
GÜTING, R.H., 1993, "Second-order signature: a tool for specifying data models,
query processing, and optimization", SIGMOD Rec., v. 22, n. 2 (1993), pp. 277-286.
DIEKER, S., GUTING, R., 2000, Plug and play with query algebras: SECONDO, a
generic DBMS development environment, In: Database Engineering and Applications
Symposium, 2000 International, pp 380-390.
CAREY, M.J., DEWITT, D.J., FRANKLIN, M.J., et al., 1994, "Shoring up persistent
applications", SIGMOD Rec., v. 23, n. 2 (1994), pp. 383-394.
Site do W3C. Disponível em: <http://www.w3.org/TR/>
Acesso em: 31 mar. 2010.
Site do W3C. Disponível em: <http://www.w3.org/TR/soap/>
Site do W3C. Disponível em: < http://www.w3.org/TR/wsdl/>
72
CHAUDHURI, S., 1998, “Extracting predicates from mining models for efficient
query evaluation”.
GÜTING,
R.H., 2004, "SECONDO:
An
Extensible
DBMS
Architecture
and
Prototype", Informatik Report 313, FernUniversität Hagen, 2004.
Site
sobre
Serviços
Web.
Disponível
em:
<http://www.linhadecodigo.com.br/artigo/60/web-services.aspx> Acesso em: 20 jul.
2010.
Site sobre Serviços Web. Disponível em: <http://netbeans.org/kb/docs/websvc/gsaxis.html> Acesso em: 2 jul. 2010.
[1] Site do Secondo. Disponível em: <http://dna.fernuni-hagen.de/Secondo.html>
Acesso em: 8 dez. 2009.
[2] Site do Prolog. Disponível em: <http://www.swi-prolog.org/> Acesso em: 20 jan.
2010.
[3] Site
com
informações
sobre
Serviços
Web.
Disponível
<http://www.webmaster.pt/web-services-2694.html> Acesso em: 20 nov. 2009.
73
em:
8 ANEXOS
8.1 Porção do código do OptimizerServer.java relativa à otimização
public void escreve(String x, String arq){
try{
BufferedWriter
bw
=
new
BufferedWriter(new
FileWriter("c:\\msys\\1.0\\home\\professor\\secondo\\" + arq + ".txt"));
bw.write(x);
bw.close();
}catch(IOException e){}
}
/** return the optimized query
* if no optimization is found, query is returned
* otherwise the result will be the best query plan
*/
private synchronized String optimize(String query){
//System.out.println("optimize called with argument \""+query+"\"");
try{
if(trace){
System.out.println("\n optimization-input : "+query+"\n");
}
escreve(query, "a_opt"); //linha inserida
Vector<String> v = new Vector<String>();
Vector<Integer> w = new Vector<Integer>();
Vector<String> q = new Vector<String>();
int count = 0;
74
if (query.contains("(ad ")){
w.add(query.indexOf("(ad "));
count++;
}
if (query.contains("(di ")){
w.add(query.indexOf("(di "));
count++;
}
if (query.contains("(bi ")){
w.add(query.indexOf("(bi "));
count++;
}
if (query.contains("(do ")){
w.add(query.indexOf("(do "));
count++;
}
if (query.contains("(dp ")){
w.add(query.indexOf("(dp "));
count++;
}
if (query.contains("(bp ")){
w.add(query.indexOf("(bp "));
count++;
}
if (query.contains("(ds ")){
w.add(query.indexOf("(ds "));
75
count++;
}
if (query.contains("(bs ")){
w.add(query.indexOf("(bs "));
count++;
}
w.add(query.lastIndexOf("r"));
for (int i=0; i<w.size(); i++){
if (w.get(i)==-1) w.remove(i);
}
Collections.sort(w);
for (int i=0; i<w.size(); i++){
if (i!=(w.size()-1))
v.add(query.substring(w.get(i), w.get(i+1)-1));
else {
v.add(query.substring(w.get(i), query.length()-1));
}
}
for (int i=0; i<v.size(); i++){
escreve(v.get(i),"a_substring" + i);
}
for (int i=0; i<8;i++){
q.add(i, "");
}
for (int i=0; i<v.size(); i++){
76
if (v.get(i).contains("(bs ")) q.set(0, " " + v.get(i));
if (v.get(i).contains("(ds ")) q.set(1, " " + v.get(i));
if (v.get(i).contains("(bp ")) q.set(2, " " + v.get(i));
if (v.get(i).contains("(dp ")) q.set(3, " " + v.get(i));
if (v.get(i).contains("(do ")) q.set(4, " " + v.get(i));
if (v.get(i).contains("(bi ")) q.set(5, " " + v.get(i));
if (v.get(i).contains("(di ")) q.set(6, " " + v.get(i));
if (v.get(i).contains("(ad ")) q.set(7, " " + v.get(i));
}
int count = 1; //otimizaSeletividade
//int count = 2; //otimizaComplexidade
//int count = 3; //não otimiza
if (count==1){
String query_final = "(query" + q.get(0) + q.get(1) + q.get(2) + q.get(3) +
q.get(4) + q.get(5) + q.get(6) + q.get(7) + " " + v.lastElement()+")";
query = query_final;
}
if (count==2){
String query_final = "(query" + q.get(0) + q.get(1) + q.get(2) + q.get(3) +
q.get(7) + q.get(4) + q.get(5) + q.get(6) + " " + v.lastElement()+")";
query = query_final;
}
escreve(query,"a_opt_query_final");
if(trace){
System.out.println("\n optimized query : "+query+"\n");
}
} catch(Exception e){
if(trace)
77
System.out.println("\n Exception :"+e);
showPrompt();
}
return query;
}
8.2 Arquivo de Configuração do usuário
<dados_usuarios>
<visitante>
<config>
<operadores>
<AD_titulo>
<ativo>true</ativo>
<palavras>player</palavras>
<funcao_similaridade>Jaccard</funcao_similaridade>
<similaridade>1</similaridade>
<stopwords>false</stopwords>
<stemming>false</stemming>
<feed_language>english</feed_language>
<feed_order>no</feed_order>
</AD_titulo>
<AD_descricao>
<ativo>false</ativo>
<palavras>Department torture Central Park</palavras>
<stopwords>false</stopwords>
<stemming>false</stemming>
<feed_language>english</feed_language>
</AD_descricao>
78
<AD_autores>
<autores/>
<funcao_similaridade/>
<similaridade/>
<stopwords/>
<stemming/>
<feed_language/>
<feed_order/>
</AD_autores>
<DP_titulo>
<palavras>Basketball Recruiting Rays</palavras>
<stopwords/>
<stemming/>
<feed_language/>
<feed_order/>
</DP_titulo>
<DP_descricao>
<palavras/>
<similaridade/>
<stopwords/>
<stemming/>
<feed_language/>
<feed_order/>
</DP_descricao>
<DP_autores>
<autores/>
79
<similaridade/>
<stopwords/>
<stemming/>
<feed_language/>
<feed_order/>
</DP_autores>
<DS_titulo>
<similaridade/>
<stopwords/>
<stemming/>
<feed_language/>
<feed_order/>
</DS_titulo>
<DS_descricao>
<similaridade/>
<stopwords/>
<stemming/>
<feed_language/>
<feed_order/>
</DS_descricao>
<DO>
<data_inicial/>
<data_atual/>
<feed_order/>
</DO>
<DI_endereco>
80
<enderecos/>
</DI_endereco>
<DI_categoria>
ativo>false</ativo>
<categorias/>
<feed_order/>
</DI_categoria>
</operadores>
</config>
</visitante>
</dados_usuarios>
8.3 Cliente alternativo para a invocação do serviço
import org.apache.axis.client.Call;
import org.apache.axis.client.Service;
public class Cliente {
/**
* @param args
*/
public static void main(String[] args) throws Exception {
String local = "http://localhost:8084/axis2/services/WSoperadores";
Call call = (Call) new Service().createCall();
call.setTargetEndpointAddress(local);
call.setOperationName("OperacaoDoWS");
String strDados = "dados_config"; //dados_config representa as
configurações do usuário
String strUrl = "urls_feeds"; //urls_feeds representa as urls dos
feeds
Object[] param = new Object[]{new String(strDados),new
String(strUrl)};
String ret = (String)call.invoke(param);
System.out.println("Resultado da filtragem : " + ret);
}
}
81

Otimização E Disponibilização De Operadores De - SE/8

Transcrição

Documentos relacionados

Introd. Prog. Java com NetBeans

guia de atividades

Circuitos Lógicos Aula 6

isotat - home page

Instituto OPUS

- Maclinea

Protecção do Consumidor, Privacidade e Segurança de

The Disciplined Trader - Monitor Investimentos

Jessica Tais Barreto Jorge

Circuitos Lógicos Aula 7