UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE …siaibib01.univali.br/pdf/Rodrigo Andreatta da...

UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR

CURSO DE CIÊNCIA DA COMPUTAÇÃO

ANÁLISE DE MÉTODOS DE CONSULTA POR SIMILARIDADE DE TEXTOS EM BANCO DE DADOS

Área de Banco de Dados

por

Rodrigo Andreatta da Costa

Julia Marques Carvalho da Silva, MSc Orientadora

Itajaí (SC), dezembro de 2008

UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR

CURSO DE CIÊNCIA DA COMPUTAÇÃO

ANÁLISE DE MÉTODOS DE CONSULTA POR SIMILARIDADE DE TEXTOS EM BANCO DE DADOS

Área de Banco de Dados

por

Rodrigo Andreatta da Costa Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientadora: Julia Marques C. da Silva, MSc

Itajaí (SC), dezembro de 2008

ii

SUMÁRIO

LISTA DE ABREVIATURAS...................................................................v

LISTA DE FIGURAS................................................................................vi LISTA DE TABELAS............................................................................... ix

RESUMO.....................................................................................................x

ABSTRACT................................................................................................xi 1 INTRODUÇÃO......................................................................................1

1.1 PROBLEMATIZAÇÃO ..................................................................................... 3 1.1.1 Formulação do Problema................................................................................. 3 1.1.2 Solução Proposta ............................................................................................... 3 1.2 OBJETIVOS ........................................................................................................ 3 1.2.1 Objetivo Geral ................................................................................................... 3 1.2.2 Objetivos Específicos ........................................................................................ 3 1.3 METODOLOGIA................................................................................................ 4 1.4 ESTRUTURA DO TRABALHO ....................................................................... 5

2 FUNDAMENTAÇÃO TEÓRICA........................................................6

2.1 BANCO DE DADOS ........................................................................................... 6 2.1.1 Linguagem SQL ................................................................................................ 9 2.1.2 Algoritmos para Operações de Consulta...................................................... 12 2.1.3 Funções para Tratamento de Strings ............................................................ 13 2.2 ALGORITMOS DE BUSCA............................................................................ 15 2.2.1 Algoritmo da Força Bruta.............................................................................. 15 2.2.2 Algoritmo de Knuth-Morris-Pratt ................................................................ 16 2.2.3 Algoritmo de Boyer-Moore ............................................................................ 20 2.2.4 Algoritmo de Rabin-Karp .............................................................................. 24 2.2.5 Algoritmo de Levenshtein .............................................................................. 27 2.2.6 Algoritmo de Smith Waterman ..................................................................... 28 2.2.7 Algoritmo de Stochastic Model...................................................................... 29 2.2.8 Algoritmo de Jaro Metric............................................................................... 30 2.2.9 Algoritmo de Hamming Distance .................................................................. 31 2.2.10 Algoritmo de Soundex Distance Metric ........................................................ 31 2.2.11 Algoritmo de Convington’s Distance Function............................................ 33 2.2.12 Considerações sobre os Algoritmos de Similaridade Analisados............... 33 2.3 APLICAÇÕES COM ALGORITMOS DE SIMILARIDADE..................... 34 2.3.1 Similarity Retrivel Engine.............................................................................. 35 2.3.2 XSimilarity....................................................................................................... 37 2.3.3 Sistema de Reconhecimento de Imagens Similares ..................................... 41 2.3.4 Considerações sobre os aplicativos similares ............................................... 43

iii

2.4 SISTEMA DE AVALIAÇÃO DA PESQUISA INSTITUCIONAL ............. 44

3 PROJETO.............................................................................................52

3.1.1 Hamming Distance.......................................................................................... 53 3.1.2 Levenshtein ...................................................................................................... 55 3.1.3 KMP ................................................................................................................. 60 3.1.4 Jaro................................................................................................................... 62 3.1.5 Rabin-Karp...................................................................................................... 63 3.1.6 Algoritmo Proposto......................................................................................... 66 3.2 TESTES .............................................................................................................. 67 3.3 RESULTADOS OBTIDOS............................................................................... 69 3.4 ANÁLISE DA HIPÓTESE ............................................................................... 71 3.4.1 Hipótese 1......................................................................................................... 72 3.4.2 Hipótese 2......................................................................................................... 72 3.4.3 Hipótese 3......................................................................................................... 73 3.4.4 Hipótese 4......................................................................................................... 73 3.4.5 Hipótese 5......................................................................................................... 73 3.4.6 Hipótese 6......................................................................................................... 74 3.4.7 Conclusões........................................................................................................ 74

4 CONCLUSÃO ......................................................................................75

REFERÊNCIAS BIBLIOGRÁFICAS ...................................................77

A Cenários de testes .................................................................................80

A.1 CENÁRIO 1: USUÁRIO COM POUCAS PRODUÇÕES............................ 80 A.1.1 Cenário 1a: Participação em Bancas ............................................................ 80 A.1.2 Cenário 1b: Projeto de Pesquisa.................................................................... 81 A.1.3 Cenário 1c: Artigo em Evento Nacional ....................................................... 82 A.1.4 Cenário 1d: Orientação de TCC.................................................................... 83 A.1.5 Cenário 1e: Projeto de Pesquisa .................................................................... 84 A.1.6 Cenário 1f: Projeto de Pesquisa .................................................................... 84 A.1.7 Cenário 1g: Participação em Banca .............................................................. 85 A.1.8 Cenário 1h: Participação em Banca.............................................................. 86 A.1.9 Cenário 1i: Participação em banca ............................................................... 87 A.2 CENÁRIO 2 – USUÁRIO COM MAIS DE 1000 PRODUÇÕES................. 88 A.2.1 Cenário 2a: Participação em Banca .............................................................. 88 A.2.2 Cenário 2b: Artigo em Evento Internacional............................................... 89 A.2.3 Cenário 2c: Artigo em Evento Nacional ....................................................... 90 A.2.4 Cenário 2d: Curso de Curta Duração........................................................... 91 A.2.5 Cenário 2e: Participação em Banca .............................................................. 92 A.2.6 Cenário 2f: Artigo em Evento Internacional................................................ 93 A.2.7 Cenário 2g: Resumo em Evento Nacionais................................................... 94 A.2.8 Cenário 2h: Artigo em Evento Internacional............................................... 95 A.2.9 Cenário 2i: Comissão de Avaliação de Cursos............................................. 96

iv

A.2.10 Cenário 2j: Artigo em Evento Nacional................................................. 97

v

LISTA DE ABREVIATURAS

BD Banco de Dados CCIFM Centro de Ciências das Imagens e Física Médica CGI Common Gateway Interface CNPq Conselho Nacional de Desenvolvimento Científico e Tecnológico CPF Cadastro de Pessoa Física DCL Data Control Language DDL Data Definition Language DLL Dynamic-link library DML Data Manipulation Language DNA Deoxyribonucleic acid DQL Data Query Language HCFMRP Hospital das Clínicas da Faculdade de Medicina de Ribeirão Preto KMP Knuth-Morris-Pratt ODBC Open Data Base Connectivity PACS Picture Archiving and Communication System PL/SQL Procedural Language/Structured Query Language PROPPEC Pró-reitoria de Pesquisa, Pós-graduação, Extensão e Cultura SAPI Sistema de Avaliação da Produção Institucional SIREN Similarity Retrivel Engine SGBD Sistema Gerenciador de Banco de Dados SQL Structured Query Language SRIS Sistema de Reconhecimento de Imagens Similares TCC Trabalho de Conclusão de Curso UNIVALI Universidade do Vale do Itajaí XML Extensible Markup Language

vi

LISTA DE FIGURAS

Figura 1. Exemplo de banco de dados relacional.................................................................................8 Figura 2. Sintaxe do comando de consulta.........................................................................................10 Figura 3. Exemplo de uma consulta SQL ..........................................................................................12 Figura 4. Exemplo de uma consulta SQL com operador LIKE..........................................................12 Figura 5. Tipos de alinhamentos de strings........................................................................................15 Figura 6. Exemplo de funcionamento do algoritmo de força bruta ...................................................16 Figura 7. Exemplo da fórmula para calculo da próxima posição a ser utilizada na comparação do

algoritmo KMP...........................................................................................................................18 Figura 8. Valores de d(k) para o exemplo da Figura 6.......................................................................19 Figura 9. Algoritmo para determinação do D(k)................................................................................19 Figura 10. Resolução do mesmo exemplo mostrado na Figura 6, mas com a utilização do algoritmo

de KMP ......................................................................................................................................20 Figura 11. Explicação da heurística do bom sufixo e do mau caractere ............................................21 Figura 12. Exemplo da utilização da heurística do mau caractere baseado na Figura 11 ..................21 Figura 13. Exemplo da utilização da heurística do bom sufixo baseado na Figura 11 ......................22 Figura 14. Exemplo de applet comparando as palavras “a costa” e “rodrigo a costa” ......................23 Figura 15. Resultado da pesquisa do algoritmo Boyer-Moore...........................................................24 Figura 16. Exemplo do algoritmo de Rabin Karp. .............................................................................26 Figura 17. Definição da função de Levenshtein.................................................................................27 Figura 18. Exemplo de applet comparando as palavras “andreata” e “andreatta”.............................28 Figura 19. Definição da função de Smith Waterman .........................................................................29 Figura 20. Exemplo de comparação usando a função Smith Waterman............................................29 Figura 21. Métrica do algoritmo de Jaro. ...........................................................................................30 Figura 22. Exemplo da métrica de Jaro..............................................................................................31 Figura 23. Exemplo de cadeia de bits ................................................................................................31 Figura 24. Atribuição de valores do algoritmo de Convington’s Distance ........................................33 Figura 25. Exemplo de execução de consultas por similaridade sobre a tabela Exame, k-NN query

usando a métrica textura.............................................................................................................36 Figura 26. Exemplo da execução de consultas por similaridade sobre a tabela automóveis. ............37 Figura 27. Casos de uso apresentando as principais funcionalidades do sistema ..............................38 Figura 28. Interface do Xsimilarity ....................................................................................................39 Figura 29. Exemplo arquivo XML.....................................................................................................40 Figura 30. Exemplo de uma consulta do XSimilarity ........................................................................41 Figura 31. Visualização das imagens médicas do SRIS.....................................................................42 Figura 32. Tela de resultados de consultas por similaridade do SRIS ...............................................43 Figura 33. Tela do SAPI.....................................................................................................................46 Figura 34. Referências das produções................................................................................................47 Figura 35. Detalhes das produções.....................................................................................................48 Figura 36. Diagrama entidade-relacionamento do SAPI ...................................................................49 Figura 37. Código PHP do SAPI utilizado para efetuar a comparação..............................................51 Figura 38. Sintaxe das funções de similaridade produzidas...............................................................52 Figura 39. Comparação entre as strings “ABACATE” e “ABATE”. ................................................53 Figura 40. Implementação da função Hamming Distance. ................................................................54 Figura 41. Resultado da comparação entre as palavras ABACATE e ABATE utilizando a função

Hamming Distance. ....................................................................................................................54

vii

Figura 42. Tabela gerada na comparação entre as palavras “ABACATE” e “ABATE” utilizando a função Hamming Distance. ........................................................................................................55

Figura 43. Trecho principal do código da função Levenshtein..........................................................55 Figura 44. Resultado da comparação entre as palavras “ABACATE” e “ABATE” utilizando a

função Levenshtein. ...................................................................................................................56 Figura 45. Primeiro passo do exemplo do algoritmo de Levenshtein. ...............................................56 Figura 46. Primeira comparação da segunda iteração do exemplo do algoritmo de Levenshtein. ....57 Figura 47. Segunda comparação da segunda iteração do exemplo do algoritmo de Levenshtein. ....58 Figura 48. Terceira comparação da segunda iteração do exemplo do algoritmo de Levenshtein......58 Figura 49. Quarta comparação da segunda iteração do exemplo do algoritmo de Levenshtein. .......59 Figura 50. Quinta comparação da segunda iteração do exemplo do algoritmo de Levenshtein. .......60 Figura 51. Resultado final da tabela de comparações do exemplo do algoritmo de Levenshtein .....60 Figura 52. Implementação da função KMP. ......................................................................................61 Figura 53. Resultado da comparação entre as strings “ABACATE” e “ABATE” utilizando o

algoritmo KMP...........................................................................................................................61 Figura 54. Primeira comparação do exemplo do algoritmo KMP. ....................................................61 Figura 55. Segunda comparação do exemplo do algoritmo KMP. ....................................................62 Figura 56. Resultado da comparação entre “ABACATE” e “ABATE” utilizando o algoritmo Jaro.

....................................................................................................................................................62 Figura 57. Implementação da função KMP. ......................................................................................63 Figura 58. Implementação da função Rabin-Karp. ............................................................................64 Figura 59. Resultado da comparação entre as strings “ABACATE” e “ABATE” utilizando o

algoritmo Rabin-Karp. ...............................................................................................................64 Figura 60. Primeira comparação do exemplo do algoritmo de Rabin-Karp. .....................................65 Figura 61. Segunda comparação do exemplo do algoritmo de Rabin-Karp. .....................................65 Figura 62. Terceira comparação do exemplo do algoritmo de Rabin-Karp.......................................66 Figura 63. Terceira comparação do exemplo do algoritmo de Rabin-Karp.......................................67 Figura 64. Gráfico do número de docentes por faixa de quantidade de produções. ..........................68 Figura 65. Gráfico da média do grau de similaridade resultante dos dois cenários de testes. ...........70 Figura 66. Gráfico da média do tempo de execução em segundos resultante dos dois cenários de

testes. ..........................................................................................................................................71 Figura 67. Teste Z para comparação entre médias.............................................................................72 Figura 68. Produção original e alterada do cenário 1a. ......................................................................80 Figura 69. Produção original e alterada do cenário 1b.......................................................................81 Figura 70. Produção original e alterada do cenário 1c. ......................................................................82 Figura 71. Produção original e alterada do cenário 1d.......................................................................83 Figura 72. Produção original e alterada do cenário 1e. ......................................................................84 Figura 73. Produção original e alterada do cenário 1f. ......................................................................85 Figura 74. Produção original e alterada do cenário 1g.......................................................................86 Figura 75. Produção original e alterada do cenário 1h.......................................................................87 Figura 76. Produção original e alterada do cenário 1i........................................................................88 Figura 77. Produção original e alterada do cenário 2a. ......................................................................89 Figura 78. Produção original e alterada do cenário 2b.......................................................................90 Figura 79. Produção original e alterada do cenário 2c. ......................................................................91 Figura 80. Produção original e alterada do cenário 2d.......................................................................92 Figura 81. Produção original e alterada do cenário 2e. ......................................................................93 Figura 82. Produção original e alterada do cenário 2f. ......................................................................94 Figura 83. Produção original e alterada do cenário 2g.......................................................................95 Figura 84. Produção original e alterada do cenário 2h.......................................................................96

viii

Figura 85. Produção original e alterada do cenário 2i........................................................................97 Figura 86. Produção original e alterada do cenário 2j........................................................................98

ix

LISTA DE TABELAS

Tabela 1. Composição de um comando de seleção ............................................................................11 Tabela 2. Comparação entre funções dos bancos Oracle, Postgre e SQL Server ..............................14 Tabela 3. Regras do Soundex Code ...................................................................................................32 Tabela 4. Exemplo da regra do algoritmo Soundex Code com a string “Dickson” e “Dixon”. ........32 Tabela 5. Valores das penalidades da função de Convigton’s Distance ............................................33 Tabela 6. Tabela comparativa entre aplicativos similares..................................................................44 Tabela 7. Tabela de resultados geral dos testes quanto ao grau de similaridade ...............................69 Tabela 8. Tabela de resultados do cenário 1a.....................................................................................81 Tabela 9. Tabela de resultados do cenário 1b. ...................................................................................81 Tabela 10. Tabela de resultados do cenário 1c...................................................................................82 Tabela 11. Tabela de resultados do cenário 1d. .................................................................................83 Tabela 12. Tabela de resultados do cenário 1e...................................................................................84 Tabela 13. Tabela de resultados do cenário 1f. ..................................................................................85 Tabela 14. Tabela de resultados do cenário 1g. .................................................................................86 Tabela 15. Tabela de resultados do cenário 1h. .................................................................................87 Tabela 16. Tabela de resultados do cenário 1i. ..................................................................................88 Tabela 17. Tabela de resultados do cenário 2a...................................................................................89 Tabela 18. Tabela de resultados do cenário 2b. .................................................................................90 Tabela 19. Tabela de resultados do cenário 2c...................................................................................91 Tabela 20. Tabela de resultados do cenário 2d. .................................................................................92 Tabela 21. Tabela de resultados do cenário 2e...................................................................................93 Tabela 22. Tabela de resultados do cenário 2f. ..................................................................................94 Tabela 23. Tabela de resultados do cenário 2g. .................................................................................95 Tabela 24. Tabela de resultados do cenário 2h. .................................................................................96 Tabela 25. Tabela de resultados do cenário 2i. ..................................................................................97 Tabela 26. Tabela de resultados do cenário 2j. ..................................................................................98

x

RESUMO

COSTA, Rodrigo Andreatta da. Análise de Métodos de Consulta por Similaridade de Textos em Banco de Dados. Itajaí, 2008. 127 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2008. Os sistemas de bancos de dados evoluíram nos últimos anos, sendo cada vez mais comum encontrar bases com grandes volumes de dados. Nelas são encontradas informações dos mais diversos tipos, números, textos, datas e inclusive dados de tipos mais complexos, como arquivos e imagens. Porém estas informações não têm muita valia se não puderem ser recuperadas de alguma forma. A consulta vem a ser, por este motivo, uma funcionalidade muito importante para auxiliar os usuários. Contudo este procedimento permite apenas pesquisas por palavras fixas. Por outro lado, existem aplicações que necessitam realizar buscas textuais cujas consultas não podem retornar resultados iguais (idênticos) ou distintos, mas qual é o grau de semelhança. O objetivo deste trabalho é apresentar os principais algoritmos de busca por similaridade de textos, escolher alguns para serem implementados e analisar qual melhor se adequa ao cenário do Sistema de Avaliação da Produção Institucional (SAPI) e executar uma comparação entre os resultados obtidos nos testes. Palavras-chave: Busca por String. Algoritmos de Similaridade. Similaridade de Textos.

xi

ABSTRACT

The databases systems have been improved significantly in the last years. Nowadays, it’s very

common to find bases with a large number of records. They are able to store different kinds of data,

like numbers, characters, date and also complex data as images and files. But this stored

information doesn’t have any value if it cannot be recovered. The query comes to be, therefore, a

very important feature to help the users. The problem is that the database management systems

allow only exact searches. Otherwise, there are applications that need to do text searches can’t

return distinct or identical results, but the similarity’s degree. The aim of this work is to show some

algorithms to search for similar texts, choose some of them to implement and to analyze which is

the best for the scenario of SAPI and to execute a comparison among the test’s results.

Keywords: String Searches, Similarity Algorithms, Text Similarity.

1 INTRODUÇÃO

No passado era comum encontrar em empresas áreas de arquivamento de documentos, tanto

de texto, quanto de imagens, vídeos e sons, que formavam uma base de dados. O armazenamento

requeria muito espaço físico e a busca por informações era lenta e imprecisa. Com o

aperfeiçoamento da tecnologia, foi criada uma forma computacional de guardar estas informações,

forma esta que ficou conhecida como banco de dados.

Os bancos de dados costumam ser acessados e configurados por um sistema gerenciador de

banco de dados (SGBD). O SGBD normalmente utiliza um modelo relacional, onde as estruturas

têm forma de tabelas, compostas por linhas e colunas.

Em bancos de dados pode ocorrer o armazenamento de dados semelhantes, um exemplo

disso ocorre em bibliotecas digitais. Em uma base de dados composta pela integração de sistemas

de informações externos pode acontecer de existir informações relacionadas ao mesmo assunto,

porém gravadas de maneiras diferentes.

Borges et al. (2005) cita como exemplo o caso onde, o nome de uma cidade pode estar

armazenado das seguintes formas: “Rio Grande - RS”, “R. Grande”, “Rio Grande”, “Rio Graande.”

e assim por diante. Nestes casos, como não há como afirmar se duas representações são

provenientes de um mesmo objeto, uma saída é criar um mecanismo que verifique a proximidade

entre os valores.

Entretanto as possibilidades de busca e cruzamento de informações são realizadas de

diversas formas, possibilitando que uma consulta retorne dados não pertinentes. Neste cenário, para

se conseguir realizar uma consulta eficaz e confiável, é necessário a indexação adequada dos

registros armazenados na base que possua suporte à similaridade, o que nem sempre ocorre.

A idéia da técnica de busca por similaridade é baseada em recuperar objetos semelhantes ou

próximos ao elemento pesquisado, sendo definido como espaço métrico o conjunto dos objetos

referenciados. Na atualidade existem programas na área da medicina que utilizam Content-based

image retrieval em consultas à banco de dados de imagens.

2

Santos Filho (2001 apud Borges et al., 2005) afirma que: “Esta técnica executa comparações

por semelhança, permitindo uma consulta precisa o suficiente para que possa retornar resultados

satisfatórios, porém não tão precisa que venha deixar de retornar resultados relevantes.”.

Outra possível utilização de similaridade em consultas está na validação de estruturas

genéticas, onde uma seqüência de DNA (formada por agrupamento de letras que dão origem a

cadeias compostas por milhares de nucleotídeos). Altschul (1990) apud Souza (2004) desenvolveu

uma ferramenta capaz de definir o coeficiente de semelhança entre diferentes cadeias de seqüências.

A busca em textos é um importante recurso utilizado em ferramentas para edição de texto,

para recuperação de dados e manipulação de símbolos. Segundo Carvalho et al. (2005):

Os problemas de busca em texto consistem em encontrar todas as ocorrências (ou a primeira ocorrência) de uma palavra no texto. Onde a palavra e o texto são strings de um mesmo alfabeto. O importante é reportar todas as ocorrências sabendo-se que a busca por uma palavra de tamanho m em um texto de tamanho n (onde n > m) tem um tempo O(n) no pior caso (para m fixo).

A UNIVALI possui um sistema conhecido como Sistema de Avaliação da Produção

Institucional (SAPI) que é utilizado para gerenciar as produções dos docentes, mantendo uma base

de dados de todas as produções que são desenvolvidas, de forma integrada com o sistema Lattes.

Uma produção é qualquer artigo, trabalho acadêmico ou orientação. Cada produção

registrada no Lattes é carregada para o SAPI. Neste momento, cada produção do Lattes é

comparada com aquelas que já existem no currículo do SAPI, onde aquelas que apresentam 90% de

similaridade são consideradas iguais e então os dados são atualizados. As produções com menos de

90% são consideradas como novas e inseridas no SAPI.

Atualmente, para realizar esta comparação todas as produções do Lattes e do SAPI são

carregadas para a página PHP e então comparadas. Esta tarefa demanda um alto processamento do

servidor web, onde em currículos com alto número de produções (por exemplo, 450 produções)

pode levar até cinco minutos para realizar o processamento.

Considerando o cenário citado acima, surgiu a idéia de desenvolver rotinas implementadas

nos sistemas gerenciadores de banco de dados para resolver o problema de lentidão nas

comparações e também nas ineficiências existentes no processo.

3

