um método de análise semântica de consultas com palavras

UNIVERSIDADE FEDERAL DE GOIÁS

INSTITUTO DE INFORMÁTICA

MARIANA SOLLER RAMADA

Um Método de Análise Semântica deConsultas com Palavras-chave para

acesso a Informações Armazenadas emMúltiplos Bancos de Dados

Goiânia2013




Dissertação apresentada ao Programa de Pós–Graduação doInstituto de Informática da Universidade Federal de Goiás,como requisito parcial para obtenção do título de Mestre emMestrado em Ciência da Computação.

Área de concentração: Banco de Dados.

Orientador: Prof. Dr. João Carlos da Silva

Goiânia2013




Dissertação defendida no Programa de Pós–Graduação do Instituto deInformática da Universidade Federal de Goiás como requisito parcialpara obtenção do título de Mestre em Mestrado em Ciência da Compu-tação, aprovada em 26 de Fevereiro de 2013, pela Banca Examinadoraconstituída pelos professores:

Prof. Dr. João Carlos da SilvaInstituto de Informática – UFG

Presidente da Banca

Prof. Dr. Thierson Couto RosaInstituto de Informática – UFG

Profa. Dra. Mirella Moura MoroDepartamento de Ciência da Computação – UFMG

Todos os direitos reservados. É proibida a reprodução total ou parcial dotrabalho sem autorização da universidade, do autor e do orientador(a).

Mariana Soller Ramada

Graduou-se em Ciência da Computação na UFG - Universidade Federal deGoiás. Durante sua graduação, foi estagiária do Centro de Recurso Computa-cionais (Cercomp) da UFG. Durante o Mestrado, foi bolsista REUNI e mo-nitora no Instituto de Informática na disciplina Banco de Dados do curso deCiência da Computação. Atualmente é Analista de Tecnologia da Informaçãodo Instituto de Informática da Universidade Federal de Goiás.

Aos meus pais

Agradecimentos

Primeiramente, agradeço ao meu pai e minha mãe que acreditaram e investiramem mim, dando todo o suporte e educação e não medindo esforços para que eu chegasseonde estou agora. Ao meu irmão Marcelo que é um exemplo de pessoa e aluno, e umdos principais motivos pelo qual eu decidi fazer o mestrado. Agradeço ao meu namoradoMurilo, pelo carinho, dedicação, paciência, incentivo e principalmente por sua capacidadede me trazer paz na correria de cada semestre.

Agradeço também ao professor Dr. João Carlos que desempenhou um papelimensamente importante em minha vida acadêmica, desde a graduação quando lecionou amatéria de Banco de Dados, descobrindo então minha paixão pela área, até a monografiade conclusão do curso sob sua orientação. Agradeço principalmente pela insistência a qualme levou a fazer o mestrado e pela confiança em mim depositada. Agradeço também peladisponibilidade, pela paciência, pelas correções, pelos seus conhecimentos repassadosdurante todo o desenvolvimento deste trabalho e pela oportunidade de ser monitora dadisciplina de Banco de Dados, a qual me proporcionou grande satisfação e aprendizagem.

Ao professor Dr. Plínio que foi imprescindível para este trabalho. Sempre dis-posto a me atender, mesmo sem marcar horário, e gastava horas de seus dias discutindoas próximas tarefas a serem feitas durante a implementação, sanando dúvidas e levan-tando novas ideias que agregaram muito valor a este trabalho. Obrigada pelas reuniõesesclarecedoras e principalmente motivadoras, e também pela preocupação, afinal comovocê mesmo dizia: “Você não se preocupa porque já tem gente se preocupando por vocêné?”. Obrigada também pela correção do texto, pelas sugestões, melhorias, pelo tempodedicado e pela boa vontade de me ajudar a concluir esse trabalho.

Aos colegas de trabalho que muitas vezes deixaram de lado seus afazeres e meajudaram durante o desenvolvimento deste trabalho. Em especial ao Danillo, pela ajudana implementação, com algumas dicas e melhorias; e ao Afonso, pela ajuda na escrita dotexto.

Aos colegas do curso pela convivência, estudo, alegrias, tristezas e dores com-partilhadas. Em especial ao Alison que sempre esteve acompanhando meu trabalho, suge-rindo ideias, discutindo problemas e soluções; a Elisabete que sempre foi solicita respon-dendo meus e-mails, enviando-me seu material e sanando minhas inúmeras dúvidas; e ao

Adriano, Roussian, Douglas e Lucas, com vocês as pausas entre um parágrafo e outro deprodução se tornaram mais prazerosas e proveitosas.

Aos meus amigos e familiares que apesar da distância estiveram torcendo eapoiando.

Ao REUNI pelo apoio financeiro.E por fim, a todos que direta ou indiretamente me ajudaram a concretizar mais

esta etapa da minha vida.

“Você nunca sabe que resultados virão da sua ação. Mas se você não fizernada, não existirão resultados.”

Mahatma Gandhi

Resumo

Ramada, Mariana Soller. Um Método de Análise Semântica de Consultascom Palavras-chave para acesso a Informações Armazenadas em MúltiplosBancos de Dados. Goiânia, 2013. 107p. Dissertação de Mestrado. Instituto deInformática, Universidade Federal de Goiás.

A Web representa o principal canal de circulação de informações na sociedade atual.Essas informações estão dispersas nos mais diversos meios de armazenamento, fazendo-se necessário uma interface de recuperação. A técnica de consulta com palavras-chave,por ser simples e eficaz, mostrou-se ideal para este tipo de necessidade e tornou-se entãoo padrão de interação entre o usuário e a Web.Contudo, a maioria das informações da Web encontra-se armazenada em bancos de dadosrelacionais, e tais repósitorios oferecem suporte limitado para a pesquisa com palavras-chave. Para se realizar consultas em banco de dados relacionais é necessário o conhe-cimento das estruturas de armazenamento e da sintaxe de uma linguagem estruturada,conhecimentos os quais não são familiares para a maioria dos usuários comuns.Neste sentido, o propósito deste trabalho é apresentar um método para realizar consultascom palavras-chave em banco de dados relacionais, a fim de eliminar a necessidade desteconhecimento prévio e permitir uma recuperação simplificada dos dados dos múltiplosbancos de dados disponíveis na Web.

Palavras–chave

Consulta com palavras-chave, Banco de dados relacionais, Semântica

Abstract

Ramada, Mariana Soller. An Analysis Semantic Method of Keyword Queriesover Multiple Databases. Goiânia, 2013. 107p. MSc. Dissertation. Instituto deInformática, Universidade Federal de Goiás.

Information flows mainly through the Web in the present society. This informationis scattered and stored in different data storages, which requires an access interfaceto retrieve it. Keyword query proved to be a simple and effective way to access theinformation, becoming the standard user-Web interaction.However, most Web information is stored in relational databases, and such repositoriesoffer limited support for keyword queries. To perform queries in relational databases isnecessary to know the data schema and the syntax of a structured query language, whichare not familiar to most of ordinary users.In this sense, the purpose of this paper is to present a method for performing keywordqueries in relational databases in order to eliminate the need of this prior knowledge, andenable a simplified recovery of data from multiple databases available on the Web.

Keywords

Keyword query, Relational database, Semantics.

Sumário

Lista de Figuras 12

Lista de Tabelas 13

Lista de Algoritmos 15

Lista de Códigos de Programas 16

1 Introdução 171.1 Contexto e Motivação 171.2 Objetivos 181.3 Principais Problemas 201.4 Organização do Texto 21

2 Trabalhos Relacionados 22

3 Contexto e Arquitetura para o Método Proposto 263.1 Contexto 263.2 Arquitetura 30

3.2.1 Pré-processamento 31Verificação de Função Agregada/Ordenação/Valores Compostos 32Expansão da consulta 33

3.2.2 Processamento da consulta 34Identificação dos bancos de dados relevantes 34Ranking dos bancos de dados relevantes 35Mapeamento 36Execução 37Ranking dos resultados 38

3.3 Considerações Finais 38

4 Análise Semântica da Consulta 394.1 Definição do problema 394.2 Análise Semântica segundo a Keymantic 41

4.2.1 Cálculo dos pesos intrínsecos (Passo 1) 43Cálculo dos pesos intrínsecos dos termos de esquema do banco de dados 44Cálculo dos pesos intrínsecos dos termos de valor do banco de dados 44

4.2.2 Seleção dos Melhores Mapeamentos para os termos de esquema (Passo 2) 46Processo de Seleção dos Melhores Mapeamentos 47

4.2.3 Contextualização de VW e Seleção dos Melhores Mapeamentos para os

termos de valor (Passo 3) 49Regras e Processo de Contextualização 51

4.2.4 Geração das Configurações (Passo 4) 544.2.5 Geração das Interpretações (Passo 5) 54

4.3 Consideração Finais 55

5 Contribuições à Analise Semântica 565.1 Limitações da Keymantic 565.2 Modificações à abordagem da Keymantic 575.3 Considerações Finais 64

6 Aplicação do Método Proposto 666.1 Estudos de Caso 66

6.1.1 Estudo de Caso - Funções Agregadas e Ordenação 676.1.2 Estudo de Caso - Valores Compostos 77

6.2 Comparação com a Keymantic 826.2.1 Suposições à implementação Keymantic 826.2.2 Exemplo selecionado para Comparação 83

Cálculo dos pesos intrínsecos (Passo 1) 84Seleção dos Melhores Mapeamentos para os termos de esquema (Passo 2) 85Contextualização de VW e Seleção dos Melhores Mapeamentos para os

termos de valor (Passo 3) 87Geração das Configurações (Passo 4) 88Geração das Interpretações (Passo 5) 89Impacto das Modificações Internas à Keymantic 89Ranking dos resultados 91


7 Conclusão 947.1 Contribuições 947.2 Trabalhos Futuros 967.3 Produção Bibliográfica 97

Referências Bibliográficas 98

A Estrutura da Tabela de Metadados para Exposição (TME) 102

B Banco de dados COMPANY 103B.1 Requisitos de Dados em Forma Textual 103B.2 Esquema Conceitual 104B.3 Esquema Lógico 105B.4 Esquema Físico 106

Lista de Figuras

3.1 Arquitetura do método proposto (inspirado em [28]) 303.2 Banco de dados COMPANY (retirado de [8]) 31

(a) Esquema lógico do banco de dados COMPANY com suas restriçõesde integridade referencial. 31

(b) Fração dos dados do banco de dados COMPANY. 31

4.1 Mapeamento das palavras-chave (retirado de [3]) 42

5.1 Processo de Mapeamento com as etapas modificadas em destaque 58

6.1 Número de configurações e interpretações geradas por ambos os sitemas 90(a) Número de configurações geradas por ambos os sistemas 90(b) Número interpretações geradas por ambos os sistemas 90

6.2 Métrica de precisão para ambos os sistemas 91(a) 91(b) 91

6.3 Gráfico MRR-Tamanho da consulta (inspirado em [10]) 92

B.1 Diagrama de esquema ER para o banco de dados COMPANY (retiradode [8]) 104

B.2 Esquema lógico do banco de dados COMPANY (retirado de [8]) 106

Lista de Tabelas

3.1 Atributos da Tabela de Metadados para Exposição (TME) [20] 283.2 Informações da Tabela de Metadados para Exposição(TME) do banco de

dados COMPANY (inspirado em [20]) 35

4.1 Matriz de peso com a submatrizes SW (claro) e VW (escuro) (retirado de[4]) 43

4.2 Pesos intrínsecos da Submatriz SW (inspirado em [4]) 444.3 Pesos intrínsecos da Submatriz VW (inspirado em [4]) 464.4 Mapeamento para a consulta “employees dependent relationship” 474.5 Primeira matriz gerada a partir do mapeamento da Tabela 4.4 494.6 Segunda matriz gerada a partir do mapeamento da Tabela 4.4 494.7 Terceira matriz gerada a partir do mapeamento da Tabela 4.4 49

5.1 Mapeamento onde todas as palavras-chave são mapeadas para termosde esquema 61

5.2 Mapeamento parcial das palavras-chave para termos de esquema 625.3 Mapeamento parcial das palavras-chave para termos de valor 625.4 Mapeamento considerando a proximidade entre as palavras-chave 64

6.1 Pesos intrínsecos da Submatriz SW (consulta “quantity employees foreach department order by name”) 69

6.2 Pesos intrínsecos da Submatriz VW (consulta “quantity employees foreach department order by name”) 69

6.3 Mapeamento da consulta “quantity employees for each department orderby name” 69

6.4 Primeiro mapeamento gerado a partir do mapeamento da Tabela 6.3 706.5 Segundo mapeamento gerado a partir do mapeamento da Tabela 6.3 706.6 Terceiro mapeamento gerado a partir do mapeamento da Tabela 6.3 706.7 Primeiro mapeamento gerado a partir do mapeamento da Tabela 6.6 706.8 Segundo mapeamento gerado a partir do mapeamento da Tabela 6.6 706.9 Terceiro mapeamento gerado a partir do mapeamento da Tabela 6.6 716.10 Mapeamento gerado a partir do mapeamento da Tabela 6.9 716.11 Mapeamento da consulta “quantity employees for each department order

by department” 736.12 Pesos intrínsecos da Submatriz SW (consulta “ employees ‘Houston Tx’ ”) 786.13 Pesos intrínsecos da Submatriz VW (consulta “ employees ‘Houston Tx’ ”) 786.14 Mapeamento da consulta “employees ‘Houston Tx”’ 786.15 Submatriz VW contextualizada com base no mapeamento da Tabela 6.14 796.16 Mapeamento para termos de valor (consulta “employees ‘Houston TX”’) 79

6.17 Mapeamento gerado a partir do mapeamento da Tabela 6.16 796.18 Mapeamento gerado após negativar os pesos iguais à 75 806.19 Pesos intrínsecos da Submatriz SW calculados pelo MP 846.20 Pesos intrínsecos da Submatriz SW calculados pela Keymantic 846.21 Pesos intrínsecos da Submatriz VW calculados pelo MP 856.22 Pesos intrínsecos da Submatriz VW calculados pela Keymantic 856.23 Mapeamento gerado pelo MP 856.24 Mapeamento gerado pela Keymantic 866.25 Mapeamento gerado a partir do mapeamento da Tabela 6.24 (Keymantic) 866.26 Submatriz VW contextualizada com base no mapeamento da Tabela 6.23

(MP) 876.27 Submatriz VW contextualizada com base no mapeamento da Tabela 6.24

(Keymantic) 876.28 Submatriz VW contextualizada com base no mapeamento da Tabela 6.25

(Keymantic) 876.29 Conjunto de consultas com palavras-chave 906.30 Mapeamento a partir do qual são gerados mapeamentos que não estão

de acordo com a ordem decrescente de pontuação 92

Lista de Algoritmos

4.1 Intrinsic SW Matrix Computation (retirado de [4]) 454.2 Keyword to db term mapping selection (retirado de [4]) 494.3 Contextualizing ValueWeight Sub-MatrixVW(retirado de [4]) 535.1 Modificação do Algoritmo 4.1 59

Lista de Códigos de Programas

6.1 Código da primeira configuração para a consulta “quantity employees foreach department order by department” 74

6.2 Código SQL da segunda configuração para a consulta “quantity em-ployees for each department order by department” 75

6.3 Código SQL da quarta configuração para a consulta “quantity employeesfor each department order by department” 76

6.4 Código SQL gerado para consulta “ employees ‘Houston Tx’ ” 81A.1 Código SQL para a criação da Tabela de Metadados para Exposição

(TME) [20] 102B.1 Esquema físico do banco de dados COMPANY 107

CAPÍTULO 1Introdução

Este capítulo introdutório apresenta o problema a ser tratado neste trabalho,elucidando a solução que será proposta e os desafios a serem superados. Na Seção 1.1são apresentados o contexto e a motivação que deram origem a este trabalho, seguidosdos objetivos traçados na Seção 1.2 e as principais dificuldades a serem solucionadas naSeção 1.3. E por fim, a Seção 1.4 descreve a organização do restante deste trabalho.

1.1 Contexto e Motivação

A Internet representa o principal meio de comunicação existente na atualidade,uma vez que possibilita a rápida difusão do conhecimento gerado. A informação, uma vezproduzida, circula instantaneamente e se torna disponível em qualquer parte do mundo.

A rede mundial de computadores é uma maneira muito eficiente de se ter acessoa uma grande quantidade de informações de forma simultânea, transpondo barreirasgeográficas e temporais, e possibilitando a troca de dados, informações, decisões econhecimento de uma maneira surpreendentemente ágil. A quantidade de informaçõesdisponíveis no universo online está além da capacidade que uma pessoa poderia assimilardurante uma vida inteira.

As informações estão dispersas nos mais diversos meios de armazenamento e ousuário normalmente não sabe como e onde encontrá-las. Neste sentido, é necessário umainterface de recuperação de informação, de modo que o usuário submeta sua necessidadede informação e o sistema busque pelas fontes que contenham informações relevantespara a consulta submetida e retorne os resultados encontrados ao usuário.

Uma técnica simples, porém eficaz de buscar e explorar informações, é a técnicade consulta com palavras-chave. A última década presenciou o emprego cada vez maiordesta tecnologia de pesquisa que tornou-se de fato um padrão para a interação do usuáriocom a World Wide Web (WWW). Porém, a técnica não é utilizada de forma generalizadapor todos os meios de armazenamento. Dentre eles, estão os bancos de dados relacionaisque são uma forma importante de armazenamento de dados.

1.2 Objetivos 18

Apesar dos sistemas gerenciadores de banco de dados relacionais (SGDBR’s)armazenarem a maior quantidade de dados do mundo empresarial, eles fornecem suportelimitado para pesquisa com palavras-chave e esses dados permanecem então “escondidos”na Web. De fato, apenas alguns poucos dados da Web podem ser encontrados pelosmotores de busca, uma vez que a maioria dos dados são armazenados em bancos de dadose são necessárias interfaces de pesquisa especiais para encontrá-los.

Os dados armazenados em bancos de dados formam a Web Invisível. Bergman[5] constatou em 2001, que a quantidade de informações armazenadas na Web Invisívelera 400 ou 550 vezes maior do que a Web visível. Em 2008, estimou-se que 70 a 75% detodos os dados da Web estavam armazenados na Web Invisível, ou seja, cerca de um trilhãode páginas não indexadas pelos motores de busca [33]. O problema da Web Invisível écausado pela incompatibilidade de interfaces de pesquisa entre os motores de busca ebancos de dados. Permitir consulta com palavras-chave em bases de dados relacionaisseria um bom começo para a solução deste problema.

Assim, nos últimos anos tem-se empregado um grande esforço em atividadesde pesquisa e desenvolvimento para estender as capacidades de busca com palavras-chave para fontes de dados que seguem o paradigma relacional. No entanto, as técnicasque utilizam palavras-chave para busca na Web não podem ser aplicadas diretamente emdados armazenados em bancos de dados. Nos bancos de dados relacionais, a informaçãoé representada através de tabelas de dados, sendo necessário descobrir as estruturas dobanco de dados que contenham as palavras-chave da consulta e explorar como estasestruturas são conectadas entre si. Isto exige, por parte do usuário, um conhecimentoprévio da estrutura do banco de dados e de uma linguagem estruturada, como a SQL, paraformular uma consulta. Contudo, nem todos os usuários possuem tal conhecimento, o quese torna uma limitação ao acesso destes dados.

Nesse sentido, o propósito deste trabalho é apresentar um método para solucionarconsultas com palavras-chave em bancos de dados relacionais, a fim de eliminar anecessidade deste conhecimento prévio e permitir uma recuperação simplificada dosdados dos múltiplos bancos de dados disponíveis na Web.

1.2 Objetivos

Dado um conjunto de banco de dados disponíveis na Web, o objetivo do presentetrabalho é permitir que a partir de uma consulta com palavras-chave submetida por umusuário, sejam identificados os bancos de dados relacionais que contêm informaçõesrelevantes para a consulta, e esta seja então submetida a cada banco de dados subjacentee os resultados por eles retornados sejam exibidos ao usuário.

1.2 Objetivos 19

Como mencionado anteriormente, a técnica de consultas com palavras-chaveé comum no contexto da Web, mas não no contexto de banco de dados relacionais.Para estes, é necessário converter a consulta com palavras-chave em consultas SQLcorrespondentes. Contudo, uma consulta SQL é uma consulta estruturada onde as tabelas,os atributos e suas condições são precisamente especificadas, enquanto que uma consultacom palavra-chave é formada por termos indefinidos que expressam a necessidade deinformação do usuário.

Como mencionado anteriormente, um grande esforço tem sido despendido vi-sando estender as capacidades de busca com palavras-chave para bancos de dados relaci-onais. Contudo, as técnicas existentes possuem algumas limitações.

A primeira limitação é que tais abordagens consideram que toda palavra-chavedesempenha algum papel no banco de dados e cada palavra-chave é mapeada para umaestrutura do banco de dados correspondente. Considere o esquema de relação Employee

(Fname, Minit, Lname, Ssn, Bdate, Address, Sex, Salary, Superssn, Dno) do exemplodo banco de dados Company proposto por Elmasri e Navathe [8]. A consulta “higher

salary” espera como resultado uma estatística, o maior salário, e não um conjunto detuplas interconectadas que possuam as palavras-chave higher e salary.

A segunda limitação é que a consulta é segmentada de modo que cada palavra-chave represente isoladamente um papel no banco de dados. Ainda considerando arelação Employee, uma possível interpretação para a consulta “employee Houston Tx” éo funcionário que reside no endereço Houston Tx. Espera-se, então, que as palavras-chaveHouston Tx sejam mapeadas conjuntamente para o atributo Address da tabela Employee,ao invés de cada uma ser mapeada para uma estrutura do banco de dados isoladamente.

A terceira limitação diz respeito ao fato de muitos trabalhos não considerarem ainterdependência entre as palavras-chave. Apesar do fato de uma consulta ser uma listasimples de palavras-chave, o significado de cada palavra-chave não é independente dosignificado das demais, todos eles representam coletivamente os conceitos pretendidosque o usuário tinha em mente ao construir a consulta.

A abordagem inerente à ferramenta Keymantic [3] foi escolhida como um pontode partida para o propósito deste trabalho, pois ela trata parcialmente a terceira limita-ção anteriormente discutida, levando em consideração as várias interpretações que umaconsulta pode assumir.

Assim, o presente trabalho tem também como objetivo abordar as limitaçõesmencionadas acima e agregar semântica a este processo de conversão, a fim de fazer umamelhor suposição do significado pretendido pela consulta com palavra-chave e construirconsultas SQL que representem as intenções do usuário.

1.3 Principais Problemas 20

1.3 Principais Problemas

Os problemas identificados durante o desenvolvimento deste trabalho dizemrespeito à aplicação de técnicas de consultas com palavras-chave em banco de dadosrelacionais, nas quais é necessário um processo de conversão da consulta com palavras-chave em consultas SQL correspondentes.

Uma das primeiras dificuldades deste processo de conversão é a decisão sobrequal papel cada palavra-chave desempenha no contexto da consulta, isto é, se ela é umvalor de um dado, ou uma metainformação que descreve o conceito de outra palavra-chave. Por exemplo, na consulta “nome João” a palavra-chave nome descreve o fato dapalavra-chave João ser um nome.

Uma vez descoberto o papel desempenhado por cada palavra-chave, é precisodescobrir como cada palavra-chave é modelada no banco de dados, ou seja, a palavra-chave representa um atributo, uma tabela ou um valor de um atributo? É pertinentesaber também como estas estruturas se relacionam. Em bancos de dados relacionais,as informações são fragmentadas e representadas como dados. Os dados são entãomodelados em forma de tabelas e atributos. Uma informação pode estar espalhada emmais de uma estrutura do banco de dados, sendo necessário fazer a junção destes dadosde modo a obter a informação pretendida. A junção em banco de dados é realizadapor meio de relacionamentos entre chave primária e chave estrangeira ou por meio dorelacionamento tabela-atributo-valor.

Em adição, uma única palavra-chave pode ser modelada de várias maneiras nobanco de dados subjacente, porém nem todas as maneiras representam a informaçãopretendida pelo usuário. Tal fato, se torna mais uma dificuldade a ser solucionada: comoidentificar qual estrutura do banco de dados melhor modela ou representa o significado dapalavra-chave pretendida no contexto da consulta?

E se existir mais de um banco de dados com informações úteis para a consultacom palavras-chave? É necessário mapear a consulta para os termos de cada banco dedados, considerando o fato de que cada um deles pode possuir um esquema de dadosdiferente. Por exemplo, a palavra “carro” poderia ser representada como uma tabelaem um banco de dados, enquanto que em outro poderia ser representada como umatributo. Desta forma, durante o processo de conversão é necessário considerar estaheterogeneidade de esquemas, de modo que a partir de uma única consulta com palavras-chave seja construída uma série de consultas SQL, cada qual considerando o contéudo dobanco de dados ao qual será submetida.

Outro problema identificado neste trabalho e que se apresenta como uma limita-ção, se refere ao fato das técnicas de consulta com palavras-chave em banco de dados rela-cionais dependerem das informações do esquema e/ou dos dados para realizar o processo

1.4 Organização do Texto 21

de conversão. Caso estas informações não sejam disponibilizadas pelo administrador dobanco de dados, não é possível realizar tal processo e consequentemente não é possívelconsultar os dados.

1.4 Organização do Texto

Após este capítulo inicial, o presente documento possui outros seis capítulos. OCapítulo 2 apresenta alguns trabalhos relacionados ao contexto de consulta com palavras-chave em bancos de dados relacionais. O Capítulo 3 apresenta uma descrição mais deta-lhada do problema a ser solucionado neste trabalho, bem como a arquitetura da soluçãoproposta. A solução proposta se baseia no uso da Keymantic, uma ferramenta já existentede consulta com palavras-chave em banco de dados relacionais. O Capítulo 4 apresenta talferramenta e detalha seu funcionamento. O Capítulo 5 descreve as adaptações realizadasnesta ferramenta para compor a solução final. O Capítulo 6 exemplifica o funcionamentoda solução proposta, bem como realiza uma análise comparativa entre a Keymantic e ométodo proposto. E por fim, o Capítulo 7 expõe as conclusões e contribuições obtidascom este trabalho e os possíveis trabalhos futuros.

CAPÍTULO 2Trabalhos Relacionados

