UNIVERSIDADE CATLICA DO SALVADOR CURSO DE BACHARELADO EM INFORMTICA

INDEXAO E PESQUISA UTILIZANDO O APACHE LUCENE E O HIBERNATE SEARCH: UMA ABORDAGEM COMPARATIVA COM FERRAMENTAS EXISTENTES.

LUCIANA SANTANA FERREIRA

SALVADOR 2010

UNIVERSIDADE CATLICA DO SALVADOR CURSO DE BACHARELADO EM INFORMTICA

LUCIANA SANTANA FERREIRA

Monografia apresentada para a disciplina Projeto Final do curso de Bacharelado em Informtica, da Universidade Catlica do Salvador, sob a orientao do Prof. Osvaldo Requio Melo.

SALVADOR 2010

CERTIFICADO

Certifico que a presente memria, que a monografia INDEXAO E PESQUISA UTILIZANDO O APACHE LUCENE E O HIBERNATE SEARCH: UMA ABORDAGEM COMPARATIVA COM FERRAMENTAS EXISTENTES foi realizada, sob minha direo, por LUCIANA SANTANA FERREIRA, constituindo o Projeto Final de Curso de Bacharelado em Informtica da Universidade Catlica do Salvador UCSAL.

Salvador, 08 de setembro de 2010

____________________________________ Osvaldo Requio Melo Curso de Bacharelado em Informtica Universidade Catlica do Salvador

AGRADECIMENTOS

Agradeo primeiramente a Deus pela Sua bondade e fidelidade. Agradeo a Ele pela vida e pela permisso de concluir o curso de graduao. Com certeza sem Ele nada poderia fazer.

Agradeo a meus pais, por me proporcionarem estar aqui e me ajudarem na minha construo pessoal e a meus irmos pelo apoio em todos os momentos da minha vida.

Um agradecimento especial ao meu amigo Juvenal Fonseca, pela grande ajuda elaborao dessa monografia.

Agradeo a pacincia e auxlio dado pelo professor Osvaldo Requio que muito me ajudou e orientou nos momentos mais difceis durante esse projeto.

RESUMO
Este trabalho realiza uma anlise comparativa entre o prottipo desenvolvido utilizando o Apache Lucene e softwares de indexao gratuitos Google Desktop e Windows Search. O desenvolvimento de uma nova aplicao para comparar com ferramentas j existentes surge pelo fato de que os softwares indicados foram criados para uso genrico enquanto que este novo programa poderia estar mais sintonizado com o ambiente para o qual se destina ligado empresa e utilizando acesso ao banco de dados de uma organizao, por exemplo. Para a anlise comparativa foram levadas em considerao a relevncia dos registros retornados e o tempo de busca.

Palavras chave: Recuperao de informao, Indexao, Busca, Lucene, Google Desktop, Windows Search, Hibernate Search.

ABSTRACT
This work makes a comparative analysis of the prototype of a tool developed using the Apache Lucene indexing software and free Google Desktop Search and Windows Search. The development of a new application to compare with existing tools arises from the fact that the software packages were created for general use while the new program could be more attuned to the environment which is designed on the company and using database access of an organization's data, for example. For the comparative analysis were considered the relevance of records returned and the search time.

Keywords: Information Retrieval, Indexing, Search, Lucene, Google Desktop, Windows Search, Hibernate Search.

SUMRIO
INTRODUO ......................................................................................................... 11

1. WEB SEMNTICA .............................................................................................. 14 1.1. Arquitetura da Web Semntica ..................................................................... 16 1.2. Padro RDF .................................................................................................. 19 1.3. Linguagem XML ........................................................................................... 23 1.4. Funcionamento da Web Semntica ............................................................. 25

2. RECUPERAO DA INFORMAO ................................................................. 30 2.1. Modelos de Recuperao ............................................................................. 31 2.2. Sistemas de Busca ....................................................................................... 35 2.2.1. Diretrios (Directory) ......................................................................... 36 2.2.2. Mecanismos de Busca (Search Engine) ........................................... 36 2.2.3. Metabuscadores ............................................................................... 37 2.2.4. Software de Busca ............................................................................ 37 2.2.5. Problemas e limitaes dos atuais Sistemas de Busca .................... 38 2.3. Indexao ..................................................................................................... 38 2.3.1. Etapas da Indexao ........................................................................ 40 2.3.1.1. Tokenize ............................................................................. 40 2.3.1.2. Analysis .............................................................................. 41 2.3.1.3. Stemming ............................................................................ 42

3. MOTORES DE INDEXAO E BUSCAS ........................................................... 44 3.1. Lucene .......................................................................................................... 44 3.1.1. Estrutura de ndice do Lucene ............................................................ 45 3.1.2. Processo de Indexao do Lucene ..................................................... 46 3.1.3. Processo de Busca do Lucene ........................................................... 48 3.1.4. Processo de Remoo e Substituio do ndice no Lucene .............. 49 3.1.5. Exemplos de Aplicao com Lucene .................................................. 49 3.2. Windows Search ........................................................................................... 50 3.3. Google Desktop Search 52

4. PROTTIPO .. 56 4.1. Ferramentas Utilizadas ................................................................................ 57 4.2. Diagramas de Requisitos ............................................................................. 59 4.2.1. Diagrama de Caso de Uso................................................................ 59 4.2.2. Diagrama Classes ............................................................................ 60 4.2.3. Diagrama de Pacotes ....................................................................... 61 4.3. Estrutura de Pacotes..................................................................................... 62 4.4. Operao com Hibernate...... 62 4.5. Operaes com Lucene................................................................................ 64 4.6. Testes .. 66 4.6.1. Processo de Indexao ................................................................. 67 4.6.2. Processo de Busca ....................................................................... 69 4.6.3. Tempo de Pesquisa ....................................................................... 71 4.6.4. Pesquisa em Banco de Dados ...................................................... 73 4.6.5. 4.6.6. Tipos de Dados Indexados ........................................................... 75 Resultados dos Testes ................................................................. 76

CONCLUSO ........................................................................................................... 77

REFERNCIAS BIBLIOGRFICAS ......................................................................... 80 APNDICE I PRINCIPAIS CLASSES.................................................................... 82 Classe Arquivo ...................................................................................................... 82 Classe Autor .......................................................................................................... 82 Classe AutorDao ................................................................................................... 83 Classe LuceneDao ................................................................................................ 84 Classe LuceneFaces ............................................................................................. 86 APNDICE II CONFIGURAES......................................................................... 89 Configurando o Hibernate Search em um Projeto Hibernate ................................ 89 Mapeamento de Classe utilizando o Hibernate ..................................................... 90

LISTA DE FIGURAS
Figura 1 - Camadas da Web Semntica....................................................................16 Figura 2 - Representao de uma sentena por grafo..............................................21 Figura 3 - Estrutura do documento RDF utilizando elementos do Dublin Core.........23 Figura 4 - Trecho de cdigo utilizando XML..............................................................25 Figura 5 - Um trio de RDF tem um sujeito (Anakin Skywalker), um objeto (Luke Skywalker) e uma propriedade que une os dois........................................................26 Figura 6 - Um URI d ao computador um ponto de referncia especfico para cada item do trio..................................................................................................................27 Figura 7 - Exemplo de um nmero pequeno dos recursos e conexes que podem ser encontrados na ontologia Star Wars .........................................................................28 Figura 8 - Taxonomia de modelos de RI....................................................................32 Figura 9 - Texto separado em Tokens aps execuo do analisador lxico.............41 Figura 10 - Texto separado em Tokens aps execuo do analysis.........................42 Figura 11 - Texto separado em Tokens aps execuo do stemming......................43 Figura 12 - Estrutura do ndice do Lucene.................................................................45 Figura 13 - Interface do Google Desktop Enterprise..................................................53 Figura 14 - Diagrama de Caso de Uso do prottipo...................................................59 Figura 15 - Diagrama de Classes do prottipo...........................................................60 Figura 16 - Diagrama de Pacote do prottipo............................................................61 Figura 17 - Trecho do cdigo da Classe AutorDao....................................................63 Figura 18 - Mtodo que pesquisa autores atravs dos ndices criados.....................63 Figura 19 - Trecho do cdigo da Classe Abstrata Dao..............................................64 Figura 20 - Mtodo que indexa arquivos utilizando o Lucene....................................64 Figura 21 - Mtodo que pesquisa arquivos utilizando o Lucene................................65 Figura 22 - Janela de seleo de diretrio do Prottipo.............................................67 Figura 23 - Diretrio onde esto localizados os arquivos que sero indexados........68 Figura 24 - Indexao e lista de arquivos indexados.................................................68 Figura 25 - Pesquisa de arquivos indexados no Windows Search............................69 Figura 26 - Pesquisa de arquivos indexados no Google Desktop.............................69 Figura 27 - Resultado de pesquisa no Windows Search...........................................70 Figura 28 - Resultado de pesquisa no Google Desktop............................................70 Figura 29 - Pesquisa de arquivos indexados pelo Lucene........................................71 Figura 30 - Resultado de pesquisa no Google Desktop............................................72 Figura 31 - Resultado de pesquisa no Prottipo.......................................................72 Figura 32 - Resultado da pesquisa para o termo Scott.............................................73 Figura 33 - Resultado da pesquisa para o termo Scott usando til............................74 Figura 34 - Resultado da pesquisa para o termo Scott usando o smbolo +............74 Figura 35 - Resultado da pesquisa para o termo Scott usando o smbolo -.............74 Figura 36 - Extenses usadas na indexao pelo Prottipo.....................................75 Figura 37 - Trecho do arquivo de configurao........................................................89 Figura 38 - Configurao dos ouvintes do Hibernate Search...................................89 Figura 39 - Configurao de classe com o Hibernate e Hibernate Search...............90 Figura 40 - Configurao de classe com o Hibernate e Hibernate Search (complemento)..........................................................................................................91

LISTA DE TABELAS
Tabela 1 - Representao de uma sentena ........................................................... 20 Tabela 2 - Quadro comparativo dos testes .............................................................. 76

LISTA DE ABREVIATURAS
API - Application Programming Interface DC - Dublin Core DCMI - Dublin Core Metadata Initiative DTD - Document Type Definition EIS - Sistemas de Informao Empresarial FOAF - Friend of a Friend GD - Google Desktop GDS - Google Desktop Search GPL - General Public License HQL - Hibernate Query Language HTML - HyperText Markup Language IDE - Integrated Development Environment JDBC - Java Database Connectivity JDK - Java Development Kit LGPL - GNU Lesser General Public License MVC - Model View Controll OCLC - Online Computer Library Center ORM - Object Relational Maing OWL - Web Ontology Language RDF - Resource Description Framework RDFS - RDF Schema RI - Recuperao da Informao RTF - Rich Text Format SDK - Software Development Kit SGBD - Sistema Gerenciador de Banco de Dados SKOS - Simple Knowledge Organization System SO - Sistema Operacional SQL - Structured Query Language SRI - Sistema de Recuperao de Informao SWRL - Semantic Web Rule Language TCP - Transmission Control Protocol URI - Uniform Resource Identifier URL - Uniform Resource Locator W3C - World Wide Web Consortium WD - Windows Desktop WDS - Windows Desktop Search WWW - World Wide Web XML - eXtensible Markup Language

INTRODUO

A Web (World Wide Web) proporciona um gigantesco espao de informao e servio, atravs dos quais pessoas podem acompanhar investimentos, planejar e contratar pacotes tursticos, marcar consultas mdicas, manter-se atualizadas. Entretanto, ao mesmo tempo em que a Web proporciona facilidades, causa tambm um problema pelo mesmo motivo: excesso de informao. Esse excesso de informao, aliado a uma diversidade de dados e formas de armazenamentos tornase um problema grave porque muitas vezes no possvel coletar os dados necessrios para uma tomada de deciso em tempo hbil.

Este fato pode ser claramente percebido ao efetuar uma pesquisa, usando ferramentas de busca (Google, Yahoo, Cad?, entre outros), na internet. Na maioria das vezes, encontrar informao relevante pode ser uma tarefa rdua e complexa, pois o computador no consegue distinguir o significado do termo que est sendo pesquisado nem qual deve ser o contedo retornado para o solicitante. O contedo retornado pode ser proveniente de vrias fontes de dados, tais como documentos gerados por organizaes, documentos e pginas pessoais dos membros dessas organizaes, arquivos de texto, planilhas, arquivos de udio, bancos de dados orientado a objeto, bancos de dados relacionais, imagens, entre outros.

Com a reconhecida importncia da Web no cenrio mundial, tornou-se essencial um melhor tratamento das informaes armazenadas nessa grande rede de computadores. A partir dessa necessidade, os mecanismos de buscas (Alta Vista, Cad?, Yahoo, entre outros) tornaram-se indispensveis para os usurios da rede, buscando otimizar e recuperar com mais eficincia as informaes pesquisadas. Apesar de ter atendido as finalidades iniciais facilitar o acesso a informaes que esto em vrias partes do mundo em um pequeno intervalo de tempo - os sistemas de busca tornaram-se um tanto ineficientes em seu trabalho, pois a popularizao da Web, especialmente no incio dos anos 2000, proporcionou uma exploso de informaes armazenadas que levou a necessidade de melhores critrios para as buscas, possibilitando assim o desenvolvimento do termo Recuperao da Informao - RI. A RI busca definir estratgias de buscas utilizando tcnicas ou

11

conjuntos de regras que possibilite uma maior relevncia dos contedos exibidos para um termo pesquisado.

No contexto especfico da Web, este problema foi reconhecido em 2001 por Tim Berners-Lee, James Hendler e Ora Lassila, e as iniciativas para tentar minimizar seus efeitos deram origem rea de pesquisa denominada Web Semntica (Semantic Web). No contexto da Web Semntica, busca-se tratar as informaes da Web como uma rede de conceitos em contraposio a uma rede de documentos (W3C, 2001). A idia associar conhecimento do significado aos recursos da Web, tipicamente atravs da utilizao de dados processveis por mquinas. Cada conceito pode estar relacionado a outros conceitos e pode ter um grupo de recursos de informao associados. Esta rede de conceitos e recursos de informao usada, ento, na navegao na Web. Para definir a rede de conceitos na Web Semntica, ontologias tm sido sistematicamente utilizadas.

O conceito de ontologias no ambiente da Web Semntica surge para formalizar um domnio de conceito atravs de termos e relacionamentos, sendo estes expressos atravs de linguagens. Destaca-se o padro RDF (Resource Description Framework), que prov uma semntica a modelos de dados atravs de objetos e relacionamentos entre os mesmos (ANTONIOU, 2004). Para tanto o RDF utiliza a linguagem XML (eXtensible Markup Language), que uma linguagem capaz de descrever diversos tipos de dados.

Este trabalho prope-se a realizar uma anlise comparativa entre o prottipo da ferramenta desenvolvida utilizando a API Lucene e Hibernate Search e os softwares de indexao Google Desktop (GD) e Windows Search (WS). Os critrios utilizados na anlise comparativa foram: processo de indexao, processo de busca, tempo de busca, pesquisa no Banco de dados e tipos de dados indexveis. Os arquivos que podero ser indexados so: arquivos de texto, PDF, XML, documentos do Word e arquivos contidos em uma bases de dados armazenada no banco MySQL. As pesquisas traro, como resultado ao termo pesquisado, a quantidade de ocorrncias encontradas, incluindo o caminho onde o mesmo est armazenado. O

desenvolvimento de tal ferramenta visa demonstrar que, atravs de um motor de buscas gratuito e de fcil utilizao, possvel criar aplicaes com as mesmas 12

caractersticas de programas disponveis, como o Google Desktop e o Windows Search e ainda acrescentar funcionalidades no implementadas nestes como o acesso a bancos de dados.

