Um Método de Análise Semântica de Consultas com Palavras-chave para acesso a Informações Armazenadas em Múltiplos Bancos de Dados

Transcrição

1 UNIVERSIDADE FEDERAL DE GOIÁS INSTITUTO DE INFORMÁTICA MARIANA SOLLER RAMADA Um Método de Análise Semântica de Consultas com Palavras-chave para acesso a Informações Armazenadas em Múltiplos Bancos de Dados Goiânia 2013

2 MARIANA SOLLER RAMADA Um Método de Análise Semântica de Consultas com Palavras-chave para acesso a Informações Armazenadas em Múltiplos Bancos de Dados Dissertação apresentada ao Programa de Pós Graduação do Instituto de Informática da Universidade Federal de Goiás, como requisito parcial para obtenção do título de Mestre em Mestrado em Ciência da Computação. Área de concentração: Banco de Dados. Orientador: Prof. Dr. João Carlos da Silva Goiânia 2013

3 MARIANA SOLLER RAMADA Um Método de Análise Semântica de Consultas com Palavras-chave para acesso a Informações Armazenadas em Múltiplos Bancos de Dados Dissertação defendida no Programa de Pós Graduação do Instituto de Informática da Universidade Federal de Goiás como requisito parcial para obtenção do título de Mestre em Mestrado em Ciência da Computação, aprovada em 26 de Fevereiro de 2013, pela Banca Examinadora constituída pelos professores: Prof. Dr. João Carlos da Silva Instituto de Informática UFG Presidente da Banca Prof. Dr. Thierson Couto Rosa Instituto de Informática UFG Profa. Dra. Mirella Moura Moro Departamento de Ciência da Computação UFMG

4 Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho 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 de Goiás. Durante sua graduação, foi estagiária do Centro de Recurso Computacionais (Cercomp) da UFG. Durante o Mestrado, foi bolsista REUNI e monitora no Instituto de Informática na disciplina Banco de Dados do curso de Ciência da Computação. Atualmente é Analista de Tecnologia da Informação do Instituto de Informática da Universidade Federal de Goiás.

5 Aos meus pais

6 Agradecimentos Primeiramente, agradeço ao meu pai e minha mãe que acreditaram e investiram em mim, dando todo o suporte e educação e não medindo esforços para que eu chegasse onde estou agora. Ao meu irmão Marcelo que é um exemplo de pessoa e aluno, e um dos principais motivos pelo qual eu decidi fazer o mestrado. Agradeço ao meu namorado Murilo, pelo carinho, dedicação, paciência, incentivo e principalmente por sua capacidade de me trazer paz na correria de cada semestre. Agradeço também ao professor Dr. João Carlos que desempenhou um papel imensamente importante em minha vida acadêmica, desde a graduação quando lecionou a matéria de Banco de Dados, descobrindo então minha paixão pela área, até a monografia de conclusão do curso sob sua orientação. Agradeço principalmente pela insistência a qual me levou a fazer o mestrado e pela confiança em mim depositada. Agradeço também pela disponibilidade, pela paciência, pelas correções, pelos seus conhecimentos repassados durante todo o desenvolvimento deste trabalho e pela oportunidade de ser monitora da disciplina 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 disposto a me atender, mesmo sem marcar horário, e gastava horas de seus dias discutindo as próximas tarefas a serem feitas durante a implementação, sanando dúvidas e levantando novas ideias que agregaram muito valor a este trabalho. Obrigada pelas reuniões esclarecedoras e principalmente motivadoras, e também pela preocupação, afinal como você 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 tempo dedicado e pela boa vontade de me ajudar a concluir esse trabalho. Aos colegas de trabalho que muitas vezes deixaram de lado seus afazeres e me ajudaram durante o desenvolvimento deste trabalho. Em especial ao Danillo, pela ajuda na implementação, com algumas dicas e melhorias; e ao Afonso, pela ajuda na escrita do texto. Aos colegas do curso pela convivência, estudo, alegrias, tristezas e dores compartilhadas. Em especial ao Alison que sempre esteve acompanhando meu trabalho, sugerindo ideias, discutindo problemas e soluções; a Elisabete que sempre foi solicita respondendo meus s, enviando-me seu material e sanando minhas inúmeras dúvidas; e ao

7 Adriano, Roussian, Douglas e Lucas, com vocês as pausas entre um parágrafo e outro de produção se tornaram mais prazerosas e proveitosas. Aos meus amigos e familiares que apesar da distância estiveram torcendo e apoiando. Ao REUNI pelo apoio financeiro. E por fim, a todos que direta ou indiretamente me ajudaram a concretizar mais esta etapa da minha vida.

8 Você nunca sabe que resultados virão da sua ação. Mas se você não fizer nada, não existirão resultados. Mahatma Gandhi

9 Resumo Ramada, Mariana Soller. Um Método de Análise Semântica de Consultas com Palavras-chave para acesso a Informações Armazenadas em Múltiplos Bancos de Dados. Goiânia, p. Dissertação de Mestrado. Instituto de Informá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, fazendose 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ão o 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 dados relacionais, e tais repósitorios oferecem suporte limitado para a pesquisa com palavraschave. Para se realizar consultas em banco de dados relacionais é necessário o conhecimento 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 consultas com palavras-chave em banco de dados relacionais, a fim de eliminar a necessidade deste conhecimento prévio e permitir uma recuperação simplificada dos dados dos múltiplos bancos de dados disponíveis na Web. Palavras chave Consulta com palavras-chave, Banco de dados relacionais, Semântica

10 Abstract Ramada, Mariana Soller. An Analysis Semantic Method of Keyword Queries over Multiple Databases. Goiânia, p. MSc. Dissertation. Instituto de Informática, Universidade Federal de Goiás. Information flows mainly through the Web in the present society. This information is scattered and stored in different data storages, which requires an access interface to retrieve it. Keyword query proved to be a simple and effective way to access the information, becoming the standard user-web interaction. However, most Web information is stored in relational databases, and such repositories offer limited support for keyword queries. To perform queries in relational databases is necessary to know the data schema and the syntax of a structured query language, which are not familiar to most of ordinary users. In this sense, the purpose of this paper is to present a method for performing keyword queries in relational databases in order to eliminate the need of this prior knowledge, and enable a simplified recovery of data from multiple databases available on the Web. Keywords Keyword query, Relational database, Semantics.

11 Sumário Lista de Figuras 12 Lista de Tabelas 13 Lista de Algoritmos 15 Lista de Códigos de Programas 16 1 Introdução Contexto e Motivação Objetivos Principais Problemas Organização do Texto 21 2 Trabalhos Relacionados 22 3 Contexto e Arquitetura para o Método Proposto Contexto Arquitetura Pré-processamento 31 Verificação de Função Agregada/Ordenação/Valores Compostos 32 Expansão da consulta Processamento da consulta 34 Identificação dos bancos de dados relevantes 34 Ranking dos bancos de dados relevantes 35 Mapeamento 36 Execução 37 Ranking dos resultados Considerações Finais 38 4 Análise Semântica da Consulta Definição do problema Análise Semântica segundo a Keymantic Cálculo dos pesos intrínsecos (Passo 1) 43 Cálculo dos pesos intrínsecos dos termos de esquema do banco de dados 44 Cálculo dos pesos intrínsecos dos termos de valor do banco de dados Seleção dos Melhores Mapeamentos para os termos de esquema (Passo 2) 46 Processo de Seleção dos Melhores Mapeamentos 47

12 4.2.3 Contextualização de VW e Seleção dos Melhores Mapeamentos para os termos de valor (Passo 3) 49 Regras e Processo de Contextualização Geração das Configurações (Passo 4) Geração das Interpretações (Passo 5) Consideração Finais 55 5 Contribuições à Analise Semântica Limitações da Keymantic Modificações à abordagem da Keymantic Considerações Finais 64 6 Aplicação do Método Proposto Estudos de Caso Estudo de Caso - Funções Agregadas e Ordenação Estudo de Caso - Valores Compostos Comparação com a Keymantic Suposições à implementação Keymantic Exemplo selecionado para Comparação 83 Cálculo dos pesos intrínsecos (Passo 1) 84 Seleção dos Melhores Mapeamentos para os termos de esquema (Passo 2) 85 Contextualização de VW e Seleção dos Melhores Mapeamentos para os termos de valor (Passo 3) 87 Geração das Configurações (Passo 4) 88 Geração das Interpretações (Passo 5) 89 Impacto das Modificações Internas à Keymantic 89 Ranking dos resultados Considerações Finais 93 7 Conclusão Contribuições Trabalhos Futuros 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 103 B.1 Requisitos de Dados em Forma Textual 103 B.2 Esquema Conceitual 104 B.3 Esquema Lógico 105 B.4 Esquema Físico 106

13 Lista de Figuras 3.1 Arquitetura do método proposto (inspirado em [28]) Banco de dados COMPANY (retirado de [8]) 31 (a) Esquema lógico do banco de dados COMPANY com suas restrições de integridade referencial. 31 (b) Fração dos dados do banco de dados COMPANY Mapeamento das palavras-chave (retirado de [3]) Processo de Mapeamento com as etapas modificadas em destaque 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 Métrica de precisão para ambos os sistemas 91 (a) 91 (b) Gráfico MRR-Tamanho da consulta (inspirado em [10]) 92 B.1 Diagrama de esquema ER para o banco de dados COMPANY (retirado de [8]) 104 B.2 Esquema lógico do banco de dados COMPANY (retirado de [8]) 106

14 Lista de Tabelas 3.1 Atributos da Tabela de Metadados para Exposição (TME) [20] Informações da Tabela de Metadados para Exposição(TME) do banco de dados COMPANY (inspirado em [20]) Matriz de peso com a submatrizes SW (claro) e VW (escuro) (retirado de [4]) Pesos intrínsecos da Submatriz SW (inspirado em [4]) Pesos intrínsecos da Submatriz VW (inspirado em [4]) Mapeamento para a consulta employees dependent relationship Primeira matriz gerada a partir do mapeamento da Tabela Segunda matriz gerada a partir do mapeamento da Tabela Terceira matriz gerada a partir do mapeamento da Tabela Mapeamento onde todas as palavras-chave são mapeadas para termos de esquema Mapeamento parcial das palavras-chave para termos de esquema Mapeamento parcial das palavras-chave para termos de valor Mapeamento considerando a proximidade entre as palavras-chave Pesos intrínsecos da Submatriz SW (consulta quantity employees for each department order by name ) Pesos intrínsecos da Submatriz VW (consulta quantity employees for each department order by name ) Mapeamento da consulta quantity employees for each department order by name Primeiro mapeamento gerado a partir do mapeamento da Tabela Segundo mapeamento gerado a partir do mapeamento da Tabela Terceiro mapeamento gerado a partir do mapeamento da Tabela Primeiro mapeamento gerado a partir do mapeamento da Tabela Segundo mapeamento gerado a partir do mapeamento da Tabela Terceiro mapeamento gerado a partir do mapeamento da Tabela Mapeamento gerado a partir do mapeamento da Tabela Mapeamento da consulta quantity employees for each department order by department Pesos intrínsecos da Submatriz SW (consulta employees Houston Tx ) Pesos intrínsecos da Submatriz VW (consulta employees Houston Tx ) Mapeamento da consulta employees Houston Tx Submatriz VW contextualizada com base no mapeamento da Tabela Mapeamento para termos de valor (consulta employees Houston TX ) 79

15 6.17 Mapeamento gerado a partir do mapeamento da Tabela Mapeamento gerado após negativar os pesos iguais à Pesos intrínsecos da Submatriz SW calculados pelo MP Pesos intrínsecos da Submatriz SW calculados pela Keymantic Pesos intrínsecos da Submatriz VW calculados pelo MP Pesos intrínsecos da Submatriz VW calculados pela Keymantic Mapeamento gerado pelo MP Mapeamento gerado pela Keymantic Mapeamento gerado a partir do mapeamento da Tabela 6.24 (Keymantic) Submatriz VW contextualizada com base no mapeamento da Tabela 6.23 (MP) Submatriz VW contextualizada com base no mapeamento da Tabela 6.24 (Keymantic) Submatriz VW contextualizada com base no mapeamento da Tabela 6.25 (Keymantic) Conjunto de consultas com palavras-chave Mapeamento a partir do qual são gerados mapeamentos que não estão de acordo com a ordem decrescente de pontuação 92

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

17 Lista de Códigos de Programas 6.1 Código da primeira configuração para a consulta quantity employees for each department order by department Código SQL da segunda configuração para a consulta quantity employees for each department order by department Código SQL da quarta configuração para a consulta quantity employees for each department order by department Código SQL gerado para consulta employees Houston Tx 81 A.1 Código SQL para a criação da Tabela de Metadados para Exposição (TME) [20] 102 B.1 Esquema físico do banco de dados COMPANY 107

18 Introdução CAPÍTULO 1 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.1 são apresentados o contexto e a motivação que deram origem a este trabalho, seguidos dos objetivos traçados na Seção 1.2 e as principais dificuldades a serem solucionadas na Seçã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 vez produzida, circula instantaneamente e se torna disponível em qualquer parte do mundo. A rede mundial de computadores é uma maneira muito eficiente de se ter acesso a uma grande quantidade de informações de forma simultânea, transpondo barreiras geográficas e temporais, e possibilitando a troca de dados, informações, decisões e conhecimento de uma maneira surpreendentemente ágil. A quantidade de informações disponíveis no universo online está além da capacidade que uma pessoa poderia assimilar durante uma vida inteira. As informações estão dispersas nos mais diversos meios de armazenamento e o usuário normalmente não sabe como e onde encontrá-las. Neste sentido, é necessário uma interface de recuperação de informação, de modo que o usuário submeta sua necessidade de informação e o sistema busque pelas fontes que contenham informações relevantes para 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écnica de consulta com palavras-chave. A última década presenciou o emprego cada vez maior desta tecnologia de pesquisa que tornou-se de fato um padrão para a interação do usuário com a World Wide Web (WWW). Porém, a técnica não é utilizada de forma generalizada por todos os meios de armazenamento. Dentre eles, estão os bancos de dados relacionais que são uma forma importante de armazenamento de dados.

19 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 suporte limitado 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 pelos motores de busca, uma vez que a maioria dos dados são armazenados em bancos de dados e 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ível era 400 ou 550 vezes maior do que a Web visível. Em 2008, estimou-se que 70 a 75% de todos os dados da Web estavam armazenados na Web Invisível, ou seja, cerca de um trilhão de 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 e bancos de dados. Permitir consulta com palavras-chave em bases de dados relacionais seria um bom começo para a solução deste problema. Assim, nos últimos anos tem-se empregado um grande esforço em atividades de pesquisa e desenvolvimento para estender as capacidades de busca com palavraschave para fontes de dados que seguem o paradigma relacional. No entanto, as técnicas que utilizam palavras-chave para busca na Web não podem ser aplicadas diretamente em dados 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 do banco de dados que contenham as palavras-chave da consulta e explorar como estas estruturas são conectadas entre si. Isto exige, por parte do usuário, um conhecimento prévio da estrutura do banco de dados e de uma linguagem estruturada, como a SQL, para formular uma consulta. Contudo, nem todos os usuários possuem tal conhecimento, o que se torna uma limitação ao acesso destes dados. Nesse sentido, o propósito deste trabalho é apresentar um método para solucionar consultas com palavras-chave em bancos de dados relacionais, a fim de eliminar a necessidade deste conhecimento prévio e permitir uma recuperação simplificada dos dados 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 presente trabalho é permitir que a partir de uma consulta com palavras-chave submetida por um usuário, sejam identificados os bancos de dados relacionais que contêm informações relevantes para a consulta, e esta seja então submetida a cada banco de dados subjacente e os resultados por eles retornados sejam exibidos ao usuário.

20 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 SQL correspondentes. Contudo, uma consulta SQL é uma consulta estruturada onde as tabelas, os atributos e suas condições são precisamente especificadas, enquanto que uma consulta com palavra-chave é formada por termos indefinidos que expressam a necessidade de informação do usuário. Como mencionado anteriormente, um grande esforço tem sido despendido visando estender as capacidades de busca com palavras-chave para bancos de dados relacionais. Contudo, as técnicas existentes possuem algumas limitações. A primeira limitação é que tais abordagens consideram que toda palavra-chave desempenha algum papel no banco de dados e cada palavra-chave é mapeada para uma estrutura do banco de dados correspondente. Considere o esquema de relação Employee (Fname, Minit, Lname, Ssn, Bdate, Address, Sex, Salary, Superssn, Dno) do exemplo do 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 de tuplas interconectadas que possuam as palavras-chave higher e salary. A segunda limitação é que a consulta é segmentada de modo que cada palavrachave represente isoladamente um papel no banco de dados. Ainda considerando a relaçã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-chave Houston 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 a interdependência entre as palavras-chave. Apesar do fato de uma consulta ser uma lista simples de palavras-chave, o significado de cada palavra-chave não é independente do significado das demais, todos eles representam coletivamente os conceitos pretendidos que o usuário tinha em mente ao construir a consulta. A abordagem inerente à ferramenta Keymantic [3] foi escolhida como um ponto de 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 uma consulta pode assumir. Assim, o presente trabalho tem também como objetivo abordar as limitações mencionadas acima e agregar semântica a este processo de conversão, a fim de fazer uma melhor suposição do significado pretendido pela consulta com palavra-chave e construir consultas SQL que representem as intenções do usuário.