A adaptação de consultas com palavras-chave para extrair informações de bancosde dados estruturados já atraiu a atenção de vários pesquisadores e há muitas propostasinteressantes na literatura científica. Para identificar tais propostas e verificar o estado daarte desta área de pesquisa foi realizada uma revisão sistemática [29]. Por meio desteestudo, foi possível identificar duas principais abordagens para solucionar o problema deconsultas com palavras-chave em banco de dados relacionais: a abordagem baseada emCandidate Networks e a abordagem baseada em Steiner Trees.

Na abordagem baseada em Candidate Networks, o banco de dados é modeladocomo um grafo de esquema Gs(V,E), onde cada relação Ri é representada como um nóno grafo, e existe uma aresta Ri → R j para cada relacionamento entre chave primáriae chave estrangeira de Ri para R j [16]. Esta abordagem é dividida em duas etapas: aetapa de geração dos Candidade Networks (CNs) e a etapa de avaliação dos Candidade

Networks. Na etapa de geração dos CNs, são construídos índices sobre o conjunto dosdados e das palavras-chave da consulta, de modo a identificar diretamente as tuplasque contém tais palavras-chave. Tais indíces são construídos em uma etapa anterior aoprocessamento da consulta. A partir destas tuplas de interesse são gerados os CNs, quesão conjuntos de tuplas que contêm todas as palavras-chave da consulta e são conectadosatravés de relações entre chave primária e chave estrangeira. Na etapa de avaliação, estesCNs gerados são convertidos em consultas SQL e estas consultas são, então, executadase os resultados apresentados aos usuários.

Na abordagem baseada em Steiner Tree, o banco de dados é modelado como umgrafo de dados Gd(V,E) ponderado, onde cada nó corresponde a uma tupla do banco dedados e as arestas correspondem às relações entre chave primária e chave estrangeira [22].Dado um grafo G(V,E) e um conjunto de vértice V ′ ∈ V , uma subárvore T em G é umaSteiner Tree de V ′ se T cobre todos os vértices em V’ [23]. Assim, nesta abordagem oproblema de consultas com palavras-chave é modelado como o problema de se encontrarSteiner Trees no grafo de dados, onde V ′ representa o conjunto de palavras-chave daconsulta. Em síntese, esta abordagem retorna subgrafos como resposta, onde os subgrafosconectam os nós (isto é, tuplas) contendo as palavras-chave da consulta.

23

DBXplorer [2], DISCOVER [17] e BANKS [1] estão entre os primeiros sistemasde consultas com palavras-chave em banco de dados relacionais. Os dois primeirosimplementam a abordagem baseada em Candidate Networks, enquanto que o últimoaplica a abordagem baseada em Steiner Tree.

DBXplorer retorna todas as tuplas que contêm as palavras-chave, tanto de tabelasindividuais como de múltiplas tabelas por meio de junções de chaves estrangeiras. Paratanto, faz uso de sua própria estrutura de dados, conhecida como Tabela de Símbolos,para encontrar os respectivos locais em que se encontram as palavras-chave da consultano banco de dados.

Durante a etapa de geração dos CNs, DISCOVER produz, sem redundância,todos os CNs relevantes para a consulta. Além disso, durante a etapa de avaliação dosCNs, o sistema propõe um algoritmo guloso que cria um plano de execução quase idealpara avaliar o conjunto de CNs gerados. Contudo, DISCOVER possui duas limitações.Primeiro, ele não considera soluções que incluem duas tuplas da mesma relação esegundo, ele considera apenas correspondências exatas, onde uma palavra-chave devecorresponder exatamente ao valor de um atributo.

O sistema BANKS provê uma rica interface que permite navegar sobre os dadosarmazenados em um banco de dados. O sistema gera automaticamente visões navegáveissobre as relações do banco de dados e os resultados da consulta. Cada tabela apresentada éacompanhada com uma variedade de ferramentas para interagir com os dados, tais como:as colunas em uma tabela selecionada podem se projetadas (apresentadas), as tuplasem uma tabela selecionada podem ser ordenadas por colunas, os resultados podem seragrupados por coluna e o usuário pode clicar em qualquer valor do resultado para ver astuplas associadas a este valor, etc.

Nos três sistemas, uma consulta pode obter mais de um resultado, sendo assimdesejável ordenar os resultados de acordo com sua relevância. As funções de ranking

atribuem uma pontuação para cada resultado e classifica a lista de resultados de acordocom suas pontuações. Intuitivamente, os resultados do topo da lista são mais relevantespara a consulta do que aqueles que estão no final.

Algumas teorias e práticas para ordenação de documentos foram desenvolvidasna comunidade de Recuperação de Informação a fim de agregar funções de ranking. Porexemplo, o esquema de pontuação tf-idf (term frequency-inverse document frequency) éamplamente usado no contexto de documentos. Este peso é uma medida estatística usadapara avaliar o quão importante é uma palavra para um documento em uma coleção. Aimportância aumenta proporcionalmente ao número de vezes que uma palavra aparece nodocumento, mas é compensado pela freqüência da palavra na coleção.

Os resultados dos trabalhos desenvolvidos por Luo et al. [25], Hristidis et al. [16]e Liu et al. [24] são ordenados usando métodos de ranking de Recuperação de Informação

24

(RI). Hristidis et al. [16] usa o método simples de tf-idf, e Liu et al. [24] aplica medidasmais complexas de RI. Enquanto Hristidis et al. [16] e Liu et al. [24] pontuam cadaatributo e então os combinam para estimar a pontuação dos resultados, Luo et al. [25]pontua os resultados diretamente.

Além dos métodos de ranking de RI, algumas outras métricas foram identificadase aplicadas no contexto de banco de dados relacionais. Nos sistemas DISCOVER [17] eDBXplorer [2], os resultados da consulta com palavras-chave contêm todas as palavras-chave da consulta e são ordenados por métodos simples, por exemplo, com base nonúmero de junções. Já no sistema BANKS [1], o cálculo das pontuações dos resultadoslevam em consideração os pesos das arestas do grafo de dados.

Além das particularidades em relação à técnica aplicada e o método de ranking,os trabalhos desta área de pesquisa também podem ser classificados em duas abordagens:abordagem AND-semantics e OR-semantics. A abordagem AND-semantics requer quea resposta contenha todas as palavras-chave da consulta, enquanto que a abordagemOR-semantics requer apenas que a resposta contenha alguma, mas não necessariamentetodas as palavras-chave da consulta. DBXplorer, DISCOVER e BANKS se enquadramna abordagem AND-semantics, enquanto que no trabalho de Hristidis et al. [16] foiproposto um aprimoramento do DISCOVER, adicionando suporte para a abordagem OR-

semantics.Em relação às pesquisas existentes na área, existem diversos focos de estudo. Li

et al. [21] e Peng et al. [27] apresentam estratégias de feedback que permitem aos usuáriosnão satisfeitos com os conjuntos de resultados iniciais realizarem outras execuções,a fim de obter melhores resultados. Além disso, Li et al. [21] também apresenta umsistema que permite não apenas consultas exatas, mas também consultas que possuemdissimilaridades. Para tanto, propõe um método de classificação dos resultados com basena dissimilaridade e a correlação entre diferentes tipos de objetos. A dissimilaridaded(i, j) entre dois objetos é denotada por um valor numérico que representa a diferençaentre eles, onde se i é mais similar à j, então d(i, j) é mais próximo de 0. Particularmente,d(i, i) = d( j, j) = 0. Enquanto que a correlação c(i, j) entre dois objetos é calculada comoc(i, j) = 1−d(i, j).

No sistema TASTIER [23], o objetivo é guiar o usuário na formulação daconsulta por meio do uso da autocomplementação, enquanto que Koutrika et al. [19]busca guiar os usuários e permitir um melhor refinamento da consulta por meio do usodas capacidades de sumarização e navegação das nuvens de dados.

Hassan et al. [15], Yu et al. [34] e Sayyadian et al. [30] permitem o uso de con-sultas com palavras-chave sobre banco de dados relacionais distribuídos e heterogêneos.Em [15], dado um conjunto de banco de dados distribuídos, e uma consulta q, formadapor palavras-chave e operadores lógicos, o sistema proposto identifica os bancos de da-

25

dos mais propensos a retornar resultados relevantes para a consulta q, e então pesquisasomente estes bancos de dados. Para calcular a utilidade de cada um deles para a consultaq, é criado um índice invertido que armazena as estatísticas do banco de dados e estas es-tatísticas são então utilizadas para representar quão útil ele é para a consulta. De maneirasemelhante, o propósito do trabalho em [34] é identificar os bancos de dados relevantespara uma determinada consulta com palavras-chave. Para Hassan et al. [15], a utilidade deum banco de dados é calculada apenas com base na frequência com que a palavra-chaveaparece em um termo do banco de dados, enquanto que em [34] além do fator frequência,também é considerado um novo fator, o fator de proximidade, que é definido como umparâmetro que é o inverso da distância do caminho de junção que conecta duas palavras-chave. Desta forma, além de considerar a representativade da palavra-chave no banco dedados, também é considerada a relevância do resultado retornado, onde o número de jun-ções entre as palavras-chave é inversamente proporcial à relevância do relacionamentoentra elas, ou seja, quanto mais distante as palavras-chave, mais fraca é a relação entreelas e consequentemente menos significativa ela é para a consulta.

Sayyadian et al. [30] assumem que a resposta para uma consulta com palavras-chave pode não residir em apenas um único banco de dados e sim em múltiplos bancosde dados. Neste sentido, é necessário combinar as tuplas de vários bancos de dadospara obter a resposta desejada. Assim, neste trabalho é proposto o algoritmo Kite queencontra junções aproximadas entre chaves estrangeiras de múltiplos bancos de dadosheterogêneos.

O sistema FRISK [28] faz uso de um algoritmo de programação dinâmica paracomputar as melhores segmentações da consulta e apresentá-las ao usuário, que por suavez escolhe a que mais se aproxima de sua intenção.

E por fim, Keymantic [3] e Keyword++ [13] são ferramentas que levam emconsideração as várias interpretações que uma consulta pode assumir, considerandoa ambiguidade da consulta, e prezando pela completude e precisão das respostas. Acompletude se refere a retornar todos os resultados relevantes, enquanto que a precisão serefere aos resultados mais relevantes, que correspondem com a intenção do usuário.

O presente trabalho visa propor um método de consulta com palavras-chaveque englobe os aspectos propostos por Hassan et al. [15], Yu et al. [34], Keymantic

[3] e FRISK [28]. Em outras palavras, o método proposto tem por objetivo identificaros bancos de dados que possuem informações relevantes para a consulta com palavras-chave, realizar um tratamento semântico de tal consulta e segmentar a consulta de modo aconsiderar a possibilidade de mapear conjuntamente duas ou mais palavras-chave. Alémdesses aspectos, o método proposto leva em consideração consultas com palavras-chaveque representam estatísticas e não estruturas do banco de dados para as quais devem sermapeadas.

CAPÍTULO 3Contexto e Arquitetura para o Método Proposto

Segundo Hopcroft [26], uma das grandes áreas atuais de pesquisa é a de Recupe-ração de Informação, pois “existem todos os tipos de informação em um banco de dadosque as pessoas que criaram o banco nem sabiam que elas tinham colocado lá”. Contudo,recuperar os dados destes repositórios é uma tarefa que exige um conhecimento a respeitodas estruturas do banco de dados e de uma linguagem de consulta estruturada. A fim desimplificar o acesso a estes dados, o presente trabalho propôs um método de consulta compalavras-chave em bancos de dados relacionais.

O contexto introduzido no Capítulo 1 será expandido na Seção 3.1. A Seção 3.2apresenta a arquitetura do método proposto, bem como a descrição do seu funcionamento,e a Seção 3.3 sintetiza o capítulo realçando aspectos importantes do método.

3.1 Contexto

É crescente o número de usuários que utilizam a Internet, uma vez que esta se tor-nou o principal canal de circulação e disseminação de informações. As informações estãoespalhadas nos mais diversos meios de armazenamento, sejam eles textuais, de imagens,páginas Web, documentos ou banco de dados, a maior parte na abordagem relacional.Tal heterogeniedade de repositórios digitais dificulta a recuperação das informações de-vido à dispersão das fontes, divergências nas interfaces de busca, falta de integração dosconteúdos, dentre outros.

Nesse sentido, foi criada a Open Archives Initiative (OAI), uma iniciativa paradesenvolver e promover padrões de interoperabilidade entre repositórios digitais. Paratanto, a OAI criou o protocolo OAI-PMH (Open Archives Initiative - Protocol for Meta-

data Harvesting) que permite a publicação e compartilhamento de coleções digitais como objetivo de facilitar a disseminação eficiente de conteúdo entre esses repositórios.

A interoperabilidade entre os repositórios digitais promovida pelo protocoloOAI-PMH permite a criação de novos serviços, como a busca federada, que consiste emsubmeter uma consulta a um grupo de bases de dados dispersas, agrupando os resultadoscoletados destas bases de dados e apresentando-os em um formato sucinto e unificado, ou

3.1 Contexto 27

seja, consiste no acesso simultâneo aos dados contidos nestes repositórios. Desta forma,é possível maximizar o resultado da busca e reduzir o tempo de resposta.

Ao invés de realizar a busca em cada um dos diversos repositórios, o protocoloOAI- PMH realiza uma busca automática de metadados (harvesting) de recursos queadotam o protocolo e cria uma base de dados que armazena esses metadados coletados.Uma vez que um usuário submete uma consulta, essa base de dados, que agrupa osmetadados de todos os repositórios pesquisado, é consultada.

A publicação e compartilhamento de coleções digitais são mecanismos utiliza-dos de forma mais ampla por bibliotecas digitais e sites da Internet. Porém, uma grandequantidade de informação encontra-se armazenada em bancos de dados, principalmenterelacionais. Quando um usuário submete uma consulta na Internet, utilizando algum pro-grama de busca, o mecanismo de execução da pesquisa não alcança aquelas informaçõesarmazenadas em bancos de dados, uma vez que esses ou são restritos às organizações,que por algum motivo não querem (ou não podem) expor seus dados, ou inexiste um me-canismo que permita a divulgação dessas fontes de informação. Assim, a publicação eo compartilhamento de metadados de bancos de dados são uma vertente que ainda nãofoi explorada a contento [20]. Com a finalidade de permitir a busca por informações embancos de dados relacionais através da Web, Kowata define em [20] um mecanismo quepermite a consulta a bibliotecas digitais e a bancos de dados de forma homogênea, pormeio da definição de um conjunto comum de metadados utilizados para exportar (dispo-nibilizar) essas fontes de informação.

Para permitir a publicação e o compartilhamento de recursos digitais, o protocoloOAI- PMH necessita de um formato padrão de metadados. O padrão utilizado no contextode bibliotecas digitais é o padrão Dublin Core [11]. Em [20] é feito um estudo doselementos do padrão Dublin Core utilizados para representar metadados para bibliotecasdigitais, de modo a identificar quais elementos seriam necessários para descrever umbanco de dados relacional.

As informações a respeito da estrutura de um banco de dados podem ser en-contradas no catálogo de um sistema gerenciador de banco de dados que armazena in-formações como esquemas dos bancos criados no sistema, descrição das tabelas de cadaesquema, definição das colunas que compõem cada tabela, definição de restrições, usuá-rios e permissões de acesso, dentre outras informações. Entretanto, em um estudo descritoem [20] a respeito dos catálogos dos principais gerenciadores de banco de dados dispo-níveis atualmente, demonstrou-se que em tais catálogos não há os metadados necessáriospara descrever um recurso de informação em repositórios digitais. Nesse sentido, o estudoresultou na definição de um conjunto comum de metadados para descrever um banco dedados a fim de promover a interoperabilidade entre estas bases de dados e outras fontes deinformações, tais quais as bibliotecas digitais, e permitir a publicação (disponibilização)

3.1 Contexto 28

do conteúdo destes bancos de dados por meio de um protocolo também comum.Durante o estudo realizado a respeito dos elementos definidos no padrão Dublin

Core para representar metadados para bibliotecas digitais, foram identificados 15 elemen-tos. Além desses 15, foram propostos mais 8 elementos necessários para a descrição dosmetadados de banco de dados relacionais, totalizando assim 23 elementos. A Tabela 3.1resume o conjunto destes atributos definidos para descrever os metadados de um bancode dados. Os nomes dos elementos iniciados com dc_ representam os elementos que per-tencem ao padrão Dublin Core e que são utilizados no contexto de bibliotecas digitais. Oselementos que não são iniciados por dc_ representam os elementos adicionais propostospelo trabalho para permitir a descrição dos bancos de dados.

Tabela 3.1: Atributos da Tabela de Metadados para Exposição(TME) [20]

serial provider url email oai_set dispquerydc_title dc_creator dc_subject dc_description dc_contributor dc_publisherdc_date dc_type dc_format dc_identifier dc_source dc_language

dc_relation dc_coverage dc_rights loginbd passwordbd -

Estes elementos armazenam as seguintes informações [20]:

• serial: utilizado para gerar uma sequência do repositório cadastrado;• provider: utilizado para informar o endereço do provedor de dados do banco de

dados;• url: utilizado para informar a url ou endereço do sítio vinculado ao banco de dados;• email: utilizado para informar o endereço eletrônico do administrador do banco de

dados;• oai_set: utilizado para informar a url do sítio ou endereço onde o sistema está

hospedado;• dispquery: este campo é um flag que indica se o conteúdo do banco de dados está

disponível ou não para consulta na Web;• dc_title: utilizado para apresentar o título do banco de dados;• dc_creator: utilizado para informar o nome do autor ou entidade responsável pelo

recurso;• dc_subject: na recomendação do Dublin Core, este campo deverá ser representado

pelo uso de palavras-chave, frases-chave ou código de classificação. O Dublin Core

recomenda ainda que a melhor prática é usar vocabulários controlados. É utilizadopara informar as palavras-chave associadas ao conteúdo do banco de dados;• dc_description: utilizado para apresentar um resumo (textual) sobre o conteúdo do

banco de dados;• dc_contributor: utilizado para informar o nome da pessoa/instituição responsável

por qualquer contribuição para o conteúdo do recurso;

3.1 Contexto 29

• dc_publisher: utilizado para informar o nome da entidade/instituição responsávelpor tornar o recurso acessível;• dc_date: utilizado para informar a data da publicação do recurso;• dc_type: utilizado para informar o gerenciador adotado para implementar o banco

de dados com o valor padrão de “database” seguido pelo seu tipo. Ex.: MySQL,PostGreSQL;• dc_format: utilizado para descrever o formato do banco de dados, com o valor

padrão de “SGBDR”;• dc_identifier: utilizado para descrever o nome do banco de dados conforme criado

por seu administrador;• dc_source: utilizado para informar o principal departamento que faz uso do banco

de dados;• dc_language: utilizado para informar o idioma que descreve o recurso;• dc_relation: utilizado para relacionar os sistemas que utilizam o banco de dados;• dc_coverage: utilizado para descrever as áreas de interesse do banco de dados

(financeira, cadastro, administrativo, vendas, acadêmico etc.);• dc_rights: utilizado para registrar os direitos sobre o recurso;• loginbd: usuário do banco de dados utilizado para acessar o banco de dados;• passwordbd: senha do banco de dados utilizada para acessar o banco de dados.

Visto que esses metadados necessários para descrever um banco de dados nãoestão disponíveis no catálogo do sistema, o mecanismo proposto em [20] sugere que estesmetadados sejam fornecidos pelo administrador do banco de dados e armazenados emuma tabela que representará uma extensão do catálogo do sistema gerenciador de banco dedados. Essa tabela para armazenamento de metadados, denominada Tabela de Metadadospara Exposição (TME), contém um atributo para cada um dos elementos descritos naTabela 3.1. O Código SQL para a criação da tabela TME encontra-se no Anexo A.

Uma vez definida a Tabela de Metadados para Exposição, esses metadadossão extraídos e exportados utilizando o protocolo OAI-PMH, permitindo, desta forma,a identificação e a localização dos bancos de dados disponibilizados na rede. Isto permitea indexação destes bancos de dados e o compartilhamento dos seus dados com os demaisusuários da rede.

De forma geral, esse trabalho permite a exposição dos metadados dos bancosde dados relacionais que podem então ser indexados. Contudo, isso não é suficientepara permitir a recuperação dos dados destas fontes de informações. Para se realizarconsultas em banco de dados relacionais é necessário o conhecimento das estruturas dearmazenamento e da sintaxe de uma linguagem estruturada, como o SQL. Contudo, amaioria dos usuários não possui esse conhecimento, tornando-se assim uma limitação aoacesso desses dados. Nesse sentido, surge a ideia de expandir a técnica de consulta com

3.2 Arquitetura 30

palavras-chave para banco de dados relacionais, uma vez que elimina a necessidade desseconhecimento prévio por parte do usuário e por ser uma técnica com a qual os usuários jáestão familiarizados.

Desta forma, visto que o trabalho [20] permite a exposição e indexação dosbancos de dados relacionais, mas não a consulta a estes dados, o presente trabalho visapropor um método de recuperação dos dados destes bancos por meio do uso da técnica deconsulta com palavra-chave.

3.2 Arquitetura

Dada uma única consulta com palavras-chave, o método proposto neste trabalhoidentifica os bancos de dados disponíveis e relevantes para tal consulta, e converte estaconsulta em consultas SQL correspondentes, as quais são submetidas aos bancos de dadosidentificados como relevantes. Como resposta à consulta com palavras-chave, o métodoretorna os resultados obtidos pela execução das consultas SQL.

Uma visão geral da arquitetura do método proposto é apresentada na Figura 3.1.

Figura 3.1: Arquitetura do método proposto (inspirado em [28])

Para exemplificar os conceitos explorados nesta seção utilizaremos o bancode dados COMPANY proposto por Elmasri e Navathe [8]. A Figura 3.2(a) apresenta oesquema de relações enquanto que a Figura 3.2(b) ilustra a fração dos dados do bancode dados COMPANY. Maiores informações a respeito deste banco de dados podem serencontradas no Apêndice B.

3.2 Arquitetura 31

3.2.1 Pré-processamento

A fase de Pré-processamento da consulta é responsável por “limpar” a consultacom palavras-chave, identificar a melhor segmentação da consulta para valores compostospor mais de uma palavra-chave, e por fim agregar semântica à consulta.

(a) Esquema lógico do banco de dados COMPANY com suasrestrições de integridade referencial.

(b) Fração dos dados do banco de dados COMPANY.

Figura 3.2: Banco de dados COMPANY (retirado de [8])

3.2 Arquitetura 32

Algumas palavras-chave da consulta podem não ter um significado em relaçãoaos termos do banco de dados. Por exemplo, considere a consulta “higher salary”. Apalavra-chave salary poderia ser mapeada para o atributo Salary da relação Employee,porém a palavra-chave higher não possui nenhum elemento representativo no banco dedados para o qual poderia ser mapeada. Nesse caso, a melhor interpretação dessa consultaé que a palavra-chave higher represente a necessidade do uso da função agregada max.Ou seja, é necessário “limpar” a consulta de forma a deixar apenas as palavras-chave quepossuem um significado real na base de dados.

Outro fator considerado nessa fase de pré-processamento é a segmentação daconsulta. Palavras-chave que podem ser mapeadas para valores de atributos, ou seja, paraos dados em si, devem receber uma atenção especial durante o momento de segmentaçãoda consulta. Se a consulta for segmentada de tal maneira que cada palavra-chave repre-sente um termo do banco de dados para a qual será mapeada, valores como endereço edescrição de um produto poderão perder seu significado. Por exemplo, considere a con-sulta “employee Houston TX”. Uma possível interpretação dessa consulta é encontrar osempregados que moram em Houston, TX. Assim, espera-se que as palavras-chave Hous-

ton e TX sejam mapeadas conjuntamente para o domínio do atributo Address. Posto isso,durante a segmentação da consulta deve-se levar em consideração os valores que são com-postos por mais de uma palavra-chave, de modo que eles sejam mapeados conjuntamente.

Em relação à agregação de semântica à consulta, nem sempre as palavras-chaveda consulta estão representadas da mesma maneira nas estruturas do banco de dados.Por exemplo, considere a consulta “department workers”. A palavra-chave department

poderia claramente ser mapeada para a relação Department, porém para a palavra-chaveworkers não existe nenhum termo no banco de dados da Figura 3.2(a) que forneça umacorrespondência exata. Mas se for considerado que o conceito de employee é similar aoconceito de workers, então é possível mapear workers para a relação Employee.

A fase de Pré-processamento é composta por duas etapas, as quais consi-deram os fatores mencionados acima. As duas etapas, Verificação de Função Agre-

gada/Ordenação/Valores Compostos e Expansão da consulta, estão descritas a seguir.

Verificação de Função Agregada/Ordenação/Valores Compostos

Esta etapa permite a identificação de palavras-chave que representam a intençãodo uso de funções agregadas e ordenação, bem como a identificação de palavras-chaveque devem ser consideradas conjuntamente para formar o valor de um atributo.

A identificação das palavras-chave que sugerem o uso de funções agregadas eordenação é feita por meio de uma lista de palavras “reservadas”. Essas palavras reser-vadas nada mais são que um conjunto de palavras pré-definidas com base na observaçãode como os usuários formulam suas consultas. Além disso, outro fato observado é que

3.2 Arquitetura 33

as palavras-chave que representam o uso de funções agregadas são seguidas da palavraem que será aplicada a função. Por exemplo, na consulta “higher salary” a palavra-chavehigher é identificada na lista de palavras reservadas e por meio dessa lista descobre-se queela pertence ao grupo pré-definido de palavras que representam a função agregada max.Uma vez que a palavra-chave salary é adjacente e posterior à palavra-chave higher, elaserá a palavra sobre a qual a função max será aplicada. No contexto do banco COMPANY,considere que a palavra-chave salary seja mapeada para o atributo Salary da relação Em-

ployee. Dessa forma, a consulta “higher salary” pode ser então convertida para a consultaSQL: select max(Salary) from Employee. A identificação do uso de ordenação e agrupa-mento segue o mesmo raciocínio.

A identificação das palavras-chave que devem ser consideradas conjuntamentepara formar o valor de um atributo é feita por meio do uso de aspas simples. Porexemplo, no caso da consulta “employee Houston TX”, as palavras-chave Houston TX

devem aparecer entre aspas simples para representar a necessidade de serem mapeadasconjuntamente para o mesmo domínio de um atributo. Assim, a consulta deve ser“employee ‘Houston TX’ ”.

Expansão da consulta