Atualmente, os sistemas gerenciadores de banco de dados (SGBD's) comerciais existentes

não conseguem executar consultas de strings aproximadas para textos (GRAVANO, 2001 apud

BORGES, CONY, FREITAS, 2005). Desta forma, o presente TCC visa pesquisar e avaliar

algoritmos de pesquisa que consigam distinguir informações similares, mas que possam estar

representadas de maneiras diferentes em base de dados textuais.

1.1 PROBLEMATIZAÇÃO

1.1.1 Formulação do Problema

Os SGBD’s foram criados para permitir o armazenamento de informações, permitindo aos

usuários a recuperação dos dados através de consultas. Estas consultas possuem certa restrição, pois

apenas são possíveis comparações exatas com operadores do tipo: maior que, menor que, igual,

diferente, entre outros. Uma deficiência deste sistema está no fato da impossibilidade da execução

de consultas buscando por informações similares. Na grande maioria dos gerenciadores de banco de

dados há apenas funções para alterar a formatação e comparação de strings.

1.1.2 Solução Proposta

A solução proposta é pesquisar funções baseadas em algoritmos que realizam busca por

similaridade. Após análise das funções encontradas foram escolhidas algumas delas para serem

implementadas e disponibilizadas no SGBD. Foram realizados testes para saber qual algoritmo

realiza as buscas trazendo os dados mais próximos aos desejados e com o melhor desempenho. E

por último, foi documentado os resultados de cada algoritmo codificado.

1.2 OBJETIVOS

1.2.1 Objetivo Geral

Investigar, implementar e avaliar o uso de algoritmos de busca por similaridade, baseados

em métricas de distância entre Strings.

1.2.2 Objetivos Específicos

• Pesquisar e analisar possíveis aplicações similares;

• Compreender o processo de pesquisa em banco de dados;

4

• Pesquisar e definir os algoritmos que serão implementados;

• Implementação dos algoritmos:

o KMP;

o Rabin Karp;

o Levenshtein;

o Hamming Distance;

o Jaro.

• Testes dos algoritmos;

• Comparar os algoritmos, resultados obtidos e documentar informações sobre as

informações obtidas.

1.3 METODOLOGIA

O projeto tem como modelo de metodologia as seguintes etapas principais: (i) estudo; (ii)

especificação; (iii) implementação; (iv) testes; e (v) documentação.

A etapa de estudo tem como função a análise do problema que gerou o motivo do trabalho,

pesquisa de tecnologias necessárias para o desenvolvimento dos objetivos propostos, busca por

produtos similares e análise quanto a viabilidade do projeto.

A especificação é a segunda etapa do projeto proposto. É nesta fase que é feito o

levantamento e definição do que será desenvolvido, é procurado por algoritmos que possuem

características de pesquisa em textos, é feita a escolha os algoritmos que serão codificados e

formulada a criação da documentação em geral.

O próximo passo é a implementação dos algoritmos que foram escolhidos na etapa de

especificação. Nesta fase também se encontra a tarefa da obtenção e instalação do SGBD. Nesta

fase foram escolhidos alguns dos algoritmos encontrados para serem transformados em funções

codificadas na linguagem PL/SQL.

As duas últimas etapas são os testes e documentação, onde após a criação de um banco de

dados real são processadas as rotinas com as funções criadas. Para os testes, foram selecionados

registros da base de dados obtida. Após isso, cada registro foi copiado e modificado para ser

5

executado nas funções. Cada dupla de registros (original e modificado) teve sua similaridade

calculada pelos algoritmos implementados e também por uma função do PHP chamada similar_text

para haver um ponto de referência ao avaliar os resultados gerados em cada teste.

1.4 ESTRUTURA DO TRABALHO

Este trabalho está dividido em quatro capítulos principais, onde no primeiro é descrita uma

introdução do assunto de banco de dados, explicado qual o problema que originou a idéia deste

trabalho e definida qual a solução proposta. Também são expostos os objetivos gerais e específicos

do projeto.

O segundo capítulo é composto pela fundamentação teórica, onde são explicados os

principais assuntos que serão abordados no trabalho. Há tópicos que conceituam e definem os temas

de banco de dados, linguagem SQL, principais algoritmos existentes para realização de consultas

em banco de dados, funções para tratamentos de strings e os aplicativos existentes no mercado que

possuem uma funcionalidade parecida ao projeto proposto.

O terceiro capítulo é formado pela implementação dos algoritmos escolhidos, onde são

selecionadas duas palavras para serem aplicadas às funções e para explicar como cada algoritmo se

comporta para as mesmas variáveis de entrada. Este capítulo é a base de informação para

documentar o capítulo quatro que é onde são comentados os resultados obtidos.

2 FUNDAMENTAÇÃO TEÓRICA

Considerando que este trabalho é focado ao assunto de banco de dados, mais

especificadamente ao procedimento de consultas por strings em textos, neste capítulo serão

apresentados alguns conceitos sobre banco de dados, a linguagem utilizada para realizar consultas,

algoritmos existentes e algumas funções utilizadas para tratamento de strings.

2.1 BANCO DE DADOS

No cotidiano, a maioria das pessoas se depara com situações ou atividades que utilizam

algum tipo de banco de dados. Situações como, ir ao banco imprimir um extrato da conta, fazer uma

reserva de um hotel ou passagem aérea, consultar a disponibilidade de livros em uma biblioteca e

consultar preços de produtos em supermercados são formas invisíveis de interação com banco de

dados.

Segundo Date (2007) banco de dados é basicamente um sistema computacional que executa

a manutenção de registros. Pode ser feita uma comparação como sendo o equivalente eletrônico de

um armário de arquivamento, onde são armazenados conjuntos de arquivos de dados

computadorizados. Podem também ser considerados como um sistema de computador cuja função

principal é armazenar informações, permitindo que estas possam ser consultadas ou alteradas

quando necessário.

Para Elmasri (2006) “Um banco de dados é uma coleção de dados relacionados. Os dados

são fatos que podem ser gravados e que possuem um significado implícito”.

Estes sistemas podem ser encontrados desde em pequenos computadores de mão (palm),

computadores pessoais, até grandes mainframes ou clusters de computadores, sendo que quanto

mais mobilidade existir menor é a quantidade de recursos fornecidos pelo sistema. Em máquinas

com grande poder de processamento os sistemas costumam ser multi-usuário, onde mais de que um

usuário pode acessar o banco de dados ao mesmo tempo, diferentemente do que ocorre em sistemas

monousuário.

Date (2007) caracteriza os dados de um banco de dados como integrados e compartilhados,

pois é uma unificação de vários arquivos que podem ser acessados por mais de um usuário onde,

7

normalmente, cada usuário está interessado em apenas uma pequena parte das informações

armazenadas.

Segundo Elmasri e Navathe (2006), um banco de dados pode ser de qualquer tamanho e ter

sua complexidade variável, podendo ser mantido manualmente ou automaticamente.

Quando se está lendo sobre banco de dados é comum encontrar o termo Sistema

Gerenciador de Banco de Dados, conhecido como SGBD. Trata-se de um conjunto de softwares

(programas) responsáveis por manter o banco de dados em funcionamento. Segundo Date (2007), o

SGBD é a peça mais importante de todo o sistema. De uma forma simples, ele está localizado entre

o banco de dados físico (hardware), onde os dados estão realmente gravados, e o usuário que está

utilizando o sistema.

Para Elmasri e Navathe (2006) “O SGBD é um sistema de software de propósito geral que

facilita os processos de definição, construção, manipulação e compartilhamento de banco de dados

entre vários usuários e aplicações”.

Atualmente os SGBD’s utilizam o modelo de dados relacional que foi considerado como

sendo o mais flexível e adequado para tratar os vários problemas que se colocam no nível de

implementação da base de dados. A estrutura fundamental do modelo relacional é a relação (tabela),

que é formada por várias linhas (conhecidas como registros) que por sua vez são compostas por um

ou mais atributos que guardam o tipo de dados a ser armazenado.

Um SGBD possui algumas funcionalidades importantes, como por exemplo:

• Controlar a concorrência entre usuários ou programas: isto ocorre pois a mesma

informação não pode ser alterada por mais de um recurso ao mesmo tempo.

Considerando como exemplo uma reserva de passagem de avião, no momento em

que a atendente estiver realizando uma alteração na reserva do passageiro, o registro

que possui as informações desta reserva é bloqueado pelo SGBD contra a ação de

outros recursos (outros funcionários ou rotinas que são executadas no banco de

dados). Apenas a pós o fim da tarefa da atendente é que o registro é liberado para

outra operação. Segundo Mattoso (2005), o bloqueio pode ser lógico (através de

linguagem de programação) ou físico (travando o registro ou a tabela).

8

• Controlar as transações: por exemplo, em uma operação de reserva de vôo, no

decorrer das alterações feitas pela atendente operações de inserção, deleção e

alteração são executadas, porém serão percebidas ou visualizadas por outros recursos

apenas após a confirmação (comando conhecido como commit) ou rejeição

(comando conhecido como roolback) das ações.

• Controlar o acesso feito pelos usuários: é possível atribuir permissões para cada

usuário separadamente ou para grupos informando quais tabelas cada um tem acesso

e quais operações (alteração, inserção, deleção, consulta) cada um pode realizar.

• Controle de integridade nos dados: por exemplo, em uma operação de reserva de

vôo, o SGBD deve validar o que a atendente está informando como cidade destino,

sendo que, a tabela de reservas pode aceitar apenas cidades que já foram cadastradas

em outra tabela no banco de dados.

Por exemplo, a Figura 1 apresenta a tabela CURSO, com quatro registros, sendo que cada

registro é composto pelos campos NOME, NÚMERO, CRÉDITOS e DEPARTAMENTO.

Figura 1. Exemplo de banco de dados relacional

Um ponto interessante no modelo ER é que não há caminhos pré-definidos para se fazer

acesso aos dados. Por exemplo, é possível ligar a tabela CURSO (campo “Número”) com a tabela

9

SECAO (campo “Curso”). Da mesma forma pode-se ligar a tabela CURSO (campo “Número”) com

a tabela PRE-REQUISITO (campo “Número”) para saber qual curso precisa ser feito primeiro.

Contudo, para a utilização de tal funcionalidade, precisa-se tomar cuidado de alguns fatores

como, por exemplo, a repetição de informação e a incapacidade de representar parte da informação

e perda de informação.

2.1.1 Linguagem SQL

A SQL (Structured Query Language), conhecido também como Linguagem de Consulta

Estruturada, é uma linguagem padrão de pesquisa criada para se comunicar com bancos de dados.

Segundo Battisti (2006), esta linguagem foi desenvolvida para ser independente de hardware e

software.

Para Battisti (2006):

Ao usar o SQL, não é necessário saber a respeito do software de banco de dados ou do hardware envolvido em uma operação. Tudo o que você precisa conhecer são os comandos/instruções SQL padrão para solicitar informações, que obrigatoriamente é o mesmo em todos os sistemas que utilizam o SQL.

Battisti (2006) comenta que as instruções SQL são conduzidas com um único comando que

contém uma descrição completa da informação exigida. Explica também que o maior benefício do

método SQL é não haver a necessidade de se preocupar em como os dados são recuperados, mas

somente com o conteúdo do conjunto de dados.

Segundo Leme (2006), os comandos SQL são divididos conforme abaixo:

• Data Definition Language (DDL), Linguagem de Definição de Dados: Permite ao

usuário criar/apagar tabelas, índices e visões. Os principais comandos são create, drop e

alter.

• Data Manipulation Language (DML), Linguagem de Manipulação de Dados: Permite ao

usuário inserir, alterar, apagar ou selecionar registros (dados) em uma tabela. Os

principais comandos são insert, update, delete e select.

• Data Control Language (DCL), Linguagem de Controle de Dados: Controla as

permissões de acesso dos usuários do banco de dados para ver ou manipular

informações. Os principais comandos são grant e revoke.

10

• Data Query Language (DQL), Linguagem de Recuperação de Dados: É a parte da SQL

mais utilizada, sendo baseada no comando select para elaborar consultas.

Um dos comandos DML mais importante é a Consulta (select), pois é responsável por

recuperar os dados armazenados no banco de dados utilizando, ou não, critérios de restrição e

junção a outras tabelas. Sua sintaxe é apresentada na Figura 2.

SELECT [predicado] {*|tabela.*|[tabela.]campo1 [AS alias1] [,[tabela.]campo2 [AS alias2] [, ...]]} FROM tabelaexpression [, ...] [@externaldatabase] [WHERE <condição>] [GROUP BY <atributos agrupados>] [HAVING <condição de agrupamento>] [ORDER BY <lista de atributos>] [WITH OWNERACCESS OPTION]

Figura 2. Sintaxe do comando de consulta

Fonte: Adaptado de Battisti (2006); Elmasri e Navathe (2006).

Cada um dos elementos apresentados na Figura 2 é descrito em detalhes na Tabela 1.

11

Tabela 1. Composição de um comando de seleção

Elemento Descrição Predicado Um dos seguintes: ALL, DISTINCT, DISTINCTROW ou TOP.

Você usa um predicado para restringir o número de Registros que é retornado pela consulta. Se nenhum for especificado o padrão é ALL

* Especifica que todos os campos de uma determinada tabela ou consulta devem ser selecionados. Por exemplo: Select * from Pedidos - Retorna todos os campos da tabela Pedidos.

Tabela O nome da tabela ou consulta de onde são selecionados os campos. Por exemplo, Select Pedidos.NúmeroDoPedido, Pedidos.DataDoPedido from Pedidos - Seleciona os Campos NúmeroDoPedido e DataDoPedido, da tabela Pedidos.

Campo1, Campo2 O Nome dos campos a serem selecionados. Alias1, Alias2 Um "apelido" para o campo. Na Folha de Dados o apelido

aparece como o título da coluna. Por exemplo, Select Pedidos.NúmeroDoPedido As Número from Pedidos, faz com que a coluna NúmeroDoPedido tenha o nome Número a ela associado.

TabelaExpression O nome da tabela de onde os campos serão selecionados ExternalDatabase O nome do Bando de Dados que contem a tabela, caso não seja o

banco de dados atual. Where Utilizado para especificar critérios na consulta.

Por exemplo, Where Pedidos.PaísDeDestino="Brasil"

Group By O mesmo que Agrupar Por no modo estrutura da consulta, na linha Total

Having Especifica critérios quando utilizamos Agrupar Por. Order By Utilizado para classificação dos registros em ordem crescente ou

descendente de um determinado campo.

Fonte: Adaptado de Battisti (2003)

Em SQL, os operadores lógicos básicos de comparação usados para confrontar os valores

entre os atributos e constantes são: =, <, <=, >, >= e <>. A maioria dos SGBD’s possui uma

condição conhecida como LIKE, onde o usuário consegue definir apenas uma parte da string e

aceitar qualquer caractere nas demais posições da string como pode ser visto nos exemplos da

Figura 3 e Figura 4.

12

Select * From fornecedor Where cd_base_fornecedor = 157456811;

Figura 3. Exemplo de uma consulta SQL

Na consulta apresentada na Figura 3, o usuário deseja buscar todos os fornecedores que

possuam o código de base de fornecedor igual a 157456811.

Select * From cliente Where ds_logradouro like ‘%Brasil%’;

Figura 4. Exemplo de uma consulta SQL com operador LIKE

Na consulta apresentada na Figura 4, o usuário deseja buscar todos os clientes que possuam

a palavra ‘Brasil’ no campo de endereço da tabela, não importando se a palavra é rua, avenida,

estrada, rodovia ou o que mais estiver preenchido.

A PL/SQL (Procedural Language/Structured Query Language) é uma extensão da

linguagem padrão SQL para o SGBD Oracle da Oracle Corporation.

Novelli (2003) comenta que:

PL/SQL permite que a manipulação de dados seja incluídas em unidades de programas. Blocos de PL/SQL são passados e processados por uma PL/SQL Engine que pode estar dentro de uma ferramenta Oracle ou do Server. A PL/SQL Engine filtra os comandos SQL e manda individualmente o comando SQL para o SQL Statement Executor no Oracle Server, que processa o PL/SQL com os dados retornados do Server. É a linguagem básica para criar programas complexos e poderosos, não só no banco de dados, mas também em diversas ferramentas Oracle.

2.1.2 Algoritmos para Operações de Consulta

Segundo Elmasri e Navathe (2006), existem diversas opções para a execução da operação de

consulta (select), onde algumas dependem de o arquivo possuir caminhos específicos de acesso e

apenas podem aplicar certos tipos de condições de seleção. Os métodos de busca para seleção são

classificados em:

• Simples: selecionam registros de um arquivo podendo utilizar técnicas de varreduras de

arquivo (file scan) – percorrem os registros de um arquivo para buscar e recuperar os

13

registros que satisfazem a condição de seleção-; ou índices de varredura – se envolver

um índice; ou

• Complexos: se a consulta envolver diversas condições simples conectadas pelo operador

lógico and.

Abaixo estão alguns tipos de seleção dos métodos de busca (ELMASRI; NAVATHE, 2006):

• Busca linear (força bruta): recupera cada registro do arquivo e testa se seus valores de

atributos satisfazem a condição de seleção;

• Busca binária: se a condição de seleção envolver uma comparação de igualdade em um

atributo-chave para o qual o arquivo está ordenado. Ex: select * from cidade where nome

= ‘Itajaí’;

• Utilização de um índice primário (ou chave de hash): se a condição de seleção envolver

uma comparação de igualdade em um atributo-chave com um índice primário. Vale

ressaltar que esta condição recupera, no máximo, um único registro;

• Utilização de um índice primário para recuperar múltiplos registros: se a condição de

comparação for >, >=, < ou <= em um campo-chave com um índice primário, usa o

índice para encontrar o registro que satisfaça a condição de igualdade correspondente e

depois recupera os registros seguintes do arquivo de forma ordenada.

• Utilização de um índice cluster para recuperar múltiplos registros: se a condição de

seleção envolver uma comparação de igualdade em um atributo que não seja chave com

um índice clustering, usa o índice para recuperar todos os registros que satisfaçam a

condição; e

• Utilização de um índice secundário em uma comparação de igualdade: utilizado para

recuperar um único registro se o campo de indexação for uma chave ou para recuperar

múltiplos registros se o campo de indexação não for chave. Pode ser aplicado para

comparações com operadores: >, >=, < ou <=.

2.1.3 Funções para Tratamento de Strings

No banco de dados, as tabelas possuem campos que podem ser definidos para aceitar apenas

uma data, números, caracteres ou outros tipos de dados específicos. Existem funções criadas nos

bancos de dados para tratamento de cada tipo dos dados citados, funções estas que variam conforme

14

o SGBD utilizado. Na Tabela 2 são apresentadas as principais funções de tratamento de strings

existentes em três dos principais gerenciadores de banco de dados.

Tabela 2. Comparação entre funções dos bancos Oracle, Postgre e SQL Server

Elemento ORACLE SQL SERVER POSTGRE Converter a string caso seja nula

NVL ISNULL NULLIF

Retornar a string que possuir a maior letra inicial

GREATEST Não Encontrado Não Encontrado

Quantidade de caracteres de uma string

LENGHT LEN CHAR_LENGTH

Substituir uma string dentro de outra string

REPLACE STUFF REPLACE

Colocar a primeira letra em maiúsculo de cada palavra de uma string

INITCAP Não Encontrado INITCAP

Consultar parte de uma string

SUBSTR SUBSTRING SUBSTRING

Converter numérico para caractere

TO_CHAR STR TO_CHAR

Completar string com espaços ou caracteres

RPAD, LPAD SPACE RPAD, LPAD

Posição inicial de um caractere em uma string

INSTR PATINDEX POSITION

Retirar espaços em branco à direita de uma string

RTRIM RTRIM RTRIM

Retirar espaços em branco à esquerda de uma string

LTRIM LTRIM LTRIM

Converter todos os caracteres para maiúsculo

UPPER UPPER UPPER

Converter todos os caracteres para minúsculo

LOWER LOWER LOWER

Converter ASCII para caractere

CHR CHAR ASCII

Repetir uma string n vezes Não Encontrado Não Encontrado REPEAT

Na Tabela 2 pode-se verificar que há algumas funções com o mesmo nome, outras parecidas

e há ainda algumas que existem apenas em um SGBD específico, porém os gerenciadores são muito

parecidos neste ponto considerando as informações coletadas como um todo.

15

2.2 ALGORITMOS DE BUSCA

Para o ramo da computação, um algoritmo de busca, em termos gerais, é um algoritmo que

toma um problema como entrada e retorna uma solução, geralmente após resolver um número

possível de soluções.

Segundo Gondim (2006), há basicamente três tipos de comparações quanto aos

alinhamentos das strings, sendo:

• Global, quando as duas strings são alinhadas como um todo;

• Semi-Global, quando ignora os espaços nos extremos das seqüências e;

• Local, quando ignora espaços e diferenças nos extremos das strings.

A Figura 5 apresenta os tipos de alinhamentos de string.

Figura 5. Tipos de alinhamentos de strings

Fonte: Gondim (2006)

2.2.1 Algoritmo da Força Bruta

O algoritmo da força bruta verifica a existência de uma cadeia em um texto de forma

exaustiva. Considerando o padrão P a ser encontrado no texto T e i como a posição de inicio da

comparação na cadeia, são feitas comparações iniciando da primeira posição de T (P[1] = T[1]; P[2]

= T[2]; P[3] = T[3] …) (GOMES Jr., 2003). No momento em que a comparação informar que os

caracteres são diferentes, o algoritmo pára a análise, verifica qual é a posição de início e soma um a

16

este valor, continuando as comparações da posição seguinte do texto (P[1] = T[2]; P[2] = T[3]; P[3]

= T[4] … ). Na Figura 6 é ilustrado um exemplo do algoritmo de força bruta, considerando P como

a string abaeabaeaae e T como a primeira linha da figura.

Figura 6. Exemplo de funcionamento do algoritmo de força bruta

Fonte: Gomes Jr. (2008)

Neste algoritmo as comparações são executadas coluna à coluna. Quando uma das letras não

é igual, a posição inicial de comparação passa a ser a posição à direita seguinte conforme mostrado

na Figura 6. O algoritmo da força bruta repete estas tarefas até percorrer todo o texto, não se

preocupando em armazenar nenhuma informação referente aos caracteres que foram comparados

anteriormente.

2.2.2 Algoritmo de Knuth-Morris-Pratt

Este algoritmo, conhecido também como KMP, foi publicado no ano de 1977 por D. Knuth,

J. Morris e V. Pratt (REGO, 2006). A idéia do algoritmo é identificar um padrão P em uma

seqüência T analisando apenas uma vez cada termo da seqüência. Ele utiliza uma tabela, conhecida

17

como vetor next, temporária auxiliar para armazenar informações que serão usadas nas

comparações.

Rego (2006) comenta que o algoritmo possui implementação mais complicada porém mais

eficiente do que comparado com o da força bruta, e eficiência pior ao comparar com o Boyer-

Moore que será analisado em seguida.

Ao iniciar uma comparação de um novo padrão, informações importantes podem estar sendo

perdidas. Após a comparação de parte da string já se sabe os últimos caracteres da cadeia, sendo

possível em alguns casos, não perder tempo comparando alguns caracteres pois já se sabe que as

letras são diferentes e o algoritmo irá apenas perder tempo ao executar tal comparação.

O objetivo desta melhoria é evitar comparações repetidas, aproveitando ao máximo o padrão

correto após uma diferença ser encontrada. Considerando a Figura 6, as comparações das linhas

quatro, cinco e seis poderiam ter sido puladas. Isto se dá ao fato que na linha três as comparações

foram feitas até a coluna 17 do texto. Utilizando-se de um vetor auxiliar pode se concluir que a

comparação poderia continuar tendo como posição inicial a coluna sete, pois já se tem

conhecimento que as colunas quatro, cinco e seis não possuem caracteres válidos para o padrão.

Utilizando a Figura 7 como base, Gomes Jr. (2008) afirma que:

Dada uma discordância na posição k, uma sub-cadeia (l+h) conseqüente só poderá fornecer casamento se e somente pi = pi + h , 1 <= i <= k – h. A próxima posição a ser examinada após Bl + 1 é Bl + 1 + h. Para determinar o valor de h, calcula-se d(k-1), onde d(k-1) é o comprimento do maior prefixo próprio de pi , … pk – 1 tal que esse prefixo coincida com o sufixo de mesmo tamanho. Com isso, o valor mínimo de h = k – 1 – d(k-1), onde d(1) = 0 e se houver coincidências, d(k-1) = 0.

18

Figura 7. Exemplo da fórmula para calculo da próxima posição a ser utilizada na comparação do algoritmo KMP


Na Figura 8 é exemplificado o cálculo dos valores do vetor next (D(k)) necessário para saber

quantas posições deve ser deslocada a string ao efetuar um novo alinhamento. Para o cálculo, copia-

se a string que se deseja localizar e alinha-se está cópia com a ela mesma. Por padrão, a primeira

posição (d(1)) é sempre zero e para as demais o valor de D(k) é sempre igual ao acumulado de

número de letras que são iguais. No caso de k = 2, está se comparando “a” com “b” e por serem

diferentes a variável acumulada continua sendo zero. Para k = 3, está se comparando “a” com “a” e

por serem iguais verifica-se as próximas letras (“b” e “e”). Por elas serem diferentes, a variável

acumulada recebe o valor dela mesma mais um (quantidade de letras iguais), ou seja, D(3) = 1. Para

k = 4, está se comparando “a” e “e”, que por serem diferentes atribui-se zero para a variável

acumulada. Para k = 5, está se comparando “a” com “a”, que por serem iguais incrementa-se o valor

da variável acumulada (0 + 1), sendo desta forma D(5) = 1. Para k = 6, está se comparando “b” com

“b”, que por serem iguais incrementa-se o valor da variável acumulada (1 + 1), sendo desta forma

D(6) = 2. Para k = 7, está se comparando “a” com “a”, que por serem iguais incrementa-se o valor

da variável acumulada (2 + 1), sendo desta forma D(7) = 3. O cálculo de D(k) para os demais

valores de k continua seguindo a mesma idéia até que ocorra uma diferença na comparação. Quando

isto ocorrer a variável acumulada recebe o valor zero e a verificação continua com a mesma regra

até toda string ser percorrida.

19

Figura 8. Valores de d(k) para o exemplo da Figura 6


A Figura 9 apresenta o algoritmo para determinar o valor de D(k) (vetor next utilizado para o

cálculo do deslocamento).

j = d[1] = 0 k = 1 enquanto k < m faça se P[k + 1] = P[j + 1] então k = k + 1 j = j + 1 d[k] = j senão se j = 0 então k = k + 1 d[k] = 0 senão j = d[j]

Figura 9. Algoritmo para determinação do D(k)

Fonte: Adaptado de Gomes Jr. (2008)

A Figura 10 mostra como seria o processo de comparação do algoritmo de KMP com base

no mesmo exemplo da Figura 6 onde foi utilizado o algoritmo da força bruta.

20

Figura 10. Resolução do mesmo exemplo mostrado na Figura 6, mas com a utilização do algoritmo de KMP

Fonte: Adaptado de Gomes Jr. (2008)

Como pode ser analisado na comparação da Figura 6 com a Figura 10, verifica-se que o

algoritmo da força bruta executa 58 comparações enquanto o KMP executa apenas 30.

2.2.3 Algoritmo de Boyer-Moore

A idéia deste algoritmo é realizar uma busca da direita para a esquerda no padrão a ser

buscado. O algoritmo posiciona o padrão sobre o caractere mais à esquerda no texto, e faz uma

busca da direita para a esquerda. Se não ocorrer nenhuma diferença, então o padrão foi encontrado.

O algoritmo de Boyer-Moore possui duas heurísticas para calcular esta mudança, utilizadas

simultaneamente. Essas heurísticas freqüentemente permitem que muitos caracteres sejam pulados

evitando diversas comparações. Elas são conhecidas como a heurística do bom sufixo e a heurística

do mau caractere.

Segundo Moura, Dantas Filho e Porto (2002), este algoritmo desenvolvido por Robert Boyer

e Strother Moore é utilizado na grande maioria dos editores de textos existentes atualmente para

executar as tarefas de busca e substituição de texto.

Na Figura 11 o padrão a ser encontrado é representado pela segunda linha (string

“reminiscence”). Ao executar a comparação com o texto “writen_notice_that”, após executado o

alinhamento, percebe-se que as duas letras “ce” são iguais, porém ao analisar a terceira letra nota-se

uma diferença. Desta forma os caracteres “ce” formam o bom sufixo enquanto que o “i”, terceira

letra da analise, é o mau caractere.

21

Figura 11. Explicação da heurística do bom sufixo e do mau caractere

Fonte: Moura, Dantas Filho e Porto (2002)

Segundo Moura, Dantas Filho e Porto (2002), as heurísticas trabalham paralela e

independentemente. Quando ocorre uma diferença, cada uma das duas indica uma posição para o

deslocamento da próxima comparação, sendo escolhida sempre a que tiver maior valor.

A heurística do mau caractere verifica onde o caractere errado é encontrado no padrão

proposto para informar a nova possível posição de comparação. Moura, Dantas Filho e Porto (2002)

afirmam que o melhor caso ocorre quando o erro se encontra na primeira posição e este caractere

não existe no padrão, propondo o deslocamento igual a m (tamanho do padrão).

Na Figura 12 pode-se analisar o que a heurística do mau caractere faria no exemplo anterior.

Como a letra “i” foi a marcada com sendo o mau caractere, é procurado na string o caractere “i”

para fazer o novo alinhamento para seguir a analise da similaridade, alinhamento este que teve custo

de 4 posições.

Figura 12. Exemplo da utilização da heurística do mau caractere baseado na Figura 11


22

A heurística do bom sufixo procura na string, da direita para esquerda, se existe dentro dela

o sufixo correto, sendo neste caso a string “ce”. Na Figura 13 é mostrado o novo alinhamento

proposto, que teve custo de 3 posições, utilizando a regra do bom sufixo.

Figura 13. Exemplo da utilização da heurística do bom sufixo baseado na Figura 11


Depois de calculado as duas possíveis respostas, o algoritmo de Boyer-Moore acabaria

escolhendo a proposta pela heurística do bom sufixo, pois é a que retornou o menor custo de

deslocamento para realizar o próximo alinhamento.

A Figura 25 ilustra um applet que utiliza a função Boyer-Moore onde a string padrão “a

costa” é comparada com o texto “rodrigo a costa”. Na parte inferior encontra-se a tabela auxiliar

que mostra a posição de cada letra dentro da string padrão.

23

Figura 14. Exemplo de applet comparando as palavras “a costa” e “rodrigo a costa”

Fonte: Bühler (2004).

O resultado do exemplo da Figura 14 é encontrado na Figura 15, mostrando a quantidade de

comparações, a média de comparações por quantidade de caracteres, tamanho do texto e do padrão

e a posição em que o padrão foi encontrado dentro do texto.

24

Figura 15. Resultado da pesquisa do algoritmo Boyer-Moore.

Fonte: Bühler (2004).

2.2.4 Algoritmo de Rabin-Karp

Este algoritmo, criado por Michael Rabin e Richard Karp é baseado em uma teoria de

números, utilizando uma função hash para localizar strings em textos. Segundo Spido (2007), uma

função hash é utilizada para converter strings em valores numéricos. A idéia principal está no fato

de que caso duas cadeias de letras são iguais, os seus valores hash também devem ser iguais. Desta

forma, deve-se calcular o valor hash do padrão a ser procurado e, após isto, iniciar a comparação

com o valor hash do texto de referência.

Spido (2007) explica que existe uma desvantagem neste procedimento. Ocorre que devido

ao grande número de strings e para manter o tamanho dos valores hash pequenos, algumas strings

acabam recebendo valores iguais. Desta forma, mesmo que os valores hash sejam iguais, as strings

podem ser diferentes.

No exemplo da Figura 16 deseja-se encontrar a string “cab” na palavra “aabbcaba”. No

primeiro passo, armazenam-se os três primeiros caracteres em uma tabela hash que serão

comparados com a string que se deseja encontrar. Após isso se verifica quantos caracteres são

diferentes ao comparar com a string desejada, ainda não importando a seqüência que se encontra.

25

No primeiro passo calcula-se o valor hash da string “cab” (igual a 0) com o valor hash das

três primeiras letras, “aab” (igual a 1). Como os valores são diferentes, a comparação vai para o

passo seguinte onde é trocada a letra mais à esquerda pela letra seguinte da direita. Neste segundo

passo, o padrão “cab” é comparado com a string “abb”, que possui valor hash igual a 2. Como os

valores são diferentes, faz-se um deslocamento para gerar o novo alinhamento. No passo 3 o padrão

“cab” é comparado com a string “bbc” que possui valor hash igual a 1. Como os valores são

diferentes faz-se um deslocamento para gerar o novo alinhamento. No passo 4, o padrão “cab” é

comparado com a string “bca” que possui valor hash igual a 0. Neste caso, é iniciada uma

comparação da ordem de cada caractere pois os dois valores hash são iguais. A função ainda retorna

falso pois a seqüência das letras não é igual. No passo cinco, tanto os valores hash quanto a ordem

das letras são iguais e por isto a função termina sua execução retornando a posição como resposta.

26

Figura 16. Exemplo do algoritmo de Rabin Karp.

Fonte: Sparknotes (2008).

Spido (2007) conclui que, mesmo que este algoritmo possua o pior desempenho para O(mn)

e tenha desempenho inferior para pesquisa de padrões simples, o método possui a vantagem na

busca de padrões compostos, tendo assim uma grande aplicação como validação de rotinas para

analise de plágio.

27

2.2.5 Algoritmo de Levenshtein

Também conhecido como Edit Distance, foi um dos primeiros algoritmos de comparação

criados e é um dos mais utilizados nos dias de hoje. Permite inserções, exclusões e substituições de

caracteres para igualar duas strings.

Segundo Gondim (2006), são atribuídos diferentes valores para as operações: match

(igualdade dos caracteres); mismatch (substituições); inserções e exclusões para ser comparada a

pontuação de todas as possibilidades.

Na Figura 17 é mostrada a definição desta função onde, X e Y são as duas strings a serem

comparadas, M é uma matriz de Levenshtein, I e J são as posições dos caracteres das respectivas

strings, e a função p(i,j) é utilizada para determinar o grau de igualdade das strings.

Figura 17. Definição da função de Levenshtein


Considerando a regra da Figura 17, para a criação da tabela deve-se preencher as células

partindo da primeira linha/coluna, onde M(0,0) recebe valor 0 e as células à direita e abaixo

recebem o valor da célula anterior decrementando em 1. Para o preenchimento dos demais campos

da tabela deve-se seguir a regra:

• M(i – 1, j) – 1 : valor da célula da linha acima e da mesma coluna;

• M(i – 1, j – 1) + p(i,j) : valor da célula da linha acima e uma coluna à esquerda, onde

p(i,j) será igual a 2 caso os caracteres em questão sejam iguais ou -1 caso sejam

diferentes; e

• M(i , j – 1) – 1 : valor da célula da mesma linha e coluna à esquerda.

28

Figura 18. Exemplo de applet comparando as palavras “andreata” e “andreatta”

Fonte: Charras (1998).

Na Figura 18 está um exemplo de um applet que mostra a tabela auxiliar do algoritmo

levenshtein distance (preenchida conforme regra citada acima) para a comparação das palavras

“andreata” e “andreatta”. Na parte inferior estão os dois alinhamentos possíveis para o exemplo em

questão e a última célula da última linha mostra a quantidade de diferenças entre as duas palavras

(valor igual a um).

2.2.6 Algoritmo de Smith Waterman

Este algoritmo é similar ao de Levenshtein, tendo como diferencial a melhoria no

alinhamento de substrings ao invés de alinhar toda a string.

Gondim (2006) explica que qualquer pontuação negativa é trocada por zero e a pontuação

do alinhamento é o que possuir melhor pontuação entre todos, permitindo que as extremidades não

estejam alinhadas. A Figura 19 ilustra a definição da função de Smith Waterman.

29

Figura 19. Definição da função de Smith Waterman


O que diferencia o Levenshtein do Smith Waterman está no fato de que no segundo, caso o

valor seja negativo, ele será substituído por zero. Na Figura 20 foi executada a comparação das

strings “biomedicina” e “medico”, tendo 10 como a maior pontuação obtida na matriz.

Figura 20. Exemplo de comparação usando a função Smith Waterman


2.2.7 Algoritmo de Stochastic Model

Este algoritmo, da mesma forma que o de Levenshtein e o de Smith Waterman, é baseado na

execução de inserções, exclusões e alterações para a construção de uma matriz de pontuações. O

seu diferencial está no fato de que o algoritmo possui um mecanismo que dá valores às pontuações

dinamicamente, se adaptando conforme o conjunto de informações que o algoritmo recebe.

Gondim (2006) explica que o algoritmo de Stochastic Model possui um desempenho muito

parecido com o de Levenshtein, porém sua grande vantagem está na sua taxa de erro que é

aproximadamente 75% menor. O autor cita também que o algoritmo pode ser utilizado para

30

comparar qualquer tipo de string, mas foi testado apenas para o aprendizado de palavras em

conversações.

Uma desvantagem deste algoritmo está no fato de que é realizado um alinhamento global

das strings, possibilitando um baixo desempenho na atribuição de pontuações para palavras que

possuam sufixos semelhantes, como por exemplo as strings “telecomunicação” e “comunicação”.

Entretanto, Gondim (2006) explica que devido ao dinamismo do algoritmo, ele pode ser adaptado

para tratar este tipo de caso específico.

2.2.8 Algoritmo de Jaro Metric

Este algoritmo é parecido ao Levenshtein, pois também utiliza uma matriz, porém não

precisa ser implementada já que não é preciso guardar todos os dados na matriz.A idéia do

algoritmo está na quantidade de caracteres iguais na comparação de duas strings e na semelhança

quanto ao posicionamento na apresentação dos caracteres nas strings. Gondim (2006) explica o

algoritmo da seguinte forma:

Seja s = a1 ... ak e t = b1 ... bL, um caractere ai será considerado "em comum" com t se existir um caractere bj = ai, e o valor de i não pode diferir do valor de j mais do que H, onde H = mínimo( |s| |t| )/2, onde |s| e |t| são os tamanhos das strings s e t respectivamente. Seja s' = a'1 ... a'k os caracteres em s que são comuns com os de t (na mesma ordem que aparecem em s), e seja t' = b'1 ... b'L, análogo a s'.

A Figura 21 ilustra o algoritmo de Jaro.

Figura 21. Métrica do algoritmo de Jaro.


Na Figura 22 exemplifica-se a métrica de Jaro comparando-se as strings s = “Martha” e t =

“Marhta”. Para estas duas strings, o grau de similaridade obtido é igual a 0,944. Considere que uma

transposição ocorre quando duas palavras possuem as mesmas letras, porém há alguma diferença

nas posições. Isto ocorre neste exemplo onde as letras t e h estão trocadas entre si.

31

|s| = 6 (tamanho de s); |t| = 6 (tamanho de t); |s’ | e |t’ | = 6 (quantidade de letras iguais); Ts’,t’ = (quantidade de transposições dividido por 2) = 2 / 2 = 1. Jaro(Martha,Marhta) = 1/3 ( 6/6 + 6/6 + (6-1) / 6) Jaro(Martha,Marhta) = 0,944

Figura 22. Exemplo da métrica de Jaro

2.2.9 Algoritmo de Hamming Distance

Este algoritmo possibilita apenas substituições com custo igual a 1. Segundo Navarro (2001)

apud Gondim (2006), este problema é conhecido como “string matching with k mismatches”. Outra

definição da função por Chapman (2005 apud GONDIM, 2006) é “Número de bits que diferem

entre duas strings binárias, ou número de bits que precisam ser modificados para transformar uma

string idêntica à outra”. No exemplo da Figura 23 o valor da hamming distance entre as duas strings

que estão sendo comparadas é igual a 4, pois há 4 bits diferentes entre elas.

1 0 0 1 1 0 1 0 1 0 0 0 1 1 0 1

Figura 23. Exemplo de cadeia de bits


Ao comentar sobre este algoritmo, Gondim (2006) conclui que o mesmo é bastante eficiente

porém não seria capaz de comparar strings como “datanascimento” e “data-nascimento”, devido ao

fato de não permitir inserções ou exclusões.

2.2.10 Algoritmo de Soundex Distance Metric

A idéia deste algoritmo está em transformar cada string em um código formado por uma

letra e três números, conhecido como Soundex Code. O primeiro caractere deste código será sempre

o primeiro caractere da string e as demais letras devem ser substituídas por valores conforme as

regras apresentadas na Tabela 3.

32

Tabela 3. Regras do Soundex Code

Termo Valor A, E, I, O, U, H, W, Y 0 B, P, F,V 1 C, S, K, G, J, Q, X, Z 2 D, T 3 L 4 M, N 5 R 6

Fonte: Adaptado de Gondim (2006)

Na Tabela 4 está um exemplo de aplicação da regra utilizando as palavras “Dickson” e

“Dixon”. O primeiro passo é separar cada letra e atribuir seu respectivo valor conforme apresentado

na Tabela 3. Na coluna “Valor 1” da Tabela 4 encontram-se os valores de cada letra da palavra

“Dickson”, que juntos formam o código: D022205. O primeiro caractere do código sempre é igual a

primeira letra da string, sendo neste caso a letra “D”. No segundo passo, todos os números “0”

(zero) devem ser removidos, formando o código D2225. E por fim, para os números que aparecem

repetidos em seqüência deve-se deixar a penas um, formando o código D25. A palavra “Dixon”

possui o código D0205 (valores da coluna “Valor 2” da Tabela 4), que após a execução do passo

dois forma-se o código D25, mesmo soundex code da palavra “Dickson”. Gondim (2006) explica

que o algoritmo é bom apenas para verificar questões de fonética, pois foi desenvolvido para a

língua inglesa.

Tabela 4. Exemplo da regra do algoritmo Soundex Code com a string “Dickson” e “Dixon”.

Palavra 1 Valor 1 Palavra 2 Valor 2 D D D D I 0 I 0 C 2 X 2 K 2 O 0 S 2 N 5 O 0 N 5


33

2.2.11 Algoritmo de Convington’s Distance Function

Este algoritmo possui uma idéia parecida ao Soundex Distance, onde são realizadas

comparações que consideram se o caractere é uma vogal ou consoante. A função é simples, pois é

baseada na “tentativa / erro”. Ela considera três tipos de dados: consoantes, vogais e espaços em

branco. A Tabela 5 apresenta os valores das penalidades da função Convigton’s Distance.

Tabela 5. Valores das penalidades da função de Convigton’s Distance

Termo Penalidade Consoantes idênticas ou espaços 0 Vogais idênticas 5 Vogais diferentes 30 Consoantes diferentes 60 Termos Diferentes 100


Na Figura 24 é demonstrado o funcionamento da função de Convigton comparando-se as

strings “paciente” e “patient”. Após efetuar o alinhamento das duas palavras aplicam-se as

penalidades conforme regra da Tabela 5. O valor da soma das penalidades da comparação destas

duas palavras é igual a 125. Considerando que o número de letras da maior string é igual a 8,

conclui-se que no pior caso o valor da penalidade seria igual a 800 (oito termos diferentes). Desta

forma o grau de semelhança é igual a 125 / 800, que é igual a 0,844.

Figura 24. Atribuição de valores do algoritmo de Convington’s Distance


2.2.12 Considerações sobre os Algoritmos de Similaridade Analisados

Após as explicações realizadas sobre os algoritmos citados acima, pode-se concluir que o

com menor desempenho entre todos é o da força bruta, pois faz verificações de forma exaustiva,

sem utilizar comparações previas para melhorar o desempenho.

34

O algoritmo KMP é mais eficiente quanto utilizado para comparar cadeias de caracteres

repetidos como, por exemplo, uma cadeia de DNA. Isto ocorre pelo motivo de que o algoritmo usa

um vetor auxiliar (next) para armazenar as posições dos novos alinhamentos.

Quanto ao algoritmo de Rabin-Karp, ele tenta diminuir a quantidade de comparações

utilizando valores hash da string procurada e da substring do texto. Isto faz com que ele se torne

probabilístico. Sua melhor aplicação está em buscas de palavras maiores em textos grandes.

O algoritmo Stochastic Model tem sua eficiência comprovada para aprender os custos de

edição de um corpo de exemplos. Ele é capaz de adaptar a forma como que aplica as penalidades,

de acordo com informações que este algoritmo recebe.

Do algoritmo Levenshtein conclui-se que não é muito eficiente, mas é um dos mais

flexíveis, pelo fato de poder ser adaptado para diferentes funções de distância.

O algoritmo Hamming Distance é eficiente, mas permite apenas substituições, não sendo

possível realizar inserções ou remoções. Isto dificulta as comparações de, por exemplo,

“data_nascimento” com “data-de-nascimento”.

Do algoritmo Soundex conclui-se que possui um bom desempenho, mas ele apenas pode ser

aplicado para verificar erros de fonética, pois provavelmente apresentará grandes erros ao ser usado

para outra aplicação. E, além disso, terá muitos problemas para analisar strings que não forem da

língua inglesa.

O algoritmo Convington’s Distance possui desempenho muito ruim, pelo fato de utilizar

técnicas de construir uma árvore para efetuar as comparações. O tempo gasto é muito grande,

devido ao número de possíveis alinhamentos testados. Sua única vantagem está no cálculo do grau

de similaridade quando ocorrem erros fonéticos no texto.

Quanto ao Boyer-Moore, realiza as comparações da direita para a esquerda, baseada em

duas heurísticas e com complexidade igual a O(m . n).

2.3 APLICAÇÕES COM ALGORITMOS DE SIMILARIDADE

Esta seção apresenta alguns estudos de caso que utilizam algoritmos para comparação

baseado em similaridade para recuperação de informação. Através deste tópico é possível ter uma

idéia da fartura ou carência de programas com a funcionalidade proposta neste trabalho.

35

2.3.1 Similarity Retrivel Engine

O Similarity Retrivel Engine (SIREN) foi desenvolvido para validar a adequação de uma

proposta de extensão da linguagem SQL padrão que permite a execução de consultas por

similaridade (BARIONI et al., 2005).

Basicamente o que ocorre é uma comunicação entre um SGBD e os programas de aplicação,

interceptando todo comando SQL enviado por uma aplicação. Caso a aplicação tenha submetido

apenas comandos em SQL padrão o mecanismo executa as instruções de maneira transparente e,

caso o comando possua alguma condição que envolva similaridade ou alguma referência a um

objeto complexo definido pela extensão da linguagem, o comando é alterado e as operações de

similaridade são executadas por este mecanismo, com auxílio do SGBD para executar as operações

sobre os dados tradicionais.

Para executar consultas por similaridade sobre objetos em um domínio complexo é preciso

definir como a similaridade será mensurada e um novo tipo de dados complexo. De uma maneira

geral foram considerados dois tipos de objetos complexos:

• objetos armazenados como um conjunto de atributos; e

• objetos armazenados como um único objeto binário

Estes objetos são contemplados respectivamente pelos domínios PARTICULATE e

MONOLITHIC. Para ser possível executar as medidas de similaridades foi necessário criar os

comandos CREATE METRIC, ALTER METRIC e DROP METRIC que seguiram o estilo dos

comandos da Data Definition Language (DDL).

O projeto SIREN foi desenvolvido em C++ para ambiente Windows e utiliza o protocolo

ODBC para conexão com o SGBD Oracle 9i. Foi implementada uma aplicação web (CGI) em C++

que fornece um ambiente para a submissão de comandos em SQL.

Barioni et al. (2005) citam dois exemplos. Para isto dois novos tipos de dados definidos,

foram utilizados dois conjuntos de dados. O primeiro conjunto, denominado Exame, é formado por

800 imagens de exames de tomografia computadorizada divididas em quatro classes: crânio axial,

crânio coronal, crânio sagital e espinha sagital.

36

Cada tupla é constituída por um identificador da imagem, a imagem, e um atributo que

especifica a classe da imagem. Essas imagens podem ser consultadas de várias maneiras. Elas

podem ser comparadas, por exemplo, pela similaridade da distribuição de suas cores ou de suas

texturas. Para tanto devem ser definidas duas métricas, uma utilizando o extrator HISTOGRAMEXT

e outra o extrator TEXTUREEXT (BARIONI et al., 2005). A Figura 25 apresenta um exemplo de

execução de consultas tendo por base a similaridade.

Figura 25. Exemplo de execução de consultas por similaridade sobre a tabela Exame, k-NN query usando a métrica textura

Fonte: Barioni et al. (2005)

O segundo conjunto de dados usado no exemplo feito por Barioni et al. (2005), denominado

automóveis, é formado pelos testes realizados pela revista Quatro Rodas, entre maio de 2001 e

junho de 2005, com 140 carros de vários fabricantes. Cada conjunto possui o nome do modelo e do

fabricante do carro testado além dos resultados dos seguintes itens avaliados: número de cilindros,

potência em cavalos, aceleração de 0 a 100 km/h em segundos, retomada de 40 a 80 km/h em

segundos, velocidade máxima em km/h, frenagem de 80 a 0 km/h em metros, ruído interno em dB,

volume do porta malas em litros e consumo urbano em km/l. Consultas por similaridade podem ser

37

empregadas para explorar esse conjunto de dados em diversas questões, por exemplo, a relação

custo/benefício considerando itens como potência, volume do porta malas e consumo urbano. A

Figura 26 ilustra tal exemplo onde o usuário deseja encontrar quais são os cinco carros que

apresentam as características mais próximas de 70 cavalos de potência, 250 litros de volume de

porta malas e 13 km/l de consumo urbano.

Figura 26. Exemplo da execução de consultas por similaridade sobre a tabela automóveis.

Fonte: Barioni et al. (2005)

2.3.2 XSimilarity

O XSimilarity é uma ferramenta para consultas por similaridade embutidas na linguagem

XQuery. Segundo Silva, Borges e Galante (2008), a XQuery foi criada devido a necessidade de

realizar consultas em documentos XML. A XML foi inventada em 1996 e possui como principal

característica a flexibilidade, permitindo a definição de tags e marcações pelo próprio usuário.

Silva, Borges e Galante (2008) ainda citam que o XQuery está para o XML assim como o

SQL está para os bancos de dados relacionais, pois mesmo que as sintaxes sejam diferentes, a

semântica é a mesma. Os autores explicam que a sintaxe XQuery possibilita a realização de

consultas mais complexas e de leitura mais fácil ao se comparar com a sintaxe do SQL.

Foram implementadas várias funções de similaridade que foram embutidas na linguagem

XQuery, podendo ser comparadas através de uma funcionalidade existente no sistema. O aplicativo

38

é capaz de realizar consultas em ambientes integrados na Web, como por exemplo o CiteSeer e

bibliotecas digitais.

O XSimilarity foi desenvolvido em Java, utilizando a biblioteca NUX como mecanismo de

execução XQuery e a biblioteca SimMetrics para fornecer as funções de similaridade. Para a

criação da interface foi utilizado o pacote Java Swing. Na Figura 27 pode ser verificado as

principais funcionalidades disponíveis pela ferramenta ao usuário.

Figura 27. Casos de uso apresentando as principais funcionalidades do sistema

Fonte: Silva, Borges e Galante (2008)

Na Figura 28 é ilustrada a interface do XSimilarity. Nela há botões com funções de “novo”,

“abrir” e “salvar”. Os arquivos utilizados possuem extensão “xq” para serem diferenciados dos

demais, tendo seu conteúdo armazenado em formato texto. Silva, Borges e Galante (2008) explicam

que o botão com um desenho de “S” é o responsável por inserir as funções de similaridade na

consulta, enquanto que o botão com uma figura de um funil é o que permite a execução da consulta

XQuery.

39

Figura 28. Interface do Xsimilarity


O conjunto de funções de similaridade implementado nesta ferramenta envolve métricas

baseadas tanto em caracteres, palavras (tokens) ou híbridas. Ainda possuem diferentes custos

computacionais e aplicabilidade variada. Estas diferentes características fornecem maior

flexibilidade para experimentos dos mais diversos tipos, o que justifica a escolha destas funções

para a implementação da ferramenta. A ferramenta foi planejada de modo que possa ser facilmente

estendida para a inclusão de novas funções de similaridade (SILVA; BORGES & GALANTE,

2008). Na Figura 29 é apresentado um exemplo do conteúdo de um arquivo utilizado para validar o

software.

40

<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE dblp SYSTEM "dblp.dtd"> <dblp> <incollection mdate="2002-01-03" key="books/acm/kim95/AnnevelinkACFHK95"> <author>Jurgen Annevelink</author> <author>Rafiul Ahad</author> <author>Amelia Carlson</author> <title>Object SQL - A Language for the Design and Implementation of Object Databases.</title>

<pages>42-68</pages> <year>1995</year> <booktitle>Modern Database Systems</booktitle> <url>db/books/collections/kim95.html#AnnevelinkACFHK95</url> </incollection> <incollection mdate="2002-01-03" key="books/acm/kim95/Blakeley95"> <author>José A. Blakeley</author> <title>OQL[C++]: Extending C++ with an Object Query Capability.</title> <pages>69-88</pages> <booktitle>Modern Database Systems</booktitle> <url>db/books/collections/kim95.html#Blakeley95</url> <year>1995</year> </incollection> ... </dblp>

Figura 29. Exemplo arquivo XML


A Figura 30 ilustra um exemplo onde o usuário deseja pesquisar por algo semelhante a

string “Leonidas Kavvbos” no arquivo “dblp2.xml”, tendo seu resultado apresentado na parte

inferior da interface. Como pode ser analisado, o nome correto do autor é “Leonidas Koveos” e só

foi possível encontrar o registro com a utilização da função de similaridade.

41

Figura 30. Exemplo de uma consulta do XSimilarity


Sobre o processo de consulta, Silva, Borges e Galante (2008) concluem que o resultado de

uma consulta por similaridade depende da função utilizada, do limiar adotado e da base de dados a

ser consultada. É possível recuperar resultados indesejados se a função utilizada não for adequada à

consulta, ou se o limiar de similaridade não estiver corretamente ajustado.

2.3.3 Sistema de Reconhecimento de Imagens Similares

O Sistema de Reconhecimento de Imagens Similares (SRIS) é um sistema para consultas em

bancos de dados de imagens. Segundo Rosa et al. (2002), o programa tem o objetivo de possibilitar

a recuperação de imagens semelhantes armazenadas no banco de dados do Hospital das Clínicas da

Faculdade de Medicina de Ribeirão Preto (HCFMRP).

Rosa et al. (2002) conta que a aplicação foi adaptada a partir de um sistema Picture

Archiving and Communication System (PACS), tendo como motivo principal a deficiência dos

PACS, em realizar consultas baseadas nos conteúdos das imagens. Os autores explicam que estes

tipos de sistema permitem capturar, armazenar, distribuir e exibir imagens médicas.

Segundo Rosa et al. (2002), o Centro de Ciências das Imagens e Física Médica (CCIFM) da

Faculdade de Medicina de Ribeirão Preto desenvolveu uma ferramenta de laudo eletrônico utilizado

pelo Serviço de Radiodiagnóstico do HCFMRP, que contém todas as informações dos pacientes

(dados do paciente, data do exame, região do corpo, descrições, observações) existentes em forma

42

de texto. Rosa, Traina e Traina Jr. (2002) cita que o SRIS foi desenvolvido como proposta para de

extensão deste produto de laudo eletrônico, permitindo desta forma armazenar as imagens destes

exames e possibilitar a comparação delas por similaridade.

O SRIS foi desenvolvido através do Cbuilder 5 com banco de dados Oracle 8i. Suas

comparações são baseadas principalmente em características de cor, brilho, formas e texturas

existentes nas fotos gravadas. Essas características podem ser extraídas das fontes no momento em

que as imagens são gravadas ou podem ser apenas salvas, deixando este processo para ser realizado

futuramente.

Sobre o processo de verificação das características das imagens, Rosa et al. (2002) comenta

que:

Duas técnicas de extração de características de imagens foram adotadas no SRIS: o histograma tradicional e o histograma métrico, uma nova e eficiente técnica para capturar características de brilho das imagens, permitindo um acesso rápido e eficiente às imagens, e demandando menos espaço de armazenamento.

Figura 31. Visualização das imagens médicas do SRIS

Fonte: Rosa et al. (2002)

Na Figura 32 pode ser verificada a tela de realizações de consultas por similaridade, onde os

resultados são mostrados na forma de miniaturas possibilitando a ampliação de qualquer imagem

conforme desejo do usuário.

43

Figura 32. Tela de resultados de consultas por similaridade do SRIS

Fonte: Rosa et al. (2002)

2.3.4 Considerações sobre os aplicativos similares

O SIREN é uma ferramenta interessante, pois se nota que ela é capaz de analisar um banco

de imagens e exibir semelhanças conforme imagem passada como referência pelo usuário. Além

disso, o programa verifica uma característica similar em base de dados em formato de texto. Isto

pode ser visto no exemplo dos carros, cuja função é semelhante com a proposta no presente TCC.

O XSimilarity também realiza consultas em textos e possui um diferencial ao analisar bases

de arquivos do tipo XML, e permite ao usuário escolher qual a função que será utilizada pra efetuar

a busca.

O SRIS possui funcionalidade parcial ao comparada com o SIREN. Utilizado para análise de

imagens, baseia-se nas tonalidades das cores e brilhos das fotos armazenadas.

Foi construída a Tabela 6 para fins de comparação dos aplicativos similares, onde foram

consideradas as características tipo de dados aceito pelo programa, se o algoritmo de comparação

utilizado pelo programa é sempre o mesmo ou pode ser selecionado, se permite alteração do código

de busca por parte do programador e a linguagem utilizada pela aplicação.

44

Tabela 6. Tabela comparativa entre aplicativos similares

Aplicativo Tipo Dado Algoritmo Flexível Linguagem SIREN Imagem e texto Fixo Sim PHP XSIMILARITY XML Opcional Sim Java SRIS Imagem Fixo Não C++

Através da Tabela 6 pode-se verificar que cada um dos programas foi desenvolvido em uma

linguagem diferente, apenas o XSimilarity permite ao usuário escolher qual o algoritmo será

utilizado na operação e apenas o SRIS não permite ao usuário agir como programador para alterar a

forma de busca do aplicativo. Quanto ao tipo de dado permitido, o SRIS trata apenas imagens, o

XSimilarity apenas arquivos XML enquanto que o SIREN faz análise de imagem e texto.

2.4 Sistema de Avaliação da Pesquisa Institucional

O Sistema de Avaliação da Pesquisa Institucional (SAPI) é um sistema que avalia as

produções dos docentes da UNIVALI. Os resultados obtidos a partir das avaliações culminam na

forma de distribuição de bolsas de pesquisa, horas de pesquisa aos docentes, avaliação dos cursos,

etc. O acesso ao sistema deve ser possível para os docentes (que remetem seus currículos),

funcionários da Pró-Reitoria de Ensino - PROPPEC (que gerenciam as informações, principalmente

controlando a validação das produções) e demais funcionários da instituição que necessitam de

relatórios gerenciais conforme sua atuação (pró-reitores, diretores de centro, coordenadores de

curso).

Desta forma, as funcionalidades do SAPI são apresentadas conforme o perfil do usuário:

1. Funcionário da PROPPEC:

a) Envio de Currículos: o funcionário poderá realizar a submissão de currículos Lattes