21 1.3 Principais Problemas Principais Problemas Os problemas identificados durante o desenvolvimento deste trabalho dizem respeito à aplicação de técnicas de consultas com palavras-chave em banco de dados relacionais, nas quais é necessário um processo de conversão da consulta com palavraschave em consultas SQL correspondentes. Uma das primeiras dificuldades deste processo de conversão é a decisão sobre qual papel cada palavra-chave desempenha no contexto da consulta, isto é, se ela é um valor de um dado, ou uma metainformação que descreve o conceito de outra palavrachave. Por exemplo, na consulta nome João a palavra-chave nome descreve o fato da palavra-chave João ser um nome. Uma vez descoberto o papel desempenhado por cada palavra-chave, é preciso descobrir como cada palavra-chave é modelada no banco de dados, ou seja, a palavrachave representa um atributo, uma tabela ou um valor de um atributo? É pertinente saber 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ão modelados em forma de tabelas e atributos. Uma informação pode estar espalhada em mais de uma estrutura do banco de dados, sendo necessário fazer a junção destes dados de modo a obter a informação pretendida. A junção em banco de dados é realizada por meio de relacionamentos entre chave primária e chave estrangeira ou por meio do relacionamento tabela-atributo-valor. Em adição, uma única palavra-chave pode ser modelada de várias maneiras no banco de dados subjacente, porém nem todas as maneiras representam a informação pretendida pelo usuário. Tal fato, se torna mais uma dificuldade a ser solucionada: como identificar qual estrutura do banco de dados melhor modela ou representa o significado da palavra-chave pretendida no contexto da consulta? E se existir mais de um banco de dados com informações úteis para a consulta com palavras-chave? É necessário mapear a consulta para os termos de cada banco de dados, considerando o fato de que cada um deles pode possuir um esquema de dados diferente. Por exemplo, a palavra carro poderia ser representada como uma tabela em um banco de dados, enquanto que em outro poderia ser representada como um atributo. Desta forma, durante o processo de conversão é necessário considerar esta heterogeneidade de esquemas, de modo que a partir de uma única consulta com palavraschave seja construída uma série de consultas SQL, cada qual considerando o contéudo do banco 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 relacionais dependerem das informações do esquema e/ou dos dados para realizar o processo

22 1.4 Organização do Texto 21 de conversão. Caso estas informações não sejam disponibilizadas pelo administrador do banco de dados, não é possível realizar tal processo e consequentemente não é possível consultar os dados. 1.4 Organização do Texto Após este capítulo inicial, o presente documento possui outros seis capítulos. O Capítulo 2 apresenta alguns trabalhos relacionados ao contexto de consulta com palavraschave em bancos de dados relacionais. O Capítulo 3 apresenta uma descrição mais detalhada do problema a ser solucionado neste trabalho, bem como a arquitetura da solução proposta. A solução proposta se baseia no uso da Keymantic, uma ferramenta já existente de consulta com palavras-chave em banco de dados relacionais. O Capítulo 4 apresenta tal ferramenta e detalha seu funcionamento. O Capítulo 5 descreve as adaptações realizadas nesta ferramenta para compor a solução final. O Capítulo 6 exemplifica o funcionamento da solução proposta, bem como realiza uma análise comparativa entre a Keymantic e o método proposto. E por fim, o Capítulo 7 expõe as conclusões e contribuições obtidas com este trabalho e os possíveis trabalhos futuros.

23 Trabalhos Relacionados CAPÍTULO 2 A adaptação de consultas com palavras-chave para extrair informações de bancos de dados estruturados já atraiu a atenção de vários pesquisadores e há muitas propostas interessantes na literatura científica. Para identificar tais propostas e verificar o estado da arte desta área de pesquisa foi realizada uma revisão sistemática [29]. Por meio deste estudo, foi possível identificar duas principais abordagens para solucionar o problema de consultas com palavras-chave em banco de dados relacionais: a abordagem baseada em Candidate Networks e a abordagem baseada em Steiner Trees. Na abordagem baseada em Candidate Networks, o banco de dados é modelado como um grafo de esquema G s (V,E), onde cada relação R i é representada como um nó no grafo, e existe uma aresta R i R j para cada relacionamento entre chave primária e chave estrangeira de R i para R j [16]. Esta abordagem é dividida em duas etapas: a etapa 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 dos dados e das palavras-chave da consulta, de modo a identificar diretamente as tuplas que contém tais palavras-chave. Tais indíces são construídos em uma etapa anterior ao processamento da consulta. A partir destas tuplas de interesse são gerados os CNs, que são conjuntos de tuplas que contêm todas as palavras-chave da consulta e são conectados através de relações entre chave primária e chave estrangeira. Na etapa de avaliação, estes CNs gerados são convertidos em consultas SQL e estas consultas são, então, executadas e os resultados apresentados aos usuários. Na abordagem baseada em Steiner Tree, o banco de dados é modelado como um grafo de dados G d (V,E) ponderado, onde cada nó corresponde a uma tupla do banco de dados 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 é uma Steiner Tree de V se T cobre todos os vértices em V [23]. Assim, nesta abordagem o problema de consultas com palavras-chave é modelado como o problema de se encontrar Steiner Trees no grafo de dados, onde V representa o conjunto de palavras-chave da consulta. Em síntese, esta abordagem retorna subgrafos como resposta, onde os subgrafos conectam os nós (isto é, tuplas) contendo as palavras-chave da consulta.

24 23 DBXplorer [2], DISCOVER [17] e BANKS [1] estão entre os primeiros sistemas de consultas com palavras-chave em banco de dados relacionais. Os dois primeiros implementam a abordagem baseada em Candidate Networks, enquanto que o último aplica a abordagem baseada em Steiner Tree. DBXplorer retorna todas as tuplas que contêm as palavras-chave, tanto de tabelas individuais como de múltiplas tabelas por meio de junções de chaves estrangeiras. Para tanto, 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 consulta no 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 dos CNs, o sistema propõe um algoritmo guloso que cria um plano de execução quase ideal para 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 e segundo, ele considera apenas correspondências exatas, onde uma palavra-chave deve corresponder exatamente ao valor de um atributo. O sistema BANKS provê uma rica interface que permite navegar sobre os dados armazenados em um banco de dados. O sistema gera automaticamente visões navegáveis sobre 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 tuplas em uma tabela selecionada podem ser ordenadas por colunas, os resultados podem ser agrupados por coluna e o usuário pode clicar em qualquer valor do resultado para ver as tuplas associadas a este valor, etc. Nos três sistemas, uma consulta pode obter mais de um resultado, sendo assim desejá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 acordo com suas pontuações. Intuitivamente, os resultados do topo da lista são mais relevantes para a consulta do que aqueles que estão no final. Algumas teorias e práticas para ordenação de documentos foram desenvolvidas na comunidade de Recuperação de Informação a fim de agregar funções de ranking. Por exemplo, o esquema de pontuação tf-idf (term frequency-inverse document frequency) é amplamente usado no contexto de documentos. Este peso é uma medida estatística usada para avaliar o quão importante é uma palavra para um documento em uma coleção. A importância aumenta proporcionalmente ao número de vezes que uma palavra aparece no documento, 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

25 24 (RI). Hristidis et al. [16] usa o método simples de tf-idf, e Liu et al. [24] aplica medidas mais complexas de RI. Enquanto Hristidis et al. [16] e Liu et al. [24] pontuam cada atributo 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 identificadas e aplicadas no contexto de banco de dados relacionais. Nos sistemas DISCOVER [17] e DBXplorer [2], os resultados da consulta com palavras-chave contêm todas as palavraschave da consulta e são ordenados por métodos simples, por exemplo, com base no número de junções. Já no sistema BANKS [1], o cálculo das pontuações dos resultados levam 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 que a resposta contenha todas as palavras-chave da consulta, enquanto que a abordagem OR-semantics requer apenas que a resposta contenha alguma, mas não necessariamente todas as palavras-chave da consulta. DBXplorer, DISCOVER e BANKS se enquadram na abordagem AND-semantics, enquanto que no trabalho de Hristidis et al. [16] foi proposto um aprimoramento do DISCOVER, adicionando suporte para a abordagem ORsemantics. 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ários nã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 um sistema que permite não apenas consultas exatas, mas também consultas que possuem dissimilaridades. Para tanto, propõe um método de classificação dos resultados com base na dissimilaridade e a correlação entre diferentes tipos de objetos. A dissimilaridade d(i, j) entre dois objetos é denotada por um valor numérico que representa a diferença entre 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 como c(i, j) = 1 d(i, j). No sistema TASTIER [23], o objetivo é guiar o usuário na formulação da consulta 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 uso das 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 consultas 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, formada por palavras-chave e operadores lógicos, o sistema proposto identifica os bancos de da-

26 25 dos mais propensos a retornar resultados relevantes para a consulta q, e então pesquisa somente estes bancos de dados. Para calcular a utilidade de cada um deles para a consulta q, é criado um índice invertido que armazena as estatísticas do banco de dados e estas estatísticas são então utilizadas para representar quão útil ele é para a consulta. De maneira semelhante, o propósito do trabalho em [34] é identificar os bancos de dados relevantes para uma determinada consulta com palavras-chave. Para Hassan et al. [15], a utilidade de um banco de dados é calculada apenas com base na frequência com que a palavra-chave aparece 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 um parâmetro que é o inverso da distância do caminho de junção que conecta duas palavraschave. Desta forma, além de considerar a representativade da palavra-chave no banco de dados, 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 relacionamento entra elas, ou seja, quanto mais distante as palavras-chave, mais fraca é a relação entre elas e consequentemente menos significativa ela é para a consulta. Sayyadian et al. [30] assumem que a resposta para uma consulta com palavraschave pode não residir em apenas um único banco de dados e sim em múltiplos bancos de dados. Neste sentido, é necessário combinar as tuplas de vários bancos de dados para obter a resposta desejada. Assim, neste trabalho é proposto o algoritmo Kite que encontra junções aproximadas entre chaves estrangeiras de múltiplos bancos de dados heterogêneos. O sistema FRISK [28] faz uso de um algoritmo de programação dinâmica para computar as melhores segmentações da consulta e apresentá-las ao usuário, que por sua vez escolhe a que mais se aproxima de sua intenção. E por fim, Keymantic [3] e Keyword++ [13] são ferramentas que levam em consideração as várias interpretações que uma consulta pode assumir, considerando a ambiguidade da consulta, e prezando pela completude e precisão das respostas. A completude se refere a retornar todos os resultados relevantes, enquanto que a precisão se refere 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-chave que 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 identificar os bancos de dados que possuem informações relevantes para a consulta com palavraschave, realizar um tratamento semântico de tal consulta e segmentar a consulta de modo a considerar a possibilidade de mapear conjuntamente duas ou mais palavras-chave. Além desses aspectos, o método proposto leva em consideração consultas com palavras-chave que representam estatísticas e não estruturas do banco de dados para as quais devem ser mapeadas.

27 CAPÍTULO 3 Contexto e Arquitetura para o Método Proposto Segundo Hopcroft [26], uma das grandes áreas atuais de pesquisa é a de Recuperação de Informação, pois existem todos os tipos de informação em um banco de dados que 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 respeito das estruturas do banco de dados e de uma linguagem de consulta estruturada. A fim de simplificar o acesso a estes dados, o presente trabalho propôs um método de consulta com palavras-chave em bancos de dados relacionais. O contexto introduzido no Capítulo 1 será expandido na Seção 3.1. A Seção 3.2 apresenta 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 tornou o principal canal de circulação e disseminação de informações. As informações estão espalhadas 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 devido à dispersão das fontes, divergências nas interfaces de busca, falta de integração dos conteúdos, dentre outros. Nesse sentido, foi criada a Open Archives Initiative (OAI), uma iniciativa para desenvolver e promover padrões de interoperabilidade entre repositórios digitais. Para tanto, a OAI criou o protocolo OAI-PMH (Open Archives Initiative - Protocol for Metadata Harvesting) que permite a publicação e compartilhamento de coleções digitais com o objetivo de facilitar a disseminação eficiente de conteúdo entre esses repositórios. A interoperabilidade entre os repositórios digitais promovida pelo protocolo OAI-PMH permite a criação de novos serviços, como a busca federada, que consiste em submeter uma consulta a um grupo de bases de dados dispersas, agrupando os resultados coletados destas bases de dados e apresentando-os em um formato sucinto e unificado, ou

28 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 protocolo OAI- PMH realiza uma busca automática de metadados (harvesting) de recursos que adotam 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 os metadados de todos os repositórios pesquisado, é consultada. A publicação e compartilhamento de coleções digitais são mecanismos utilizados de forma mais ampla por bibliotecas digitais e sites da Internet. Porém, uma grande quantidade de informação encontra-se armazenada em bancos de dados, principalmente relacionais. Quando um usuário submete uma consulta na Internet, utilizando algum programa de busca, o mecanismo de execução da pesquisa não alcança aquelas informações armazenadas 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 mecanismo que permita a divulgação dessas fontes de informação. Assim, a publicação e o compartilhamento de metadados de bancos de dados são uma vertente que ainda não foi explorada a contento [20]. Com a finalidade de permitir a busca por informações em bancos de dados relacionais através da Web, Kowata define em [20] um mecanismo que permite a consulta a bibliotecas digitais e a bancos de dados de forma homogênea, por meio da definição de um conjunto comum de metadados utilizados para exportar (disponibilizar) essas fontes de informação. Para permitir a publicação e o compartilhamento de recursos digitais, o protocolo OAI- PMH necessita de um formato padrão de metadados. O padrão utilizado no contexto de bibliotecas digitais é o padrão Dublin Core [11]. Em [20] é feito um estudo dos elementos do padrão Dublin Core utilizados para representar metadados para bibliotecas digitais, de modo a identificar quais elementos seriam necessários para descrever um banco de dados relacional. As informações a respeito da estrutura de um banco de dados podem ser encontradas no catálogo de um sistema gerenciador de banco de dados que armazena informações como esquemas dos bancos criados no sistema, descrição das tabelas de cada esquema, 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 descrito em [20] a respeito dos catálogos dos principais gerenciadores de banco de dados disponíveis atualmente, demonstrou-se que em tais catálogos não há os metadados necessários para descrever um recurso de informação em repositórios digitais. Nesse sentido, o estudo resultou na definição de um conjunto comum de metadados para descrever um banco de dados a fim de promover a interoperabilidade entre estas bases de dados e outras fontes de informações, tais quais as bibliotecas digitais, e permitir a publicação (disponibilização)

29 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 elementos. Além desses 15, foram propostos mais 8 elementos necessários para a descrição dos metadados de banco de dados relacionais, totalizando assim 23 elementos. A Tabela 3.1 resume o conjunto destes atributos definidos para descrever os metadados de um banco de dados. Os nomes dos elementos iniciados com dc_ representam os elementos que pertencem ao padrão Dublin Core e que são utilizados no contexto de bibliotecas digitais. Os elementos que não são iniciados por dc_ representam os elementos adicionais propostos pelo 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 oai_set dispquery dc_title dc_creator dc_subject dc_description dc_contributor dc_publisher dc_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; 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. É utilizado para 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;

30 3.1 Contexto 29 dc_publisher: utilizado para informar o nome da entidade/instituição responsável por 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ão estão disponíveis no catálogo do sistema, o mecanismo proposto em [20] sugere que estes metadados sejam fornecidos pelo administrador do banco de dados e armazenados em uma tabela que representará uma extensão do catálogo do sistema gerenciador de banco de dados. Essa tabela para armazenamento de metadados, denominada Tabela de Metadados para Exposição (TME), contém um atributo para cada um dos elementos descritos na Tabela 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 metadados sã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 permite a indexação destes bancos de dados e o compartilhamento dos seus dados com os demais usuários da rede. De forma geral, esse trabalho permite a exposição dos metadados dos bancos de dados relacionais que podem então ser indexados. Contudo, isso não é suficiente para permitir a recuperação dos dados destas fontes de informações. Para se realizar consultas em banco de dados relacionais é necessário o conhecimento das estruturas de armazenamento e da sintaxe de uma linguagem estruturada, como o SQL. Contudo, a maioria dos usuários não possui esse conhecimento, tornando-se assim uma limitação ao acesso desses dados. Nesse sentido, surge a ideia de expandir a técnica de consulta com

31 3.2 Arquitetura 30 palavras-chave para banco de dados relacionais, uma vez que elimina a necessidade desse conhecimento 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 dos bancos de dados relacionais, mas não a consulta a estes dados, o presente trabalho visa propor um método de recuperação dos dados destes bancos por meio do uso da técnica de consulta com palavra-chave. 3.2 Arquitetura Dada uma única consulta com palavras-chave, o método proposto neste trabalho identifica os bancos de dados disponíveis e relevantes para tal consulta, e converte esta consulta em consultas SQL correspondentes, as quais são submetidas aos bancos de dados identificados como relevantes. Como resposta à consulta com palavras-chave, o método retorna 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 banco de dados COMPANY proposto por Elmasri e Navathe [8]. A Figura 3.2(a) apresenta o esquema de relações enquanto que a Figura 3.2(b) ilustra a fração dos dados do banco de dados COMPANY. Maiores informações a respeito deste banco de dados podem ser encontradas no Apêndice B.

32 3.2 Arquitetura Pré-processamento A fase de Pré-processamento da consulta é responsável por limpar a consulta com palavras-chave, identificar a melhor segmentação da consulta para valores compostos por mais de uma palavra-chave, e por fim agregar semântica à consulta. (a) Esquema lógico do banco de dados COMPANY com suas restrições de integridade referencial. (b) Fração dos dados do banco de dados COMPANY. Figura 3.2: Banco de dados COMPANY (retirado de [8])

33 3.2 Arquitetura 32 Algumas palavras-chave da consulta podem não ter um significado em relação aos termos do banco de dados. Por exemplo, considere a consulta higher salary. A palavra-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 de dados 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 que possuem um significado real na base de dados. Outro fator considerado nessa fase de pré-processamento é a segmentação da consulta. Palavras-chave que podem ser mapeadas para valores de atributos, ou seja, para os dados em si, devem receber uma atenção especial durante o momento de segmentação da consulta. Se a consulta for segmentada de tal maneira que cada palavra-chave represente um termo do banco de dados para a qual será mapeada, valores como endereço e descrição de um produto poderão perder seu significado. Por exemplo, considere a consulta employee Houston TX. Uma possível interpretação dessa consulta é encontrar os empregados que moram em Houston, TX. Assim, espera-se que as palavras-chave Houston 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 compostos 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-chave da 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-chave workers não existe nenhum termo no banco de dados da Figura 3.2(a) que forneça uma correspondência exata. Mas se for considerado que o conceito de employee é similar ao conceito de workers, então é possível mapear workers para a relação Employee. A fase de Pré-processamento é composta por duas etapas, as quais consideram os fatores mencionados acima. As duas etapas, Verificação de Função Agregada/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ção do uso de funções agregadas e ordenação, bem como a identificação de palavras-chave que 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 e ordenação é feita por meio de uma lista de palavras reservadas. Essas palavras reservadas nada mais são que um conjunto de palavras pré-definidas com base na observação de como os usuários formulam suas consultas. Além disso, outro fato observado é que