Uma vez eliminadas as palavras-chave que representam o uso de funções agre-gadas e ordenação, a consulta permanece apenas com palavras-chave que representamalgum termo do banco de dados. Porém, como mencionado anteriormente, nem sempreas palavras-chave são uma representação exata do termo que está no banco. Para lidarcom esse problema, é necessário considerar também outras palavras relacionadas à essaspalavras-chave.

Para tanto, foi utilizado o dicionário WordNet que provê sinônimos, hiperônimos,hipônimos e outros termos relacionados à uma dada palavra. Como o WordNet é uma basede dados com palavras na língua inglesa, o presente trabalho considera apenas consultas ebanco de dados com conteúdo em Inglês. Caso as palavras que compõem a consulta ou osmetadados e o contéudo do banco de dados estejam em outra língua, como o Português, aconsulta poderá ser realizada, porém não será agregada semântica à ela. Ou seja, essa fasede expansão da consulta não encontrará sinônimos e a consulta permanecerá a mesma.Caso existam palavras-chave na consulta que possuem a mesma grafia em Inglês, serãoadicionados à consulta original os sinônimos retornados pelo WordNet, porém na fase demapeamento provavelmente eles serão desconsiderados. Um exemplo disso é a palavraitem, que possui a mesma grafia em inglês.

3.2 Arquitetura 34

3.2.2 Processamento da consulta

Até este momento foram identificados os possíveis usos de funções agregadase ordenação, valores compostos por mais de uma palavra-chave e foram adicionados àconsulta termos relacionados às palavras-chave. Dessa forma, tem-se uma consulta quepossui apenas palavras-chave que possuem um significado real no banco de dados e umconjunto de sinônimos para o caso de não existir uma correspondência exata entre ostermos do banco de dados e as palavras-chave da consulta.

Dado um conjunto de banco de dados disponibilizados por meio do protocoloOAI-PMH usando a extração de metadados sugerida por Kowata [20], é necessário iden-tificar quais bancos contêm informações úteis para a consulta com palavras-chave. Umavez identificados, é necessário criar a partir dessa única consulta com palavras-chave,várias consultas SQL que serão executadas nos múltiplos bancos de dados selecionadoscomo relevantes. Esse processo de criação das consultas SQL é feito pelo mapeamentodas palavras-chave para os termos do banco subjacente. Uma vez executadas as consultasSQL, os resultados são retornados ao usuário ordenados por relevância. Todo esse proces-samento é realizado em 5 etapas: Identificação dos bancos de dados relevantes, Ranking

dos bancos de dados relevantes, Mapeamento, Execução e Ranking dos resultados. Aexplicação sobre cada uma dessas etapas está abaixo.

Identificação dos bancos de dados relevantes

Em concordância com o método de exposição dos metadados de bancos dedados relacionais, proposto em [20], cada banco possui uma tabela TME que representaa extensão do catálogo do banco de dados e que contém informações a respeito doconteúdo do banco de dados. Essas informações são descritas por meio dos 23 elementosapresentados na Tabela 3.1.

A identificação e seleção dos bancos de dados que possuem conteúdo relevantepara a consulta com palavra-chave é feita com base na análise das informações contidasna tabela TME. Considere as informações fictícias da tabela TME do banco COMPANY

apresentada na Tabela 3.2. Nem todos os elementos desta tabela contêm informações arespeito do conteúdo do banco de dados. Alguns elementos como login, url, dispquery,dentre outros, dizem respeito à localização e ao acesso. Essa etapa de identificaçãodos bancos de dados relevantes considera apenas os elementos que contêm ou sugereminformações a respeito do conteúdo do banco de dados. Os elementos consideradossão: dc_title, dc_subject, dc_description e dc_identifier. Caso as informações de umdesses quatro elementos contenha alguma palavra-chave da consulta, o banco de dadosé considerado como relevante para a consulta.

3.2 Arquitetura 35

Tabela 3.2: Informações da Tabela de Metadados para Exposi-ção(TME) do banco de dados COMPANY (inspiradoem [20])

Elemento Informaçãoserial 1provider http://localhost/website/xyzsystem/database/oaiurl http://localhost/website/xyzsystem/email [email protected]_set http://localhost/website/system/systemnamedispquery simdc_title COMPANYdc_creator Elmasri e Navathedc_subject Department. Dependent. Location. Employee. Project. Management.

Salary. Working hours. Address.dc_description Records the staff of the company, which department they belong to,

which department they manage, in which project they work, thelocation of the department and project, the employees dependents.

dc_contributor XYZdc_publisher ABCdc_date 2001-11-01dc_type Database - MYSQLdc_format SGBDRdc_identifier bdcompanydc_source DEFdc_language Inglêsdc_relation GHIdc_coverage JKLdc_rights MNOdc_login ********dc_passwordbd ********

Ranking dos bancos de dados relevantes

Dado o conjunto de bancos de dados relevantes para a consulta, estes sãoordenados de modo que o banco de dados mais relevante para a consulta fique no topo dalista.

A relevância de um banco de dados em relação à uma consulta é computadacom base no número de vezes que as palavras-chave da consulta aparecem nas informa-ções dos quatro elementos considerados na etapa anterior. Por exemplo, para a consulta“department employees”, a pontuação do banco de dados COMPANY é 5. Esta pon-tuação é computada da seguinte maneira: a palavra-chave department aparece 1 vez noelemento dc_subject e 3 vezes no elemento dc_description, enquanto que a palavra-chaveemployees aparece 1 vez no elemento dc_description, totalizando assim 5, o número devezes que ambas palavras-chave aparecem nos elementos descritores de conteúdo.

3.2 Arquitetura 36

Mapeamento

A consulta com palavra-chave é executada em cada um dos bancos de dadosconsiderados como relevante e a ordem de execução em cada banco de dados é baseadana ordenação gerada na etapa anterior.

Responder uma consulta com palavras-chave em banco de dados relacionaisrequer o entendimento do significado de cada palavra-chave e a construção de umaconsulta SQL que ofereça uma interpretação da consulta em termos do banco de dadosrelacional. Ou seja, é necessário mapear as palavras-chave em termos das estruturas dobanco de dados, tais como relações, atributos e valores de atributos.

Nesse sentido, diversas técnicas e ferramentas foram propostas a fim de solu-cionar o problema de consulta com palavras-chave em banco de dados relacionais. Ge-ralmente, essas técnicas consideram o banco de dados como uma rede de tuplas interco-nectadas e detectam as tuplas que contêm as palavras-chave da consulta. Componentesconectados são gerados, com base em como essas tuplas são associadas, e retornam estastuplas conectadas como uma resposta à consulta. Para tanto, estruturas especializadas queindexam o conteúdo da base de dados são utilizadas. Ao usar esses índices, as tuplas deinteresse podem ser diretamente identificadas.

Contudo, para construir tais índices é necessário um acesso prévio ao dados dobanco de dados. Tal fato torna-se uma limitação caso não seja permitido o acesso aosdados. Exemplos de tais situações incluem banco de dados restritos às organizações, quepor algum motivo não querem (ou não podem) dispor de seus dados e normalmente expõeapenas as informações do esquema ou parte delas.

Levando isto em consideração, é necessário o uso de uma ferramenta ou técnicade consulta com palavra-chave que não necessite do acesso ao dados do banco para cons-truir expressões SQL que correspondam à consulta. Baseado nesse fato, a ferramenta es-colhida para realizar a etapa de mapeamento foi a ferramenta conhecida como Keymantic

[3]. Tal sistema responde à consulta com palavras-chave sobre banco de dados relacio-nais baseando-se apenas no conhecimento intensional, ou seja, informações extraídas (oufornecidas) pelas fontes de dados, tais como, esquemas e tipos de dados e conhecimentoadicional que está publicamente disponível na Web, como recursos lexicais, vocabulários,ontologias, etc [3]. Além desse motivo, a ferramenta também foi escolhida pelo fato deconsiderar as várias interpretações que uma consulta pode assumir, condizendo com oobjetivo deste trabalho.

Apesar de não requerer acesso aos dados, a ferramenta necessita do esquemapara realizar o mapeamento das palavras-chave e necessita do acesso ao banco de dadosapenas para executar as consultas SQL geradas. Com base nisso, temos dois cenários.Para identificar qual cenário deve ser considerado é necessário verificar o conteúdo doelemento dispquery da tabela TME. Considere que as etapas de pré-processamento e

3.2 Arquitetura 37

identificação e ordenação dos bancos de dados relevantes já tenham sido executadas.No primeiro cenário, um dos bancos considerados como relevantes foi disponibi-

lizado pelo administrador do banco de dados, expondo os metadados do mesmo por meioda tabela TME, porém não disponibilizou o esquema do banco de dados e/ou o acesso àesse banco de dados. Nesse caso, o elemento dispquery conterá a informação que o bancode dados não está disponível para consulta. Não será possível realizar o processo de ma-peamento das palavras-chave da consulta e consequentemente não será possível realizaras demais etapas, impedindo assim que os resultados sejam gerados e retornados parao usuário. Uma solução para esse cenário, seria repassar a consulta com palavra-chavepara o administrador do banco de dados. Este então, deveria possuir uma implementaçãoprópria da técnica de consulta com palavras-chave em bases de dados relacionais e entãoexecutar a consulta que lhe foi entregue. Uma vez realizada a consulta, o administradordo banco de dados retornaria os resultados desta consulta.

O outro cenário considera que o administrador além de expor os metadados,disponibiliza o esquema e o acesso ao banco de dados. O acesso ao banco é fornecidopor meio dos elementos loginbd e passwordbd, presentes na tabela TME. Desta forma,as etapas de mapeamento, execução e ranking dos resultados podem ser realizadas e osresultados são então retornados ao usuário.

Para o propósito deste trabalho, o último cenário será considerado. O processode mapeamento e o funcionamento da ferramenta Keymantic serão descritos em maioresdetalhes no Capítulo 4.

Execução

O processo de mapeamento realiza a correspondência entre as palavras-chave daconsulta e os termos do banco de dados subjacente. Com base nessa correspondência, aferramenta Keymantic constroi uma consulta SQL correspondente. Porém, uma consultacom palavras-chave pode ter mais de uma interpretação, e cada interpretação pode cor-responder a um mapeamento diferente das palavras-chave em termos das estruturas dobanco de dados. Dessa forma, uma consulta com palavras-chave pode ser convertida emvárias consultas SQL. Logo, para cada banco de dados relevante são construídas váriasconsultas SQL. Cada consulta SQL é então executada no banco de dados correspondente,e os resultados destas consultas representam os resultados esperados pela consulta compalavras-chave. Porém, estes resultados não são igualmente significativos, alguns repre-sentam melhor a semântica pretendida pela consulta do usuário. Nesse sentido, é interes-sante apresentar ao usuário, primeiramente, os resultados mais significativos. O ranking

destes resultados é executado na próxima etapa que será descrita a seguir.


Ranking dos resultados

Para gerar um ranking dos resultados é necessário ter uma medida quantitativaque indica quão significativo um resultado é para a consulta. Considerando que a ferra-menta Keymantic computa uma pontuação para cada consulta SQL gerada e, consequen-temente, o resultado obtido pela execução dessa consulta possui a mesma pontuação, osresultados retornados ao usuário podem atender a seguinte ordenação: os resultados dobanco de dados mais relevante para consulta aparecem primeiro e, em seguida, os re-sultados dos demais, na ordem definida na etapa de ranqueamento dos bancos de dadosrelevantes; os resultados de cada banco de dados são então ordenados primariamente pelapontuação de sua consulta SQL correspondente, e secundariamente pelo tamanho do ca-minho de junção.

O tamanho do caminho de junção é baseado no número de junções necessáriasna consulta SQL. Por exemplo, considere que dois resultados de um dos bancos de dadosrelevantes possuam pontuação 283, e que as consultas SQL que os originou possuam4 junções e 3 junções, respectivamente. Ambos possuem a mesma pontuação, porém umpossui menor caminho de junção. Então, o resultado com o tamanho de caminho de junção3 irá aparecer antes do resultado que possui tamanho de caminho de junção 4.

3.3 Considerações Finais

Como visto na Figura 3.1 e detalhado neste capítulo, o método proposto en-globa outras funcionalidades além da simples aplicação de uma técnica de consultacom palavras-chave para realizar o mapeamento das palavras-chave. As etapas de pré-processamento, seleção e ordenação dos bancos de dados relevantes e ordenação dosresultados são cruciais para a identificação de fontes com conteúdo de interesse para aconsulta e para permitir uma melhor interpretação da consulta de modo a encontrar osresultados mais proeminentes. Puramente, a técnica de consulta com palavras-chave apli-cada engloba apenas as etapas de Mapeamento e Execução. Essas duas últimas etapasnada mais são que a representação do uso da ferramenta Keymantic.

Assim, como foram agregadas funcionalidades externas ao contexto da ferra-menta Keymantic, também foram realizadas algumas modificações internas à ferramenta,mais precisamente, no processo de Mapeamento, a fim de aprimorar a qualidade dos re-sultados retornados. O funcionamento da ferramenta, ou seja, a técnica utilizada pela Key-

mantic, bem como as melhorias propostas à esta técnica, serão apresentados nos próximoscapítulos.

CAPÍTULO 4Análise Semântica da Consulta

Apesar de ser uma alternativa atraente para consultas SQL tradicionais, elimi-nando a necessidade de um conhecimento prévio por parte dos usuários, a consulta compalavras-chave em banco de dados relacionais mostra-se como um problema complexoe desafiador. Neste sentido, diversos esforços têm sido feitos para propor técnicas quesolucionem este problema, entre elas, a Keymantic.

Nas próximas seções será descrito de forma mais detalhada o problema deconsulta com palavra-chave em banco de dados relacionais, modelado de acordo coma solução proposta pela ferramenta Keymantic (Seção 4.1); e as particularidades daferramenta e a técnica utilizada para solucionar o problema (Seção 4.2).

4.1 Definição do problema

Considere um banco de dados D como um conjunto de tabelas relacionais. Umatabela relacional é denotada como R(A1, A2, ... , An), onde R é o nome da tabela e A1, A2,

... , An são os atributos da tabela. O vocabulário do banco de dados D, denotado como VD,é o conjunto de todos os nomes de suas relações, atributos e o respectivos domínios destesatributos. Um termo de banco de dados é um membro do seu vocabulário.

Uma consulta com palavra-chave q é uma lista ordenada de palavras-chave, ondecada uma delas é uma especificação do elemento de interesse. A especificação pode tersido modelada no banco de dados como uma tabela relacional, um atributo, ou um valorde um atributo. Uma configuração é uma função que mapeia cada palavra-chave comrespeito aos termos do banco de dados.

Definição 4.1 Uma configuração C de uma consulta com palavra-chave q sobre um

banco de dados D é um mapeamento injetivo das palavras-chave em q para os termos

de banco de dados do vocabulário de D. Cki denota a função de mapeamento aplicada a

palavra-chave ki [4].

Algumas suposições são consideradas pela Keymantic nesse processo de mape-amento das palavras-chave. A primeira suposição é que cada palavra-chave não pode ter

4.1 Definição do problema 40

mais de um significado na mesma configuração, ou seja, cada palavra-chave só pode sermapeada para um único termo do banco de dados. Além disso, também é considerado queduas palavras-chave não podem ser mapeadas para o mesmo termo do banco de dados. Epor fim, também é feita a suposição de que toda palavra-chave desempenha um papel naconsulta, ou seja, toda palavra-chave é mapeada para um termo do banco de dados.

Uma vez mapeadas as palavras-chave, ou seja, construída uma configuração, res-ponder uma consulta com palavras-chave sobre um banco de dados D significa encontrarum conjunto de consultas SQL. Tais consultas SQL são referidas como interpretações daconsulta com palavras-chave, uma vez que oferecem um possível significado da consultaem termos do vocabulário do banco de dados.

Devido aos múltiplos caminhos de junção existentes em uma base de dados D,a partir de uma dada configuração C é possível gerar múltiplas interpretações de umadada consulta com palavra-chave q. Assim, a notação I(q, C, D) é usada para se referirao conjunto das interpretações possíveis para uma configuração, enquanto que a notaçãoI(q, D) se refere à união de todos esses conjuntos para todas as possíveis configurações daconsulta q.

Definição 4.2 Uma resposta para uma consulta com palavra-chave q sobre um banco de

dados relacional D é o conjunto res(q) = {t | t ∈ execD(q′) ∧ q′ ∈ I(q,D)}, onde execD(q′)

denota a execução da consulta SQL q′ no banco de dados D [4].

Uma vez que cada palavra-chave em uma consulta pode ser mapeada para umnome de uma relação, nome de um atributo ou para o domínio de um atributo, existem2×∑

|D|i=1 |Ri|+ |D| diferentes configurações, com |Ri| denotando a aridade da relação Ri

e |D| o número de tabelas no banco de dados. Baseado nisso, e considerando que duaspalavras-chave não podem ser mapeadas para o mesmo termo do banco, para N palavras-chave existem |V D|!

(|V D|−N)! configurações possíveis [4].Claramente, nem todas interpretações geradas por essas configurações são igual-

mente significativas. Algumas interpretações representam melhor a semântica pretendidada consulta com palavras-chave do que outras.

Na seção seguinte será apresentado como a Keymantic [3] realiza a transforma-ção da consulta com palavras-chave em consultas SQL, levando em consideração dife-rentes tipos de metainformação e a interdependência entre os mapeamentos das palavras-chave para os termos do banco de dados, afim de identificar de forma eficaz e eficienteestas interpretações mais significativas.

4.2 Análise Semântica segundo a Keymantic 41

4.2 Análise Semântica segundo a Keymantic

A ferramenta Keymantic propõe uma técnica para consulta com palavras-chavesobre banco de dados relacionais, onde as consultas são convertidas em uma série de con-sultas SQL, também referenciadas como interpretações, que capturam a possível semân-tica da consulta com palavras-chave. As consultas SQL geradas podem ser submetidas aobanco de dados e seus resultados servem como respostas à consulta com palavras-chave.Uma das novidades desta técnica é que ela não é baseada em um acesso prévio ao dadosdo banco de dados. De fato, a ferramenta utiliza apenas o esquema e outras fontes ex-ternas auxiliares para agregar semântica ao processo de mapeamento das palavras-chaveem termos do banco de dados. Além disso, a ferramenta explora as posições relativasdas palavras-chave na consulta juntamente com essas fontes externas a fim de fazer umamelhor suposição da semântica que a consulta com palavra-chave representa.

Para selecionar as melhores configurações, e por consequência, gerar as inter-pretações mais proeminentes, a ferramenta Keymantic considera dois tipos de pesos: ointrínseco e o contextual. Dado um mapeamento das palavras-chave para os termos dobanco de dados, seu peso intrínseco mede a probabilidade que a semântica do termo dobanco é aquela pretendida pela palavra-chave, sem considerar os mapeamentos das ou-tras palavras-chave na consulta. O cálculo de um peso intrínseco é baseado em fatoressintáticos, semânticos e estruturais, como nomes de relações e atributos, ou outras fon-tes externas auxiliares, como vocabulários, ontologias, domínios, etc. Por outro lado, umpeso contextual é usado para medir a mesma probabilidade, mas considerando os mapea-mentos das palavras-chave restantes. Isto é motivado pelo fato de que um mapeamentode uma palavra-chave para um termo do banco de dados pode aumentar ou diminuira probabilidade de que uma outra palavra-chave corresponda a um determinado termo.Isto é baseado em observações de que os seres humanos tendem a escrever consultas emque palavras-chave relacionadas estão perto umas das outras. Por exemplo, uma vez sub-metida a consulta “Department Name Research” ao banco da Figura 3.2(a), o fato dapalavra-chave Name estar próxima à palavra-chave Department torna mais provável quea palavra-chave Name deve ser mapeada para o atributo Dname da tabela Department.Ao mesmo tempo, esse fato diminui a probabilidade da palavra Name ser mapeada paraos atributos Fname, Lname, Pname e Dependent_name das tabelas Employee, Project eDependent, respectivamente.

A noção de peso oferece uma medida quantitativa da relação entre uma palavra-chave e um termo do banco, isto é, a probabilidade de que a semântica do termo do bancoé a semântica pretendida da palavra-chave na consulta.

A soma dos pesos dos pares <palavras-chave,termo> do banco de dados repre-senta uma pontuação que serve como uma medida quantitativa da probabilidade da confi-


guração conduzir a uma interpretação que descreve com precisão a semântica pretendidada consulta com palavras-chave.

Uma abordagem simples para selecionar as melhores configurações é calculara pontuação de todas as configurações possíveis e, então, selecionar aquelas que têm asmaiores pontuações. Contudo, esta abordagem não é muito eficiente.

Para contornar este problema, a ferramenta faz uso do algoritmo Hungarian.Este algoritmo calcula o mapeamento com a pontuação máxima sem uma enumeraçãoexaustiva de todos os mapeamentos possíveis. Porém, ele fornece apenas o melhormapeamento, ao invés dos melhores mapeamentos. Para lidar com esta limitação, aKeymantic propôs um novo algoritmo que extende o algoritmo Hungarian para calcularos melhores mapeamentos. Este novo algoritmo será descrito na Subseção 4.2.2.

Uma ilustração visual das etapas individuais realizadas pela Keymantic paratraduzir a consulta com palavras-chave em consultas SQL está representada na Figura4.1.

Figura 4.1: Mapeamento das palavras-chave (retirado de [3])

Uma estrutura de dados especial, chamada matriz de pesos, é utilizada nestasetapas. A matriz de pesos é uma matriz bidimensional com uma linha para cada palavra-chave na consulta, e uma coluna para cada termo do banco de dados. O valor de umacélula [i, j] representa o peso associado ao mapeamento entre a palavra-chave i e o termo


Tabela 4.1: Matriz de peso com a submatrizes SW (claro) e VW(escuro) (retirado de [4])

R1 . . . Rn AR1 . . . AR1

n1. . . ARn

nnAR1

1 . . . AR1n1

. . . ARnnn

keyword1

keyword2

. . .keywordk

de banco de dados j. A Tabela 4.1 exibe uma ilustração abstrata de uma matriz de peso[4].

As colunas Ri e ARij correspondem à relação Ri e o atributo A j de Ri, respectiva-

mente, enquanto que uma coluna ARij representa os valores que o atributo A j da relação

Ri pode assumir, isto é, seu domínio. Duas partes (isto é, submatrizes) podem ser distin-guidas na matriz de peso. Uma corresponde aos termos do banco de dados relacionadosaos elementos do esquema, isto é, relações e atributos, e a outra corresponde a valores deatributo, isto é, elementos pertencentes aos domínios dos atributos. Os termos do bancode dados relacionados a elementos do esquema são referidos como termos de esquema,enquanto os relacionados aos domínios de atributo são referidos como termos de valor.Na Tabela 4.1, estas duas submatrizes são ilustradas com diferentes tons de cinza, os pe-sos na submatriz mais clara são referidos como pesos de esquema (SW) e os da submatrizmais escura como pesos de valor (VW).

Os detalhes das etapas individuais da Figura 4.1 são descritas nas subseçõesseguintes.

4.2.1 Cálculo dos pesos intrínsecos (Passo 1)

Para calcular os pesos intrínsecos, é preciso calcular a relevância entre cadapalavra-chave da consulta e cada termo banco de dados. O cálculo é realizado atravésda exploração e da combinação de uma série de técnicas de similaridade baseadas nosconhecimentos estruturais e léxicos extraídos a partir da base de dados, e no conhecimentoexterno, como ontologias, vocabulários, etc. O conhecimento extraído da fonte de dados ébasicamente a metainformação que a fonte torna pública, em geral, a estrutura do esquemae restrições. Esta metainformação é representada pelos nomes de tabelas e atributos,os domínios dos atributos e muitas vezes restrições referenciais e de integridade, comochaves primárias e chaves estrangeiras.

O Passo 1 é dividido em duas etapas, o Cálculo dos pesos intrínsecos para os

termos de esquema do banco de dados e o Cálculo dos pesos intrínsecos dos termos de

valor do banco de dados. Ambas etapas são descritas nas subseções seguintes.


Cálculo dos pesos intrínsecos dos termos de esquema do banco de dados

Para o cálculo dos pesos intrínsecos para os termos de esquema a Keymantic

emprega diferentes técnicas de medição de similaridade e seleciona a que oferece omelhor resultado. Uma dessas técnicas é a similaridade entre strings onde se emprega umasérie de métricas de similaridade diferentes, tais como Jaccard, Hamming, Levenshtein,etc. A ferramenta também avalia a relação de uma palavra-chave com um termo deesquema do banco de dados com base em sua relação semântica. Para tanto, utilizaontologias públicas, como o SUMO, ou dicionários semânticos, como o WordNet.

O Algoritmo 4.1 descreve o procedimento para o cálculo do peso intrínseco damatriz SW. O conjunto ∑ representa os métodos de similaridade utilizados pela ferramentaKeymantic. Cada método tem como entrada duas strings e retorna a similaridade entreelas em um intervalo de 0 a 1. O maior valor retornado é então multiplicado por 100e escolhido como peso intrínseco. Se a similaridade entre uma palavra-chave e umtermo de esquema é abaixo de um determinado limiar (definido pela aplicação), entãoa similaridade é definida como 0. Ao final do procedimento algumas linhas na matrizSW poderão ter somente zeros. Estas linhas representam palavras-chave que não sãosemelhantes o suficiente com nenhum termo de esquema, então elas serão consideradasmais tarde como candidatas no mapeamento para os termos de valor.

O Algoritmo 4.1 está exatamente como descrito em [4], contudo pode-se perce-ber que alguns erros foram cometidos. Provavelmente nas linhas 12 e 16, ssim deveria sersubstituído por sim, e SW [w,c] deveria ser substituído por SW [w,e], respectivamente.

Exemplo 1. Considere a consulta “employees department research” submetida ao banco

de dados COMPANY, cuja matriz de pesos está na Tabela 4.2. A tabela apresenta

uma fração da Submatriz SW contendo os pesos intrínsecos para os termos do banco

pertencentes às tabelas Employee e Department. Apenas uma abreviação dos nomes

das relações e dos atributos foi utilizada. Como pode se observar na tabela, todos os

valores da linha da palavra-chave research são 0, dessa forma esta palavra-chave não

será mapeada para nenhum termo de esquema, e será considerada posteriormente no

mapeamento para termos de valor.