(XML) em nome de algum docente. A identificação do currículo será realizada pelo

CPF encontrado no arquivo submetido.

b) Buscas: o funcionário poderá localizar produções ou currículos utilizando palavras-

chave, nome do docente ou código do docente.

c) Aguardando Verificação: exibir as produções por docente que aguardam verificação

por parte dos funcionários da PROPPEC. A verificação consiste em checar se as

45

produções já não foram validadas previamente (pelo sistema antigo) ou se os

docentes deverão validá-las.

d) Relatórios: o funcionário poderá confeccionar relatórios customizados a partir de

parâmetros selecionados, tais como: especificar cursos, centros, grupos de pesquisa,

docentes, etc. Além disso, pode visualizar todos os relatórios confeccionados.

e) Cadastros: é possível gerenciar as informações sobre áreas, grupos, cenários de

pontuação, perfis de usuário – PROPPEC e Pró-reitores -, currículos.

2. Pró-Reitor:

a) Envio de currículos (caso o pró-reitor também atuar como docente na instituição).

b) Minhas produções (caso o pró-reitor também atuar como docente na instituição).

c) Relatórios: de forma semelhante ao funcionário da PROPPEC, o pró-reitor poderá

confeccionar relatórios com informações referentes a toda instituição. Além disso,

pode visualizar todos os relatórios confeccionados.