34 3.2 Arquitetura 33 as palavras-chave que representam o uso de funções agregadas são seguidas da palavra em que será aplicada a função. Por exemplo, na consulta higher salary a palavra-chave higher é identificada na lista de palavras reservadas e por meio dessa lista descobre-se que ela 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, ela será 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 Employee. Dessa forma, a consulta higher salary pode ser então convertida para a consulta SQL: select max(salary) from Employee. A identificação do uso de ordenação e agrupamento segue o mesmo raciocínio. A identificação das palavras-chave que devem ser consideradas conjuntamente para formar o valor de um atributo é feita por meio do uso de aspas simples. Por exemplo, no caso da consulta employee Houston TX, as palavras-chave Houston TX devem aparecer entre aspas simples para representar a necessidade de serem mapeadas conjuntamente 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 agregadas e ordenação, a consulta permanece apenas com palavras-chave que representam algum termo do banco de dados. Porém, como mencionado anteriormente, nem sempre as palavras-chave são uma representação exata do termo que está no banco. Para lidar com esse problema, é necessário considerar também outras palavras relacionadas à essas palavras-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 base de dados com palavras na língua inglesa, o presente trabalho considera apenas consultas e banco de dados com conteúdo em Inglês. Caso as palavras que compõem a consulta ou os metadados e o contéudo do banco de dados estejam em outra língua, como o Português, a consulta poderá ser realizada, porém não será agregada semântica à ela. Ou seja, essa fase de 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ão adicionados à consulta original os sinônimos retornados pelo WordNet, porém na fase de mapeamento provavelmente eles serão desconsiderados. Um exemplo disso é a palavra item, que possui a mesma grafia em inglês.

35 3.2 Arquitetura Processamento da consulta Até este momento foram identificados os possíveis usos de funções agregadas e 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 que possui apenas palavras-chave que possuem um significado real no banco de dados e um conjunto de sinônimos para o caso de não existir uma correspondência exata entre os termos do banco de dados e as palavras-chave da consulta. Dado um conjunto de banco de dados disponibilizados por meio do protocolo OAI-PMH usando a extração de metadados sugerida por Kowata [20], é necessário identificar quais bancos contêm informações úteis para a consulta com palavras-chave. Uma vez 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 selecionados como relevantes. Esse processo de criação das consultas SQL é feito pelo mapeamento das palavras-chave para os termos do banco subjacente. Uma vez executadas as consultas SQL, os resultados são retornados ao usuário ordenados por relevância. Todo esse processamento é realizado em 5 etapas: Identificação dos bancos de dados relevantes, Ranking dos bancos de dados relevantes, Mapeamento, Execução e Ranking dos resultados. A explicaçã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 de dados relacionais, proposto em [20], cada banco possui uma tabela TME que representa a extensão do catálogo do banco de dados e que contém informações a respeito do conteúdo do banco de dados. Essas informações são descritas por meio dos 23 elementos apresentados na Tabela 3.1. A identificação e seleção dos bancos de dados que possuem conteúdo relevante para a consulta com palavra-chave é feita com base na análise das informações contidas na 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 a respeito 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ção dos bancos de dados relevantes considera apenas os elementos que contêm ou sugerem informações a respeito do conteúdo do banco de dados. Os elementos considerados são: dc_title, dc_subject, dc_description e dc_identifier. Caso as informações de um desses quatro elementos contenha alguma palavra-chave da consulta, o banco de dados é considerado como relevante para a consulta.

36 3.2 Arquitetura 35 Tabela 3.2: Informações da Tabela de Metadados para Exposição(TME) do banco de dados COMPANY (inspirado em [20]) Elemento Informação serial 1 provider url admname@xyz.com oai_set dispquery sim dc_title COMPANY dc_creator Elmasri e Navathe dc_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, the location of the department and project, the employees dependents. dc_contributor XYZ dc_publisher ABC dc_date dc_type Database - MYSQL dc_format SGBDR dc_identifier bdcompany dc_source DEF dc_language Inglês dc_relation GHI dc_coverage JKL dc_rights MNO dc_login ******** dc_passwordbd ******** Ranking dos bancos de dados relevantes Dado o conjunto de bancos de dados relevantes para a consulta, estes são ordenados de modo que o banco de dados mais relevante para a consulta fique no topo da lista. A relevância de um banco de dados em relação à uma consulta é computada com 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 pontuação é computada da seguinte maneira: a palavra-chave department aparece 1 vez no elemento dc_subject e 3 vezes no elemento dc_description, enquanto que a palavra-chave employees aparece 1 vez no elemento dc_description, totalizando assim 5, o número de vezes que ambas palavras-chave aparecem nos elementos descritores de conteúdo.

37 3.2 Arquitetura 36 Mapeamento A consulta com palavra-chave é executada em cada um dos bancos de dados considerados como relevante e a ordem de execução em cada banco de dados é baseada na ordenação gerada na etapa anterior. Responder uma consulta com palavras-chave em banco de dados relacionais requer o entendimento do significado de cada palavra-chave e a construção de uma consulta SQL que ofereça uma interpretação da consulta em termos do banco de dados relacional. Ou seja, é necessário mapear as palavras-chave em termos das estruturas do banco de dados, tais como relações, atributos e valores de atributos. Nesse sentido, diversas técnicas e ferramentas foram propostas a fim de solucionar o problema de consulta com palavras-chave em banco de dados relacionais. Geralmente, essas técnicas consideram o banco de dados como uma rede de tuplas interconectadas e detectam as tuplas que contêm as palavras-chave da consulta. Componentes conectados são gerados, com base em como essas tuplas são associadas, e retornam estas tuplas conectadas como uma resposta à consulta. Para tanto, estruturas especializadas que indexam o conteúdo da base de dados são utilizadas. Ao usar esses índices, as tuplas de interesse podem ser diretamente identificadas. Contudo, para construir tais índices é necessário um acesso prévio ao dados do banco de dados. Tal fato torna-se uma limitação caso não seja permitido o acesso aos dados. Exemplos de tais situações incluem banco de dados restritos às organizações, que por algum motivo não querem (ou não podem) dispor de seus dados e normalmente expõe apenas as informações do esquema ou parte delas. Levando isto em consideração, é necessário o uso de uma ferramenta ou técnica de consulta com palavra-chave que não necessite do acesso ao dados do banco para construir expressões SQL que correspondam à consulta. Baseado nesse fato, a ferramenta escolhida para realizar a etapa de mapeamento foi a ferramenta conhecida como Keymantic [3]. Tal sistema responde à consulta com palavras-chave sobre banco de dados relacionais baseando-se apenas no conhecimento intensional, ou seja, informações extraídas (ou fornecidas) pelas fontes de dados, tais como, esquemas e tipos de dados e conhecimento adicional 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 de considerar as várias interpretações que uma consulta pode assumir, condizendo com o objetivo deste trabalho. Apesar de não requerer acesso aos dados, a ferramenta necessita do esquema para realizar o mapeamento das palavras-chave e necessita do acesso ao banco de dados apenas 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 do elemento dispquery da tabela TME. Considere que as etapas de pré-processamento e

38 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 disponibilizado pelo administrador do banco de dados, expondo os metadados do mesmo por meio da 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 banco de dados não está disponível para consulta. Não será possível realizar o processo de mapeamento das palavras-chave da consulta e consequentemente não será possível realizar as demais etapas, impedindo assim que os resultados sejam gerados e retornados para o usuário. Uma solução para esse cenário, seria repassar a consulta com palavra-chave para o administrador do banco de dados. Este então, deveria possuir uma implementação própria da técnica de consulta com palavras-chave em bases de dados relacionais e então executar a consulta que lhe foi entregue. Uma vez realizada a consulta, o administrador do 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 é fornecido por 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 os resultados são então retornados ao usuário. Para o propósito deste trabalho, o último cenário será considerado. O processo de mapeamento e o funcionamento da ferramenta Keymantic serão descritos em maiores detalhes no Capítulo 4. Execução O processo de mapeamento realiza a correspondência entre as palavras-chave da consulta e os termos do banco de dados subjacente. Com base nessa correspondência, a ferramenta Keymantic constroi uma consulta SQL correspondente. Porém, uma consulta com palavras-chave pode ter mais de uma interpretação, e cada interpretação pode corresponder a um mapeamento diferente das palavras-chave em termos das estruturas do banco de dados. Dessa forma, uma consulta com palavras-chave pode ser convertida em várias consultas SQL. Logo, para cada banco de dados relevante são construídas várias consultas SQL. Cada consulta SQL é então executada no banco de dados correspondente, e os resultados destas consultas representam os resultados esperados pela consulta com palavras-chave. Porém, estes resultados não são igualmente significativos, alguns representam melhor a semântica pretendida pela consulta do usuário. Nesse sentido, é interessante apresentar ao usuário, primeiramente, os resultados mais significativos. O ranking destes resultados é executado na próxima etapa que será descrita a seguir.

39 3.3 Considerações Finais 38 Ranking dos resultados Para gerar um ranking dos resultados é necessário ter uma medida quantitativa que indica quão significativo um resultado é para a consulta. Considerando que a ferramenta Keymantic computa uma pontuação para cada consulta SQL gerada e, consequentemente, o resultado obtido pela execução dessa consulta possui a mesma pontuação, os resultados retornados ao usuário podem atender a seguinte ordenação: os resultados do banco de dados mais relevante para consulta aparecem primeiro e, em seguida, os resultados dos demais, na ordem definida na etapa de ranqueamento dos bancos de dados relevantes; os resultados de cada banco de dados são então ordenados primariamente pela pontuação de sua consulta SQL correspondente, e secundariamente pelo tamanho do caminho de junção. O tamanho do caminho de junção é baseado no número de junções necessárias na consulta SQL. Por exemplo, considere que dois resultados de um dos bancos de dados relevantes possuam pontuação 283, e que as consultas SQL que os originou possuam 4 junções e 3 junções, respectivamente. Ambos possuem a mesma pontuação, porém um possui menor caminho de junção. Então, o resultado com o tamanho de caminho de junção 3 irá aparecer antes do resultado que possui tamanho de caminho de junção Considerações Finais Como visto na Figura 3.1 e detalhado neste capítulo, o método proposto engloba outras funcionalidades além da simples aplicação de uma técnica de consulta com 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 dos resultados são cruciais para a identificação de fontes com conteúdo de interesse para a consulta e para permitir uma melhor interpretação da consulta de modo a encontrar os resultados mais proeminentes. Puramente, a técnica de consulta com palavras-chave aplicada engloba apenas as etapas de Mapeamento e Execução. Essas duas últimas etapas nada mais são que a representação do uso da ferramenta Keymantic. Assim, como foram agregadas funcionalidades externas ao contexto da ferramenta Keymantic, também foram realizadas algumas modificações internas à ferramenta, mais precisamente, no processo de Mapeamento, a fim de aprimorar a qualidade dos resultados retornados. O funcionamento da ferramenta, ou seja, a técnica utilizada pela Keymantic, bem como as melhorias propostas à esta técnica, serão apresentados nos próximos capítulos.

40 Análise Semântica da Consulta CAPÍTULO 4 Apesar de ser uma alternativa atraente para consultas SQL tradicionais, eliminando a necessidade de um conhecimento prévio por parte dos usuários, a consulta com palavras-chave em banco de dados relacionais mostra-se como um problema complexo e desafiador. Neste sentido, diversos esforços têm sido feitos para propor técnicas que solucionem este problema, entre elas, a Keymantic. Nas próximas seções será descrito de forma mais detalhada o problema de consulta com palavra-chave em banco de dados relacionais, modelado de acordo com a solução proposta pela ferramenta Keymantic (Seção 4.1); e as particularidades da ferramenta 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. Uma tabela relacional é denotada como R(A 1, A 2,..., A n ), onde R é o nome da tabela e A 1, A 2,..., A n são os atributos da tabela. O vocabulário do banco de dados D, denotado como V D, é o conjunto de todos os nomes de suas relações, atributos e o respectivos domínios destes atributos. Um termo de banco de dados é um membro do seu vocabulário. Uma consulta com palavra-chave q é uma lista ordenada de palavras-chave, onde cada uma delas é uma especificação do elemento de interesse. A especificação pode ter sido modelada no banco de dados como uma tabela relacional, um atributo, ou um valor de um atributo. Uma configuração é uma função que mapeia cada palavra-chave com respeito 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. C ki denota a função de mapeamento aplicada a palavra-chave k i [4]. Algumas suposições são consideradas pela Keymantic nesse processo de mapeamento das palavras-chave. A primeira suposição é que cada palavra-chave não pode ter