Tabela 4.2: Pesos intrínsecos da Submatriz SW (inspirado em [4])D E D.Dna D.Dnu D.Mgr_ss D.Mgr_st E.Fn E.Mi E.Ln E.Ssn E.Bd E.Ad E.Dno

employees 0 92 0 0 0 0 0 0 0 0 0 0 0department 100 0 70 0 0 0 0 0 0 0 0 0 0

research 0 0 0 0 0 0 0 0 0 0 0 0 0

Cálculo dos pesos intrínsecos dos termos de valor do banco de dados

Para computar os pesos intrínsecos para os termos de valor, a Keymantic exploraa informação a respeito do domínio do atributo e decide se uma palavra-chave pertence


ou não ao domínio em questão. Além disso, utiliza da noção de semantic relatedness paracomputar o grau de similaridade entre cada par <palavra-chave,domínio de atributo>.

Algoritmo 4.1: Intrinsic SW Matrix Computation (retirado de[4])

Input : Q: Keyword QueryT: Schema Database Terms

Output: SW matrix

Algoritmo: ComputeISW(Q,T)

2 SW ← [0,0, ...,0]3 ∑← {Synonyms(w,t), Hyponyms(w,t), Hypernyms(w,t),

StringSimilarity(w,t) . . .}4 foreach w ∈ Q do5 foreach e ∈ T do6 sim← 0;7 foreach m ∈ ∑ do8 if m(w,e) > sim then9 sim← m(w,e)

endend

12 if ssim ≤ threshold then13 sim← 0;

endend

16 SW [w,c] = ssim∗100

end

O conceito de semantic relatedness SR(x, y) de dois termos x e y é definidocomo: SR(x, y) = e−2NXD(x,y), onde NXD(x, y) = {max{log f (x),log f (y)}−log f (x,y)}

{logN−min{log f (x),log f (y)}} com f(x)

denotando o número de documentos Web contendo x, e f(x, y) o número de documentoscontendo ambos x e y. Esses números são retornados por motores de buscas. O número Nrepresenta o número de documentos indexados pelo motor de busca correspondente [4].

Exemplo 2. A Tanela 4.3 ilustra uma fração dos pesos intrínsecos da Submatriz VW

para a consulta do Exemplo 1. Os pesos foram calculados usando o conhecimento a

respeito do domínio dos atributos e expressões regulares. Dessa forma, a similaridade

é calculada com base na compatibilidade da palavra-chave com o domínio do atributo,

e não entre a palavra-chave e o nome do atributo. O peso intrínseco para os termos de

valor são tratados de forma binária, onde 1 representa que a palavra-chave faz parte

do domínio do atributo, ou seja, é compatível com o domínio; enquanto 0 representa a

incompatibilidade entre a palavra-chave e o domínio.


Tabela 4.3: Pesos intrínsecos da Submatriz VW (inspirado em [4])D.Dna D.Dnu D.Mgr_ss D.Mgr_st E.Fn E.Mi E.Ln E.Ssn E.Bd E.Ad E.Sex E.Sa E.Su E.Dno

employees 1 0 1 0 1 1 1 1 0 1 1 0 1 0department 1 0 1 0 1 1 1 1 0 1 1 0 1 0

research 1 0 1 0 1 1 1 1 0 1 1 0 1 0

4.2.2 Seleção dos Melhores Mapeamentos para os termos de es-quema (Passo 2)

Os pesos intrínsecos fornecem uma primeira indicação das similaridades entreas palavras-chave e os termos do banco de dados. Para gerar os mapeamentos maisproeminentes, a Keymantic também considera as interdependências entre os mapeamentosdas diferentes palavras-chave.

Primeiramente são considerados os melhores mapeamentos de palavras-chavepara termos de esquema. Para tanto é utilizada a Submatriz SW e, baseado em seus pesosintrínsecos, é gerada uma série de mapeamentos MS

1 , MS2 , ..., MS

n de palavras-chave paratermos de esquema. Os mapeamentos são aqueles que atingem as maiores pontuações, ouseja, a soma dos pesos dos mapeamentos individuais das palavras-chave.

Os mapeamentos gerados podem ser totais ou parciais. Os mapeamentos totaissão aqueles em que todas as palavras-chave são mapeadas para termos de esquema,enquanto que os mapeamentos parciais são aqueles que nem todas as palavras-chavesão mapeadas para algum termo de esquema. As palavras-chave que permanecem nãomapeadas irão desempenhar o papel de um valor real e serão consideradas em uma etapaposterior no mapeamento para termos de valor. A seleção das palavras-chave que irãocontinuar sem mapeamento é baseada na matriz de peso e em um limiar de corte. Aquelascom similaridade abaixo do limite permanecerão não mapeadas.

Para cada mapeamento MSi , a Keymantic ajusta os pesos da Submatriz SW para

levar em consideração o contexto gerado pelo mapeamento das palavras-chave vizinhas.Isto é feito baseado na observação que os usuários formam consultas em que palavras-chave referentes aos mesmos conceitos ou conceitos relacionados são adjacentes. Ageração dos mapeamentos e o ajuste dos pesos em SW são realizados pela extensãodo algoritmo Hungarian que será descrito na Subseção 4.2.2. Durante a execução doalgoritmo, é gerado uma série de mapeamentos para termos de esquema, e para cadamapeamento é calculado a pontuação correspondente. O algoritmo é executado até omomento em que nenhum dos mapeamentos gerados possua pontuação acima de umlimiar estabelecido. Não existe um valor específico para definir o limiar. Esse valor éescolhido de acordo com a quantidade de resultados que se espera da consulta. Quantomaior o valor, menos interpretações serão geradas, mas com maior confiança. Quantomenor o valor do limiar, mais interpretações são geradas, porém a medida que sãogeradas mais interpretações, estas são menos significativas. Isto porquê com a extensão do


algoritmo Hungarian, no decorrer da execução as pontuações dos mapeamentos geradosvão decrescendo.

Processo de Seleção dos Melhores Mapeamentos

A ferramenta Keymantic adaptou o algoritmo Hungarian de modo a não pararapós a geração do melhor mapeamento, mas continuar para gerar o segundo melhor, oterceiro, etc. Além disso, a ferramenta modificou alguns passos internos do algoritmo demodo que a matriz de peso é atualizada dinamicamente para representar a interdependên-cia entre as palavras-chave.

A execução do algoritmo consiste de uma série de passos iterativos que geram ummapeamento com pontuação máxima. Uma vez gerado o melhor mapeamento, a matrizde peso é modificada de maneira a excluir o mapeamento já gerado e o processo continuapara gerar o segundo melhor mapeamento e assim sucessivamente.

O algoritmo funciona da seguinte maneira:

1. Para cada linha é identificado o maior peso e este, então, é caracterizado comomáximo.

2. Se todos os pesos caracterizados como máximos estiverem em colunas diferentes,então um mapeamento é gerado associando cada palavra-chave ao termo do bancoreferente à coluna do peso caracterizado como máximo na linha correspondente.

• Por exemplo, considere a consulta “employees dependent relationship”. ASubmatriz SW correspondente à consulta está ilustrada na Tabela 4.4, ondeos pesos marcados com * representam os pesos caracterizados como máxi-mos na linha. A figura apresenta os pesos intrínsecos apenas para os termosdo banco de dados pertencentes às tabelas Employee e Dependent e os nomesdas tabelas e dos atributos foram abreviados. Uma vez que cada peso caracte-rizado como máximo está em uma coluna diferente dos demais, então tem-seum mapeamento onde a palavra-chave employees é mapeada para a relaçãoEmployee, a palavra-chave dependent é mapeada para a relação Dependent ea palavra-chave relationship é mapeada para o atributo relationship da relaçãoDependent.

Tabela 4.4: Mapeamento para a consulta “employees dependentrelationship”

E D E.Fn E.Mi E.Ln E.Ssn E.Bd E.Ad E.Dno D.De D.Sex D.Bd D.Re

employees 89* 0 0 0 0 0 0 0 0 0 0 0 0dependent 0 100* 0 0 0 0 52 0 0 0 0 52 68

relationship 0 0 0 0 0 0 0 0 0 0 0 0 100*

3. Senão, se uma coluna contêm mais de um peso caracterizado como máximo,todos os máximos da coluna, exceto aquele com maior valor, deixam de ser


máximos. Dessa forma, algumas linhas deixam de ter algum peso caracterizadocomo máximo.

4. O valor dos pesos das linhas que estão sem peso caracterizado como máximo, sãoentão atualizados de acordo com as regras de contextualização que serão descritasna Subseção 4.2.3.

• Essa última ação leva em consideração a interdependência entre os mapea-mentos das palavras-chave, ou seja, o mapeamento de uma palavra-chave podeaumentar ou diminuir a probabilidade de que uma outra palavra-chave aindanão mapeada corresponda à um determinado termo do banco.

5. Para cada linha sem peso caracterizado como máximo, o peso com maior valor, quepertence à uma coluna correspondente à um termo do banco de dados diferente da-quele que já havia sido caracterizado, é selecionado e caracterizado como máximo.

• Se essa ação resultar em uma matriz que tem cada peso caractacterizado comomáximo em diferentes colunas, então um mapeamento é gerado como des-crito anteriormente, caso contrário, o processo de descaracterização descritoanteriormente é repetido até que um mapeamento seja gerado.

6. O mapeamento gerado é incluído no conjunto de mapeamentos que será retornadopelo algoritmo. Em seguida, o algoritmo precisa ser repetido para gerar mapeamen-tos adicionais.

• Para evitar que os mesmos mapeamentos sejam computados, o algoritmo éreexecutado ciclicamente com uma nova matriz como entrada. A nova matrizé a matriz antiga, modificada para excluir um mapeamento que já tenha sidoconsiderado em execuções anteriores do algoritmo. Isto é feito negativando ovalor de um dos pesos caracterizado como máximo, forçando o algoritmo anunca mais selecioná-lo novamente. Todo este processo é repetido até que apontuação dos mapeamentos que o algoritmo gera esteja abaixo de um limiarespecífico.Por exemplo, a partir do mapeamento da Tabela 4.4 é possível gerar 3 novasmatrizes de entrada para o algoritmo. Estas matrizes estão apresentadas nastabelas 4.5, 4.6 e 4.7. A matriz da Tabela 4.5 foi gerada a partir da atribuiçãodo valor negativo para o peso caracterizado como máximo da primeira linha daTabela 4.4. A matriz da Tabela 4.6 foi gerada negativando o peso caracterizadocomo máximo da segunda linha, e a matriz em 4.7 negativando o peso daterceira linha.

O Algoritmo 4.2 descreve todo o processo de geração do conjunto de mapea-mentos mais proeminentes de um conjunto de palavras-chave para os termos do banco


Tabela 4.5: Primeira matriz gerada a partir do mapeamento daTabela 4.4


employees -100 0 0 0 0 0 0 0 0 0 0 0 0dependent 0 100 0 0 0 0 52 0 0 0 0 52 68

relationship 0 0 0 0 0 0 0 0 0 0 0 0 100

Tabela 4.6: Segunda matriz gerada a partir do mapeamento daTabela 4.4


employees 89 0 0 0 0 0 0 0 0 0 0 0 0dependent 0 -100 0 0 0 0 52 0 0 0 0 52 68

relationship 0 0 0 0 0 0 0 0 0 0 0 0 100

Tabela 4.7: Terceira matriz gerada a partir do mapeamento daTabela 4.4


employees 89 0 0 0 0 0 0 0 0 0 0 0 0dependent 0 100 0 0 0 0 52 0 0 0 0 52 68

relationship 0 0 0 0 0 0 0 0 0 0 0 0 -100

de dados, dada uma matriz de pesos. A expressão HUNGARIANExt se refere à versãoestendida proposta pela Keymantic.

Algoritmo 4.2: Keyword to db term mapping selection (retirado de [4])

Input : I(ii j) where I ≡ SW or I ≡ VWOutput: MI = {MI

1, ...,MIz}: Mappings generated by I

Algoritmo: Mapping(I,WMAX )

2 tempM =⋃

ipt ← HUNGARIANExt ∗ (I)3 W← ∑ ipt

4 MI ← tempM5 if W > c * WMAX then6 WMAX ←W

end8 while W > c * WMAX do9 foreach ipt ∈ tempM do

10 ipt ∈ I←−10011 Mapping(I, WMAX )

endend

4.2.3 Contextualização de VW e Seleção dos Melhores Mapeamentospara os termos de valor (Passo 3)

Para cada mapeamento parcial MSi de palavras-chave para termos de esquema

gerados na etapa anterior, os mapeamentos das palavras-chave ainda não mapeadas serãodecididos neste estágio. Este mapeamento é feito em duas fases.


Na primeira fase, os pesos intrínsecos da Submatriz VW que foram gerados noPasso 1, são atualizados para refletir a interdependência entre as palavras-chave ainda nãomapeadas e as palavras-chave já mapeadas para termos de esquema no mapeamento MS

i .Esse processo é chamado de contextualização. Esta contextualização é baseada no fatoque usuários formam consultas em que as palavras-chave que especificam informaçõesde metadados sobre um conceito são adjacentes ou pelo menos vizinhas. Assim, quandouma palavra-chave é mapeada para um termo de esquema, torna-se mais provável queuma palavra-chave adjacente deva ser mapeada para um valor no domínio deste termo deesquema. Por exemplo, considere a consulta “name Research” e que durante a primeiraetapa do processo de mapeamento (Figura 4.1), os pesos intrínsecos referente a linha dapalavra-chave Research na Submatriz SW foram 0, significando que a palavra-chave serámapeada para um termo de valor. Desta forma, durante o cálculo dos pesos intrínsecospara os termos de valor, todos os atributos que possuem como domínio uma sequênciade caracteres, terão o peso 1 para a palavra-chave Research, possuindo, assim, a mesmaprobabilidade da palavra-chave ser mapeada à eles. Se durante o Passo 2 a palavra-chavename for mapeada para o atributo Dname da relação Department, a probabilidade que apalavra-chave Research é um nome de um departamento aumenta, então o peso entre apalavra-chave e o termo de valor representando o domínio do atributo Dname deve seraumentado. Essa atualização do peso é feita pelo processo de contextualização que serámelhor detalhado na Subseção 4.2.3.

Na segunda fase, dada uma Submatriz VW atualizada, os mapeamentos paratermos de valor mais proeminentes das palavras-chave restantes ainda não mapeadassão gerados. Os mapeamentos são gerados usando novamente a técnica adaptada doalgoritmo Hungarian, descrita anteriormente na Subseção 4.2.2. O resultado é uma sériede mapeamentos parciais MV

ik, com k = 1..mi, onde i identifica o mapeamento MSi que foi

considerado para atualizar a submatriz VWi.Em resumo, dado um mapeamento parcial MS

i , as palavras-chave ainda nãomapeadas para termos de esquema serão mapeadas para termos de valor. Isso é feitocontextualizando a Submatriz VW com base no mapeamento MS

i . Esta Submatriz VW

contextualizada é então utilizada como entrada do algoritmo de seleção dos melhoresmapeamentos (Algoritmo 4.2). A saída do algoritmo é uma série de mapeamentosparcias MV

ik, assim referenciados porque as palavras-chave já mapeadas para termos deesquema no mapeamento MS

i não são consideradas, ou seja, o mapeamento MVik irá conter

apenas os mapeamentos das palavras-chave que não haviam sido mapeadas em MSi . O

mapeamento total das palavras-chave da consulta é formado pelo par MSi , MV

ik, formandouma configuração. O processo de geração das configurações será descrito na Subseção4.2.4.


Regras e Processo de Contextualização

O processo de contextualização, previamente explicado, explora as interdepen-dências entre os mapeamentos de diferentes palavras-chave. Na Figura 4.1 o processode contextualização está apresentado apenas no Passo 3. Contudo, como mencionado naSubseção 4.2.2, o processo de seleção dos melhores mapeamentos faz uso de regras decontextualização quando mais de uma palavra-chave é mapeada para um mesmo termodo banco. Desta forma, apesar de não estar explícito na figura, será considerado que oprocesso de contextualização também é realizado durante o Passo 2.

Para tal, é necessário definir dois conceitos, free trailing keywords e free prece-

ding keywords, para o entendimento do processo de contextualização. Seja K a lista depalavras-chave da consulta, MS

i um mapeamento parcial das palavras-chave em K paratermos de esquema, e KS o subconjunto de K contendo as palavras-chave mapeadas paratermos de esquema em MS

i .

Definição 4.3 Free trailing keywords de uma palavra-chave k, denotado como T(k), é

o conjunto máximo k1, k2, ..., km, de palavras-chave consecutivas em K que estão na

consulta entre duas palavras-chave ks e ke, onde ks = k e MSi é definido para ks e ke, e

indefinido para cada ki com i = 1..m [4]. Ou seja, ks e ke são palavras-chave mapeadas

para termos de esquema em MSi , enquanto que cada ki permanece não mapeada.

Definição 4.4 Free preceding keywords de uma palavra-chave k, denotado como P(k),

é o conjunto máximo k1, k2, ..., km, de palavras-chave consecutivas em K que estão na

consulta entre duas palavras-chave ks e ke, onde ke = k e MSi é definido para ks e ke, e

indefinido para cada ki com i = 1..m [4].

Quando mais de um peso é caracterizado como máximo em uma mesma coluna,todos os pesos são descaracterizados, exceto o maior. Desta forma, tem-se que algumaspalavras-chave estão mapeadas para termos de esquema e outras ainda não. Neste mo-mento, os pesos das linhas destas palavras-chave ainda não mapeadas são atualizadas deacordo com as regras de contextualização. Para o Passo 2 o processo de contextualiza-ção considera como entrada a Submatriz SW, o mapeamento parcial das palavras-chavepara os termos de esquema e o conjunto de palavras-chave. No Passo 3, o processo decontextualização considera como entrada a Submatriz VW , o mapeamento parcial daspalavras-chave para os termos de esquema, o conjunto de palavras-chave e a SubmatrizSW . A diferença entre o processo de contextualização do Passo 2 e do Passo 3, é que noPasso 2 as palavras-chave ainda não mapeadas serão mapeadas para termos de esquema,enquanto que no Passo 3, estas palavras-chave ainda não mapeadas serão mapeadas paratermos de valor.


O processo de contextualização consiste de três fases. Apenas para o Passo

3, como um passo de inicialização, todos os pesos das linhas em VW correspondentes àpalavras-chave já mapeadas para termos de esquema são definidos como zero. Isto é feitopara guarantir que nenhuma destas palavras-chave sejam mapeadas para termos de valordurante o processo de contextualização.

As três fases, explicadas a seguir, são as mesmas tanto para processo de con-textualização realizado no Passo 2 como o realizado no Passo 3. Considere apenas quepara o processo de contextualização do Passo 2 os pesos atualizados são referentes aosdomínios dos atributos, enquanto que para o processo do Passo 3 os pesos atualizados sãoreferentes aos atributos.

Na primeira fase do processo de contextualização da Submatriz VW, para cadapalavra-chave k mapeada para uma relação R em MS

i , acrescenta-se um valor constante aospesos de T(k) e P(k), que são pertinentes aos termos representando os atributos/domíniosdos atributos da relação R, são acrescidos de um valor constante. O valor acrescido visa aaumentar o peso do mapeamento, pois as consultas normalmente contêm palavras-chaveque são descrições genéricas para os valores que elas fornecem. Por exemplo, na consulta“employee Alicia”, pelo fato de estarem consecutivas, a palavra-chave employee podecorresponder a uma relação e a palavra-chave Alicia pode corresponder a um valor de umdos atributos desta relação.

Durante a segunda fase, para cada palavra-chave k mapeada para um atributo A

em MSi , é acrescido um valor constante aos pesos de T(k) e P(k), para termos representando

os atributos/domínios dos atributos da mesma relação de A. A lógica dessa regra é quepalavras-chave consecutivas podem representar além de especificações de valor, valoresque são relacionados. Por exemplo, para a consulta “employee name Jennifer Houston”

uma possível interpretação, porém não a única, é: saber a respeito de um empregadoque se chama Jennifer e reside em Houston. Nesse sentido, as palavras-chave employee

e name são especificações a respeito do valor Jennifer e a palavra-chave Houston é umvalor relacionado.

Na terceira e última fase, se uma palavra-chave k é mapeada para um atributoA, os pesos de T(k) e P(k), para os termos representando os atributos/domínios deatributos relacionados à A por meio de um caminho de junção, são acrescidos de umvalor constante. Isso porque, usuários normalmente utilizam palavras-chave referindo-sea conceitos que são semanticamente relacionados, mesmo que esses conceitos estejammodelados no banco de dados em tabelas diferentes. Considerando a consulta “employee

name Jennifer Houston” citada acima, outra possível interpretação é saber a respeito deum empregado que se chama Jennifer e trabalha em Houston. Neste caso, a palavra-chaveHouston pode representar a localização do projeto ou a localização do departamento noqual o empregado trabalha. Nos dois casos, essa informação está armazenada em uma


tabela separada da tabela Employee.As três fases descritas acima são ilustradas no Algoritmo 4.3. O algoritmo

apresenta o processo de contextualização para o Passo 3. Para representar o processode contextualização do Passo 2, são necessárias as seguintes modificações: a SubmatrizVW não é considerada como entrada do algoritmo, a saída do algoritmo é a SubmatrizSW atualizada; e a atualização dos pesos é referente aos pesos dos atributos, ou seja, oconteúdo das linhas 10, 16 e 21 é substituído por SW [k′,R.A]← SW [k′,R.A] + ∆w.

Algoritmo 4.3: Contextualizing ValueWeight Sub-MatrixVW(retirado de [4])

Input : M: Partial keyword assignment to schema database termsQ: Keyword QuerySW: Schema intriscic weight sub-matrixVW: Value intrinsic weight sub-matrix

Output: Updated VW sub-matrix

Algoritmo: ComputeCVW(SW,VW,M)

2 foreach k ∈ Q do3 t← x : ∃(k,x) ∈M4 if t = null then5 continue

end7 if t is a relation R then8 foreach attribute A of R do9 foreach k′ ∈ T (k)∪P(k) do

10 VW[k′,R.A]←VW [k′,R.A]+∆w

endend

13 else if t is an attribute A of a relation R then14 foreach attribute A′ of R with A’ 6= A do15 foreach k′ ∈ T (k)∪P(k) do16 VW[k′,R.A]←VW [k′,R.A]+∆w

endend

19 foreach attribute A′ of R′ s.t. ∃ join path from A′ to A do20 foreach k′ ∈ T(k) ∪ P(k) do21 VW[k′, R.A]← VW[k′, R.A] + ∆w

endend

endend


4.2.4 Geração das Configurações (Passo 4)

Até este momento, durante o Passo 2 foi gerado uma série de mapeamentosparciais MS

i , que representam os mapeamentos para termos de esquema, e durante o Passo

3 foi gerado uma série de mapeamentos parciais MVik, que representam os mapeamentos

para termos de valor.Cada par de mapeamento <MV

ik, MSi > é um mapeamento total das palavras-chave

para os termos do banco de dados, formando uma configuração Cik. A pontuação daconfiguração é a soma das pontuações dos dois mapeamentos, ou de forma similar, asoma dos pesos na matriz de pesos dos elementos [i,j], onde i é uma palavra-chave e j é otermo do banco para o qual a palavra foi mapeada.

4.2.5 Geração das Interpretações (Passo 5)

Uma vez computadas as melhores configurações, as interpretações da consultacom palavra-chave, isto é, as consultas SQL, podem ser geradas. A pontuação de cadaconsulta SQL é a pontuação da respectiva configuração.

Uma configuração é simplesmente um mapeamento das palavras-chave para ostermos do banco de dados. A presença de diferentes caminhos de junções entre estestermos resulta em múltiplas interpretações. Para gerar essas interpretações, a Keymantic

adotou uma abordagem gulosa para produzir uma consulta para cada caminho de junção.Para tanto, é construído um grafo onde cada nó corresponde a um termo do bancode dados. Uma aresta conecta dois termos se existe uma relação chave-primária-chaveestrangeira, ou se eles são relacionados por meio de um relacionamento tabela-atributo-valor. Para este último caso, existe uma aresta entre um nó que representa uma tabela eum nó que representa um atributo desta tabela, bem como existe uma aresta entre um nóque representa um valor e um nó que representa o atributo que contém este valor e outraaresta entre o nó que representa este valor e o nó que representa a tabela que contém estevalor.

Dada uma configuração, todos os termos que fazem parte desta configuração sãomarcados no grafo. Então é feita uma busca em largura para encontrar os caminhos queconectam estes termos. A consulta SQL é então construída usando os termos marcados,de forma a colocar as tabelas na cláusula from, as condições de integridade referencialmodeladas pela aresta na cláusula where e os atributos na claúsula select. O processo éentão repetido para encontrar uma interpretação diferente que será baseada em um outrocaminho de junção.

4.3 Consideração Finais 55

4.3 Consideração Finais

A ferramenta Keymantic realiza consultas com palavras-chave sobre banco dedados relacionais, onde tais consultas são convertidas em uma série de expressões SQLe executadas no banco de dados subjacente. A ferramenta faz uso do esquema do bancode dados e outras fontes externas auxiliares, visando agregar semântica ao processo demapeamento das palavras-chave para as estruturas do banco de dados. Tal processo demapeamento é realizado em 5 passos, nos quais são calculados os pesos intrínsecos dostermos de esquema e de valor, selecionados os melhores mapeamentos, fazendo uso deum processo de contextualização, e construídas as configurações e interpretações, sendoestas últimas executadas no banco de dados.

CAPÍTULO 5Contribuições à Analise Semântica

A Keymantic é uma ferramenta que se propõe realizar consultas com palavras-chave em banco de dados relacionais. Uma das novidades desta ferramenta é que elanão é baseada em um acesso prévio ao dados do banco. A ferramenta faz uso apenas doesquema do banco para realizar o processo de conversão da consulta com palavras-chaveem consultas SQL.

Para agregar semântica a esse processo de conversão da consulta com palavras-chave em consultas SQL, a ferramenta faz uso de fontes externas auxiliares comoontologias e dicionários e explora as posições relativas das palavras-chave de modoa fazer uma melhor suposição do significado pretendido pela consulta com palavra-chave. Esta última consideração é baseada no fato que podem existir interdependênciasentre as palavras-chave da consulta. Ou seja, o significado de cada palavra-chave não éindependente do significado das outras, todos eles representam coletivamente os conceitospretendidos que o usuário tinha em mente ao construir a consulta. Além disso, nemtodas as palavras-chave representam valores de instância, os dados propriamente dito.Muitas são utilizadas como metadados da especificação das palavras-chave adjacentes.Um exemplo disso, é a consulta “dependent relationship son” que no contexto do bancoCOMPANY, as palavras-chave dependent e relationship representam metadados (relaçãoe atributo, respectivamente) que especificam o valor son.