3. Diretor de Centro:

a) Envio de currículos (caso o diretor também atuar como docente na instituição).

b) Minhas produções (caso o diretor também atuar como docente na instituição).

c) Relatórios: de forma semelhante aos perfis anteriores, o diretor poderá confeccionar

relatórios, porém com informações apenas referentes ao centro em que atua. Além

disso, pode visualizar os relatórios a ele disponibilizados.

4. Coordenador de Curso:

a) Envio de currículos (caso o coordenador também atuar como docente na instituição).

b) Minhas produções (caso o coordenador também atuar como docente na instituição).

c) Relatórios: de forma semelhante aos perfis anteriores, o coordenador poderá

confeccionar relatórios, porém com informações apenas referentes ao curso em que

atua. Além disso, pode visualizar os relatórios a ele disponibilizados.

5. Docente:

a) Envio de currículos (caso o coordenador também atuar como docente na instituição).

b) Minhas produções (caso o coordenador também atuar como docente na instituição).

46

c) Relatórios: pode visualizar os relatórios a ele disponibilizados.

Na Figura 33 pode ser verificada a tela de menu de opções do SAPI, onde o usuário pode

solicitar uma atualização, verificar suas produções e gerar relatórios, entre outros.

Figura 33. Tela do SAPI

A Figura 34 exibe as produções cadastradas para o usuário Júlia Marques Carvalho da Silva,

cada uma com uma situação (produção validada, falta entregar produção na PROPPEC, produção

válida para a UNIVALI, entre outras) que é identificada por uma imagem ao lado.

47

Figura 34. Referências das produções

O usuário pode clicar em uma das produções para verificar todos os atributos referentes a

produção selecionada, conforme pode ser visto na Figura 35.

48

Figura 35. Detalhes das produções

Na Figura 36 pode ser visualizado o diagrama ER do sistema SAPI. Para este projeto, as

entidades importantes são a PRODUCAO e DOCENTE_PRODUCAO.

49

AREA

ARE_COD

ARE_NOMEARE_PES_CADASTROUARE_PES_DELETAARE_INICIOARE_FIMARE_COD_CNPQ

AREA_PRODUCAO

ARE_COD (FK)PRO_COD (FK)ARP_INICIO

ARP_PES_CADASTROUARP_PES_DELETAARP_FIM

ARQUIVO

PES_COD

SUB_COD (FK)ARQ_XML

CENARIO

CEN_COD

CEN_NOMECEN_PES_CADASTROUCEN_INICIOCEN_PES_DELETACEN_FIM

CENARIO_PRODUCAO

TIP_COD (FK)CEN_COD (FK)

CEP_PESOCEP_INICIOCEP_FIMCEP_PES_CADASTROUCEP_PES_DELETA

DOCENTE_PRODUCAO

PES_CODPRO_COD (FK)DOP_INICIO

PRO_REFERENCIADOP_FIMDOP_PES_CADASTROUDOP_PES_DELETA

GRUPO

GRU_COD

GRU_NOMEPES_CODUNICODGRU_PES_CADASTROUGRU_PES_DELETAGRU_INICIOGRU_FIMGRU_PARTICIPANTES

PRODUCAO

PRO_COD

PRO_PES_DELETAPRO_PES_CADASTROUTIP_COD (FK)PRO_INICIOPRO_FIMSUB_COD (FK)PRO_VALIDAPRO_VALIDA_DOCENTEPRO_VALIDA_PROPPECPRO_VALIDA_DATATIP_COD_PAIPRO_VALIDA_ANTIGO

PRODUCAO_CURSO

PRO_COD (FK)CURCODPRC_INICIO

PRC_PES_CADASTROUPRC_PES_DELETAPRC_FIM

PRODUCAO_GRUPO

PRO_COD (FK)GRU_COD (FK)PRG_INICIO

PRG_PES_CADASTROUPRG_FIMPRG_PES_DELETA

RELATORIO

REL_COD

REL_NOMECEN_COD (FK)REL_PES_CADASTROUREL_INICIOREL_FIMREL_PES_DELETAREL_ANO_INICIOREL_ANO_FIMREL_UNIVALI

RELATORIO_AGRUPA

REL_COD (FK)AGR_ORDEM

AGR_DESCRICAO

RELATORIO_AREA

REL_COD (FK)ARE_COD (FK)

RELATORIO_CAMPUS

REL_COD (FK)CAMCOD

RELATORIO_CENTRO

REL_COD (FK)CENCOD

RELATORIO_CURSO

REL_COD (FK)CURCOD

RELATORIO_DOCENTE

PES_CODREL_COD (FK)

RELATORIO_GRUPO

REL_COD (FK)GRU_COD (FK)

RELATORIO_PERFIL

REL_COD (FK)PES_CODREP_INICIO

REP_PES_CADASTROUREP_PES_DELETAREP_FIM

RELATORIO_TIPO

REL_COD (FK)TIP_COD (FK)

RELATORIO_TITULACAO

REL_COD (FK)TIT_COD

SUBMISSAO

SUB_COD

SUB_INICIOSUB_FIMPES_CODSUB_PES_CADASTROU

TIPO_PRODUCAO

TIP_COD

TIP_COD_PAI (FK)TIP_NOMETIP_PES_CADASTROUTIP_INICIOTIP_FIMTIP_PES_DELETATIP_COD_ANTIGO

VALOR_ATRIBUTO

PRO_COD (FK)VAL_ORDEMVAL_ATRIBUTO

VAL_CONTEUDOPES_COD

Figura 36. Diagrama entidade-relacionamento do SAPI

Quanto ao processo de submissão de um currículo, o usuário gera um arquivo XML que irá

conter o número do seu CPF com identificador. Os dados deste arquivo serão comparados com as

informações presentes na base de dados de docentes do sistema de carga-horária. Caso seja um

docente que esteja submetendo, é verificado se o currículo realmente pertence a ele, se não for, será

solicitado que o docente verifique se ele não submeteu o arquivo errado, ou então que corrija seus

dados no currículo ou departamento de controle docente, pois há inconsistência das informações.

Caso o currículo seja submetido por um funcionário da PROPPEC, será identificada a qual docente

pertence através do número de CPF.

50

A similaridade é realizada a partir da referência e dos atributos que compõe a produção (ex:

título, local do evento, ano, etc.). No método semi-automático as referências que tiverem mais de

90% de similaridade e as referências que ainda não tiverem sido confirmadas pela PROPPEC são

substituídas pela existente na base, ao contrário, se a referência já tiver sido confirmada ela não é

substituída.

Caso o grau de semelhança da produção existente no arquivo XML esteja entre 60% e 90%

com alguma já existente no banco de dados, é necessário a validação por um usuário específico do

sistema para decidir se a produção é nova ou não. Para os casos onde a similaridade é menor do que

60%, o sistema considera a produção automaticamente como sendo nova.

O problema que o presente TCC visa apoiar se refere a análise comparativa de algoritmos

utilizados para pesquisas de strings por similaridade, utilizando o SAPI como estudo de caso. O

SAPI possui alguns problemas onde o procedimento que compara se uma produção é nova não

funciona eficientemente. Também foi relatado que as comparações demandam muito tempo, fatores

estes que incentivaram a motivação para o desenvolvimento deste projeto.

Atualmente o SAPI utiliza uma função PHP chamada similar_text para realizar as

comparações. Está função utiliza chamadas recursivas que podem melhorar o desempenho do

processo. Sua sintaxe é composta por três parâmetros, sendo os dois primeiros as duas strings que

se deseja comparar e o terceiro parâmetro serve para indicar se a resposta será retornada em

porcentagem ou não. Parte do código está descrito na Figura 37.

A utilização de comparação via linguagem de alto nível demanda um alto processamento do

servidor, e acarreta no carregamento de todas as produções para então realizar a comparação.

Utilizando uma função do próprio SGBD, acredita-se diminuir o tempo de comparação e o

processamento da máquina.

51