Para o comparativo nas buscas, foi feita a pesquisa de um termo, por exemplo, monografia, utilizando o prottipo desenvolvido, o Google Desktop e o Windows Search. Para as pesquisas no banco de dados tambm foi usado um termo de pesquisa, porm foi considerada pesquisa utilizando lgebra booleana. Nas pesquisas no banco de dados foi feito o comparativo nas buscas utilizando SQL atravs do Hibernate e buscas nos ndices criados atravs do Hibernate Search. Para ambas as pesquisas foram levadas em considerao relevncia dos registros retornados e tempo de pesquisa.

A presente monografia est dividida em quatro captulos, alm da introduo e concluso. O captulo um destina-se a explicar o conceito, funcionamento e ferramentas utilizadas na Web Semntica. No captulo dois so abordados os conceitos de Recuperao da Informao (RI), alm de sua arquitetura e funcionamento. As principais ferramentas utilizadas para buscas em Web Semntica so descritas no capitulo trs. Neste captulo estudado com maior detalhe o projeto da Apache Foundation Lucene alm da comparao entre as ferramentas Google Desktop, Windows Search. O captulo quatro descreve o processo de

desenvolvimento do prottipo, testes e resultados obtidos. Neste captulo ser abordada a estrutura utilizada no desenvolvimento do prottipo: quais as funcionalidades implementadas, com as respectivas especificaes; linguagem de programao escolhida e pequenos trechos de cdigo, contendo as funes mais importantes da implementao, tambm so partes integrantes deste captulo. Na concluso so analisados os resultados obtidos, dificuldades encontradas e sugesto para trabalhos futuros.

13

1. WEB SEMNTICA

Neste captulo sero abordados os principais conceitos de Web Semntica, porque utilizar esse novo conceito de Web, como ela funciona e quais as principais ferramentas que so utilizadas por ela para seu funcionamento.

A evoluo humana constante, com a Web no seria diferente. Para onde a Web est caminhando? Qual ser o prximo marco histrico no desenvolvimento tecnolgico, cultural e comportamental da Web? A resposta para essa pergunta, apostam algumas comunidades internacionais (a W3C uma delas), a Web 3.0 ou a Web Semntica.

Na Web 1.0 o poder gerador de contedo estava centralizado. Apesar de j haver uma grande quantidade de informao disponvel na Web, os sites no eram interativos, era mais um espao para leitura. Os visitantes no podiam contribuir com ele, seus aplicativos eram desenvolvidos com cdigos fechados, o usurio ficava no papel de espectador da ao que se passava na pgina que ele visitava. Na maioria das vezes um visitante no acessa o mesmo site mais de uma vez (SEIXAS, 2007).

J na Web 2.0 (como chamada nossa Web atual) o poder gerador de contedo descentralizado - qualquer usurio pode gerar informao. Essa Web que conhecida hoje feita para ser acessada por pessoas. A informao organizada de um modo que seja fcil para o homem compreender. Os sites usam linguagem natural, imagens e layouts de pginas para apresentar contedos igualmente fceis de serem entendidos pelos usurios. Sendo assim, fcil para o homem analisar, cruzar e obter resultados de informaes dentro da internet. Para um computador essa tarefa, atualmente, invivel. Ele no pode ler, fazer relaes ou tomar decises como o homem. Segundo Tim OReilly (2009), a Web 2.0 a mudana para uma internet como plataforma, e um entendimento das regras para obter sucesso nesta nova plataforma. Entre outras, a regra mais importante desenvolver aplicativos que aproveitem os efeitos de rede para se tornarem melhores quanto mais so usados pelas pessoas, aproveitando a inteligncia coletiva.

14