5.1 Limitações da Keymantic

Como mencionado anteriormente, a Keymantic faz algumas considerações du-rante o processo de mapeamento. Essas considerações trazem consigo algumas limita-ções. Uma das limitações está atrelada à suposição que toda palavra-chave desempenhaum papel na consulta, ou seja, cada palavra-chave representa um termo no banco de dados.Como cada palavra-chave deve representar um termo no banco de dados, a ferramenta nãoconsegue interpretar consultas que sugerem o uso de consultas agregadas ou ordenação.Mesmo que uma consulta contenha, por exemplo, a palavra-chave higher a ferramenta

5.2 Modificações à abordagem da Keymantic 57

irá mapear tal palavra-chave para um termo do banco de dados, ao invés de interpretá-lacomo a necessidade do uso da função agregada max.

Outra limitação é imposta com base no fato da ferramenta considerar o processode mapeamento como uma função injetora. Em uma função injetora não existe elementoda imagem que possui correspondência com mais de um elemento do domínio, onde odomínio seria o conjunto de palavras-chave e a imagem seria os termos do banco dedados. Em outras palavras, duas palavras-chave não podem ser mapeadas para o mesmotermo do banco de dados. Porém, como mencionado no Capítulo 3, existe a possibilidadede um valor ser composto por mais de uma palavra-chave. Nesse sentido, é necessáriomapear todas as palavras-chave que compõe esse valor para o mesmo domínio de atributo.Dessa forma, a ferramenta Keymantic não é capaz de interpretar consultas com valorescompostos.

Além dessas limitações e apesar de computar pesos referentes à cada interpreta-ção, a ferramenta Keymantic não provê uma ordenação dos resultados obtidos. O artigoque descreve a ferramenta sugere que uma ordenação com base na pontuação de cada in-terpretação e no tamanho do caminho de junção poderia ser feita, porém por não ser focodo artigo o assunto não foi aprofundado.

5.2 Modificações à abordagem da Keymantic

Com o intuito de superar as limitações referentes à função agregada, ordenaçãoe valores compostos, e permitir uma ordenação dos resultados, o método proposto nestetrabalho implementou as funcionalidades que se referem aos módulos de Verificação de

Função Agregada/Ordenação/Valores Compostos e Ranking dos resultados ilustradosna Figura 3.1, os quais são externos à ferramenta Keymantic. Em adição, algumasmodificações internas à ferramenta, mais precisamente, no processo de Mapeamento,também foram realizadas a fim de agregar maior qualidade aos resultados retornados.

A Figura 5.1 apresenta em destaque as etapas internas do processo de mapea-mento da ferramenta que foram modificadas.

Durante a fase de cálculo dos pesos intrínsecos dos termos de esquema do banco,a Keymantic emprega uma série de técnicas de medição de similaridade entre as palavras-chave e os termos do banco de dados e seleciona a que oferece o melhor resultado.Uma dessas técnicas é a similaridade entre strings. Além da similaridade entre strings,a ferramenta também avalia a relação de uma palavra-chave com um termo de esquemado banco de dados com base em sua relação semântica, fazendo uso de ontologias edicionários. Para cada técnica de medição (similaridade entre strings, relação semântica,entre outros) é calculada a similaridade entre a palavra-chave e o termo do banco em umintervalo de 0 à 1. O maior valor retornado é então multiplicado por 100 e escolhido como


Figura 5.1: Processo de Mapeamento com as etapas modificadasem destaque

peso intrínseco. Se nenhum dos valores retornados for maior que um limiar pré-definido,então o peso é definido como 0.

No método proposto neste trabalho, inicialmente é considerada apenas a técnicade similaridade entre strings. Para esta técnica são empregadas três métricas de simila-ridades: Jaccard, Levenshtein e Cosseno. Cada métrica tem como entrada duas strings eretorna a similaridade entre elas em um intervalo de 0 à 1. O peso intrínseco referentea uma palavra-chave e um termo do banco de dados é calculado com base na média dassimilaridades retornadas por cada métrica. Caso a média das similaridades seja acima dolimiar, a média é multiplicada por 100 e escolhida como peso intrínseco. Caso contrário,será calculada a similaridade entre os sinônimos da palavra-chave e o termo do banco dedados. Para tanto é utilizado o dicionário WordNet para retornar os sinônimos de cadapalavra-chave da consulta. Para cada sinônimo de uma palavra-chave, é calculado a mé-dia das similaridades retornadas por cada métrica. O maior valor de média retornado seráconsiderado. Se esse valor for maior que o limiar, a média é multiplicada por 90 e es-colhida como peso intrínseco. Se o valor for abaixo do limiar, então o peso intrínseco édefinido como 0.

O Algoritmo 5.1 apresenta o código referente ao Algoritmo 4.1 com as modifi-cações citadas.


Algoritmo 5.1: Modificação do Algoritmo 4.1

Input : Q: Keyword QueryT: Schema Database Terms

Output: SW matrix

1 SW ← [0,0, ...,0]2 ∑←{Cosseno(w,e),Jaccard(w,e),Levenshtein(w,e)}3 foreach w ∈ Q do4 foreach e ∈ T do5 sim← 0;6 media← 0;7 foreach m ∈ ∑ do8 media← media+m(w,e);

end10 media← media/3;11 if media ≤ threshold then12 S← Synonyms(w);13 max← 0;14 foreach s ∈ S do15 media← 0;16 foreach m ∈ ∑ do17 media← media+m(s,e);

end19 media← media/3;20 if media > max then21 max← media;

endend

24 if max≤ threshold then25 sim← 0;

26 else27 sim← max;28 SW [w,e] = sim∗90;

end30 else31 sim← media;32 SW [w,e] = sim∗100;

endend

end


Uso de Sinônimos para palavra-chave

Como os usuários normalmente esperam que as palavras-chave colocadas naconsulta apareçam nos resultados, a razão de considerar o uso do dicionário de sinônimosem um segundo nível se deve à necessidade de dar maior relevância às palavras-chave daconsulta. Ou seja, a existência da palavra-chave no banco de dados deve possuir um maiorpeso do que a existência do sinônimo dessa palavra. Por esse motivo, o valor da médiadas similaridades dos sinônimos é multiplicada por 90, enquanto que o valor da médiadas palavras-chave é multiplicada por 100.

Métricas de Similaridade

A decisão para considerar como cálculo do peso intrínseco a média dos valoresde similaridades, e não a escolha do maior valor, se deve à discrepância entre os valo-res retornados pelas métricas de similaridade entre strings. Por exemplo, considere osseguintes pares de strings: ‹dependent, project›, ‹address, relationship›, ‹dept_location,

location›. Os valores de similaridade retornados para o primeiro par pelas métricas Jac-

card, Levenshtein e Cosseno são 0.33, 0.33 e 0.50, respectivamente. Para o segundo paros valores são 0.33, 0.16 e 0.53, e para o último par os valores são 0.63, 0.61, 0.79. Comose pode perceber os valores de similaridades retornados pela métrica Cosseno são sempremaiores, uma vez que o cálculo dessa métrica é baseada apenas no número de caracteresem comum entre as duas strings. No caso do limiar ser definido como 0.5, e ser conside-rado como peso intrínseco o maior valor retornado pelas métricas, todos os pares iriamter similaridade acima do limiar. Porém isso não reflete a realidade. A similaridade entreas strings dos pares ‹dependent, project› e ‹address, relationship› é baixa e ambos os pa-res deveriam então possuir peso intrínseco 0. Nesse sentido, é considerado a média dasmétricas, de maneira a normalizar as similaridades por elas retornadas. A média das si-milaridades para o primeiro par de strings é 0.38, para o segundo par 0.34 e para o últimopar 0.67. Dessa forma, apenas o último par de strings possui similaridade acima do limiar,em outras palavras, uma similaridade considerada alta, o que de fato é verdade.

Normalização de pesos para Submatriz VW

Utilizando a mesma idéia de normalização, a modificação aplicada à etapa deCálculo dos pesos intrínsecos dos termos de valor do banco de dados reflete ao fato docálculo destes pesos ser tratado de forma binária. Assim, enquanto os pesos da SubmatrizSW, que se referem aos termos de esquema, estão em um intervalo de 0 a 100, os pesosda Submatriz VW estão entre 0 e 1.


Considere agora para uma determinada consulta, um mapeamento onde todasas palavras-chave são mapeadas para termos de esquema e um mapeamento onde nemtodas as palavras-chave são mapeadas para termos de esquema, sendo o restante delasmapeadas para termos de valor. No primeiro caso, como todas as palavras-chave sãomapeadas para termos de esquema, apenas a Submatriz SW será utilizada para o cálculoda pontuação da configuração, enquanto que para o segundo caso, seriam considerados ospesos das submatrizes SW e VW. Dessa forma, como os pesos da matriz VW são binários,o valor agregado à pontuação total da configuração pelas palavras-chave mapeadas paratermos de valor é mínimo. Assim, configurações que representam o mapeamento detodas as palavras-chave para termos de esquema sempre possuirão pontuações maioresque configurações que representam um mapeamento para termos de valor. Contudo,esse cenário não é condizente com todas as situações. Um exemplo disso é a consulta“employees department research” do Exemplo 1 (Capítulo 4), onde espera-se saber arespeito dos empregados que trabalham no departamento cujo nome é Research.

Os pesos intrínsecos das submatrizes SW e VW referentes a estas consultasestão representados nas tabelas 4.2 e 4.3, respectivamente. Consideremos, para fins desteexemplo, que a similaridade entre a palavra-chave research e o atributo Address da relaçãoEmployee seja maior que o limiar. Sendo assim, ao invés do peso intrínseco ser 0, ele seja,por exemplo, 51. Dessa forma, um possível mapeamento para essa consulta, considerandoesse fato, é apresentado na Tabela 5.1. A pontuação da configuração é calculada com basena soma dos pesos intrínsecos referente ao mapeamento. Dessa forma, a pontuação dessaconfiguração é 240.

Tabela 5.1: Mapeamento onde todas as palavras-chave são mape-adas para termos de esquema

D E D.Dna D.Dnu D.Mgr_ss D.Mgr_st E.Fn E.Mi E.Ln E.Ssn E.Bd E.Ad

employees 0 89* 0 0 0 0 0 0 0 0 0 0department 100* 0 0 0 0 0 0 0 0 0 0 0

research 0 0 0 0 0 0 0 0 0 0 0 51*

Como explicado na Subseção 4.2.2, após gerar o melhor mapeamento, os demaismapeamentos são gerados atribuindo um valor negativo a cada mapeamento individualde forma a não haver repetições. Assim, um possível mapeamento gerado a partir domapeamento da Tabela 5.1, é apresentado nas tabelas 5.2 e 5.3. Como pode se ver naTabela 5.2, o peso intrínseco entre a palavra-chave research e o termo Address possuiagora um valor negativo, garantindo assim que o mesmo mapeamento não seja repetido.Porém, como agora não existe nenhum peso que possa ser escolhido como máximo nalinha da palavra-chave research, é necessário mapear tal palavra-chave para um termode valor. Para tanto, é preciso contextualizar a Submatriz VW com base no mapeamentoparcial da Submatriz SW. Este mapeamento parcial é representado pelos mapeamentosindividuais das palavras-chave employees e deparment. Como estas palavras-chave foram


mapeadas para as relações Employee e Deparment, respectivamente, o processo decontextualização adiciona uma constante, neste caso 10, aos pesos referentes aos atributospertencentes à essas relações e que são diferentes de 0.

A Tabela 5.3 apresenta a Submatriz VW após esse processo de contextualização,bem como o mapeamento da palavra-chave research para o domínio do atributo Dname

da relação Department. O mapeamento total, isto é, a configuração, é formado pelosmapeamentos parciais das submatrizes SW e VW. Assim, a pontuação dessa configuraçãoé 200.

Tabela 5.2: Mapeamento parcial das palavras-chave para termosde esquema

D E D.Dna D.Dnu D.Mgr_ss D.Mgr_st E.Fn E.Mi E.Ln E.Ssn E.Bd E.Ad


research 0 0 0 0 0 0 0 0 0 0 0 -100

Tabela 5.3: Mapeamento parcial das palavras-chave para termosde valor

D.Dna D.Dnu D.Mgr_ss D.Mgr_st E.Fn E.Mi E.Ln E.Ssn E.Bd E.Ad

employees 0 0 0 0 0 0 0 0 0 0department 0 0 0 0 0 0 0 0 0 0

research 11* 0 11 0 11 11 11 11 0 11

Como se pode notar, a pontuação do primeiro mapeamento (Tabela 5.1) é maiorque a pontuação deste último mapeamento gerado. Contrariamente ao que é posto pelanoção de pontuação, o último mapeamento é mais relevante para a consulta do que oprimeiro mapeamento, por ser mais condizente com a semântica da consulta. Contudo,devido ao fato dos pesos intrínsecos dos termos de valor terem uma característica binária,o valor agregado por eles à pontuação total da configuração é miníno. Dito isso, é precisoque o valor dos pesos intrínsecos de termos de valor seja equiparado com o valor dospesos de termos de esquema. Dessa forma, após o cálculo dos pesos íntrínsecos para ostermos de valor, no método proposto por este trabalho os pesos que possuem valor 1 sãomultiplicados por uma constante pré-definida. O valor dessa constante foi definida como65, uma vez que o limiar considerado no cálculo dos pesos intrínsecos para termos deesquema foi 0.65. Este último valor, por sua vez, foi definido com base na quantidadeesperada de mapeamentos a serem gerados. Quanto maior o limiar, menor é o número demapeamentos gerados, porém melhor é a qualidade dos resultados retornados ao usuário,uma vez que à medida que os mapeamentos vão sendo gerados, sua pontuação, ou seja, arelevância em relação à consulta, decresce.


Proximidade entre as palavras-chave

Por fim, a última alteração interna à Keymantic foi realizada no processo de con-textualização. Conforme mencionado na Subseção 4.2.3, apesar do processo de contextu-alização aparecer explícito apenas no Passo 3 (Figura 5.1), assume-se que esse processotambém está sendo executado durante o Passo 2, uma vez que o processo de seleção dosmelhores mapeamentos faz uso das regras de contextualização para atualizar os pesosdurante a construção do mapeamento. Por este motivo, na Figura 5.1 o Passo 2 tambémestá destacado, simbolizando a modificação referente ao processo de contextualizaçãoutilizada neste passo.

Como mencionado no presente texto, a ferramenta Keymantic leva em conside-ração a interdependência entre as palavras-chave da consulta, onde o mapeamento de umapalavra-chave pode aumentar ou diminuir a probabilidade de que uma outra palavra-chaveainda não mapeada corresponda a um determinado termo do banco de dados. Como vistono mapeamento da Tabela 5.3, o mapeamento das palavras-chave employees e department

para as relações Employees e Department aumentou a probabilidade da palavra-chave re-

search ser mapeada para domínios de atributos pertencentes a estas relações. Este fato érepresentado durante processo de contextualização, onde é acrescida uma constante a to-dos os domínios de atributos pertencentes às relações Employee e Department. No caso daTabela 5.3, todos os domínios diferentes de 0 foram acrescidos da constante, isto porquea figura apresenta apenas os domínios dos atributos das tabelas Employee e Department.Caso a figura apresentasse todos os domínios de atributos presentes no banco de dadosCOMPANY, seria possível perceber que os demais domínios de atributos das tabelas res-tantes permaneceram com peso 1.

Como se pode perceber na Figura 5.3, apesar dos domínios dos atributos deambas relações possuirem maior valor que os demais domínios, entre si eles possuemo mesmo valor. A probabilidade da palavra-chave research ser mapeada para um domíniode atributo da relação Employee é a mesma probabilidade de ser mapeada para umdomínio de atributo da relação Department. Porém, essa não é a realidade. Com baseem observações de que os seres humanos tendem a escrever consultas em que palavras-chave relacionadas estão próximas umas das outras, o fato da palavra-chave research

estar próxima da palavra-chave deparment à qual foi mapeada para a relação Deparment,fornece uma forte indicação de que a palavra-chave research deve ser mapeada para umdomínio de atributo da relação Deparment.

Além de considerar as interdependências entre as palavras-chave, o métodoproposto neste trabalho considera as posições relativas destas palavras na consulta combase na proximidade entre elas. Quanto mais distante uma palavra-chave mapeada está deuma palavra-chave não mapeada, menor é sua influência no mapeamento desta palavra.


Este fato levou à seguinte modificação no processo de contextualização: ao invés deadicionar uma constante aos pesos intrínsecos, o valor acrescido ao peso é proporcionalà distância entre as palavras-chave em questão. A distância entre duas palavras-chave écalculada como a diferença entre suas posições relativas. No caso da consulta “employees

department research”, a distância entre department e research é 1, uma vez que a posiçãorelativa da palavra-chave department é 2 e da palavra research é 3, enquanto que adistância entre employees e research é 2.

Dessa forma, faz-se necessário uma alteração no algoritmo de contextualização(Algoritmo 4.3). Nas linhas 10, 16 e 21 onde é acrescida uma constante ∆w, essa constanteé substituída por ∆w/d, onde d é a distância entre k e k′.

Dito isso, a Tabela 5.4 apresenta a mesma Submatriz VW da Tabela 5.3, porémconsiderando a modificação no processo de contextualização. Como a constante consi-derada é 10 e a distância entre as palavras-chave department e research é 1, então ovalor adicionado aos pesos intrínsecos dos domínios de atributos da relação Department

é 10/1 = 10, totalizando 11. Enquanto que o valor adicionado aos pesos dos domínios deatributos da relaçao Employee é 10/2 = 5, totalizando 6.

Tabela 5.4: Mapeamento considerando a proximidade entre aspalavras-chave

D.Dna D.Dnu D.Mgr_ss D.Mgr_st E.Fn E.Mi E.Ln E.Ssn E.Bd E.Ad

employees 0 0 0 0 0 0 0 0 0 0department 0 0 0 0 0 0 0 0 0 0

research 11* 0 11 0 6 6 6 6 0 6


Analisando a ferramenta Keymantic é possível identificar certas limitações,como a impossibilidade de tratar consultas com funções agregadas e valores compostospor mais de uma palavra-chave. Com o intuito de superar tais limitações, o métodoproposto implementou novas funcionalidades externas e realizou modificações internasà ferramenta.

Entre as novas funcionalidades externas estão a capacidade de realizar consultascom funções agregadas, ordenação e valores compostos por mais de uma palavra-chave;identificar e ranquear os bancos de dados com informações relevantes para a consulta; eranquear os resultados retornados ao usuário de modo que os resultados mais relevantesserão apresentados antes dos demais.

As modificações internas dizem respeito aos três primeiros passos do processode Mapeamento. No Passo 1, o método proposto calcula os pesos para termos de esquemacom base na média das métricas de similaridade e considerando o uso de sinônimos emum segundo nível. Ainda nesse passo, faz uso de uma constante para equipar a pontuação


entre os pesos de termos de esquema e de termos de valor. A modificação nos passos 2 e3 se refere à alteração no processo de contextualização, de modo que além de consideraras interdependências entre as palavras-chave, o método proposto também considera aproximidade entre elas.

CAPÍTULO 6Aplicação do Método Proposto

A fim de exemplificar de forma mais detalhada o processo de mapeamentode uma consulta com palavra-chave em consultas SQL, executado pelo método pro-posto neste trabalho, serão apresentados dois estudos de caso. O primeiro englobao cenário referente às consultas que sugerem o uso de funções agregadas e ordena-ção. Durante o processamento desta consulta pela etapa Verificação de Função Agre-

gada/Ordenação/Valores Compostos, as palavras-chave referentes ao uso das funçõesagregadas e ordenação são retiradas da consulta, restando apenas palavras-chave que se-rão mapeadas para os termos do banco de dados. A consulta resultante dessa “limpeza”de palavras-chave servirá para exemplificar o mapeamento de uma consulta onde todasas palavras-chave são mapeadas para termos de esquema. O segundo estudo de caso irádetalhar o mapeamento de uma consulta que faz uso de valores compostos por mais deuma palavra-chave. Além disso, em oposição ao primeiro estudo de caso, o segundo apre-sentará o mapeamento de uma consulta onde nem todas as palavras-chave são mapeadaspara termos de esquema, ou seja, algumas palavras-chave são mapeadas para valores deatributos.

Para fins de exemplificação e simplificação, um único banco de dados seráconsiderado. Dessa forma, as etapas de Identificação dos banco de dados relevantes eRanking dos bancos relevantes serão desconsideradas nos estudos de caso a seguir. Paraambos os estudos de caso, será considerado o esquema e os dados do banco de dadosCOMPANY.

Após apresentada a seção de estudos de caso será estabelecido um comparativoentre os resultados gerados pela ferramenta Keymantic e o presente método, elucidandoas melhorias originadas pelas modificações propostas.

6.1 Estudos de Caso

Esta seção detalha passo a passo o processo de mapeamento realizado pelométodo proposto por meio de dois exemplos de consulta com palavras-chave. Taisexemplos estão apresentados nas duas subseções seguintes.

6.1 Estudos de Caso 67

6.1.1 Estudo de Caso - Funções Agregadas e Ordenação

Como mencionado no Capítulo 3, o processo de verificação de função agregadae de ordenação é baseado em uma lista de palavras “reservadas” pré-definidas, quepermitem a identificação das palavras-chave da consulta que sugerem o uso destasfunções. Estas palavras “reservadas” são agrupadas de acordo com a função por elassugeridas. Foram criados 7 grupos e para cada grupo é definido o conjunto de palavras-chave que o representa. Um conjunto mais representativo poderia ser obtido acoplandoum thesaurus ao sistema. Os grupos e seus respectivos conjuntos de palavras-chave sãolistados a seguir:

• O grupo maximo contém as palavras-chave que sugerem o uso da função agregadamax e é formado pelo seguinte conjunto de palavras-chave, maximo = {higher,

highest, maximum, maximal, larger, largest, greater, greatest, max}.• O grupo minimo contém as palavras-chave que sugerem o uso da função agregada

min e é formado pelo seguinte conjunto de palavras-chave, minimo = {lower,

lowest, minimal, minimum, smaller, smallest, least, shorter, shortest, min}.• O grupo media contém a palavra-chave average que sugere o uso da função

agregada avg, media = {average, mean, avg}.• O grupo soma contém as palavras-chave que sugerem o uso da função agregada

sum, soma = {total, sum}.• O grupo conta contém as palavras-chave que sugerem o uso da função agregada

count e é formado pelo seguinte conjunto de palavras-chave, conta = {quantity,

amount, count}.• O grupo agrupamento contém as palavras-chave que sugerem o uso da função

de agrupamento group by e é formado pelo seguinte conjunto de palavras-chave,agrupamento = {for each, for all, grouped by, aggregate by}.• O grupo ordenacao contém as palavras-chave que sugerem o uso da função de orde-

nação order by e é formado pelo seguinte conjunto de palavras-chave, ordenacao

= {order by, descending order by, ascending order by, sorted by, ranked by, classi-

fied by, organized by}. Neste grupo, ainda é feita uma verificação adicional. Caso aconsulta contenha a palavra-chave descending, então além do uso da cláusula orderby é usada a claúsula desc.

Após identificar qual palavra-chave sugere o uso de funções agregadas ou deordenação, é necessário identificar sobre qual atributo a função será aplicada. Como jámencionado, os usuários constroem consultas onde palavras relacionadas estão próximasumas das outras. Desta forma, após a identificação da palavra-chave que sugere o uso deuma função agregada ou de ordenação, a função por ela sugerida é aplicada ao termo dobanco representado pela palavra-chave imediatamente posterior.



Considere a consulta “quantity employees for each department order by name”.As palavras-chave quantity, for each e order by são identificadas como o uso das funçõescount, group by e order by, respectivamente. Até este momento, nenhuma palavra-chave foi mapeada para um termo do banco de dados, então limita-se a dizer queestas funções identificadas serão aplicadas aos termos representados pelas palavras-chaveemployees, department e name. As palavras-chave identificadas como funções agregadasou de ordenação são eliminadas da consulta, restando apenas as palavras-chave quedesempenham um papel no banco de dados. A consulta resultante desta etapa é a consulta“employees department name”.


Para cada palavra-chave da consulta resultante da etapa anterior, são obtidos seussinônimos a partir do WordNet e estes sinônimos são então adicionados à consulta. Ao fimdesta etapa, a consulta expandida é a seguinte: “employees employee department section

name figure gens”.A próxima etapa é a etapa de Mapeamento. Como visto no Capítulo 3, esta etapa

é dividida em cinco passos.

Cálculo dos pesos intrínsecos (Passo 1)

O Passo 1 é composto pelo Cálculo dos pesos intrínsecos dos termos de esquema

do banco de dados e pelo Cálculo dos pesos intrínsecos dos termos de valor do banco de

dados.O método proposto por este trabalho calcula os pesos intrínsecos dos termos de

esquema com base inicialmente nas métricas de similaridade entre strings e, caso neces-sário, faz uso dos sinônimos destas palavras. No caso da consulta deste estudo de caso,a similaridade entre as palavras-chave e os termos do banco de dados subjacente é maiorque o limiar (0.65), dispensando, assim, o uso dos sinônimos. A Tabela 6.1 apresenta ospesos intrínsecos referente aos termos de esquema (Submatriz SW ). Por motivos de es-paço, a figura não apresenta todos os termos de esquema (relações e atributos) do bancode dados COMPANY, limitando-se apenas àqueles que serão necessários ao contexto domapeamento da consulta em questão.

Os pesos intrínsecos dos termos de valor são calculados com base no uso deexpressões regulares. Se um valor é compatível com o domínio de um determinadoatributo, então o peso é definido como 1, caso contrário, como 0. Para normalizar os


Tabela 6.1: Pesos intrínsecos da Submatriz SW (consulta “quantityemployees for each department order by name”)

D E D.Dna D.Dnu D.Mgr_ss D.Mgr_st E.Fn E.Mi E.Ln E.Ssn E.Bd E.Ad E.Dno P.Pna


name 0 0 83 0 0 0 83 0 83 0 0 0 0 83