41 4.1 Definição do problema 40 mais de um significado na mesma configuração, ou seja, cada palavra-chave só pode ser mapeada para um único termo do banco de dados. Além disso, também é considerado que duas palavras-chave não podem ser mapeadas para o mesmo termo do banco de dados. E por fim, também é feita a suposição de que toda palavra-chave desempenha um papel na consulta, 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, responder uma consulta com palavras-chave sobre um banco de dados D significa encontrar um conjunto de consultas SQL. Tais consultas SQL são referidas como interpretações da consulta com palavras-chave, uma vez que oferecem um possível significado da consulta em 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 uma dada consulta com palavra-chave q. Assim, a notação I(q, C, D) é usada para se referir ao conjunto das interpretações possíveis para uma configuração, enquanto que a notação I(q, D) se refere à união de todos esses conjuntos para todas as possíveis configurações da consulta 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 exec D (q ) q I(q,D)}, onde exec D (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 um nome de uma relação, nome de um atributo ou para o domínio de um atributo, existem 2 D i=1 R i + D diferentes configurações, com R i denotando a aridade da relação R i e D o número de tabelas no banco de dados. Baseado nisso, e considerando que duas palavras-chave não podem ser mapeadas para o mesmo termo do banco, para N palavraschave existem V D! ( V D N)! configurações possíveis [4]. Claramente, nem todas interpretações geradas por essas configurações são igualmente significativas. Algumas interpretações representam melhor a semântica pretendida da 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 diferentes tipos de metainformação e a interdependência entre os mapeamentos das palavraschave para os termos do banco de dados, afim de identificar de forma eficaz e eficiente estas interpretações mais significativas.

42 4.2 Análise Semântica segundo a Keymantic Análise Semântica segundo a Keymantic A ferramenta Keymantic propõe uma técnica para consulta com palavras-chave sobre banco de dados relacionais, onde as consultas são convertidas em uma série de consultas SQL, também referenciadas como interpretações, que capturam a possível semântica da consulta com palavras-chave. As consultas SQL geradas podem ser submetidas ao banco 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 dados do banco de dados. De fato, a ferramenta utiliza apenas o esquema e outras fontes externas auxiliares para agregar semântica ao processo de mapeamento das palavras-chave em termos do banco de dados. Além disso, a ferramenta explora as posições relativas das palavras-chave na consulta juntamente com essas fontes externas a fim de fazer uma melhor suposição da semântica que a consulta com palavra-chave representa. Para selecionar as melhores configurações, e por consequência, gerar as interpretações mais proeminentes, a ferramenta Keymantic considera dois tipos de pesos: o intrínseco e o contextual. Dado um mapeamento das palavras-chave para os termos do banco de dados, seu peso intrínseco mede a probabilidade que a semântica do termo do banco é aquela pretendida pela palavra-chave, sem considerar os mapeamentos das outras palavras-chave na consulta. O cálculo de um peso intrínseco é baseado em fatores sintáticos, semânticos e estruturais, como nomes de relações e atributos, ou outras fontes externas auxiliares, como vocabulários, ontologias, domínios, etc. Por outro lado, um peso contextual é usado para medir a mesma probabilidade, mas considerando os mapeamentos das palavras-chave restantes. Isto é motivado pelo fato de que um mapeamento de uma palavra-chave para um termo do banco de dados pode aumentar ou diminuir a 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 em que palavras-chave relacionadas estão perto umas das outras. Por exemplo, uma vez submetida a consulta Department Name Research ao banco da Figura 3.2(a), o fato da palavra-chave Name estar próxima à palavra-chave Department torna mais provável que a 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 para os atributos Fname, Lname, Pname e Dependent_name das tabelas Employee, Project e Dependent, respectivamente. A noção de peso oferece uma medida quantitativa da relação entre uma palavrachave 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 representa uma pontuação que serve como uma medida quantitativa da probabilidade da confi-

43 4.2 Análise Semântica segundo a Keymantic 42 guração conduzir a uma interpretação que descreve com precisão a semântica pretendida da consulta com palavras-chave. Uma abordagem simples para selecionar as melhores configurações é calcular a pontuação de todas as configurações possíveis e, então, selecionar aquelas que têm as maiores 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ção exaustiva de todos os mapeamentos possíveis. Porém, ele fornece apenas o melhor mapeamento, ao invés dos melhores mapeamentos. Para lidar com esta limitação, a Keymantic propôs um novo algoritmo que extende o algoritmo Hungarian para calcular os melhores mapeamentos. Este novo algoritmo será descrito na Subseção Uma ilustração visual das etapas individuais realizadas pela Keymantic para traduzir a consulta com palavras-chave em consultas SQL está representada na Figura 4.1. Figura 4.1: Mapeamento das palavras-chave (retirado de [3]) Uma estrutura de dados especial, chamada matriz de pesos, é utilizada nestas etapas. A matriz de pesos é uma matriz bidimensional com uma linha para cada palavrachave na consulta, e uma coluna para cada termo do banco de dados. O valor de uma célula [i, j] representa o peso associado ao mapeamento entre a palavra-chave i e o termo

44 4.2 Análise Semântica segundo a Keymantic 43 Tabela 4.1: Matriz de peso com a submatrizes SW (claro) e VW (escuro) (retirado de [4]) R 1... R n A R 1... A R1 n 1... A Rn n n A R A R1 n 1... A Rn n n keyword 1 keyword 2... keyword k de banco de dados j. A Tabela 4.1 exibe uma ilustração abstrata de uma matriz de peso [4]. As colunas R i e A R i j correspondem à relação R i e o atributo A j de R i, respectivamente, enquanto que uma coluna A R i j representa os valores que o atributo A j da relação R i pode assumir, isto é, seu domínio. Duas partes (isto é, submatrizes) podem ser distinguidas na matriz de peso. Uma corresponde aos termos do banco de dados relacionados aos elementos do esquema, isto é, relações e atributos, e a outra corresponde a valores de atributo, isto é, elementos pertencentes aos domínios dos atributos. Os termos do banco de 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 pesos na submatriz mais clara são referidos como pesos de esquema (SW) e os da submatriz mais escura como pesos de valor (VW). seguintes. Os detalhes das etapas individuais da Figura 4.1 são descritas nas subseções Cálculo dos pesos intrínsecos (Passo 1) Para calcular os pesos intrínsecos, é preciso calcular a relevância entre cada palavra-chave da consulta e cada termo banco de dados. O cálculo é realizado através da exploração e da combinação de uma série de técnicas de similaridade baseadas nos conhecimentos estruturais e léxicos extraídos a partir da base de dados, e no conhecimento externo, 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 esquema e 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, como chaves 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.

45 4.2 Análise Semântica segundo a Keymantic 44 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 o melhor resultado. Uma dessas técnicas é a similaridade entre strings onde se emprega uma sé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 de esquema do banco de dados com base em sua relação semântica. Para tanto, utiliza ontologias 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 da matriz SW. O conjunto representa os métodos de similaridade utilizados pela ferramenta Keymantic. Cada método tem como entrada duas strings e retorna a similaridade entre elas em um intervalo de 0 a 1. O maior valor retornado é então multiplicado por 100 e escolhido como peso intrínseco. Se a similaridade entre uma palavra-chave e um termo de esquema é abaixo de um determinado limiar (definido pela aplicação), então a similaridade é definida como 0. Ao final do procedimento algumas linhas na matriz SW poderão ter somente zeros. Estas linhas representam palavras-chave que não são semelhantes o suficiente com nenhum termo de esquema, então elas serão consideradas mais tarde como candidatas no mapeamento para os termos de valor. O Algoritmo 4.1 está exatamente como descrito em [4], contudo pode-se perceber que alguns erros foram cometidos. Provavelmente nas linhas 12 e 16, ssim deveria ser substituí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 department research 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 explora a informação a respeito do domínio do atributo e decide se uma palavra-chave pertence

46 4.2 Análise Semântica segundo a Keymantic 45 ou não ao domínio em questão. Além disso, utiliza da noção de semantic relatedness para computar 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 Query T: 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 do 5 foreach e T do 6 sim 0; 7 foreach m do 8 if m(w,e) > sim then 9 sim m(w,e) end end 12 if ssim threshold then 13 sim 0; end end 16 SW[w,c] = ssim 100 end O conceito de semantic relatedness SR(x, y) de dois termos x e y é definido como: 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 documentos contendo ambos x e y. Esses números são retornados por motores de buscas. O número N representa 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.

47 4.2 Análise Semântica segundo a Keymantic 46 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 department research Seleção dos Melhores Mapeamentos para os termos de esquema (Passo 2) Os pesos intrínsecos fornecem uma primeira indicação das similaridades entre as palavras-chave e os termos do banco de dados. Para gerar os mapeamentos mais proeminentes, a Keymantic também considera as interdependências entre os mapeamentos das diferentes palavras-chave. Primeiramente são considerados os melhores mapeamentos de palavras-chave para termos de esquema. Para tanto é utilizada a Submatriz SW e, baseado em seus pesos intrínsecos, é gerada uma série de mapeamentos M1 S, MS 2,..., MS n de palavras-chave para termos de esquema. Os mapeamentos são aqueles que atingem as maiores pontuações, ou seja, a soma dos pesos dos mapeamentos individuais das palavras-chave. Os mapeamentos gerados podem ser totais ou parciais. Os mapeamentos totais sã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-chave são mapeadas para algum termo de esquema. As palavras-chave que permanecem não mapeadas irão desempenhar o papel de um valor real e serão consideradas em uma etapa posterior no mapeamento para termos de valor. A seleção das palavras-chave que irão continuar sem mapeamento é baseada na matriz de peso e em um limiar de corte. Aquelas com similaridade abaixo do limite permanecerão não mapeadas. Para cada mapeamento Mi S, 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 palavraschave referentes aos mesmos conceitos ou conceitos relacionados são adjacentes. A geração dos mapeamentos e o ajuste dos pesos em SW são realizados pela extensão do algoritmo Hungarian que será descrito na Subseção Durante a execução do algoritmo, é gerado uma série de mapeamentos para termos de esquema, e para cada mapeamento é calculado a pontuação correspondente. O algoritmo é executado até o momento em que nenhum dos mapeamentos gerados possua pontuação acima de um limiar 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. Quanto maior o valor, menos interpretações serão geradas, mas com maior confiança. Quanto menor o valor do limiar, mais interpretações são geradas, porém a medida que são geradas mais interpretações, estas são menos significativas. Isto porquê com a extensão do

48 4.2 Análise Semântica segundo a Keymantic 47 algoritmo Hungarian, no decorrer da execução as pontuações dos mapeamentos gerados vão decrescendo. Processo de Seleção dos Melhores Mapeamentos A ferramenta Keymantic adaptou o algoritmo Hungarian de modo a não parar após a geração do melhor mapeamento, mas continuar para gerar o segundo melhor, o terceiro, etc. Além disso, a ferramenta modificou alguns passos internos do algoritmo de modo que a matriz de peso é atualizada dinamicamente para representar a interdependência entre as palavras-chave. A execução do algoritmo consiste de uma série de passos iterativos que geram um mapeamento com pontuação máxima. Uma vez gerado o melhor mapeamento, a matriz de peso é modificada de maneira a excluir o mapeamento já gerado e o processo continua para 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 como má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 banco referente à coluna do peso caracterizado como máximo na linha correspondente. Por exemplo, considere a consulta employees dependent relationship. A Submatriz SW correspondente à consulta está ilustrada na Tabela 4.4, onde os pesos marcados com * representam os pesos caracterizados como máximos na linha. A figura apresenta os pesos intrínsecos apenas para os termos do banco de dados pertencentes às tabelas Employee e Dependent e os nomes das tabelas e dos atributos foram abreviados. Uma vez que cada peso caracterizado como máximo está em uma coluna diferente dos demais, então tem-se um mapeamento onde a palavra-chave employees é mapeada para a relação Employee, a palavra-chave dependent é mapeada para a relação Dependent e a palavra-chave relationship é mapeada para o atributo relationship da relação Dependent. Tabela 4.4: Mapeamento para a consulta employees dependent relationship 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* dependent 0 100* relationship * 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

49 4.2 Análise Semântica segundo a Keymantic 48 máximos. Dessa forma, algumas linhas deixam de ter algum peso caracterizado como máximo. 4. O valor dos pesos das linhas que estão sem peso caracterizado como máximo, são então atualizados de acordo com as regras de contextualização que serão descritas na Subseção Essa última ação leva em consideração a interdependência entre os mapeamentos das palavras-chave, ou seja, o mapeamento de uma palavra-chave pode aumentar ou diminuir a probabilidade de que uma outra palavra-chave ainda não mapeada corresponda à um determinado termo do banco. 5. Para cada linha sem peso caracterizado como máximo, o peso com maior valor, que pertence à uma coluna correspondente à um termo do banco de dados diferente daquele que já havia sido caracterizado, é selecionado e caracterizado como máximo. Se essa ação resultar em uma matriz que tem cada peso caractacterizado como máximo em diferentes colunas, então um mapeamento é gerado como descrito anteriormente, caso contrário, o processo de descaracterização descrito anteriormente é repetido até que um mapeamento seja gerado. 6. O mapeamento gerado é incluído no conjunto de mapeamentos que será retornado pelo algoritmo. Em seguida, o algoritmo precisa ser repetido para gerar mapeamentos 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 sido considerado em execuções anteriores do algoritmo. Isto é feito negativando o valor de um dos pesos caracterizado como máximo, forçando o algoritmo a nunca mais selecioná-lo novamente. Todo este processo é repetido até que a pontuação dos mapeamentos que o algoritmo gera esteja abaixo de um limiar específico. Por exemplo, a partir do mapeamento da Tabela 4.4 é possível gerar 3 novas matrizes de entrada para o algoritmo. Estas matrizes estão apresentadas nas tabelas 4.5, 4.6 e 4.7. A matriz da Tabela 4.5 foi gerada a partir da atribuição do valor negativo para o peso caracterizado como máximo da primeira linha da Tabela 4.4. A matriz da Tabela 4.6 foi gerada negativando o peso caracterizado como máximo da segunda linha, e a matriz em 4.7 negativando o peso da terceira linha. O Algoritmo 4.2 descreve todo o processo de geração do conjunto de mapeamentos mais proeminentes de um conjunto de palavras-chave para os termos do banco

50 4.2 Análise Semântica segundo a Keymantic 49 Tabela 4.5: Primeira matriz gerada a partir do mapeamento da Tabela 4.4 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 dependent relationship Tabela 4.6: Segunda matriz gerada a partir do mapeamento da Tabela 4.4 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 dependent relationship Tabela 4.7: Terceira matriz gerada a partir do mapeamento da Tabela 4.4 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 dependent relationship de dados, dada uma matriz de pesos. A expressão HUNGARIAN Ext se refere à versão estendida proposta pela Keymantic. Algoritmo 4.2: Keyword to db term mapping selection (retirado de [4]) Input : I(i i j ) where I SW or I VW Output: M I = {M1 I,...,MI z}: Mappings generated by I Algoritmo: Mapping(I,W MAX ) 2 tempm = i pt HUNGARIAN Ext (I) 3 W i pt 4 M I tempm 5 if W > c * W MAX then 6 W MAX W end 8 while W > c * W MAX do 9 foreach i pt tempm do 10 i pt I Mapping(I, W MAX ) end end Contextualização de VW e Seleção dos Melhores Mapeamentos para os termos de valor (Passo 3) Para cada mapeamento parcial Mi S de palavras-chave para termos de esquema gerados na etapa anterior, os mapeamentos das palavras-chave ainda não mapeadas serão decididos neste estágio. Este mapeamento é feito em duas fases.

51 4.2 Análise Semântica segundo a Keymantic 50 Na primeira fase, os pesos intrínsecos da Submatriz VW que foram gerados no Passo 1, são atualizados para refletir a interdependência entre as palavras-chave ainda não mapeadas e as palavras-chave já mapeadas para termos de esquema no mapeamento M S i. Esse processo é chamado de contextualização. Esta contextualização é baseada no fato que usuários formam consultas em que as palavras-chave que especificam informações de metadados sobre um conceito são adjacentes ou pelo menos vizinhas. Assim, quando uma palavra-chave é mapeada para um termo de esquema, torna-se mais provável que uma palavra-chave adjacente deva ser mapeada para um valor no domínio deste termo de esquema. Por exemplo, considere a consulta name Research e que durante a primeira etapa do processo de mapeamento (Figura 4.1), os pesos intrínsecos referente a linha da palavra-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ínsecos para os termos de valor, todos os atributos que possuem como domínio uma sequência de caracteres, terão o peso 1 para a palavra-chave Research, possuindo, assim, a mesma probabilidade da palavra-chave ser mapeada à eles. Se durante o Passo 2 a palavra-chave name for mapeada para o atributo Dname da relação Department, a probabilidade que a palavra-chave Research é um nome de um departamento aumenta, então o peso entre a palavra-chave e o termo de valor representando o domínio do atributo Dname deve ser aumentado. Essa atualização do peso é feita pelo processo de contextualização que será melhor detalhado na Subseção Na segunda fase, dada uma Submatriz VW atualizada, os mapeamentos para termos de valor mais proeminentes das palavras-chave restantes ainda não mapeadas são gerados. Os mapeamentos são gerados usando novamente a técnica adaptada do algoritmo Hungarian, descrita anteriormente na Subseção O resultado é uma série de mapeamentos parciais M V ik, com k = 1..m i, onde i identifica o mapeamento M S i que foi considerado para atualizar a submatriz VW i. Em resumo, dado um mapeamento parcial Mi S, as palavras-chave ainda não mapeadas para termos de esquema serão mapeadas para termos de valor. Isso é feito contextualizando a Submatriz VW com base no mapeamento Mi S. Esta Submatriz VW contextualizada é então utilizada como entrada do algoritmo de seleção dos melhores mapeamentos (Algoritmo 4.2). A saída do algoritmo é uma série de mapeamentos parcias Mik V, assim referenciados porque as palavras-chave já mapeadas para termos de esquema no mapeamento Mi S não são consideradas, ou seja, o mapeamento Mik V irá conter apenas os mapeamentos das palavras-chave que não haviam sido mapeadas em Mi S. O mapeamento total das palavras-chave da consulta é formado pelo par M S i, MV ik, formando uma configuração. O processo de geração das configurações será descrito na Subseção

52 4.2 Análise Semântica segundo a Keymantic 51 Regras e Processo de Contextualização O processo de contextualização, previamente explicado, explora as interdependências entre os mapeamentos de diferentes palavras-chave. Na Figura 4.1 o processo de contextualização está apresentado apenas no Passo 3. Contudo, como mencionado na Subseção 4.2.2, o processo de seleção dos melhores mapeamentos faz uso de regras de contextualização quando mais de uma palavra-chave é mapeada para um mesmo termo do banco. Desta forma, apesar de não estar explícito na figura, será considerado que o processo de contextualização também é realizado durante o Passo 2. Para tal, é necessário definir dois conceitos, free trailing keywords e free preceding keywords, para o entendimento do processo de contextualização. Seja K a lista de palavras-chave da consulta, Mi S um mapeamento parcial das palavras-chave em K para termos de esquema, e K S o subconjunto de K contendo as palavras-chave mapeadas para termos de esquema em Mi S. Definição 4.3 Free trailing keywords de uma palavra-chave k, denotado como T(k), é o conjunto máximo k 1, k 2,..., k m, de palavras-chave consecutivas em K que estão na consulta entre duas palavras-chave k s e k e, onde k s = k e Mi S é definido para k s e k e, e indefinido para cada k i com i = 1..m [4]. Ou seja, k s e k e são palavras-chave mapeadas para termos de esquema em Mi S, enquanto que cada k i permanece não mapeada. Definição 4.4 Free preceding keywords de uma palavra-chave k, denotado como P(k), é o conjunto máximo k 1, k 2,..., k m, de palavras-chave consecutivas em K que estão na consulta entre duas palavras-chave k s e k e, onde k e = k e Mi S é definido para k s e k e, e indefinido para cada k i 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 algumas palavras-chave estão mapeadas para termos de esquema e outras ainda não. Neste momento, os pesos das linhas destas palavras-chave ainda não mapeadas são atualizadas de acordo 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-chave para os termos de esquema e o conjunto de palavras-chave. No Passo 3, o processo de contextualização considera como entrada a Submatriz VW, o mapeamento parcial das palavras-chave para os termos de esquema, o conjunto de palavras-chave e a Submatriz SW. A diferença entre o processo de contextualização do Passo 2 e do Passo 3, é que no Passo 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 para termos de valor.

53 4.2 Análise Semântica segundo a Keymantic 52 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 é feito para guarantir que nenhuma destas palavras-chave sejam mapeadas para termos de valor durante o processo de contextualização. As três fases, explicadas a seguir, são as mesmas tanto para processo de contextualização realizado no Passo 2 como o realizado no Passo 3. Considere apenas que para o processo de contextualização do Passo 2 os pesos atualizados são referentes aos domínios dos atributos, enquanto que para o processo do Passo 3 os pesos atualizados são referentes aos atributos. Na primeira fase do processo de contextualização da Submatriz VW, para cada palavra-chave k mapeada para uma relação R em Mi S, acrescenta-se um valor constante aos pesos de T(k) e P(k), que são pertinentes aos termos representando os atributos/domínios dos atributos da relação R, são acrescidos de um valor constante. O valor acrescido visa a aumentar o peso do mapeamento, pois as consultas normalmente contêm palavras-chave que 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 pode corresponder a uma relação e a palavra-chave Alicia pode corresponder a um valor de um dos atributos desta relação. Durante a segunda fase, para cada palavra-chave k mapeada para um atributo A em Mi S, é 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 é que palavras-chave consecutivas podem representar além de especificações de valor, valores que 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 empregado que 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 é um valor relacionado. Na terceira e última fase, se uma palavra-chave k é mapeada para um atributo A, os pesos de T(k) e P(k), para os termos representando os atributos/domínios de atributos relacionados à A por meio de um caminho de junção, são acrescidos de um valor constante. Isso porque, usuários normalmente utilizam palavras-chave referindo-se a conceitos que são semanticamente relacionados, mesmo que esses conceitos estejam modelados no banco de dados em tabelas diferentes. Considerando a consulta employee name Jennifer Houston citada acima, outra possível interpretação é saber a respeito de um empregado que se chama Jennifer e trabalha em Houston. Neste caso, a palavra-chave Houston pode representar a localização do projeto ou a localização do departamento no qual o empregado trabalha. Nos dois casos, essa informação está armazenada em uma

54 4.2 Análise Semântica segundo a Keymantic 53 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 processo de contextualização do Passo 2, são necessárias as seguintes modificações: a Submatriz VW não é considerada como entrada do algoritmo, a saída do algoritmo é a Submatriz SW atualizada; e a atualização dos pesos é referente aos pesos dos atributos, ou seja, o conteú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 terms Q: Keyword Query SW: Schema intriscic weight sub-matrix VW: Value intrinsic weight sub-matrix Output: Updated VW sub-matrix Algoritmo: ComputeCVW(SW,VW,M) 2 foreach k Q do 3 t x : (k,x) M 4 if t = null then 5 continue end 7 if t is a relation R then 8 foreach attribute A of R do 9 foreach k T (k) P(k) do 10 VW[k,R.A] VW[k,R.A] + w end end 13 else if t is an attribute A of a relation R then 14 foreach attribute A of R with A A do 15 foreach k T (k) P(k) do 16 VW[k,R.A] VW[k,R.A] + w end end 19 foreach attribute A of R s.t. join path from A to A do 20 foreach k T(k) P(k) do 21 VW[k, R.A] VW[k, R.A] + w end end end end

55 4.2 Análise Semântica segundo a Keymantic Geração das Configurações (Passo 4) Até este momento, durante o Passo 2 foi gerado uma série de mapeamentos parciais Mi S, que representam os mapeamentos para termos de esquema, e durante o Passo 3 foi gerado uma série de mapeamentos parciais Mik V, que representam os mapeamentos para termos de valor. Cada par de mapeamento <Mik V, MS i > é um mapeamento total das palavras-chave para os termos do banco de dados, formando uma configuração C ik. A pontuação da configuração é a soma das pontuações dos dois mapeamentos, ou de forma similar, a soma dos pesos na matriz de pesos dos elementos [i,j], onde i é uma palavra-chave e j é o termo do banco para o qual a palavra foi mapeada Geração das Interpretações (Passo 5) Uma vez computadas as melhores configurações, as interpretações da consulta com palavra-chave, isto é, as consultas SQL, podem ser geradas. A pontuação de cada consulta SQL é a pontuação da respectiva configuração. Uma configuração é simplesmente um mapeamento das palavras-chave para os termos do banco de dados. A presença de diferentes caminhos de junções entre estes termos 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 banco de dados. Uma aresta conecta dois termos se existe uma relação chave-primária-chave estrangeira, ou se eles são relacionados por meio de um relacionamento tabela-atributovalor. Para este último caso, existe uma aresta entre um nó que representa uma tabela e um 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 outra aresta entre o nó que representa este valor e o nó que representa a tabela que contém este valor. Dada uma configuração, todos os termos que fazem parte desta configuração são marcados no grafo. Então é feita uma busca em largura para encontrar os caminhos que conectam 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 referencial modeladas 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 outro caminho de junção.

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

57 Contribuições à Analise Semântica CAPÍTULO 5 A Keymantic é uma ferramenta que se propõe realizar consultas com palavraschave em banco de dados relacionais. Uma das novidades desta ferramenta é que ela não é baseada em um acesso prévio ao dados do banco. A ferramenta faz uso apenas do esquema do banco para realizar o processo de conversão da consulta com palavras-chave em consultas SQL. Para agregar semântica a esse processo de conversão da consulta com palavraschave em consultas SQL, a ferramenta faz uso de fontes externas auxiliares como ontologias e dicionários e explora as posições relativas das palavras-chave de modo a fazer uma melhor suposição do significado pretendido pela consulta com palavrachave. Esta última consideração é baseada no fato que podem existir interdependências entre 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 conceitos pretendidos que o usuário tinha em mente ao construir a consulta. Além disso, nem todas 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 banco COMPANY, as palavras-chave dependent e relationship representam metadados (relação e atributo, respectivamente) que especificam o valor son. 5.1 Limitações da Keymantic Como mencionado anteriormente, a Keymantic faz algumas considerações durante o processo de mapeamento. Essas considerações trazem consigo algumas limitações. Uma das limitações está atrelada à suposição que toda palavra-chave desempenha um 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ão consegue 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

58 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á-la como a necessidade do uso da função agregada max. Outra limitação é imposta com base no fato da ferramenta considerar o processo de mapeamento como uma função injetora. Em uma função injetora não existe elemento da imagem que possui correspondência com mais de um elemento do domínio, onde o domínio seria o conjunto de palavras-chave e a imagem seria os termos do banco de dados. Em outras palavras, duas palavras-chave não podem ser mapeadas para o mesmo termo do banco de dados. Porém, como mencionado no Capítulo 3, existe a possibilidade de um valor ser composto por mais de uma palavra-chave. Nesse sentido, é necessário mapear 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 valores compostos. 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 artigo que descreve a ferramenta sugere que uma ordenação com base na pontuação de cada interpretação e no tamanho do caminho de junção poderia ser feita, porém por não ser foco do 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ção e valores compostos, e permitir uma ordenação dos resultados, o método proposto neste trabalho implementou as funcionalidades que se referem aos módulos de Verificação de Função Agregada/Ordenação/Valores Compostos e Ranking dos resultados ilustrados na Figura 3.1, os quais são externos à ferramenta Keymantic. Em adição, algumas modificaçõ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 mapeamento 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 palavraschave 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 esquema do banco de dados com base em sua relação semântica, fazendo uso de ontologias e dicioná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 um intervalo de 0 à 1. O maior valor retornado é então multiplicado por 100 e escolhido como

59 5.2 Modificações à abordagem da Keymantic 58 Figura 5.1: Processo de Mapeamento com as etapas modificadas em 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écnica de similaridade entre strings. Para esta técnica são empregadas três métricas de similaridades: Jaccard, Levenshtein e Cosseno. Cada métrica tem como entrada duas strings e retorna a similaridade entre elas em um intervalo de 0 à 1. O peso intrínseco referente a uma palavra-chave e um termo do banco de dados é calculado com base na média das similaridades retornadas por cada métrica. Caso a média das similaridades seja acima do limiar, 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 de dados. Para tanto é utilizado o dicionário WordNet para retornar os sinônimos de cada palavra-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 escolhida 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 modificações citadas.

60 5.2 Modificações à abordagem da Keymantic 59 Algoritmo 5.1: Modificação do Algoritmo 4.1 Input : Q: Keyword Query T: 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 do 4 foreach e T do 5 sim 0; 6 media 0; 7 foreach m do 8 media media + m(w,e); end 10 media media/3; 11 if media threshold then 12 S Synonyms(w); 13 max 0; 14 foreach s S do 15 media 0; 16 foreach m do 17 media media + m(s,e); end 19 media media/3; 20 if media > max then 21 max media; end end 24 if max threshold then 25 sim 0; 26 else 27 sim max; 28 SW[w,e] = sim 90; end 30 else 31 sim media; 32 SW[w,e] = sim 100; end end end

61 5.2 Modificações à abordagem da Keymantic 60 Uso de Sinônimos para palavra-chave Como os usuários normalmente esperam que as palavras-chave colocadas na consulta apareçam nos resultados, a razão de considerar o uso do dicionário de sinônimos em um segundo nível se deve à necessidade de dar maior relevância às palavras-chave da consulta. Ou seja, a existência da palavra-chave no banco de dados deve possuir um maior peso do que a existência do sinônimo dessa palavra. Por esse motivo, o valor da média das similaridades dos sinônimos é multiplicada por 90, enquanto que o valor da média das 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 valores de similaridades, e não a escolha do maior valor, se deve à discrepância entre os valores retornados pelas métricas de similaridade entre strings. Por exemplo, considere os seguintes pares de strings: dependent, project, address, relationship, dept_location, location. Os valores de similaridade retornados para o primeiro par pelas métricas Jaccard, Levenshtein e Cosseno são 0.33, 0.33 e 0.50, respectivamente. Para o segundo par os valores são 0.33, 0.16 e 0.53, e para o último par os valores são 0.63, 0.61, Como se pode perceber os valores de similaridades retornados pela métrica Cosseno são sempre maiores, uma vez que o cálculo dessa métrica é baseada apenas no número de caracteres em comum entre as duas strings. No caso do limiar ser definido como 0.5, e ser considerado como peso intrínseco o maior valor retornado pelas métricas, todos os pares iriam ter similaridade acima do limiar. Porém isso não reflete a realidade. A similaridade entre as strings dos pares dependent, project e address, relationship é baixa e ambos os pares deveriam então possuir peso intrínseco 0. Nesse sentido, é considerado a média das métricas, de maneira a normalizar as similaridades por elas retornadas. A média das similaridades para o primeiro par de strings é 0.38, para o segundo par 0.34 e para o último par 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 de Cálculo dos pesos intrínsecos dos termos de valor do banco de dados reflete ao fato do cálculo destes pesos ser tratado de forma binária. Assim, enquanto os pesos da Submatriz SW, que se referem aos termos de esquema, estão em um intervalo de 0 a 100, os pesos da Submatriz VW estão entre 0 e 1.

62 5.2 Modificações à abordagem da Keymantic 61 Considere agora para uma determinada consulta, um mapeamento onde todas as palavras-chave são mapeadas para termos de esquema e um mapeamento onde nem todas as palavras-chave são mapeadas para termos de esquema, sendo o restante delas mapeadas para termos de valor. No primeiro caso, como todas as palavras-chave são mapeadas para termos de esquema, apenas a Submatriz SW será utilizada para o cálculo da pontuação da configuração, enquanto que para o segundo caso, seriam considerados os pesos 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 para termos de valor é mínimo. Assim, configurações que representam o mapeamento de todas as palavras-chave para termos de esquema sempre possuirão pontuações maiores que 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 a respeito dos empregados que trabalham no departamento cujo nome é Research. Os pesos intrínsecos das submatrizes SW e VW referentes a estas consultas estão representados nas tabelas 4.2 e 4.3, respectivamente. Consideremos, para fins deste exemplo, que a similaridade entre a palavra-chave research e o atributo Address da relação Employee 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, considerando esse fato, é apresentado na Tabela 5.1. A pontuação da configuração é calculada com base na soma dos pesos intrínsecos referente ao mapeamento. Dessa forma, a pontuação dessa configuração é 240. Tabela 5.1: Mapeamento onde todas as palavras-chave são mapeadas 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* department 100* research * Como explicado na Subseção 4.2.2, após gerar o melhor mapeamento, os demais mapeamentos são gerados atribuindo um valor negativo a cada mapeamento individual de forma a não haver repetições. Assim, um possível mapeamento gerado a partir do mapeamento da Tabela 5.1, é apresentado nas tabelas 5.2 e 5.3. Como pode se ver na Tabela 5.2, o peso intrínseco entre a palavra-chave research e o termo Address possui agora 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 na linha da palavra-chave research, é necessário mapear tal palavra-chave para um termo de valor. Para tanto, é preciso contextualizar a Submatriz VW com base no mapeamento parcial da Submatriz SW. Este mapeamento parcial é representado pelos mapeamentos individuais das palavras-chave employees e deparment. Como estas palavras-chave foram

63 5.2 Modificações à abordagem da Keymantic 62 mapeadas para as relações Employee e Deparment, respectivamente, o processo de contextualização adiciona uma constante, neste caso 10, aos pesos referentes aos atributos pertencentes à 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 pelos mapeamentos parciais das submatrizes SW e VW. Assim, a pontuação dessa configuração é 200. Tabela 5.2: Mapeamento parcial das palavras-chave 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* department 100* research Tabela 5.3: Mapeamento parcial das palavras-chave para termos de valor D.Dna D.Dnu D.Mgr_ss D.Mgr_st E.Fn E.Mi E.Ln E.Ssn E.Bd E.Ad employees department research 11* Como se pode notar, a pontuação do primeiro mapeamento (Tabela 5.1) é maior que a pontuação deste último mapeamento gerado. Contrariamente ao que é posto pela noção de pontuação, o último mapeamento é mais relevante para a consulta do que o primeiro 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, é preciso que o valor dos pesos intrínsecos de termos de valor seja equiparado com o valor dos pesos de termos de esquema. Dessa forma, após o cálculo dos pesos íntrínsecos para os termos de valor, no método proposto por este trabalho os pesos que possuem valor 1 são multiplicados por uma constante pré-definida. O valor dessa constante foi definida como 65, uma vez que o limiar considerado no cálculo dos pesos intrínsecos para termos de esquema foi Este último valor, por sua vez, foi definido com base na quantidade esperada de mapeamentos a serem gerados. Quanto maior o limiar, menor é o número de mapeamentos 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, a relevância em relação à consulta, decresce.

64 5.2 Modificações à abordagem da Keymantic 63 Proximidade entre as palavras-chave Por fim, a última alteração interna à Keymantic foi realizada no processo de contextualização. Conforme mencionado na Subseção 4.2.3, apesar do processo de contextualização aparecer explícito apenas no Passo 3 (Figura 5.1), assume-se que esse processo também está sendo executado durante o Passo 2, uma vez que o processo de seleção dos melhores mapeamentos faz uso das regras de contextualização para atualizar os pesos durante a construção do mapeamento. Por este motivo, na Figura 5.1 o Passo 2 também está destacado, simbolizando a modificação referente ao processo de contextualização utilizada neste passo. Como mencionado no presente texto, a ferramenta Keymantic leva em consideração a interdependência entre as palavras-chave da consulta, onde o mapeamento de uma palavra-chave pode aumentar ou diminuir a probabilidade de que uma outra palavra-chave ainda não mapeada corresponda a um determinado termo do banco de dados. Como visto no 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 research 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 todos os domínios de atributos pertencentes às relações Employee e Department. No caso da Tabela 5.3, todos os domínios diferentes de 0 foram acrescidos da constante, isto porque a 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 dados COMPANY, seria possível perceber que os demais domínios de atributos das tabelas restantes permaneceram com peso 1. Como se pode perceber na Figura 5.3, apesar dos domínios dos atributos de ambas relações possuirem maior valor que os demais domínios, entre si eles possuem o mesmo valor. A probabilidade da palavra-chave research ser mapeada para um domínio de atributo da relação Employee é a mesma probabilidade de ser mapeada para um domínio de atributo da relação Department. Porém, essa não é a realidade. Com base em observações de que os seres humanos tendem a escrever consultas em que palavraschave 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 um domínio de atributo da relação Deparment. Além de considerar as interdependências entre as palavras-chave, o método proposto neste trabalho considera as posições relativas destas palavras na consulta com base na proximidade entre elas. Quanto mais distante uma palavra-chave mapeada está de uma palavra-chave não mapeada, menor é sua influência no mapeamento desta palavra.

65 5.3 Considerações Finais 64 Este fato levou à seguinte modificação no processo de contextualização: ao invés de adicionar 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ção relativa da palavra-chave department é 2 e da palavra research é 3, enquanto que a distâ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ém considerando a modificação no processo de contextualização. Como a constante considerada é 10 e a distância entre as palavras-chave department e research é 1, então o valor 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 de atributos da relaçao Employee é 10/2 = 5, totalizando 6. Tabela 5.4: Mapeamento considerando a proximidade entre as palavras-chave D.Dna D.Dnu D.Mgr_ss D.Mgr_st E.Fn E.Mi E.Ln E.Ssn E.Bd E.Ad employees department research 11* Considerações Finais Analisando a ferramenta Keymantic é possível identificar certas limitações, como a impossibilidade de tratar consultas com funções agregadas e valores compostos por mais de uma palavra-chave. Com o intuito de superar tais limitações, o método proposto implementou novas funcionalidades externas e realizou modificações internas à ferramenta. Entre as novas funcionalidades externas estão a capacidade de realizar consultas com 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; e ranquear os resultados retornados ao usuário de modo que os resultados mais relevantes serão apresentados antes dos demais. As modificações internas dizem respeito aos três primeiros passos do processo de Mapeamento. No Passo 1, o método proposto calcula os pesos para termos de esquema com base na média das métricas de similaridade e considerando o uso de sinônimos em um segundo nível. Ainda nesse passo, faz uso de uma constante para equipar a pontuação

66 5.3 Considerações Finais 65 entre os pesos de termos de esquema e de termos de valor. A modificação nos passos 2 e 3 se refere à alteração no processo de contextualização, de modo que além de considerar as interdependências entre as palavras-chave, o método proposto também considera a proximidade entre elas.

67 Aplicação do Método Proposto CAPÍTULO 6 A fim de exemplificar de forma mais detalhada o processo de mapeamento de uma consulta com palavra-chave em consultas SQL, executado pelo método proposto neste trabalho, serão apresentados dois estudos de caso. O primeiro engloba o 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 Agregada/Ordenação/Valores Compostos, as palavras-chave referentes ao uso das funções agregadas e ordenação são retiradas da consulta, restando apenas palavras-chave que serã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 todas as 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 de uma palavra-chave. Além disso, em oposição ao primeiro estudo de caso, o segundo apresentará o mapeamento de uma consulta onde nem todas as palavras-chave são mapeadas para termos de esquema, ou seja, algumas palavras-chave são mapeadas para valores de atributos. 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 e Ranking dos bancos relevantes serão desconsideradas nos estudos de caso a seguir. Para ambos os estudos de caso, será considerado o esquema e os dados do banco de dados COMPANY. Após apresentada a seção de estudos de caso será estabelecido um comparativo entre os resultados gerados pela ferramenta Keymantic e o presente método, elucidando as melhorias originadas pelas modificações propostas. 6.1 Estudos de Caso Esta seção detalha passo a passo o processo de mapeamento realizado pelo método proposto por meio de dois exemplos de consulta com palavras-chave. Tais exemplos estão apresentados nas duas subseções seguintes.

68 6.1 Estudos de Caso Estudo de Caso - Funções Agregadas e Ordenação Como mencionado no Capítulo 3, o processo de verificação de função agregada e de ordenação é baseado em uma lista de palavras reservadas pré-definidas, que permitem a identificação das palavras-chave da consulta que sugerem o uso destas funções. Estas palavras reservadas são agrupadas de acordo com a função por elas sugeridas. Foram criados 7 grupos e para cada grupo é definido o conjunto de palavraschave que o representa. Um conjunto mais representativo poderia ser obtido acoplando um thesaurus ao sistema. Os grupos e seus respectivos conjuntos de palavras-chave são listados a seguir: O grupo maximo contém as palavras-chave que sugerem o uso da função agregada max 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 ordenação order by e é formado pelo seguinte conjunto de palavras-chave, ordenacao = {order by, descending order by, ascending order by, sorted by, ranked by, classified by, organized by}. Neste grupo, ainda é feita uma verificação adicional. Caso a consulta contenha a palavra-chave descending, então além do uso da cláusula order by é usada a claúsula desc. Após identificar qual palavra-chave sugere o uso de funções agregadas ou de ordenaçã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óximas umas das outras. Desta forma, após a identificação da palavra-chave que sugere o uso de uma função agregada ou de ordenação, a função por ela sugerida é aplicada ao termo do banco representado pela palavra-chave imediatamente posterior.

69 6.1 Estudos de Caso 68 Verificação de Função Agregada/Ordenação/Valores Compostos 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ções count, group by e order by, respectivamente. Até este momento, nenhuma palavrachave foi mapeada para um termo do banco de dados, então limita-se a dizer que estas funções identificadas serão aplicadas aos termos representados pelas palavras-chave employees, department e name. As palavras-chave identificadas como funções agregadas ou de ordenação são eliminadas da consulta, restando apenas as palavras-chave que desempenham um papel no banco de dados. A consulta resultante desta etapa é a consulta employees department name. Expansão da consulta Para cada palavra-chave da consulta resultante da etapa anterior, são obtidos seus sinônimos a partir do WordNet e estes sinônimos são então adicionados à consulta. Ao fim desta 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 necessá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 é maior que o limiar (0.65), dispensando, assim, o uso dos sinônimos. A Tabela 6.1 apresenta os pesos intrínsecos referente aos termos de esquema (Submatriz SW). Por motivos de espaço, a figura não apresenta todos os termos de esquema (relações e atributos) do banco de dados COMPANY, limitando-se apenas àqueles que serão necessários ao contexto do mapeamento da consulta em questão. Os pesos intrínsecos dos termos de valor são calculados com base no uso de expressões regulares. Se um valor é compatível com o domínio de um determinado atributo, então o peso é definido como 1, caso contrário, como 0. Para normalizar os

70 6.1 Estudos de Caso 69 Tabela 6.1: Pesos intrínsecos da Submatriz SW (consulta quantity employees 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 employees department name pesos intrínsecos dos termos de esquema e de valor, os pesos dos termos de valor são multiplicados por uma constante, definida como 65. A Tabela 6.2 apresenta os pesos intrínsecos referente aos termos de valor (Submatriz VW) para a consulta do presente estudo de caso. Tabela 6.2: Pesos intrínsecos da Submatriz VW (consulta quantity 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 employees department name 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 cada peso 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 à coluna do peso caracterizado como máximo. Na Tabela 6.3, os pesos 89 da linha 1, 100 da linha 2, e 83 da linha 3 são escolhidos como máximos. Como cada peso escolhido está em uma coluna diferente, temos um mapeamento formado pelos mapeamentos individuais das palavras-chave employees, department, name para os termos Employee, Department, Dname. A pontuação deste mapeamento é calculada como a soma dos pesos íntrinsecos selecionados como máximo, resultando em 272. Tabela 6.3: Mapeamento da consulta quantity employees 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 employees 0 89* department 100* name * Uma vez gerado o melhor mapeamento, o processo de seleção dos melhores mapeamentos gera novos mapeamentos atribuindo um valor negativo aos mapeamentos individuais já realizados, de modo a não repetí-los. Assim, a partir do mapeamento da Tabela 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 apenas os 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

71 6.1 Estudos de Caso 70 Tabela 6.4: Primeiro mapeamento gerado a partir do mapeamento da Tabela 6.3 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 employees department 100* name * Tabela 6.5: Segundo mapeamento gerado a partir do mapeamento da Tabela 6.3 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 employees 0 89* department name * Tabela 6.6: Terceiro mapeamento gerado a partir do mapeamento da Tabela 6.3 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 employees 0 89* department 100* name * que quanto maior o limiar, menor o número de resultados e melhor a qualidade destes resultados. 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 ( = 244). O algoritmo de seleção é executado até o ponto em que nenhum dos mapeamentos gerados possua pontuação acima do limiar. Como o mapeamento da Tabela 6.6 possui pontuação acima do limiar, são gerados a partir dele os três mapeamentos apresentados nas tabelas 6.7, 6.8 e 6.9. Tabela 6.7: Primeiro mapeamento gerado a partir do mapeamento da Tabela 6.6 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 employees department 100* name * Tabela 6.8: Segundo mapeamento gerado a partir do mapeamento da Tabela 6.6 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 employees 0 89* department name * De modo semelhante, por possuir pontuação abaixo do limiar, os mapeamentos das tabelas 6.7 e 6.8 são desconsiderados, e por posuir pontuação acima do limiar, são gerados novamente mais três mapeamentos a partir do mapeamento da Subfigura 6.9. A Figura 6.10 apresenta apenas um dos mapeamentos gerados, uma vez que os outros dois mapeamentos 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 mapeamentos, porém nenhum desses mapeamentos agora possuem pontuação acima do limiar.

72 6.1 Estudos de Caso 71 Tabela 6.9: Terceiro mapeamento gerado a partir do mapeamento da Tabela 6.6 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 employees 0 89* department 100* name * Tabela 6.10: Mapeamento gerado a partir do mapeamento da Tabela 6.9 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 employees 0 89* department 100* name * Ao gerar o primeiro mapeamento, o valor 89 da primeira linha será negativado, restando nenhum peso a ser escolhido como máximo nessa linha. Dessa forma, a pontuação do mapeamento será calculada apenas com os pesos máximos das segunda e terceira linhas, = 183. Ao gerar o segundo mapeamento, o valor 100 da segunda linha será negativado e o mapeamento irá possuir pontuação = 172. Ao gerar o terceito mapeamento, o valor 83 da terceira linha será negativado resultando em uma pontuação = 189. Uma vez que nenhum dos mapeamentos possui pontuação acima do limiar, o algoritmo de seleção dos melhores mapeamentos pára e retorna o conjunto de mapeamentos selecionados, ou seja, aqueles que foram gerados e possuem pontuação acima do limiar. No caso da consulta deste estudo de caso, o conjunto retornado é formado pelos mapeamentos das tabelas 6.3, 6.6, 6.9 e Contextualização de VW e Seleção dos Melhores Mapeamentos para os termos de valor (Passo 3) Para cada mapeamento gerado na etapa anterior, é realizado o processo de contextualização da Submatriz VW e selecionados os melhores mapeamentos para os termos de valor, seguindo a mesma ideia. Porém, como todas as palavras-chave já foram mapeadas para termos de esquema durante o Passo 2, ao ser realizado o processo de contextualização, todos os pesos das linhas em VW correspondentes a estas palavraschave já mapeadas serão definidos como 0. Assim, nenhum mapeamento gerado para os termos de valor possuirá pontuação maior que 0 e o algoritmo de seleção de melhores mapeamentos 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 à Submatriz SW. Assim, cada um dos 4 mapeamentos retornados no Passo 2 formam uma

73 6.1 Estudos de Caso 72 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 department 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 Agregada/Ordenação/Valores Compostos foram identificadas algumas palavras-chave como representações de funções agregadas e de ordenação, e essas funções seriam aplicadas sobre os termos para os quais as palavras-chave employees, department e name seriam mapeadas. Neste momento, é possível saber sobre quais termos essas funções serão aplicadas. 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 Employee. Da mesma forma, a palavra-chave for each identificada como uso da cláusula de agrupamento group by será aplicada à relação Department e por fim, a palavra-chave order by identificada como uso da claúsula de ordenação order by será aplicada ao atributo Dname. 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 uma consulta onde as palavras-chave sobre as quais serão aplicadas as funções representem atributos. Considerando esse fato, o método proposto oferece uma solução para este problema. Quando o usuário constrói a consulta de modo que a palavra-chave sobre a qual será 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, é usada apenas 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 que duas 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ência de mais de um peso caracterizado como máximo na mesma coluna. Caso haja, todos os pesos 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 uma semântica semelhante (não igual) à consulta deste estudo de caso, os resultados desta consulta iriam apresentar resultados semanticamente diferentes. Veja na Tabela 6.11 os pesos instrínsecos referentes à Submatriz SW desta consulta. Durante o processo de mapeamento, os pesos 89 da linha 1 e os pesos 100 das linhas 2 e 3 seriam escolhidos como 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

74 6.1 Estudos de Caso 73 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á tido como 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 valor 67. Consequentemente, a última palavra-chave department seria mapeada para a relação Dependent, o que não representa a semântica correta da palavra-chave. Tabela 6.11: Mapeamento da consulta quantity employees for each department order by department Depa E Depe Dept P W employees 0 89* department 100* department * Geração das Interpretações (Passo 5) Uma vez computadas as melhores configurações, as interpretações da consulta com palavra-chave, isto é, as consultas SQL, são geradas. A presença de diferentes caminhos de junções permite que uma configuração gere diversas interpretações. Para o primeiro mapeamento gerado, em que as palavras-chave employees, department 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 duas tabelas 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 caminhos diretos entre Employee e Department por meio dos pares <chave primária,chave estrangeira> <Dno, Dnumber> e <Ssn, Mgr_ssn>, e o caminho formado pela junção entre Department-Project-Works_on-Employee. Assim, temos três interpretações possíveis para o primeiro mapeamento. Cada interpretação será construída da seguinte forma: as funções agregadas identificadas são aplicadas aos atributos definidos no mapeamento e são colocadas na claúsula select. As relações necessárias são colocadas na cláusula from e a junçã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 e sã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ão mapeadas 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.

75 6.1 Estudos de Caso 74 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 9 /* Interpretação do caminho de junção por meio do par 10 * chave-primária-chave-estrangeira <dno, dnumber>*/ 11 select distinct count(employee.ssn), department.dname 12 from department, employee 13 where department.dnumber = employee.dno 14 group by department.dnumber 15 order by department.dname /* Interpretação do caminho de junção entre 18 * Department-Project-Works_on-Employee*/ 19 select distinct count(employee.ssn), department.dname 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 24 group by department.dnumber 25 order by department.dname Dessa forma, as tabelas necessárias para essa configuração também são Employee 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 na terceira configuração a palavra-chave name é mapeada para o atributo Lname da relação Employee. Assim, novamente são geradas três interpretações semelhantes as anteriores.

76 6.1 Estudos de Caso 75 Código 6.2 Código SQL da segunda 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), employee.fname 4 from department, employee 5 where employee.ssn = department.mgr_ssn 6 group by department.dnumber 7 order by employee.fname 8 9 /* Interpretação do caminho de junção por meio do par 10 * chave-primária-chave-estrangeira <dno, dnumber>*/ 11 select distinct count(employee.ssn), employee.fname 12 from department, employee 13 where department.dnumber = employee.dno 14 group by department.dnumber 15 order by employee.fname /* Interpretação do caminho de junção entre 18 * Department-Project-Works_on-Employee*/ 19 select distinct count(employee.ssn), employee.fname 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 23 group by department.dnumber 24 order by employee.fname Na quarta e última configuração, as palavras-chave employees e department são mapeadas para as relações Employee e Department e a palavra-chave name mapeada para o atributo Pname da relação Project. Assim, é necessário o uso das informações das tabelas Employee, Deparment e Project. O número de possíveis caminhos de junção entre estas 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 os resultados 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 da configuração correspondente e secundariamente pelo tamanho do caminho de junção

77 6.1 Estudos de Caso 76 Código 6.3 Código SQL da quarta configuração para a consulta quantity employees for each department order by department 1 /* Interpretação do caminho de junção entre 2 * Employee-Department-Project usando o par 3 * chave-primária-chave-estrangeira <ssn, mgr_ssn>*/ 4 select distinct count(employee.ssn), project.pname 5 from department, employee, project 6 where employee.ssn = department.mgr_ssn 7 AND project.dnum = department.dnumber 8 group by department.dnumber 9 order by project.pname /* Interpretação do caminho de junção entre 12 * Employee-Department-Project usando o par 13 * chave-primária-chave-estrangeira <dno, dnumber>*/ 14 select distinct count(employee.ssn), project.pname 15 from department, employee, project 16 where employee.dno = department.dnumber 17 AND project.dnum = department.dnumber 18 group by department.dnumber 19 order by project.pname /* Interpretação do caminho de junção entre 22 * Project-Works_on-Employee-Department usando o par 23 * chave-primária-chave-estrangeira <ssn, mgr_ssn>*/ 24 select distinct count(employee.ssn), project.pname 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 28 group by department.dnumber 29 order by project.pname /* Interpretação do caminho de junção entre 32 * Project-Works_on-Employee-Department usando o par 33 * chave-primária-chave-estrangeira <dno, dnumber>*/ 34 select distinct count(employee.ssn), project.pname 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 38 group by department.dnumber 39 order by project.pname

78 6.1 Estudos de Caso 77 da interpretação correspondente. Como todas as configurações geradas neste estudo de caso possuem a mesma pontuação (272), os resultados ficarão ordenados pelo tamanho do caminho de junção. Desta forma, os resultados das interpretações que possuem 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 exibidos para o usuário. Mapeamentos diferentes, podem gerar as mesmas interpretações, e a execução destas interpretações geram os mesmos resultados. Além disso, algumas interpretações, quando executadas no banco de dados subjacente, retornam um conjunto vazio (Empty set) de resultado. Assim, resultados repetidos e a falta de resultados não são retornados ao usuário 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 ambas palavras representam conjuntamente um único valor. Esta será a consulta utilizada como exemplo neste estudo de caso. Verificação de Função Agregada/Ordenação/Valores Compostos Durante esta etapa, a consulta com palavras-chave é segmentada em duas palavras-chave employees e Houston Tx. Expansão da consulta 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 consulta expandida resultante é employees employee Houston Tx. Cálculo dos pesos intrínsecos (Passo 1) No método proposto, durante o cálculo dos pesos para termos de esquema, uma vez que a palavra-chave Houston Tx representa um termo de valor, todos os pesos da linha em SW correspondente à esta palavra-chave são definidos como 0, garantindo que esta palavra-chave não seja mapeada para um termo de esquema. Para a palavra-chave employees, o cálculo dos pesos intrínsecos é feito da maneira habitual proposta pelo método apresentado neste trabalho. Ou seja, o cálculo é feito com base inicialmente nas métricas de similaridade entre strings e, caso necessário, faz uso dos sinônimos destas

79 6.1 Estudos de Caso 78 palavras. A Tabela 6.12 apresenta uma fração dos pesos intrínsecos referentes aos termos de esquema (Submatriz SW). Os pesos intrínsecos referentes aos termos de esquemas omitidos na figura possuem todos valor 0. Tabela 6.12: Pesos intrínsecos da Submatriz SW (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 Houston Tx O cálculo dos pesos intrínsecos para termos de valor, também é executado da maneira 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 atributos compatíveis com este tipo possuem peso 1, enquanto que os atributos incompatíveis possuem 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 employees 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 Houston Tx Seleção dos melhores mapeamentos para termos de esquema (Passo 2) A partir do algoritmo de seleção dos melhores mapeamento é gerado o melhor mapeamento, o qual está apresentado na Tabela 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* Houston Tx A partir deste mapeamento, é possível gerar um novo mapeamento onde o valor 89 da primeira linha é negativado. Porém, a pontuação deste novo mapeamento é 0. Sendo assim, tal mapeamento é desconsiderado e o algoritmo de seleção termina, uma vez que não é mais possível gerar novos mapeamentos para termos de esquema com pontuação acima do limiar. Contextualização de VW e Seleção dos Melhores Mapeamentos para os termos de valor (Passo 3) Terminado o processo de seleção dos melhores mapeamentos para termos de esquema, a Submatriz VW é contextualizada com base em cada um dos mapeamentos

80 6.1 Estudos de Caso 79 gerados na etapa anterior. Os pesos da Submatriz VW da Tabela 6.13 são atualizados de acordo com as regras de contextualização, resultando na Submatriz VW atualizada da Tabela Tabela 6.15: Submatriz VW contextualizada com base no mapeamento da Tabela 6.14 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 Houston Tx 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 como 0. Por esta razão, os pesos da primeira linha foram todos zerados. Como é possível observar 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-chave employees ter sido mapeada para à relação Employee. Assim, todos os pesos dos domínios de 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 proximidade entre as palavras-chave. No caso desta consulta, como a distância entre as palavras-chave employees e Houston Tx é 1, o valor adicionado aos pesos foi 10/1 = 10, ou seja, o próprio valor da constante. A partir da Submatriz VW contextualizada é possível então gerar os mapeamentos para os termos de valor. Primeiramente, é gerado o mapeamento apresentado na Tabela Tabela 6.16: Mapeamento para termos de valor (consulta employees 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 Houston Tx * Com base neste mapeamento, é possível então gerar o mapeamento da Tabela 6.17 negativando o peso da coluna referente ao mapeamento já gerado. Tabela 6.17: Mapeamento gerado a partir do mapeamento da Tabela 6.16 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 Houston Tx * Este processo é repetido até que todos os pesos com valores iguais à 75 tenham sido negativados e seja gerado o seguinte mapeamento (Tabela 6.18). Este mapeamento por sua vez possui pontuação abaixo do limiar ( = 67 > 65), sendo então desconsiderado e encerrado o algoritmo de seleção de mapeamento.

81 6.1 Estudos de Caso 80 Tabela 6.18: Mapeamento gerado após negativar os pesos iguais à 75 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 Houston Tx Uma vez que a segunda linha da Submatriz VW atualizada da Tabela 6.15 possui 7 pesos intrínsecos com valores iguais à 75, é possível então gerar 7 mapeamentos de termos de valor. Geração das Configurações (Passo 4) Para o mapeamento SW da Tabela 6.14 tem-se 7 mapeamentos correspondentes para 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 mapeamento de 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. Geração das Interpretações (Passo 5) Como se pode notar, apenas a tabela Employee é necessária para a construção das consultas SQL. Dessa forma, não existem caminhos de junção e, consequentemente para cada configuração é gerada apenas uma interpretação. As 7 interpretações resultantes destas 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 à segunda configuração gerada (tabelas 6.14 e 6.17) e assim sucessivamente. Como se pode perceber, em cada interpretação a cláusula select possui todos os atributos da tabela Employee. Essa é a solução proposta neste trabalho para o caso em que a cláusula select fica vazia. Ou seja, como nenhuma palavra-chave foi mapeada para 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 contidas na cláusula from. Também é possível notar que as palavras-chave mapeadas para valores de atributos são verificadas na cláusula where, juntamente com as junções das tabelas, quando houver.

82 6.1 Estudos de Caso 81 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, 8 employee.bdate, employee.address, employee.sex, employee.salary, 9 employee.super_ssn, employee.dno 10 from employee 11 where employee.minit like %houston% AND employee.minit like %tx% select distinct employee.fname, employee.minit, employee.ssn, 14 employee.bdate, employee.address, employee.sex, employee.salary, 15 employee.super_ssn, employee.dno 16 from employee 17 where employee.lname like %houston% AND employee.lname like %tx% select distinct employee.fname, employee.minit, employee.lname, 20 employee.bdate, employee.address, employee.sex, employee.salary, 21 employee.super_ssn, employee.dno 22 from employee 23 where employee.ssn like %houston% AND employee.ssn like %tx% select distinct employee.fname, employee.minit, employee.lname, 26 employee.ssn, employee.bdate, employee.sex, employee.salary, 27 employee.super_ssn, employee.dno 28 from employee 29 where employee.address like %houston% AND employee.address like %tx% select distinct employee.fname, employee.minit, employee.lname, 32 employee.ssn, employee.bdate, employee.address, employee.salary, 33 employee.super_ssn, employee.dno 34 from employee 35 where employee.sex like %houston% AND employee.sex like %tx% select distinct employee.fname, employee.minit, employee.lname, 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%

83 6.2 Comparação com a Keymantic 82 Ranking do resultados Cada uma dessas interpretações é executada e os seus resultados retornados ao usuário. Como todas as interpretações possuem a mesma pontuação (75) e não possuem caminho de junção, os resultados são apresentados ao usuário com base na ordem em que as interpretações foram geradas. Contudo, apenas o resultado referente à execução da quinta interpretação do Código 6.4 é apresentado ao usuário. Esta interpretação se refere 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 vez que nenhum dos atributos da relação Employee, exceto o atributo Address, possui o valor Houston Tx. 6.2 Comparação com a Keymantic A seção anterior apresentou o funcionamento do método proposto por este trabalho, detalhando a entrada e a saída de cada etapa, até a execução de cada interpretação gerada e o retorno dos resultados ordenados ao usuário. Os estudos de caso utilizados englobaram as modificações externas e internas à Keymantic a fim de cobrir o método proposto por completo. Por outro lado, esta seção visa a elucidar quais são os impactos causados por estas modificações no conjunto de resultados apresentado ao usuário. Para tanto é feito um comparativo entre a ferramenta Keymantic e o método proposto por este trabalho. Imediatamente é possivel perceber que as modificações externas representam uma melhoria evidente à ferramenta, uma vez que elas permitem consultas até então não realizadas pela Keymantic, como consultas com o uso de funções agregadas, ordenação e 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 comum em ambos sistemas, de forma a identificar as diferenças entre as saídas de cada etapa do processo de Mapeamento da consulta Suposições à implementação Keymantic Apesar dos esforços, não se conseguiu encontrar a implementação da ferramenta Keymantic. Neste sentido, para realizar o comparativo foi necessário realizar uma implementação própria. Esta implementação, bem como a implementação do método proposto neste trabalho, foram baseadas nas informações contidas no artigo que descreve a ferramenta ([4]). O artigo não é claro o suficiente para permitir uma implementação fiel. Desta forma, algumas suposições foram feitas e alguns detalhes omitidos.

84 6.2 Comparação com a Keymantic 83 Uma das suposições feitas é o uso do processo de contextualização no processo de seleção dos melhores mapeamentos para os termos de esquema. Como mencionado no Capítulo 4, a figura do processo de Mapeamento (Figura 4.1) apresenta explicitamente o processo de contextualização apenas para os termos de valor (Passo 3). Na explicação do processo de seleção dos melhores mapeamentos, o artigo apenas cita o uso de regras de contextualizaçã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 a contextualização também é realizada no Passo 2. Assumiu-se, também, que as regras de contextualização só são utilizadas quando ocorre o fato de duas palavras-chave serem mapeadas para o mesmo termo do banco, ou seja, existir mais de um peso caracterizado como máximo na mesma coluna. Então, todos os pesos definidos como máximo são descaracterizados, exceto o maior, e os pesos das linhas correspondentes aos pesos descaracterizados são atualizados com as regras de contextualização. Caso nenhuma coluna tenha mais de um peso caracterizado como máximo, não é necessário atualizar os 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 é mapeada para um atributo, permanecendo a cláusula select vazia, todos os atributos das tabelas que estã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 para termos de esquema a implementação não faz uso de ontologias e durante o cálculo dos pesos 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étricas de similaridade de string e faz uso dos sinônimos obtidos pelo WordNet, enquanto que os pesos intrínsecos de termos de valor são calculados com base no uso de expressões regulares apenas Exemplo selecionado para Comparação Uma vez implementados os dois sistemas, é possível compará-los com base nos resultados retornados por cada um a partir da execução de uma mesma consulta com palavras-chave. Os exemplos de consulta das seções anteriores já executados pelo método proposto não podem ser utilizados para o propósito deste comparativo, visto que 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 consulta exemplo desta seção será a consulta employees department research do Exemplo 1 (Capítulo 4), cuja semântica pretendida é encontrar os empregados que trabalham no departamento de nome Research. Para cada sistema, será apresentada a saída e a entrada de cada etapa do processo

85 6.2 Comparação com a Keymantic 84 de Mapeamento correspondente e comentadas as diferenças entre eles, caso haja. Para simplificar, a partir deste momento o método proposto será referenciado como MP. Cálculo dos pesos intrínsecos (Passo 1) Dada a consulta employees department research, a Tabela 6.19 apresenta uma fração dos pesos intrínsecos calculados para termos de esquema pelo MP, enquanto que a Tabela 6.20 apresenta os pesos calculados pela Keymantic. Os termos de esquema omitidos nas figuras possuem peso igual a 0. Tabela 6.19: Pesos intrínsecos da Submatriz SW calculados pelo MP Depa E Depe Dept D.Dna D.Dnu E.Fn E.Mi E.Ln E.Ad Depe.De P.Pn employees department research Tabela 6.20: Pesos intrínsecos da Submatriz SW calculados pela Keymantic Depa E Depe Dept D.Dna D.Dnu E.Fn E.Mi E.Ln E.Ad Depe.De P.Pn employees department research 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étricas de similaridade, enquanto que na Keymantic os pesos são definidos como o maior valor retornado por essas métricas. No cálculo realizado pelo MP, foi encontrada uma alta similaridade entre a palavra-chave department e os termos Department, Dependent e Dependent_name. A expressão alta similaridade é usada com o intuito de expressar o fato da similaridade entre a palavra-chave e o termo ser acima do limiar. De fato, se considerado apenas o conjunto 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 à palavrachave em questão. No cálculo realizado pela Keymantic, constatou-se uma alta similaridade entre a palavra-chave department e os termos Department, Dependent, Dept_locations, Dname, Dependent_Name e Pname. Novamente, apenas o termo Department é similar à semântica pretendida pela palavra-chave department. Repare que se considerarmos o contexto da consulta, o termo Dname poderia ser considerado como similiar à semântica pretendida pela consulta. Porém, durante a etapa de cálculo dos pesos intrínsecos é considerado

86 6.2 Comparação com a Keymantic 85 apenas a semântica da palavra-chave de forma isolada. O contexto da consulta é considerado durante a etapa de seleção dos melhores mapeamentos, em que são empregadas as regras de contextualização que levam em consideração a interdependência entre as palavras-chave da consulta. Comparando os conjuntos de termos não similares à semântica 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ão mais similares à palavra-chave. Os pesos calculados para termos de valor por ambos os sistemas são apresentados nas tabelas 6.21 e Tabela 6.21: Pesos intrínsecos da Submatriz VW calculados pelo MP 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 department research Tabela 6.22: Pesos intrínsecos da Submatriz VW calculados pela Keymantic 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 department research Quanto aos pesos intrínsecos dos termos de valor calculados pelo MP e pela Keymantic também é possível notar uma diferença entre as tabelas. Tal diferença é causada pela modificação referente à normalização dos pesos dos termos de valor, realizada pelo MP na etapa de Cálculo dos pesos intrínsecos para os termos de valor. No caso desta consulta, não fica evidente a razão desta modificação. Como exemplificado no capítulo anterior, na Seção 5, o motivo da modificação é equiparar o valor dos pesos dos termos de esquema e dos termos de valor, de maneira que ambos influenciem igualmente a pontuaçã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 pesos intrínsecos calculados. Em posse da Submatriz SW, o Passo 2 realiza a seleção dos melhores mapeamentos para os termos de esquema. As tabelas 6.23 e 6.24 apresentam o primeiro mapeamento para termos de esquema gerado por ambos os sistemas. Tabela 6.23: Mapeamento gerado pelo MP Depa E Depe Dept D.Dna D.Dnu E.Fn E.Mi E.Ln E.Ad Depe.De P.Pn employees 0 89* department 100* research

87 6.2 Comparação com a Keymantic 86 Tabela 6.24: Mapeamento gerado pela Keymantic Depa E Depe Dept D.Dna D.Dnu E.Fn E.Mi E.Ln E.Ad Depe.De P.Pn employees 0 94* department 100* research Em ambos sistemas, a palavra-chave employees foi mapeada para a relação Employee e a palavra-chave department para a relação Department. A palavra-chave research 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 do mapeamento gerado em cada sistema, são gerados novos mapeamentos pelo algoritmo de seleção dos melhores mapeamentos até que nenhum mapeamento novo possua pontuação maior que o limiar. Considere o mapeamento do MP (Tabela 6.23). A partir dele é possível gerar dois 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ção deste novo mapeamento é 100, estando abaixo do limiar ( = 170). Sendo assim, este mapeamento é desconsiderado. O segundo mapeamento é gerado negativando o valor 100 da segunda linha, e selecionando o valor 89 da primeira linha e o valor 67 da segunda linha. 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 gerados dois novos mapeamentos. O mapeamento gerado por negativar o valor 94 da primeira linha, por sua vez, também possui pontuação abaixo do limiar e é desconsiderado. O mapeamento gerado negativando o valor 100 da segunda linha e selecionando como pesos máximos os valores 94 e 81 das primeira linha e segunda linhas, respectivamente, gera um novo mapeamento com pontuação 175 que está acima do limiar ( = 174). Este mapeamento é apresentado na Tabela A partir deste mapeamento é possível gerar dois novos mapeamentos. Porém estes dois mapeamentos possuem pontuação abaixo do limiar e são desconsiderados. Tabela 6.25: Mapeamento gerado a partir do mapeamento da Tabela 6.24 (Keymantic) Depa E Depe Dept D.Dna D.Dnu E.Fn E.Mi E.Ln E.Ad Depe.De P.Pn employees 0 94* department * research Assim, ao final do Passo 2, o MP retorna um único mapeamento para termo de esquema (Tabela 6.23), enquanto que a Keymantic retorna dois mapeamentos (Tabela 6.24 e 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

88 6.2 Comparação com a Keymantic 87 vez que a Keymantic gerou um mapeamento a mais para termos de esquema. O primeiro mapeamento gerado pela Keymantic é equivalente ao único mapeamento gerado pelo MP, onde a palavra-chave employees é mapeada para a relação Employee e a palavra department para a relação Deparment. O segundo mapeamento representa o mapeamento da palavra-chave department para a relação Dependent. Claramente, apenas o primeiro mapeamento da Keymantic, assim como o mapeamento do MP, são condizentes com a semântica pretendida pela consulta. Dessa forma, novamente o MP se mostrou mais eficiente que a Keymantic. Contextualização de VW e Seleção dos Melhores Mapeamentos para os termos de valor (Passo 3) Terminado o Psasso 2, cada mapeamento para termos de esquema gerado neste passo é 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 um dos mapeamentos gerados pelos dois sistemas. Tabela 6.26: Submatriz VW contextualizada com base no mapeamento da Tabela 6.23 (MP) 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 department research Tabela 6.27: Submatriz VW contextualizada com base no mapeamento da Tabela 6.24 (Keymantic) 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 department research Tabela 6.28: Submatriz VW contextualizada com base no mapeamento da Tabela 6.25 (Keymantic) 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 department research Considere as tabelas 6.26 e Em ambas, os pesos das linhas 1 e 2 foram zerados pelo fato das palavras-chave correspondentes já terem sido mapeadas. Além disso, o valor 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 sido mapeadas para tais relações, aumentando assim a probabilidade do valor research ser um domínio de atributo de umas destas duas relações. Porém, na Submatriz VW referente ao MP, os valores referentes aos domínios de atributos da relação Deparment sofreram

89 6.2 Comparação com a Keymantic 88 um maior acréscimo em relação aos da relação Employee. Isso se deve à modificação no processo de contextualização referente à proximidade das palavras-chave. O fato da palavra-chave research estar mais próxima da palavra-chave deparment, a qual foi mapeada para a relação Deparment, torna mais provável que esta palavra-chave seja mapeada para termos relacionados à relação Deparment. A Tabela 6.28 segue o mesmo raciocínio da 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ão aqueles referentes aos domínios de atributo desta relação. Realizado o processo de contextualização, inicia-se a seleção dos melhores mapeamentos para termos de valor baseado nas submatrizes VW atualizadas. A partir da Tabela 6.26 referente ao sistema MP, é possível gerar 9 mapeamentos para termos de valor com pontuações acima do limiar ( = 67). Esses mapeamentos representam o mapeamento da palavra-chave research para os domínios dos atributos Dname, Mgr_ssn, Fname, Minit, Lname, Ssn, Address, Sex e Super_ssn. Estes mesmos mapeamentos são gerados pela Keymantic a partir da Submatriz VW contextualizada referente ao primeiro mapeamento de esquema (Tabela 6.27). Já para a Submatriz VW referente ao segundo mapeamento da Keymantic são gerados 11 mapeamentos de termos de valor com pontuaçã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 de esquema e 9 mapeamentos correspondentes para termos de valor; para a Keymantic temos 2 mapeamentos para termos de esquema e 9 mapeamentos para termos de valor para o primeiro e 11 para o segundo. Geração das Configurações (Passo 4) Durante o Passo 4 a execução do MP resulta em 9 configurações, enquanto que a execução da Keymantic resulta em 20 configurações. Das configurações do MP, 2 configurações possuem pontuação igual a = 264, referentes ao mapeamento da palavra-chave research para os domínios dos atributos da relação Department; e 7 configurações possuem pontuação igual a = 259, referentes ao mapeamento da palavra-chave para os domínios dos atributos da relação Employee. Em relação a Keymantic tem-se 9 configurações com pontuação igual a = 205, referentes ao mapeamento da palavra-chave department para a relação Department e da palavrachave research para os domínios de atributos das relações Employee e Department, e 11 configurações com pontuação igual a = 186, referentes ao mapeamento da palavra-chave department para a relação Dependent e da palavra-chave research para os domínios de atributos das relações Employee e Dependent.

90 6.2 Comparação com a Keymantic 89 As 9 configurações geradas pelo MP são equivalentes às 9 configurações com pontuaçã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 configurações referentes ao mapeamento da palavra-chave para os domínios de atributos da relação Department possuem uma maior pontuação, enquanto que na execução da Keymantic todas as 9 possuem a mesma pontuação. De acordo com a semântica pretendida pela consulta, os mapeamentos referentes aos domínios de atributos da relação Department são mais relevantes para a consulta do que os mapeamentos referentes aos domíníos de atributos da relação Employee. Além disso, nenhuma das 11 outras configurações geradas pela Keymantic estão de acordo com o resultado esperado pela consulta, uma vez que 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. Geração das Interpretações (Passo 5) Considerando estas configurações, as interpretações são geradas no Passo 5. A partir das 9 configurações do MP são geradas 9 3 = 27 interpretações, enquanto que para as 20 configurações da Keymantic são geradas = 38 interpretações. Em ambos os casos, apenas as interpretações referentes à configuração que mapeia as palavrachave da consulta para os termos Employee, Department e Dname retornam resultados válidos. Esta configuração gera 3 interpretações. Percebe-se que as modificações internas que foram realizadas nos três primeiros passos do processo de Mapeamento da Keymantic, causaram impacto não somente na saí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 e interpretaçõ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ântica pretendida pelo usuário, apresentados na Tabela A Figura 6.1 compara o numero de configurações e interpretações (consultas SQL) geradas por ambos os sistemas. Os valores são apresentados para cada uma das consultas, cuja identificação é a mesma usada na Tabela As modificações internas, as quais foram realizadas nos três primeiros passos do processo de Mapeamento da Keymantic, influenciaram os resultados obtidos pelo método proposto, resultando em valores inferiores em relação à Keymantic para o numero de configurações e interpretações. Tal

91 6.2 Comparação com a Keymantic 90 Tabela 6.29: Conjunto de consultas com palavras-chave Consulta com palavras-chave Semântica pretendida 1 department lista de informações sobre os departamentos da empresa 2 department employee lista de empregados de cada departamento 3 department project lista de projetos de cada departamento 4 department project newbenefits informações do departamento responsável pelo projeto Newbenefits 5 location project productx localização do projeto cujo nome é ProductX 6 employee dependent daughter informações dos empregados que tem filha como dependente 7 project name employee John nome do projeto no qual o empregado John trabalha 8 employee address project 1 endereço do empregado que trabalha no projeto 1 9 hours employee works project productz quantidade de horas trabalhadas por cada empregado do projeto ProductZ 10 project location employee salary localização do projeto no qual trabalha o empregado cujo o salário é redução possui impacto importante no custo do processo, e possibilita ao usuário lidar com um número menor de resultados para a sua consulta. (a) Número de configurações geradas por ambos os sistemas (b) Número interpretações geradas por ambos os sistemas Figura 6.1: Número de configurações e interpretações geradas por ambos os sitemas Os gráficos da Figura 6.2 exploram as consultas com três ou mais palavras-chave,

92 6.2 Comparação com a Keymantic 91 e apresentam a precisão relativa a cada sistema. Essa métrica denota a fração relevante das interpretações obtidas, sendo um indicador de qualidade difundido na literatura. Como se pode observar na Subfigura 6.2(a) o método proposto foi superior em todas as consultas. A Subfigura 6.2(b) exibe valores de precisão em relação ao tamanho da consulta, ou seja, o número de palavras-chave que a compõe. A precisão decresce em ambos os sistemas com o aumento do número de palavras-chave na consulta. Contudo, observam-se novamente melhores 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 exibe os resultados de acordo com a ordem em que eles são gerados. À medida que os mapeamentos 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 correspondentes 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 mapeamentos. Contudo, apesar das pontuações dos mapeamentos decrescerem à medida que

93 6.2 Comparação com a Keymantic 92 eles são gerados, pode acontecer de um mapeamento com menor pontuação ser gerado antes de um mapeamento com maior pontuação, desde que estes dois mapeamentos estejam sendo gerados a partir de um mesmo mapeamento. Considere o mapeamento da Tabela 6.30 para a consulta department number location. Tabela 6.30: Mapeamento a partir do qual são gerados mapeamentos que não estão de acordo com a ordem decrescente de pontuação Depa Depe Dept Depa.Dnu Dept.Dnu Dept.Dlo department 100* number * 85 0 location * A partir deste mapeamento podem ser gerados 3 mapeamentos. O primeiro mapeamento é gerado negativando o valor 100 da primeira linha e escolhendo o valor 81 desta mesma linha como máximo, resultando numa pontuação igual a = 254. O segundo mapeamento é gerado negativando o primeiro valor 85 da segunda linha e escolhendo o próximo valor 85 desta linha, resultando na pontuação = 273. E o terceiro e último mapeamento é gerado negativando o valor 88 da terceira linha e escolhendo o valor 76, resultando na pontuação = 261. Como se pode observar, a ordem dos mapeamentos gerados não corresponde à ordem decrescente de pontuação. Assim, uma vez que a ferramenta apresenta os resultados pela ordem em que são gerados, nem sempre os resultados serão apresentados com uma ordenação decrescente 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 o primeiro resultado relevante aparece no conjunto de resultados. A Figura 6.3 apresenta o MRR para ambos os sistemas, com base no comprimento da consulta, ou seja, o número de 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])

94 6.3 Considerações Finais 93 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 desconsiderados. Uma vez que o Reciprocal Rank representa o inverso da posição na qual o primeiro resultado relevante apareceu, no caso do cálculo do MRR, todos os resultados foram considerados, de modo a verificar em que posição o primeiro resultado relevante apareceu. Como se pode observar na Figura 6.3, o MP supera a ferramenta Keymantic com base na métrica MRR. Na Keymantic, quanto maior a consulta, mais longe do topo do ranking aparece o primeiro resultado relevante. No MP, ocorre o mesmo, porém de forma mais suave, ou seja, apesar do primeiro resultado se distanciar do topo à medida que a consulta aumenta, este resultado ainda permanece como um dos primeiros resultados do ranking. 6.3 Considerações Finais Uma vez identificadas algumas limitações na ferramenta Keymantic, foram sugeridas 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 resultados menor e mais significativo para a consulta com palavras-chave submetida, enquanto que as modificações externas à ferramenta tornaram possível o tratamento de consultas até então não realizadas pela Keymantic, como consultas com o uso de funções agregadas, ordenação e valores compostos por mais de uma palavra-chave.

95 Conclusão CAPÍTULO 7 Este trabalho propôs um método para consultar bancos de dados relacionais com o uso de palavras-chave de modo a simplificar o acesso a estes dados, uma vez que tais consultas fazem uso de palavras que se aproximam à língua usual. O método proposto identifica os bancos de dados disponíveis e relevantes para uma consulta e converte a consulta em expressões SQL correspondentes, as quais são submetidas aos bancos de dados identificados como relevantes. O método retorna os resultados obtidos pela execução das consultas SQL aos bancos de dados. A análise semântica da consulta com palavras-chave foi baseada na abordagem pertinente à ferramenta Keymantic. O método proposto incorporou melhorias à referida abordagem, proporcionando resultados mais eficazes em relação às intenções do usuário concernente às suas consultas com palavras-chave. As próximas seções apresentam uma síntese das principais contribuições deste trabalho, a descrição dos possíveis trabalhos futuros, e por fim a menção do trabalho relacionado 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 de mapeamento 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 dos dados de bases relacionais. Consultar bancos de dados é uma tarefa complexa, uma vez que é necessário o conhecimento da estrutura do banco, bem como de uma linguagem estruturada. Prover o uso de palavras-chave como um método alternativo de 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

96 7.1 Contribuições 95 algumas modificações internas que permitiram obter um conjunto de resultados menor 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 consulta SQL para cada um destes bancos representa um alto custo computacional, tornandose assim uma solução ineficiente. Identificar quais bancos de dados são relevantes, elimina a necessidade de mapeamento para todos eles, reduzindo consequentemente a 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 esquemas distintos para armazenar estes dados. Neste sentido, o método proposto é capaz de converter uma única consulta com palavras-chave em várias consultas SQL, cada uma correspondente a um banco de dados, independente da hetereogenidade de esquemas. 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 no banco de dados, se apresenta como uma limitação ao processamento de consultas com palavras-chave que sugerem o uso de funções. O método proposto superou tal limitação, pois incorpora uma etapa de verificação de palavras-chave, as quais possam 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 banco de dados, impedindo que se mapeie corretamente valores que são compostos por mais de uma palavra-chave. O método proposto apresentou uma solução para tal problema, 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 a proximidade entre elas, são considerados com o intuito de prever o contexto das palavras-chave na consulta e permitir um mapeamento mais próximo do significado esperado 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. Com a ordenação dos resultados sugerida neste trabalho, a implementação do método proposto se mostrou mais efetiva que a implementação da ferramenta Keymantic, uma vez que os resultados mais relevantes aparecem no topo do ranking.

97 7.2 Trabalhos Futuros Trabalhos Futuros No desenvolvimento da pesquisa, foram identificados alguns aspectos que poderiam 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 mapeamento da Keymantic empregado no método proposto, ao gerar os melhores mapeamentos faz 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, a Keymantic gera várias interpretações que são executadas no banco de dados correspondente. A execução de tais interpretações pode ter um alto custo computacional dependendo do número de consultas SQL geradas. Validar o método proposto em um cenário com múltiplos bancos de dados relacionais: no presente trabalho, o método proposto foi analisado considerando apenas um único banco de dados. Como o método pode ser aplicado a um conjunto de banco de dados, seria necessário verificar a eficiência e a eficácia do sistema neste cená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 e comparaçã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 de tais valores. Contudo, para esta solução faz-se necessário um conhecimento prévio por parte do usuário para construir a consulta de maneira adequada. Visando a eliminar esta necessidade, poderia ser utilizada a ideia do sistema FRISK ([28]). O sistema faz uso de um algoritmo de programação dinâmica para computar as melhores segmentações da consulta. Tais segmentações são apresentadas ao usuá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ão utilizadas somente quando ocorre o mapeamento de duas palavras-chave para um mesmo termo. Então, alguns pesos são descaracterizados como máximo, restando apenas o maior. Os pesos das linhas correspondentes aos pesos descaracterizados são então atualizados com as regras de contextualização. Caso não ocorra alguma descaracterizaçã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 banco de dados. Desta forma, a interdependência dos mapeamentos da palavra-chave não

98 7.3 Produção Bibliográfica 97 será considerada, pois as regras de contextualização não serão aplicadas. Como trabalho futuro, a medida que cada palavra-chave fosse mapeada, as regras de contextualização seriam aplicadas. Assim, uma vez que a palavra-chave department fosse mapeada para a relação Department, aumentaria a probabilidade da palavra-chave name 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ção dos 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 pelo dicioná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 consulta com palavras-chave mais abrangente. Tal consulta inclui palavras-chave que não representam um real significado para a consulta, como por exemplo, as palavras de, um, os, conhecidas como stopwords. A consulta em linguagem natural pode ser mapeada em consulta com palavras-chave, pela retirada das stopwords e outras transformações, visando a limpar a consulta. Construir uma versão Web: a construção de uma versão Web eliminaria a necessidade de instalação do software e seus complementos, sendo necessário apenas o uso 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, como o PostgreSQL e Oracle, por exemplo. 7.3 Produção Bibliográfica Durante o desenvolvimento deste trabalho foi produzida uma revisão sistemática com o intuito de identificar as principais técnicas e ferramentas existentes no contexto de consultas com palavras-chave em bancos de dados relacionais, bem como identificar os principais focos de pesquisa nesta área e os desafios ainda não solucionados, determinando assim o estado da arte deste assunto. O título da revisão é Consulta com palavraschave em Banco de Dados Relacionais: uma revisão sistemática e foi apresentada no Congresso de Pesquisa, Ensino e Extensão de 2012 (CONPEEX 2012) da Universidade Federal de Goiás.

99 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 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 Morgan Kaufmann, San Francisco, [2] AGRAWAL, S.; CHAUDHURI, S.; DAS, G. Dbxplorer: a system for keyword-based search over relational databases. In: Data Engineering, Proceedings. 18th International Conference on, p. 5 16, [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: , September [4] BERGAMASCHI, S.; DOMNORI, E.; GUERRA, F.; TRILLO LADO, R.; VELEGRAKIS, Y. Keyword search over relational databases: a metadata approach. In: Proceedings of the 2011 ACM SIGMOD International Conference on Management of data, SIGMOD 11, p , New York, NY, USA, ACM. [5] BERGMAN, M. K. The deep web: Surfacing hidden value, [6] COFFMAN, J.; WEAVER, A. An empirical performance evaluation of relational keyword search techniques. Knowledge and Data Engineering, IEEE Transactions on, PP(99):1, [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 , New York, NY, USA, ACM. [8] ELMASRI, R.; NAVATHE, S. B. Fundamentals of Database Systems (6th Edition). Addison-Wesley, 2011.

100 Referências Bibliográficas 99 [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), nd International Workshop on, p , sept [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 , New York, NY, USA, ACM. [11] FOUNDATION, A. W. M. Dublin core metadata initiative. Disponível em: http: //dublincore.org/. Acesso em: 21 fev [12] FOUNDATION, A. W. M. Open archives initiative. Disponível em: openarchives.org/. Acesso em: 21 fev [13] GANTI, V.; HE, Y.; XIN, D. Keyword++: a framework to improve keyword search over entity databases. Proc. VLDB Endow., 3: , September [14] GU, J.; KITAGAWA, H. Extending keyword search to metadata on relational databases. In: Information-Explosion and Next Generation Search, INGS 08. International Workshop on, p , april [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 , New York, NY, USA, ACM. [16] HRISTIDIS, V.; GRAVANO, L.; PAPAKONSTANTINOU, Y. Efficient ir-style keyword search over relational databases. In: Proceedings of the 29th international conference on Very large data bases - Volume 29, VLDB 2003, p VLDB Endowment, [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 Morgan Kaufmann, San Francisco, [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 , aug

101 Referências Bibliográficas 100 [19] KOUTRIKA, G.; ZADEH, Z. M.; GARCIA-MOLINA, H. Data clouds: summarizing keyword search results over structured data. In: Proceedings of the 12th International Conference on Extending Database Technology: Advances in Database Technology, EDBT 09, p , New York, NY, USA, 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, [21] LI, F.-Z.; LUO, D.; XIE, D. Fuzzy search on non-numeric attributes of keyword query over relational databases. In: Computer Science Education, ICCSE 09. 4th International Conference on, p , july [22] LI, G.; FENG, J.; ZHOU, X.; WANG, J. Providing built-in keyword search capabilities in rdbms. The VLDB Journal, 20:1 19, [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 , New York, NY, USA, 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 , New York, NY, USA, ACM. [25] LUO, Y.; WANG, W.; LIN, X. Spark: A keyword search engine on relational databases. In: Data Engineering, ICDE IEEE 24th International Conference on, p , april [26] MORO, M. M. Entrevista com John E. Hopcroft. SBC Horizontes, 4(1):24 27, Apr [27] PENG, Z.; ZHANG, J.; WANG, S.; WANG, C. Bring user feedback into keyword search over databases. In: Web Information Systems and Applications Conference, WISA Sixth, p , sept [28] PU, K.; YU, X. Frisk: Keyword query cleaning and processing in action. In: Data Engineering, ICDE 09. IEEE 25th International Conference on, p , april [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.

102 Referências Bibliográficas 101 [30] SAYYADIAN, M.; LEKHAC, H.; DOAN, A.; GRAVANO, L. Efficient keyword search across heterogeneous relational databases. In: Data Engineering, ICDE IEEE 23rd International Conference on, p , april [31] WANG, S.; ZHANG, K.-L. Searching databases with keywords. Journal of Computer Science and Technology, 20:55 62, [32] WANG, W.; LIN, X.; LUO, Y. Keyword search on relational databases. In: Network and Parallel Computing Workshops, NPC Workshops. IFIP International Conference on, p. 7 10, sept [33] WIKIPÉDIA, A. E. L. Deep web, Disponível em: w/index.php?title=deep_web&oldid= Acesso em: 7 maio [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 , New York, NY, USA, ACM.

103 Estrutura da Tabela de Metadados para Exposição (TME) APÊNDICE A 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 Metadados para Exposição (TME) [20] Estrutura da Tabela de Metadados para Exposição 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 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;

104 Banco de dados COMPANY APÊNDICE B O banco de dados COMPANY registra os funcionários de uma empresa, o departamento e o projeto nos quais eles trabalham, seus dependentes, a localização dos departamentos e dos projetos, etc. Tal banco de dados foi retirado da sexta edição do livro Fundamentals of Database Systems [8], bem como as informações contidas nesse apê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. Cada departamento tem um nome exclusivo, um número exclusivo e um funcionário que o gerencia. 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 nome exclusivo, 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 para um departamento, mas pode trabalhar em vários projetos, que não necessariamente são controlados pelo mesmo departamento. O número de horas por semana que um funcionário trabalha em cada projeto também é registado, bem como o supervisor direto de 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.

105 Apêndice B 104 B.2 Esquema Conceitual O Modelo Entidade-Relacionamento descreve os dados como entidades, relacionamentos 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 dados COMPANY (retirado de [8]) De acordo com os requisitos listados na seção anterior, é possível identificar quatro entidades: 1. A entidade Funcionario (Employee) possui os atributos CPF (Ssn), DataNascimento (Bdate), Nome (Name), Endereco (Address), Salario (Salary) e Sexo (Sex). Sendo o atributo Name um atributo composto. O atributo(ssn) é especificado como o atributo-chave (identificador) da entidade. 2. A entidade Departamento (Department) possui os atributos Nome (Name), Numero (Number), Numero_de_funcionarios (Number_of_employees) e Localizacoes (Locations). (Locations) é o único atributo multivalorado. Tanto (Name) como Numero (Number) podem ser especificados como atributos-chave (separadamente), uma vez que cada um foi especificado como sendo exclusivo.

106 Apêndice B A entidade Projeto (Project) possui os atributos Nome (Name), Numero (Number) e Localizacao (Location). Tanto (Name) como (Number) são atributos-chave (separadamente). 4. A entidade Dependente (Dependent) possui os atributos Nome (Name), Sexo (Sex), Data_nascimento (Birth_date) e Parentesco (Relationship). Dois dependentes de dois funcionários distintos podem, por coincidência, ter os mesmos valores para Name, Sex, Birth_date e Relationship, mas, ainda assim, eles são entidades distintas. Eles são identificados como entidades distintas somente depois de determinar a entidade de funcionário em particular à qual cada dependente está relacionado. Por este motivo, a entidade Dependent é considerada uma entidade fraca, e o atributo Name é considerado como chave parcial. Essas entidades são relacionadas entre si por meio de seis relacionamentos: 1. O relacionamento Supervisao (Supervision) representa um auto-relacionamento que associa um funcionário a um supervisor, no qual as entidades funcionário e supervisor são membros do mesmo conjunto - entidade Funcionário (Employee). 2. O relacionamento Gerencia (Manages) relaciona uma entidade de departamento ao funcionário que gerencia esse departamento. Esse relacionamento possui o atributo Data_inicio (Start_date) que registra a data que um gerente começou a chefiar um departamento. 3. O relacionamento Trabalha_para (Works_for) associa cada funcionário ao departamento para o qual o funcionário trabalha. 4. O relacionamento Dependentes_de (Dependents_of ) representa um relacionamento identificador, uma vez que a entidade Dependente (Dependent) é fraca. Esse relacionamento associa um funcionário aos seus dependentes. 5. O relacionamento Trabalha_em (Works_on) associa cada funcionário ao projeto no qual ele trabalha. Tal relacionamento possui um atributo Horas (Hours) que registra o 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 departamento que controla esse projeto. B.3 Esquema Lógico Com base no esquema conceitual é possível criar um esquema lógico. A Figura B.2, também presente no Capítulo 3, apresenta o esquema lógico do banco de dados COMPANY. Tal figura apresenta as relações, seus atributos e as restrições de integridade referencial.

107 Apêndice B 106 Figura B.2: Esquema lógico do banco de dados COMPANY (retirado de [8]) Existem seis relações: 1. A relação Employee possui 10 atributos. O atributo Ssn representa a chave primária da relação, enquanto que o atributo Dno representa uma chave estrangeira para o atributo Dnumber da relação Department. 2. A relação Department possui 4 atributos. O atributo Dnumber representa a chave primária da relação, enquanto que o atributo Mgr_ssn representa uma chave estrangeira para o atributo Ssn da relação Employee. 3. A relação Dept_Locations possui 2 atributos, os quais formam uma chave primária composta. 4. A relação Project possui 4 atributos. O atributo Pnumber representa a chave primária da relação, enquanto o atributo Dnum representa uma chave estrangeira para o atributo Dnumber da relação Department. 5. A relação Works_on possui 3 atributos. Os atributos Essn e Pno formam uma chave primá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 estruturas físicas de armazenamento de dados, como o tipo e tamanho dos campos. É uma sequência de comandos executados em SQL para criar o banco de dados. O Código B.1 apresenta os comandos para criação do banco COMPANY usando o MySQL.