A Web Semntica prope ter toda essa informao disponvel no apenas para as pessoas, mas tambm ajudar os computadores a interpretarem, entenderem e tirarem concluses do contedo disponvel na Web. Segundo Tim Berners-Lee (2001) a Web desenvolveu linguagens excelentes (.NET ASP, C#; PHP; Java Servlet, Struts; HTML) para expressar informao que se destina a ser utilizada pelo homem, porm foi falha quando da manipulao destas pelas mquinas, j que estas no conseguem interpretar uma sentena da mesma forma que o homem. Por isso, a Web Semntica surge como uma proposta de trazer rede global uma estrutura e significado de dados, que permitem a sua evoluo de uma rede de documentos para uma rede de dados na qual toda a informao tem um significado bem definido, podendo ser interpretada e processada por humanos e computadores (BERNERS, 2001).

O objetivo principal da Web Semntica no pelo menos para j, treinar as mquinas para que se comportem como pessoas, mas sim desenvolver tecnologias e linguagens que tornem a informao legvel para as mquinas. A proposta padronizar a forma com a qual descrevemos informao na internet, ou seja, fazer com que as mquinas consigam interpretar as informaes dadas pelas pessoas e retornem os dados esperados por eles. Acredita-se que isso se tornaria realidade quando cada criador de contedo na Web formatasse seus dados de forma estruturada. Segundo o World Wide Web Consortium - W3C (2001), essa finalidade passa pelo desenvolvimento de um modelo tecnolgico que permita a partilha global de conhecimento assistido por mquinas.

O W3C - um consrcio internacional no qual organizaes filiadas (Cisco, HP, Oracle Corporation, entre outras), uma equipe em tempo integral e o pblico trabalham juntos para desenvolver padres e diretrizes para a Web. A misso do W3C conduzir a World Wide Web para que atinja todo seu potencial, desenvolvendo protocolos e diretrizes que garantam seu crescimento de longo prazo (W3C, 2001). O W3C lidera um esforo corporativo que busca tornar realidade este tipo de Web: fornecer um quadro comum que permita que dados sejam compartilhados e reutilizados em toda aplicao, empresa, comunidade e fronteiras. Assim, em 2001, surge a idia da Web Semntica que, segundo Berners-Lee (2001), um novo formato de contedo para a Web que tem significado para computadores. 15

A Web Semntica no exige alteraes na Web atual, no necessrio mudar todo seu sistema para comear a dar incio aos passos para a Web Semntica, ela pode ser gradativamente includa no sistema sem nenhuma alterao estrutural. Basicamente, para tornar um sistema mais prximo dessa realidade, necessrio apenas explicar o contedo da Web com a linguagem da Web Semntica.

O HTML comum, usado com fins puramente visuais daria lugar a linguagens e tecnologias mais rgidas (RDF, XML, OWL, etc.). A integrao dessas linguagens e tecnologias, associadas arquitetura de metadados - informaes compreensveis por mquinas sobre recursos da Web ou outros objetos; ontologias especificaes que permitem o compartilhamento de uma conceitualizao sobre determinado domnio; frameworks aplicao que prov uma soluo para uma famlia de problemas semelhantes e agentes computacionais possuem a capacidade de, com a ajuda de outras aplicaes, solucionar problemas complexos, favorecer o aparecimento de servios Web que garantam a interoperabilidade e cooperao.

1.1 ARQUITETURA

O esquema de arquitetura de desenvolvimento da Web Semntica de Berners-Lee citado por SANTANCH (2003). As camadas so definidas a partir de linguagens de baixo nvel para aquelas de mais alto nvel, conforme ilustrado na figura 1.

Figura 1 - Camadas da Web Semntica (SANTANCH, 2003)

16

A camada denominada Unicode/URI fornece a interoperabilidade em relao codificao de caracteres e ao endereamento e nomeao de recursos da Web Semntica. O Unicode um padro de codificao, definido pela Unicode Consortium desde 1995 e adotado por algumas organizaes como Oracle, SAP e Apple, para fornecer uma representao numrica universal e sem ambigidade para cada caractere de maneira independente da plataforma de software e do idioma. O URI - Uniform Resource Identifier, um padro para identificar um recurso fsico ou abstrato de maneira nica e global. Um identificador URL - Uniform Resource Locator, um caso especfico de URI. Endereos mailto, FTP e Telnet so outros exemplos de URIs (ADAGENOR, 2009).

Mailto um mtodo que permite comunicao na internet atravs de sistemas eletrnicos (Outlook, Exchange, entre outros). Tambm conhecido como e-mail. FTP - File Transfer Protocol um protocolo de transmisso de dados, a forma mais usada para transferncia de arquivos na internet. Telnet um protocolo clienteservidor usado para permitir a comunicao entre computadores ligados numa rede (LAN, Internet, entre outras), baseado em TCP - Transmission Control Protocol (ADAGENOR, 2009).

camada

denominada

de

XML/Namespace(NS)/XML

Schema

fornece

interoperabilidade em relao sintaxe de descrio de recursos da Web Semntica. A Extensible Markup Language (XML) uma linguagem para representao sinttica de recursos de maneira independente de plataforma (ADAGENOR, 2009).

A XML Schema uma linguagem de definio para descrever uma gramtica (ou esquema) para uma classe de documentos XML. A linguagem XML Schema fornece elementos para descrever a estrutura e restringir o contedo de documentos XML. Os espaos de nomes (Namespaces) fornecem um mtodo para qualificar os nomes de elementos e atributos, utilizados nos documentos XML, atravs da associao destes nomes com os espaos de nomes identificados por referncias de URI. Os espaos de nomes so teis para distinguir entre dois elementos definidos com um mesmo nome, mas que pertencem a esquemas diferentes. Alm disso, um documento pode associar elementos previamente definidos sua estrutura, desde 17

que utilize referencias aos esquemas que definem esses elementos (ADAGENOR, 2009).

A camada denominada RDF/RDF Schema fornece um framework para representar informao (metadados) sobre recursos. As principais especificaes do Resource Description Framework (RDF) abrangem um modelo de dados (para expressar declaraes sobre os recursos), uma sintaxe baseada na Extensible Markup Language (XML) (para o intercmbio das declaraes) e uma linguagem de definio de esquemas para vocabulrio (ADAGENOR, 2009). Esse assunto ser abordado mais detalhadamente no tpico 1.3 desta monografia.

A camada denominada de Ontology Vocabulary fornece suporte para a evoluo de vocabulrios e para processar e integrar a informao existente sem problemas de indefinio ou conflito de terminologia. A linguagem RDF Schema permite a construo de ontologias com expressividade e inferncia limitadas, pois fornece um conjunto bsico de elementos para a modelagem, e poucos desses elementos podem ser utilizados para inferncia. A Web Ontology Language (OWL) estende o vocabulrio da RDF Schema para a incluso de elementos com maior poder com relao a expressividade e inferncia. Alm disso, a linguagem OWL fornece trs mdulos (ou dialetos), OWL Lite, OWL DL e OWL Full, para permitir o uso da linguagem por aplicaes com diferentes requisitos de expressividade e inferncia. O desenvolvedor pode escolher o mdulo OWL adequado, de acordo com os requisitos da sua aplicao (ADAGENOR, 2009).

A camada denominada Logic fornece suporte para a descrio de regras para expressar relaes sobre os conceitos de uma ontologia, as quais no podem ser expressas com a linguagem de ontologia utilizada. As linguagens Rule Markup Language (RuleML) e Semantic Web Rule Language (SWRL) so exemplos de linguagens propostas para a descrio de regras para a Web Semntica (ADAGENOR, 2009).

As camadas denominadas de Proof e Trust fornecem o suporte para a execuo das regras, alm de avaliar a correo e a confiabilidade dessa execuo. Essas

18

camadas ainda esto em desenvolvimento e dependem da maturidade das camadas inferiores (ADAGENOR, 2009).

1.2 PADRO RDF

O modelo RDF um padro recomendado pela W3C para representar informaes sobre recursos na Web (RDF, 2005). Ele fornece um mecanismo de auxlio ao desenvolvimento dos metadados, que so dados sobre dados, ou dados sobre os sistemas que operam esses dados. Baseados nesse mecanismo, os documentos Web so marcados semanticamente. Para que o modelo RDF possa ser visualizado e representado, so utilizados grafos rotulados. Estes grafos so construdos com a utilizao de trs objetos: recursos, propriedades e sentenas.

Os recursos representam o universo de objetos que podem ser descritos pelo modelo RDF. Uma pgina inteira da Web ou uma parte dela; uma coleo de pginas; ou um objeto que no diretamente acessvel via Web, como por exemplo, um livro impresso. Para cada recurso associado um identificador nico (URI) de forma a poder identific-lo posteriormente (SILVA e BRITO, 2004). Um URI pode apontar para qualquer coisa na Web e tambm pode apontar para objetos que no sejam parte da Web, como eletrnicos em casas informatizadas.

As propriedades representam os aspectos do recurso a serem descritos. Propriedades podem ser visualizadas como atributos (caractersticas) de recursos. Tambm so utilizadas para descrever relacionamento entre recursos. Neste sentido, o modelo de dados RDF assemelha-se ao modelo Entidade-

Relacionamento usado na anlise estruturada. Cada propriedade tem um significado especfico, define quais os seus valores permitidos, quais os tipos de recursos que podem descrever, e seu relacionamento com outras propriedades (SILVA e BRITO, 2004).

As sentenas representam a relao entre um recurso, uma de suas propriedades e o valor que essa propriedade pode assumir, ou seja, uma declarao de um recurso contendo um nome, uma propriedade e um valor agregado. Estas trs partes 19

da sentena (tripla) so chamadas respectivamente de predicado (propriedade), sujeito (recurso) e objeto (valor de uma propriedade). E a notao utilizada para representao dessa tripla : (predicado, sujeito, objeto). Com isso, as sentenas conseguem representar essa interligao entre o recurso, suas propriedades e seus valores (SILVA e BRITO, 2004).

De acordo com os conceitos acima, o modelo de dados RDF pode ser visualizado atravs de um formato de tripla como tambm por um grafo. A seguir sero mostrados exemplos de como representar esses formatos. A tabela 1 e a figura 2 representam a construo de uma sentena que descreve que o recurso, um documento da Web e de URI http://www.ulbra-to.br/cursos/Informatica, possui uma propriedade http://www.ulbra-to.br/rdf/esquema-imagem/coordenador, cujo valor um literal "Joo Silva".

seguinte

tripla

(http://www.ulbra-to.br/rdf/esquema-imagem/coordenador,

http://www.ulbra-to.br/cursos/Informatica, "Joo Silva") est representada na tabela 1.

Tabela 1: Representao de uma sentena (REIS, 2006)

PROPRIEDADE http://www.ulbrato.br/rdf/esquemaimagem/coordenador

RECURSO http://www.ulbrato.br/cursos/Informatica

OBJETO Joo Silva

A representao de um grafo consiste em arcos e ns representando propriedades e recursos respectivamente. A figura 2 ilustra a sentena da tabela 1.

20

http://www.ulbrato.br/cursos/Informatica

http://www.ulbra-to.br/rdf/esquemaimagem/coordenador Joo Silva

Figura 2 - Representao de uma sentena por grafo (REIS, 2006)

O RDF destaca-se pela simplicidade com que busca estruturar o contedo contido na Web. Os documentos RDFs so escritos com base em um ou vrios modelos de descrio de contedo RDF. Esses modelos definem padres para a construo dos metadados que compem o contedo.

A padronizao na forma de se escrever os modelos RDF visa resolver problemas oriundos do uso de diferentes nomenclaturas para metadados e vrias outras situaes nas quais a interpretao dos metadados no ocorre de maneira nica. Atualmente existem vrios modelos para padronizao do contedo RDF, entre os mais conhecidos est o Dublin Core (DC). Cada padro identificado por um namespace, que identificado atravs de um termo xmlns seguido de seu nome e URI (xmlns:dc=http://purl.org/dc/elements/1.1/) (BRITO e DIVINO, 2005).

O padro Dublin Core foi definido pelo padro NISO Z39.85-2007. O "Dublin" do nome se refere Dublin, Ohio, U.S., onde o trabalho se originou de um workshop sediado em 1995 pela OCLC - Online Computer Library Center, um consrcio de bibliotecas. O "Core" se refere ao fato de que o conjunto de elementos de metadados so uma lista bsica mas expansvel.

O padro Dublin Core um esquema para descrio de metadados que favorece a representao de recursos eletrnicos, tornando-os mais visveis aos motores de busca e sistemas de recuperao. Esse padro descreve objetos digitais como 21

vdeos, sons, imagens, sites e texto por meio de arquivos XML. A organizao DCMI (Dublin Core Metadata Initiative) dedicada a desenvolver esses tipos de padres para descrever fontes que tornem mais fcil a utilizao de recursos eletrnicos. De acordo com a DCMI (DUBLIN CORE, 2009), o padro Dublin Core define uma lista de quinze elementos de metadados que descrevem todas as caractersticas do recurso. So esses elementos: 1. Title: nome pelo qual o recurso formalmente conhecido; 2. Creator: responsvel em primeira instncia pela existncia do recurso; 3. Subject: tpicos do contedo do recurso; 4. Description: descrio do contedo do recurso; 5. Publisher: entidade responsvel por tornar o recurso acessvel; 6. Contributor: entidade responsvel por qualquer contribuio para o contedo do recurso; 7. Date: data associada a um evento do ciclo de vida do recurso; 8. Type: natureza ou gnero do contedo do recurso; 9. Format: manifestao fsica ou digital do recurso; 10. Identifier: uma referncia no ambgua ao recurso, definida num determinado contexto; 11. Source: uma referncia a um recurso de onde o presente recurso possa ter derivado; 12. Language: lngua do contedo intelectual do recurso; 13. Relation: uma referncia a um recurso relacionado; 14. Coverage: extenso ou alcance do recurso; 15. Rights: informao de direitos sobre o recurso ou relativos ao mesmo.

Cada elemento Dublin Core opcional e pode ser repetido. O DCMI estabeleceu maneiras padronizadas para refinar os elementos e encorajar o uso de esquemas de codificao e vocabulrio. No h ordem no Dublin Core para apresentar ou usar os elementos.

O RDF usa os namespaces para indicar o padro de descrio adotado e sua localizao. Todos os documentos RDFs que possuem os mesmos namespaces vo trabalhar com as mesmas nomenclaturas e significados, que esto definidos no padro usado. A utilizao de namespaces evita que haja conflitos em termos com o 22

mesmo nome, mas com significados diferentes a depender do contexto. Isso possvel porque o mesmo termo pode estar definido em mais de um modelo, mudando apenas o significado. Todo documento RDF, por padro, deve usar o namespace definido pela W3C, http://www.w3.org/1999/02/22-rdf-syntax-ns#, e a extenso rdf.

Figura 3 - Estrutura do documento RDF utilizando elementos do Dublin Core.

As funes rdf:description so utilizadas para fazer a converso do padro Dublin Core para o padro RDF, cada uma representando um tipo de informao do recurso. Dessa forma, cada um dos 15 elementos do padro Dublin Core podem ser representados pelo rdf:node ID, seguido de um caractere A, seguido de um valor numrico. A representao desses elementos do DC ilustrado na figura 3.

1.3 LINGUAGEM XML

O XML uma especificao tcnica desenvolvida pela W3C para superar as limitaes do HTML, que o padro das pginas da Web. O XML complementa o 23

HTML ao adicionar tags (etiquetas) que descrevem os dados. Essas tags so visveis ao computador, porm invisveis ao ser humano. So essas tags que so atualmente utilizadas pelos sites de busca. Com o XML possvel definir em um documento o que contedo, significado e apresentao, podendo extrair, manipular, integrar e publicar dados na rede. HTML e XML vem do padro SGML, padro ISO 8879 de formatao de textos. SGML no padro aplicado de maneira padronizada: todos os produtos SGML tm seu prprio sistema para traduzir as etiquetas para um particular formatador de texto.

Num documento utilizando o HTML, a tag <p> </p> indica o incio e o fim de um pargrafo. No XML, as tags so usadas para definir blocos de dados. Isso quer dizer que, <p> </p> podem significar qualquer coisa que o programador desejar. Por exemplo, <p> </p> podem significar peso, pessoa, nome, endereo, enfim, o que o usurio quiser que represente. Por essa caracterstica, o XML at considerado por muitos uma linguagem capaz de gerar outras linguagens, visto que quem define os comandos e suas funes o programador (LINGUAGEM XML, 2009).

Para evitar confuso na utilizao da linguagem XML (uma vez que cada usurio pode criar sua prpria linguagem), utilizado um conjunto de regras (gramtica) para a organizar seus elementos. Essas regras so ditadas pelo DTD (Document Type Definition). Um analisador de documentos pode checar os dados que chegam analisando as regras contidas no DTD para ter certeza de que o dado foi estruturado corretamente. No DTD as tags so pr definidas, cada pessoa pode definir suas prprias tags. Alm do DTD, h tambm o XML Schema, que tem a mesma funo, porm conta com mais recursos.

A figura 4 ilustra um exemplo de cdigo para um melhor entendimento. O texto em azul representa as tags:

<email> <de> <para> <assunto> Departamento Departamento Anlise do Financeiro Operacional Ano Fiscal </de> </para> </assunto>

24

<mensagem> Favor comparecem reunio que se realizar em 10/08/2005, s 8:00 horas, no auditrio da </email>
Figura 4 - Trecho de cdigo utilizando XML

empresa.

</mensagem>

A figura 4 permite visualizar a importncia da linguagem XML, principalmente porque empresas e instituies podero usar a linguagem conforme sua necessidade. Entre as funes principais do XML, tem-se: descrever dados; apresentar dados em algum formato, como HTML; transportar dados; trocar dados de forma transparente entre plataformas diferentes.

Apesar da importncia da linguagem XML para a Web Semntica, vlido destacar que o XML uma estrutura e uma sntese, mas no a semntica, o estudo do significado. Ela (a linguagem) tem capacidade limitada para expressar as relaes entre os recursos, por isso deve ser assistida por outras linguagens como as ontologias (REIS, 2005). O conceito de Ontologia ser tratado posteriormente neste trabalho.

1.4 FUNCIONAMENTO DA WEB SEMNTICA

Segundo Berners Lee (2001) citado por Brito e Divino (2005), para que as mquinas consigam administrar o raciocnio automatizado, ou seja, entender a representao do conhecimento disponvel na Web, necessrio que elas consigam ler dados estruturados e tenham acesso a conjuntos de regras de inferncia que ajudem a conduzir seus raciocnios para um processo de deduo automtica das pginas marcardas semanticamente.

Essas regras de inferncia so especificadas atravs de ontologias, que representam explicitamente a semntica dos dados, as regras lgicas de raciocnio 25

sobre eles, os conceitos e as relaes entre esses dados. Para interpretar o significado das informaes, as mquinas e sistemas de buscas usam ontologias.

Para demonstrar o funcionamento da Web Semntica tem-se o exemplo a seguir: Como tornar legvel para o computador a frase Anakin Skywalker pai de Luke Skywalker? Para o ser humano isso acontece quando se define que Anakin e Luke so pessoas e que h uma relao de parentesco (no caso de pai) entre eles. Essa frase pode significar tambm que Luke filho de Anakin, mas o computador no consegue entender isso sem ajuda. Para o computador entender o significado dessa frase e a relao entre as pessoas mencionadas ser necessrio utilizar, inicialmente, duas ferramentas: o XML e o RDF.

O RDF, usando tags de XML, fornece uma estrutura para descrever recursos. Esta estrutura, no exemplo mostrado na figura 5, emparelha o recurso (qualquer substantivo, como Anakin Skywalker) com um item especfico na Web para que o computador saiba exatamente qual recurso . Identificar de maneira clara os recursos evita que o computador confunda Anakin Skywalker com Sebastian Shaw ou Hayden Christiansen (outros personagens do filme Star Wars).

Figura 5: Um trio de RDF tem um sujeito (Anakin Skywalker), um objeto (Luke Skywalker) e uma propriedade que une os dois (HOWSTUFFWORKS, 2009).

Aqui, o computador sabe que h dois objetos nessa frase e que h uma relao entre eles. Mas no sabe o que so esses objetos ou como se relacionam entre si. A ferramenta que vai adicionar esta camada de significado a URI. Ela vai direcionar o computador a um documento ou objeto que representa o recurso. Para esse exemplo sero utilizados as pginas dos personagens no site oficial do Star Wars como suas URIs, como mostrado na figura 6. 26

Figura 6: Um URI d ao computador um ponto de referncia especfico para cada item do trio (HOWSTUFFWORKS, 2009).

Agora o computador sabe quem so o sujeito e o objeto. Porm, percebe-se que a URI que identifica a propriedade no trio representado na figura 6 no aponta para o site oficial do Star Wars. Em vez disso aponta para a um documento irreal no servidor da HowStuffWorks. Caso esta pgina fosse real, ela seria a XML namespace. Nesse exemplo, a declarao da namespace seria uma linha de cdigo que mandaria a seguinte mensagem para o computador: quaisquer tags que comecem com hsw, use o vocabulrio desse documento.

XML e RDF so as principais ferramentas da Web Semntica, mas por si s no so o suficiente para tornar toda a Web acessvel para um computador. Para entender o que as palavras significam e qual a relao entre elas o computador precisa ter documentos que descrevem todas as palavras e a lgica para fazer as conexes necessrias.

H duas ferramentas relacionadas para ajudar o computador a entender o vocabulrio humano, so esquemas e ontologias. Um esquema um mtodo de organizar informaes e uma ontologia o vocabulrio que descreve objetos e como eles se relacionam. Esquemas e ontologias utilizam outras ferramentas na Web Semntica, as principais so:

Esquemas de Linguagem de Descrio de Vocabulrio RDF (RDF Schema - RDFS) - adicionam classes, subclasses e propriedades aos recursos, criando uma estrutura bsica de linguagem. Por exemplo, dentro do filme Star Wars, recurso Dagobah uma subclasse da classe planeta. Uma propriedade de Dagobah poderia ser pantanoso.

27

Sistema Simples de Organizao de Conhecimento (Simple Knowledge Organization System - SKOS) - classifica recursos em termos de mais amplo ou mais especfico, permite a designao de etiquetas preferenciais e alternativas e permite que as pessoas rapidamente transportem dicionrios e glossrios para a Web. Por exemplo, em um glossrio do Star Wars, um termo mais especfico para Sith Lord poderia ser Darth Sidious e um termo mais amplo poderia ser vilo. Da mesma maneira, etiquetas alternativas para Han Solo poderia ser pastor nerf e crebro de laser.

Linguagem de Ontologia da Web (Web Ontology Language - OWL) - a camada mais complexa, formaliza as ontologias, descreve relaes entre classes e usa lgica para fazer dedues. Ela tambm pode construir novas classes com base em informaes existentes.

Figura 7: Exemplo de um nmero pequeno dos recursose conexes que podem ser encontrados na ontologia Star Wars (HOWSTUFFWORKS, 2009).

28

A figura 7 representa o exemplo de um nmero pequeno dos recursos e conexes que podem ser encontrados na ontologia Star Wars (HOWSTUFFWORKS, 2009). Para o ser humano possvel deduzir as relaes entre os personagens assistindo ao filme, mas um computador precisa ter um esquema muito claro para entender isso.

Muito da funo e praticidade da Web Semntica ainda esto em desenvolvimento e h muitos obstculos a serem superados, como por exemplo, alguns

desenvolvedores discordam sobre se a Web Semntica deveria se basear mais em regras ou ontologias, outros dizem que o projeto completamente impraticvel principalmente porque empresas e sites existentes no iro dedicar tempo e recursos necessrios para serem padronizados de acordo com o que a Web

Semntica necessita para seu fucionamento. Para Berners-Lee (2008), a prtica da Web semntica acontece a partir da interoperabilidade, a exemplo da integrao de dados intra e entre empresas e da integrao de dados cientficos, alm da possibilidade de consultas aos dados integrados. No futuro, software produzido em srie pode incluir opes para adicionar metadados ao criar novos documentos, mas esta ferramenta pode ainda no ser suficiente para tornar o projeto vivel em grande escala.

Algumas reas da Web j incorporam componentes da Web Semntica. Incluem-se a feeds de RSS (a sigla tem mais de um significado. Alguns a chamam de RDF Site Summary, outros a denominam Really Simple Syndication e h ainda os que a definem como Rich Site Summary), que usam o RDF e o projeto FOAF (Friend of a Friend), mecanismo ontolgico que prope a criao de pginas pessoais legveis por mquina.

29

2. RECUPERAO DA INFORMAO

Atualmente j no se pode falar em crescimento do volume de publicaes, mas em uma verdadeira exploso. As bibliotecas digitais, que so publicaes armazenadas e manipuladas eletronicamente, aparecem como um paradigma para melhorar a busca e apresentao de informaes desejadas. Neste contexto so estudadas tcnicas de digitalizao de objetos originados de fontes heterogneas, tcnicas de armazenamento, processos de busca, recuperao e apresentao de forma amigvel das informaes. Diante deste quadro, recuperao de informao apresenta a cada dia novos desafios e se configura como uma rea de significncia maior.

Recuperao da Informao (RI) uma rea da Cincia da Computao que estuda o armazenamento de documentos e a recuperao de informao associada ao mesmo. responsvel em buscar informaes em documentos, documentos propriamente ditos, metadados que descrevam documentos e informaes em banco de dados, sejam eles relacionais e isolados ou interligados em rede hipermdia, tais como a Web. Segundo Baeza-Yates (1999), a RI engloba diversos aspectos como representao, armazenamento, organizao e acesso aos itens que contm as informaes. A RI deve proporcionar ao usurio do Sistema de Recuperao de Informao (SRI) atingir de forma relativamente direta a informao procurada.

No entanto, atingir de forma mais precisa possvel a informao desejada no uma tarefa simples. Ao definir o contedo a ser pesquisado, tambm chamado de necessidade de informao do usurio, deve-se transform-lo em uma sentena que possa ser processada pelo motor de busca disponvel. Geralmente essa transformao significa resumir a necessidade de informao em um conjunto de palavras-chaves que sero utilizadas para realizar a busca de informaes relevantes. Essa transformao pode ocorrer de trs maneiras:

A primeira reunir um conjunto de palavras que expressem o significado da informao requerida (BAEZA-YATES, 1999).

30

A segunda opo escolher uma coleo de palavras que estabeleam restries de modo que o resultado da busca contenha os dados esperados inicialmente.

Outra alternativa quando o usurio no precisa alimentar o sistema com algo que ele deseja pesquisar. Nesse caso a busca por resultados acontece atravs da navegao pelos documentos, que no foram necessariamente indexados anteriormente (SOUZA, 2006).

2.1 MODELOS DE RECUPERAO

As consultas realizadas pelo usurio de um SRI podem ser separadas nos modos de operao Adhoc e Filtragem. A primeira forma ocorre quando h pequenas alteraes na base de documentos ao se realizar novas pesquisas, ou seja, quando o acervo de documentos sofre poucas alteraes enquanto novas queries so submetidas ao sistema de busca. A segunda forma ocorre quando a busca por resultados se mantm praticamente inalterada ao se adicionar novos documentos, ou seja, quando as queries se mantm relativamente estticas enquanto novos documentos so adicionados ao sistema de busca. A filtragem acontece usualmente em processos de monitorao de fontes de informao, enquanto a recuperao Adhoc representa as buscas usuais em SRIs. (SOUZA, 2006).

Os modelos de recuperao Adhoc so subdivididos em clssicos e estruturados. Nos modelos clssicos o documento indexado representado por palavras-chave que buscam representar semanticamente o todo, esses modelos sero melhor abordados neste mesmo captulo. J nos estruturados so determinados outros metadados relativos ao documento, tais como fontes, relao entre as palavras e outras informaes relativas estrutura do texto (SOUZA, 2006).

A figura 8 ilustra a taxonomia de modelos de Recuperao de Informao. (SOUZA, 2006 apud BAEZA-YATES, 1999, p.21)

31

Figura 8 - Taxonomia de modelos de RI

Dentre os modelos clssicos podem ser destacados os modelos booleano, vetorial e probabilstico. Em seguida, sero abordados a descrio dos modelos citados e alguns derivados dos mesmos.

Booleano: modelo baseado na teoria dos conjuntos. Podem ser utilizados operadores booleanos como o and, or ou not para correlacionar as palavras da pesquisa. No entanto pouco eficaz, pois os documentos so apenas caracterizados de forma binria como relevantes ou no e no h qualquer ordenao dos elementos que fazem parte do resultado da consulta. Por causa dessas limitaes, foram concebidas a partir desse modelo duas novas abordagens de busca para minimizar os problemas citados.

Lgica difusa ou nebulosa (fuzzy): o modelo toma como premissa que cada consulta representa um conjunto difuso e cada documento presente no ndice tem um nvel de pertencimento quele conjunto. O grau de pertencimento pode ser determinado pela ocorrncia de palavras expressas na query, tal como no modelo booleano, mas pode tambm utilizar um instrumento como um tesauro para determinar que termos relacionados semanticamente aos termos ndice tambm confiram algum grau de pertencimento ao conjunto difuso determinado pela query (SOUZA, 2006). Este nvel admite infinitos valores lgicos intermedirios entre 0 (zero) denominado de FALSO e 1 (um) 32

denominado de VERDADEIRO, assim como de valor mdio (0,5) denominado de TALVEZ. Pode ser determinado tanto de maneira binria, atravs da quantidade de ocorrncias de palavras da consulta no documento, como utilizando dispositivos de controle que determine relacionamento semntico entre as palavras da consulta e do documento possibilitando avaliar conceitos no-quantificveis, a exemplo de avaliar a veracidade de um argumento (corretssimo, correto, contra-argumentativo, incoerente, falso, totalmente errneo, etc.). Booleano estendido esse modelo tem como objetivo resolver o problema criado pelas decises dualistas do modelo original. Para isso atribuindo pesos a cada termo, o que aproxima esse modelo do vetorial. Vetorial esse modelo prope um arcabouo onde o casamento parcial entre uma consulta e um documento da coleo possvel atravs do assinalamento de pesos no binrios aos termos de indexao dos documentos e consultas. Esses pesos associados aos termos so usados para calcular o grau de similaridade entre cada documento de uma coleo e a consulta de usurio. Dessa forma, o modelo vetorial leva em considerao documentos que casam com a consulta de forma parcial. Isto possvel devido representao de cada documento como vetores no espao de dimenso n, sendo n o nmero de palavras contidas no ndice (todos os documentos). Grande parte dos SRIs baseada nesse modelo de recuperao. A seguir so apresentados alguns modelos que estendem o vetorial. Vetorial generalizado esse modelo considera que as palavras presentes no ndice no so necessariamente independentes e que elas podem ter relao umas com as outras. Essa relao pode ser determinada ao se avaliar a ocorrncia conjunta de palavras no mesmo documento ou ainda pode-se utilizar um tesauro, como foi comentado no modelo de Lgica Fuzzy, para avaliar relacionamentos semnticos. Indexao semntica latente nesse modelo cada consulta e cada documento devem ser mapeados em um espao relativamente pequeno, construdo a partir dos conceitos relevantes que possuem os documentos no acervo. Esses espaos devem ser determinados a partir de conceitos presentes nos documentos indexados. A 33

partir da compatibilidade desses espaos (da consulta e dos documentos) montada a lista de resultados. Redes neurais esse modelo faz uso de redes neurais - sistemas estruturados baseados em ligaes (ns) - para obter o resultado esperado. Cada consulta ativa os termos indexados e estes ativam documentos aos quais eles pertencem, que por sua vez ativam novamente termos indexados. Essas interaes ocorrem continuamente at que se consiga um resultado. Atravs desse mtodo no garantido que os resultados encontrados contenham sequer um termo presente na consulta original. Probabilstico nesse modelo, supe-se que existe um conjunto timo de resultados para cada consulta e que ele seja passvel de recuperao. Para obter esse conjunto timo, o mtodo parte de uma lista de resultados obtida utilizando qualquer um dos mtodos j citados e de interaes consecutivas com o usurio. A partir disso analisa quais documentos so relevantes para o usurio em cada interao visando obter a lista tima. desse modelo: Redes de inferncia aqui, caso um documento especfico seja considerado relevante para uma consulta, criada uma varivel aleatria e associada a este relacionamento. Essas variveis podem ser alteradas de acordo com os acontecimentos seguintes e, dessa forma, se determinam relacionamentos a partir dos eventos ocorridos. Redes de crena nesse modelo, os documentos e consultas so mapeados como subconjuntos de um espao de conceitos. Cada um dos documentos associado a uma probabilidade de atender aos conceitos pertencentes a esse espao. Posteriormente, cada query mapeada no espao de conceitos, que por sua vez, est conectado ao espao de documentos. Abaixo so descritas algumas extenses

Segundo Souza (2006) e Baeza-Yates (1999), h diversos modelos de recuperao de informaes, alm dos apresentados, que esto sendo estudados, j que este um campo muito abrangente de pesquisa tais como, Interfaces Cognitivas, 34

Personalizao, Anlise de Links. Entre esses modelos, h novas estratgias de pesquisa para complementar as tcnicas j existentes de recuperao. Alguns pontos estudados por essas novas estratgias de pesquisa so:

O aumento do estudo do significado das informaes presentes em cada documento, com o objetivo de compreender melhor os padres semnticos presentes,

A utilizao de metadados ligados a cada documento para facilitar a identificao dos mesmos, A criao de meios para a apresentao das informaes, de modo a tornar menos complexo o refinamento das informaes, A utilizao de perfis de usurio para que o SRI possa ganhar conhecimento a partir das interaes com aquele usurio e atingir melhores resultados posteriormente e

O uso da estrutura da linguagem de marcao na Web, e dos relacionamentos entre as pessoas nos sites de relacionamento para auxiliar na determinao da relevncia dos documentos para as pesquisas (SOUZA, 2006).

2.2 SISTEMAS DE BUSCAS

So sistemas com objetivo de facilitar a busca de informaes e localizao de stios na web. Neste trabalho convencionaremos como sistemas de busca, os servios, ferramentas e softwares criados com o objetivo de prover aos usurios meios para localizar informaes na web.

H duas abordagens bsicas de sistemas de busca na web: diretrios e mecanismos de busca (search engine). Os diretrios surgiram logo no incio do WWW com objetivo de facilitar a localizao de informao. Com o crescimento e a dificuldade de manter atualizadas as listas com endereos das pginas Web, surgiram os mecanismos de busca, que automatizaram a descoberta e a indexao das pginas. Com a evoluo, surgiram subcategorias de sistemas de busca, como os

35

metabuscadores ou multibuscadores que realizam busca em outros sistemas de busca, no possuindo as funes de descoberta e indexao de pginas. Alm deste, surgiram software de busca que so tambm metabuscadores com funes adicionais.

Um sistema de busca pode manter e oferecer simultaneamente os servios de diretrio e mecanismo de busca.

2.2.1 DIRETRIOS (DIRECTORY)

So listas de assuntos organizadas em categorias, geralmente com uma estrutura hierrquica (rvore).

Os diretrios buscam como abordagem principal: Manuteno do nvel de qualidade estabelecido Classificao precisa de stios da web

Alguns

dos

diretrios

populares

so:

Cade

(www.cade.com.br),

Aonde

(www.aonde.com.br), Yahoo (www.yahoo.com.br).

2.2.2 MECANISMOS DE BUSCA (SEARCH ENGINE)

Conhecidos tambm como programas de busca, mecanismo de procura, ferramenta de busca. So programas que tem trs funes bsicas identificar pginas da web, indexar estas pginas em um banco de dados e um mecanismo de pesquisa como interface. O resultado de uma busca classificado e apresentado por um mtodo conhecido como relevncia. Cada mecanismo de busca utiliza mtodo prprio de classificao. Os mecanismos de busca tm como abordagem: Indexao de documentos da web buscando o mximo de acesso Recuperao por relevncia utilizando tcnicas de indexao automtica

Exemplos de mecanismos de buscas: AltaVista (www.altavista.com), Google (www.google.com). 36

Os mecanismos de busca tm trs funes principais: Um rob, que localiza os documentos. Conhecido como spider, agente, crawler, worm; Um indexador, que extrai a informao dos documentos; Uma interface com o usurio.

H autores que consideram quatro funes principais para o mecanismo, subdividindo a interface com o usurio em duas funes: a interface com o usurio e o motor de busca que realiza a pesquisa do contedo desejado no banco de dados.

2.2.3 METABUSCADORES

So sistemas que realizam buscas em outros sistemas de busca em paralelo, apresentando os resultados. Estes sistemas no mantm banco de dados prprio. Alguns dos metabuscadores conhecidos so: Metacrawler (www.metacrawler.com), C4 (www.c4.com).

2.2.4 SOFTWARE DE BUSCA

So programas para instalao nos computadores dos usurios para auxiliar o processo de pesquisa na Internet. Funcionam utilizando os sistemas de busca (diretrios e mecanismos de busca) como os metabuscadores. Os softwares de busca armazenam os resultados das buscas no computador do usurio, podendo possuir caractersticas adicionais facilitadoras como a eliminao de ligaes desativadas (links quebrados) e a remoo de ligaes repetidas dos resultados.

Exemplos de software de busca: Copernic (www.copernic.com), WebFerret (www.ferretsoft.com).

37

2.2.5 PROBLEMAS E LIMITAES DOS ATUAIS SISTEMAS DE BUSCA

O volume de informao disponvel na Web um dos problemas que os atuais sistemas de busca so limitados para trabalhar. Os usurios encontram grandes dificuldades para realizar buscas com a preciso desejada, normalmente retornando grande quantidade de rudos.

Segundo Bergman (2001), em 2000 foi estimado que a Web continha cerca de 2,5 bilhes de documentos na web visvel e com crescimento de 7,5 milhes de documentos ao dia e que a web oculta era cerca de 500 vezes maior.

Cada sistema de busca tem critrios prprios de busca e indexao de pginas, recuperao da informao no banco de dados e classificao e apresentao dos resultados, sendo este ltimo uma caracterstica que diferencia os sistemas, conhecido como ranking de relevncia. Normalmente os critrios e a frmula de clculo da relevncia no so divulgados pelas empresas que desenvolvem os sistemas de busca. Os ndices de preciso e relevncia de uma busca, em pesquisas na web podem ser diretamente atingidos pelo ranking de relevncia, levando em considerao que caso a quantidade de endereos que retornaram como resultado for grande, o usurio se limitar a verificar os primeiros resultados.

Portanto, se as informaes desejadas estiverem no incio da lista de resultado, a possibilidades do usurio encontrar o que deseja aumenta significativamente.

As caractersticas tcnicas e a poltica adotada tm impacto direto sobre o nvel de atualizao do contedo dos bancos de dados dos sistemas de busca e sobre o tamanho dos bancos de dados.

2.3 INDEXAO

A finalidade de indexar os dados, eles estando em uma organizao, em um computador pessoal ou na grande rede de computadores (Internet) fazer com que os mesmos estejam disponveis de maneira rpida e direta a aqueles que desejam 38

fazer uso desses arquivos, poupando tempo e trabalho desnecessrio na tarefa de localizao dos mesmos.

A indexao de dados envolve uma gama de aspectos, dentre os quais destacam-se a maneira utilizada para a coleta, interpretao e armazenamento dos dados. A inter-relao desses aspectos contribui e possibilita a recuperao de informao com uma maior eficincia, ou seja, mais precisa e rpida.

Diversos tipos de dados podem ser indexados. Como exemplo desses tipos de dados podem ser citados arquivos textos (pdf, doc, txt, etc.), de vdeo, udio e imagem. H particularidades na forma como esses arquivos so indexados e normalmente um mesmo motor de indexao (mecanismo responsvel pela indexao dos dados) no da suporte a indexao de todos os tipos de arquivos. No entanto, a indexao consiste basicamente do mesmo princpio para todos os arquivos, que a organizao dos dados em uma estrutura conhecida como ndice.

Suponha que voc precise pesquisar um arquivo e que este arquivo tenha uma determinada palavra ou frase. Uma abordagem seria a varredura sequencial no arquivo em busca da palavra ou frase desejada, porm essa abordagem peca na confiabilidade dos dados exibidos e no custo de desempenho para a execuo da pesquisa. A utilizao de ndices na recuperao de informaes contribui para minimizar o problema dessa abordagem.

Um ndice pode ser entendido como uma estrutura de dados que permite o rpido acesso aleatrio de palavras armazenadas no seu interior. O conceito subjacente anlogo a um ndice no final de um livro, que lhe permite localizar rapidamente pginas que discutem determinado tema.

Como citado anteriormente, o principal motivo para a utilizao de ndices em uma base de dados poder atingir um melhor desempenho na recuperao desses dados, pois ao pesquisar em fontes de dados no indexadas, a pesquisa feita sequencialmente para cada solicitao levando a um gasto de tempo considervel e processamento desnecessrio.

39

Para um melhor entendimento da importncia da indexao de arquivos, ser detalhada em seguida o processo que um arquivo submetido para a sua indexao e os tipos possveis de ndices que poder ser gerados.

2.3.1 ETAPAS DA INDEXAO

Para a construo de um ndice, alguns passos comuns indexao de dados textuais so necessrios. Esses passos so detalhados a seguir, no intuto de uma melhor compreenso de como composto um ndice.

2.3.1.1 TOKENIZE

Interpretar a frase - A informtica mudou o comrcio mundial - no nenhuma tarefa rdua para uma pessoa que saiba ler e que tenha conhecimento do idioma na qual a mesma foi escrita. No entanto essa tarefa no to simples quando essa interpretao deve ser feita por um sistema computadorizado.

Para a interpretao do texto o computador necessita que o mesmo seja identificado como vrias seqncias de caracteres. Para isso feita a identificao de cada palavra na frase, no qual identificado o incio e o fim de cada uma delas, considerando ainda pontuao, espaos em branco, entre outros. O responsvel em executar esse procedimento um programa chamado de analisador lxico ou tokenizer que tambm so encontrados nos compiladores dos sistemas

operacionais.

O analisador lxico identifica cada token (sequncia de caracteres), e os armazena. Ao fazer isso, o analisador pode guardar outras informaes relevantes sobre aquele token anexadas a ele, tais como lngua, codificao, posio no documento, posio na frase, nmero da linha, tamanho, etc (AMAZONAS, 2007).

40

Figura 9 Texto separado em Tokens aps execuo do analisador lxico.

A figura 9 exibe a sada do texto aps a execuo do analisado lxico no qual separa o mesmo em sequncia de caracteres distintos. Na representao grfica os tokens que no h caracter textual em seu interior a representatividade dos espaos em branco do texto original.

A converso do texto lido para uma sequncia de tokens o primeiro passo para a indexao de documentos textuais. Dando sequncia ao processo de criao do ndice, os tokens aqui criados so encaminhados para o segundo passo: a anlise dos mesmos.

2.3.1.2 ANALYSIS

Aps a anlise lxica do texto original no qual foi obtida uma sequncia de tokens, necessria a execuo da anlise textual dos mesmos, pois nessa etapa feita a verificao dos tokens no relevantes no qual devem ser descartados. Para exemplificar podemos citar como tokens irrelevantes, artigos, preposies, pontuao, espao em branco, entre outros. Tambm nessa fase que so retirados as pontuaes e os acentos, alm da transformao das letras maisculas em minsculas.

Outra caracterstica do analysis que nesse passo da indexao que determinado o idioma no qual o texto foi escrito necessrio para determinar a forma no qual os tokens sero tratados.

A figura 10 exibe a sada do texto aps a anlise dos tokens da figura 9 pelo analysis. Como pode ser observado foram descartados os tokens irrelevantes que

41

na sequncia eram representadas pelos espaos em brancos e acentuao, alm da converso dos caracteres em maisculo para minsculo.

Figura 10 Texto separado em Tokens aps execuo do analysis.

2.3.1.3 STEMMING

Voltando a frase: A informtica mudou o comrcio mundial, que tipo de resultado seria obtido se a pesquisa fosse feita utilizando os termos, mudana no comrcio do mundo? Nesse contexto, na melhor das hipteses, sero exibidos alguns registros que tenha como informao algo relacionado com a palavra comrcio, mas como pode ser observado ignorado dois dados importantes que so as mudanas e a amplitude desta que global.

Para evitar que ocorra o problema mencionado no pargrafo anterior, que o processo de stemming importante na indexao de dados.

O processo de stemming tem como finalidade reduzir os tokens resultantes aps a execuo do analysis retirando-o prefixos, sufixos, plural, flexes verbais bem como qualquer outra flexo existente na palavra original, com o intuito de aumentar o contexto semntico nas futuras pesquisas.

De acordo com as formalidades do idioma, satisfatrio que palavras relacionadas ou derivadas tenham a mesma raiz dentro do ndice. Com isso o ndice ser armazenado com semntica suficiente.

Com base no que foi citado, aps a execuo no processo de stemming nos tokens remanescentes do analysis exibidos na figura 10 possvel obter o resultado conforme figura 11. 42

Figura 11 Texto separado em Tokens aps execuo do stemming.

Com o stemming, uma pesquisa que estava restrita a buscar palavras idnticas a qual foram informadas, pode ser substituda por busca de palavras similares. Para exemplificar, tomando como base o texto da figura 11, pode ser feita a pesquisa utilizando as palavras informtica, informatizao, mudana, mudou, comercio, mundo, mundial, ou seja: a informatizao mudou o comercio do mundo, a informatizao mudou o comercio mundial, a informtica mudou o comercio do mundo, a informtica mudou o comercio mundial e assim por diante.

43

3. MOTORES DE INDEXAO E BUSCAS

Alguns dos principais motores de indexao sero exibidos neste captulo. Como j foi comentado na Introduo deste trabalho, esses motores se tornaram necessrios devido a grande quantidade de dados criada a cada dia. Sua proposta fazer com as informaes geradas por usurios sejam aproveitadas ao mximo, facilitando as buscas dessas informaes.

Foram estudados, alm do Lucene, o Windows Search e o Google Desktop Search, softwares que implementam o conceito de recuperao da informao visando a soluo do problema existente. Os mesmos sero analisados do ponto de vista funcional, mostrando as principais caractersticas de cada um.

3.1 LUCENE

O projeto Lucene uma API (Application Programming Interface) desenvolvida na linguagem de programao Java que faz a indexao de documentos e efetua a pesquisa destes possibilitando um ganho de performance na procura de dados. O seu projeto mantido pelo grupo Apache Software Foundation e tem como licena a Apache License que permite o uso e a distribuio do seu cdigo fonte, assim como dos softwares provenientes dela.

O Lucene tem como caracterstica ser um indexador de altssima performance, no importando a origem dos dados, seu formato ou a linguagem na qual foram escritas. O nico requisito para a indexao dos arquivos que estes possam ser convertidos em um arquivo no formato texto.

Por se tratar de uma API, o Lucene composto por uma srie de funes que possibilita a indexao e a busca de arquivos de diversos formatos (desde que possvel converter em arquivo texto), mas essas funes somente so acessveis atravs do desenvolvimento de aplicaes, pois o Lucene no dispe de uma interface grfica pronta.

44

Atualmente j h implementao do Lucene em outras linguagens de programao podendo ser citadas como exemplo as linguagens C# (.NET), Ruby, Python e C.

3.1.1 ESTRUTURA DE NDICE DO LUCENE

Como descrito no capitulo 3 um ndice uma estrutura de dados que armazena informaes de documentos no qual possibilita a sua localizao com maior facilidade e rapidez. O Lucene tambm dispe dessa estrutura.

A estrutura de um ndice do Lucene pode ser observada na figura 12. Como pode ser visto um ndice composto por um ou mais Document (Documento) e cada documento pode conter um ou mais Field (Campo). Fazendo uma analogia, um documento um objeto que pode ser pesquisado (Lucene in Action, por exemplo) e os campos, os diversos atributos que possibilite a pesquisa do documento (Lucene, por exemplo). Por este motivo o Lucene capaz de indexar arquivos de diferentes formatos, contanto que os mesmos possam ser convertidos para texto.

Na API do Lucene um Document representado por um objeto do tipo org.apache.lucene.document.Document e um Field, tambm representando por um objeto, do tipo org.apache.lucene.document.Field.

Figura 12 Estrutura do ndice do Lucene

45

3.1.2 PROCESSO DE INDEXAO DO LUCENE

Antes da realizao de qualquer operao de indexao ou pesquisa, necessrio informa qual o ndice que dever ser manipulado ou criado se for o caso. Para isso o Lucene encapsula a localizao fsica do ndice em uma classe abstrata, a org.apache.lucene.store.Directory. Essa classe responsvel em indicar a localizao dos ndices a serem pesquisados ou onde os mesmos devero ser criados.

H duas implementaes importantes da classe Directoy. So as classes org.apache.lucene.store.FSDirectory e a org.apache.lucene.store.RAMDirectory. Na primeira os ndices so manipulados no sistema de arquivos e na segunda na memria RAM do Sistema Operacional.

Para que o Lucene efetue a indexao dos dados necessrio que o texto seja extrado dos seus respectivos arquivos. A extrao dessas informaes no fica a cargo do Lucene, pois esta no dispe de ferramenta para tal finalidade, mas sim do desenvolvedor. Como exemplos podem ser citados a API Apache POI capaz de extrair textos do Microsoft Word e Microsoft Excel, o PDFBox para extrair contedo textual de documentos PDF e classes do JDK Java Development Kit (File por exemplo), capaz da extrao de textos de arquivos nos formatos RTF (Rich Text Format) e XML.

Sendo feita uma anlise no texto extrado possvel encontrar informaes no relevantes que no precisa ser incorporadas aos ndices. Como por exemplo, palavras do tipo de, a, e e o so comuns nos textos da lngua portuguesa e por isso no precisam ser indexadas. Alm disso, palavras maisculas e minsculas e acentuadas exigem um tratamento antes da indexao. Para resolver esse problema o Lucene efetua o procedimento de anlise que responsvel pela filtragem das palavras do texto. Essa anlise feita pela implementao da classe abstrata org.apache.lucene.analysis.Analyzer.

46

Por se tratar de uma classe abstrata, a classe Analyzer no pode ser instanciada (criada um objetivo), mas disponibiliza caractersticas para as suas subclasses (classes que podem ser instanciadas e que herdam da primeira).

A StandardAnalyze, org.apache.lucene.analysis.standard.StandardAnalyzer, a implementao default da classe Analyzer, mas podem ser encontradas classes mais especificas para determinados idiomas. Podemos citar a

org.apache.lucene.analysis.br.BrazilianAnalyzer, que a implementao para o portugus brasileiro. Alm disso, a criao de uma Analyzer pode ficar a cargo do desenvolvedor.

Feito o acesso ao arquivo no diretrio indicado e a anlise do mesmo o Lucene cria o documento (Document) e os seus respectivos campos (Field) que sero indexados. Feito isso a indexao do documento (Document) feita pela classe org.apache.lucene.index.indexWriter.

A forma que a indexao feita pela classe indexWriter depende de como foi definida as propriedades para o objeto Field. As propriedades de um campo so: indexed, tokenized e stored.

Um campo indexed indica que o contedo otimizado para pesquisa e um campo stored ter seu contedo armazenado no ndice. Ambos podem ser ou no tokenized que indica se o campo deve ser separado em tokens.

Para uma maior clareza, vamos analisar dois trechos de cdigo: document.add(new Field(conteudo, fReader)); Nesse caso o campo conteudo serve para pesquisar o documento. Ele indexed para acelerar a pesquisa e tokenized para permitir a pesquisa por partes do texto, mas no precisa ser guardado no ndice o texto exato que foi extrado, por isso no stored. document.add(new Field(nomearquivo, nomeCompleto, Field.Store.YES,

Field.Index.UN_TOKENIZED)); 47

J nesse caso, o campo nomearquivo idenfica o documento pelo nome do arquivo. Para que seja possvel exibir o nome do arquivo no qual os documentos foram localizados necessrio que o campo seja stored.

No primeiro exemplo no foi necessrio informar no cdigo os valores das propriedades. Nesse caso o Lucene interpreta que as propriedades devem assumir o valor default.

O trecho de cdigo que segue resume a forma na qual a classe indexWriter armazena um documento no ndice: idxWriter.addDocument(document).

3.1.3 PROCESSO DE BUSCA DO LUCENE

O Lucene pode efetuar a pesquisa de documentos a partir dos ndices indexados como descrito no tpico anterior. A principal classe para a pesquisa a org.apache.lucene.search.IndexSearcher que instanciada referenciando o ndice a ser pesquisado: indexSearcher iSearcher = new IndexSearcher(fsDir).

As implementaes concretas da classe abstrata org.apache.lucene.search.Query define diferentes formas de pesquisa textual. As principais so as

org.apache.lucene.search.TermQuery, que possibilita pesquisa por palavra e org.apache.lucene.search.PhraseQuery, que possibilita a pesquisa por frase, alm da org.apache.lucene.search.FuzzyQuery que aplica na pesquisa algoritmos sofisticados de busca por semelhana.

A classe org.apache.lucene.queryParser.QueryParser capaz de construir o objeto Query apropriado a partir de uma expresso de pesquisa. Alm disso deve ser informado o nome do campo a ser pesquisado e o analisador que processar o texto da expresso. O analisador deve ser o mesmo usado no processo de indexao do documento. O trecho de cdigo que seja resume o processo de pesquisa. QueryParser qParser = new QueryParser(conteudo, new BrazilianAnalyzer()); Query query = qParser.parser(expressaoDeBusca); Hits hits =

iSearcher.search(query); 48

3.1.4 PROCESSO DE REMOO E SUBSTITUIO DO NDICE NO LUCENE

Quando um arquivo apagado importante a remoo da entrada do arquivo correspondente no ndice. No sendo feito esse procedimento, os resultados das pesquisas podem indicar um arquivo que no mais existe. A remoo da entrada feita pela classe org.apache.lucene.indexReader.

Uma

das

maneiras

para

efetuar

remoo

utilizando

mtodo

indexReader.deleteDocuments(Term term). No entanto necessrio construir um objeto org.apache.lucene.index.Term que ser usado para localizar os documentos a serem removidos. Um objeto Term representa uma palavra presente em um campo. O trecho de cdigo a seguir exemplifica o processo de remoo. Term term = new Term(teste.txt, nome); FSDirectory fsDir = FSDirectory.getDirectory(/tmp/idx, false); IndexReader idxReader = IndexReader.open(fsDir); idxReader.deleteDocuments(term); idxReader.close();

No exemplo sero removidos todos os documentos com o nome teste.txt.

Para a substituio de um documento no ndice necessrio remover a entrada existente e inserir a nova entrada.

3.1.5 EXEMPLOS DE APLICAO COM LUCENE

Muitas so as aplicaes, sejam elas web ou desktop, e sites que utilizam o Lucene para a indexao e pesquisa de arquivos. Como site pode ser citado o renomado site de enciclopdia colaborativa Wikipdia (http://pt.wikipedia.org) que utiliza o Lucene como base para a pesquisa interna do seu contedo.

Outra aplicao que deve ser destacada o Nutch. Esta um motor de pesquisa desenvolvida em Java e tem como base o Lucene. A principal caracterstica do 49

Nutch a indexao e pesquisas de pginas Web. Maiores informaes podem ser obtidas no site oficial do mesmo: http://lucene.apache.org/nutch/. No endereo http://wiki.apache.org/lucene-java/PoweredBy pode ser visto todos os projetos, aplicaes e sites que utilizam o Lucene como base.

3.2 WINDOWS SEARCH

O Windows Search um motor representado pelo WDS (Windows Desktop Search), um software independente que pode ser instalado nos sistemas operacionais Windows XP e Windows 2003 Server, ou pelo sistema integrado de busca e organizao do sistema operacional Windows Vista (MICROSOFT, 2009).

O objetivo dessa ferramenta fornecer uma forma mais eficiente de administrao da crescente quantidade de informao digital gerada e maximizar a produtividade ao permitir a obteno de informaes relevantes de maneira mais fcil e rpida (MICROSOFT, 2009).

Ainda segundo a MICROSOFT, (2009), o WDS capaz de indexar e buscar mais de duzentos tipos de arquivos mais comumente usados. Dentre esses tipos esto emails, contatos, documentos e tambm outros formatos, desde que sejam implementadas extenses para eles. Outra caracterstica desta aplicao permitir a obteno de dados sejam eles indexados em seu prprio computador ou a partir de pastas compartilhadas em uma rede local.

A capacidade de pesquisa do Windows Search pode ser estendida de diversas maneiras. Uma dessas alternativas a insero direta de funcionalidades de busca oferecidas pela ferramenta dentro de uma aplicao prpria. Outro ponto que pode ser usado para ampliar as propriedades do Windows Search a adio da capacidade de indexar tipos de dados que no so reconhecidos originalmente pela ferramenta. Alm dessas alternativas, a ferramenta pode ser estendida com diversos outros propsitos que, em geral, derivam desses dois supracitados.

50

A verso mais recente do WDS, 4.0, foi otimizada com recursos que ajudam os gerentes de Tecnologia da Informao a personalizar, implantar e gerenciar facilmente a instalao do Windows Desktop Search para todos os usurios e computadores na organizao. Essa verso possui como vantagens permitir uma implantao rpida, o administrador pode implantar diretivas de busca por grupos de usurios, integrao com a Intranet da empresa, capacidade de ampliao de novos tipos de arquivos e fontes de dados atravs de IFilters - plugin que permite o WDS indexar arquivos de diferentes formatos para que se tornem pesquisveis. Sem um IFilter o contedo de um arquivo no pode ser analisado e indexado pelo motor de busca.

O Windows Search disponibiliza um SDK (Software Development Kit) que deve ser utilizado para acoplar as funcionalidades aplicao desenvolvida. Objetivando facilitar o acesso aos dados indexados pelo Windows Search, est presente nesse SDK uma camada de acesso unificada que torna indiferente tanto o tipo de dado acessado como a aplicao que ser usada para fazer o acesso a ele. O SDK prov implementaes de interfaces que permitem efetuar as principais operaes sobre o ndice criado pelo Windows Search, tais como indexao, pesquisa, reindexao e remoo (desindexao) de dados presentes nesse ndice (MICROSOFT, 2009).

O Windows Search tem como principal vantagem a capacidade de indexar uma variedade muito grande de tipos de arquivos nativamente, tanto na prpria mquina quanto via rede. Outra caracterstica desse motor de indexao o acoplamento com o Sistema Operacional (SO) homnimo ferramenta. Esta pode ser vista como positiva ou negativa, j que por um lado isto limita o seu uso a este SO, porm por outro facilita, teoricamente, a criao de plugins para indexar novos tipos de documentos. Isto porque dispensa a implementao necessria para associar a ferramenta com o novo tipo, caso essa associao j exista no SO.

Entre as desvantagens apresentadas pelo Windows Search esto: o fato de no ser conhecido o mtodo usado para indexao e recuperao da informao, bem como suas etapas (alm de no permitir alter-los); a falta de possibilidade de determinar o modo de ordenao dos resultados, ou como definido o grau de relevncia dos mesmos. A maior limitao do Windows Search , entretanto, a dificuldade 51

apresentada para o desenvolvimento desses plugins para indexar outros tipos de dados que no sejam arquivos, como um banco de dados relacional (onde est boa parte das informaes de uma organizao), por exemplo. A documentao, ao contrrio do que publicado na prpria, insuficiente, complexa e oferece uma grande dificuldade de aprendizagem.

3.3 GOOGLE DESKTOP SEARCH

O Google Desktop Search (GDS) um software similar ao WDS que tem como objetivo facilitar o acesso s informaes geradas a cada momento de maneira crescente. Alm disso, o GDS faz com que no seja necessria a organizao manual dos dados (GOOGLE, 2009). O Google Desktop Enterprise a alternativa do Google Desktop para as empresas. A verso original precisa ser instalada em cada mquina para funcionar. A verso Enterprise instalada no servidor da empresa e automaticamente passa a funcionar em todos os computadores ligados rede, precisando somente de um pequeno aplicativo MSI para rodar em cada mquina.

O GDS contm uma interface de interao com o usurio para que este possa realizar pesquisas em sua base de dados indexada. Esta interface permite que os documentos retornados mediante uma consulta sejam filtrados pelo seu respectivo tipo, e, alm de apresentar o nome desse documento na lista, tambm exibe um breve trecho do mesmo onde os termos da consulta foram encontrados (GOOGLE, 2009).

Uma caracterstica singular do Google Desktop Search a capacidade de criar cpias dos arquivos a cada vez que os mesmos so acessados, e armazenar essa cpia em disco. Dessa forma, os arquivos apagados acidentalmente podem ser recuperados atravs do GDS (GOOGLE, 2009).

Assim como o Google Desktop Search, o Google Desktop Enterprise capaz de indexar e permitir pesquisa textual em diversos tipos de arquivos, tais como: e-mails do Microsoft Outlook E-mail, Outlook Express, Thunderbird; arquivos do Word, Excel, PowerPoint e PDF; conversas do Windows Messenger, Google Talk; histrico do 52

Internet Explorer; Firefox, Mozilla; metadados de arquivos de msica, imagens e vdeo. Alm disso, a ferramenta tambm permite que sejam adicionados ao ndice arquivos presentes em computadores ligados atravs de uma rede local (GOOGLE, 2009).

A maior vantagem da verso para empresas o fato de precisar somente de uma instalao. Isso no s uma economia de tempo, mas tambm de recursos, j que toda a configurao da rede fica no servidor. Atravs desse computador possvel configurar todo o servio do programa que funcionar para todos os computadores da rede, como ativar ou desativar recursos, caminhos ou indexao de determinados tipos de arquivo. Todas as opes e mais algumas exclusivas para empresas como a utilizao dos aplicativos Google Saerch Appliance ou o Google Mini para centralizar todas as pesquisas dos funcionrios, seja em PCs, na Intranet da empresa ou na Internet. Os resultados de busca so exibidos numa interface de fcil navegao que o usurio j conhece, como ilustra a figura 13. Esto disponveis para configurao e controle pelo servidor. Isso centraliza melhor as opes e otimiza as possibilidades da empresa.

Figura 13 - Interface do Google Desktop Enterprise

53

Assim como no WDS, existem algumas possibilidades de extenso das caractersticas do GDS. Para isso fornecido um SDK, que est dividido em quatro APIs (Interface de Programao de Aplicativos): Index, Query, Action, Event

E permite dois tipos de utilizao: 1) o desenvolvimento de plugins para adicionar a capacidade de indexao de novos tipos de arquivos no reconhecidos originalmente pelo GDS e 2) o uso das funcionalidades da aplicao acoplada a uma aplicao prpria, que envia as consultas e recebe os resultados (GOOGLE, 2009).

Assim como o Windows Search, o Google Desktop Search tem seu ponto forte na indexao nativa de vrios tipos de arquivos e tambm em permiti-la ser executada via rede. Ao contrrio da outra ferramenta, no entanto, no diretamente relacionada a nenhum Sistema Operacional, e possui verses para trs sistemas operacionais (Windows, MacOS e Linux). Decorre desse fato, porm, o inverso do que foi relatado na seo anterior com relao ao Windows Search: apesar de sua utilizao no estar limitada a um nico SO, preciso implementar uma srie de cdigos para registrar os novos tipos a serem indexados junto aplicao sempre que acontecer o desenvolvimento de algum plugin.

A falta de transparncia quanto aos mtodos utilizados internamente pelo motor de indexao do GDS tambm um dos problemas que ele possui. Contudo, o GDS fornece, ao menos, a possibilidade de escolha na ordenao dos resultados (relevncia ou data), mas no permite que seja alterada a maneira que essa ordenao definida e, portanto, o modo que os dados so indexados e a informao recuperada.

Novamente a maior desvantagem mostrada, agora pelo Google Desktop Search, diz respeito indexao de novos tipos de dados no indexados nativamente. Ao contrrio do Windows Search, no entanto, o problema no consiste na dificuldade 54

com o desenvolvimento, mas sim na impossibilidade real do desenvolvimento de plugins para indexar certos tipos de dados. Como foi visto no anteriormente, o Google Desktop Search limita a indexao a certos modelos, e no permite, portanto, que sejam indexados dados provenientes de outra fonte de dados que tenha um padro de dados fora dessa lista.

55

4. PROTTIPO

As buscas por informaes se tornam cada dia mais freqentes e de vital importncia dentro das empresas. Os sistemas de gesto so capazes de organizar e disponibilizar os dados inseridos neles. Porm, nem todas as informaes esto contidas dentro desses sistemas. Facilmente conseguimos encontrar planilhas eletrnicas, documentos de texto, como contratos, comunicados internos, recibos, pginas da intranet, etc. que contm informaes de grande utilidade, mas que podero ficar sem uso por se encontrarem espalhadas dentro das organizaes. Atualmente, existem algumas ferramentas capazes de coletar dados em tais bases heterogneas como, por exemplo, o Google Desktop, o Windows Search, dentre outras. Porm tais ferramentas gratuitas so de uso genrico e no fornecem acesso s informaes contidas em bancos de dados institucionais.

O objetivo desta monografia realizar uma anlise comparativa entre o prottipo da ferramenta desenvolvida utilizando a API Lucene e o Hibernate Search e os softwares de indexao Google Desktop e Windows Search. Tais softwares so largamente utilizados e costumam atender as necessidades dos usurios. Estes softwares conseguem indexar uma quantidade de tipos de arquivos bastante diversificada, porm no oferece suporte para indexao de dados de um banco de dados. Diante disto, o projeto visa identificar se o desenvolvimento de uma ferramenta prpria utilizando API Lucene seria capaz de oferecer alguma vantagem em relao aos concorrentes citados. Esta nova aplicao poderia ser desenvolvida de maneira mais ntima com a organizao para a qual se destina, permitindo a escolha dos tipos de arquivos mais utilizados na empresa e at mesmo proporcionando a busca por informaes no banco de dados da instituio. Uma API (Application Programming Interface) uma interface de programao de aplicativo que dispe funcionalidades prontas que facilitam o desenvolvimento de programas.

A aplicao desenvolvida ser submetida a testes comparativos com as ferramentas citadas avaliando o tempo de pesquisa e confiabilidade das buscas com o intuito de identificar as vantagens e desvantagens do desenvolvimento de uma aplicao corporativa ou a utilizao das ferramentas para a indexao de recuperao dos dados. 56

Inicialmente,

no

tpico

4.1,

ser

descrita

as

ferramentas

utilizadas

no

desenvolvimento do prottipo. Em seguida, no tpico 4.2, as estruturas de pacotes do sistema descrevendo as suas respectivas finalidade. Logo aps, no tpico 4.3, as principais operaes criadas utilizando o Hibernate e no tpico 4.4 as operaes criadas utilizando o Lucene. Para finalizar no tpico 4.5 so feito os testes comparativos com o prottipo desenvolvido e as ferramentas Google Desktop e Windows Search. As principais classes do prottipo so ilustradas no Apndice I e as configuraes necessrias do Hibernate e Hibernate Search no Apndice II.

4.1 FERRAMENTAS UTILIZADAS Para o desenvolvimento do prottipo proposto no trabalho foram utilizadas as seguintes ferramentas: JavaServer Faces 1.2 RichFaces 3.3.2 Apache Lucene 2.4.1 Apache Hibernate 3 Apache Hibernate Search 3.1.1 Netbeans 6.8 GlassFish Server Open Source Edition v3 MySQL Server 4.1 JavaServer Faces um framework MVC (Model View - Controll) desenvolvido em Java pela Sun Microsystems com o propsito de tornar o desenvolvimento de aplicaes Web mais rpida e fcil. Por ser MVC ela possibilita a diviso da aplicao em trs camadas no qual separa a aplicao em apresentao (View), controle (Controll) e modelo de negcio (Model). RichFaces uma biblioteca de componentes desenvolvido em Java com a finalidade de estender as funcionalidades e aumentar a produtividade no desenvolvimento de aplicaes JavaServer Faces e foi desenvolvido JBoss Community.

57

Apache Lucene, como descrito no tpico 3.1, uma API de indexao de arquivos textos desenvolvida em Java pela Apache Software Foundation. Hibernate uma API ORM (Object/Relational Mapping) desenvolvida em Java que tem como finalidade tornar mais simples e rpida as operaes com o banco de dados nas plataformas e .Net. Com o Hibernate possvel criar aplicaes

totalmente orientadas a objetos com banco de dados relacional. O Hibernate tambm mantido pela Apache Software Foundation. Hibernate Search um complemento da API Hibernate construda atravs da Apache Lucene e utilizada para indexar banco de dados. Tambm possibilita efetuar pesquisa no banco de dados atravs dos ndices criados. O Hibernate Search tambm mantido pela Apache Software Foundation. Netbeans uma IDE (Integrated Development Environment) para desenvolvimento de aplicativo. Ela utilizada largamente para desenvolvimento na linguagem Java, embora possa ser utilizada para desenvolver em outras linguagens como PHP. Uma IDE um ambiente de desenvolvimento integrado que oferece facilidades na programao dispondo de recursos visuais, facilidade de acesso a base de dados entre outros. O Netbeans mantido pela Sun Microsystems. GlassFish um servidor de aplicao para a plataforma Java Enterprise Edition JEE. usada para rodar as aplicaes web feita em Java. O GlassFish tambm mantido pela Sun Microsystems. MySQL um servidor de banco de dados e mantido pela Sun Microsystems.

58

4.2 DIAGRAMAS DE REQUISITOS 4.2.1 DIAGRAMA DE CASO DE USO A figura 14 ilustra o diagrama de classe do prottipo.

Figura 14 Diagrama de Caso de Uso do prottipo

No diagrama exibido apenas como ator o Usuario. Isto porque as operaes disponveis no prottipo podem ser desempenhadas por qualquer usurio no restringindo o mesmo para um tipo de perfil. O diagrama est dividido por mdulos do sistema que assim seguem: Mdulo Banco de Dados: representa as operaes feitas no banco de dados. representada por Autor, Editora e Livro. usado o Hibernate e Hibernate Search para as operaes do mdulo; Mdulo Preferncia (Indexao): representa o mdulo de indexao do sistema. Para indexao de arquivos textos e pdf usado o Lucene e para os registros do banco de dados usado o Hibernate Search; 59

 Mdulo Home (Pesquisa Arquivo): representa o mdulo de pesquisa dos arquivos indexados pelo Lucene. A pesquisa feita a partir dos ndices criados na indexao dos arquivos texto e pdf. Como forma de simplificar o modelo do diagrama de caso de uso foi subtrada do mesmo as operaes de edio e excluso possvel em alguns dos mdulos listados, a exemplo do mdulo de banco de dados.

4.2.2 DIAGRAMA DE CLASSES O diagrama de classes do prottipo ilustrado na figura 15.

Figura 15 Diagrama de Classes do prottipo

O diagrama lista as classes do prottipo e seus relacionamentos alm de permitir de forma simples, exibe informaes dos mtodos da classe como visibilidade, tipos de parmetros passados, tipo de retorno e atributos da classe e sua visibilidade. No mesmo destaca-se a classe Dao<T>.

60

A classe Dao<T> foi declarada como do tipo genrica, que indicado pelo smbolo <T> e implementa a classe Serializable do pacote padro do Java. Esta classe, Dao<T>, implementa os mtodos para adicionar, remover e atualizar os objetos das classes que a herda. As classes AutorDao, EditoraDao e LivroDao herdam os mtodos da classe Dao<T> e implementam outros mtodos especficos da classe. A classe LuceneDao dispe dos mtodos gerar os ndices do banco de dados e indexar e pesquisar arquivos.

4.2.3 DIAGRAMA DE PACOTES O diagrama de pacotes do prottipo demonstrado na figura 16.

Figura 16 Diagrama de Pacote do prottipo

O diagrama lista os pacotes do prottipo e as dependncias entre eles. Para exemplificar a dependncia ilustrada no diagrama, pode ser citada a dependncia do pacote dao que necessita da existncia do pacote bean para um perfeito funcionamento do prottipo. Pode ser tambm notado as classes que fazem parte dos pacotes.

61

4.3 ESTRUTURA DE PACOTES Para o desenvolvimento do prottipo foi usada a estrutura de pacotes que agrupa as classes Java por caractersticas semelhantes. O pacote de cdigo fonte da aplicao dividido da seguinte forma: br.com.projeto.bean: pacote utilizado para representar as classes do JavaBeans. Nas classes JavaBeans as propriedades da classe s podem ser acessadas pelos mtodos pblicos gets e sets; br.com.projeto.dao: pacote utilizado para representar as classes de acesso a base de dados. Cada classe implementa as operaes de manipulao na base de dados da classe representada pelo JavaBean e a tabela do banco de dados relacional; br.com.projeto.hibernate: pacote que contm o arquivo de configurao do Hibernate (hibernate.cfg.xml) e a classe que cria a sesso do Hibernate. br.com.projeto.managerbean: pacote que contm as classes gerenciadoras dos beans do JavaServer Faces. Com essas classes que os componentes da View (pginas de exibio) interagem com o cdigo fonte (classes Java). br.com.projeto.util: pacote que contm arquivos utilitrios da aplicao.

4.4 OPERAES COM HIBERNATE As classes do pacote Dao define as operaes particulares das classes do JavaBeans no banco de dados utilizando o Hibernate e atravs do ndice utilizado o Hibernate Search.

62

Figura 17 Trecho do cdigo da Classe AutorDao

A classe AutorDao, no qual o trecho de cdigo mostrada na figura 17, define as operaes especificas para a classe Autor do pacote bean. Nela pode ser vista o construtor da classe que chama o construtor da superclasse (Dao) e os mtodos que pesquisa o objeto Autor no banco de dados pela chave primria e pela descrio. Na figura 18 temos outro mtodo importante da classe. O mtodo obterAutorPorIndex obtm os autores gravado no banco de dados utilizando o ndice como pesquisa.

Figura 18 Mtodo que pesquisa autores atravs dos ndices criados

63

Figura 19 Trecho do cdigo da Classe Abstrata Dao

A figura 19 refere-se classe abstrata Dao na qual as classes do pacote Dao estendem. A classe contm as operaes padro das demais classes. Qualquer classe que estenda a classe Dao utilizar dos mtodos adicionar, remover e atualizar como operaes para incluir, remover e atualizar os dados no banco de dados. Ao executar alguma das operaes listadas os ndices referentes aos dados do banco de dados so criados, removidos e atualizados automaticamente.

4.5 OPERAES COM LUCENE

Figura 20 Mtodo que indexa arquivos utilizando o Lucene

64

A figura 20 mostra o mtodo indexarDocumento da classe LuceneDao. Esse mtodo responsvel por indexar os arquivos do tipo texto e pdf. Na linha 40 criado o Document (documento) a ser indexado. Na linha 44 criado o objeto IndexWrite que utilizar o BrazilianAnalyzer como analizador de indexao. Nas linhas 45 a 48 so adicionados ao Document os Fields (campos) criados que contm as informaes do arquivo a ser indexado. A figura 21 mostra o mtodo de pesquisa dos arquivos pelo ndice da classe LuceneDao.

Figura 21 Mtodo que pesquisa arquivos utilizando o Lucene

O mtodo adiciona o valor a ser pesquisado passado na varivel local parmetro no mtodo parser da classe QueryParser que ir procurar no Field de nome contedo a informao passada e utiliza o analisador BrazilianAnalyzer para efetuar a anlise do documento.

65

4.6 TESTES Foram realizados testes para poder analisar comparativamente as ferramentas de busca desenvolvida, o Windows Search e o Google Desktop. Para essa anlise foram utilizados os testes listados a seguir: Processo de indexao Processo de busca Tempo de busca Pesquisa no Banco de dados Tipos de dados indexveis No processo de indexao foi considerada a forma que iniciada a indexao dos arquivos, a possibilidade de selecionar um determinado diretrio para indexao e se suporta indexao de registro de banco de dados. No processo de busca foi avaliado se a pesquisa leva em considerao o contedo dos arquivos, destacando tambm se foi retornado algum arquivo irrelevante. Para o tempo de pesquisa foi considerado o tempo que as ferramentas gastaram para encontrar os arquivos. Para a pesquisa no banco de dados foi analisado se as ferramentas possibilitam a indexao e o tempo e relevncia na pesquisa para consultas utilizando SQL e as consultas pelos ndices criados utilizando lgebra booleana. E por fim, so comparadas as variedades dos tipos de arquivos suportados para indexao. Para realizar os testes citados, foi utilizada arquitetura de hardware e software conforme descrito a seguir: Hardware Computador Pessoal Processador AMD Atholon X2 Dual Core 4000+ 2.11GHz Memria RAM de 4GB DDR2 800MHz HD Sata II 250GB

Software Sistema Operacional Microsoft Windows 7 Ultimate 64Bits

66

4.6.1 PROCESSO DE INDEXAO O processo de indexao do Windows Search automtico. No possvel definir o momento que a indexao ser iniciada. Porm possvel definir o local para indexao. A partir do Windows Vista o Windows Search tornou-se componente integrante do sistema operacional. No Google Desktop o processo de indexao tambm automtico e assim como o Windows Search tambm no possvel definir quando os arquivos devem ser indexados. Mas diferentemente do Windows Search, no possvel selecionar o diretrio onde os arquivos esto salvos para serem indexados. Tanto o Windows Search como o Google Desktop no permite a indexao dos dados salvos em banco de dados. O prottipo desenvolvido permite selecionar o local onde os arquivos encontram-se armazenados. Isso feito por uma interface semelhante a do Windows Explorer, como pode ser visto na figura 22.

Figura 22 Janela de seleo de diretrio do Prottipo

67

A figura 23 exibe o diretrio selecionado para buscar os arquivos a serem indexados.

Figura 23 Diretrio onde esto localizados os arquivos que sero indexados

A figura 24 ilustra como a indexao feita e qual a lista de arquivos indexados.

Figura 24 - Indexao e lista de arquivos indexados

A indexao do banco de dados feita na incluso do registro no banco. A cada incluso de registro o Hibernate Search cria no diretrio configurado um ndice correspondente ao registro salvo. Quando feita a alterao e tambm a excluso de um registro no banco de dados o Hibernate Search atualiza o ndice correspondente. Na operao de atualizao o ndice removido e criado um novo ndice com os dados atualizados. A criao e excluso do ndice so feitas de forma sincronizada com as operaes no banco de dados.

68

4.6.2 PROCESSO DE BUSCA Pesquisando o termo search engine nos arquivos do diretrio

C:\index\documentos, no foi obtido resultado na pesquisa conforme figura 25.

Figura 25 Pesquisa de arquivos indexados no Windows Search

O mesmo resultado encontrado para o Windows Search foi constatado no Google Desktop. Como pode ser visto na figura 26 no houve resultado na pesquisa do termo search engine.

Figura 26 Pesquisa de arquivos indexados no Google Desktop

Efetuando posteriores pesquisas utilizando o Google Desktop e o Windows Search do termo search engine, foi encontrado arquivo, obtendo dessa forma um resultado diferente do ilustrado nas figuras 25 e 26. Isso ocorre porque no possvel determinar o momento que as duas ferramentas devem iniciar a indexao dos arquivos. As figuras 27 e 28 mostram as pesquisas para o mesmo termo.

69

No entanto, como pode ser visto nas figuras 30 a pesquisa do Google Desktop pode retornar arquivos baseando-se no diretrio que o mesmo encontra-se, podendo retornar arquivos no to relevantes como o arquivo teste.txt que no tem nenhuma relao com o termo pesquisado j que no contm nenhum texto no seu contedo.

Figura 27 Resultado de pesquisa no Windows Search

Figura 28 Resultado de pesquisa no Google Desktop

Assim como no processo de indexao do Google Desktop e Windows Search, no processo de indexao do Lucene tambm considerado o contedo do arquivo. Com isso quando feito a pesquisa do termo search engine a busca retorna os arquivos que tm esse termo em seu contedo como pode ser visto na figura 29.

70

Figura 29 Pesquisa de arquivos indexados pelo Lucene

4.6.3 TEMPO DE PESQUISA O Windows Search no exibe o tempo necessrio que o mesmo necessitou para efetuar a pesquisa do termo pesquisado. Ao pesquisar o termo monografia no Google Desktop o aplicativo retorna trs arquivos no tempo de 0,4 segundos. A massa de dados utilizada na pesquisa pelo Google Desktop so todos os arquivos indexados pela ferramenta. A indexao feita para todos os tipos de arquivos definido para indexao nas configuraes da ferramenta que pode ser configurvel pelo usurio final. Para o teste realizado foi utilizada as configuraes default da ferramenta. Quanto relevncia dos registros retornados, em alguns casos os mesmos podem ser considerados irrelevantes, pois retornam registros que contenha o termo pesquisado apenas em diretrios do sistema operacional como pode ser constatado para o arquivo teste.txt, que no h informao no seu contedo para o termo pesquisado, mas que aparece na pesquisa por estar em um diretrio com o valor do termo pesquisado e no no seu contedo, que a proposta do prottipo.

71

Figura 30 Resultado de pesquisa no Google Desktop

O prottipo pesquisa o termo considerando o contedo do arquivo.

Figura 31 Resultado de pesquisa no Prottipo

A figura 31 mostra a mesma pesquisa feita no Google Desktop (GD) no Lucene, porm com os arquivos que tem a palavra monografia no seu contedo. A pesquisa retornou os registros com um tempo de 0.025 segundos conforme ilustrado. A massa de dados para a pesquisa realizada com o prottipo foi de aproximadamente 220MB de arquivos nos formatos texto: pdf, txt, doc, docx, rtf, entre outros e s retorna na pesquisa arquivos que s contenham o termo pesquisado no seu contedo.

72

4.6.4 PESQUISA EM BANCO DE DADOS Na anlise do Google Desktop no foi encontrada nenhuma informao que identificasse que a mesma possibilite a indexao e pesquisa em banco de dados. Em relao ao Windows Search, o mesmo possibilita a indexao de arquivos em Access. No foi identificado nenhuma opo que possibilitasse a indexao de outros bancos de dados a exemplo do MySQL. Uma das grandes vantagens na utilizao do Hibernate Search na indexao dos dados do banco de dados a possibilidade de ter as diversas formas de pesquisa que o mesmo oferece. A figura 32 mostra o resultado da busca para pesquisa do termo Scott utilizando a forma tradicional com SQL para pesquisar no banco de dados. A tabela pesquisada contm um total de 25 registros. Nessa consulta so retornados trs registros.

Figura 32 Resultado da pesquisa para o termo Scott

Quando a pesquisa do registro feita utilizando os ndices criados utilizando o mesmo termo (Scott) so retornados os mesmos registros que a pesquisa anterior, porm o resultado obtido de forma mais rpida. Porm quando a consulta feita utilizando lgebra booleana, utilizando os smbolos + (mais), - (menos), * (asterisco), entre outros para restringir ou ampliar a consulta, s pesquisas feitas pelo ndice tornam-se mais eficaz como veremos nas demais consultas. As consultas SQL tambm podem conter pesquisa baseadas em lgebra booleana, porm o tipo de pesquisa ser definido pelo programador no possibilitando a consulta para um usurio final com uma interface simples. No entanto, utilizando o Hibernate Search a pesquisa utilizando lgebra booleana torna-se mais simples para o usurio.

73

A figura 33 mostra o resultado da pesquisa pelo ndice utilizando lgebra booleana utilizando o termo Scott~. O termo de pesquisa indica que deve ser pesquisado qualquer registro que seja semelhante com Scott.

Figura 33 - Resultado da pesquisa para o termo Scott usando til

Quando feita a pesquisa diretamente no banco de dados no exibido nenhum registro, pois a pesquisa procura o termo Scott~, porm so existe nada no banco com essa informao. Outras formas de pesquisa tambm podem ser feitas. A figura 34 mostra o resultado da consulta Scott +urman. A consulta procura o registro no banco que contenha Scott e Urman.

Figura 34 - Resultado da pesquisa para o termo Scott usando o smbolo +

Na figura 35 exibe o resultado da consulta passando Scott urman como parmetro. A consulta procura os registros no banco que contenha Scott, mas que no contenha Urman.

Figura 35 - Resultado da pesquisa para o termo Scott usando o smbolo -

74

Alm das consultas ilustradas nas figuras 34 e 35, outra forma de pesquisa que pode ser feita com o uso do asterisco (*) que usado para substituir uma seqncia de caracteres.

4.6.5 TIPOS DE DADOS INDEXADOS O Windows Search permite a indexao de muitos tipos de arquivos. As extenses suportadas variam desde arquivos texto at arquivos multimdias. Para citar alguns arquivos suportados pelo Windows Search podem ser citados arquivos pdf, doc, wma, zip, HTML, entre tantos outros. Assim como o Windows Search o Google Desktop tambm permite a indexao de uma grande variedade de tipos de arquivos. Como exemplo pode ser listado arquivos ppt, pdf, txt. Porm tanto o Windows Search quanto o Google Desktop no permite a indexao dos dados de um banco de dados. O prottipo proposto permite a indexao de arquivos texto e dos registros salvo em banco de dados. Isso possvel porque o Lucene efetua a indexao de qualquer arquivo que possa ser convertido em texto e o Hibernate Search permite a indexao dos registros do banco de dados. Para simplificar o exemplo foram utilizadas apenas as extenses definida na varivel extenso conforme figura 36.

Figura 36 Extenses usadas na indexao pelo Prottipo

75

4.6 .6 RESULTADOS DOS TESTES Neste item sero demonstrados os resultados obtidos dos testes realizados.
Tabela 2: Quadro comparativo dos testes

Quadro Comparativo dos Testes Prottipo Google Desktop Pode ser iniciado conforme desejado pelo usurio. A Processo indexao do banco de de Automtico dados automtica, porm indexao pode ser feita de forma manual.

Windows Search

Automtico

Pesquisa o arquivo pelo contedo, porm Pesquisa o arquivo pelo como a contedo, porm como a indexao no indexao no feita de Pesquisa o termo pelo feita de forma Processo forma imediata pode ser contedo do arquivo que foi imediata pode ser de busca exibido resultados indexado exibido errados quando o arquivo resultados ainda no tenha sido errados quando o indexado arquivo ainda no tenha sido indexado A pesquisa feita de Mostrou-se mais rpido nas forma rpida, mas Tempo de buscas de arquivos No mostra o necessitando de um busca comparando com as buscas tempo de busca tempo maior que a do Google Desktop pesquisa do Prottipo No foi identificado Demonstrou ser mais rpido suporte para Pesquisa do que a forma utilizada com No foi identificado indexao com no Banco SQL e suporta consultas suporte para indexao bando de dados, de dados com termos da lgebra com bando de dados com exceo de booleana arquivos do Access Tipos de Suporta arquivo texto e Vasta variedade de Vasta variedade dados registros do banco de dados arquivos de arquivos indexveis No quadro comparativo ilustrado na tabela 2 so descritos os resultados obtidos nos testes efetuados utilizando o prottipo desenvolvido e as ferramentas GD e WS conforme descrito nos tpicos que antecederam. 76

CONCLUSO

O estudo da rea de recuperao da informao de grande importncia para a comunidade de sistemas da informao. Com a exploso do nmero de documentos e usurios na Web, modelos de recuperao da informao passaram a ser fundamentais e de grande ajuda para os usurios.

A soluo desse problema encontra resposta parcial nos motores de indexao de dados existentes. Com os dados indexados, o acesso aos mesmos facilitado, agilizado e reduz a quantidade de informao no aproveitada. Contudo, apesar de possurem caractersticas que visam a soluo do problema, esses motores no apresentam solues completas.

Conhecendo-se as principais deficincias dos mecanismos disponveis atualmente no mercado e pr-estabelecendo os requisitos para uma possvel soluo deste problema, este trabalho props-se desenvolver um prottipo com o objetivo de atender a real necessidade do usurio que busca por informaes potencialmente relevantes e depois fazer uma anlise comparativa com os dois principais sistemas de busca existentes hoje.

Utilizando-se da simplicidade encontrada na API do Apache Lucene foi desenvolvida a aplicao prottipo que permite a indexao de arquivos textos e sua posterior recuperao de forma rpida e precisa. Alm disso, a aplicao tambm possibilita a indexao dos registros de um determinado bando de dados aproveitando-se da API do Hibernate Search para a citada.

O sistema implementando demonstra essencialmente a utilidade do Lucene, na indexao de arquivos textos, e do Hibernate Search, na indexao de dados contidos em banco de dados, em projetos especficos no qual o mesmo pode ser desenvolvido com caractersticas especficas de cada cliente sem a perda de desempenho e confiabilidade no armazenamento e recuperao desses dados.

A concepo desse modelo levou em considerao a restrio de indexao por parte do Lucene a arquivos que podem ser convertidos para texto no considerando 77

os demais arquivos suportados pelas ferramentas WS e GD. No entanto destaca-se o suporte a indexao de banco de dados com o Hibernate Search no qual no suportado pelas ferramentas anteriores citadas.

Conforme demonstrado na etapa de realizao dos testes, a aplicao desenvolvida atende aos requisitos previamente estabelecidos, demonstrando uma maior eficincia no processo de recuperao de informaes potencialmente relevantes ao usurio considerando o que foi proposto no prottipo que retornar registros que contenham o termo pesquisado em seu contedo, em detrimento com o GD e o WS que demonstrou informaes no muito confiveis nas pesquisas e a impossibilidade do suporte a banco de dados.

Com as informaes comparativas obtidas foi possvel concluir que o GD e WS so boas ferramentas para indexao e pesquisa de arquivos indexados para usurios finais, porm para utilizao corporativa as mesmas pecam com a falta de suporte a banco de dados, como informado no foi possvel detectar o suporte a banco de dados. Em se tratando do suporte aos tipos de arquivos indexados as duas ferramentas citadas possibilitam a indexao de uma maior variedade de arquivo.

Para um melhor aproveitamento da variedade de arquivos indexados que o GD e WS oferecem, as proprietrias das ferramentas, respectivamente Google e Microsoft, desenvolveram as verses Enterprise, destinada para empresas. A verso Enterprise do Google possibilita a utilizao de forma distribuda no qual instalada no servidor e pode oferecer integrao a intranet corporativa. No foi obtido sucesso na instalao da verso Enterprise do WS, porm o mesmo tambm possibilita a utilizao distribuda e integrao com o servio de controle de usurio da rede corporativa.

Como sugesto de trabalhos futuros prope-se uma aplicao utilizando uma estrutura com um grande volume de dados, pois os testes realizados neste trabalho foram em mquinas pessoais. Sugere-se tambm que as verses Enterprise do Google e do Windows Search sejam configuradas em servidor, ou numa pequena rede, para que suas funcionalidades possam ser testadas e analisadas. Outra sugesto criar uma aplicao para indexar dados heterogneos (e-mails, textos, 78

planilhas, pginas Web) e tambm uma base de dados Oracle e outra em SQL Server.

79

REFERNCIAS BIBLIOGRFICAS AJAX REVERSO: Conhecendo o Apache. Implemente recursos completos de pesquisa. [S.l.]: Java Magazine, mar. 2008. Mensal. AMAZONAS, Andr Mano. Um modelo de integrao para motores de indexao de dados. 2007. Dissertao (Grau de Bacharel em Cincia da Computao), Universidade Federal da Bahia, Salvador Bahia. APACHE SOFTWARE FOUNDATION. Lucene 2.4.1 API. Disponvel em: <http://lucene.apache.org/java/2_4_1/api/index.html>. Acesso em: 13 jan. 2010. APACHE SOFTWARE FOUNDATION (Org.). HIBERNATE - Relational Persistence for Idiomatic Java: Hibernate Reference Documentation. [S.l.]: Hibernate, [200-?]. 65 p. Disponvel em: <http://www.hibernate.org/docs.html>. Acesso em: 02 mar. 2010. APACHE SOFTWARE FOUNDATION (Org.). Hibernate Search: Apache Lucene Integration. [S.l.]: Hibernate, [200-?]. 65 p. Disponvel em: http://www.hibernate.org/subprojects/search/docs.html>. Acesso em: 02 mar. 2010. EIS, Diego. A WEB Semntica. Disponvel em: <http://www.tableless.com.br/a-websemantica>. Acesso em: 05 abr. 2010. GOOGLE. Recursos: Saiba mais sobre os recursos que tornam o Google Desktop to til. Disponvel em: <http://desktop.google.com/pt/BR/features.html>. Acesso em: 20 abr. 2010. GOSPODNETIC, Otis; HATCHER, Erik. Lucene in Action A guide to Java search engine, 2005. GUERRA, Glaucio. Possibilitando alta performance na indexao com o Apache Lucene. Disponvel em: <http://www.devmedia.com.br/articles/post-4681Possibilitando-alta-performance-na-indexacao-com-o-Apache-Lucene-Parte-I.html>. Acesso em: 20 mar. 2010. HOWSTUFFWORKS BRASIL. Como funciona a web semntica. Disponvel em: <http://informatica.hsw.uol.com.br/web-semantica.htm>. Acesso em: 10 abr. 2010. MEHMERI, Rafael Ribeiro Soares; SILVA, Rodrigo Dantas. PROTTIPO DE SOLUO DE RECUPERAO DE INFORMAO UTILIZANDO O APACHE LUCENE. 2008. 64 f. Dissertao (Graduao) - Universidade Catlica Do Salvador, Salvador, 2008. MICROSOFT. Windows Desktop Search. Disponvel em: <http://www.microsoft.com/brasil/windows/desktopsearch/default.mspx>. Acesso em: 25 abr. 2010.

80

RIBEIRO, Adagenor Lobato. As Camadas da Arquitetura da Web Semntica. Disponvel em: <http://adagenor.blogspot.com/2008/03/as-camadas-da-arquiteturada-web.html>. Acesso em: 26 mar. 2010.

W3C. RDF: Resource Description Framework (RDF). Disponvel em: <http://www.w3.org/RDF/>. Acesso em: 10 dez. 2010.

W3C. Semantic Web. Disponvel em: <http://www.w3.org/standards/semanticweb/>. Acesso em: 02 abr. 2010.

81

APNDICE I PRINCIPAIS CLASSES Classe Arquivo

package br.com.projeto.bean; public class Arquivo { private String diretorio; private String nome; private String path; public Arquivo(){} public String getDiretorio() { return diretorio; } public void setDiretorio(String diretorio) { this.diretorio = diretorio; } public String getNome() { return nome; } public void setNome(String nome) { this.nome = nome; } public String getPath() { return path; } public void setPath(String path) { this.path = path; } }

Classe Autor
package br.com.projeto.bean; import import import import import import java.io.Serializable; java.util.Collection; javax.persistence.*; org.hibernate.annotations.Cascade; org.hibernate.annotations.CascadeType; org.hibernate.search.annotations.*;

@Entity @Table(name="autor", schema="projeto") @SequenceGenerator(name="seq_autor", sequenceName="id") @Indexed public class Autor implements Serializable{ private static final long serialVersionUID = 1L; public Autor(){} @Id @GeneratedValue(strategy=GenerationType.AUTO, generator="seq_autor") @DocumentId private int id;

82

@Column(name="nome") @Field(index=Index.TOKENIZED, store=Store.YES) private String nome; @Column(name="email") private String email; @OneToMany(mappedBy="autor", fetch=FetchType.LAZY) @Cascade(CascadeType.ALL) @ContainedIn private Collection<Livro> livros; public public public public public public public public } } int getId() { return id; } String getNome() { return nome; } String getEmail() { return email; } Collection<Livro> getLivros() { return livros; } void void void void setId(int id) { this.id = id; } setNome(String nome) { this.nome = nome; } setEmail(String email) { this.email = email; } setLivros(Collection<Livro> livros) { this.livros = livros;

Classe AutorDao
package br.com.projeto.dao; import import import import import import import import import import import import br.com.projeto.bean.Autor; java.util.HashMap; java.util.List; java.util.Map; org.apache.lucene.analysis.br.BrazilianAnalyzer; org.apache.lucene.queryParser.ParseException; org.apache.lucene.queryParser.QueryParser; org.hibernate.Query; org.hibernate.Transaction; org.hibernate.search.FullTextQuery; org.hibernate.search.FullTextSession; org.hibernate.search.Search;

public class AutorDao extends Dao{ public AutorDao(){ super(Autor.class); } public Autor obterPorPK(int codigo) { return (Autor)this.getSession().get(Autor.class, codigo); } public List<Autor> obterAutorPorFiltro(String nome) throws Exception{ List<Autor> result; try{ Query query; query = this.getSession().createQuery("from Autor a where a.nome like :fnome"); query.setString("fnome","%" + nome + "%"); result = (List<Autor>)query.list(); }catch(Exception e){ throw new Exception("Erro ao pesquisar Autor."); } return result; }

83

public List<Autor> allAutor() throws Exception{ List<Autor> result; try{ Query query; query = this.getSession().createQuery("from Autor"); result = (List<Autor>)query.list(); }catch(Exception e){ throw new Exception("Erro ao listar todos os Autores."); } return result; } public List<Autor> obterAutorPorIndex(String s) throws ParseException{ List<Autor> result; if (!s.isEmpty()){ Map<String, Object> param = new HashMap<String, Object>(); FullTextSession luceneSession = Search.getFullTextSession(this.getSession()); org.apache.lucene.search.Query luceneQuery; StringBuilder sBuilder = new StringBuilder(); QueryParser parser = new QueryParser("nome", new BrazilianAnalyzer()); param.put("pesquisa", s); for (String key:param.keySet()){ sBuilder.append("" + param.get(key)); } luceneQuery = parser.parse(sBuilder.toString()); FullTextQuery fullTextQuery luceneSession.createFullTextQuery(luceneQuery, Autor.class); result = fullTextQuery.list(); }else{ result = null; } return result; } =

public void geraIndiceAutor(){ FullTextSession fullTextSession = Search.getFullTextSession(this.getSession()); Transaction tx = fullTextSession.beginTransaction(); List<Autor> autores = fullTextSession.createQuery("from Autor").list(); for (Autor autor:autores){ fullTextSession.index(autor); } tx.commit(); } }

Classe LuceneDao
package br.com.projeto.dao; import br.com.projeto.bean.Arquivo; import java.io.File;

84

import import import import import import import import import import import import import import

java.io.FileReader; java.util.ArrayList; java.util.Iterator; java.util.List; org.apache.lucene.analysis.br.BrazilianAnalyzer; org.apache.lucene.document.Document; org.apache.lucene.document.Field; org.apache.lucene.index.IndexWriter; org.apache.lucene.queryParser.QueryParser; org.apache.lucene.search.Hit; org.apache.lucene.search.Hits; org.apache.lucene.search.IndexSearcher; org.apache.lucene.search.Query; org.apache.lucene.store.Directory;

public class LuceneDao{ public LuceneDao(){ } public void geraIndiceBanco(){ AutorDao autorDao = new AutorDao(); EditoraDao editoraDao = new EditoraDao(); LivroDao livroDao = new LivroDao(); autorDao.geraIndiceAutor(); editoraDao.geraIndiceEditora(); livroDao.geraIndiceLivro(); autorDao = null; editoraDao = null; livroDao = null; } public void indexarDocumento(File arquivo, Directory diretorio){ Document documento = new Document(); IndexWriter indexWrite = null; try{ indexWrite = new IndexWriter(diretorio, new BrazilianAnalyzer(), IndexWriter.MaxFieldLength.UNLIMITED); indexWrite.setUseCompoundFile(false); documento.add(new Field("arquivo", arquivo.getName(), Field.Store.YES, Field.Index.NO)); documento.add(new Field("conteudo", new FileReader(arquivo))); documento.add(new Field("diretorio", arquivo.getParent(), Field.Store.YES,Field.Index.NO)); documento.add(new Field("path", arquivo.getPath(), Field.Store.YES, Field.Index.NO)); indexWrite.addDocument(documento); indexWrite.close(); }catch(Exception e){ e.printStackTrace(); } } public List<Arquivo> pesquisaArquivos(String parametro, Directory diretorio){ ArrayList<Arquivo> documentos = new ArrayList<Arquivo>(); try {

85

IndexSearcher indexSearcher = new IndexSearcher(diretorio); QueryParser qParser = new QueryParser("conteudo", BrazilianAnalyzer()); Query query = qParser.parse(parametro); Hits hits = indexSearcher.search(query); Iterator<Hit> i = hits.iterator(); Document doc = new Document(); while (i.hasNext()){ Arquivo arq = new Arquivo(); Hit hit = i.next(); doc = (Document)hit.getDocument(); arq.setDiretorio(doc.get("diretorio").toString()); arq.setNome(doc.get("arquivo").toString()); arq.setPath(doc.get("path").toString()); documentos.add(arq); } indexSearcher.close(); } catch (Exception ex) { ex.printStackTrace(); } return documentos; } } new

Classe LuceneFaces
package br.com.projeto.managerbean; import import import import import import import import import import import br.com.projeto.bean.Arquivo; br.com.projeto.dao.LuceneDao; br.com.projeto.util.Cronometro; java.io.File; java.io.IOException; java.util.ArrayList; java.util.List; javax.faces.event.ActionEvent; javax.swing.JFileChooser; org.apache.lucene.store.Directory; org.apache.lucene.store.FSDirectory;

public class LuceneFaces { private File arquivo; private Directory diretorio; private String nomeBusca; private List<Arquivo> documentos; private List<Arquivo> documentosIndexados; private Arquivo arq; private boolean subdiretorio; private int contador; private boolean render; private String radio; private Arquivo documento; private float tempoDecorrido = 0; private Cronometro cronometro; private String pagina; private String dirArquivos; private String[] extensao = {".doc", ".docx", ".txt", ".xml", ".rtf", ".docx", ".odt", ".docx", ".dot", ".htm", ".html", ".wps", ".xhtml"};

86

private LuceneDao luceneDao = new LuceneDao(); public LuceneFaces(){ cronometro = new Cronometro(); documento = new Arquivo(); } public void indexarDocumento(){ luceneDao.indexarDocumento(arquivo, diretorio); setContador(getContador() + 1); if (contador > 0) setRender(true); } public void indexarDocumentos(ActionEvent event) { contador = 0; render = false; File diretorioDoArquivo = new File(this.getDirArquivos()); documentosIndexados = new ArrayList<Arquivo>(); if (this.getRadio().equals("2")){ cronometro.iniciarCronometro(); luceneDao.geraIndiceBanco(); setTempoDecorrido(cronometro.finalizarCronometro()); }else if (this.getRadio().equals("3")){ luceneDao.geraIndiceBanco(); this.setDiretorio(this.buscaDiretorio()); cronometro.iniciarCronometro(); this.listar( diretorioDoArquivo, 0); setTempoDecorrido(cronometro.finalizarCronometro()); }else{ this.setDiretorio(this.buscaDiretorio()); cronometro.iniciarCronometro(); this.listar( diretorioDoArquivo, 0); setTempoDecorrido(cronometro.finalizarCronometro()); } } /** Exibe uma listagem do arquivo ou diretrio. */ public void listar( File diretorioDoArquivo, int nivel) { if (diretorioDoArquivo.isDirectory()) { File[] lista= diretorioDoArquivo.listFiles(); for (int i= 0; i < lista.length; i++){ if (lista[i].isFile()){ String a = lista[i].getPath(); a = a.replace("\\", "/"); arquivo = this.buscaArquivo(a); arq = new Arquivo(); if (this.getRadio().equals("0")){ if (this.verificaExtensaoTexto(arquivo.getName())){ this.indexarDocumento(); arq.setNome(arquivo.getName()); arq.setDiretorio(arquivo.getParent()); arq.setPath(arquivo.getPath()); documentosIndexados.add(arq); } }else if (this.getRadio().equals("1")){ if (arquivo.getName().toLowerCase().endsWith(".pdf")){ arq.setNome(arquivo.getName());

87

arq.setDiretorio(arquivo.getParent()); arq.setPath(arquivo.getPath()); documentosIndexados.add(arq); } } arq = null; } if ( isSubdiretorio() ){ listar( lista[i], nivel+1); } } } } //parte do cdigo omitido }

88

APNDICE II CONFIGURAES CONFIGURANDO O HIBERNATE SEARCH EM UM PROJETO HIBERNATE Para persistir os dados em um banco de dados utilizado o Hibernate como a ferramenta ORM. O Hibernate oferece uma maior facilidade e rapidez na implementao da camada de persistncia de dados em comparao com o JDBC (Java Database Connectivity) que utiliza instruo SQL para o mesmo. O Hibernate Search, como j mencionado, possibilita que as informaes salvas no banco de dados possam ser indexadas e pesquisadas de forma mais rpida e diversificada. No entanto para que o Hibernate Search esteja disponvel na aplicao faz-se necessrio a sua configurao no arquivo de configurao do Hibernate. A figura 37 exibe o trecho arquivo de configurao.

Figura 37 Trecho do arquivo de configurao

A primeira propriedade define o tipo de armazenamento dos incides e a segunda o local de armazenamento do ndice. FSDirectoryProvider define que os ndices devem ser armazenados em disco. A outra forma de armazenamento do ndice em memria que tem como valor RAMDirectoryProvider.

Figura 38 Configurao dos ouvintes do Hibernate Search

89

A figura 38 mostra a configurao dos ouvintes do Hibernate Search. Quando a operao de insert, delete ou update ocorre para um registro que tenha sido indexado, o Hibernate Search executa o mesmo evento para o ndice.

MAPEAMENTO DE CLASSE UTILIZANDO O HIBERNATE As classes do pacote bean contm os JavaBeans que a representao de um objeto da tabela de um banco relacional. Utilizando as anotaes do Hibernate possvel fazer o relacionamento entre as propriedades da classe e as colunas da tabela do banco de dados.

Figura 39 Configurao de classe com o Hibernate e Hibernate Search

Na figura 39 tm-se as seguintes informaes: na linha 1 feita a declarao do pacote onde a classe foi criada. Na linha 23 a anotao indica que a classe poder ser persistida pelo Hibernate. Na linha 24 indicado o nome da tabela que a classe vai representar (autor) e o database onde est localizada a tabela (projeto). A linha 25 define a relao da chave primria da tabela e a propriedade da classe e na linha 26 a anotao do Hibernate Search indica que a classe deve ser indexada. Para que o objeto criado da classe possa ser persistido pelo Hibernate a classe deve ser Serializable (serializada).

90

A figura 40 complementa a classe Autor.

Figura 40 Configurao de classe com o Hibernate e Hibernate Search (complemento)

A anotao @Id na linha 40 indica qual a propriedade da classe a chave primria na tabela. @Column relaciona a propriedade da classe com a coluna da tabela. @OneToMany define a forma de relacionamento das tabelas autor e livro. Nesse caso definido que um autor pode ter um ou mais livros publicados. Alm das anotaes citadas, importante notar tambm as anotaes do Hibernate Search @DocumentId e @Field. A primeira identifica o documento criado e a segunda as propriedades que sero indexadas da classe.

91