pesos intrínsecos dos termos de esquema e de valor, os pesos dos termos de valor sãomultiplicados por uma constante, definida como 65. A Tabela 6.2 apresenta os pesosintrínsecos referente aos termos de valor (Submatriz VW ) para a consulta do presenteestudo de caso.

Tabela 6.2: Pesos intrínsecos da Submatriz VW (consulta “quan-tity employees for each department order by name”)

D.Dna D.Dnu D.Mgr_ss D.Mgr_st E.Fn E.Mi E.Ln E.Ssn E.Bd E.Ad E.Sex E.Su E.Dno P.Pna


name 65 0 65 0 65 65 65 65 0 65 65 65 0 65

Seleção dos Melhores Mapeamentos para os termos de esquema (Passo 2)

Nesse passo, o maior peso de cada linha é considerado como máximo. Caso cadapeso considerado como máximo esteja em uma coluna diferente, então um mapeamentoé gerado associando cada palavra-chave ao termo do banco de dados referente à colunado peso caracterizado como máximo. Na Tabela 6.3, os pesos 89 da linha 1, 100 da linha2, e 83 da linha 3 são escolhidos como máximos. Como cada peso escolhido está emuma coluna diferente, temos um mapeamento formado pelos mapeamentos individuaisdas palavras-chave employees, department, name para os termos Employee, Department,

Dname. A pontuação deste mapeamento é calculada como a soma dos pesos íntrinsecosselecionados como máximo, resultando em 272.

Tabela 6.3: Mapeamento da consulta “quantity employees foreach department order by name”


employees 0 89* 0 0 0 0 0 0 0 0 0 0 0 0department 100* 0 0 0 0 0 0 0 0 0 0 0 0 0

name 0 0 83* 0 0 0 83 0 83 0 0 0 0 83

Uma vez gerado o melhor mapeamento, o processo de seleção dos melhoresmapeamentos gera novos mapeamentos atribuindo um valor negativo aos mapeamentosindividuais já realizados, de modo a não repetí-los. Assim, a partir do mapeamento daTabela 6.3, são gerados os três mapeamentos apresentados nas tabelas 6.4, 6.5, 6.6.

Contudo, o algoritmo de seleção dos melhores mapeamentos seleciona apenasos mapeamentos com pontuação maior que um determinado limiar. No método proposto,o limiar considerado foi 90% da pontuação do melhor mapeamento, com base na ideia


Tabela 6.4: Primeiro mapeamento gerado a partir do mapeamentoda Tabela 6.3


employees 0 -100 0 0 0 0 0 0 0 0 0 0 0 0department 100* 0 0 0 0 0 0 0 0 0 0 0 0 0

name 0 0 83* 0 0 0 83 0 83 0 0 0 0 83

Tabela 6.5: Segundo mapeamento gerado a partir do mapeamentoda Tabela 6.3


employees 0 89* 0 0 0 0 0 0 0 0 0 0 0 0department -100 0 0 0 0 0 0 0 0 0 0 0 0 0

name 0 0 83* 0 0 0 83 0 83 0 0 0 0 83

Tabela 6.6: Terceiro mapeamento gerado a partir do mapeamentoda Tabela 6.3



name 0 0 -100 0 0 0 83* 0 83 0 0 0 0 83

que quanto maior o limiar, menor o número de resultados e melhor a qualidade destesresultados. Com base nisso, os mapeamentos das tabelas 6.4 e 6.5 são desconsiderados,uma vez que suas pontuações, 183 e 172, respectivamente, estão abaixo do limiar definido(272∗0.9 = 244).

O algoritmo de seleção é executado até o ponto em que nenhum dos mapeamen-tos gerados possua pontuação acima do limiar. Como o mapeamento da Tabela 6.6 possuipontuação acima do limiar, são gerados a partir dele os três mapeamentos apresentadosnas tabelas 6.7, 6.8 e 6.9.

Tabela 6.7: Primeiro mapeamento gerado a partir do mapeamentoda Tabela 6.6


employees 0 -100 0 0 0 0 0 0 0 0 0 0 0 0department 100* 0 0 0 0 0 0 0 0 0 0 0 0 0

name 0 0 -100 0 0 0 83* 0 83 0 0 0 0 83

Tabela 6.8: Segundo mapeamento gerado a partir do mapeamentoda Tabela 6.6


employees 0 89* 0 0 0 0 0 0 0 0 0 0 0 0department -100 0 0 0 0 0 0 0 0 0 0 0 0 0

name 0 0 -100 0 0 0 83* 0 83 0 0 0 0 83

De modo semelhante, por possuir pontuação abaixo do limiar, os mapeamentosdas tabelas 6.7 e 6.8 são desconsiderados, e por posuir pontuação acima do limiar, sãogerados novamente mais três mapeamentos a partir do mapeamento da Subfigura 6.9. AFigura 6.10 apresenta apenas um dos mapeamentos gerados, uma vez que os outros doismapeamentos também serão desconsiderados seguindo o mesmo raciocínio anterior.

A partir do mapeamento da Figura 6.10, novamente são gerados mais três mape-amentos, porém nenhum desses mapeamentos agora possuem pontuação acima do limiar.


Tabela 6.9: Terceiro mapeamento gerado a partir do mapeamentoda Tabela 6.6



name 0 0 -100 0 0 0 -100 0 83* 0 0 0 0 83

Tabela 6.10: Mapeamento gerado a partir do mapeamento da Ta-bela 6.9



name 0 0 -100 0 0 0 -100 0 -100 0 0 0 0 83*

Ao gerar o primeiro mapeamento, o valor 89 da primeira linha será negativado, restandonenhum peso a ser escolhido como máximo nessa linha. Dessa forma, a pontuação domapeamento será calculada apenas com os pesos máximos das segunda e terceira linhas,100+ 83 = 183. Ao gerar o segundo mapeamento, o valor 100 da segunda linha seránegativado e o mapeamento irá possuir pontuação 89+ 83 = 172. Ao gerar o terceitomapeamento, o valor 83 da terceira linha será negativado resultando em uma pontuação100+89 = 189.

Uma vez que nenhum dos mapeamentos possui pontuação acima do limiar, oalgoritmo de seleção dos melhores mapeamentos pára e retorna o conjunto de mapea-mentos selecionados, ou seja, aqueles que foram gerados e possuem pontuação acima dolimiar. No caso da consulta deste estudo de caso, o conjunto retornado é formado pelosmapeamentos das tabelas 6.3, 6.6, 6.9 e 6.10.

Contextualização de VW e Seleção dos Melhores Mapeamentos para os termos devalor (Passo 3)

Para cada mapeamento gerado na etapa anterior, é realizado o processo decontextualização da Submatriz VW e selecionados os melhores mapeamentos para ostermos de valor, seguindo a mesma ideia. Porém, como todas as palavras-chave já forammapeadas para termos de esquema durante o Passo 2, ao ser realizado o processo decontextualização, todos os pesos das linhas em VW correspondentes a estas palavras-chave já mapeadas serão definidos como 0. Assim, nenhum mapeamento gerado para ostermos de valor possuirá pontuação maior que 0 e o algoritmo de seleção de melhoresmapeamentos não retornará nenhum mapeamento referente a termos de valor.

Geração das Configurações (Passo 4)

As configurações serão formadas apenas pelos mapeamentos referentes à Sub-matriz SW . Assim, cada um dos 4 mapeamentos retornados no Passo 2 formam uma


configuração, totalizando 4 configurações.Para a configuração formada pelo mapeamento da Tabela 6.3, temos que a

palavra-chave employees foi mapeada para a relação Employee, a palavra-chave de-

partment para a relação Department e a palavra-chave name para o atributo Dname

da relação Department. Lembre-se que durante a etapa Verificação de Função Agre-

gada/Ordenação/Valores Compostos foram identificadas algumas palavras-chave comorepresentações de funções agregadas e de ordenação, e essas funções seriam aplicadassobre os termos para os quais as palavras-chave employees, department e name seriammapeadas. Neste momento, é possível saber sobre quais termos essas funções serão apli-cadas. A palavra-chave quantity que foi identificada como o uso da função count seráaplicada ao termo representado pela palavra-chave employees, neste caso a relação Em-

ployee. Da mesma forma, a palavra-chave for each identificada como uso da cláusula deagrupamento group by será aplicada à relação Department e por fim, a palavra-chave or-

der by identificada como uso da claúsula de ordenação order by será aplicada ao atributoDname.

Contudo, essas funções só podem ser aplicadas à atributos. O usuário, porém,não possui conhecimento do esquema do banco de dados de maneira a construir umaconsulta onde as palavras-chave sobre as quais serão aplicadas as funções representematributos. Considerando esse fato, o método proposto oferece uma solução para esteproblema. Quando o usuário constrói a consulta de modo que a palavra-chave sobre a qualserá aplicada a função representa uma relação ao invés de um atributo, então a função éaplicada à chave primária desta relação. Caso a chave primária seja composta, é usadaapenas um dos atributos que compõem essa chave. Assim, a função count será aplicada àchave primária Ssn da relação Employee enquanto que a função group by será aplicada àchave primária Dnumber da relação Department.

Outro detalhe a ser lembrado, é que a ferramenta Keymantic não permite queduas palavras-chave sejam mapeadas para um mesmo termo do banco de dados. Isso égarantido pelo algoritmo de seleção de melhores mapeamentos, que verifica a existênciade mais de um peso caracterizado como máximo na mesma coluna. Caso haja, todos ospesos desta coluna são descaracterizados como máximo exceto o maior deles.

Por este motivo, a construção de uma consulta como “quantity employees for

each department order by department” não é aconselhável. Apesar de representar umasemântica semelhante (não igual) à consulta deste estudo de caso, os resultados destaconsulta iriam apresentar resultados semanticamente diferentes. Veja na Tabela 6.11 ospesos instrínsecos referentes à Submatriz SW desta consulta. Durante o processo demapeamento, os pesos 89 da linha 1 e os pesos 100 das linhas 2 e 3 seriam escolhidoscomo máximo. Porém, como haveriam dois pesos escolhidos como máximo na coluna 3,um deles seria descaracterizado como máximo. Como as linhas são verificadas de cima


para baixo, o valor 100 da segunda linha seria escolhido como o maior valor, uma vez que,quando verificado na terceira linha, o valor 100 desta linha não é maior que o valor já tidocomo maior. Assim, o valor 100 da terceira linha seria descaracterizado como máximo,e o segundo maior valor desta linha seria caracterizado como máximo, no caso o valor67. Consequentemente, a última palavra-chave department seria mapeada para a relaçãoDependent, o que não representa a semântica correta da palavra-chave.

Tabela 6.11: Mapeamento da consulta “quantity employees foreach department order by department”

Depa E Depe Dept P Wemployees 0 89* 0 0 0 0department 100* 0 67 0 0 0department 100 0 67* 0 0 0

Geração das Interpretações (Passo 5)

Uma vez computadas as melhores configurações, as interpretações da consultacom palavra-chave, isto é, as consultas SQL, são geradas. A presença de diferentescaminhos de junções permite que uma configuração gere diversas interpretações.

Para o primeiro mapeamento gerado, em que as palavras-chave employees, de-

partment e name foram mapeadas para os termos Employee, Department e Dname, énecessário o uso das informações das tabelas Employee e Department. Assim, essas duastabelas estarão na claúsula from da consulta SQL gerada. Existem três caminhos de jun-ção entre estas duas tabelas no esquema do banco de dados COMPANY. Os caminhosdiretos entre Employee e Department por meio dos pares <chave primária,chave estran-geira> <Dno, Dnumber> e <Ssn, Mgr_ssn>, e o caminho formado pela junção entre De-

partment-Project-Works_on-Employee. Assim, temos três interpretações possíveis para oprimeiro mapeamento. Cada interpretação será construída da seguinte forma: as funçõesagregadas identificadas são aplicadas aos atributos definidos no mapeamento e são co-locadas na claúsula select. As relações necessárias são colocadas na cláusula from e ajunção entre elas é colocada na cláusula where. As claúsulas de agrupamento (group by)e ordenação (order by) são aplicadas aos atributos também definidos no mapeamento esão colocadas após a cláusula where. O Código 6.1 apresenta estas três interpretações.

Na segunda configuração, as palavras-chave employees, department também sãomapeadas para as relações Employee e Department, respectivamente. A única diferença éque a palavra-chave name é mapeada para o atributo Fname da relação Employee.


Código 6.1 Código da primeira configuração para a consulta“quantity employees for each department order by department”

1 /* Interpretação do caminho de junção por meio do par

2 * chave-primária-chave-estrangeira <ssn, mgr_ssn>*/

3 select distinct count(employee.ssn), department.dname

4 from department, employee

5 where employee.ssn = department.mgr_ssn

6 group by department.dnumber

7 order by department.dname

8


10 * chave-primária-chave-estrangeira <dno, dnumber>*/



13 where department.dnumber = employee.dno



16

17 /* Interpretação do caminho de junção entre

18 * Department-Project-Works_on-Employee*/


20 from project, works_on, department, employee

21 where department.dnumber = project.dnum

22 AND project.pnumber = works_on.pno

23 AND employee.ssn = works_on.essn



Dessa forma, as tabelas necessárias para essa configuração também são Em-

ployee e Department, e também existem 3 interpretações possíveis para esta configuração.O Código 6.2 apresenta as consultas SQL referentes à segunda configuração.

A única diferença entre a terceira configuração e as duas últimas, é que naterceira configuração a palavra-chave name é mapeada para o atributo Lname da relaçãoEmployee. Assim, novamente são geradas três interpretações semelhantes as anteriores.


Código 6.2 Código SQL da segunda configuração para a consulta“quantity employees for each department order by department”



3 select distinct count(employee.ssn), employee.fname




7 order by employee.fname

8





13 where department.dnumber = employee.dno



16


18 * Department-Project-Works_on-Employee*/


20 from project, works_on, department, employee

21 where department.dnumber = project.dnum AND

22 project.pnumber = works_on.pno AND employee.ssn = works_on.essn



Na quarta e última configuração, as palavras-chave employees e department sãomapeadas para as relações Employee e Department e a palavra-chave name mapeadapara o atributo Pname da relação Project. Assim, é necessário o uso das informações dastabelas Employee, Deparment e Project. O número de possíveis caminhos de junção entreestas 3 tabelas é 4, gerando assim 4 interpretações que estão representadas no Código 6.3.

Cada uma destas interpretações é executada no banco de dados e então osresultados retornados pela execução dessas interpretações são ordenados.

Ranking do resultados

Durante esta etapa os resultados são ordenados primariamente pela pontuação daconfiguração correspondente e secundariamente pelo tamanho do caminho de junção


Código 6.3 Código SQL da quarta configuração para a consulta“quantity employees for each department order by department”


2 * Employee-Department-Project usando o par


4 select distinct count(employee.ssn), project.pname

5 from department, employee, project


7 AND project.dnum = department.dnumber


9 order by project.pname

10


12 * Employee-Department-Project usando o par



15 from department, employee, project

16 where employee.dno = department.dnumber

17 AND project.dnum = department.dnumber



20


22 * Project-Works_on-Employee-Department usando o par



25 from department, employee, project, works_on

26 where project.pnumber = works_on.pno

27 AND employee.ssn = works_on.essn AND employee.ssn = department.mgr_ssn



30


32 * Project-Works_on-Employee-Department usando o par



35 from department, employee, project, works_on

36 where project.pnumber = works_on.pno

37 AND employee.ssn = works_on.essn AND employee.dno = department.dnumber




da interpretação correspondente. Como todas as configurações geradas nesteestudo de caso possuem a mesma pontuação (272), os resultados ficarão ordenadospelo tamanho do caminho de junção. Desta forma, os resultados das interpretações quepossuem menor caminho de junção irão aparecer primeiro para o usuário.

Nem todos os resultados obtidos pela execução destas interpretações são exibi-dos para o usuário. Mapeamentos diferentes, podem gerar as mesmas interpretações, ea execução destas interpretações geram os mesmos resultados. Além disso, algumas in-terpretações, quando executadas no banco de dados subjacente, retornam um conjuntovazio (Empty set) de resultado. Assim, resultados repetidos e a falta de resultados não sãoretornados ao usuário.

6.1.2 Estudo de Caso - Valores Compostos

No método proposto, valores que são compostos por mais de uma palavra-chave,são apresentados entre aspas simples. No caso da consulta “ employees ‘Houston Tx’ ”,o fato das palavras-chave Houston e Tx estarem entre aspas simples sugere que ambaspalavras representam conjuntamente um único valor. Esta será a consulta utilizada comoexemplo neste estudo de caso.


Durante esta etapa, a consulta com palavras-chave é segmentada em duaspalavras-chave employees e ‘Houston Tx’.


Uma vez que a palavra-chave composta por Houston e Tx representa um valor,apenas os sinônimos das demais palavras-chave são obtidos. Dessa forma, a consultaexpandida resultante é “ employees employee ‘Houston Tx’ ”.


No método proposto, durante o cálculo dos pesos para termos de esquema, umavez que a palavra-chave ‘Houston Tx’ representa um termo de valor, todos os pesos dalinha em SW correspondente à esta palavra-chave são definidos como 0, garantindo queesta palavra-chave não seja mapeada para um termo de esquema. Para a palavra-chaveemployees, o cálculo dos pesos intrínsecos é feito da maneira habitual proposta pelométodo apresentado neste trabalho. Ou seja, o cálculo é feito com base inicialmente nasmétricas de similaridade entre strings e, caso necessário, faz uso dos sinônimos destas


palavras. A Tabela 6.12 apresenta uma fração dos pesos intrínsecos referentes aos termosde esquema (Submatriz SW ). Os pesos intrínsecos referentes aos termos de esquemasomitidos na figura possuem todos valor 0.

Tabela 6.12: Pesos intrínsecos da Submatriz SW (consulta “ em-ployees ‘Houston Tx’ ”)

D E D.Dna D.Dnu D.Mgr_ss D.Mgr_st E.Fn E.Mi E.Ln E.Ssn E.Bd

employees 0 89 0 0 0 0 0 0 0 0 0‘Houston Tx’ 0 0 0 0 0 0 0 0 0 0 0

O cálculo dos pesos intrínsecos para termos de valor, também é executado damaneira habitual, fazendo uso de expressão regulares e de uma constante de normalização.Como a palavra-chave ‘Houston Tx’ é um conjunto de caracteres, todos os atributoscompatíveis com este tipo possuem peso 1, enquanto que os atributos incompatíveispossuem peso 0. Estes pesos são então multiplicados pela constante de normalização.A Tabela 6.13 apresenta uma fração dos pesos intrínsecos referentes aos termos de valor.

Tabela 6.13: Pesos intrínsecos da Submatriz VW (consulta “ em-ployees ‘Houston Tx’ ”)

D.Dna D.Dnu D.Mgr_ss E.Fn E.Mi E.Ln E.Ssn E.Bd E.Ad E.Sex E.Su E.Dno P.Pl W.Es

employees 65 0 65 65 65 65 65 0 65 65 65 0 65 0‘Houston Tx’ 65 0 65 65 65 65 65 0 65 65 65 0 65 0

Seleção dos melhores mapeamentos para termos de esquema (Passo 2)

A partir do algoritmo de seleção dos melhores mapeamento é gerado o melhormapeamento, o qual está apresentado na Tabela 6.14.

Tabela 6.14: Mapeamento da consulta “employees ‘Houston Tx”’D E D.Dna D.Dnu D.Mgr_ss D.Mgr_st E.Fn E.Mi E.Ln E.Ssn E.Bd

employees 0 89* 0 0 0 0 0 0 0 0 0‘Houston Tx’ 0 0 0 0 0 0 0 0 0 0 0

A partir deste mapeamento, é possível gerar um novo mapeamento onde o valor89 da primeira linha é negativado. Porém, a pontuação deste novo mapeamento é 0. Sendoassim, tal mapeamento é desconsiderado e o algoritmo de seleção termina, uma vez quenão é mais possível gerar novos mapeamentos para termos de esquema com pontuaçãoacima do limiar.


Terminado o processo de seleção dos melhores mapeamentos para termos deesquema, a Submatriz VW é contextualizada com base em cada um dos mapeamentos


gerados na etapa anterior. Os pesos da Submatriz VW da Tabela 6.13 são atualizados deacordo com as regras de contextualização, resultando na Submatriz VW atualizada daTabela 6.15.

Tabela 6.15: Submatriz VW contextualizada com base no mapea-mento da Tabela 6.14


employees 0 0 0 0 0 0 0 0 0 0 0 0 0 0‘Houston Tx’ 65 0 65 75 75 75 75 0 75 75 75 0 65 0

Durante o processo de contextualização é realizado um passo de inicialização,onde os pesos referentes às linhas das palavras-chave já mapeadas são definidos como0. Por esta razão, os pesos da primeira linha foram todos zerados. Como é possívelobservar na segunda linha, os valores dos pesos dos domínios de atributos referentes àrelação Employees foram os únicos atualizados. Isso se deve ao fato da palavra-chaveemployees ter sido mapeada para à relação Employee. Assim, todos os pesos dos domíniosde atributos pertencentes a essa relação foram acrescidos de uma constante, no caso 10.Vale lembrar que durante o processo de contextualização é considerada a proximidadeentre as palavras-chave. No caso desta consulta, como a distância entre as palavras-chaveemployees e ‘Houston Tx’ é 1, o valor adicionado aos pesos foi 10/1 = 10, ou seja, opróprio valor da constante.

A partir da Submatriz VW contextualizada é possível então gerar os mapeamen-tos para os termos de valor. Primeiramente, é gerado o mapeamento apresentado na Tabela6.16.

Tabela 6.16: Mapeamento para termos de valor (consulta “em-ployees ‘Houston TX”’)


employees 0 0 0 0 0 0 0 0 0 0 0 0 0 0‘Houston Tx’ 65 0 65 75* 75 75 75 0 75 75 75 0 65 0

Com base neste mapeamento, é possível então gerar o mapeamento da Tabela6.17 negativando o peso da coluna referente ao mapeamento já gerado.

Tabela 6.17: Mapeamento gerado a partir do mapeamento da Ta-bela 6.16


employees 0 0 0 0 0 0 0 0 0 0 0 0 0 0‘Houston Tx’ 65 0 65 -100 75* 75 75 0 75 75 75 0 65 0

Este processo é repetido até que todos os pesos com valores iguais à 75 tenhamsido negativados e seja gerado o seguinte mapeamento (Tabela 6.18). Este mapeamentopor sua vez possui pontuação abaixo do limiar (75∗0.9 = 67 > 65), sendo então descon-siderado e encerrado o algoritmo de seleção de mapeamento.


Tabela 6.18: Mapeamento gerado após negativar os pesos iguaisà 75


employees 0 0 0 0 0 0 0 0 0 0 0 0 0 0‘Houston Tx’ 65 0 65 -100 -100 -100 -100 0 -100 -100 -100 0 65 0

Uma vez que a segunda linha da Submatriz VW atualizada da Tabela 6.15 possui7 pesos intrínsecos com valores iguais à 75, é possível então gerar 7 mapeamentos determos de valor.


Para o mapeamento SW da Tabela 6.14 tem-se 7 mapeamentos correspondentespara termos de valor (VW ). O mapeamento SW e os 7 mapeamentos VW são parciais, jáque são considerados isoladamente um do outro e nenhum deles possui o mapeamentode todas as palavras-chave da consulta. Para cada par <SW , VW> correspondente égerada uma configuração que então representa o mapeamento total das palavras-chave,totalizando 7 configurações.


Como se pode notar, apenas a tabela Employee é necessária para a construçãodas consultas SQL. Dessa forma, não existem caminhos de junção e, consequentementepara cada configuração é gerada apenas uma interpretação. As 7 interpretações resultantesdestas configurações estão apresentadas no Código 6.4. A primeira interpretação se refereà primeira configuração gerada (tabelas 6.14 e 6.16), a segunda interpretação à segundaconfiguração gerada (tabelas 6.14 e 6.17) e assim sucessivamente.

Como se pode perceber, em cada interpretação a cláusula select possui todosos atributos da tabela Employee. Essa é a solução proposta neste trabalho para o casoem que a cláusula select fica vazia. Ou seja, como nenhuma palavra-chave foi mapeadapara um atributo do banco de dados, nenhum atributo será colocado na cláusula select,permanecendo esta vazia. Como é obrigatório o uso desta claúsula em uma consulta SQL,quando isto ocorre são listados na cláusula select todos os atributos das tabelas contidasna cláusula from.

Também é possível notar que as palavras-chave mapeadas para valores de atri-butos são verificadas na cláusula where, juntamente com as junções das tabelas, quandohouver.


Código 6.4 Código SQL gerado para consulta “ employees ‘Houston Tx’ ”1 select distinct employee.minit, employee.lname, employee.ssn,

2 employee.bdate, employee.address, employee.sex, employee.salary,

3 employee.super_ssn, employee.dno

4 from employee

5 where employee.fname like ’%houston%’ AND employee.fname like ’%tx%’

6

7 select distinct employee.fname, employee.lname, employee.ssn,



10 from employee

11 where employee.minit like ’%houston%’ AND employee.minit like ’%tx%’

12

13 select distinct employee.fname, employee.minit, employee.ssn,



16 from employee

17 where employee.lname like ’%houston%’ AND employee.lname like ’%tx%’

18

19 select distinct employee.fname, employee.minit, employee.lname,



22 from employee

23 where employee.ssn like ’%houston%’ AND employee.ssn like ’%tx%’

24


26 employee.ssn, employee.bdate, employee.sex, employee.salary,


28 from employee

29 where employee.address like ’%houston%’ AND employee.address like ’%tx%’

30


32 employee.ssn, employee.bdate, employee.address, employee.salary,


34 from employee

35 where employee.sex like ’%houston%’ AND employee.sex like ’%tx%’

36


38 employee.ssn, employee.bdate, employee.address, employee.sex,

39 employee.salary, employee.dno

40 from employee

41 where employee.super_ssn like ’%houston%’ AND employee.super_ssn like ’%tx%’

6.2 Comparação com a Keymantic 82

Ranking do resultados

Cada uma dessas interpretações é executada e os seus resultados retornados aousuário. Como todas as interpretações possuem a mesma pontuação (75) e não possuemcaminho de junção, os resultados são apresentados ao usuário com base na ordem emque as interpretações foram geradas . Contudo, apenas o resultado referente à execuçãoda quinta interpretação do Código 6.4 é apresentado ao usuário. Esta interpretação serefere ao mapeamento do valor Houston Tx para o atributo Address da relação Employee.A execução das demais interpretações retorna um conjunto vazio de resultados, uma vezque nenhum dos atributos da relação Employee, exceto o atributo Address, possui o valorHouston Tx.

