indexação de arquivos texto: uma contribuição para o projeto

UNIVERSIDADE DO PLANALTO CATARINENSE
DEPARTAMENTO DE CIÊNCIAS EXATAS E TECNOLÓGICAS
CURSO DE INFORMÁTICA
(BACHARELADO)
INDEXAÇÃO DE ARQUIVOS TEXTO: UMA CONTRIBUIÇÃO PARA
O PROJETO OPENGED
Relatório do Trabalho de Conclusão de
Curso submetido à Universidade do
Planalto Catarinense para obtenção dos
créditos de disciplina com nome
equivalente no curso de Informática Bacharelado.
ISMAEL FRANCISCO ANTUNES DOS SANTOS
LAGES, NOVEMBRO DE 2002.
UNIVERSIDADE DO PLANALTO CATARINENSE
DEPARTAMENTO DE CIÊNCIAS EXATAS E TECNOLÓGICAS
CURSO DE INFORMÁTICA
(BACHARELADO)
INDEXAÇÃO DE ARQUIVOS TEXTO: UMA CONTRIBUIÇÃO PARA
O PROJETO OPENGED
Relatório do Trabalho de Conclusão de
Curso submetido à Universidade do
Planalto Catarinense para obtenção dos
créditos de disciplina com nome
equivalente no curso de Informática Bacharelado.
ISMAEL FRANCISCO ANTUENS DO SANTOS
Orientador: Prof. Angelo Augusto Frozza,
Esp.
LAGES, NOVEMBRO DE 2002.
INDEXAÇÃO DE ARQUIVOS TEXTO: UMA CONTRIBUIÇÃO PARA O
PROJETO OPENGED
ISMAEL FRANCISCO ANTUNES DOS SANTOS
ESTE RELATÓRIO, DO TRABALHO DE CONCLUSÃO DE CURSO, FOI
JULGADO ADEQUADO PARA OBTENÇÃO DOS CRÉDITOS DA
DISCIPLINA DE TRABALHO DE CONCLUSÃO DE CURSO DO VIII
SEMESTRE, OBRIGATÓRIA PARA OBTENÇÃO DO TÍTULO DE:
BACHAREL EM INFORMÁTICA
Prof. Angelo Augusto Frozza, Esp.
Orientador
BANCA EXAMINADORA:
Prof. Wilson Castello Branco Neto, M.
Eng.
UNIPLAC
Prof. João Soares de Oliveira Neto
UNIPLAC
Prof. Angelo Augusto Frozza, Esp.
Supervisor de TCC
Prof. Alexandre Perin de Souza
Coordenador de Curso
Lages, 27 de Novembro de 2002
iv
Dedico este trabalho a meus pais, pelo
apoio que me deram para a conclusão deste
curso, quando nos momentos difíceis me
falavam que o conhecimento é a maior
riqueza de um Homem.
Dedico também este trabalho aos membros
do Projeto OpenGED, que nos últimos dias
se dedicaram integralmente à conclusão do
Projeto.
Agradeço a toda a minha família, pelo
incentivo, e credibilidade que nas maiores
dificuldades jamais duvidaram do meu
potencial.
Agradeço a meu orientador, Prof. Angelo
Augusto Frozza pela paciência e auxílio na
elaboração deste trabalho.
SUMÁRIO
LISTA DE FIGURAS..............................................................................................VIII
LISTA DE QUADROS............................................................................................... IX
LISTA DE SIGLAS ......................................................................................................X
RESUMO ..................................................................................................................... XI
ABSTRACT................................................................................................................... 1
1. INTRODUÇÃO .............................................................................................................. 2
1.1. Apresentação............................................................................................................ 2
1.2. Definição do problema............................................................................................. 3
1.3. Justificativa .............................................................................................................. 4
1.4. Objetivo geral .......................................................................................................... 5
1.5. Objetivos específicos ............................................................................................... 5
1.6. Metodologia ............................................................................................................. 6
2. INDEXAÇÃO DE DOCUMENTOS................................................................................... 8
2.1. Problemas com a indexação..................................................................................... 8
2.2. Estruturas de armazenamento .................................................................................. 9
2.2.1. Arquivos Invertidos...........................................................................................................9
2.2.2. Árvores Trie ....................................................................................................................11
2.2.3. Árvores PAT....................................................................................................................11
2.2.4. Árvores RD-Tree.............................................................................................................12
2.3. Conclusão............................................................................................................... 16
3. O PROJETO OPENFTS............................................................................................. 18
3.1. Motivação .............................................................................................................. 18
3.2. Descrição do componente OpenFTS ..................................................................... 19
3.2.1. Requisitos de software ....................................................................................................20
3.2.2. Preparando o OpenFTS para o uso................................................................................22
3.2.3. Estrutura de uma base de dados do OpenFTS................................................................24
3.2.4. Parser..............................................................................................................................26
3.2.5. Dicionário .......................................................................................................................28
3.3. Conclusão............................................................................................................... 29
4. SINTAXE DE USO DO OPENFTS ............................................................................... 31
4.1. Preparando o banco de dados................................................................................. 31
vii
4.2. Indexando documentos .......................................................................................... 33
4.3. Pesquisando documentos indexados...................................................................... 34
4.4. Estatística de proximidade ..................................................................................... 35
4.5. Atualizando documentos indexados ...................................................................... 35
4.6. Conclusão............................................................................................................... 36
5. ANÁLISE DO FUNCIONAMENTO DO OPENFTS ...................................................... 38
5.1. Definição da base de dados.................................................................................... 38
5.2. Inicializando o banco de dados.............................................................................. 39
5.3. Indexando documentos .......................................................................................... 39
5.4. Analisando a pesquisa............................................................................................ 41
5.5. Conclusão............................................................................................................... 44
6. CONSIDERAÇÕES FINAIS .......................................................................................... 46
REFERÊNCIAS BIBLIOGRÁFICAS...................................................................... 48
LISTA DE FIGURAS
FIGURA 1
FIGURA 2
FIGURA 3
FIGURA 4
FIGURA 5
FIGURA 6
FIGURA 7
FIGURA 8
FIGURA 9
FIGURA 10
FIGURA 11
- Estrutura de arquivos invertidos ................................................
- Estrutura de uma árvore Trie .....................................................
- Estrutura de uma árvore PAT.....................................................
- Estrutura de uma árvore RD-Tree..............................................
- Arquitetura de acesso ao banco de dados PostgreSQL de uma
aplicação Perl...............................................................................
- Exemplo da execução do script init.pl ................................
- Número de lexemas indexados ..................................................
- Exemplo da execução do script index.pl ..............................
- Exemplo da execução do script search.pl ............................
- Exemplo da execução do script search.pl..............................
- Exemplo da execução do script search.pl..............................
9
10
11
12
21
40
40
41
42
42
43
LISTA DE QUADROS
QUADRO 1
QUADRO 2
QUADRO 3
QUADRO 4
QUADRO 5
QUADRO 6
QUADRO 7
QUADRO 8
- Estrutura da tabela txt........................................................... 24
- Estrutura da tabela index .......................................................24
- Estrutura da tabela fts_conf ............................................... 25
- Conteúdo da tabela fts_conf ................................................25
- Estrutura da tabela fts_unknown_lexem .......................... 26
- Descrição dos tipos de lexema reconhecidos pelo parser ........ 26
- Fragmento do script init.pl ............................................... 31
- Fragmento do script contendo a instrução SQL gerada para uma
requisição de consulta ..................................................................33
QUADRO 9 - Fragmento do script delete.pl .......................................... 35
QUADRO 10 - Resultados obtidos pelo script de consulta do OpenFTS ..........44
LISTA DE SIGLAS
AIIM
- Avant Imaging & Information Management Inc.
CD-R
- Compact Disk Read
CENADEM - Centro Nacional de Desenvolvimento do Gerenciamento da
Informação
CPAN
- Comprehensive Perl Archive Network
FSF
- Free Software Foundation
GED
- Gerenciamento Eletrônico de Documentos
GPL
- General Public License
HTML
- Hiper Text Mark up Language
MB
- Mega Bytes
PDF
- Portable Document Format
SGDB
- Sistema Gerenciador de Banco de Dados
SGBDOO - Sistema Gerenciador de Banco de Dados Orientado a Objetos
SGBDOR - Sistema Gerenciador de Banco de Dados Objeto/Relacional
SGBDR
- Sistema Gerenciador de Banco de Dados Relacional
RESUMO
Este trabalho tem como objetivo apresentar uma proposta de solução para
um dos principais problemas encontrados na definição do Projeto OpenGED: a
indexação de documentos. Para alcançar este objetivo, inicialmente foi realizada uma
pesquisa sobre sistemas de Gerenciamento Eletrônico de Documentos, o que
possibilitou conhecer melhor as tecnologias envolvidas. Em seguida, foi pesquisado
sobre a indexação de documentos, os problemas associados com a implementação
deste tipo de recurso e as facilidades que ele traz para um sistema de GED, tais como,
recuperação de informação e agilização dos processos que envolvem documentação
eletrônica. No estudo, foram identificadas várias estruturas e algoritmos utilizados para
implementar a indexação de documentos e, por sua vez, organizar as informações de
um sistema de GED. Assim, são apresentadas neste trabalho, as estruturas de arquivos
invertidos, árvores Trie, PAT e RD-Tree. Pela complexidade do tema, optou-se por
pesquisar ferramentas de indexação e busca de documentos já disponíveis. O OpenFTS
foi a ferramenta escolhida, por preencher os critérios de seleção definidos para o
projeto, principalmente por possuir livre distribuição, garantida pela General Public
Licence – GPL, como o OpenFTS implementa seu mecanismo de indexação baseado
em uma RD-Tree, foi necessário um estudo mais detalhado deste tipo de estrutura. Na
seqüência, foram feitos inúmeros testes, com a finalidade de entender como o
OpenFTS trabalha. A partir destes testes, da leitura da documentação e do estudo do
próprio código fonte, pôde-se descrever passo-a-passo como é feita a indexação e
busca de um documento. Outro importante resultado do trabalho foi a descrição
detalhada das tabelas criadas no banco de dados PostgreSQL, que são usadas para
implementar a RD-Tree. Um ponto negativo encontrado no OpenFTS é o fato dele
reconhecer somente arquivos com texto puro. Como o Projeto OpenGED prevê o uso
de arquivos PDF, foi necessário descobrir uma solução para esta limitação, que foi
resolvida pela conversão dos arquivos PDF originais em arquivos texto, com o uso do
utilitário pdftotext. Para finalizar, foram feitos novos testes para analisar a performance
do OpenFTS, sendo que o mesmo demonstrou ter um bom desempenho e que poderá
ser utilizado no Projeto OpenGED.
Palavras Chaves: OpenFTS; indexação; recuperação de informações; Software livre.
ABSTRACT
This paper aims to present a solution proposal for one of the main problems
found during OpenGED Project definition: the document indexation. To reach this
objective, initially a research on Electronic Document Management systems was
carried through, what made possible a better knowledge of involved technologies.
After that, a research was made about document indexing, the problems related to the
implementation of this feature and the easiness that it provides for a EDM system,
namely, recovery of information and acceleration of the processes involving electronic
documentation. During this study, some structures and algorithms used for document
indexation and to organize the information of an EDM system had been identified.
They are presented in this paper: the structures of inverted archives, Trie trees, PAT
and RD-Tree. Due to the subject complexity, already existing searching and indexing
tools were preferred. OpenFTS was the chosen tool; because it fills he defined criteria
for the project, mainly for possessing free distribution, guaranteed by General Public
License - GPL. As OpenFTS implements its indexation mechanism based on a RDTree, a detailed study of this type of structure was necessary. In the sequence, many
tests had been performed, with the purpose of understanding how OpenFTS works.
Due to these tests, the documentation reading and the study of the source code, it was
possible to make a detailed description of how indexation and documentation search
works. An important result of this paper was the detailed description of the tables
created in the PostgreSQL database used to implement the RD-Tree. A negative
feature found in OpenFTS is that it only recognizes pure text files. As OpenGED
Project foresees the use of PDF files, it was necessary to discover a solution for this
limitation, achieved by the conversion of original PDF files to text files, using the
pdftotext tool. Finally, tests to analyze the performance of OpenFTS had been
performed, and it demonstrated having a good performance and proving that it could
be used in the OpenGED Project.
Key Words: OpenFTS; indexation; information retrieve; free software.
2
1. INTRODUÇÃO
1.1. Apresentação
Atualmente, na sociedade em que vivemos, cresce cada vez mais o
volume de informações geradas pelas organizações, bem como, a necessidade de se
ter acesso a estas informações no menor tempo possível. No entanto, boa parte
destas informações ainda é armazenada em papel. Segundo a Avant Imaging &
Information Management Inc. - AIIM, em 1990 nos Estados Unidos, 95% dos
documentos das organizações ainda eram impressos e armazenados em papel
(CENADEM, 2002; AIIM, 2002).
Com a evolução da informática, passou-se a buscar novas formas de
armazenar e gerenciar documentos impressos. Uma das soluções criadas foi o
Gerenciamento Eletrônico de Documentos - GED. De acordo com o Centro
Nacional de Desenvolvimento do Gerenciamento da Informação – CENADEM
(2002), o GED consiste em converter informações de diferentes mídias para forma
digital, tornando a sua recuperação rápida e segura.
Nos últimos anos, a humanidade vem gerando informações de forma
exponencial. Essa avalanche de informações fez com que o mercado de GED
permanecesse em constante crescimento. Um exemplo de seu potencial é obtido
quando se compara um arquivo de quatro gavetas, que comporta em média 10 mil
imagens de documentos, e um CD-R, que pode armazenar 650 MB de informações,
o que corresponde a 13 mil páginas.
Conhecendo este potencial, formou-se um grupo de trabalho para
3
desenvolver o protótipo de uma solução para GED, com base no uso de ferramentas
de livre distribuição disponíveis no mercado, o qual esta sendo chamado de Projeto
OpenGED.
Devido à quantidade de tecnologias envolvidas e à complexidade inerente
a este tipo de sistema, optou-se por dividir o projeto inicial em três trabalhos
distintos:
a) Conceituação, análise de ferramentas disponíveis no mercado, descrição de
um projeto para desenvolvimento de aplicações em GED e elaboração de
estudos de casos sobre a utilização do mesmo;
b) Estudo sobre indexação de documentos e proposta de uma solução para
indexação de arquivos textuais a ser usada no Projeto OpenGED;
c) Implementação de uma aplicação utilizando os conceitos abordados no
Projeto.
O presente trabalho irá tratar sobre a questão da indexação de
documentos, que consiste basicamente na formulação de um dicionário de palavras
contidas nos documentos, a partir do qual será feita a recuperação da informação. A
indexação deve ser projetada de maneira lógica, estudando-se métodos de pesquisa
e diferentes estruturas de dados, procurando oferecer o menor tempo de resposta ao
usuário e uma maior confiabilidade dos dados apresentados.
Como os estudos estão sendo desenvolvidos em equipe, CENCI (2002)
aborda os conceitos relacionados ao GED e a descrição do Projeto OpenGED.
OLIVEIRA FILHO (2002), por sua vez, aborda o projeto e a implementação de
uma aplicação de GED, construída com softwares de livre distribuição.
1.2. Definição do problema
Um dos pontos críticos em sistemas de Gerenciamento Eletrônico de
Documentos é o método de recuperação da informação em documentos textuais. A
eficiência da recuperação da informação está associada às técnicas de indexação e
pesquisa utilizadas.
4
No contexto do Projeto OpenGED, o problema deste trabalho consiste em
propor uma solução para indexação de documentos textuais, a qual permita a
extração das palavras e posterior armazenamento em um banco de dados.
1.3. Justificativa
A cada dia, é gerado nas organizações um volume muito grande de
informações. Segundo o Centro Nacional de Desenvolvimento do Gerenciamento
da Informação (CENADEM, 2002), “A humanidade gerou a mesma quantidade de
informação nos últimos 50 anos que nos 5 mil anteriores. Esse número duplicou em
agosto de 2001. Em 2010, a informação duplicará a cada 11 horas”.
Estas informações armazenadas apenas em papel trazem grandes
problemas, tanto em relação ao espaço necessário para armazenamento, quanto para
o meio ambiente de onde vem o papel. Por isso, o Gerenciamento Eletrônico de
Documentos - GED, como ferramenta para recuperação de informações de forma
rápida, consistente e precisa, a cada dia vem chamando mais a atenção das
empresas. Assim, o GED deixou de ser apenas uma ferramenta para redução de
espaço físico e acesso simultâneo às informações, uma vez que também tem por
objetivo agilizar a recuperação de informações e a tomada de decisão.
Uma empresa que opta por uma solução de GED busca, principalmente,
controle absoluto nos processos de negócios, alta velocidade e precisão na
localização de documentos. Isto é imprescindível nos dias de hoje, onde questões de
minutos podem definir um grande negócio ou um grande fracasso. Até mesmo em
empresas de menor porte não se pode deixar um cliente esperando até que se
encontre um determinado documento guardado em alguma gaveta.
Conforme colocado por CENCI (2002), soluções de GED ainda têm um
custo bastante elevado, tornando-se inviáveis para a maioria das médias e pequenas
empresas. Além de investimentos em hardware e software, existe o custo associado
à contratação de uma empresa que faça a implantação/personalização do sistema de
GED.
5
O Projeto OpenGED preocupa-se em oferecer uma solução para
Gerenciamento Eletrônico de Documentos mais acessível às médias e pequenas
empresas, através da redução do investimento em software. Para tal, serão
pesquisadas ferramentas distribuídas na forma de software livre.
Segundo a Free Software Foundation (FSF, 2002), "software livre" se
refere à liberdade dos usuários executarem, copiarem, distribuírem, estudarem,
modificarem e aperfeiçoarem o software. O Projeto OpenGED usará software com
licença pública não só pelo fator financeiro, pois o software livre pode até não ter
custo, mas também, pela facilidade na adaptação de um software a uma determina
tarefa, uma vez que, tendo acesso aos arquivos fontes, qualquer alteração ou nova
funcionalidade poderá ser adicionada.
A indexação é de fundamental importância dentro de um sistema GED,
pois é através da indexação que as informações vão ser recuperadas, oferecendo
uma das grandes facilidades que um sistema de GED traz para seus clientes, que é o
acesso às informações em um menor tempo. Portanto, o estudo e implementação de
uma forma de indexação têm um papel vital na construção de uma ferramenta de
gerenciamento de documentos eletrônicos.
1.4. Objetivo geral
Contribuir para o desenvolvimento do Projeto OpenGED, propondo uma
solução para o problema da indexação de documentos, que ofereça recuperação de
informação de forma rápida e confiável, utilizando ferramentas de livre distribuição.
1.5. Objetivos específicos
Os objetivos específicos do trabalho são:
a) Identificar os principais processos de indexação de documentos usados em
sistemas de Gerenciamento Eletrônico de Documentos;
b) Propor uma ferramenta para a indexação de documentos, no contexto do Projeto
6
OpenGED;
c) Descrever o funcionamento e interfaces da ferramenta proposta;
d) Avaliar a performance da solução proposta.
1.6. Metodologia
O embasamento teórico deste trabalho foi adquirido através da leitura de
artigos sobre: GED, estrutura de arquivos PDF, extração de palavras em arquivos
PDF, indexação, entre outros, disponíveis em livros técnicos, sites de fornecedores
de tecnologia, revistas e manuais.
Uma vez compreendido como funciona o processo de indexação e busca
em documentos textuais, procurou-se encontrar ferramentas já desenvolvidas e
distribuídas na forma de software livre, para que pudessem integrar o Projeto
OpenGED. Previu-se, também, a possibilidade de não ser encontrada uma solução
pronta, caso em que deveria ser avaliada a hipótese de se implementar uma
ferramenta de indexação.
Entre várias ferramentas pesquisadas, optou-se por utilizar o OpenFTS,
distribuído gratuitamente sob a General Public Licence – GPL (OPENFTS, 2002).
Com a decisão de adotar esta ferramenta, iniciou-se o estudo da mesma,
os requisitos do ambiente necessários para a instalação e configuração, a forma
como as informações são armazenadas e os algoritmos utilizados para a indexação e
recuperação de informações.
Em uma etapa seguinte, foi feita a instalação da ferramenta escolhida em
um servidor de testes para avaliar o desempenho da mesma. Os documentos que
formaram o banco de testes foram obtidos na Internet.
Com os testes, procurou-se verificar se o OpenFTS é uma ferramenta de
indexação de documentos funcional, com interfaces de gerenciamento e consulta
simples e, se pode ser distribuída sem custos, sob a General Public License - GPL,
da Free Software Fundation (FSF, 2002).
O Projeto OpenGED está sendo disponibilizado gratuitamente no site
7
http://codigolivre.org.br, que é um repositório de projetos de software livre,
podendo ser acessado pelo endereço http://openged.codigolivre.org.br.
2. INDEXAÇÃO DE DOCUMENTOS
Uma empresa que utiliza um sistema de GED, não procura apenas a
redução de papel ou o controle do fluxo de documentos. Um dos principais motivos
para adesão a um sistema de GED é ter informações, que antes demoravam um
grande período de tempo para serem encontradas, disponíveis em segundos.
A indexação é o mecanismo usado pelos sistemas de GED para oferecer
esta facilidade aos seus clientes, ou seja, um bom sistema de indexação é um
recurso imprescindível em um sistema de GED.
Este capítulo apresenta o conceito de indexação textual e os principais
problemas relacionados com o tema. Aborda, ainda, algumas estruturas de
armazenamento mais utilizadas por produtos de GED.
2.1. Problemas com a indexação
Quando documentos impressos são recebidos por uma empresa, eles
devem ser organizados para serem utilizados. Esta organização normalmente
consiste em etiquetar, grampear e arquivar documentos em pastas ou armários. Sem
este processo, seria bastante difícil encontrar um documento em especial dentre
tantos outros. Em um sistema eletrônico o princípio é o mesmo, ou seja, um sistema
de GED deve fornecer uma estrutura para armazenar e organizar documentos.
O objetivo da indexação é, de uma maneira funcional e com uma estrutura
de fácil entendimento, organizar os documentos que são inseridos no sistema, da
mesma forma que uma pessoa arquiva documentos, organizando-os de maneira que
possa encontrá-los em poucos instantes. Um sistema de GED também deve ter a
9
mesma facilidade de recuperar informações em segundos, independente do tamanho
ou da complexidade do documento a ser recuperado.
Denomina-se indexação ao processo de criação de uma representação de um documento
para tornar sua manipulação mais fácil e rápida. Um sistema de recuperação de
documentos automatizado retorna um conjunto de documentos como resposta a uma
eventual consulta. Este sistema, contudo, pode não processar cada documento na forma
de linguagem natural. Ao invés disso, ele utiliza estruturas representativas de cada
documento que podem ter sido produzidas manual ou automaticamente. Em virtude da
complexidade da operação de indexação, tal operação realizada automaticamente será
invariavelmente imperfeita em comparação com a indexação feita por agentes humanos.
(SILVA, 1996)
Para se criar uma estrutura de indexação é necessário tomar alguns
cuidados, principalmente com o espaço ocupado pelos arquivos de índice. Em
determinadas situações, dependendo do algoritmo a ser utilizado para indexar, os
arquivos de índices podem ocupar até 100% do tamanho dos arquivos originais, o
que torna uma estrutura de indexação inviável quando se tem um grande número de
documentos. Outro problema é a complexidade que estes arquivos de índices vão
adquirindo com o aumento significativo do volume de documentos armazenados,
prejudicando a performance do sistema para indexar e recuperar documentos.
2.2. Estruturas de armazenamento
Cada vez mais, estão sendo pesquisadas novas formas de armazenamento
para índices de arquivos textuais. Entre as diversas técnicas existentes, as mais
utilizadas são os Arquivos Invertidos (WIVES, 2002), as árvores Trie e PAT
(NEUBERT, 1999) e árvores RD-Tree (HELLERSTEIN e PFEFFER, 2000).
Esta seção faz uma rápida apresentação destas estruturas para criação de
índices, dando especial atenção à RD-Tree.
2.2.1. Arquivos Invertidos
Os arquivos invertidos são as estruturas mais utilizadas para indexação de
arquivos textuais, devido a sua simplicidade e eficiência na busca, bem como, pela
possibilidade de compressão, o que pode oferecer uma considerável redução nos
10
custos adicionais com espaço para armazenamento.
A estrutura de um arquivo invertido, conforme mostrado na Figura 1,
geralmente é composta por três entidades relacionadas:
• Dicionário: é uma lista de todas as palavras indexadas;
• Lista de inversão: contém a identificação das palavras com ponteiros para os
documentos; e,
• Documentos indexados.
FIGURA 1 – Estrutura de arquivos invertidos.
Fonte: (WIVES, 2002).
Para cada palavra do dicionário, existirá uma lista invertida contendo
ponteiros para todas as ocorrências da palavra nos documentos indexados.
Existe, também, a necessidade da criação de uma lista de stop words, que
contém a relação de palavras que não precisam ser indexadas, pelo fato de sua
ocorrência ser bastante comum ou irrelevante, como é o caso das preposições, ou
mesmo, palavras que aparecem praticamente em todos os documentos. Se estas
palavras fossem indexadas, não estariam auxiliando a filtragem dos documentos,
além de deixar o processo de recuperação de informações mais lento.
Apesar de possuir uma estrutura simples, os arquivos invertidos, segundo
WIVES (2002), podem ocupar de 50% a 100% do tamanho do documento original.
No entanto, se forem utilizados algoritmos de compressão, pode-se reduzir este
gasto com espaço para valores menores do que 10%.
11
2.2.2. Árvores Trie
Árvores Trie são estruturas de árvores criadas especialmente para indexar
palavras. Sua principal utilização se dá em arquivos cujo objetivo é armazenar
palavras. Nessa estrutura, cada nodo é um vetor contento 27 componentes que
correspondem às letras do alfabeto (NEUBERT, 1999).
As árvores Trie geralmente são usadas quando se tem grande quantidade
de textos estáticos, ou seja, textos que não mudam ou quando não são inseridos
novos documentos. Por exemplo, a indexação de dicionário ou livros.
FIGURA 2 – Estrutura de uma árvore Trie.
Fonte: (NEUBERT, 1999).
2.2.3. Árvores PAT
Segundo NEUBERT (1999), As árvores PAT são bastante semelhantes às
árvores Trie, porém, são árvores binárias e trabalham com um esquema de
codificação binária das palavras. Figura 3.
Nesse tipo de estrutura o documento é visto como uma cadeia de
caracteres (uma grande string) onde cada uma de suas posições pode ser um ponto
de entrada (um ponto de busca). Cada posição da string define uma substring que
começa nesse ponto e vai até o final do documento, incluindo todo o texto
intermediário.
12
FIGURA 3 – Estrutura de uma árvore PAT.
Fonte: (NEUBERT, 1999).
Na árvore PAT, os índices referenciam seqüências de caracteres no texto.
Deve haver um apontador para cada caractere do texto, o qual começa uma nova
palavra ou sub-palavra.
Para que se possa fazer uma consulta nesse tipo de árvore, a expressão
desejada também deve ser codificada para uma sentença binária, utilizando-se o
mesmo padrão empregado no momento da indexação. Os bits individuais do código
são utilizados para definir o caminho a ser percorrido, onde zero indica os ramos à
esquerda e um indica os ramos à direita.
2.2.4. Árvores RD-Tree
Uma árvore RD-Tree trabalha com um sistema de indexação por
conjuntos ou blocos. Através deste mecanismo de indexação por blocos, reduz-se o
tamanho dos arquivos de índice, o que pode ser considerado uma vantagem sobre os
demais métodos. O uso da RD-Tree possibilita que a indexação de texto tenha uma
boa performance. Na recuperação de documentos indexados também se pode ter
ganhos em tempo de resposta ao usuário.
A Figura 4 mostra a estrutura de uma árvore RD-Tree. A estrutura deste
tipo de árvore é similar à árvore R-Tree, que é uma estrutura popular para
13
armazenamento de dados espaciais, como retângulos e polígonos.
FIGURA 4 – Estrutura de uma árvore RD-Tree.
Fonte: (HELLERSTEIN e PFEFFER, 2000).
Na RD-Tree, o conjunto de dados que está sendo indexado é chamado de
conjunto base1, enquanto que os elementos pertencentes a este conjunto base são
chamados de elementos base2. O conjunto formado por todos os conjuntos base é
chamado de universo. Cada conjunto base está dentro de um conjunto limitador3
que, no contexto de árvores, é o nó “pai” (Figura 4). Um nó “pai” pode ter vários
filhos. A escolha do nó que vai receber um novo conjunto base ou a decisão de criar
um novo nó “pai” é feita por heurísticas (HELLERSTEIN e PFEFFER, 2000).
Um nó folha de uma RD-Tree contém as entradas de um conjunto base.
Um nó não folha contém as entradas de um conjunto limitador. Assim, o nó não
folha, que é um conjunto limitador, contém obrigatoriamente todas as entradas dos
nós filhos, representando a união de todos os seus nós filhos.
Para encontrar um determinado conjunto base, inicialmente é feita uma
consulta no nó raiz. Se o conjunto que está sendo procurado for um subconjunto do
1
Conjunto base – tradução do termo inglês base sets.
Elementos base – tradução do termo inglês base elements.
3
Conjunto limitador – tradução do termo inglês bounding set.
2
14
nó raiz, a busca deve continuar nos nós filhos do nó raiz. Esta operação deve ser
repetida até que se encontre um nó folha. Caso o conjunto procurado não seja
encontrado no nó raiz, ou em um nó não folha, ele não pertence à árvore formada
por todas as entradas descendentes deste nó, que podem ser descartadas.
Na inserção de um novo conjunto base, o nó escolhido para ser o “pai” do
novo nó é aquele cujo conjunto de entradas formam mais intersecções, ou seja,
procura-se o conjunto limitador mais parecido com o novo conjunto base, pois
posteriormente, os elementos base deste novo conjunto serão acrescentados ao
conjunto limitador.
2.2.4.1. Por que usar RD-Tree?
Gerenciadores de Bancos de Dados Relacionais (SGBDR) tradicionais
possuem excelente capacidade de processamento de consultas, mas sofrem com um
rígido e semanticamente empobrecido modelo de dados (HELLERSTEIN e
PFEFFER, 2000).
Gerenciadores de Bancos de Dados Orientados a Objetos (SGBDOO)
possuem um modelo de dados mais flexível, que permite a criação de tipos
complexos. Entre as facilidades deste modelo, está o suporte a atributos de
“conjunto valorados”4, os quais são elementos de registro do tipo conjunto-dex, onde x é algum tipo de dado conhecido do sistema. Estes conjuntos ocorrem
naturalmente na associação com objetos simples, como por exemplo, o conjunto das
disciplinas feitas por um acadêmico ou o conjunto de palavras-chave de um
documento (HELLERSTEIN e PFEFFER, 2000).
Gerenciadores de Bancos de Dados Objeto-Relacional (SGBDOR), tais
como o PostgreSQL, combinam a riqueza do modelo de dados dos SGBDOO com a
performance de processamento de consulta dos SGBDR. Essa flexibilidade em criar
novos e complexos tipos de dados permite, por exemplo, que um sistema de
Gerenciamento Eletrônico de Documentos, tenha uma classe definida como:
DOCUMENTO =[nome: texto; id: inteiro; palavras:conjunto-de4
Atributos de conjunto-valorados – tradução do termo inglês: set-valued attributes.
15
plavras-chaves],
onde, conjunto-de-plavras-chaves é tratado como um campo único da
tabela DOCUMENTO e cada palavra indexada representa um elemento deste
conjunto.
2.2.4.2. Um exemplo de indexação com RD-Tree
Neste item, será apresentado um exemplo bastante simples de indexação
usando uma árvore RD-Tree. Para um melhor entendimento, restringiu-se em dois o
número de entradas em cada nó. Na prática este número pode ser bem maior
(HELLERSTEIN e PFEFFER, 2000).
Neste exemplo, são utilizados sete conjuntos compostos por números
inteiros de 0 a 9, os quais são:
− S1 = {1,2,3,5,6,9};
− S2 = {1,2,5};
− S3 = {0,5,6,9};
− S4 = {1,4,5,8};
− S5 = {0,9};
− S6 = {3,5,6,7,8};
− S7 = {4,7,9};
A Figura 4 mostra como os conjuntos ficaram dispostos na árvore. Os
conjuntos S3, S2, S1e S5 são subconjuntos da entrada esquerda do nó raiz, portanto,
são inseridos à esquerda do nó raiz. Os conjuntos S4, S6 e S7 são subconjuntos da
entrada direita da raiz.
Para encontrar o conjunto S2, por exemplo, os conjuntos descendentes da
entrada direita seriam descartados no momento da busca.
Uma busca por todos os conjuntos que contenham os sub-conjunto {2, 9}
irá iniciar pelo nó raiz da árvore. Uma vez que o conjunto {1, 3, 4, 5, 6, 7, 8, 9}
(entrada direita do nó raiz) não é um super-conjunto5 de {2,9}, a sub-árvore da
direita é descartada. {0, 1, 2, 3, 5, 6, 9} é um super-conjunto de {2, 9}, portanto, o
16
lado esquerdo da raiz é examinada. {0, 5, 6, 9} é rejeitado, por não ser um
superconjunto de {2, 9}, mas {1, 2, 3, 5, 6, 9} é um superconjunto e seus nós filhos
são examinados, e assim por diante.
2.3. Conclusão
A indexação é uma técnica utilizada para que informações sejam
recuperadas rapidamente. Aplicada aos sistemas de GED, a indexação foi um dos
fatores que impulsionaram estes sistemas no mercado.
Através da indexação de textos, um sistema de GED pode fazer com que
uma empresa agilize todos os processos que envolvam documentação eletrônica.
As estruturas de armazenamento indicam como as informações são
organizadas em mídia eletrônica. A escolha por uma ferramenta de indexação que
possua uma boa estrutura de armazenamento é de vital importância para um sistema
de GED, pois, pode determinar até mesmo se vai ser necessário utilizar um
computador mais potente, refletindo assim em gastos extras para a empresa que está
implantando o sistema de GED.
Neste
capítulo,
procurou-se
dar
uma
idéia
das
estruturas
de
armazenamento usadas pelas ferramentas de indexação pesquisadas. Na literatura,
nota-se a preferência pelo uso de arquivos invertidos em função de sua
simplicidade. Diversos estudos apresentam soluções alternativas, algumas vezes
preocupadas em otimizar o tamanho dos índices, outras vezes otimizando o
desempenho dos algoritmos de indexação e busca.
O detalhamento da árvore RD-Tree justificou-se, uma vez que é a
estrutura utilizada pelo mecanismo de indexação OpenFTS, utilizado no Projeto
OpenGED.
Nesta etapa do trabalho, a equipe do Projeto fez uma extensa pesquisa por
mecanismos de indexação que pudessem ser utilizados em ambiente GNU/Linux.
Diversas ferramentas foram encontradas, porém, com restrições de uso,
5
Isto é, o conjunto {2, 9} não está contido no conjunto {0,1,3,4,5,6,7,8,9}.
17
principalmente em aplicações comerciais.
Antes de encontrar o OpenFTS, a equipe cogitou, inclusive, implementar
um mecanismo de indexação baseados em arquivos invertidos. Optou-se pelo
OpenFTS por este ser de livre distribuição e porque, tendo uma ferramenta de
indexação pronta, a equipe poderia avançar nos objetivos do Projeto OpenGED,
descritos em CENCI (2002).
3. O PROJETO OPENFTS
Neste capítulo é apresentado o OpenFTS, que é a ferramenta de indexação
e busca textual adotada para o Projeto OpenGED. Inicialmente são feitos
comentários sobre a motivação que levou à escolha do OpenFTS para,
posteriormente, descrever em detalhes como esta ferramenta está estruturada.
3.1. Motivação
Sendo o problema da indexação de documentos um ponto crítico para o
Projeto OpenGED, a princípio levantou-se duas possíveis soluções:
a) Encontrar uma ferramenta de indexação distribuída sob a licença GPL;
b) Desenvolver uma ferramenta para indexação e pesquisa de arquivos
textos.
Em função da complexidade inerente a um sistema de indexação e ao
tempo disponível para desenvolver o trabalho, a primeira solução mostrou-se como
a mais adequada.
Em CENCI (2002), definiu-se que o Projeto OpenGED seria construído a
partir de softwares distribuídos sob a General Public License - GPL (FSF, 2002).
Assim, optou-se pela procura de softwares de indexação já existentes, sendo
analisados entre outros, os seguintes produtos:
• Glimpse: é uma ferramenta para uso em ambiente GNU/Linux, de livre
distribuição para fins educacionais e em organizações não governamentais,
porém, exige aquisição de licença para uso comercial (GLIMPSE, 2002). O
Glimpse trabalha de forma semelhante ao comando grep existente no Unix,
19
ou seja, procura uma determina palavra ou um conjunto de palavras dentro
de arquivos texto previamente indexados. A velocidade de indexação e
procura no texto depende do tamanho dos arquivos. Segundo MAMBER
(1993), uma das grandes vantagens do Glimpse é o fato que seus arquivos de
índices serem relativamente pequenos cerca de 2% a 4% dos arquivos
originais. O Glimpse utiliza arquivos invertidos como estrutura de
armazenamento6.
• OpenFTS: construído para trabalhar com o banco de dados PostgreSQL,
permite a indexação e recuperação de informação em documentos textuais.
Possibilita a indexação on-line, ou seja, à medida que os documentos são
inseridos no sistema, também podem passar pelo processo de indexação. O
OpenFTS oferece, ainda, funções de ranqueamento7, que possibilitam uma
probabilidade de acerto na pesquisa bem maior (OPENFTS, 2002).
3.2. Descrição do componente OpenFTS
O OpenFTS é uma aplicação que trabalha sobre o banco de dados
PostgreSQL, oferecendo um mecanismo de indexação e busca em documentos
textuais. Possui recursos avançados, tais como: indexação on-line, estatísticas sobre os
dados e suporte para múltiplas línguas. Além disso, o OpenFTS é distribuído sob a
General Public License - GPL, o que, entre outras vantagens, permite a redução dos
custos de aquisição de software e a possibilidade de modificação do código pelo
próprio usuário (OPENFTS, 2002; FSF, 2002).
O OpenFTS, para atingir uma melhor performance, faz a implementação de
uma árvore RD-Tree em um banco de dados relacional-objeto. As árvores RD-Tree,
descritas na seção 2.2.4, são estruturas de dados que se mostraram bastante eficientes
tanto no armazenamento, como no processo de recuperação de informação
(OPENFTS, 2002).
6
7
Maiores informações sobre o produto podem ser encontradas em http://webglimpse.net.
Ranqueamento: forma de classificação obedecendo algum critério pré-definido.
20
3.2.1. Requisitos de software
O OpenFTS foi desenvolvido para ser executado sobre o Sistema Operacional
GNU/Linux. Nas seções seguintes, são relacionados os demais softwares e recursos
necessários para a instalação e utilização do OpenFTS, os quais também são
distribuídos sob a GPL.
3.2.1.1. Perl
Perl é a linguagem de programação usada na implementação do OpenFTS.
Sua sigla significa "Practical Extraction and Report Language", originalmente
desenvolvida
para
realizar
tarefas
de
administração
de
sistema
(WALL,
CHRISTIANSEN e ORWANT, 2001).
Pode ser utilizado em ambiente GNU/Linux e demais sistemas operacionais
compatíveis com Unix, bem como, no Windows8.
3.2.1.2. PostgreSQL
Sistema de Gerenciamento de Banco de Dados Relacional-Objeto, de livre
distribuição para o ambiente GNU/Linux (POSTGRESQL, 2002). Segundo
GREENSPUN (2002), a escolha do PostgreSQL para construção do OpenFTS se deve
por ser um SGDB completo, com índices, triggers, store procedures e se apresentar
como um banco de dados bastante seguro. Complementando, ainda, o PostgreSQL
possui flexibilidade no armazenamento de informações, possibilitando a criação de
campos com tamanhos dinâmicos9.
3.2.1.3. Tsearch
O Tsearch é um componente distribuído como uma extensão do PostgreSQL,
desenvolvido por Teodor Sigaev e Oleg Bartunov, que permite uma melhor integração
entre o banco de dados PostgreSQL e o OpenFTS. O Tsearch acrescenta um novo tipo
de dado ao PostgresSQL, denominado txtidx, que permite acesso ao conteúdo de
8
Maiores informações, código fonte e binários para instalação, podem ser encontrados no site oficial do produto:
http://www.perl.org.
21
forma indexada. Com ele, a busca de uma determinada palavra, mesmo em um grande
universo de palavras, é realizada em um intervalo de tempo pequeno.
Foi inserido na versão 0.33 do OpenFTS, substituindo o pacote GIST10
anteriormente utilizado para implementar as estruturas dos índices de indexação e
busca, tipos de dado e interface dos dicionários (OPENFTS, 2002; GIST, 2002).
Os fontes do Tsearch são distribuídos juntamente com os fontes do
PostgreSQL, sendo encontrados no sub-diretório contrib11.
3.2.1.4. DBI
O DBI é a camada de acesso à base de dados para a linguagem de
programação Perl. Nele, está definido um conjunto de métodos, variáveis e
convenções, que fornecem uma relação com a base de dados de forma consistente,
independente da base de dados real que está sendo usada (CPAN, 2002).
No entanto, o DBI12 é apenas uma camada que faz a interface entre a
aplicação Perl e o driver da base de dados (Figura 5). No caso do OpenFTS, que
utiliza o banco de dados PostgreSQL, o driver utilizado é o DBD::Pg.
FIGURA 5 – Arquitetura de acesso ao banco de dados PostgreSQL de uma aplicação Perl.
3.2.1.5. DBD::Pg
Conforme mencionado na seção anterior, o DBD::Pg é o driver que
9
Maiores informações podem ser obtidas no site do produto em: http://www.postgres.org.
Generalized Search Tree – Permite a criação estruturas de dados para acessar uma base de dados
11
A localização do diretório depende de como foram instaladas os fontes no computador do usuário, por
exemplo, /usr/local/postgresql-7.2.2/contrib.
12
O DBI pode ser encontrado no site http://search.cpan.org/author/TIMB/DBI-1.30/DBI.pm.
10
22
permite a uma aplicação Perl, através da interface DBI, trabalhar com os dados
contidos em uma base de dados PostgreSQL13.
3.2.2. Preparando o OpenFTS para o uso
Durante a realização do trabalho, as maiores dificuldades foram encontradas
no processo de instalação e configuração do OpenFTS. Diversas tentativas, sem êxito,
foram realizadas usando-se a versão 0.32 do produto. Com o lançamento da versão
0.33, que trouxe alterações nos tipos de dados, nas estruturas das tabelas de índices e
nas interfaces com os dicionários, obteve-se sucesso, uma vez que houve substituições
de componentes e o sistema se tornou mais estável. Atualmente está sendo utilizada a
versão 0.34.
Nesta seção serão descritos, de forma detalhada, os passos necessários para a
instalação e configuração do OpenFTS, versão 0.34. Esta seqüência pode ser utilizada
como guia de instalação para outras versões, mas, há necessidade de se consultar a
documentação de cada versão.
3.2.2.1. Instalação e configuração
Para instalar o OpenFTS, deve-se observar a existência de uma dependência
entre aplicativos, ou seja, um aplicativo depende que um outro já esteja instalado. Na
ordem, deve-se fazer a instalação dos seguintes aplicativos:
• Perl;
• PostgreSQL;
• Tsearch;
• DBI;
• DBD::Pg;
• OpenFTS.
Como diversos desses componentes possuem atualização regular e novas
versões são distribuídas com freqüência, recomenda-se que sejam seguidos os
13
O DBD::Pg pode ser obtido no site http://search.cpan.org/author/JBAKER/DBD-Pg-1.13/Pg.pm.
23
procedimentos de instalação contidos na documentação que acompanha os códigos
fonte dos programas, uma vez que as instruções contidas nos sites e/ou livros podem
pertencer a versões diferentes. Geralmente, essa documentação encontra-se nos
arquivos INSTALL e README.
Todo o processo de instalação do OpenFTS é descrito na documentação que
acompanha
o
software,
mais
especificamente
nos
arquivos
INSTALL
e
primer.html, consistindo basicamente nos seguintes passos:
• Descompactar os arquivos do OpenFTS com o comando tar –xzvf Search0.33.tar.gz;
• Mudar para o diretório criado, com o comando cd Search-OpenFTS-034;
• Executar o script Perl, que prepara o ambiente para instalação, com o comando
perl Makefile.PL;
• Recompilar os fontes com o comando make;
•
Fazer a instalação com o comando make install;
• Copiar o diretório pgsql_contrib_openfts para o diretório contrib que
se encontra dentro do diretório de instalação do PostgreSQL, por exemplo:
cp –r pgsql_contrib_openfts
/usr/local/pgsql/PostgreSQL7.2.2/contrib
• Mudar para o diretório pgsql_contrib_openfts anteriormente copiado:
cd
/usr/local/pgsql/PostgreSQL7.2.2/contrib/pgsql_contri
b_openfts
• Executar os comandos: make e, em seguida: make install.
Com o OpenFTS já instalado é necessário criar um banco de dados onde vão
ser armazenadas todas as informações e índices utilizados pelo mecanismo de
indexação. No PostgreSQL, este comando é createdb [nome do banco], onde
[nome do banco] corresponde ao nome dado à base de dados, por exemplo:
createdb teste_fts.
Na seqüência, é necessário executar o arquivo de script tsearch.sql
24
que se encontra juntamente com os códigos fonte do PostgreSQL, no subdiretório
tsearch. Este script irá incluir as configurações do Tsearch no banco de dados. O
comando para executar este script é psql
[nome
do
banco]
<
tsearch.sql.
Também é necessário executar o arquivo de script openfts.sql para
incluir as funções de ranqueamento e busca por aproximação. Este arquivo encontra-se
com os fontes do PostgreSQL, no subdiretório pgsql_contrib_openfts. O
comando para executar este script é psql
[nome
do
banco]
<
openfts.sql.
3.2.3. Estrutura de uma base de dados do OpenFTS
No processo de instalação e configuração do OpenFTS são criadas diversas
tabelas para armazenar as informações dos documentos indexados, as quais são
descritas nas seções seguintes.
3.2.3.1. Tabela txt
É a tabela onde são armazenadas as informações de cadastro dos documentos
já indexados. Compõe-se de três campos, conforme mostrado no Quadro 1:
QUADRO 1 – Estrutura da tabela txt
Nome
Tipo de dado
Descrição
tid
Inteiro não nulo
Identificador único para cada documento
indexado. É a chave primária.
path
fts_index
Caractere, de tamanho
Identifica o caminho físico do documento.
variável
txtidx
14
Contém, em ordem alfabética, todos
lexemas extraídos do texto pelo parser15
O Campo mais importante desta tabela é o fts_index, que representa o
conjunto de todos os lexemas extraídos de um documento. Lexema é o termo utilizado
para definir um elemento do texto que pode ser indexado. Indica uma palavra simples,
14
txtidx é um tipo especial, definido pelo componente Tsearch conforme descrito na seção 3.2.1.3, que
representa um conjunto de lexemas.
15
Parser é o “motor” do sistema OpenFTS, responsável pelo reconhecimento de lexemas de um documento.
Será melhor explicado na seção 3.2.4.
25
uma URL ou outra estrutura do texto. No Quadro 6 da seção 3.2.4, estão todos os tipos
de lexemas reconhecidos pelo parser do OpenFTS.
3.2.3.2. Tabela index
É a tabela que contém a posição de todas as ocorrências dos lexemas dentro
do documento.
Existem 10 tabelas de índices, iniciando na tabela index1 até a index10,
que são constituídas pelos campos mostrados no Quadro 2.
QUADRO 2 – Estrutura da tabela index
Nome
Tipo de dado
Descrição
lexem
Caractere, de tamanho
variável
Contém o lexema em si.
tid
Inteiro não nulo
Identifica o documento.
pos
Conjunto de inteiros
Identifica a posição de cada ocorrência do
lexema no documento.
Sua chave de acesso (chave primária) é composta pelos campos lexem e
tid.
3.2.3.3. Tabela fts_conf
Tabela que possui as configurações do OpenFTS, como dicionários usados e
stop words. Compõe-se dos campos mostrados no Quadro 3.
Nome
QUADRO 3 – Estrutura da tabela fts_conf
Tipo de dado
Descrição
name
Caractere, de tamanho
variável
Nome do item de configuração.
did
Inteiro não nulo
Identifica a seqüência do item de
configuração (padrão –1)
param
Caractere, de tamanho
variável
Parâmetros da configuração.
mod
Caractere variável
Identifica o módulo da configuração.
Por exemplo, na configuração básica do OpenFTS encontram-se os registros
mostrados no Quadro 4.
26
Name
QUADRO 4 – Conteúdo da tabela fts_conf.
Did
Mod
map
-1
parser
-1
Search::OpenFTS::Parser
ignore_id_index
-1
7 13 14 12 23
ignore_headline
-1
13 15 16 17 5
Txtidx_field
-1
fts_index
use_index_table
-1
1
numbergroup
-1
10
txttid
-1
txt.tid
dict
0
Search::OpenFTS::Dict::
param
{ '4'=>[1], 5=>[1],
6=>[1], 8=>[1], 18=>[1],
19=>[1],}
PorterEng
dict
1
Search::OpenFTS::Dict::
UnknownDict
{table =>
'fts_unknown_lexem'}
A tabela fts_conf contém os parâmetros passados para a função de
inicialização do OpenFTS, a qual será melhor explicada na seção 4.1.
3.2.3.4. Tabela fts_unknown_lexem
Tabela para armazenar os lexemas que o parser não reconheceu. Compõe-se
apenas de um campo, conforme mostrado no Quadro 5.
Nome
Lexem
QUADRO 5 – Estrutura da tabela fts_unknown_lexem
Tipo de dado
Descrição
Caractere, de tamanho
variável
Contém um lexema que o parser não
conseguiu reconhecer.
Os lexemas que poderão ser aceitos por esta tabela são definidos na
inicialização do banco de dados, conforme será descrito no próximo capítulo.
3.2.4. Parser
Parser é o “motor” de um mecanismo de indexação, ou seja, é a parte do
software que separa e identifica os lexemas de um documento.
O OpenFTS utiliza o parser para:
a) Extrair lexemas de um documento contendo texto;
27
b) Extrair lexemas de uma requisição de consulta.
Em ambos os casos, o parser cria uma seqüência de lexemas16 a serem
pesquisados. Pode-se utilizar diferentes parsers em diferentes tipos de projetos
(OPENFTS, 2002), por exemplo, pode-se construir um parser específico para
documentos do Word ou para arquivos de áudio.
O parser distribuído com o OpenFTS reconhece vinte e três tipos de lexemas
em arquivos de texto puro (sem formatação ou caracteres especiais), conforme mostra
o Quadro 6.
QUADRO 6 – Descrição dos tipos de lexemas reconhecidos pelo parser do OpenFTS
Tipo de Lexema
ID
Descrição de lexemas
Exemplo
LATWORD
1
latin Word
Alou
CYRWORD
2
cyrillic word
…
UWORD
3
mixed word
…
EMAIL
4
Email address
[email protected]
FURL
5
full URL
http://www.uniplac.net
HOST
6
host name
…
SCIENTIFIC
7
number in scientific notation
-0.12345e+15
VERSIONNUMBER
8
integer or version number
3
7.1.2
PARTHYPHENWORD
9
part of mixed hyphenated word
…
CYRPARTHYPHENWORD
10
cyrillic part of hyphenated word
…
LATPARTHYPHENWORD
11
latin part of hyphenated word
multi in word multi-key
SPACE
12
Symbols
$#%^
SYMTAG
13
HTML tag
<b>
<table>
HTTP
14
HTTP
http://
HYPHENWORD
15
mixed hyphenated word
…
LATHYPHENWORD
16
latin hyphenated word
multi-key
CYRHYPHENWORD
17
cyrillic hyphenated word
…
URI
18
Uniform Resource Identifier
/index.html
FILEPATH
19
filename or path
example.txt
DECIMAL
20
number in decimal notation
10.345
SIGNEDINT
21
Integer
-4
16
Seqüência de lexemas - tradução do termo inglês: “stream of lexems”.
28
UNSIGNEDINT
22
unsigned integer
4
HTMLENTITY
23
HTML entity
4
Fonte: (OPENFTS, 2002)
3.2.5. Dicionário
De forma geral, um dicionário é utilizado para o reconhecimento de palavras
em uma determinada língua. No OpenFTS, o conceito é o mesmo. É utilizado um
dicionário para reconhecer as palavras (lexemas) do texto e, a partir deste
reconhecimento, definir o local de armazenamento da palavra em questão.
Um
dicionário
deve
possuir
dois
métodos
chamados
lemms
e
is_stoplexem. O método lemms retorna um conjunto de lexemas. O método
is_istoplexem é uma função “booleana” que, caso a palavra tratada seja uma stop
word, retorna verdadeiro (1), caso a palavra não seja uma stop word, retorna falso (0).
O OpenFTS possui interface para trabalhar com dicionários do tipo ISpell17
ou com algoritmos de stemming criados sob o projeto Snowball18.
No processo de instalação do OpenFTS, por padrão, é configurado um
dicionário para a língua inglesa. Para o Projeto OpenGED é necessário alterar este
dicionário
dicionário
para um dicionário que reconheça
pode
ser
encontrado
no
a língua portuguesa. Este novo
site
http://snowball.tartarus.org/
portuguese/stemmer.html.
O OpenFTS pode trabalhar com mais de um dicionário ao mesmo tempo,
assim como, podem ser criados dicionários personalizados ou para uso específico, por
exemplo, nas áreas jurídicas e médicas. A definição de qual dicionário será utilizado é
feita no momento da configuração do OpenFTS (que será tratada na seção 4.1).
A construção de um novo dicionário deve levar em consideração vários
fatores relevantes à língua que se deseja construir o dicionário. Para construir um
dicionário de língua portuguesa, por exemplo, é preciso implementar um algoritmo
17
Dicionários ISpell são gratuitos e disponíveis para muitas linguagens. São usados para retornar a forma básica
de uma palavra (OPENFTS, 2002).
18
Algoritmos de stemming são usados para identificar a raiz lingüística (stemmer) de uma palavra, eliminando os
sufixos e reduzindo o número de palavras indexadas. Por exemplo, as palavras teste e testando, seriam indexadas
apenas uma vez como teste (OPENFTS, 2002; SNOWBALL, 2002).
29
que reconheça: letras, sufixos e prefixos de palavras, terminações verbais, palavras
primitivas e derivadas. Assim, para as palavras química, químicas e químico, o
dicionário vai relacionar com a palavra quimic.
Conforme apresentado em SNOWBALL (2002), o stemming é parte de um
processo composto pela extração de palavras de um texto, seguida da indexação dos
termos em um sistema de recuperação de informações. Pela complexidade e
especialização, este assunto deve ser estudado de forma separada dos sistemas de
recuperação de informação.
3.3. Conclusão
Uma ferramenta de indexação e busca textual é a parte principal de um
sistema GED, ou seja, ela é responsável pela principal vantagem que uma empresa
procura em um sistema GED, que é encontrar informações em um tempo bastante
reduzido, mesmo quando se tem em um grande volume de documentos.
No estudo feito sobre o Glimpse houve uma grande dificuldade para
encontrar documentação, apesar do número de usuários do sistema. Porém, o principal
fator para que ele não fosse escolhido como ferramenta de busca e indexação do
OpenGED foi o fato do Glimpse ser gratuito apenas para uso educacional e
governamental, o que representaria uma desvantagem para aplicações em outras áreas.
O OpenFTS foi, então, escolhido como ferramenta de indexação e busca
textual para o Projeto OpenGED após uma longa etapa de pesquisa. Ele oferece
vantagens que, posteriormente, serão bastante úteis em um sistema de GED, como
indexação on-line, ranqueamento no resultado de pesquisa e, principalmente,
velocidade na indexação e na busca de informações.
Porém, o seu uso também trouxe vários desafios para a equipe envolvida no
Projeto. Estes desafios começaram pelo uso do “quase desconhecido” sistema
operacional GNU/Linux, passando pela instalação dos pacotes de software necessários,
até atingir o ponto onde o OpenFTS funcionou efetivamente, após várias tentativas
frustradas. Os testes foram realizados com versão 0.32, 0.33 e 0.34 do OpenFTS,
30
sendo as duas últimas responsáveis pelo sucesso da equipe.
Com o software funcionando, partiu-se para a tarefa de entender sua
operacionalização. Primeiro foram identificados e descritos todos os outros softwares e
extensões necessárias para instalação do OpenFTS. Em seguida, procurou-se entender
sua estrutura de índices, ou seja, as árvores RD-Tree descritas no capítulo 2. O
próximo passo foi entender como esta estrutura foi implementada no PostgreSQL,
resultando na descrição das tabelas apresentadas neste capítulo. Por último, procurouse estudar as interfaces do OpenFTS, ou seja, a forma de uso das funções por ele
disponibilizadas, que é o assunto do próximo capítulo.
4. SINTAXE DE USO DO OPENFTS
Neste capítulo é apresentado um tutorial de uso do OpenFTS e sua sintaxe.
Procurou-se descrever detalhadamente cada função, bem como, o objetivo de cada
parâmetro passado às mesmas. É conveniente lembrar que esta descrição baseia-se nas
versões 0.33 e 0.34 do software, podendo ter algumas diferenças em relação a outras
versões anteriores.
4.1. Preparando o banco de dados
O OpenFTS oferece uma série de funções para indexação e pesquisa de
documentos textuais. Originalmente, o sistema traz vários scripts em linguagem Perl,
que são usados para demonstrar o uso de suas funções. Conforme a necessidade de
cada desenvolvedor, esses scripts podem ser remodelados em outras linguagens, como
o PHP.
Antes de iniciar o processo de indexação pela primeira vez, em um banco de
dados recém criado, é necessário executar a função
Search::OpenFTS::Index->init
para configurar o banco de dados, de acordo com as necessidades do sistema e do
usuário. No Quadro 7 é mostrado um fragmento do código de um script que usa esta
função.
32
QUADRO 7 – Fragmento do script initi.pl
my $idx=Search::OpenFTS::Index->init(
dbi=>$dbi,
txttid=>'txt.tid',
use_index_table=>1,
txtidx_field=>'fts_index',
numbergroup=>10,
ignore_id_index=>[ qw( 7 13 14 12 23 ) ],
ignore_headline=>[ qw(13 15 16 17 5) ],
map=>'{ \'19\'=>[1], 18=>[1], 8=>[1], 7=>[1], 6=>[1],
5=>[1], 4=>[1],}',
dict=>[
'Search::OpenFTS::Dict::PorterEng',
'Search::OpenFTS::Dict::UnknownDict',
]
);
Fonte: (OPENFTS, 2002).
Vários parâmetros são passados à função Search::OpenFTS::Index->init, os
quais são descritos abaixo:
• dbi=>$dbi - especifica o nome do banco de dados utilizado ($dbi);
• txttid=>'txt.tid' – identifica o nome da tabela de cadastro de documentos
e sua chave primária ('txt.tid');
• use_index_table=>1 - informa se vão ser usadas as tabelas de índice (1) ou
não (0);
• txtidx_field=>'fts_index'
–
indica
o
nome
do
campo
('fts_index'), do tipo txtidx, onde serão armazenados os lexemas extraídos
do documento pelo parser;
• numbergroup=>10 – indica o número de tabelas de índices a serem criadas;
• ignore_id_index=>[ qw( 7 13 14 12 23 ) ] - informa o tipo de
lexemas ignorados pelo algoritmo de indexação;
• ignore_headline=>[ qw(13 15 16 17 5) ] – informa os tipos de
lexemas que serão ignorados quando se processa uma requisição de consulta;
• map=>'{ \'19\'=>[1], 18=>[1], 8=>[1], 7=>[1], 6=>[1],
5=>[1], 4=>[1], }' - mapeia os lexemas que serão indexados por cada
dicionário, por exemplo, 6=>[1] indica que os lexemas do tipo 6 (FURL)serão
processados pelo dicionário 1, no caso UnknownDict. Este parâmetro serve para
33
otimizar a busca/indexação e suporte a multiplas línguas;
• dict=>[Search::OpenFTS::Dict::PorterEng',
'Search::OpenFTS::Dict::UnknownDict']) – Indica os dicionários a
serem usados (PorterEng e UnknowDict).
Todos os parâmetros da configuração são armazenados na tabela
fts_conf, descrita na seção 3.2.3.3.
Pode-se criar mais de uma instância19 do OpenFTS, passando um parâmetro
juntamente com a função de inicialização. Este parâmetro deve estar entre os
caracteres de “a” até “z”. Por exemplo, para criar a instância “a” seria utilizado o
seguinte comando: ./init.pl [nome do banco]:a. Com este comando as
tabelas criadas terão o prefixo “a_” no seu nome (a_txt,a_index1,
a_fts_conf, a_fts_unknown_lexem).
A divisão da base de dados em instâncias serve, principalmente, para
organizar e otimizar o processo de indexação e de busca, pois uma busca pode se
restringir apenas a uma instância desejada.
A função de inicialização cria, também, a tabela fts_unknown_lexem,
onde são armazenados os lexemas não reconhecidos pelo parser durante o processo de
indexação.
4.2. Indexando documentos
Após inicializar o banco de dados, os documentos já podem ser indexados. A
indexação é feita basicamente passando para função
Search::OpenFTS::Index->index
a seqüência de lexemas extraídos pelo parser.
Como exemplo, a documentação do OpenFTS apresenta o script
index.pl, que pode ser utilizado para fazer a indexação:
perl index.pl < [nome do(s) arquivo(s) a ser(em) indexados]
19
Instância significa ter várias cópias do mesmo banco de dados, usadas para fins diferentes (p. ex. jurídico e
médico).
34
4.3. Pesquisando documentos indexados
Quando uma requisição de consulta é recebida (função de busca), está é
convertida pelo parser em uma cadeia de lexemas e, então, é construída uma SQL de
consulta.
Por exemplo, para se pesquisar a palavra “uniplac” é gerado o script de
consulta mostrado no Quadro 8.
QUADRO 8 – Fragmento do script contendo a instrução SQL gerada para uma requisição de consulta.
SELECT
txt.tid,
relkov( 1.0, 0.01, 0, txt.tid, txt.tid % 10 + 1 ,
'{"uniplac"}' ) as pos
FROM
txt
WHERE
txt.fts_index @@ '\'uniplac\''
ORDER BY pos desc
Uma pequena explicação desta instrução é :
• SELECT
txt.tid,
relkov( 1.0, 0.01, 0, txt.tid, txt.tid % 10 + 1 ,
'{"uniplac"}' ) as pos
indica que serão selecionados o campo tid da tabela txt e o resultado da
função relor estará na variável pos;
• A função
relkov(1.0,
0.01,
0,
txt.tid,
txt.tid
%
10
+
1
,
'{"uniplac"}'), é usada para o ranqueamento dos resultados da busca:
− os primeiros dois argumentos denotam os pesos para palavras encontradas no
título20 e no corpo do documento, respectivamente (1.0, 0.01);
− o terceiro argumento é o prefixo que denota que instância do OpenFTS usar (0);
− o quarto argumento é o nome da tabela onde estão cadastrados os documentos e
20
Título – é definido como as primeiras linhas do documento.
35
sua chave primária (txt.tid);
− o quinto argumento é o número da tabela do índice (txt.tid % 10 + 1) a ser
usada, equivalente a expressão: tid mod21 10 + 1;
− por último, o sexto argumento corresponde à cadeia de lexemas a ser pesquisada,
no caso deste exemplo, apenas o lexema {"uniplac"} é solicitado.
• WHERE
txt.fts_index @@ '\'uniplac\'' – informa que a tabela será
filtrada, ou seja, somente serão apresentados os registros que contiverem no campo
fts_index o lexema desejado;
• ORDER BY pos desc – informa que os resultado serão apresentados em ordem
decrescente pelo valor do campo pos.
4.4. Estatística de proximidade
É a função relkov, que fornece estatísticas sobre o documento, de acordo
com as palavras pesquisadas. Esta função é implementada mantendo-se informações
sobre as coordenadas de cada ocorrência de um lexema em um documento indexado.
O valor de um documento é dinâmico, ou seja, a cada nova consulta
realizada, os documentos resultantes tem seu valor calculado em função dos lexemas
pesquisados. Este valor é calculado seguindo a fórmula:
• para cada palavra encontrada no documento é atribuído um valor;
• se a palavra for encontrada no título do documento este valor é 1; e,
• se encontrada no corpo do documento, o valor atribuído é 0,01.
O resultado do cálculo efetuado em cada documento é utilizado pelo
OpenFTS para fazer a classificação dos resultados, ou seja, o ranqueamento (ranking).
4.5. Atualizando documentos indexados
O OpenFTS não possui funções de atualização e exclusão de documentos
21
Mod - função que retorna o resto de uma divisão.
36
indexados, ou seja, se um documento original é alterado, não é possível apenas
atualizar no OpenFTS as mudanças deste documento.
A solução encontrada foi a exclusão do documento e suas respectivas entradas
de índices. Toda vez que o usuário deseja atualizar um documento que já tenha sido
indexado deve ser feita a exclusão do documento original da base de dados do
OpenFTS para, em seguida, indexar o documento atualizado, que receberá um novo
identificador.
Um fragmento do script construído para exclusão de documentos é mostrado no
Quadro 9.
QUADRO 9 – Fragmento do script delete.pl
my $ftsi=Search::OpenFTS::index->new(..);
$ftsi->delete( $iddoc_for_delete );
$dbh->do("delete from txt where txt.tid=$iddoc_for_delete;");
• my $ftsi=Search::OpenFTS::index->new(..); indica que a variável
$ftsi vai ser o ponto de acesso às funções do OpenFTS;
• $ftsi->delete( $iddoc_for_delete ); indica a exclusão dos índices
relacionados com o documento a ser excluído;
• $dbh->do("delete from txt where txt.tid=
$iddoc_for_delete;"); exclui o documento da tabela txt.
4.6. Conclusão
O conhecimento das funções apresentado neste capítulo é de fundamental
importância para o uso correto do OpenFTS.
Um dos fatores para escolha do OpenFTS como ferramenta de indexação
para o Projeto OpenGED foi por ele ser razoavelmente fácil de utilizar, possuir
mecanismo de otimização, como a possibilidade de dividir a base de dados em várias
instâncias, possibilitando assim indexação e pesquisa em menor tempo.
Porém, descrever o funcionamento de cada operação não foi uma tarefa fácil,
uma vez que estas informações não são detalhadas na documentação.
37
Para poder redigir este capítulo, a equipe precisou realizar vários testes,
procurando entender o que o OpenFTS fazia a cada comando executado. Novamente o
pouco conhecimento sobre o sistema operacional GNU/Linux, somado ao banco de
dados PostgreSQL e à linguagem Perl, foram os principais obstáculos encontrados.
Uma parte considerável das dúvidas e detalhes de funcionamento do programa foi
descoberta pela interação com os criadores do OpenFTS (Oleg Bartunov, Neophytos
Demetriou, Teodor Sigaev e Daniel Wickstram), através da lista de discussão
disponível no site do projeto, em http://openfts.sourceforge.net.
Com certeza, não foi possível estudar todo o potencial do OpenFTS, mas,
procurou-se esclarecer os pontos básicos relacionados a inicialização do banco de
dados e à indexação e pesquisa de documentos. A exclusão de documentos é um
exemplo de solução obtida através da lista de discussão do OpenFTS.
Ainda, a equipe acredita que a tradução dos capítulo 3 e 4 para a língua
inglesa representarão uma excelente contribuição para o site do OpenFTS, uma vez
que contém informações importantes para os usuários iniciantes.
5. ANÁLISE DO FUNCIONAMENTO DO OPENFTS
Neste capítulo serão mostrados os resultado dos testes feitos com o
OpenFTS, onde se procurou observar a velocidade de indexação e recuperação de
informações, o espaço utilizado tanto pelos arquivos originais em formato PDF, como
pelos arquivos texto gerados a partir dos originais.
5.1. Definição da base de dados
Para os testes foram utilizados arquivos no formato PDF. Em CENCI (2002),
são mostradas várias vantagens na utilização deste formato de arquivo, como
segurança, arquivos com tamanho reduzido, cópia fiel do documento original, entre
outras. Como o OpenFTS não trabalha diretamente com arquivos PDF, foi necessário
convertê-los para arquivos do tipo texto. Utilizou-se para fazer esta conversão o
programa pdftotext que é distribuído sob a licença GPL, juntamente com o pacote
XPDF22.
Os documentos utilizados foram os Trabalhos de Conclusão do Curso de
Informática. Ao todo, 37 trabalhos foram convertidos de sua forma original para
arquivos PDF, utilizando-se a ferramenta Acrobat Distiller disponibilizada pela
UNIPLAC.
O tamanho médio de cada arquivo no formato PDF ficou em 1 MB, sendo
que, no formato original (.DOC ou .SDW) o tamanho médio era de 3,27 MB. Ainda,
cada documento possuía aproximadamente 11 mil palavras. Os arquivos texto gerados
através do pdftotext, ocupam em média um espaço de 120 KB, esta redução se deve
22
Maiores informações sobre o XPDF podem ser encontradas em http://www.foolabs.com/xpdf/.
39
principalmente pelo foto que nos arquivos texto não são armazenadas as imagens e
configuração existentes no formato PDF.
5.2. Inicializando o banco de dados
Definiu-se o nome do banco de dados como Teste_OpenGED, então foi
executado o script init.pl para criação das tabelas, conforme mostrado na Figura 6.
Este processo não foi monitorado, pois, será executado apenas uma vez.
Foi utilizado o dicionário padrão instalado juntamente com o OpenFTS, o qual
é otimizado para a língua inglesa, mas consegue indexar satisfatoriamente documentos
em outras línguas.
A Figura 6 mostra a inicialização do banco de dados onde, na primeira linha,
mostra a chamado do script init.pl e, nas demais linhas, mostra mensagens de
sucesso na criação das tabelas, índices e chaves primárias.
FIGURA 6 – Exemplo da execução do script init.pl.
5.3. Indexando documentos
Após a inicialização da base de dados, passou-se para a etapa de indexação dos
documentos. Para analisar os dados armazenados nas tabelas, antes de indexar todos os
arquivos foi indexado apenas um documento.
Este documento, no formato original, continha 11.210 palavras. No processo de
indexação foram eliminadas as stop words e as palavras repetidas, restando apenas
40
2.184 lexemas para indexar. A Figura 7 mostra uma instrução SQL que apresenta o
número total de lexemas indexados na tabela index2 (que é a tabela onde foram
armazenados os lexemas indexados para este documento).
FIGURA 7: Número de lexemas indexados.
Na Figura 8 é mostrada a chamada ao script que dispara a indexação, bem
como, a confirmação da indexação de cada arquivo. Ao final, é apresentado o tempo
total de processamento para indexar os 37 arquivos, que foi de 66,59 segundos, ou
seja, um tempo bastante pequeno considerando a quantidade de informação. Em
média, o tempo de indexação de cada documento ficou em 1,8 segundos.
41
FIGURA 8: Exemplo da execução do script index.pl.
5.4. Analisando a pesquisa
Nesta seção será mostrado o resultado de uma pesquisa simples.
Na Figura 9 é mostrada a execução do script search.pl, onde foi passado
como lexema de pesquisa a palavra cluster. O tempo para o OpenFTS responder foi de
apenas seis centésimos de segundo, resultando em 8 documentos encontrados. Na
resposta são apresentados, ainda, os id dos documentos (código de identificação de
cada documento na tabela txt).
42
FIGURA 9: Exemplo da execução do script search.pl.
Em uma nova pesquisa, a palavra turismo foi pesquisada, conforme mostrado
na Figura 10. Nota-se que o tempo para a resposta foi o de cinco centésimos de
segundo, praticamente o mesmo da pesquisa anterior, retornando três documentos.
FIGURA 10: Exemplo da execução do script search.pl.
Executando uma pesquisa um pouco mais complexa, foram passados como
parâmetros de consulta as palavras UNIVERSIDADE e orientador. Também foi
solicitado que o OpenFTS apresentasse partes do texto encontrado, conforme é
apresentado na Figura 11. O tempo de resposta foi de quinze centésimos de segundo.
Neste teste, nota-se que a opção de mostrar partes do texto na tela faz com que o
sistema tenha um tempo de resposta um pouco maior. Isto se deve ao fato dele ter que
montar a parte do texto a ser mostrada, ou seja, é necessário encontrar algumas
palavras anteriores e posteriores àquelas pesquisadas. Este recurso, embora tenha um
tempo de resposta maior que as pesquisas anteriores, é bastante útil uma vez que
auxilia na filtragem dos documentos.
43
FIGURA 11: Exemplo da execução do script search.pl.
No Quadro 10 é mostrado alguns resultados do script de pesquisa do
OpenFTS, usando por base a chamada ./search.pl
–p
Teste_OpenGED
[palavra1,palavra2,...,palavraN]. Através deste quadro, pode-se observar
que o OpenFTS tem boa performance para consultas nos dados indexados e que pode
suprir todas as necessidades do OpenGED
44
QUADRO 10: Resultados obtidos pelo script de consulta do OpenFTS.
Palavras pesquisadas
Tempo de
Nº de documentos
Documentos encontrados
resposta
encontrados
(segundos)
Universidade, Lages,
orientador
0,08
37
1,2,3,4,5,6,7,8,9,10,11,
12,13,14,15,16,17,18,19,20,
21,22,23,24,25,26,27,28,29,
30,31,32,33,34,35,36,37
Processador, memória
0,10
1
12
Software, Hardware
0,08
23
19,26,30,6,15,35,
9,8,10,3,23,24,31,28,21,
11,19,2,27,5,16,14,32
Redes, cabeamento
0,05
1
28
Informática, educação
0,07
16
23,19,4,7,33,14,15,32,22,1,2,
29,6,25,31,20
Informática, agricultura
0,06
1
1
Java, delphi,
ferramentas
0,05
6
14,6,31,36,11,27
Software, legislação
0,06
5
26,19,16,35,15
Processamento,
paralelo
0,05
3
8,26,29
Processamento,
distribuído
0,05
1
6
ATM, Ethernet
0,05
4
18,35,32,28
Automóvel,
alimentação
0,04
0
--
5.5. Conclusão
Neste capítulo foram mostrados alguns testes feitos com o OpenFTS, o que
mostrou que a ferramenta tem uma boa performance, tanto na indexação como na
busca de informações.
A preocupação com o desempenho do OpenFTS é justificada, por ele ser a
ferramenta de busca e indexação que vai ser utilizada no Projeto OpenGED, ou seja,
ele será o mecanismo que vai fornecer ao Projeto um diferencial no que diz respeito ao
acesso às informações.
A velocidade na indexação é de grande importância, pois, um sistema que tem
45
um tempo muito alto de indexação certamente vai ser cansativo para o usuário final,
ou mesmo, se for necessário indexar uma grande quantidade de documentos, este
tempo poderá comprometer o desempenho de um sistema de GED. No OpenFTS este
tempo é bastante reduzido: para indexar um documento com mais de 11.000 palavras
ele levou menos de 2 segundos.
A recuperação de informações é hoje a principal impulsionadora dos sistemas
de GED, ou seja, o grande interesse de uma empresa é ter suas informações
disponíveis no menor tempo possível, podendo, então, uma ferramenta de indexação
ser agregada a outras funcionalidades de um sistema de GED, auxiliando até mesmo
em processos de grande importância para uma empresa como, auditorias e tomadas de
decisões.
Em todos os testes feitos com o OpenFTS, o tempo para encontrar palavras nos
documentos indexados foi muito pequeno, portanto, pode-se concluir que o OpenFTS
irá suprir perfeitamente a necessidade do Projeto OpenGED, como ferramenta de
busca e indexação de texto.
No Projeto OpenGED, a equipe optou pelo armazenamento de dois arquivos: o
original em formato PDF e outro em formato texto. Esta foi uma maneira de garantir a
integridade do documento original, pois, toda parte de indexação e consulta será feita a
partir do documento texto. Nota-se que este novo arquivo texto terá um tamanho bem
menor que o arquivo original. Portanto, está técnica não acarretará em um custo
elevado para o armazenamento de documentos.
6. CONSIDERAÇÕES FINAIS
O Projeto OpenGED nasceu da idéia de oferecer às instituições de ensino e
às pequenas empresas a possibilidade de utilizar ferramentas de GED, hoje largamente
utilizadas por grandes empresas.
Sem dúvida, o Projeto trouxe mais consciência sobre software livre, pois, a
distribuição sem custo não é a única vantagem destes programas. O Projeto OpenGED
só pôde ser concretizado pela existência dos softwares livres, distribuídos com seus
códigos fontes. Isto possibilitou à equipe do Projeto alterar e adaptar estes programas
conforme a necessidade. O OpenGED é totalmente adepto à filosofia de software livre
e será disponibilizado sob a licença GPL.
Um estudo sobre Gerenciamento Eletrônico de Documentos foi feito antes de
se dividir os trabalhos. Este estudo possibilitou o conhecimento das tecnologias que
envolvem o GED, que vão deste a digitalização de documentos até a recuperação das
informações. Além disso, possibilitou o amadurecimento das idéias para definição do
Projeto e possíveis problemas, destacando-se como encontrar uma solução para a
busca textual, quesito imprescindível nos sistemas de GED, e como desenvolver uma
aplicação prática para aplicar os conhecimentos adquiridos.
Possibilitou, também, o conhecimento sobre a realidade dos sistemas de
GED no Brasil e no mundo. Hoje, eles têm destacada importância nas grandes
empresas e nos grandes sistemas de informação, chamados ERPs, que já se integram
aos sistemas de GED.
A equipe do Projeto dividiu-se em três trabalhos: um estudo teórico sobre os
sistemas de GED, um estudo sobre indexação de documentos texto, que é o presente
trabalho e o desenvolvimento de uma aplicação prática.
47
A motivação para um estudo sobre indexação de documentos justifica-se por
esta ser o “motor” do GED. Além de ser um estudo bastante interessante, pois envolve
várias matérias vistas no decorrer do curso, como: algoritmos, técnicas de
programação, estruturas de dados, sistemas operacionais, redes de computadores,
engenharia de software, entre outras.
Inicialmente um estudo sobre estruturas de armazenamento foi feito para,
através do embasamento teórico, optar por uma estrutura que pudesse suprir todas as
necessidades do Projeto. Neste estudo encontraram-se algumas dificuldades, pois, a
maioria dos materiais estava na língua inglesa ou até mesmo em outras línguas, por
exemplo, o russo.
Para definição de uma ferramenta de indexação no início havia duas
alternativas: implementar uma ferramenta ou encontrar uma proposta que fosse
distribuída sob a licença GPL. Após varias pesquisas, foi encontrado o OpenFTS e,
então, optou-se pela segunda alternativa.
O OpenFTS é um sistema desenvolvido na Rússia, que agrega ao
PostgreSQL funções para trabalhar especificamente com textos. O OpenFTS
implementa uma árvore RD-Tree para fazer a indexação de documentos, por causa
disso, no capítulo 2 fez-se uma descrição mais detalhada apenas desta estrutura.
A equipe teve um grande trabalho para a instalação e configuração do
software, sendo a utilização do sistema operacional GNU/Linux um obstáculo.
Nos testes realizados com o OpenFTS, o desempenho do mesmo agradou
bastante, se comparando aos sistemas de indexação de soluções de GED comerciais,
que até então pareciam inalcançáveis.
Este trabalho visa contribuir tanto para o Projeto OpenGED como para o
crescimento de soluções de software livre. Como trabalhos futuros, ficam as sugestões:
construção de novos parsers, que poderiam ser utilizados no reconhecimento de outros
tipos de lexemas, trazendo assim uma possível melhoria de performance para
aplicações específicas; construção de novos dicionários para aplicações em áreas
específicas, como por exemplo, a construção de um dicionário que reconhecesse
termos relacionados à área de medicina ou área musical, entre outras.
REFERÊNCIAS BIBLIOGRÁFICAS
AIIM. Avant Imaging & Information Management Inc. Organização internacional
que oferece soluções para GED, workflow, impressão etc. Disponível em:
<http://www.aiim.com.br>. Acesso em: 02 mar. 2002.
CENADEM. Cenadem.com.br - O portal de GED do Brasil. Site desenvolvido pelo
Centro Nacional de Desenvolvimento do Gerenciamento da Informação.
Apresenta informações gerais sobre GED. Disponível em:
<http://www.cenadem.com.br>. Acessado em: 22 jun. 2002.
CENCI, J. A. Gerenciamento Eletrônico de Documentos: um estudo teórico para
definição do Projeto OpenGED. 2002. Trabalho de Conclusão de Curso
(Bacharelado em Informática) – Departamento de Ciência Exatas e Tecnológicas,
Universidade do Planalto Catarinense, Lages.
CPAN. Comprehensive Perl Archive Network. Disponibiliza módulos para a
linguagem Perl. Disponível em: <http://www.cpan.org>. Acessado em: 20 ago. 2002.
FSF. Free Software Foundation. Apresenta a filosofia do software livre e a licença
GPL. Disponível em: <http://www.fsf.org> . Acessado em: 01 abr. 2002.
GIST. The GiST Indexing Project. Apresenta o projeto GiST, dedicado ao estudo das
características de engenharia e matemática, associadas à indexação de grandes
quantidades de objetos complexos (por exemplo, um documento de texto). Disponível
em: <http://gist.cs.berkeley.edu/>. Acessado em: 12 ago. 2002.
GLIMPSE. Sistema de Pesquisa.Apresenta o site oficial do sistema de indexação e
pesquisa em arquivos textos. Disponível em: <http://www.webglimpse.net>. Acessado
em: 10 jun. 2002.
GREENSPUN, Philip. Chapter 12: Database Management Systems. Descreve
características de sistemas de banco de dados e exemplos de implementação de
sistemas de busca. Disponível em <http://philip.greenspun.com/panda/databaseschoosing.html>. Acessado em 05 Set. 2002.
HELLERSTEIN, J. M.; PFEFFER, A. The RD-Tree: an index struct for sets. 2000.
Disponível em: <http://db.cs.berkeley.edu/papers/UW-CS-TR-1252.pdf>. Acessado
em: 26 mai. 2002.
MAMBER, U. Glimpse: A Tool to Search Through Entire File System. 1993.
Apresenta um estudo sobre o Glimpse. Disponível em
49
<ftp://ftp.cs.arizona.edu/reports/1993/TR93-34.os.Z>. Acessado em: 12 out. 2002.
NEUBERT M. S. Recuperação aproximada de informações em textos comprimidos e
indexados. In: SEMANA DE PÓS-GRADUAÇÃO, 3., 1999, Belo Horizonte. Anais ...
Belo Horizonte: UFMG, 1999. Disponível em:
<http://www.dcc.ufmg.br/pos/html/spg99/anais/marden/marden.html>. Acessado em:
01 abr. 2002.
OLIVEIRA FILHO, F. M. Biblioteca On-line para Trabalhos de Conclusão de
Curso: uma aplicação desenvolvida sob o Projeto OpenGED. 2002. Trabalho de
Conclusão de Curso (Bacharelado em Informática) – Departamento de Ciências Exatas
e Tecnológicas, Universidade do Planalto Catarinense, Lages. (Em andamento).
OPENFTS. Open Source Full Text Search Engine. Apresenta o site oficial do
sistema de indexação e busca textual.Disponível em: <http://openfts.sourceforge.net>.
Acessado em: 01 mai. 2002.
POSTGRESQL. Sistema Gerenciador de Banco de Dados Objeto-Relacional.
Apresenta o site oficial do PostgreSQL. Disponível em: <http://postgres.org>.
Acessado em: 26 mai. 2002.
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de Banco de
Dados.3.ed. Trad.Marilia G. Pinheiro e Claudio C. Canhette. São Paulo: Makron
Books, 1999. 778 p.
SILVA, E. B. da. Uma Ferramenta de Auxílio à Busca e Recuperação de
Documentos. Disponível em:
<http://www.cos.ufrj.br/~bezerra/publications/pf/PF.html>. Acessado em: 10 mai.
2002.
SNOWBALL.Snowball. Apresenta o projeto Snowball, que é uma linguagem de
processamento de texto usada na recuperação de informações. Disponível em:
<http://snowball.tartarus.org>. Acessado em: 05 Nov. 2002.
WALL, L.; CHRISTIANSEN, T.; ORWANT, J. Programação Perl. 3. ed. Trad.
Daniel Vieira. Rio de Janeiro: Campus, 2001. 1084 p.
WIVES, L. K. Tecnologia de Descoberta de Conhecimentos em Textos Aplicada a
Inteligência Competitiva. 2002. (Exame de Qualificação) – Programa de PósGraduação em Computação, Universidade Federal do Rio Grande do Sul. Disponível
em: <http://www.inf.ufrgs.br/~wives/publicacoes/eq.pdf>. Acessado em: 14 set. 2002.