while (list($i) = each($xmlProducao)){ if (is_array($producoesN)){ $porcent = 0; $posicao = 0; $flag = true; # Se o próximo registro do vetor, for o desejado, então nem passa pelo laço $xmlProducao[$i][90] = htmlspecialchars($xmlProducao[$i][90], ENT_QUOTES); if (trim($xmlProducao[$i][90])==trim($producoesN[$cont][referencia])){ $porcent = 100; $posicao = $cont; $flag = false; $producoesN[$posicao][associado] = $i; $cont++; } else{ # Localiza no vetor por completo, abortando ao encontrar exato $cont=0; reset($producoesN); while ((list($j) = each($producoesN)) && $flag){ $cont++; if ($producoesN[$j][base]=='1' && !$producoesN[$j][associado]){ $porcent2 = 0; if (trim($xmlProducao[$i][90])==trim($producoesN[$j][referencia])){ $porcent = 100; $posicao = $j; $flag = false; $producoesN[$j][associado] = $i; } else{ similar_text ( trim($xmlProducao[$i][90]), trim($producoesN[$j][referencia]) , $porcent2); if ($porcent2 > $porcent){ $porcent = $porcent2; $posicao = $j; } } } } } $producoesN[$j][escolhido_cod] = $posicao; $producoesN[$j][escolhido_por] = $porcent; }

Figura 37. Código PHP do SAPI utilizado para efetuar a comparação

3 PROJETO

A idéia principal do projeto é implementar os algoritmos utilizando a linguagem de

programação PL/SQL para a codificação.

As lógicas dos algoritmos documentados anteriormente foram estudadas e, após isso, foram

escolhidos os cinco algoritmos que mais se aproximaram a necessidade atual, sendo estes listados

abaixo:

• KMP;

• Rabin Karp;

• Levenshtein;

• Hamming Distance;

• Jaro.

Para cada algoritmo analisado foi desenvolvida uma função, sendo que todos terão a sintaxe

apresentada na Figura 38.

FUNCAO( TEXTO,

STRING,

RESULTADO )

Figura 38. Sintaxe das funções de similaridade produzidas

Conforme a sintaxe, a FUNCAO é o nome do algoritmo codificado, TEXTO é o texto onde

se deseja localizar a string, STRING é a palavra que se deseja encontrar no texto e RESULTADO é

o resultado retornado pela função (pode ser a porcentagem da similaridade, quantidade de

diferenças entre as strings, posição em que foi encontrada a string, dependendo da disponibilidade

de cada algoritmo).

Foi obtida uma base de dados real do SAPI para os testes, onde foram selecionados registros

para serem aplicados aos algoritmos. Após isso, cada registro foi copiado e modificado para ser

53

executado nas funções. Cada dupla de registros (original e modificado) teve sua similaridade

calculada pelos algoritmos implementados e também por uma função do PHP chamada similar_text

para haver um ponto de referência ao avaliar os resultados gerados em cada teste.

Após o fim de cada teste, foi armazenado o tempo levado pela rotina, qual o algoritmo

utilizado, quais os parâmetros de referência foram passados para a função, quais as informações que

foram obtidas como resposta e qual o grau de eficiência exibidos ao usuário, trazendo apenas as

informações realmente similares ao que foi informado por parâmetro.

Após o fim dos testes, todos os dados obtidos foram comparados entre si para que seja

possível construir uma documentação com os pontos fortes e fracos de cada algoritmo. Na Figura

39 é apresentado um exemplo básico que será realizado com os algoritmos para avaliar o

funcionamento dos mesmos.

Figura 39. Comparação entre as strings “ABACATE” e “ABATE”.

3.1.1 Hamming Distance

A função Hamming Distance possui como parâmetro duas strings que se deseja comparar. É

retornada a quantidade de diferenças entre as palavras. O código fonte é exibido na Figura 40.

54

FUNCTION Hamming (value1 IN VARCHAR2, value2 IN VARCHAR2) RETURN NUMBER IS distance NUMBER; i NUMBER; len NUMBER; BEGIN distance := 0; i := 1; IF(LENGTH(VALUE1) > LENGTH(VALUE2))THEN LEN := LENGTH(VALUE1); ELSE LEN := LENGTH(VALUE2); END IF; IF (value1 is null) or (value2 is null) THEN return null; ELSE WHILE (i <= len) LOOP IF(SUBSTR(VALUE1,i,1) <> SUBSTR(VALUE2,i,1))THEN distance := distance + 1; ELSE distance := distance + 0; END IF; i := i + 1; END LOOP; END IF; return distance; END Hamming;

Figura 40. Implementação da função Hamming Distance.

Para exemplificar o funcionamento da função Hamming Distance, foi executada uma

comparação entre as palavras “ABACATE” e “ABATE”. Na Figura 41 pode-se verificar que a

diferença retornada é igual a 2.

Figura 41. Resultado da comparação entre as palavras ABACATE e ABATE utilizando a função

Hamming Distance.

A função Hamming Distance faz uma comparação conforme observado na Figura 42, onde

as duas strings são alinhadas e é somado ao resultado o valor 1 caso as letras sejam diferentes ou

somado o valor zero caso as letras sejam iguais. A função desconsidera os caracteres que sobram

devido a diferença de tamanho entre as palavras, sendo que neste exemplo utilizado, as duas últimas

letras “T” e “E” recebem zero por este motivo.

55

Figura 42. Tabela gerada na comparação entre as palavras “ABACATE” e “ABATE” utilizando a

função Hamming Distance.

3.1.2 Levenshtein

A função Levenshtein possui como parâmetro duas strings que se deseja comparar. É

retornada a quantidade de diferenças entre as palavras. O código fonte é exibido na Figura 43.

FOR j IN 0 .. QT_TAM_STRING LOOP COLUNA_ESQ(j) := j; END LOOP; FOR i IN 1.. QT_TAM_TEXTO LOOP COLUNA_ATUAL(0) := i; FOR j IN 1 .. QT_TAM_STRING LOOP IF SUBSTR (PDS_TEXTO, i, 1) = SUBSTR (PDS_STRING, j, 1) THEN CUSTO := 0; ELSE CUSTO := 1; END IF; COLUNA_ATUAL(j) := LEAST (COLUNA_ATUAL(j-1) + 1, COLUNA_ESQ(j) + 1, COLUNA_ESQ(j-1) + CUSTO); END LOOP; FOR j IN 0 .. QT_TAM_STRING LOOP COLUNA_ESQ(j) := COLUNA_ATUAL(j); END LOOP; END LOOP;

Figura 43. Trecho principal do código da função Levenshtein.

Para demonstrar o funcionamento deste algoritmo, que foi explicado na seção 2.2.5 deste

trabalho, foi executada uma comparação entre as palavras ABACATE e ABATE. Na Figura 44

pode-se verificar que a diferença retornada é igual a 2.

56

Figura 44. Resultado da comparação entre as palavras “ABACATE” e “ABATE” utilizando a

função Levenshtein.

O primeiro passo, apresentado na Figura 45, é verificar se a primeira letra de cada string é

igual ou não. Se for é atribuído valor 0 (zero) para o primeiro campo da tabela, caso contrário é

atribuído o valor 1. Este cálculo é chamado de custo. Os demais campos da mesma coluna recebem

o valor do campo superior acrescido de um.

Figura 45. Primeiro passo do exemplo do algoritmo de Levenshtein.

Na segunda iteração é feita uma comparação entre o valor campo da esquerda acrescido de

um, o campo de cima acrescido de um e o campo da diagonal superior à esquerda acrescido do

valor do custo. No caso da Figura 46, como existe apenas valor à esquerda (0 + 1) este será

selecionado.

57

Figura 46. Primeira comparação da segunda iteração do exemplo do algoritmo de Levenshtein.

Em seguida é feita a mesma ação com os demais campos da mesma coluna. O resultado

escolhido sempre será o menor valor entre os três possíveis, sendo que nesta comparação foi o valor

da diagonal.

A segunda comparação da segunda iteração do algoritmo é mostrada na Figura 47, onde é

feita a comparação entre as letras ‘B’ e ‘B’. Devido ao fato de as letras serem iguais o custo recebe

valor igual a 0. Conforme pode ser observado na tabela auxiliar da mesma figura, o valor sugerido a

partir do campo superior é igual a 1 (valor do campo) mais o valor 1 (seguindo a regra), resultando

o valor 2. Partindo do campo à esquerda, o valor sugerido é igual a 1 (valor do campo) mais o valor

1 (seguindo a regra), resultando o valor 2. E, a partir do campo da diagonal superior esquerda, o

valor sugerido é igual a zero (valor do campo) mais o valor do custo (igual a zero pois os caracteres

comparados são iguais), resultando o valor 0.

Após o cálculo das possibilidades o valor escolhido é o menor entre os três possíveis, sendo

que neste caso é igual a 0 (proveniente do campo da diagonal).

58

Figura 47. Segunda comparação da segunda iteração do exemplo do algoritmo de Levenshtein.

A terceira comparação da segunda iteração do algoritmo é mostrada na Figura 48, onde é

feita a comparação entre as letras ‘B’ e ‘T’. Devido ao fato de as letras serem diferentes o custo

recebe valor igual a 1. Conforme pode ser observado na tabela auxiliar da mesma figura, o valor

sugerido a partir do campo superior é igual a zero (valor do campo) mais o valor 1 (seguindo a

regra), resultando o valor 1. Partindo do campo à esquerda, o valor sugerido é igual a 2 (valor do

campo) mais o valor 1 (seguindo a regra), resultando o valor 3. E, a partir do campo da diagonal

superior esquerda, o valor sugerido é igual a 1 (valor do campo) mais o valor do custo (igual a 1

pois os caracteres comparados são diferentes), resultando o valor 2.


que neste caso é igual a 1 (proveniente do campo superior).

Figura 48. Terceira comparação da segunda iteração do exemplo do algoritmo de Levenshtein.

A quarta comparação da segunda iteração do algoritmo é mostrada na Figura 49, onde é feita

a comparação entre as letras ‘B’ e ‘E’. Devido ao fato de as letras serem diferentes o custo recebe


59




valor sugerido é igual a 2 (valor do campo) mais o valor do custo (igual a 1 pois os caracteres

comparados são diferentes), resultando o valor 3.



Figura 49. Quarta comparação da segunda iteração do exemplo do algoritmo de Levenshtein.

A quinta comparação da segunda iteração do algoritmo é mostrada na Figura 49, onde é feita

a comparação entre as letras ‘B’ e ‘A’. Devido ao fato de as letras serem diferentes o custo recebe





valor sugerido é igual a 3 (valor do campo) mais o valor do custo (igual a 1 pois os caracteres

comparados são diferentes), resultando o valor 4.



60

Figura 50. Quinta comparação da segunda iteração do exemplo do algoritmo de Levenshtein.

Após o cálculo de todas as posições da tabela o valor resultante da função será o da última

linha e última coluna da tabela conforme apresentado na Figura 51.

Figura 51. Resultado final da tabela de comparações do exemplo do algoritmo de Levenshtein

3.1.3 KMP

A função Hamming Distance possui como parâmetro duas strings que se deseja comparar.

São exibidas em quais posições a string que se deseja localizar é igual na string original. Caso não

seja igual em nenhuma posição será exibido zero. O código-fonte é exibido na Figura 52.

61

BEGIN a := AUX_genprefix(p); for i IN 0 .. n LOOP while(q > 0 AND SUBSTR(p,q+1,1) <> SUBSTR(t,i+1,1)) loop q := a(q-1); end loop; if (SUBSTR(p,q+1,1) = SUBSTR(t,i+1,1)) then q := q + 1; sim := sim + 1; else show(sim); sim := 0; end if; if (q = m) then show ('String igual na posicao: ' || to_char(i - m + 1)); q := a(q-1); end if; end loop; END;

Figura 52. Implementação da função KMP.

O resultado da comparação entre as palavras “ABACATE” e “ABATE” utilizando o

algoritmo KMP é igual a zero conforme pode ser visto na Figura 53.

Figura 53. Resultado da comparação entre as strings “ABACATE” e “ABATE” utilizando o algoritmo KMP.

Conforme explicado na seção 2.2.2 , o primeiro passo deste algoritmo é alinhar as duas

strings à esquerda, para então iniciar a comparação de cada letra. Conforme exibido na Figura 59,

as três primeiras letras de cada palavra são iguais, porém há uma diferença ao chegar ao quarto

caractere.

Figura 54. Primeira comparação do exemplo do algoritmo KMP.

Ao ocorrer uma diferença o algoritmo deve fazer um novo alinhamento das palavras para

continuar a análise. A string que se deseja localizar é deslocada para a direita, mas como as quatro

62

primeiras letras já foram analisadas o algoritmo sabe que não adianta deslocar apenas uma posição à

direita pois iria fazer uma comparação desnecessária, já sabendo que os caracteres não são iguais.

Figura 55. Segunda comparação do exemplo do algoritmo KMP.

A Figura 55 mostra o alinhamento das strings no segundo passo da comparação, sendo que a

primeira letra de cada palavra é igual, mas a segunda não. Por não haver mais espaço para realizar

um outro deslocamento para a direita, o algoritmo termina a análise das duas palavras retornando

zero.

3.1.4 Jaro

A função Jaro possui como parâmetro duas strings que se deseja comparar. É calculado o

grau de similaridade entre as duas palavras em porcentagem. O código fonte é exibido na Figura 57.

O resultado da comparação entre as palavras “ABACATE” e “ABATE” utilizando o algoritmo Jaro

pode ser visto na Figura 56.

Figura 56. Resultado da comparação entre “ABACATE” e “ABATE” utilizando o algoritmo Jaro.

Conforme explicado na seção 2.2.8 o algoritmo executa o seguinte cálculo: ((LI / T1) +

(LI/T2) + ((LI-TR)/LI)) * 1/3, onde LI é o número de letras iguais ao comparar as duas palavras, T1

é o tamanho da primeira string, T2 é o tamanho da segunda string e TR é o número de

transposições. No exemplo, T1 é igual a sete, T2 é igual a cinco, LI é igual a cinco e TR é igual a

zero. Substituir estes valores na fórmula: ((5/7) + (5/5) + ((5-0)/5)) * 1/3 = 0,9047 = 90,47%.

63

FOR i IN 1 .. tam_str1 LOOP a1 := SUBSTR(str1, i, 1); IF m >= i THEN f := 1; l := i + m; ELSE f := i - m; l := i + m; END IF; IF l > tam_max THEN l := tam_max; END IF; FOR j IN f .. l LOOP a2 := SUBSTR(str2, j, 1); IF (a2 = a1) AND (f2(j) = FALSE) THEN comum := comum + 1; f1(i) := TRUE; f2(j) := TRUE; GOTO saida; END IF; END LOOP; <<saida>> NULL; END LOOP; l := 1; FOR i IN 1 .. tam_str1 LOOP IF f1(i) THEN FOR j IN l .. tam_str2 LOOP IF f2(j) THEN l := j + 1; a1 := SUBSTR(str1, i, 1); a2 := SUBSTR(str2, j, 1); IF a1 <> a2 THEN tr := tr + 0.5; END IF; GOTO j_loop; END IF; END LOOP; <<j_loop>> NULL; END IF; END LOOP;

Figura 57. Implementação da função KMP.

3.1.5 Rabin-Karp

A função Rabin-Karp possui como parâmetro duas strings que se deseja comparar. Caso a

string for encontrada a função retorna o número de caracteres iguais, caso contrário retorna zero. O

código-fonte é exibido na Figura 58.

64

M := LENGTH(STR1_IN); N := LENGTH(STR2_IN); LOOP EXIT WHEN I < M; p := trunc((d*p + tonum(substr(str1_in,i,1))) / q); h := trunc((d*h + tonum(substr(str2_in,i,1))) / q); FOR W IN 0..N-M LOOP IF (p = h) then id_found := true; FOR j IN 0..M-1 LOOP IF (substr(str1_in,j,1) <> substr(str2_in,i+j,1))THEN id_found := false; exit; ELSE qt_cnt := nvl(qt_cnt,0) + 1; END IF; END LOOP; IF (id_found) THEN return qt_cnt; END IF; END IF; IF (i<n-m) THEN h := (d*(q+h-trunc((tonum(substr(STR1_IN,i,1))) / q)) + trunc(tonum(substr(STR1_IN,i+m,1))) / q); END IF; RETURN qt_cnt; END LOOP; I := I + 1; END LOOP;

Figura 58. Implementação da função Rabin-Karp.

Para exemplificar este algoritmo que foi explicado na seção 2.2.4 , foram comparadas as

palavras “ABACATE” e “ABATE”. O resultado retornado é igual a zero conforme pode ser visto

na Figura 59.

Figura 59. Resultado da comparação entre as strings “ABACATE” e “ABATE” utilizando o algoritmo Rabin-Karp.

O primeiro passo é alinhar as duas palavras e calcular o valor numérico que cada letra se

refere. A Figura 60 mostra a primeira iteração, onde são comparadas as cinco primeiras letras da

string maior (“ABACA”) com a string que se deseja localizar (“ABATE”).

65

Figura 60. Primeira comparação do exemplo do algoritmo de Rabin-Karp.

A comparação é feita somando-se os valores numéricos que cada letra representa. A string

“ABACA” possui um valor igual a 3, enquanto que a string “ABATE” possui um valor numérico

igual a 24. Se os valores fossem iguais então a função iniciaria a comparação posição por posição,

mas neste caso a comparação segue em frente alinhando as strings em uma nova posição, conforme

exibido na Figura 61.

Figura 61. Segunda comparação do exemplo do algoritmo de Rabin-Karp.

A próxima comparação executada é entre a string (“BACAT”) com a string que se deseja

localizar (“ABATE”). São somados os valores numéricos que cada letra representa. A string

“BACAT” possui um valor igual a 22, enquanto que a string “ABATE” possui um valor numérico

igual a 24. Se os valores fossem iguais então a função iniciaria a comparação posição por posição,

mas neste caso a comparação segue em frente alinhando as strings em uma nova posição, conforme

exibido na Figura 62.

66

Figura 62. Terceira comparação do exemplo do algoritmo de Rabin-Karp.

Uma nova comparação é executada pelo motivo de a string ainda não ter sido encontrada. A

string menor (“ABATE”) é deslocada mais uma posição para a direita e uma nova iteração é

realizada. São somados os valores numéricos que cada letra representa. A string “ACATE” possui

um valor igual a 25, enquanto que a string “ABATE” possui um valor numérico igual a 24. Se os

valores fossem iguais então a função iniciaria uma comparação posição por posição, mas neste caso

a função finaliza sua execução pois não há mais posições para realizar um outro alinhamento das

duas strings.

3.1.6 Algoritmo Proposto

O primeiro passo do algoritmo proposto é inserir a produção original e a alterada em uma

tabela temporária, gravando cada palavra separadamente. O segundo passo consiste em remover

todas as acentuações, substituir as cedilhas das palavras pela letra ‘c’ e apagar as palavras que

possuam menos do que três caracteres. Em seguida, para cada palavra da produção alterada procura-

se uma palavra igual na tabela das palavras da produção original. Se a palavra for encontrada,

incrementa o valor um (1) em uma variável de controle de acertos. Caso ela não seja idêntica a

nenhuma das palavras da produção original, reinicia-se uma nova varredura na tabela de palavras da

produção original calculando qual o grau de similaridade de cada palavra, considerando a palavra

de deseja-se comparar.

Nesta etapa de cálculo da porcentagem para as palavras que não são idênticas foi utilizado

como base o algoritmo Levenshtein. Foi utilizado o mesmo cálculo, explicado anteriormente, que é

usado por esta função para verificar a quantidade de diferenças. O valor de diferenças resultante é

dividido pelo número de caracteres composto pela palavra que se deseja localizar, gerando o grau

de similaridade da palavra que será somado com a variável de controle de acertos.

67

Por exemplo, no caso de a string original possuir as palavra “ABACATE VERDE” e a

string alterada possuir “ABATE VERDE”, serão gravadas as palavras “ABACATE” e “VERDE”

separadamente na tabela auxiliar um, enquanto que na tabela auxiliar dois serão gravadas as

palavras “ABATE” e “VERDE” da string modificada.

Figura 63. Terceira comparação do exemplo do algoritmo de Rabin-Karp.

Na Figura 63 é mostrado as duas iterações possíveis no processo de comparação das

palavras. Inicia-se o processo comparativo comparando a palavra “ABACATE” com todas as

palavras gravadas na tabela auxiliar dois. Neste caso a string “ABACATE” não é totalmente

idêntica a nenhuma das armazenadas. Então o próximo passo é calcular o grau de similaridade todas

as palavras da tabela auxiliar dois, sendo a comparação um entre “ABACATE” e “ABATE” e a

comparação dois entre “ABACATE” e “VERDE”. O resultado da primeira comparação é igual a

71% (resultado da função Levenshtein dividido pela quantidade de letras da palavra) e o resultado

da segunda comparação é igual a 6%. A variável de controle de acertos recebe o valor 0,71, pois foi

o maior grau encontrado. O algoritmo segue para a segunda iteração, formando as novas

comparações entre “VERDE” e “ABATE”, e as palavras “VERDE” e “VERDE”. Neste caso a

palavra “VERDE” é 100% idêntica a uma das palavras da outra tabela auxiliar, somando um (1) ao

valor da variável de controle de acertos. O resultado final da função é igual a média das

similaridades, sendo igual a 85,5% ((1 + 0,71) / 2).

3.2 TESTES

Após a implantação das funções foi constatado, através de pequenos testes, que dos

algoritmos escolhidos apenas o Jaro é capaz de retornar o grau de similaridade em porcentagem, por

isso os demais foram descartados nos cenários de testes. Para haver como comparar os resultados,

68

foram incluídos nos cenários de testes os algoritmos similar_text (do php) e um novo algoritmo

proposto.

Para a realização dos testes foi obtida a base de dados do SAPI contendo as produções dos

docentes da UNIVALI. Foram, aleatoriamente, selecionados registros da base de dados obtida e

cada registro foi copiado e modificado para ser executado nas funções. Cada dupla de registros

(original e modificado) teve sua similaridade calculada pelo algoritmo Jaro, o algoritmo proposto e

também por uma função do PHP chamada similar_text para haver um ponto de referência ao avaliar

os resultados gerados em cada teste. Os demais algoritmos implementados não foram incluídos nos

testes por não retornarem o resultado em porcentagem de similaridade, e sim por posição em que a

string foi encontrada ou quantidade de caracteres diferentes.

Atualmente há 2161 professores cadastrados no SAPI e com a média de 84 produções por

currículo. A Figura 64 exibe a relação entre o número de docentes e a quantidade de produções de

cada um. O gráfico mostra que a maioria dos docentes (909 funcionários) possuem de zero a dez

produções cadastradas, 377 possuem entre dez e cinqüenta, 258 entre cinqüenta e cem produções,

469 docentes têm entre cem e trezentas produções, 109 têm entre trezentos e quinhentos registros e

apenas 44 docentes atingem a marca de quinhentas produções ou mais .

Figura 64. Gráfico do número de docentes por faixa de quantidade de produções.

69

Buscou-se apresentar dois cenários para os testes. O primeiro apresenta os resultados da

comparação das produções de um professor com aproximadamente 100 produções, isto é, a média

atual de produções por professor. O segundo cenário apresenta um caso de docentes com um valor

expressivo de produções, em torno de 1000 produções. Tais professores fazem parte de um grupo

pequeno, atualmente apenas 5 professores têm mais de 950 produções cadastradas. Entretanto,

devido ao elevado número de itens a comparar, há uma grande chance de demora no processamento

e qualidade nos resultados da comparação.

Os cenários de testes criados podem ser encontrados no apêndice A deste trabalho.

3.3 RESULTADOS OBTIDOS

Após a execução dos dez cenários de testes pode-se concluir que o novo algoritmo proposto

acabou tendo um melhor grau de similaridade em relação aos outros dois. Com base nos dados da

Tabela 7, verifica-se que o algoritmo similar_text obteve o melhor grau de similaridade três vezes,

cinco vezes o pior grau e na maioria dos cenários ficou com o segundo melhor resultado. O

algoritmo Jaro conseguiu melhor grau de similaridade em três cenários, porém foi o que teve pior

posição, ficando em doze vezes como o que teve o pior grau de similaridade. O algoritmo proposto

teve o melhor desempenho quanto ao grau de similaridade em treze vezes, mantendo seu resultado

próximo aos demais nos dois cenários em que não ganhou. Quanto ao tempo de execução, a

similar_text foi a melhor em todos os testes, enquanto que o algoritmo proposto foi o mais

demorado.

Tabela 7. Tabela de resultados geral dos testes quanto ao grau de similaridade

Algoritmo Melhor Grau Intermediário Pior Grau Similar_Text (PHP) 3 vezes 11 vezes 5 vezes Jaro 3 vezes 4 vezes 12 vezes Algoritmo Proposto 13 vezes 5 vez 1 vez

A Figura 65 é uma média do grau de similaridade, em porcentagem, obtido nos testes do

cenário um e dois, onde foram executadas as três funções escolhidas. O novo algoritmo proposto foi

o melhor entre os três, mantendo uma média de 88,20% de similaridade, enquanto que o Jaro e o

Similar Text tiveram média igual a 80,03 e 80,29 respectivamente.

70

Figura 65. Gráfico da média do grau de similaridade resultante dos dois cenários de testes.

O mesmo foi feito com as médias do tempo (em segundos) de execução das rotinas, que são

exibidas na Figura 66. A média resultante de todos os testes do algoritmo proposto foi de 52,52

segundos, sendo seguido pelo algoritmo Jaro que precisou de uma média de 24,39 segundos para

cada teste, enquanto que o algoritmo Similar Text rodou em média 0,48 segundos em cada teste.

71

Figura 66. Gráfico da média do tempo de execução em segundos resultante dos dois cenários de

testes.

3.4 ANÁLISE DA HIPÓTESE

Para a análise dos resultados obtidos com os algoritmos, foram propostas seis hipóteses.

Para cada hipótese foi feita a aplicação de testes estatísticos que indiquem a sua aceitação ou

rejeição. Foi selecionado o Teste Z, que é aplicado em situações onde, dadas duas amostras verificar

qual delas obteve melhor resultado.

O cálculo pode ser aplicado para comparação de duas médias. O seguinte roteiro foi

aplicado para cálculo do valor Z com relação a comparação de médias:

1. Foram definidas as hipóteses nula e alternativa. De modo geral a hipótese nula é de que a

variável analisada não é maior na segunda amostra (H0: µ1 ≥ µ2) e a hipótese alternativa

de que a segunda amostra é significativamente maior (Hα: µ1 < µ2 );

Para cada variável analisada, obteve-se a o η (tamanho da amostra), χ (média) e σ (desvio

padrão) da totalidade das produções da amostra;

Após foi calculado o erro padrão utilizando a equação 1 da Figura 67. Já o valor de Z

calculado foi obtido através da equação 2 da Figura 67. Comparou-se o valor de Z calculado com o

valor de Z crítico relacionado ao nível de confiança definido (95%). Por tratar-se de um teste

72

monocaudal esquerda 1, neste nível confiança, o valor crítico de Z é -1,96, e conseqüentemente, a

região de rejeição da hipótese nula exige valor de Z < -1,96 (LARSON & FARBER, 2004).

(1) Erro padrão: nnxx

2

2

2

1

2

1

21

σσσ +=

−

(2) Teste Z: σ xx

zxx

21

)(21

−

−=

Figura 67. Teste Z para comparação entre médias

3.4.1 Hipótese 1

A hipótese 1 verifica se o algoritmo Jaro é melhor que o similar_text quanto ao cálculo da

similaridade dos textos, isto é, dentre os dois algoritmos qual produziu o melhor resultado. A fim de

examinar esta afirmação, as hipóteses nula e a alternativa foram assim estabelecidas:

H0: µ1 ≥ µ2 (o algoritmo similar_text é melhor ou igual ao Jaro)

Hα: µ1 < µ2 (o algoritmo similar_text é pior que o Jaro)

Aplicando o Teste Z, com nível de significância de α = 0,05, cujo valor crítico é de -1,96,

tem-se o resultado z = 0,29. Conclui-se que não é possível rejeitar a hipótese nula, pois Z não está

na região de rejeição.

3.4.2 Hipótese 2

A hipótese 2 verifica se o algoritmo proposto é melhor que o similar_text quanto ao cálculo

da similaridade dos textos, isto é, dentre os dois algoritmos qual produziu o melhor resultado. A fim

de examinar esta afirmação, as hipóteses nula e a alternativa foram assim estabelecidas:

H0: µ1 ≥ µ2 (o algoritmo similar_text é melhor ou igual ao proposto)

Hα: µ1 < µ2 (o algoritmo similar_text é pior que o proposto)

1 Segundo Larson e Farber (2004): “Se a hipótese alternativa Há contiver o símbolo de menor do que (<), o teste de hipótese será um teste monocudal esquerda”.

73


tem-se o resultado z = -8,24. Conclui-se que é possível rejeitar a hipótese nula, pois Z está na região

de rejeição. Logo, o algoritmo proposto apresentou melhores resultados que o similar_text.

3.4.3 Hipótese 3

A hipótese 3 verifica se o algoritmo proposto é melhor que o Jaro quanto ao cálculo da

similaridade dos textos, isto é, dentre os dois algoritmos qual produziu o melhor resultado. A fim de

examinar esta afirmação, as hipóteses nula e a alternativa foram assim estabelecidas:

H0: µ1 ≥ µ2 (o algoritmo Jaro é melhor ou igual ao proposto)

Hα: µ1 < µ2 (o algoritmo Jaro é pior que o proposto)


tem-se o resultado z = -10,59. Conclui-se que é possível rejeitar a hipótese nula, pois Z está na

região de rejeição. Logo, o algoritmo proposto apresentou melhores resultados que o Jaro.

3.4.4 Hipótese 4

A hipótese 4 verifica se o algoritmo Jaro é melhor que o similar_text quanto ao tempo de

processamento da similaridade dos textos, isto é, dentre os dois algoritmos qual produziu o melhor

resultado. A fim de examinar esta afirmação, as hipóteses nula e a alternativa foram assim

estabelecidas:

H0: µ1 ≥ µ2 (o algoritmo similar_text é melhor ou igual ao Jaro)

Hα: µ1 < µ2 (o algoritmo similar_text é pior que o Jaro)




3.4.5 Hipótese 5

A hipótese 5 verifica se o algoritmo proposto é melhor que o similar_text quanto ao tempo

de processamento da similaridade dos textos, isto é, dentre os dois algoritmos qual produziu o

74

melhor resultado. A fim de examinar esta afirmação, as hipóteses nula e a alternativa foram assim

estabelecidas:

H0: µ1 ≥ µ2 (o algoritmo similar_text é melhor ou igual ao proposto)

Hα: µ1 < µ2 (o algoritmo similar_text é pior que o proposto)




3.4.6 Hipótese 6

A hipótese 6 verifica se o algoritmo proposto é melhor que o Jaro quanto ao tempo de

processamento da similaridade dos textos, isto é, dentre os dois algoritmos qual produziu o melhor

resultado. A fim de examinar esta afirmação, as hipóteses nula e a alternativa foram assim

estabelecidas:

H0: µ1 ≥ µ2 (o algoritmo Jaro é melhor ou igual ao proposto)

Hα: µ1 < µ2 (o algoritmo Jaro é pior que o proposto)




3.4.7 Conclusões

Estatisticamente é possível provar que quanto a similaridade, o algoritmo proposto é melhor

que o Similar_Text e que o Jaro, mas o mesmo não pode ser dito quanto ao tempo de

processamento, resultado este que ficou favorável ao algoritmo utilizado pelo PHP.

75

4 CONCLUSÃO

Os sistemas gerenciadores de banco de dados atuais possuem diversas funções importantes,

que auxiliam na manutenção, segurança e armazenamento de informações. Porém, mesmo estando

no mercado desde a década de 60, o processo de consultas é muito restrito, permitindo apenas

consultas exatas.

Existem poucos aplicativos com esta função de efetuar consultas retornando objetos

semelhantes aos solicitados pelo usuário. Os principais são utilizados na área da medicina para

consultar imagens de exames, permitindo aos médicos buscar no banco de imagens casos de outros

pacientes que tiveram o mesmo problema de saúde, possibilitando que o especialista utilize o

mesmo tratamento usado anteriormente, ou tentar outra saída caso o mesmo não tenha funcionado

com sucesso.

O que motivou a execução deste trabalho foi a necessidade do SAPI em efetuar

comparações para verificar a similaridade entre a base de dados do Lattes e da UNIVALI. Após

definido o problema, iniciou-se uma pesquisa por temas relacionados a esta área e por algoritmos

existentes para realização de consultas por similaridade de textos. Cada algoritmo encontrado foi

documentado e explicado, através de figuras e de exemplos para um melhor entendimento.

Foram selecionados alguns dos algoritmos para serem implementados em formato de

funções, que foram avaliadas para saber quais delas poderiam se encaixar na necessidade do SAPI.

Após análise, foi escolhida a função Jaro para fazer parte dos testes. Além desta, um novo algoritmo

foi desenvolvido, implementado e documentado para mesma finalidade.

Para a realização dos testes foi requisitada uma base de dados real do SAPI, contendo as

produções cadastradas dos docentes da UNIVALI. Os cenários de testes foram compostos pelas

funções Jaro, o algoritmo proposto e mais a função Similar Text do PHP, atualmente utilizada pelo

SAPI.

Foram escolhidas algumas produções da base de dados, que foram alteradas para serem

utilizadas nos testes. Cada produção alterada foi aplicada nos três algoritmos, gerando como

resposta para cada um deles o grau de similaridade e tempo de execução. Estas informações foram

documentadas e, posteriormente, utilizadas na conclusão dos cenários de testes.

76

Os resultados comprovaram que o novo algoritmo proposto é o melhor ao se tratar da

similaridade das strings, se mantendo em aproximadamente 70% das vezes como sendo o que

obteve o melhor grau de similaridade. Porém, ao analisar o tempo necessário para efetuar todas as

comparações o Similar Text obteve um desempenho de tempo de execução muito melhor que os

demais em todos os testes. Como a maioria dos docentes que utilizam o SAPI possui poucas

produções cadastradas, o impacto de performance ao adaptar o novo algoritmo no sistema não seria

muito grande e poderia trazer benefícios consideráveis quanto ao problema de erros na busca por

produções iguais já cadastradas.

77

REFERÊNCIAS BIBLIOGRÁFICAS

BATTISTI, Júlio César Fabris. Noções da linguagem SQL para consultas. 2006. Disponível em: <http://www.linhadecodigo.com.br/Artigo.aspx?id=165>. Acesso em 05 abr. 2008.

BARIONI, Maria Camila N.; RAZENTE, Humberto L.; TRAINA, Agma J. M.; TRAINA JR, Caetano. Incluindo Consultas por Similaridade em SQL. 2005. Disponível em: <http://www.sbbd-sbes2005.ufu.br/arquivos/SimSQL.pdf>. Acesso em 09 mar. 2008.

BORGES, Eduardo N.; CONY, Carlos A.; FREITAS, André L. C. Utilização de Algoritmos de Busca por Similaridade em SGBD’s Comerciais. 2005. Disponível em: <http://www.inf.ufrgs.br/~enborges/files/Sirc_2005.pdf>. Acesso em 11 mar. 2008.

BÜHLER, Dieter. Animation of the Boyer/Moore Algorithm. 2004. Disponível em: <http://www-sr.informatik.uni-tuebingen.de/~buehler/BM/BM.html>.

CARVALHO, Paulo Sérgio R.; OLIVEIRA, Deive de.; GUARACY, Alessandra; GOMES, Alisson; CONCEIÇÃO, Fernando César da; FREIRE, Joseane; OLIVEIRA, Jones Albuquerque. Um Estudo Teórico e Experimental em Algoritmos Clássicos de Busca em Texto. 2005. Disponível em: <http://www.dcc.ufla.br/infocomp/artigos/v2.1/stringMat.pdf>. Acesso em 10 mar. 2008.

CHARRAS, Christian; LECROQ, Thierry. Levenshtein Distance. 1998. Disponível em: <http://www-igm.univ-mlv.fr/~lecroq/seqcomp/node2.html>. Acesso em 11 jun. 2008.

DATE, C. J. Introdução a Sistemas de Banco de Dados. 8. ed. São Paulo: Campus, 2007.

DORNELES, Carina F.; CERVI, Cristiano R.; LIMA, Andrei E. N. Indexação para busca por similaridade textual. 2006. Disponível em: <http://www.inf.ufrgs.br/~galante/wdl/anais/10-Carina%20Dorneles%20-%20Indexacao%20para%20busca.pdf>. Acesso em: 12 mar. 2008.

ELMASRI, Ramez; NAVATHE, Shamkant, B. Sistemas de Banco de Dados. 4. ed. São Paulo: Pearson, 2006.

GOMES JR., Manuel F. Algoritmos e Estruturas de Dados 2, Processamento de Texto. 2008. Disponível em: <http://www.dimap.ufrn.br/~manuel/arquivos/AEDII/AEDII-ProcTextosKnuthMorrisPratt.pdf>. Acesso em: 20 abr. 2008.

GONDIM, Flávio Melo. Algoritmo de Comparação de Strings para Integração de Esquemas de Dados. 2006. Disponível em: <http://www.cin.ufpe.br/~tg/2005-2/fmg.pdf>. Acesso em: 25 maio 2008.

LARSON, Ron; FARBER, Betsy. Estatística Aplicada. 2 ed. São Paulo: Prentice Hall, 2004. ISBN: 8587918591.

LEME, Ricardo. Diferença entre comandos SQL. 2008. Disponível em: <http://ricardoleme.blogspot.com/2008/06/qual-diferena-entre-comandos-dcl-dml-e.html>. Acesso em: 29 maio 2008.

78

MATTOSO, Marta. Introdução a banco de dados. 2005. Disponível em: <http://www.cos.ufrj.br/~marta/BdRel.pdf>. Acesso em: 01 jun. 2008.

MOURA, Eduardo S.; DANTAS FILHO, Emanuel; PORTO, Vinícius de Araújo. Casamento de Padrões em Strings. 2002. Disponível em: <http://dalton.dsc.ufcg.edu.br/edados/index.php/Casamento_de_Padr%C3%B5es_em_Strings>. Acesso em: 26 abr. 2008.

NOVELLI, Márcio. Abordagem geral do pl/sql. 2004. Disponível em: <http://imasters.uol.com.br/artigo/2164/abordagem_geral_do_o_plsql>. Acesso em: 01 jun. 2008.

REGO, Rodrigo Soares de Lima Sá. Projeto e Implementação de uma Plataforma MP-SoC usando SystemC. Disponível em: <http://www.ppgsc.ufrn.br/html/Producao/Dissertacoes/RodrigoSoaresDeLimaSaRego.pdf>. Acesso em: 01 jun. 2008.

ROSA, Natália Abdala; TRAINA, Agma J.; TRAINA JR., Caetano. Recuperação de Imagens Médicas por Similaridade em um Hospital Universitário. 2002. Disponível em: <http://gbdi.icmc.usp.br/publicacoes.php?pubfile=Rosa2002_WIM_ImagensPorSimilaridadeEmHU.PDF>. Acesso em: 01 jun. 2008.

SILVA, Maria Estela Vieira da; BORGES, Eduardo Nunes; GALANTE, Renata de Matos. XSimilarity: Uma Ferramenta para Consultas por Similaridade embutidas na Linguagem XQuery. 2008. Disponível em: <http://www.inf.ufsc.br/erbd2008/artigos/20.pdf>. Acesso em: 20 mai. 2008.

SOUZA, Osvaldo. Algoritmos genéticos e estrutura de dados para a pesquisa biomolecular. 2004. Disponível em: <http://www.dnocs.gov.br/php/util/downloads_file.php?&dir=&file=/home/util/livres/ebooks/monografias/algoritmos_geneticos_e_estruturas_de_dados_para_a_pesquisa_biomolecular.pdf>. Acesso em: 16 mar. 2008.

SPARKNOTE. SparkNotes Hash Tables. Disponível em: <http://www.sparknotes.com/cs/searching/hashtables/section4.rhtml>. Acesso em: 15 jun. 2008.

SPIDO, Nadia Roberta Traldi. String Matching. 2007. Disponível em: <http://scs.carleton.ca/~maheshwa/courses/5703COMP/StringMatching.pdf>. Acesso em: 10 maio 2008.

APÊNDICES

A CENÁRIOS DE TESTES

A.1 CENÁRIO 1: USUÁRIO COM POUCAS PRODUÇÕES

O cenário um é baseado em usuários que possuem aproximadamente cem produções

cadastradas. Este é o cenário típico dos professores que possuem currículos cadastrados no SAPI.

Foram realizados testes para diferentes tipos de produções: participação em bancas de comissões

julgadoras, projeto de pesquisa, artigos em eventos nacionais, orientação de TCC, artigo em evento

internacional, curso de curta duração, participação em banca de mestrado, resumo publicado em

anais de congressos e comissões de avaliação de cursos de graduação e pós-graduação.

A.1.1 Cenário 1a: Participação em Bancas

O teste a do cenário um é baseado em uma produção de participação em banca julgadora,

que foi selecionada da base de dados do SAPI e é apresentada na Figura 68, juntamente com uma

cópia alterada deste mesmo registro, gerado para ser comparado com o original através das funções

de cálculo de similaridade.

Produção original: RAABE, André Luís Alice; SILVA, Júlia Marques Carvalho da; DAZZI, Rudimar Luís Scaranto; MOREIRA, Benjamin Grando; VALLE FILHO, Adhemar Maria do. Participação em banca de Diogo Altoé Lopes. Raciocínio Probabilístico Aplicado a Sistemas Tutores Inteligentes. 2007. (Ciência da Computação) - Universidade do Vale do Itajaí. Produção alterada: SILVA, Júlia Marques Carvalho; RAABE, André Luis Alice; DAZZI, Rudimar Luis Scaranto; MOREIRA, Benjamin Grando; VALLE FILHO, Adhemar Maria do. Participação em banca de Diogo Altoé Lopes. Raciocínio Probab. Aplicado a Sistemas Tutores de Inteligência Avançada. 2008. (Ciências da Computação) - UNIVALI.

Figura 68. Produção original e alterada do cenário 1a.

A produção alterada teve as seguintes modificações: troca na ordem dos autores, abreviação

da palavra “Probabilístico”, alteração da palavra “Inteligentes” por “de Inteligência Avançada”, o

ano da produção, alteração da palavra “Ciência” para o plural e abreviação do nome da instituição.

Após executar as duas produções (original e alterada) nas três funções escolhidas, a comparação

gerou o seguinte resultado apresentado na Tabela 8.

81

Tabela 8. Tabela de resultados do cenário 1a.

Algoritmo Similaridade (%) Tempo (s) Similar_Text (PHP) 81,99 0,027 Jaro 80,02 0,045 Algoritmo Proposto 89,18 0,178

Conforme os resultados obtidos, nota-se que para este cenário a função similar_text obteve

similaridade igual a 81,99% e tempo de execução igual a 0,027 segundos, a função Jaro obteve grau

de similaridade igual a 80,02% e tempo igual a 0,045 segundos, enquanto que o algoritmo proposto

obteve similaridade igual a 89,18% e tempo de execução igual a 0,178 segundos.

A.1.2 Cenário 1b: Projeto de Pesquisa

O teste b do cenário um é baseado em uma produção de projeto de pesquisa, que foi

selecionada da base de dados do SAPI e é apresentada na Figura 69, juntamente com uma cópia

alterada deste mesmo registro, gerado para ser comparado com o original através das funções de

cálculo de similaridade.

Produção Original: Júlia Marques Carvalho da Silva. O Desenvolvimento de um Assistente Inteligente para o Ensino-Aprendizagem de Algoritmos. 2005. (Ciência da Computação) - Universidade do Vale do Itajaí. Produção Alterada: Julia Carvalho da Silva. O Desenvolvimento de um Assistente interativo para o Ensino e Aprendizagem de Algoritmos. 2005. (Ciências da Computação) - UNIVALI.

Figura 69. Produção original e alterada do cenário 1b.

A produção alterada teve as seguintes modificações: alteração no nome do autor, alteração

da palavra “Inteligente” por “interativo”, alteração da palavra “Ciência” para o plural e abreviação

do nome da instituição. Após executar as duas produções (original e alterada) nas três funções

escolhidas, a comparação gerou o seguinte resultado apresentado na Tabela 9.

Tabela 9. Tabela de resultados do cenário 1b.


82





A.1.3 Cenário 1c: Artigo em Evento Nacional

O teste c do cenário um é baseado em uma produção de artigo em evento nacional, que foi




Produção Original: SILVA, Júlia Marques Carvalho da. Proposta de um Sistema Multi-agentes para a aplicação de Objetos Inteligentes de Aprendizagem seguindo o padrão SCORM. In: Simpósio Brasileiro de Informática na Educação. São Paulo: 2007 Produção Alterada: SILVA, Julia Marques da. Proposta de um Sistema Multiagentes para a construção de Objetos Inteligentes de Aprendizagem baseando-se no padrão ESCOM. In: Simpósio de Informatica na Educ do Brasil. Sao Paulo: 2004.

Figura 70. Produção original e alterada do cenário 1c.

A produção alterada teve as seguintes modificações: alteração no nome do autor, alteração

da palavra “Multi-agentes” por “Multiagentes”, alteração da palavra “seguindo” por “baseando-se”

da sigla “SCORM” para “ESCOM”, do nome do simpósio para “de Informatica na Educ. do

Brasil”, acentuação da palavra “São Paulo” e ano da produção. Após executar as duas produções

(original e alterada) nas três funções escolhidas, a comparação gerou o seguinte resultado

apresentado na Tabela 10.

Tabela 10. Tabela de resultados do cenário 1c.




83



A.1.4 Cenário 1d: Orientação de TCC

O teste d do cenário um é baseado em uma produção de orientação de TCC, que foi




Produção Original: Júlia Marques Carvalho da Silva. Análise da Influência de Parâmetros Afetivos em um Sistema Computacional de Apoio a Aprendizagem de Algoritmos. 2005. (Ciência da Computação) - Universidade do Vale do Itajaí. Produção Alterada: Silva, Júlia Marques Carvalho da. Análise da importância de parâmetros afetivos em uma aplicação de Apoio a Aprendizagem de Algoritmos. 2008. (Ciências da Computação) - UNIVALI.

Figura 71. Produção original e alterada do cenário 1d.

A produção alterada teve as seguintes modificações: nome do autor, palavra “Influência”

para “importância”, alteração das iniciais das palavras “parâmetros afetivos”, da palavra “Sistema

Computacional” para “aplicação”, do ano da produção, da palavra “Ciência” para o plural e da

abreviação do nome da instituição. Após executar as duas produções (original e alterada) nas três

funções escolhidas, a comparação gerou o seguinte resultado apresentado na Tabela 11.

Tabela 11. Tabela de resultados do cenário 1d.






84

A.1.5 Cenário 1e: Projeto de Pesquisa

O teste e do cenário um é baseado em uma produção de projeto de pesquisa, que foi




Produção Original: Júlia Marques Carvalho da Silva. Construção de Ferramentas Interativas para Apoio à Aprendizagem Via Internet. 2004. (Ciência da Computação) - Universidade do Vale do Itajaí. Produção Alterada: Silva, Júlia Marques Carvalho da. Construção de Ferramentas para Apoio à Aprendizagem pela Internet. 2007. (Ciência da Computação) - UNIVALI.

Figura 72. Produção original e alterada do cenário 1e.

A produção alterada teve as seguintes modificações: nome do autor, da palavra “Via” por

“pela”, do ano da produção e abreviação do nome da instituição. Após executar as duas produções

(original e alterada) nas três funções escolhidas, a comparação gerou o seguinte resultado


Tabela 12. Tabela de resultados do cenário 1e.






A.1.6 Cenário 1f: Projeto de Pesquisa

O teste f do cenário um é baseado em uma produção de projeto de pesquisa, que foi




85

Produção Original: Júlia Marques Carvalho da Silva. Nelle Virtual - Ambiente de Apoio a Certificação de Idiomas através da Internet. 2002. (Ciência da Computação) - Universidade do Vale do Itajaí. Produção Alterada: Silva, Júlia Marques Carvalho da. Nelle Virtual - Ambiente para Apoio de certificação de língua extrangeira através da Internet. 2004. (Ciência da Computação) - UNIVALI.

Figura 73. Produção original e alterada do cenário 1f.

A produção alterada teve as seguintes modificações: nome do autor, alteração do trecho “de

Apoio a Certificação de Idiomas” para “para Apoio de certificação de língua extrangeira”, do ano

da produção e abreviação do nome da instituição. Após executar as duas produções (original e

alterada) nas três funções escolhidas, a comparação gerou o seguinte resultado apresentado na

Tabela 13.

Tabela 13. Tabela de resultados do cenário 1f.






A.1.7 Cenário 1g: Participação em Banca

O teste g do cenário um é baseado em uma produção de participação em banca julgadora,




86

Produção Original: DAZZI, R. L. S.; RAABE, André Luís Alice; BENITTI, Fabiane Barreto Vavassori; DETERS, Janice Inês. Participação em banca de Júlia Marques Carvalho da Silva. Análise da Influência de Parâmetros Afetivos em um Sistema Comutacional de Apoio a Aprendizagem de Algoritmos. 2005. (Ciência da Computação) - Universidade do Vale do Itajaí. Produção Alterada: DETERS, Janice Inês; RAABE, André Luís Alice; DAZZI, R. L. S.; BENITTI, Fabiane Barreto Vavassori; Participação em banca de Silva, Júlia Marques Carvalho da. Análise da importância de Parâmetros Afetivos em um Sistema Comutacional de Aprendizagem de Algoritmos. 2007. (Ciências da Computação) - Universidade do Vale do Itajaí.

Figura 74. Produção original e alterada do cenário 1g.

A produção alterada teve as seguintes modificações: ordem e nomes dos autores, alteração

do ano da produção e da palavra “Ciência” para o plural. Após executar as duas produções (original

e alterada) nas três funções escolhidas, a comparação gerou o seguinte resultado apresentado na

Tabela 14.

Tabela 14. Tabela de resultados do cenário 1g.






A.1.8 Cenário 1h: Participação em Banca

O teste h do cenário um é baseado em uma produção de participação em banca julgadora,




87

Produção Original: RAABE, André Luís Alice; ALVES, Adriana Gomes; DAZZI, Rudimar Luis Scaranto; VAHLDICK, A.; SILVA, Júlia Marques Carvalho da. Participação em banca de Pedro Henrique Bandeira dos Santos. Um repositório de objetos de aprendizagem para os cursos de ciência da computação e desenvolvimento web com software livre. 2007. (Ciência da Computação) - Universidade do Vale do Itajaí. Produção Alterada: SILVA, Júlia Marques C. da; RAABE, André Luís Alice; ALVES, Adriana Gomes; DAZZI, Rudimar Luis Scaranto; VAHLDICK, A. Participação em banca de Pedro Henrique Bandeira dos Santos. Um repositório para aprendizagem para os cursos de ciência da computação e tecweb com software livre. 2008. (Ciência da Computação) - UNIVALI.

Figura 75. Produção original e alterada do cenário 1h.


das palavras “de objetos de”, das palavras “desenvolvimento web” para “tecweb”, do ano da

produção e abreviação do nome da instituição. Após executar as duas produções (original e


Tabela 15.

Tabela 15. Tabela de resultados do cenário 1h.






A.1.9 Cenário 1i: Participação em banca

O teste i do cenário um é baseado em uma produção de participação em banca julgadora,




88

Produção Original: MOREIRA, Benjamin Grando; SILVA, Júlia Marques Carvalho da; DAZZI, Rudimar Luís Scaranto. Participação em banca de Marlon Kleinschmidt. Mineração de Dados para Avaliação do Perfil de Usuários do Sistema de Informação da Academia da UNIVALI. 2007. (Ciência da Computação) - Universidade do Vale do Itajaí. Produção Alterada: SILVA, Júlia Marques C. da; MOREIRA, Benjamin Grando; DAZZI, Rudimar Luís Scaranto. Participação em banca de Marlon Kleinschmidt. Mineração de Dados para Avaliação de Perfil de Usuários do curso de Sistemas de Informação da UNIVALI. 2006. (Ciência da Computação) - Universidade do Vale do Itajaí.

Figura 76. Produção original e alterada do cenário 1i.


das palavras “Sistema de Informação da Academia” para “curso de Sistemas de Informação” e do

ano da produção. Após executar as duas produções (original e alterada) nas três funções escolhidas,

a comparação gerou o seguinte resultado apresentado na Tabela 16.

Tabela 16. Tabela de resultados do cenário 1i.






A.2 CENÁRIO 2 – USUÁRIO COM MAIS DE 1000 PRODUÇÕES

O cenário dois é baseado em usuários que possuem mais que mil produções cadastradas.

Foram realizados testes para diferentes tipos de produções: participação em bancas de comissões

julgadoras, projeto de pesquisa, artigos em eventos nacionais, orientação de TCC, artigo em evento

internacional, curso de curta duração, participação em banca de mestrado, resumo publicado em

anais de congressos e comissões de avaliação de cursos de graduação e pós-graduação.

A.2.1 Cenário 2a: Participação em Banca

O teste a do cenário dois é baseado em uma produção de participação em banca julgadora,


89



Produção original: RAABE, André Luís Alice. Comissão Científica do Workshop de Informática na Escola - WIE (CSBC 2008). 2008. Sociedade Brasileira de Computação - Porto Alegre. Produção alterada: RAABE, A. L. A. Comissão Científica do Workshop de Informática na Escola. 2008. Sociedade Brasileira de Computação - Porto Alegre.

Figura 77. Produção original e alterada do cenário 2a.

A produção alterada teve as seguintes modificações: alteração no nome do autor e retirada

siglas “WIE (CSBC 2008)”. Após executar as duas produções (original e alterada) nas três funções


Tabela 17. Tabela de resultados do cenário 2a.






A.2.2 Cenário 2b: Artigo em Evento Internacional

O teste b do cenário dois é baseado em uma produção de artigo em evento internacional, que

foi selecionada da base de dados do SAPI e é apresentada na Figura 78, juntamente com uma cópia



90

Produção original: FERNANDES, Anita Maria da Rocha. Congresso internacional sobre lógica aplicada. In: LAPTEC 2002 - Advanced in logic, artificial intelligence and robotics. São Paulo: Universidade SENAC - São Paulo, 2002. Produção alterada: FERNANDES, A. M. R. Congresso Internacional de Lógica Aplicada. In: Advanced in Logic, Artificial Intelligence and Robotics. São Paulo: Universidade SENAC - São Paulo, SP, 2002.

Figura 78. Produção original e alterada do cenário 2b.

A produção alterada teve as seguintes modificações: alteração no nome do altor, alteração da

palavra “sobre lógica aplicada” por “de Lógica Aplicada”, retirada sigla “LAPTEC”, alteração das

palavras “artificial intelligence and robotics” para inicias em maiúsculo e retirada sigla “SP”. Após

executar as duas produções (original e alterada) nas três funções escolhidas, a comparação gerou o

seguinte resultado apresentado na Tabela 18.

Tabela 18. Tabela de resultados do cenário 2b.






A.2.3 Cenário 2c: Artigo em Evento Nacional

O teste c do cenário dois é baseado em uma produção artigo em evento nacional, que foi

selecionada da base de dados do SAPI e é apresentada na Figura 79 , juntamente com uma cópia



91

Produção original: OLDONI, Alisson; FERNANDES, Anita Maria da Rocha; MOREIRA, Benjamin Grando; DETERS, Janice Ines. Desenvolvimento de um agente pedagógico inteligente para um sistema tutor n área da saúde. In: X Congresso Brasileiro de Informática em Saúde, 2006, Florianópolis, SC. Anais do X Congresso Brasileiro de Informática em Saúde. 2006. v.1, 8560391002. Produção alterada: MOREIRA, B. G.; FERNANDES, A. M. R.; OLDONI, A.; DETERS, Janice Ines. Desenvolvimento de um agente pedagógico inteligente para um sistema tutor na área da saúde. In: X Congresso Brasileiro de Informática em Saúde, 2006, Florianópolis, SC. Anais do X Congresso Brasileiro de Informática em Saúde. 2006.

Figura 79. Produção original e alterada do cenário 2c.

A produção alterada teve as seguintes modificações: troca na ordem e alteração dos nomes

dos autores e retirada das palavras “v.1, 8560391002”. Após executar as duas produções (original e


Tabela 19.

Tabela 19. Tabela de resultados do cenário 2c.






A.2.4 Cenário 2d: Curso de Curta Duração

O teste d do cenário dois é baseado em uma produção de curso de curta duração, que foi




92

Produção original: Processamento de Imagens de Satélite. 2002-2002. 4h. Instituição: Comgresso Brasileiro de Computação. CONCLUIDO. Produção alterada: Processamento de Imagens de Satélite. 2002-2002. 4h. Instituição: CBComp. CONCLUIDO.

Figura 80. Produção original e alterada do cenário 2d.

A produção alterada teve as seguintes modificações: alteração das palavras “Congresso

Brasileiro de Computação” para “CBComp”. Após executar as duas produções (original e alterada)

nas três funções escolhidas, a comparação gerou o seguinte resultado apresentado na Tabela 20.

Tabela 20. Tabela de resultados do cenário 2d.






A.2.5 Cenário 2e: Participação em Banca

O teste e do cenário dois é baseado em uma produção de participação em banca de mestrado,




93

Produção original: AZEVEDO, Fernando Mendes de; ARGOUD, Fernanda Isabel Marques; MARINO NETO, José; FERNANDES, Ana Paula Soares; FERNANDES, Anita Maria da Rocha; Hahne, M.N.M.A.. Participação em banca de George Araújo Mendonça. Estudo comparativo de técnicas de redes neurais e análise de variáveis canônicas para detecção automática de complexos K e fusos de sono em EEG. 2007. (Engenharia Elétrica) - Universidade Federal de Santa Catarina. Produção alterada: AZEVEDO, Fernando Mendes de; ARGOUD, Fernanda Isabel Marques; MARINO NETO, José; FERNANDES, Ana Paula Soares; FERNANDES, Anita Maria da Rocha; Hahne, Maria Nazareth M. Angeloni. Participação em banca de George Araújo Mendonça. Estudo comparativo de técnicas de redes neurais e análise de variáveis canônicas para detecção automática de complexos K e fusos de sono em EEG. 2007. (Engenharia Elétrica) - Universidade Federal de Santa Catarina.

Figura 81. Produção original e alterada do cenário 2e.

A produção alterada teve as seguintes modificações: alteração dos nomes dos autores. Após



Tabela 21. Tabela de resultados do cenário 2e.






A.2.6 Cenário 2f: Artigo em Evento Internacional

O teste f do cenário dois é baseado em uma produção de participação artigo em evento

internacional, que foi selecionada da base de dados do SAPI e é apresentada na Figura 82,

juntamente com uma cópia alterada deste mesmo registro, gerado para ser comparado com o

original através das funções de cálculo de similaridade.

94

Produção original: RAABE, André Luís Alice. Indicadores para Produção de Material Didático usando Vídeos através da Web, 1999. Evento: V Congresso Internacional de Engenharia Informática, Buenos Aires. Inst. promotora/financiadora: Universidade de Buenos Aires. Produção alterada: RAABE, A. L. A. Indicadores para Produção de Material Didático usando Vídeos através da Web, 1999. Evento: V CIEI, Buenos Aires, Argentina. Inst. promotora/financiadora: Universidade de Buenos Aires.

Figura 82. Produção original e alterada do cenário 2f.

A produção alterada teve as seguintes modificações: alteração dos nomes dos autores e do

nome do congresso para a sigla “CIEI”. Após executar as duas produções (original e alterada) nas

três funções escolhidas, a comparação gerou o seguinte resultado apresentado na Tabela 22.

Tabela 22. Tabela de resultados do cenário 2f.






A.2.7 Cenário 2g: Resumo em Evento Nacionais

O teste g do cenário dois é baseado em uma produção de resumo publicado em anais de

congresso, que foi selecionada da base de dados do SAPI e é apresentada na Figura 83, juntamente

com uma cópia alterada deste mesmo registro, gerado para ser comparado com o original através

das funções de cálculo de similaridade.

95

Produção original: RAABE, Renate O.; RAABE, André Luís Alice. APREP - Auxílio a Tomada de Decisão no Processo de Recuperação de Praias. In: Anais p.39, Seminário Integrado de Iniciação Científica, Balneário Camboriú. Anais. 2000. v.1, p.39-39. Produção alterada: RAABE, A. L. A..; RAABE, R. O. Auxílio a Tomada de Decisão no Processo de Recuperação de Praias. In: Seminario Integrado de Iniciacao Cientifica, Baln. Camboriú, 2000.

Figura 83. Produção original e alterada do cenário 2g.

A produção alterada teve as seguintes modificações: alteração dos nomes dos autores,

retirada da sigla “APREP” e das palavras “Anais p.39” e abreviação da palavra “Balneário”. Após



Tabela 23. Tabela de resultados do cenário 2g.






A.2.8 Cenário 2h: Artigo em Evento Internacional

O teste h do cenário dois é baseado em uma produção de artigo em evento internacional, que

foi selecionada da base de dados do SAPI e é apresentada na Figura 84, juntamente com uma cópia



96

Produção original: BENITTI, Fabiane Barreto Vavassori; SEÁRA, Everton Flávio Rufino; RAABE, André Luis Alice; SCHLINDWEIN, Luciane Maria. From conception to implantation of an educacional software to an elementary school. In: Avances en informática educativa, 2004, Cárceres. Avances en informática educativa. 2004. 84-7723-65. Produção alterada: SEÁRA, E. F. R.; RAABE, A. L. A. ; BENITTI, F. B. V.; SCHLINDWEIN, L. M. From the conception to the implementation of educating software to elementary school. In: Avances en informática educativa (AIE), 2004, Cárceres.

Figura 84. Produção original e alterada do cenário 2h.


retirada das palavras “84-7723-65” e “an” e inclusão da sigla “AIE”. Após executar as duas

produções (original e alterada) nas três funções escolhidas, a comparação gerou o seguinte resultado


Tabela 24. Tabela de resultados do cenário 2h.






A.2.9 Cenário 2i: Comissão de Avaliação de Cursos

O teste i do cenário dois é baseado em uma produção de comissão de avaliação de cursos de

graduação e pós-graduação, que foi selecionada da base de dados do SAPI e é apresentada na

Figura 85, juntamente com uma cópia alterada deste mesmo registro, gerado para ser comparado

com o original através das funções de cálculo de similaridade.

97

Produção original: DAZZI, R. L. S.; RAABE, André Luís Alice; MARTINS, Luiz Carlos; Heloisa Helena Leal Gonçalves; BENITTI, Fabiane Barreto Vavassori. Comissão de professores para a alteração da matriz curricular do curso de Ciencia da computação, 2008. Produção alterada: DAZZI, Rudimar Luís Scaranto; RAABE, André Luís Alice; MARTINS, Luís Carlos; Heloísa Helena Leal Gonçalves; BENITTI, Fabiane Barreto Vavassori. Comissão de professores para a alteração da matriz curricular do curso de Ciencia da Computação, 2008.

Figura 85. Produção original e alterada do cenário 2i.

A produção alterada teve as seguintes modificações: alteração dos nomes (acentuação e

troca por caixa alta). Após executar as duas produções (original e alterada) nas três funções


Tabela 25. Tabela de resultados do cenário 2i.






A.2.10 Cenário 2j: Artigo em Evento Nacional

O teste j do cenário dois é baseado em uma produção de artigo em evento nacional, que foi




98

Produção original: SEÁRA, Everton Flávio Rufino; BENITTI, Fabiane Barreto Vavassori; RAABE, André Luis Alice; SCHLINDWEIN, Luciane Maria. Da concepção à validação de um cenário virtual 3D para o Ensino Fundamental. In: Congresso da Sociedade Brasileira de Computação (SBC) - Workshop de Informática na Escola (WIE), 2004, Salvador. Anais do SBC 2004/XXIV Congresso da Sociedade Brasileira de Computação. 2004. 8588442949. Produção alterada: SEÁRA, Everton Flávio Rufino; BENITTI, Fabiane Barreto Vavassori; RAABE, André Luis Alice. Da concepção à validação de um cenário virtual 3D para o Ensino Fundamental. In: Congresso da SBC - WIE, 2004, Salvador.

Figura 86. Produção original e alterada do cenário 2j.


alteração do nome do congresso para a sigla “SBC”, retirada das palavras “Workshop de

Informática” e do trecho “Anais do SBC 2004/XXIV Congresso da Sociedade Brasileira de

Computação. 2004. 8588442949”. Após executar as duas produções (original e alterada) nas três

funções escolhidas, a comparação gerou o seguinte resultado apresentado na Tabela 26. Este foi o

único teste os cenários apresentados em que a função não retornou a produção original como

resposta, mas sim o seguinte registro: “SEÁRA, Everton Flávio Rufino; BENITTI, Fabiane Barreto

Vavassori; RAABE, André Luis Alice. A construção de um museu virtual 3D para o Ensino

Fundamental. Infocomp Journal Of Computer Science. Lavras: v.4, n.1, 2005. ISSN: 18074545.”.

Tabela 26. Tabela de resultados do cenário 2j.





obteve similaridade igual a 96% e tempo de execução igual a 52,14 segundos.

99

ANEXOS

I DICIONÁRIO DE DADOS

I.1 ESTRUTURA DAS TABELAS DO SAPI

TABELAS AREA Nome Tipo de Dados PK FK Descrição

ARE_COD NUMBER Sim Código da Área ARE_NOME VARCHAR2(200) Nome da Área ARE_PES_CADASTROU

NUMBER Pessoa que cadastrou a Área

ARE_PES_DELETA NUMBER Pessoa que deletou a Área ARE_INICIO DATE Data de transição inicial da Área ARE_FIM DATE Data de transição final da Área ARE_COD_CNPQ VARCHAR2(30) Código da Área no CNPq AREA_PRODUCAO Nome Tipo de Dados PK FK Descrição

ARE_COD NUMBER Sim Sim Código da Área PRO_COD NUMBER Sim Sim Código da Produção ARP_INICIO DATE Sim Data de transição inicial da relação ARP_PES_CADASTROU

NUMBER Pessoa que cadastrou a relação

ARP_PES_DELETA NUMBER Pessoa que deletou a relação ARP_FIM DATE Data de transição final da relação ARQUIVO Nome Tipo de Dados PK FK Descrição

PES_COD NUMBER Sim A quem pertence esse arquivo SUB_COD NUMBER Sim Código da submissão ARQ_XML CLOB Código XML CENARIO Nome Tipo de Dados PK FK Descrição

CEN_COD NUMBER Sim Código do Cenário CEN_NOME VARCHAR2(50) Nome do Cenário CEN_PES_CADASTROU

NUMBER Pessoa que cadastrou o Cenário

CEN_INICIO DATE Data de transição inicial do Cenário CEN_PES_DELETA NUMBER Pessoa que deletou o Cenário CEN_FIM DATE Data de transição final do Cenário CENARIO_PRODUCAO Nome Tipo de Dados PK FK Descrição

TIP_COD NUMBER Sim Sim Código do Tipo de Produção CEN_COD NUMBER Sim Sim Código do Cenário CEP_PESO FLOAT Peso do Tipo da Produção no Cenário CEP_INICIO DATE Data de transição inicial do peso CEP_FIM DATE Data de transição final do peso CEP_PES_CADASTROU

NUMBER Pessoa que cadastrou o peso

CEP_PES_DELETA NUMBER Pessoa que deletou o peso DOCENTE_PRODUCAO Nome Tipo de Dados PK FK Descrição

PES_COD NUMBER Sim Código de Pessoa

101

DOCENTE_PRODUCAO Nome Tipo de Dados PK FK Descrição

PRO_COD NUMBER Sim Sim Código da Produção DOP_INICIO DATE Sim Data de transição inicial da relação PRO_REFERENCIA VARCHAR2(3000) Referência da Produção DOP_FIM DATE Data de transição final da relação DOP_PES_CADASTROU


DOP_PES_DELETA NUMBER Pessoa que deletou a relação GRUPO Nome Tipo de Dados PK FK Descrição

GRU_COD NUMBER Sim Código do grupo GRU_NOME VARCHAR2(200) Nome do Grupo PES_COD NUMBER Código do responsável pelo Grupo UNICOD NUMBER Código do centro em que o Grupo atua GRU_PES_CADASTROU

NUMBER Pessoa que cadastrou o Grupo

GRU_PES_DELETA NUMBER Pessoa que deletou o Grupo GRU_INICIO DATE Data de transição inicial do Grupo GRU_FIM DATE Data da transição final do Grupo GRU_PARTICIPANTES

NUMBER Número de participantes do Grupo

PRODUCAO Nome Tipo de Dados PK FK Descrição

PRO_COD NUMBER Sim Código da Produção PRO_PES_DELETA NUMBER Pessoa que deletou a Produção PRO_PES_CADASTROU

NUMBER Pessoa que cadastrou a Produção

TIP_COD NUMBER Sim Código do Tipo de Produção PRO_INICIO DATE Data de transição inicial da Produção PRO_FIM DATE Data de transição final da Produção SUB_COD NUMBER Sim Código da Submissão do Currículo em que a

Produção se encontra PRO_VALIDA CHAR(1) Status de validação da Produção:

0 - verificada 1 - Verificada, validada 2 - Em validação ( utilizado até o momento) 3 - Validada

PRO_VALIDA_DOCENTE

NUMBER Docente que solicitou a validação da Produção

PRO_VALIDA_PROPPEC

NUMBER Funcionário da PROPPEC que registrou a validação

PRO_VALIDA_DATA DATE Data da realização da validação TIP_COD_PAI NUMBER Código do Tipo de Produção pai (campo auxiliar

no processo de migração dos sistemas) PRO_VALIDA_ANTIGO

NUMBER Código da Produção referente a tabela de Produções do SAPI antigo.

PRODUCAO_CURSO Nome Tipo de Dados PK FK Descrição

PRO_COD NUMBER Sim Sim Código da Produção CURCOD NUMBER Sim Código do Curso PRC_INICIO DATE Sim Data de transição inicial da relação PRC_PES_CADASTROU


PRC_PES_DELETA NUMBER Pessoa que deletou a relação PRC_FIM DATE Data de transição final da relação PRODUCAO_GRUPO Nome Tipo de Dados PK FK Descrição

PRO_COD NUMBER Sim Sim Código da Produção GRU_COD NUMBER Sim Sim Código do grupo

102

PRODUCAO_GRUPO Nome Tipo de Dados PK FK Descrição

PRG_INICIO DATE Sim Data de transição da relação PRG_PES_CADASTROU


PRG_FIM DATE Data de transição final da relação PRG_PES_DELETA NUMBER Pessoa que deletou a relação RELATORIO Nome Tipo de Dados PK FK Descrição

REL_COD NUMBER Sim Código do Relatório REL_NOME VARCHAR2(50) Nome do Relatório CEN_COD NUMBER Sim Código do Cenário REL_PES_CADASTROU

NUMBER Pessoa que cadastrou o Relatório

REL_INICIO DATE Data de transição inicial do Relatório REL_FIM DATE Data de transição final do Relatório REL_PES_DELETA NUMBER Pessoa que deletou o Relatório REL_ANO_INICIO NUMBER Ano inicial do Relatório REL_ANO_FIM NUMBER Ano final do Relatório REL_UNIVALI CHAR(1) Flag indicando se deve exibir apenas produções

válidas para a instituição ou não: 0 - Todas as produções 1 - Somente as produções válidas para a Univali

RELATORIO_AGRUPA Nome Tipo de Dados PK FK Descrição

REL_COD NUMBER Sim Sim Código do Relatório AGR_ORDEM NUMBER Sim Ordem do agrupamento AGR_DESCRICAO VARCHAR2(15) Item a ser agrupado RELATORIO_AREA Nome Tipo de Dados PK FK Descrição

REL_COD NUMBER Sim Sim Código do Relatório ARE_COD NUMBER Sim Sim Código da Área RELATORIO_CAMPUS Nome Tipo de Dados PK FK Descrição

REL_COD NUMBER Sim Sim Código do Relatório CAMCOD NUMBER Sim Código do Campus RELATORIO_CENTRO Nome Tipo de Dados PK FK Descrição

REL_COD NUMBER Sim Sim Código do Relatório CENCOD NUMBER Sim Código do Centro RELATORIO_CURSO Nome Tipo de Dados PK FK Descrição

REL_COD NUMBER Sim Sim Código do Relatório CURCOD NUMBER Sim Código do Curso RELATORIO_DOCENTE Nome Tipo de Dados PK FK Descrição

PES_COD NUMBER Sim Docentes que selecionados no Relatório REL_COD NUMBER Sim Sim Código do Relatório RELATORIO_GRUPO Nome Tipo de Dados PK FK Descrição

REL_COD NUMBER Sim Sim Código do Relatório GRU_COD NUMBER Sim Sim Código do grupo

103

RELATORIO_PERFIL Nome Tipo de Dados PK FK Descrição

REL_COD NUMBER Sim Sim Código do Relatório PES_COD NUMBER Sim Pessoa que poderá visualizar o Relatório REP_INICIO DATE Sim Data de transição inicial da relação REP_PES_CADASTROU


REP_PES_DELETA NUMBER Pessoa que deletou a relação REP_FIM DATE Data de transição final da relação RELATORIO_TIPO Nome Tipo de Dados PK FK Descrição

REL_COD NUMBER Sim Sim Código do Relatório TIP_COD NUMBER Sim Sim Código do Tipo de Produção RELATORIO_TITULACAO Nome Tipo de Dados PK FK Descrição

REL_COD NUMBER Sim Sim Código do Relatório TIT_COD NUMBER Sim Titulações selecionadas no Relatório SUBMISSAO Nome Tipo de Dados PK FK Descrição

SUB_COD NUMBER Sim Código da submissão SUB_INICIO DATE Data de transição inicial da submissão SUB_FIM DATE Data de transição final da submissão PES_COD NUMBER Código da pessoa na qual a submissão se refere SUB_PES_CADASTROU

NUMBER Pessoa que submeteu o currículo

TIPO_PRODUCAO Nome Tipo de Dados PK FK Descrição

TIP_COD NUMBER Sim Código do Tipo de Produção TIP_COD_PAI NUMBER Sim Código do Tipo de Produção do Pai TIP_NOME VARCHAR2(100) Nome do Tipo de Produção TIP_PES_CADASTROU

NUMBER Pessoa que cadastrou o Tipo de Produção

TIP_INICIO DATE Data de transição inicial do Tipo de Produção TIP_FIM DATE Data de transição final do Tipo de Produção TIP_PES_DELETA NUMBER Pessoa que deletou o Tipo de Produção TIP_COD_ANTIGO NUMBER Código do Tipo de Produção no antigo SAPI

(campo apenas utilizado para conferência durante o processo de migração dos sistemas)

VALOR_ATRIBUTO Nome Tipo de Dados PK FK Descrição

PRO_COD NUMBER Sim Sim Código da Produção VAL_ORDEM NUMBER Sim Ordem de precedência quando vários registros de

um mesmo atributo existem no XML. Ex: ordem dos autores de uma publicação.

VAL_ATRIBUTO VARCHAR2(100) Sim Nome do atributo XML VAL_CONTEUDO VARCHAR2(1000) Conteúdo do atributo XML PES_COD NUMBER Código da pessoa, caso o atributo se refere a uma

pessoa

104

II CÓDIGO FONTE

CREATE OR REPLACE package SIMILARITY is TYPE TABELA IS TABLE OF NUMBER INDEX BY BINARY_INTEGER; FUNCTION Levenshtein (PDS_TEXTO IN VARCHAR2, PDS_STRING IN VARCHAR2) RETURN NUMBER DETERMINISTIC; FUNCTION Hamming (value1 IN VARCHAR2, value2 IN VARCHAR2) RETURN NUMBER; PROCEDURE KMP (t VARCHAR2, p VARCHAR2); FUNCTION jaro(str1_in IN VARCHAR2, str2_in IN VARCHAR2) RETURN NUMBER; FUNCTION AUX_genprefix(p VARCHAR2) RETURN TABELA; FUNCTION andreatta (PDS_TEXTO1 IN OUT varchar2, PDS_TEXTO2 IN OUT varchar2) RETURN NUMBER; FUNCTION andreatta_2 (PDS_TEXTO1 IN varchar2, PDS_TEXTO2 IN varchar2) RETURN NUMBER; FUNCTION andreatta_aux (PDS_TEXTO IN VARCHAR2, PDS_STRING IN VARCHAR2) RETURN NUMBER DETERMINISTIC ; PROCEDURE CARREGA_BASE; PROCEDURE call_jaro(str2_in IN VARCHAR2,pcd_docente NUMBER) ; PROCEDURE call_andreatta(str2_in IN VARCHAR2,pcd_docente NUMBER) ; end SIMILARITY; / create or replace package body SIMILARITY is --x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x PROCEDURE ERRO IS BEGIN raise_application_error(-20001,'ERRO: '||SQLERRM); END; --x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x PROCEDURE SHOW(PDS_TEXTO VARCHAR2) IS BEGIN DBMS_OUTPUT.PUT_LINE(PDS_TEXTO); END; --x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x FUNCTION Hamming (value1 IN VARCHAR2, value2 IN VARCHAR2) RETURN NUMBER IS distance NUMBER; i NUMBER; len NUMBER; BEGIN distance := 0; i := 1; IF(LENGTH(VALUE1) > LENGTH(VALUE2))THEN LEN := LENGTH(VALUE1); ELSE LEN := LENGTH(VALUE2); END IF; IF (value1 is null) or (value2 is null) THEN return null; ELSE

105

WHILE (i <= len) LOOP DBMS_OUTPUT.PUT_LINE(SUBSTR(VALUE1,i,1) || ' / '|| SUBSTR(VALUE2,i,1)); IF(SUBSTR(VALUE1,i,1) <> SUBSTR(VALUE2,i,1))THEN distance := distance + 1; ELSE distance := distance + 0; END IF; i := i + 1; END LOOP; END IF; return distance; END Hamming; --x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x FUNCTION Levenshtein (PDS_TEXTO IN VARCHAR2, PDS_STRING IN VARCHAR2) RETURN NUMBER DETERMINISTIC IS WW_QT_TAM_TEXTO NUMBER := NVL (LENGTH (PDS_TEXTO), 0); WW_QT_TAM_STRING NUMBER := NVL (LENGTH (PDS_STRING), 0); WW_COLUNA_ESQ TABELA; WW_COLUNA_ATUAL TABELA; WW_CUSTO NUMBER := 0; BEGIN IF WW_QT_TAM_TEXTO = 0 THEN RETURN WW_QT_TAM_STRING; ELSIF WW_QT_TAM_STRING = 0 THEN RETURN WW_QT_TAM_TEXTO; ELSE FOR j IN 0 .. WW_QT_TAM_STRING LOOP WW_COLUNA_ESQ(j) := j; --SHOW(WW_COLUNA_ESQ(j)); END LOOP; FOR i IN 1.. WW_QT_TAM_TEXTO LOOP WW_COLUNA_ATUAL(0) := i; SHOW('--------------'); SHOW ('*** '||WW_COLUNA_ATUAL(0)); SHOW('--------------'); FOR j IN 1 .. WW_QT_TAM_STRING LOOP IF SUBSTR (PDS_TEXTO, i, 1) = SUBSTR (PDS_STRING, j, 1) THEN WW_CUSTO := 0; ELSE WW_CUSTO := 1; END IF; WW_COLUNA_ATUAL(j) := LEAST (WW_COLUNA_ATUAL(j-1) + 1, WW_COLUNA_ESQ(j) + 1, WW_COLUNA_ESQ(j-1) + WW_CUSTO); SHOW(' CIMA: '||WW_COLUNA_ATUAL(J-1)); SHOW(' LADO: '||WW_COLUNA_ESQ(J)); SHOW(' DIAG: ' ||WW_COLUNA_ESQ(J-1) || ' --- CUSTO: ' ||WW_CUSTO); SHOW(WW_COLUNA_ATUAL(j)); END LOOP; FOR j IN 0 .. WW_QT_TAM_STRING LOOP WW_COLUNA_ESQ(j) := WW_COLUNA_ATUAL(j); END LOOP; END LOOP; END IF; RETURN WW_COLUNA_ATUAL(WW_QT_TAM_STRING); END Levenshtein; --x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x

106

PROCEDURE KMP (t VARCHAR2, p VARCHAR2) IS a TABELA; q NUMBER := 0; n NUMBER := length(T); m NUMBER := length(P); sim NUMBER := 0; BEGIN a := AUX_genprefix(p); for i IN 0 .. n LOOP while(q > 0 AND SUBSTR(p,q+1,1) <> SUBSTR(t,i+1,1)) loop q := a(q-1); end loop; if (SUBSTR(p,q+1,1) = SUBSTR(t,i+1,1)) then q := q + 1; sim := sim + 1; else show(sim); sim := 0; end if; if (q = m) then show ('String igual na posicao: ' || to_char(i - m + 1)); q := a(q-1); end if; end loop; END KMP; --x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x FUNCTION jaro(str1_in IN VARCHAR2, str2_in IN VARCHAR2) RETURN NUMBER IS str1 VARCHAR2(4000); str2 VARCHAR2(4000); len_str1 PLS_INTEGER; len_str2 PLS_INTEGER; swap_len PLS_INTEGER; max_len PLS_INTEGER; m PLS_INTEGER; i PLS_INTEGER; j PLS_INTEGER; f PLS_INTEGER; l PLS_INTEGER; tr NUMBER := 0; a1 VARCHAR2(4000); a2 VARCHAR2(4000); swap_str VARCHAR2(4000); TYPE bool_list_t IS TABLE OF BOOLEAN INDEX BY PLS_INTEGER; f1 bool_list_t; f2 bool_list_t; wcd NUMBER; wrd NUMBER; wtr NUMBER; common NUMBER := 0; jaro_value NUMBER := 0; -- Local function -- clean_string normalizes the data as of COMPANY -> CO or CORPORATION -> CORP. Example: FUNCTION clean_string(p_str1 IN VARCHAR2) RETURN VARCHAR2 IS ret_value VARCHAR2(4000) := p_str1; BEGIN ret_value := REPLACE(ret_value, '.', ''); ret_value := REPLACE(ret_value, ',', ''); ret_value := REPLACE(ret_value, '-', ''); ret_value := REPLACE(ret_value, ';', ''); ret_value := REPLACE(ret_value, ':', ''); ret_value := REPLACE(ret_value, 'Á', 'A');

107

ret_value := REPLACE(ret_value, 'É', 'E'); ret_value := REPLACE(ret_value, 'Í', 'I'); ret_value := REPLACE(ret_value, 'Ó', 'O'); ret_value := REPLACE(ret_value, 'Ú', 'U'); ret_value := REPLACE(ret_value, ' COMPANY ', ' CO '); ret_value := REPLACE(ret_value, ' CORPORATION ', ' CO '); RETURN ret_value; END clean_string; BEGIN str1 := clean_string(str1_in); str2 := clean_string(str2_in); len_str1 := LENGTH(str1); len_str2 := LENGTH(str2); IF len_str1 > len_str2 THEN swap_len := len_str2; len_str2 := len_str1; len_str1 := swap_len; swap_str := str1; str1 := str2; str2 := swap_str; END IF; max_len := len_str2; FOR i IN 1 .. len_str1 LOOP f1(i) := FALSE; END LOOP; FOR j IN 1 .. len_str2 LOOP f2(j) := FALSE; END LOOP; m := ROUND((max_len / 2) - 1); FOR i IN 1 .. len_str1 LOOP a1 := SUBSTR(str1, i, 1); IF m >= i THEN f := 1; l := i + m; ELSE f := i - m; l := i + m; END IF; IF l > max_len THEN l := max_len; END IF; FOR j IN f .. l LOOP a2 := SUBSTR(str2, j, 1); IF (a2 = a1) AND (f2(j) = FALSE) THEN common := common + 1; f1(i) := TRUE; f2(j) := TRUE; GOTO linea_exit; END IF; END LOOP; -- j <<linea_exit>> NULL; -- Add NULL statement to avoid error END LOOP; -- i

108

l := 1; FOR i IN 1 .. len_str1 LOOP IF f1(i) THEN FOR j IN l .. len_str2 LOOP IF f2(j) THEN l := j + 1; a1 := SUBSTR(str1, i, 1); a2 := SUBSTR(str2, j, 1); IF a1 <> a2 THEN tr := tr + 0.5; END IF; GOTO j_loop; END IF; END LOOP; -- j <<j_loop>> NULL; -- Add NULL statement to avoid error END IF; END LOOP; -- i wcd := 1 / 3; wrd := 1 / 3; wtr := 1 / 3; IF common <> 0 THEN jaro_value := wcd * common / len_str1 + wrd * common / len_str2 + wtr * (common - tr) / common; END IF; RETURN NVL(jaro_value,0); EXCEPTION WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE('EXCEPTION IN jaro - ' || SQLCODE || ': ' || SQLERRM); DBMS_OUTPUT.PUT_LINE('Error stack at top level:'); DBMS_OUTPUT.PUT_LINE(dbms_utility.format_error_backtrace); RETURN jaro_value; END jaro; --x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x --x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x FUNCTION AUX_genprefix(p VARCHAR2) RETURN TABELA IS a TABELA; m NUMBER ; k NUMBER := 0; BEGIN m := length(p); a(0) := 0; for q in 1 .. m-1 loop while (k > 0 AND SUBSTR(P,k+1,1) <> SUBSTR(p,q+1,1)) loop k := a(k-1); end loop; if (SUBSTR(p,k+1,1) = SUBSTR(p,q+1,1)) then k := k + 1; end if; a(q) := k; --show(a(q)); end loop; return a;

109

END AUX_genprefix; --x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x FUNCTION TONUM(PDS_LETRA VARCHAR2)RETURN NUMBER IS PNR_AUX NUMBER; BEGIN PNR_AUX := ASCII(PDS_LETRA); RETURN PNR_AUX; END; FUNCTION RABINKARP(str1_in IN VARCHAR2, str2_in IN VARCHAR2, d NUMBER, q NUMBER) RETURN NUMBER IS M NUMBER; N NUMBER; P NUMBER := 0; H NUMBER := 0; I NUMBER := 0; id_found BOOLEAN := FALSE; qt_cnt NUMBER; BEGIN M := LENGTH(STR1_IN); N := LENGTH(STR2_IN); LOOP EXIT WHEN I < M; p := trunc((d*p + tonum(substr(str1_in,i,1))) / q); h := trunc((d*h + tonum(substr(str2_in,i,1))) / q); FOR W IN 0..N-M LOOP IF (p = h) then id_found := true; FOR j IN 0..M-1 LOOP IF (substr(str1_in,j,1) <> substr(str2_in,i+j,1))THEN id_found := false; exit; ELSE qt_cnt := nvl(qt_cnt,0) + 1; END IF; END LOOP; IF (id_found) THEN return qt_cnt; END IF; END IF; IF (i<n-m) THEN h := (d*(q+h-trunc((tonum(substr(STR1_IN,i,1))) / q)) + trunc(tonum(substr(STR1_IN,i+m,1))) / q); END IF; RETURN qt_cnt; END LOOP; I := I + 1; END LOOP; END; FUNCTION REP(PDS_TEXTO VARCHAR2) RETURN VARCHAR2 IS TAUX VARCHAR2(4000); WW_RET VARCHAR2(4000); BEGIN PDS_AUX := lower(PDS_TEXTO); PDS_AUX := REPLACE(PDS_AUX,',',''); PDS_AUX := REPLACE(PDS_AUX,';',''); PDS_AUX := REPLACE(PDS_AUX,'.',''); PDS_AUX := REPLACE(PDS_AUX,')',' '); PDS_AUX := REPLACE(PDS_AUX,'(',' '); PDS_AUX := REPLACE(PDS_AUX,'á','a'); PDS_AUX := REPLACE(PDS_AUX,'é','e'); PDS_AUX := REPLACE(PDS_AUX,'í','i'); PDS_AUX := REPLACE(PDS_AUX,'ó','o'); PDS_AUX := REPLACE(PDS_AUX,'ú','u'); PDS_AUX := REPLACE(PDS_AUX,'â','a'); PDS_AUX := REPLACE(PDS_AUX,'ê','e'); PDS_AUX := REPLACE(PDS_AUX,'ô','o'); PDS_AUX := REPLACE(PDS_AUX,'ã','a'); PDS_AUX := REPLACE(PDS_AUX,'õ','o');

110

PDS_AUX := REPLACE(PDS_AUX,'ç','c'); PDS_AUX := REPLACE(PDS_AUX,'univali','universidade do vale do itajai');*/ RETURN PDS_AUX; END; FUNCTION andreatta (PDS_TEXTO1 IN OUT varchar2, PDS_TEXTO2 IN OUT varchar2) RETURN NUMBER IS WW_DS_AUX VARCHAR2(500); WW_DS_AUX2 VARCHAR2(500); WW_DS_AUX3 VARCHAR2(500); WW_ID_POS NUMBER(3); WW_QT_PALAVRAS NUMBER(3) := 0; WW_QT_CERTAS NUMBER(3) := 0; WW_PR_SIM NUMBER(10,4); CURSOR C1 IS SELECT * FROM AUXILIAR; CURSOR C2 IS SELECT COUNT(1) FROM AUXILIAR; BEGIN PDS_TEXTO1 := PDS_TEXTO1 || ' @@@@@ '; PDS_TEXTO2 := PDS_TEXTO2 || ' @@@@@ '; delete from auxiliar; WW_DS_AUX := lower(PDS_TEXTO2); WW_DS_AUX := REP(WW_DS_AUX); WW_DS_AUX3 := lower(PDS_TEXTO1); WW_DS_AUX3 := REP(WW_DS_AUX3); LOOP WW_DS_AUX2 := SUBSTR(WW_DS_AUX,1,INSTR(WW_DS_AUX,' ')); EXIT WHEN trim(WW_DS_AUX2) = '@@@@@'; WW_DS_AUX := SUBSTR(WW_DS_AUX,INSTR(WW_DS_AUX,' ')+1,LENGTH(WW_DS_AUX)); insert into auxiliar values (trim(ww_ds_aux2),0); END LOOP; DELETE FROM AUXILIAR WHERE LENGTH(DS_AUX) <= 2 or ds_aux is null; FOR R1 IN C1 LOOP WW_ID_POS := INSTR(WW_DS_AUX3,R1.DS_AUX||' '); IF(WW_ID_POS <= 0)THEN WW_ID_POS := INSTR(WW_DS_AUX3,' '||R1.DS_AUX); END IF; IF(WW_ID_POS > 0)THEN WW_QT_CERTAS := WW_QT_CERTAS + 1; ELSE SHOW('================'||R1.DS_AUX); END IF; END LOOP; OPEN C2; FETCH C2 INTO WW_QT_PALAVRAS; CLOSE C2; SHOW('PALAVRAS: '||WW_QT_PALAVRAS); SHOW('CERTAS: '||WW_QT_CERTAS); WW_PR_SIM := (100 * WW_QT_CERTAS) / WW_QT_PALAVRAS; SHOW('SIMIRALIDADE: '||WW_PR_SIM); commit; RETURN WW_PR_SIM; END;

111

FUNCTION andreatta_2 (PDS_TEXTO1 IN varchar2, PDS_TEXTO2 IN varchar2) RETURN NUMBER IS WW_DS_AUX VARCHAR2(4000); WW_DS_AUX2 VARCHAR2(4000); WW_DS_AUX3 VARCHAR2(4000); WW_QT_PALAVRAS NUMBER(10) := 0; WW_QT_CERTAS NUMBER(10) := 0; WW_PR_SIM NUMBER(15,7); WW_ID_ACHOU NUMBER(1); CURSOR C1 IS SELECT * FROM AUXILIAR; CURSOR C3(PDS_STRING VARCHAR2) IS SELECT DISTINCT 1 FROM AUXILIAR_2 WHERE DS_AUX = PDS_STRING; CURSOR C2 IS SELECT COUNT(1) FROM AUXILIAR; V_T1 VARCHAR2(4000); V_T2 VARCHAR2(4000); BEGIN V_T1 := PDS_TEXTO1 || ' @@@@@ '; V_T2 := PDS_TEXTO2 || ' @@@@@ '; execute immediate('truncate table auxiliar'); execute immediate('truncate table auxiliar_2'); commit; WW_DS_AUX := REP(V_T2); WW_DS_AUX3 := REP(V_T1); LOOP WW_DS_AUX2 := SUBSTR(WW_DS_AUX,1,INSTR(WW_DS_AUX,' ')); EXIT WHEN trim(WW_DS_AUX2) = '@@@@@'; WW_DS_AUX := SUBSTR(WW_DS_AUX,INSTR(WW_DS_AUX,' ')+1,LENGTH(WW_DS_AUX)); begin insert into auxiliar values (trim(ww_ds_aux2),0); exception when others then raise_application_error('-20158','Erro insert 1: '||sqlerrm); end; commit; END LOOP; LOOP WW_DS_AUX2 := SUBSTR(WW_DS_AUX3,1,INSTR(WW_DS_AUX3,' ')); EXIT WHEN trim(WW_DS_AUX2) = '@@@@@'; WW_DS_AUX3 := SUBSTR(WW_DS_AUX3,INSTR(WW_DS_AUX3,' ')+1,LENGTH(WW_DS_AUX3)); begin insert into auxiliar_2 values (trim(ww_ds_aux2),0); exception when others then raise_application_error('-20145','Erro insert 2: '||sqlerrm); end; commit; END LOOP; BEGIN DELETE FROM AUXILIAR WHERE LENGTH(DS_AUX) <= 2 or ds_aux is null; DELETE FROM AUXILIAR_2 WHERE LENGTH(DS_AUX) <= 2 or ds_aux is null; exception when others then

112

raise_application_error('-20854','Erro DEL 1: '||sqlerrm); end; commit; FOR R1 IN C1 LOOP WW_ID_ACHOU := 0; OPEN C3(R1.DS_AUX); FETCH C3 INTO WW_ID_ACHOU; CLOSE C3; IF(NVL(WW_ID_ACHOU,0) = 1)THEN WW_QT_CERTAS := WW_QT_CERTAS + 1; END IF; END LOOP; OPEN C2; FETCH C2 INTO WW_QT_PALAVRAS; CLOSE C2; WW_PR_SIM := (100 * WW_QT_CERTAS) / WW_QT_PALAVRAS; commit; RETURN WW_PR_SIM; END; FUNCTION andreatta_aux (PDS_TEXTO IN VARCHAR2, PDS_STRING IN VARCHAR2) RETURN NUMBER DETERMINISTIC IS WW_QT_TAM_TEXTO NUMBER := NVL (LENGTH (PDS_TEXTO), 0); WW_QT_TAM_STRING NUMBER := NVL (LENGTH (PDS_STRING), 0); WW_COLUNA_ESQ TABELA; WW_COLUNA_ATUAL TABELA; WW_CUSTO NUMBER := 0; BEGIN IF WW_QT_TAM_TEXTO = 0 THEN RETURN WW_QT_TAM_STRING; ELSIF WW_QT_TAM_STRING = 0 THEN RETURN WW_QT_TAM_TEXTO; ELSE FOR j IN 0 .. WW_QT_TAM_STRING LOOP WW_COLUNA_ESQ(j) := j; END LOOP; FOR i IN 1.. WW_QT_TAM_TEXTO LOOP WW_COLUNA_ATUAL(0) := i; FOR j IN 1 .. WW_QT_TAM_STRING LOOP IF SUBSTR (PDS_TEXTO, i, 1) = SUBSTR (PDS_STRING, j, 1) THEN WW_CUSTO := 0; ELSE WW_CUSTO := 1; END IF; WW_COLUNA_ATUAL(j) := LEAST (WW_COLUNA_ATUAL(j-1) + 1, WW_COLUNA_ESQ(j) + 1, WW_COLUNA_ESQ(j-1) + WW_CUSTO); END LOOP; FOR j IN 0 .. WW_QT_TAM_STRING LOOP WW_COLUNA_ESQ(j) := WW_COLUNA_ATUAL(j); END LOOP; END LOOP; END IF; IF(WW_QT_TAM_TEXTO > WW_QT_TAM_STRING)THEN RETURN 1 - (WW_COLUNA_ATUAL(WW_QT_TAM_STRING) / WW_QT_TAM_TEXTO); ELSE

113

RETURN 1 - (WW_COLUNA_ATUAL(WW_QT_TAM_STRING) / WW_QT_TAM_STRING); END IF; END andreatta_aux; PROCEDURE CARREGA_BASE IS V_LINHA VARCHAR2(4000) := ''; V_ARQUIVO UTL_FILE.FILE_TYPE; V1 VARCHAR2(4000); V2 VARCHAR2(4000); V3 VARCHAR2(4000); V4 VARCHAR2(4000); BEGIN V_ARQUIVO := UTL_FILE.FOPEN('TCC', 'B.csv', 'R'); DELETE FROM PRODUCAO_DOCENTE; LOOP Begin UTL_FILE.GET_LINE(V_ARQUIVO, V_LINHA); V_LINHA := V_LINHA ||';'; /******************************************/ V1 := SUBSTR(V_LINHA, 1+1, INSTR(V_LINHA,'";')-2 ); V_LINHA := SUBSTR(V_LINHA, INSTR(V_LINHA,'";')+2, LENGTH(V_LINHA) ); /******************************************/ V2 := SUBSTR(V_LINHA, 1+1, INSTR(V_LINHA,'";')-2 ); V_LINHA := SUBSTR(V_LINHA, INSTR(V_LINHA,'";')+2, LENGTH(V_LINHA) ); /******************************************/ V3 := SUBSTR(V_LINHA, 1+1, INSTR(V_LINHA,'";')-2 ); V_LINHA := SUBSTR(V_LINHA, INSTR(V_LINHA,'";')+2, LENGTH(V_LINHA) ); /******************************************/ V4 := SUBSTR(V_LINHA, 1+1, INSTR(V_LINHA,'";')-2 ); V_LINHA := SUBSTR(V_LINHA, INSTR(V_LINHA,'";')+2, LENGTH(V_LINHA) ); /******************************************/ INSERT INTO PRODUCAO_DOCENTE VALUES (V1,V3,V2,V4); Exception when no_data_found then UTL_FILE.FCLOSE(V_ARQUIVO); exit; when others then show(V_LINHA); End; COMMIT; END LOOP;

114

COMMIT; END; PROCEDURE call_jaro(str2_in IN VARCHAR2,pcd_docente NUMBER) IS WW_PR_SIM NUMBER(15,7); WW_PR_SIM_ANT NUMBER(15,7); WW_MAIOR NUMBER(15,7); WW_CD_SEQ NUMBER(10); WW_DS_PROD VARCHAR2(4000); CURSOR C_PROD(PCD_DOC NUMBER) IS SELECT * FROM PRODUCAO_DOCENTE P WHERE P.CD_DOCENTE = PCD_DOC and p.ds_producao is not null ; BEGIN FOR R1 IN C_PROD(pcd_docente) LOOP WW_PR_SIM := jaro(r1.ds_producao,str2_in); IF(NVL(WW_PR_SIM,0) > NVL(WW_MAIOR,0) and WW_PR_SIM <= 100)THEN WW_MAIOR := WW_PR_SIM; WW_DS_PROD := R1.DS_PRODUCAO; WW_CD_SEQ := R1.NR_SEQUENCIA; END IF; END LOOP; SHOW(WW_MAIOR); SHOW(WW_DS_PROD); show(WW_CD_SEQ); EXCEPTION WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE('EXCEPTION IN jaro - ' || SQLCODE || ': ' || SQLERRM); DBMS_OUTPUT.PUT_LINE('Error stack at top level:'); DBMS_OUTPUT.PUT_LINE(dbms_utility.format_error_backtrace); END; PROCEDURE call_andreatta(str2_in IN VARCHAR2,pcd_docente NUMBER) IS WW_PR_SIM NUMBER(15,7); WW_PR_SIM_ANT NUMBER(15,7); WW_MAIOR NUMBER(15,7); WW_CD_SEQ NUMBER(10); WW_DS_PROD VARCHAR2(4000); wds_aux1 varchar2(4000); wds_aux2 varchar2(4000); CURSOR C_PROD(PCD_DOC NUMBER) IS SELECT p.nr_sequencia, p.cd_producao, p.cd_docente, replace(p.ds_producao,'ê','e') ds_producao FROM PRODUCAO_DOCENTE P WHERE P.CD_DOCENTE = PCD_DOC and p.ds_producao is not null and p.nr_sequencia = 3300 ; BEGIN wds_aux2 := str2_in; FOR R1 IN C_PROD(pcd_docente) LOOP wds_aux1 := rep(r1.ds_producao); WW_PR_SIM := andreatta_2(rep(wds_aux1),rep(wds_aux2)); IF(NVL(WW_PR_SIM,0) > NVL(WW_MAIOR,0) and WW_PR_SIM <= 100)THEN

115

WW_MAIOR := WW_PR_SIM; WW_DS_PROD := R1.DS_PRODUCAO; WW_CD_SEQ := R1.NR_SEQUENCIA; END IF; END LOOP; SHOW(WW_MAIOR); SHOW(WW_DS_PROD); SHOW( WW_CD_SEQ); EXCEPTION WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE('EXCEPTION IN jaro - ' || SQLCODE || ': ' || SQLERRM); DBMS_OUTPUT.PUT_LINE('Error stack at top level:'); DBMS_OUTPUT.PUT_LINE(dbms_utility.format_error_backtrace); END; end SIMILARITY; /

UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE …siaibib01.univali.br/pdf/Rodrigo Andreatta da...

Documents

Transcript of UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE …siaibib01.univali.br/pdf/Rodrigo Andreatta da...