6.2 Comparação com a Keymantic

A seção anterior apresentou o funcionamento do método proposto por estetrabalho, detalhando a entrada e a saída de cada etapa, até a execução de cada interpretaçãogerada e o retorno dos resultados ordenados ao usuário. Os estudos de caso utilizadosenglobaram as modificações externas e internas à Keymantic a fim de cobrir o métodoproposto por completo.

Por outro lado, esta seção visa a elucidar quais são os impactos causados porestas modificações no conjunto de resultados apresentado ao usuário. Para tanto é feitoum comparativo entre a ferramenta Keymantic e o método proposto por este trabalho.

Imediatamente é possivel perceber que as modificações externas representamuma melhoria evidente à ferramenta, uma vez que elas permitem consultas até então nãorealizadas pela Keymantic, como consultas com o uso de funções agregadas, ordenaçãoe valores compostos por mais de uma palavra-chave. Quanto às modificações internas àKeymantic o comparativo é realizado com base na execução de uma consulta em comumem ambos sistemas, de forma a identificar as diferenças entre as saídas de cada etapa doprocesso de Mapeamento da consulta.

6.2.1 Suposições à implementação Keymantic

Apesar dos esforços, não se conseguiu encontrar a implementação da ferramentaKeymantic. Neste sentido, para realizar o comparativo foi necessário realizar uma imple-mentação própria. Esta implementação, bem como a implementação do método propostoneste trabalho, foram baseadas nas informações contidas no artigo que descreve a ferra-menta ([4]). O artigo não é claro o suficiente para permitir uma implementação fiel. Destaforma, algumas suposições foram feitas e alguns detalhes omitidos.


Uma das suposições feitas é o uso do processo de contextualização no processode seleção dos melhores mapeamentos para os termos de esquema. Como mencionado noCapítulo 4, a figura do processo de Mapeamento (Figura 4.1) apresenta explicitamente oprocesso de contextualização apenas para os termos de valor (Passo 3). Na explicação doprocesso de seleção dos melhores mapeamentos, o artigo apenas cita o uso de regras decontextualização neste processo. Como o processo de seleção dos melhores mapeamentosé o mesmo tanto para termos de esquema como para termos de valor, assumiu-se que acontextualização também é realizada no Passo 2. Assumiu-se, também, que as regras decontextualização só são utilizadas quando ocorre o fato de duas palavras-chave seremmapeadas para o mesmo termo do banco, ou seja, existir mais de um peso caracterizadocomo máximo na mesma coluna. Então, todos os pesos definidos como máximo sãodescaracterizados, exceto o maior, e os pesos das linhas correspondentes aos pesosdescaracterizados são atualizados com as regras de contextualização. Caso nenhumacoluna tenha mais de um peso caracterizado como máximo, não é necessário atualizaros pesos, e consequentemente as regras de contextualização não são necessárias.

Também foi necessário assumir que quando nenhuma palavra-chave é mapeadapara um atributo, permanecendo a cláusula select vazia, todos os atributos das tabelas queestão na cláusula from são colocados na cláusula select.

Em relação aos detalhes omitidos, durante o cálculo dos pesos intrínsecos paratermos de esquema a implementação não faz uso de ontologias e durante o cálculo dospesos intrínsecos para termos de valor não se faz uso do conceito de semantic relatedness.Os pesos intrínsecos de termos de esquema são calculados com base apenas nas métricasde similaridade de string e faz uso dos sinônimos obtidos pelo WordNet, enquanto queos pesos intrínsecos de termos de valor são calculados com base no uso de expressõesregulares apenas.

6.2.2 Exemplo selecionado para Comparação

Uma vez implementados os dois sistemas, é possível compará-los com basenos resultados retornados por cada um a partir da execução de uma mesma consultacom palavras-chave. Os exemplos de consulta das seções anteriores já executados pelométodo proposto não podem ser utilizados para o propósito deste comparativo, vistoque a ferramenta Keymantic não é capaz de processar consultas com funções agregadas,de ordenação e valores compostos por mais de uma palavra-chave. Assim, a consultaexemplo desta seção será a consulta “employees department research” do Exemplo1 (Capítulo 4), cuja semântica pretendida é encontrar os empregados que trabalham nodepartamento de nome Research.

Para cada sistema, será apresentada a saída e a entrada de cada etapa do processo


de Mapeamento correspondente e comentadas as diferenças entre eles, caso haja. Parasimplificar, a partir deste momento o método proposto será referenciado como MP.


Dada a consulta “employees department research”, a Tabela 6.19 apresentauma fração dos pesos intrínsecos calculados para termos de esquema pelo MP, enquantoque a Tabela 6.20 apresenta os pesos calculados pela Keymantic. Os termos de esquemaomitidos nas figuras possuem peso igual a 0.

Tabela 6.19: Pesos intrínsecos da Submatriz SW calculados peloMP

Depa E Depe Dept D.Dna D.Dnu E.Fn E.Mi E.Ln E.Ad Depe.De P.Pn

employees 0 89 0 0 0 0 0 0 0 0 0 0department 100 0 67 0 0 0 0 0 0 0 66 0

research 0 0 0 0 0 0 0 0 0 0 0 0

Tabela 6.20: Pesos intrínsecos da Submatriz SW calculados pelaKeymantic


employees 0 94 0 0 0 0 0 0 0 0 0 0department 100 0 81 67 70 0 0 0 0 0 77 70

research 0 0 0 0 0 0 0 0 0 0 0 0

Como se pode notar, os pesos de ambas tabelas não são iguais. Isso se deve àmodificação realizada na etapa de Cálculo dos pesos intrínsecos para termos de esquema.No MP, os pesos são calculados com base na média dos valores retornados pelas métricasde similaridade, enquanto que na Keymantic os pesos são definidos como o maior valorretornado por essas métricas.

No cálculo realizado pelo MP, foi encontrada uma alta similaridade entre apalavra-chave department e os termos Department, Dependent e Dependent_name. Aexpressão alta similaridade é usada com o intuito de expressar o fato da similaridadeentre a palavra-chave e o termo ser acima do limiar. De fato, se considerado apenas oconjunto de caracteres de cada palavra, tais termos são similares à palavra-chave. Porém,com relação à semântica da consulta, apenas o termo Department é similar à palavra-chave em questão.

No cálculo realizado pela Keymantic, constatou-se uma alta similaridade entre apalavra-chave department e os termos Department, Dependent, Dept_locations, Dname,

Dependent_Name e Pname. Novamente, apenas o termo Department é similar à semân-tica pretendida pela palavra-chave department. Repare que se considerarmos o contextoda consulta, o termo Dname poderia ser considerado como similiar à semântica preten-dida pela consulta. Porém, durante a etapa de cálculo dos pesos intrínsecos é considerado


apenas a semântica da palavra-chave de forma isolada. O contexto da consulta é consi-derado durante a etapa de seleção dos melhores mapeamentos, em que são empregadasas regras de contextualização que levam em consideração a interdependência entre aspalavras-chave da consulta. Comparando os conjuntos de termos não similares à semân-tica pretendida pela palavra-chave em ambos os sistema, é possível dizer que o MP “erra”menos que a Keymantic quanto à decisão de saber quais termos do banco de dados sãomais similares à palavra-chave.

Os pesos calculados para termos de valor por ambos os sistemas são apresentadosnas tabelas 6.21 e 6.22.

Tabela 6.21: Pesos intrínsecos da Submatriz VW calculados peloMP

Depa.Dna Depa.Dnu Depa.Mgr_ssE.Fn E.Mi E.Ln E.Ssn E.Bd E.Ad E.Sex E.Su Depe.Es Depe.De Depe.Se Depe.Re

employees 65 0 65 65 65 65 65 0 65 65 65 65 65 65 65department 65 0 65 65 65 65 65 0 65 65 65 65 65 65 65

research 65 0 65 65 65 65 65 0 65 65 65 65 65 65 65

Tabela 6.22: Pesos intrínsecos da Submatriz VW calculados pelaKeymantic



research 1 0 1 1 1 1 1 0 1 1 1 1 1 1 1

Quanto aos pesos intrínsecos dos termos de valor calculados pelo MP e pelaKeymantic também é possível notar uma diferença entre as tabelas. Tal diferença é causadapela modificação referente à normalização dos pesos dos termos de valor, realizada peloMP na etapa de Cálculo dos pesos intrínsecos para os termos de valor. No caso destaconsulta, não fica evidente a razão desta modificação. Como exemplificado no capítuloanterior, na Seção 5, o motivo da modificação é equiparar o valor dos pesos dos termosde esquema e dos termos de valor, de maneira que ambos influenciem igualmente apontuação final da configuração.

Seleção dos Melhores Mapeamentos para os termos de esquema (Passo 2)

Ao fim do Passo 1, as submatrizes SW e VW estão preenchidas com os pesosintrínsecos calculados. Em posse da Submatriz SW , o Passo 2 realiza a seleção dosmelhores mapeamentos para os termos de esquema. As tabelas 6.23 e 6.24 apresentamo primeiro mapeamento para termos de esquema gerado por ambos os sistemas.

Tabela 6.23: Mapeamento gerado pelo MPDepa E Depe Dept D.Dna D.Dnu E.Fn E.Mi E.Ln E.Ad Depe.De P.Pn


research 0 0 0 0 0 0 0 0 0 0 0 0


Tabela 6.24: Mapeamento gerado pela KeymanticDepa E Depe Dept D.Dna D.Dnu E.Fn E.Mi E.Ln E.Ad Depe.De P.Pn


research 0 0 0 0 0 0 0 0 0 0 0 0

Em ambos sistemas, a palavra-chave employees foi mapeada para a relaçãoEmployee e a palavra-chave department para a relação Department. A palavra-chaveresearch não foi mapeada para nenhum termo de esquema e, consequentemente, serámapeada para um termo de valor durante o Passo 3. Ainda durante o Passo 2, a partir domapeamento gerado em cada sistema, são gerados novos mapeamentos pelo algoritmo deseleção dos melhores mapeamentos até que nenhum mapeamento novo possua pontuaçãomaior que o limiar.

Considere o mapeamento do MP (Tabela 6.23). A partir dele é possível gerardois novos mapeamentos. O primeiro é gerado negativando o valor 89 da primeira linha,e selecionando o valor 100 da segunda linha como peso máximo. Contudo, a pontuaçãodeste novo mapeamento é 100, estando abaixo do limiar (189∗0.9 = 170). Sendo assim,este mapeamento é desconsiderado. O segundo mapeamento é gerado negativando o valor100 da segunda linha, e selecionando o valor 89 da primeira linha e o valor 67 da segundalinha. Da mesma forma, esse novo mapeamento possui pontuação abaixo do limiar e étambém desconsiderado.

De forma semelhante, para o mapeamento da Keymantic (Tabela 6.24), são gera-dos dois novos mapeamentos. O mapeamento gerado por negativar o valor 94 da primeiralinha, por sua vez, também possui pontuação abaixo do limiar e é desconsiderado. O ma-peamento gerado negativando o valor 100 da segunda linha e selecionando como pesosmáximos os valores 94 e 81 das primeira linha e segunda linhas, respectivamente, gera umnovo mapeamento com pontuação 175 que está acima do limiar (194 ∗ 0.9 = 174). Estemapeamento é apresentado na Tabela 6.25. A partir deste mapeamento é possível gerardois novos mapeamentos. Porém estes dois mapeamentos possuem pontuação abaixo dolimiar e são desconsiderados.

Tabela 6.25: Mapeamento gerado a partir do mapeamento da Ta-bela 6.24 (Keymantic)


employees 0 94* 0 0 0 0 0 0 0 0 0 0department -100 0 81* 67 70 0 0 0 0 0 77 70

research 0 0 0 0 0 0 0 0 0 0 0 0

Assim, ao final do Passo 2, o MP retorna um único mapeamento para termo deesquema (Tabela 6.23), enquanto que a Keymantic retorna dois mapeamentos (Tabela 6.24e Tabela 6.25).

Como se pode observar, a modificação referente à etapa de Cálculo dos pesos

intrínsecos para termos de esquema influenciou no resultado gerado pelo Passo 2, uma


vez que a Keymantic gerou um mapeamento a mais para termos de esquema. O primeiromapeamento gerado pela Keymantic é equivalente ao único mapeamento gerado peloMP, onde a palavra-chave employees é mapeada para a relação Employee e a palavradepartment para a relação Deparment. O segundo mapeamento representa o mapeamentoda palavra-chave department para a relação Dependent. Claramente, apenas o primeiromapeamento da Keymantic, assim como o mapeamento do MP, são condizentes coma semântica pretendida pela consulta. Dessa forma, novamente o MP se mostrou maiseficiente que a Keymantic.


Terminado o Psasso 2, cada mapeamento para termos de esquema gerado nestepasso é então utilizado no Passo 3 para contextualizar a Submatriz VW . As tabelas 6.26,6.27 e 6.28 apresentam as submatrizes VW contextualizadas, correspondentes a cada umdos mapeamentos gerados pelos dois sistemas.

Tabela 6.26: Submatriz VW contextualizada com base no mapea-mento da Tabela 6.23 (MP)



research 75 0 75 70 70 70 70 0 70 70 70 65 65 65 65

Tabela 6.27: Submatriz VW contextualizada com base no mapea-mento da Tabela 6.24 (Keymantic)



research 11 0 11 11 11 11 11 0 11 11 11 1 1 1 1

Tabela 6.28: Submatriz VW contextualizada com base no mapea-mento da Tabela 6.25 (Keymantic)



research 1 0 1 11 11 11 11 0 11 11 11 11 11 11 11

Considere as tabelas 6.26 e 6.27. Em ambas, os pesos das linhas 1 e 2 foram ze-rados pelo fato das palavras-chave correspondentes já terem sido mapeadas. Além disso, ovalor dos pesos referentes aos domínios de atributos das relações Deparment e Employee

aumentou. Isso ocorre pelo fato das palavras-chave employees e department terem sidomapeadas para tais relações, aumentando assim a probabilidade do valor research ser umdomínio de atributo de umas destas duas relações. Porém, na Submatriz VW referenteao MP, os valores referentes aos domínios de atributos da relação Deparment sofreram


um maior acréscimo em relação aos da relação Employee. Isso se deve à modificaçãono processo de contextualização referente à proximidade das palavras-chave. O fato dapalavra-chave research estar mais próxima da palavra-chave deparment, a qual foi mape-ada para a relação Deparment, torna mais provável que esta palavra-chave seja mapeadapara termos relacionados à relação Deparment. A Tabela 6.28 segue o mesmo raciocínioda Tabela 6.27, porém uma vez que a palavra-chave deparment foi mapeada para a rela-ção Dependent no mapeamento da Tabela 6.25, então os pesos que sofrem acréscimo sãoaqueles referentes aos domínios de atributo desta relação.

Realizado o processo de contextualização, inicia-se a seleção dos melhoresmapeamentos para termos de valor baseado nas submatrizes VW atualizadas. A partirda Tabela 6.26 referente ao sistema MP, é possível gerar 9 mapeamentos para termos devalor com pontuações acima do limiar (75∗0.9 = 67). Esses mapeamentos representam omapeamento da palavra-chave research para os domínios dos atributos Dname, Mgr_ssn,

Fname, Minit, Lname, Ssn, Address, Sex e Super_ssn. Estes mesmos mapeamentossão gerados pela Keymantic a partir da Submatriz VW contextualizada referente aoprimeiro mapeamento de esquema (Tabela 6.27). Já para a Submatriz VW referente aosegundo mapeamento da Keymantic são gerados 11 mapeamentos de termos de valor compontuação acima do limiar, representados pelo mapeamento da palavra-chave research

para os domínios de atributo Fname, Minit, Lname, Ssn, Address, Sex, Super_ssn, Essn,Dependent_name, Sex e Relationship.

Assim, ao final do Passo 3 para o MP temos 1 mapeamento para termos deesquema e 9 mapeamentos correspondentes para termos de valor; para a Keymantic temos2 mapeamentos para termos de esquema e 9 mapeamentos para termos de valor para oprimeiro e 11 para o segundo.


Durante o Passo 4 a execução do MP resulta em 9 configurações, enquantoque a execução da Keymantic resulta em 20 configurações. Das configurações do MP, 2configurações possuem pontuação igual a 89+100+75= 264, referentes ao mapeamentoda palavra-chave research para os domínios dos atributos da relação Department; e 7configurações possuem pontuação igual a 89+100+70= 259, referentes ao mapeamentoda palavra-chave para os domínios dos atributos da relação Employee. Em relação aKeymantic tem-se 9 configurações com pontuação igual a 94+100+11 = 205, referentesao mapeamento da palavra-chave department para a relação Department e da palavra-chave research para os domínios de atributos das relações Employee e Department, e 11configurações com pontuação igual a 94+ 81+ 11 = 186, referentes ao mapeamento dapalavra-chave department para a relação Dependent e da palavra-chave research para osdomínios de atributos das relações Employee e Dependent.


As 9 configurações geradas pelo MP são equivalentes às 9 configurações compontuação igual à 205 geradas pela Keymantic. Porém, repare que na execução do MP

é feita uma distinção quanto à pontuação entre estas 9 configurações, em que as confi-gurações referentes ao mapeamento da palavra-chave para os domínios de atributos darelação Department possuem uma maior pontuação, enquanto que na execução da Key-

mantic todas as 9 possuem a mesma pontuação. De acordo com a semântica pretendidapela consulta, os mapeamentos referentes aos domínios de atributos da relação Depart-

ment são mais relevantes para a consulta do que os mapeamentos referentes aos domíníosde atributos da relação Employee. Além disso, nenhuma das 11 outras configurações ge-radas pela Keymantic estão de acordo com o resultado esperado pela consulta, uma vezque a palavra-chave department é mapeada para a relação Dependent. Desta forma, o MP

gera e avalia as configurações de forma mais condizente com a consulta em comparaçãoà Keymantic.


Considerando estas configurações, as interpretações são geradas no Passo 5. Apartir das 9 configurações do MP são geradas 9 ∗ 3 = 27 interpretações, enquanto quepara as 20 configurações da Keymantic são geradas 9∗3+11∗1 = 38 interpretações. Emambos os casos, apenas as interpretações referentes à configuração que mapeia as palavra-chave da consulta para os termos Employee, Department e Dname retornam resultadosválidos. Esta configuração gera 3 interpretações.

Percebe-se que as modificações internas que foram realizadas nos três primeirospassos do processo de Mapeamento da Keymantic, causaram impacto não somente nasaída retornada por cada um dos passos, mas influenciaram também todo o processo,inclusive os dois últimos passos, resultando em um menor número de configurações einterpretações, bem como na qualidade dos resultados gerados.

Impacto das Modificações Internas à Keymantic

Considere o conjunto de consultas com palavras-chave juntamente com a semân-tica pretendida pelo usuário, apresentados na Tabela 6.29.

A Figura 6.1 compara o numero de configurações e interpretações (consultasSQL) geradas por ambos os sistemas. Os valores são apresentados para cada uma dasconsultas, cuja identificação é a mesma usada na Tabela 6.29. As modificações internas,as quais foram realizadas nos três primeiros passos do processo de Mapeamento da Key-

mantic, influenciaram os resultados obtidos pelo método proposto, resultando em valoresinferiores em relação à Keymantic para o numero de configurações e interpretações. Tal


Tabela 6.29: Conjunto de consultas com palavras-chave

Consulta com palavras-chave Semântica pretendida1 department lista de informações sobre os departamentos da empresa2 department employee lista de empregados de cada departamento3 department project lista de projetos de cada departamento4 department project newbenefits informações do departamento responsável pelo projeto

Newbenefits5 location project productx localização do projeto cujo nome é ProductX6 employee dependent daughter informações dos empregados que tem filha como depen-

dente7 project name employee John nome do projeto no qual o empregado John trabalha8 employee address project 1 endereço do empregado que trabalha no projeto 19 hours employee works project productz quantidade de horas trabalhadas por cada empregado

do projeto ProductZ10 project location employee salary 30000 localização do projeto no qual trabalha o empregado

cujo o salário é 30000

redução possui impacto importante no custo do processo, e possibilita ao usuário lidarcom um número menor de resultados para a sua consulta.

(a) Número de configurações geradas por ambos ossistemas

(b) Número interpretações geradas por ambos os siste-mas

Figura 6.1: Número de configurações e interpretações geradas porambos os sitemas

Os gráficos da Figura 6.2 exploram as consultas com três ou mais palavras-chave,


e apresentam a precisão relativa a cada sistema. Essa métrica denota a fração relevante dasinterpretações obtidas, sendo um indicador de qualidade difundido na literatura. Como sepode observar na Subfigura 6.2(a) o método proposto foi superior em todas as consultas. ASubfigura 6.2(b) exibe valores de precisão em relação ao tamanho da consulta, ou seja, onúmero de palavras-chave que a compõe. A precisão decresce em ambos os sistemas como aumento do número de palavras-chave na consulta. Contudo, observam-se novamentemelhores valores de precisão quando comparados ao método original.

(a)

(b)

Figura 6.2: Métrica de precisão para ambos os sistemas

Ranking dos resultados

Quanto à etapa externa de Ranking dos resultados, sabe-se que a Keymantic exibeos resultados de acordo com a ordem em que eles são gerados. À medida que os mape-amentos são gerados, suas pontuações vão decrescendo até chegar o limiar estabelecido.Destes mapeamentos, são então geradas as configurações e interpretações corresponden-tes que são executadas de acordo com a ordem da geração dos mapeamentos. Desta forma,cria-se uma ilusão que os resultados estão ordenados por ordem de pontuação dos mape-amentos. Contudo, apesar das pontuações dos mapeamentos decrescerem à medida que


eles são gerados, pode acontecer de um mapeamento com menor pontuação ser geradoantes de um mapeamento com maior pontuação, desde que estes dois mapeamentos es-tejam sendo gerados a partir de um mesmo mapeamento. Considere o mapeamento daTabela 6.30 para a consulta “department number location”.

Tabela 6.30: Mapeamento a partir do qual são gerados mapea-mentos que não estão de acordo com a ordem decres-cente de pontuação

Depa Depe Dept Depa.Dnu Dept.Dnu Dept.Dlo

department 100* 81 67 0 0 0number 0 0 0 85* 85 0location 66 0 76 0 0 88*

A partir deste mapeamento podem ser gerados 3 mapeamentos. O primeiromapeamento é gerado negativando o valor 100 da primeira linha e escolhendo o valor 81desta mesma linha como máximo, resultando numa pontuação igual a 81+85+88= 254.O segundo mapeamento é gerado negativando o primeiro valor 85 da segunda linha eescolhendo o próximo valor 85 desta linha, resultando na pontuação 100+85+88 = 273.E o terceiro e último mapeamento é gerado negativando o valor 88 da terceira linha eescolhendo o valor 76, resultando na pontuação 100 + 85 + 76 = 261. Como se podeobservar, a ordem dos mapeamentos gerados não corresponde à ordem decrescente depontuação. Assim, uma vez que a ferramenta apresenta os resultados pela ordem emque são gerados, nem sempre os resultados serão apresentados com uma ordenaçãodecrescente das pontuações.

Para a avaliação da etapa de Ranking dos resultados foi utilizada a métrica Mean

Reciprocal Rank (MRR). Tal métrica é calculada com base no quão próximo do topo oprimeiro resultado relevante aparece no conjunto de resultados. A Figura 6.3 apresenta oMRR para ambos os sistemas, com base no comprimento da consulta, ou seja, o númerode palavras-chave que a compõe, considerando as consultas da Tabela 6.29

Figura 6.3: Gráfico MRR-Tamanho da consulta (inspirado em[10])


Conforme mencionado anteriormente, nem todos os resultados das interpreta-ções geradas são apresentados ao usuário. Resultados repetidos e a falta deles, são des-considerados. Uma vez que o Reciprocal Rank representa o inverso da posição na qualo primeiro resultado relevante apareceu, no caso do cálculo do MRR, todos os resultadosforam considerados, de modo a verificar em que posição o primeiro resultado relevanteapareceu.

Como se pode observar na Figura 6.3, o MP supera a ferramenta Keymantic combase na métrica MRR. Na Keymantic, quanto maior a consulta, mais longe do topo doranking aparece o primeiro resultado relevante. No MP, ocorre o mesmo, porém de formamais suave, ou seja, apesar do primeiro resultado se distanciar do topo à medida que aconsulta aumenta, este resultado ainda permanece como um dos primeiros resultados doranking.


Uma vez identificadas algumas limitações na ferramenta Keymantic, foram suge-ridas modificações e melhorias que formaram por fim o método proposto neste trabalho.Com base no comparativo estabelecido entre o método proposto e a ferramenta Keymantic

foi possível constatar que as modificações internas proporcionaram um conjunto de resul-tados menor e mais significativo para a consulta com palavras-chave submetida, enquantoque as modificações externas à ferramenta tornaram possível o tratamento de consultasaté então não realizadas pela Keymantic, como consultas com o uso de funções agrega-das, ordenação e valores compostos por mais de uma palavra-chave.

CAPÍTULO 7Conclusão

Este trabalho propôs um método para consultar bancos de dados relacionais como uso de palavras-chave de modo a simplificar o acesso a estes dados, uma vez que taisconsultas fazem uso de palavras que se aproximam à língua usual.

O método proposto identifica os bancos de dados disponíveis e relevantes parauma consulta e converte a consulta em expressões SQL correspondentes, as quais sãosubmetidas aos bancos de dados identificados como relevantes. O método retorna osresultados obtidos pela execução das consultas SQL aos bancos de dados.

A análise semântica da consulta com palavras-chave foi baseada na abordagempertinente à ferramenta Keymantic. O método proposto incorporou melhorias à referidaabordagem, proporcionando resultados mais eficazes em relação às intenções do usuárioconcernente às suas consultas com palavras-chave.

As próximas seções apresentam uma síntese das principais contribuições destetrabalho, a descrição dos possíveis trabalhos futuros, e por fim a menção do trabalhorelacionado produzido durante o desenvolvimento desta dissertação.

7.1 Contribuições

As contribuições deste trabalho se referem aos módulos externos agregados àferramenta Keymantic, bem como às modificações internas realizadas no processo demapeamento da ferramenta. A seguir são apresentadas tais contribuições:

• Permite o uso de consulta com palavras-chave em banco de dados relacionais:

a contribuição primária deste trabalho refere-se à facilidade de recuperação dosdados de bases relacionais. Consultar bancos de dados é uma tarefa complexa, umavez que é necessário o conhecimento da estrutura do banco, bem como de umalinguagem estruturada. Prover o uso de palavras-chave como um método alternativode consulta possibilita que quaisquer usuários possam acessar estes dados.• Propõe melhorias à ferramenta Keymantic: identificadas algumas limitações na

ferramenta, o método proposto agregou novas funcionalidades ao sistema e realizou

7.1 Contribuições 95

algumas modificações internas que permitiram obter um conjunto de resultadosmenor e mais significativo.• Identifica os bancos de dados relevantes para a consulta: os dados da Web estão

espalhados em inúmeros meios de armazenamento, incluindo bancos de dados.Realizar o mapeamento de uma consulta com palavras-chave para uma consultaSQL para cada um destes bancos representa um alto custo computacional, tornando-se assim uma solução ineficiente. Identificar quais bancos de dados são relevantes,elimina a necessidade de mapeamento para todos eles, reduzindo consequentementea complexidade do problema.• Pesquisa múltiplos bancos de dados a partir de uma única consulta: os bancos

de dados, além de possuírem conjuntos de dados diferentes, possuem esquemasdistintos para armazenar estes dados. Neste sentido, o método proposto é capaz deconverter uma única consulta com palavras-chave em várias consultas SQL, cadauma correspondente a um banco de dados, independente da hetereogenidade deesquemas.• Permite consultas com funções agregadas e de ordenação: o fato da ferramenta

Keymantic considerar cada palavra-chave como um termo a ser representado nobanco de dados, se apresenta como uma limitação ao processamento de consultascom palavras-chave que sugerem o uso de funções. O método proposto superoutal limitação, pois incorpora uma etapa de verificação de palavras-chave, as quaispossam corresponder ao uso de funções agregadas e de ordenação.• Permite consultas com valores compostos por mais de uma palavra-chave: na

Keymantic, duas palavras-chave não podem representar um mesmo termo no bancode dados, impedindo que se mapeie corretamente valores que são compostos pormais de uma palavra-chave. O método proposto apresentou uma solução para talproblema, em que se usa aspas simples para identificar tais valores.• Mapeia a consulta com palavra-chave considerando a semântica pretendida pelo

usuário: fatores como a interdependência entre as palavras-chave, bem como aproximidade entre elas, são considerados com o intuito de prever o contexto daspalavras-chave na consulta e permitir um mapeamento mais próximo do significadoesperado por cada uma delas.• Apresenta os resultados ordenados por ordem de relevância: o usuário espera que

os resultados mais relevantes para a consulta sejam apresentados primeiro. Coma ordenação dos resultados sugerida neste trabalho, a implementação do métodoproposto se mostrou mais efetiva que a implementação da ferramenta Keymantic,uma vez que os resultados mais relevantes aparecem no topo do ranking.

7.2 Trabalhos Futuros 96

7.2 Trabalhos Futuros

No desenvolvimento da pesquisa, foram identificados alguns aspectos que pode-riam ser complementados, visando a estender os estudos realizados. Dentre eles estão:

• Melhorar o desempenho em termos de espaço e tempo: o processo de mapeamentoda Keymantic empregado no método proposto, ao gerar os melhores mapeamentosfaz uso de uma grande quantidade de espaço, uma vez que é necessário a cria-ção de uma matriz de peso para cada mapeamento correspondente. Além disso, aKeymantic gera várias interpretações que são executadas no banco de dados corres-pondente. A execução de tais interpretações pode ter um alto custo computacionaldependendo do número de consultas SQL geradas.• Validar o método proposto em um cenário com múltiplos bancos de dados relaci-

onais: no presente trabalho, o método proposto foi analisado considerando apenasum único banco de dados. Como o método pode ser aplicado a um conjunto debanco de dados, seria necessário verificar a eficiência e a eficácia do sistema nestecenário.• Validar o método proposto utilizando um benchmark: um benchmark é uma prova

padrão em que produtos e processos são submetidos para fins de avaliação ecomparação entre si. Sua aplicação permitiria definir e analisar as ameaças àvalidade do método proposto e identificar quaisquer melhorias.• Melhor segmentação da consulta: o método proposto permite valores compostos

por várias palavras-chave, pelo uso de aspas simples para permitir a identificação detais valores. Contudo, para esta solução faz-se necessário um conhecimento préviopor parte do usuário para construir a consulta de maneira adequada. Visando aeliminar esta necessidade, poderia ser utilizada a ideia do sistema FRISK ([28]).O sistema faz uso de um algoritmo de programação dinâmica para computaras melhores segmentações da consulta. Tais segmentações são apresentadas aousuário, que por sua vez escolhe a que mais se aproxima de sua intenção.• Contextualização a cada mapeamento individual: durante a etapa de seleção dos

melhores mapeamentos da ferramenta Keymantic, as regras de contextualização sãoutilizadas somente quando ocorre o mapeamento de duas palavras-chave para ummesmo termo. Então, alguns pesos são descaracterizados como máximo, restandoapenas o maior. Os pesos das linhas correspondentes aos pesos descaracterizadossão então atualizados com as regras de contextualização. Caso não ocorra algumadescaracterização, o processo de contextualização não é realizado durante a sele-ção dos melhores mapeamentos. Considere a consulta “department name employee

John” e que nenhuma palavra-chave foi mapeada para um mesmo termo do bancode dados. Desta forma, a interdependência dos mapeamentos da palavra-chave não

7.3 Produção Bibliográfica 97

será considerada, pois as regras de contextualização não serão aplicadas. Como tra-balho futuro, a medida que cada palavra-chave fosse mapeada, as regras de contex-tualização seriam aplicadas. Assim, uma vez que a palavra-chave department fossemapeada para a relação Department, aumentaria a probabilidade da palavra-chavename ser mapeada para o atributo Dname, e assim sucessivamente. Caso esta solu-ção fosse aplicada, seria necessário que ao ocorrer o processo de descaracterizaçãodos pesos, as regras de contextualização já aplicadas fossem revertidas.• Uso de ontologias: durante o processo de expansão da consulta e cálculo dos pesos

intrínsecos dos termos de esquema, são utilizados apenas os sinônimos obtidos pelodicionário WordNet. Uma maneira de acrescentar maior semântica a estas etapas,seria o uso de ontologias.• Expandir o estudo para consulta em banco de dados por meio do uso de linguagem

natural: uma consulta em linguagem natural pode ser vista como uma consultacom palavras-chave mais abrangente. Tal consulta inclui palavras-chave que nãorepresentam um real significado para a consulta, como por exemplo, as palavrasde, um, os, conhecidas como stopwords. A consulta em linguagem natural podeser mapeada em consulta com palavras-chave, pela retirada das stopwords e outrastransformações, visando a “limpar” a consulta.• Construir uma versão Web: a construção de uma versão Web eliminaria a neces-

sidade de instalação do software e seus complementos, sendo necessário apenas ouso de um browser para acessar o sistema.• Suporte a novos SGBD´s: o sistema foi desenvolvido considerando inicialmente

apenas o MySQL, porém seria interessante agregar o suporte a novos SGBD´s, comoo PostgreSQL e Oracle, por exemplo.

7.3 Produção Bibliográfica

Durante o desenvolvimento deste trabalho foi produzida uma revisão sistemáticacom o intuito de identificar as principais técnicas e ferramentas existentes no contextode consultas com palavras-chave em bancos de dados relacionais, bem como identificaros principais focos de pesquisa nesta área e os desafios ainda não solucionados, determi-nando assim o estado da arte deste assunto. O título da revisão é “Consulta com palavras-chave em Banco de Dados Relacionais: uma revisão sistemática” e foi apresentada noCongresso de Pesquisa, Ensino e Extensão de 2012 (CONPEEX 2012) da UniversidadeFederal de Goiás.

Referências Bibliográficas

[1] ADITYA, B.; BHALOTIA, G.; CHAKRABARTI, S.; HULGERI, A.; NAKHE, C.; PARAG.;

SUDARSHANXE, S. Banks: Browsing and keyword searching in relational data-

bases. In: Bernstein, P. A.; Ioannidis, Y. E.; Ramakrishnan, R.; Papadias, D., editors,

VLDB ’02: Proceedings of the 28th International Conference on Very Large Databa-

ses, p. 1083 – 1086. Morgan Kaufmann, San Francisco, 2002.

[2] AGRAWAL, S.; CHAUDHURI, S.; DAS, G. Dbxplorer: a system for keyword-based

search over relational databases. In: Data Engineering, 2002. Proceedings. 18th

International Conference on, p. 5 –16, 2002.

[3] BERGAMASCHI, S.; DOMNORI, E.; GUERRA, F.; ORSINI, M.; LADO, R. T.; VELE-

GRAKIS, Y. Keymantic: semantic keyword-based searching in data integration

systems. Proc. VLDB Endow., 3:1637–1640, September 2010.

[4] BERGAMASCHI, S.; DOMNORI, E.; GUERRA, F.; TRILLO LADO, R.; VELEGRAKIS, Y.

Keyword search over relational databases: a metadata approach. In: Procee-

dings of the 2011 ACM SIGMOD International Conference on Management of data,

SIGMOD ’11, p. 565–576, New York, NY, USA, 2011. ACM.

[5] BERGMAN, M. K. The deep web: Surfacing hidden value, 2000.

[6] COFFMAN, J.; WEAVER, A. An empirical performance evaluation of relational

keyword search techniques. Knowledge and Data Engineering, IEEE Transactions

on, PP(99):1, 2012.

[7] COFFMAN, J.; WEAVER, A. C. A framework for evaluating database keyword

search strategies. In: Proceedings of the 19th ACM international conference on

Information and knowledge management, CIKM ’10, p. 729–738, New York, NY, USA,

2010. ACM.

[8] ELMASRI, R.; NAVATHE, S. B. Fundamentals of Database Systems (6th Edition).

Addison-Wesley, 2011.


[9] FAKHRAEE, S.; FOTOUHI, F. Effective keyword search over relational databases

considering keywords proximity and keywords n-grams. In: Database and Expert

Systems Applications (DEXA), 2011 22nd International Workshop on, p. 190 –194,

29 2011-sept. 2 2011.

[10] FAKHRAEE, S.; FOTOUHI, F. Dbsemsxplorer: semantic-based keyword search

system over relational databases for knowledge discovery. In: Proceedings of

the Third International Workshop on Keyword Search on Structured Data, KEYS ’12,

p. 54–62, New York, NY, USA, 2012. ACM.

[11] FOUNDATION, A. W. M. Dublin core metadata initiative. Disponível em: http:

//dublincore.org/. Acesso em: 21 fev. 2013.

[12] FOUNDATION, A. W. M. Open archives initiative. Disponível em: http://www.

openarchives.org/. Acesso em: 21 fev. 2013.

[13] GANTI, V.; HE, Y.; XIN, D. Keyword++: a framework to improve keyword search

over entity databases. Proc. VLDB Endow., 3:711–722, September 2010.

[14] GU, J.; KITAGAWA, H. Extending keyword search to metadata on relational

databases. In: Information-Explosion and Next Generation Search, 2008. INGS ’08.

International Workshop on, p. 97 –103, april 2008.

[15] HASSAN, M.; ALHAJJ, R.; RIDLEY, M. J.; BARKER, K. Simplified access to

structured databases by adapting keyword search and database selection. In:

Proceedings of the 2004 ACM symposium on Applied computing, SAC ’04, p. 674–

678, New York, NY, USA, 2004. ACM.

[16] HRISTIDIS, V.; GRAVANO, L.; PAPAKONSTANTINOU, Y. Efficient ir-style keyword se-

arch over relational databases. In: Proceedings of the 29th international conference

on Very large data bases - Volume 29, VLDB ’2003, p. 850–861. VLDB Endowment,

2003.

[17] HRISTIDIS, V.; PAPAKONSTANTINOU, Y. Discover: Keyword search in relational

databases. In: Bernstein, P. A.; Ioannidis, Y. E.; Ramakrishnan, R.; Papadias, D.,

editors, VLDB ’02: Proceedings of the 28th International Conference on Very Large

Databases, p. 670 – 681. Morgan Kaufmann, San Francisco, 2002.

[18] KONG, Z.; ZHANG, K. Summarizing keyword search in relational database. In:

Intelligent Human-Machine Systems and Cybernetics (IHMSC), 2011 International

Conference on, volume 2, p. 152 –155, aug. 2011.

http://dublincore.org/

http://dublincore.org/

http://www.openarchives.org/

http://www.openarchives.org/


[19] KOUTRIKA, G.; ZADEH, Z. M.; GARCIA-MOLINA, H. Data clouds: summarizing

keyword search results over structured data. In: Proceedings of the 12th Interna-

tional Conference on Extending Database Technology: Advances in Database Tech-

nology, EDBT ’09, p. 391–402, New York, NY, USA, 2009. ACM.

[20] KOWATA, E. T. Metadados de bancos de dados relacionais: Extração e exposi-

ção com o protrocolo OAI-PMH. Dissertação de mestrado, Instituto de Informática,

UFG, Goiânia, 2011.

[21] LI, F.-Z.; LUO, D.; XIE, D. Fuzzy search on non-numeric attributes of keyword

query over relational databases. In: Computer Science Education, 2009. ICCSE

’09. 4th International Conference on, p. 811 –814, july 2009.

[22] LI, G.; FENG, J.; ZHOU, X.; WANG, J. Providing built-in keyword search capabi-

lities in rdbms. The VLDB Journal, 20:1–19, 2011.

[23] LI, G.; JI, S.; LI, C.; FENG, J. Efficient type-ahead search on relational data:

a tastier approach. In: Proceedings of the 2009 ACM SIGMOD International

Conference on Management of data, SIGMOD ’09, p. 695–706, New York, NY, USA,

2009. ACM.

[24] LIU, F.; YU, C.; MENG, W.; CHOWDHURY, A. Effective keyword search in relational

databases. In: Proceedings of the 2006 ACM SIGMOD international conference on

Management of data, SIGMOD ’06, p. 563–574, New York, NY, USA, 2006. ACM.

[25] LUO, Y.; WANG, W.; LIN, X. Spark: A keyword search engine on relational data-

bases. In: Data Engineering, 2008. ICDE 2008. IEEE 24th International Conference

on, p. 1552 –1555, april 2008.

[26] MORO, M. M. Entrevista com John E. Hopcroft. SBC Horizontes, 4(1):24–27, Apr.

2011.

[27] PENG, Z.; ZHANG, J.; WANG, S.; WANG, C. Bring user feedback into keyword

search over databases. In: Web Information Systems and Applications Conference,

2009. WISA 2009. Sixth, p. 210 –214, sept. 2009.

[28] PU, K.; YU, X. Frisk: Keyword query cleaning and processing in action. In: Data

Engineering, 2009. ICDE ’09. IEEE 25th International Conference on, p. 1531 –1534,

29 2009-april 2 2009.

[29] RAMADA, M. S.; FILGUEIRAS, A. C.; SILVA, J. C. Consulta com palavras-chave em

banco de dados relacionais: uma revisão sistemática. Relatório técnico, Instituto

de Informática, UFG, Goiânia, 2012.


[30] SAYYADIAN, M.; LEKHAC, H.; DOAN, A.; GRAVANO, L. Efficient keyword search

across heterogeneous relational databases. In: Data Engineering, 2007. ICDE

2007. IEEE 23rd International Conference on, p. 346 –355, april 2007.

[31] WANG, S.; ZHANG, K.-L. Searching databases with keywords. Journal of

Computer Science and Technology, 20:55–62, 2005.

[32] WANG, W.; LIN, X.; LUO, Y. Keyword search on relational databases. In: Network

and Parallel Computing Workshops, 2007. NPC Workshops. IFIP International Con-

ference on, p. 7 –10, sept. 2007.

[33] WIKIPÉDIA, A. E. L. Deep web, 2013. Disponível em: http://pt.wikipedia.org/

w/index.php?title=Deep_web&oldid=35666350. Acesso em: 7 maio 2013.

[34] YU, B.; LI, G.; SOLLINS, K.; TUNG, A. K. H. Effective keyword-based selection

of relational databases. In: Proceedings of the 2007 ACM SIGMOD international

conference on Management of data, SIGMOD ’07, p. 139–150, New York, NY, USA,

2007. ACM.

http://pt.wikipedia.org/w/index.php?title=Deep_web&oldid=35666350

http://pt.wikipedia.org/w/index.php?title=Deep_web&oldid=35666350

APÊNDICE AEstrutura da Tabela de Metadados paraExposição (TME)

O Código A.1 apresenta a estrutura da tabela TME.

Código A.1 Código SQL para a criação da Tabela de Metada-dos para Exposição (TME) [20]

1 --

2 -- Estrutura da Tabela de Metadados para Exposição

3 --

4

5 CREATE TABLE IF NOT EXISTS TME (

6 serial int(11) NOT NULL AUTO_INCREMENT,

7 provider varchar(255) DEFAULT NULL,

8 url varchar(255) DEFAULT NULL,

9 email varchar(255) DEFAULT NULL,

10 oai_set varchar(255) DEFAULT NULL,

11 dispquery enum(’false’,’true’) NOT NULL

12 COMMENT ’Disponível para consulta externa’,

13 dc_title varchar(255) DEFAULT NULL,

14 dc_creator text,

15 dc_subject varchar(255) DEFAULT NULL,

16 dc_description text,

17 dc_contributor varchar(255) DEFAULT NULL,

18 dc_publisher varchar(255) DEFAULT NULL,

19 dc_date date DEFAULT NULL,

20 dc_type varchar(255) DEFAULT NULL,

21 dc_format varchar(255) DEFAULT NULL,

22 dc_identifier varchar(255) DEFAULT NULL,

23 dc_source varchar(255) DEFAULT NULL,

24 dc_language varchar(255) DEFAULT NULL,

25 dc_relation varchar(255) DEFAULT NULL,

26 dc_coverage varchar(255) DEFAULT NULL,

27 dc_rights varchar(255) DEFAULT NULL,

28 loginbd varchar(15) NOT NULL

29 COMMENT ’Login do banco de dados’,

30 passwordbd varchar(15) NOT NULL

31 COMMENT ’Senha de acesso ao banco de dados’,

32 PRIMARY KEY (serial)

33 ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1;

APÊNDICE BBanco de dados COMPANY

O banco de dados COMPANY registra os funcionários de uma empresa, odepartamento e o projeto nos quais eles trabalham, seus dependentes, a localização dosdepartamentos e dos projetos, etc. Tal banco de dados foi retirado da sexta edição dolivro Fundamentals of Database Systems [8], bem como as informações contidas nesseapêndice.

As próximas seções irão apresentar os requistos do banco de dados COMPANY,seu esquema conceitual, esquema lógico e, por fim, seu esquema físico.

B.1 Requisitos de Dados em Forma Textual

O banco de dados COMPANY organiza a empresa em departamentos. Cadadepartamento tem um nome exclusivo, um número exclusivo e um funcionário que ogerencia. A data em que tal funcionário começou a gerenciar o departamento também éregistrada. Um departamento pode estar localizado em várias cidades.

Um departamento controla um série de projetos, cada um deles com um nomeexclusivo, um número exclusivo e um único local.

Para cada funcionário é registrado o nome, Número do Seguro Social (SSN),endereço, salário, sexo(gênero) e data de nascimento. Um funcionário é designado paraum departamento, mas pode trabalhar em vários projetos, que não necessariamentesão controlados pelo mesmo departamento. O número de horas por semana que umfuncionário trabalha em cada projeto também é registado, bem como o supervisor diretode cada funcionário (que é outro funcionário).

Os dependentes de cada funcionário são registrados. Para cada dependente émantido o nome, sexo, data de nascimento e parentesco com o funcionário.

Apêndice B 104

B.2 Esquema Conceitual

O Modelo Entidade-Relacionamento descreve os dados como entidades, relaci-onamentos e atributos. A Figura B.1 mostra como o esquema do banco de dados COM-

PANY pode ser exibido por meio da notação gráfica conhecida como diagrama ER.

Figura B.1: Diagrama de esquema ER para o banco de dadosCOMPANY (retirado de [8])

De acordo com os requisitos listados na seção anterior, é possível identificarquatro entidades:

1. A entidade Funcionario (Employee) possui os atributos CPF (Ssn), DataNascimento(Bdate), Nome (Name), Endereco (Address), Salario (Salary) e Sexo (Sex). Sendoo atributo Name um atributo composto. O atributo(Ssn) é especificado como oatributo-chave (identificador) da entidade.

2. A entidade Departamento (Department) possui os atributos Nome (Name), Numero(Number), Numero_de_funcionarios (Number_of_employees) e Localizacoes (Lo-

cations). (Locations) é o único atributo multivalorado. Tanto (Name) como Numero(Number) podem ser especificados como atributos-chave (separadamente), uma vezque cada um foi especificado como sendo exclusivo.

Apêndice B 105

3. A entidade Projeto (Project) possui os atributos Nome (Name), Numero (Number)e Localizacao (Location). Tanto (Name) como (Number) são atributos-chave (sepa-radamente).

4. A entidade Dependente (Dependent) possui os atributos Nome (Name), Sexo (Sex),Data_nascimento (Birth_date) e Parentesco (Relationship). Dois dependentes dedois funcionários distintos podem, por coincidência, ter os mesmos valores paraName, Sex, Birth_date e Relationship, mas, ainda assim, eles são entidades distin-tas. Eles são identificados como entidades distintas somente depois de determinar aentidade de funcionário em particular à qual cada dependente está relacionado. Poreste motivo, a entidade Dependent é considerada uma entidade fraca, e o atributoName é considerado como chave parcial.

Essas entidades são relacionadas entre si por meio de seis relacionamentos:

1. O relacionamento Supervisao (Supervision) representa um auto-relacionamentoque associa um funcionário a um supervisor, no qual as entidades funcionário esupervisor são membros do mesmo conjunto - entidade Funcionário (Employee).

2. O relacionamento Gerencia (Manages) relaciona uma entidade de departamento aofuncionário que gerencia esse departamento. Esse relacionamento possui o atributoData_inicio (Start_date) que registra a data que um gerente começou a chefiar umdepartamento.

3. O relacionamento Trabalha_para (Works_for) associa cada funcionário ao departa-mento para o qual o funcionário trabalha.

4. O relacionamento Dependentes_de (Dependents_of ) representa um relacionamentoidentificador, uma vez que a entidade Dependente (Dependent) é fraca. Esse relaci-onamento associa um funcionário aos seus dependentes.

5. O relacionamento Trabalha_em (Works_on) associa cada funcionário ao projeto noqual ele trabalha. Tal relacionamento possui um atributo Horas (Hours) que registrao número de horas por semana que um funcionário trabalha em um projeto.

6. O relacionamento Controla (Controls) relaciona uma entidade de projeto ao depar-tamento que controla esse projeto.

B.3 Esquema Lógico

Com base no esquema conceitual é possível criar um esquema lógico. A FiguraB.2, também presente no Capítulo 3, apresenta o esquema lógico do banco de dadosCOMPANY. Tal figura apresenta as relações, seus atributos e as restrições de integridadereferencial.

Apêndice B 106

Figura B.2: Esquema lógico do banco de dados COMPANY (reti-rado de [8])

Existem seis relações:

1. A relação Employee possui 10 atributos. O atributo Ssn representa a chave primáriada relação, enquanto que o atributo Dno representa uma chave estrangeira para oatributo Dnumber da relação Department.

2. A relação Department possui 4 atributos. O atributo Dnumber representa a chaveprimária da relação, enquanto que o atributo Mgr_ssn representa uma chave estran-geira para o atributo Ssn da relação Employee.

3. A relação Dept_Locations possui 2 atributos, os quais formam uma chave primáriacomposta.

4. A relação Project possui 4 atributos. O atributo Pnumber representa a chaveprimária da relação, enquanto o atributo Dnum representa uma chave estrangeirapara o atributo Dnumber da relação Department.

5. A relação Works_on possui 3 atributos. Os atributos Essn e Pno formam uma chaveprimária composta, e referenciam os atributos Ssn da relação Employee e Pnumber

da relação Project, respectivamente.6. A relação Dependent possui 5 atributos. Os atributos Essn e Dependent_name

formam uma chave primária composta e o atributo Essn referencia o atributo Ssn

da relação Employee.

B.4 Esquema Físico

O modelo físico é construído a partir do modelo lógico e descreve as estruturasfísicas de armazenamento de dados, como o tipo e tamanho dos campos. É uma sequênciade comandos executados em SQL para criar o banco de dados. O Código B.1 apresentaos comandos para criação do banco COMPANY usando o MySQL.

Apêndice B 107

Código B.1 Esquema físico do banco de dados COMPANY1 create database COMPANY;

2 use COMPANY;

3

4 create table employee (

5 fname varchar(20) not null,

6 minit char(1) not null,

7 lname varchar(20) not null,

8 ssn char(9) not null,

9 bdate date not null,

10 address varchar(40) not null,

11 sex char(1) not null,

12 salary numeric(20,2) not null,

13 super_ssn char(9),

14 dno int not null,

15 primary key (ssn),

16 foreign key (super_ssn) references employee(ssn));

17

18 create table department (

19 dname varchar(20) not null,

20 dnumber int not null,

21 mgr_ssn char(9) not null,

22 mgr_start_date date not null,

23 primary key (dnumber),

24 unique(dname),

25 foreign key (mgr_ssn) references employee(ssn));

26

27

28 create table dept_locations (

29 dnumber int not null,

30 dlocation varchar(20) not null,

31 primary key ( dnumber, dlocation ),

32 foreign key(dnumber) references department (dnumber));

33

34 create table project (

35 pname varchar(20) not null,

36 pnumber int not null,

37 plocation varchar(20) not null,

38 dnum int not null,

39 primary key (pnumber),

40 unique (pname),

41 foreign key (dnum) references department (dnumber));

42

43 create table works_on (

44 essn char(9) not null,

45 pno int not null,

46 hours numeric(3,1),

47 primary key(essn,pno),

48 foreign key (essn) references employee (ssn),

49 foreign key (pno) references project(pnumber));

50

51 create table dependent (

52 essn char(9) not null,

53 dependent_name varchar(20) not null,

54 sex char(1) not null,

55 bdate date not null,

56 relationship varchar(15) not null,

57 primary key(essn, dependent_name),

58 foreign key (essn) references employee (ssn));

um método de análise semântica de consultas com palavras

Documents