Um Método de Análise Semântica de Consultas com Palavras

U NIVERSIDADE F EDERAL DE G OIÁS
I NSTITUTO DE I NFORMÁTICA
M ARIANA S OLLER R AMADA
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
M ARIANA S OLLER R AMADA
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
M ARIANA S OLLER R AMADA
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
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.
Aos meus pais
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 e-mails, enviando-me seu material e sanando minhas inúmeras dúvidas; e ao
Adriano, Roussian, Douglas e Lucas, com vocês as pausas entre um parágrafo e outro 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.
“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
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, 2013. 107p. 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
Abstract
Ramada, Mariana Soller. An Analysis Semantic Method of Keyword Queries
over Multiple Databases. Goiânia, 2013. 107p. 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.
Sumário
Lista de Figuras
12
Lista de Tabelas
13
Lista de Algoritmos
15
Lista de Códigos de Programas
16
1
17
17
18
20
21
Introdução
1.1
1.2
1.3
1.4
Contexto e Motivação
Objetivos
Principais Problemas
Organização do Texto
2
Trabalhos Relacionados
22
3
Contexto e Arquitetura para o Método Proposto
26
26
30
31
32
33
34
34
35
36
37
38
38
3.1
3.2
Contexto
Arquitetura
3.2.1
Pré-processamento
Verificação de Função Agregada/Ordenação/Valores Compostos
Expansão da consulta
3.2.2
Processamento da consulta
Identificação dos bancos de dados relevantes
Ranking dos bancos de dados relevantes
Mapeamento
Execução
Ranking dos resultados
3.3
4
Considerações Finais
Análise Semântica da Consulta
4.1
4.2
Definição do problema
Análise Semântica segundo a Keymantic
4.2.1
Cálculo dos pesos intrínsecos (Passo 1)
Cálculo dos pesos intrínsecos dos termos de esquema do banco de dados
Cálculo dos pesos intrínsecos dos termos de valor do banco de dados
4.2.2
Seleção dos Melhores Mapeamentos para os termos de esquema (Passo 2)
Processo de Seleção dos Melhores Mapeamentos
39
39
41
43
44
44
46
47
4.2.3
Contextualização de VW e Seleção dos Melhores Mapeamentos para os
termos de valor (Passo 3)
Regras e Processo de Contextualização
4.3
5
Geração das Configurações (Passo 4)
4.2.5
Geração das Interpretações (Passo 5)
Consideração Finais
Contribuições à Analise Semântica
5.1
5.2
5.3
6
4.2.4
Limitações da Keymantic
Modificações à abordagem da Keymantic
Considerações Finais
Aplicação do Método Proposto
6.1
6.2
Estudos de Caso
6.1.1
Estudo de Caso - Funções Agregadas e Ordenação
6.1.2
Estudo de Caso - Valores Compostos
Comparação com a Keymantic
6.2.1
6.2.2
Suposições à implementação Keymantic
Exemplo selecionado para Comparação
Cálculo dos pesos intrínsecos (Passo 1)
Seleção dos Melhores Mapeamentos para os termos de esquema (Passo 2)
49
51
54
54
55
56
56
57
64
66
66
67
77
82
82
83
84
85
Contextualização de VW e Seleção dos Melhores Mapeamentos para os
termos de valor (Passo 3)
Geração das Configurações (Passo 4)
Geração das Interpretações (Passo 5)
Impacto das Modificações Internas à Keymantic
Ranking dos resultados
6.3
7
Considerações Finais
Conclusão
7.1
7.2
7.3
Contribuições
Trabalhos Futuros
Produção Bibliográfica
Referências Bibliográficas
87
88
89
89
91
93
94
94
96
97
98
A
Estrutura da Tabela de Metadados para Exposição (TME)
102
B
Banco de dados COMPANY
103
103
104
105
106
B.1
B.2
B.3
B.4
Requisitos de Dados em Forma Textual
Esquema Conceitual
Esquema Lógico
Esquema Físico
Lista de Figuras
3.1
3.2
Arquitetura do método proposto (inspirado em [28])
Banco de dados COMPANY (retirado de [8])
(a)
(b)
Esquema lógico do banco de dados COMPANY com suas restrições
de integridade referencial.
Fração dos dados do banco de dados COMPANY.
30
31
31
31
4.1
Mapeamento das palavras-chave (retirado de [3])
42
5.1
Processo de Mapeamento com as etapas modificadas em destaque
58
Número de configurações e interpretações geradas por ambos os sitemas
90
90
90
91
91
91
92
6.1
(a)
(b)
6.2
Número de configurações geradas por ambos os sistemas
Número interpretações geradas por ambos os sistemas
Métrica de precisão para ambos os sistemas
(a)
(b)
6.3
Gráfico MRR-Tamanho da consulta (inspirado em [10])
B.1
Diagrama de esquema ER para o banco de dados COMPANY (retirado
de [8])
Esquema lógico do banco de dados COMPANY (retirado de [8])
B.2
104
106
Lista de Tabelas
3.1
3.2
4.1
4.2
4.3
4.4
4.5
4.6
4.7
5.1
5.2
5.3
5.4
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
6.12
6.13
6.14
6.15
6.16
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])
28
35
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 4.4
Segunda matriz gerada a partir do mapeamento da Tabela 4.4
Terceira matriz gerada a partir do mapeamento da Tabela 4.4
43
44
46
47
49
49
49
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
61
62
62
64
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 6.3
Segundo mapeamento gerado a partir do mapeamento da Tabela 6.3
Terceiro mapeamento gerado a partir do mapeamento da Tabela 6.3
Primeiro mapeamento gerado a partir do mapeamento da Tabela 6.6
Segundo mapeamento gerado a partir do mapeamento da Tabela 6.6
Terceiro mapeamento gerado a partir do mapeamento da Tabela 6.6
Mapeamento gerado a partir do mapeamento da Tabela 6.9
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 6.14
Mapeamento para termos de valor (consulta “employees ‘Houston TX”’)
69
69
69
70
70
70
70
70
71
71
73
78
78
78
79
79
6.17
6.18
6.19
6.20
6.21
6.22
6.23
6.24
6.25
6.26
6.27
6.28
6.29
6.30
Mapeamento gerado a partir do mapeamento da Tabela 6.16
Mapeamento gerado após negativar os pesos iguais à 75
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
79
80
84
84
85
85
85
86
86
87
87
87
90
92
Lista de Algoritmos
4.1
4.2
4.3
5.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 4.1
45
49
53
59
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”
6.2 Código SQL da segunda configuração para a consulta “quantity employees for each department order by department”
6.3 Código SQL da quarta configuração para a consulta “quantity employees
for each department order by department”
6.4 Código SQL gerado para consulta “ employees ‘Houston Tx’ ”
A.1 Código SQL para a criação da Tabela de Metadados para Exposição
(TME) [20]
B.1 Esquema físico do banco de dados COMPANY
74
75
76
81
102
107
CAPÍTULO 1
Introdução
Este capítulo introdutório apresenta o problema a ser tratado neste trabalho,
elucidando a solução que será proposta e os desafios a serem superados. Na Seção 1.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.
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.
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.
1.3 Principais Problemas
1.3
20
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
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.
CAPÍTULO 2
Trabalhos Relacionados
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 Gs (V, E), onde cada relação Ri é representada como um nó
no grafo, e existe uma aresta Ri → R j para cada relacionamento entre chave primária
e chave estrangeira de Ri 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 Gd (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 0 ∈ V , uma subárvore T em G é uma
Steiner Tree de V 0 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 0 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.
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
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-
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.
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
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)
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
dc_title
dc_date
dc_relation
provider
dc_creator
dc_type
dc_coverage
url
dc_subject
dc_format
dc_rights
email
dc_description
dc_identifier
loginbd
oai_set
dc_contributor
dc_source
passwordbd
dispquery
dc_publisher
dc_language
-
Estes elementos armazenam as seguintes informações [20]:
• serial: utilizado para gerar uma sequência do repositório cadastrado;
• provider: utilizado para informar o endereço do provedor de dados do banco de
dados;
• url: utilizado para informar a url ou endereço do sítio vinculado ao banco de dados;
• email: utilizado para informar o endereço eletrônico do administrador do banco de
dados;
• oai_set: utilizado para informar a url do sítio ou endereço onde o sistema está
hospedado;
• dispquery: este campo é um flag que indica se o conteúdo do banco de dados está
disponível ou não para consulta na Web;
• dc_title: utilizado para apresentar o título do banco de dados;
• dc_creator: utilizado para informar o nome do autor ou entidade responsável pelo
recurso;
• dc_subject: na recomendação do Dublin Core, este campo deverá ser representado
pelo uso de palavras-chave, frases-chave ou código de classificação. O Dublin Core
recomenda ainda que a melhor prática é usar vocabulários controlados. É 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;
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
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.
3.2 Arquitetura
3.2.1
31
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])
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
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.
3.2 Arquitetura
3.2.2
34
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.
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
serial
provider
url
email
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
dc_login
dc_passwordbd
Informação
1
http://localhost/website/xyzsystem/database/oai
http://localhost/website/xyzsystem/
[email protected]
http://localhost/website/system/systemname
sim
COMPANY
Elmasri e Navathe
Department. Dependent. Location. Employee. Project. Management.
Salary. Working hours. Address.
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.
XYZ
ABC
2001-11-01
Database - MYSQL
SGBDR
bdcompany
DEF
Inglês
GHI
JKL
MNO
********
********
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.
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
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.
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 4.
3.3
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.
CAPÍTULO 4
Análise Semântica da Consulta
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(A1 , A2 , ... , An ), onde R é o nome da tabela e A1 , A2 ,
... , An são os atributos da tabela. O vocabulário do banco de dados D, denotado como VD ,
é o conjunto de todos os nomes de suas relações, atributos e o respectivos domínios 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. Cki denota a função de mapeamento aplicada a
palavra-chave ki [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
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 ∈ execD (q0 ) ∧ q0 ∈ I(q,D)}, onde execD (q0 )
denota a execução da consulta SQL q0 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
|D|
2×∑i=1 |Ri | + |D| diferentes configurações, com |Ri | denotando a aridade da relação Ri
e |D| o número de tabelas no banco de dados. Baseado nisso, e considerando que duas
palavras-chave não podem ser mapeadas para o mesmo termo do banco, para N palavrasD|!
configurações possíveis [4].
chave existem (|V|VD|−N)!
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.
4.2 Análise Semântica segundo a Keymantic
4.2
41
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-
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 4.2.2.
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
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])
R1
...
Rn
AR1
...
ARn11
...
ARnnn
AR1 1
...
ARn11
...
ARnnn
keyword1
keyword2
...
keywordk
de banco de dados j. A Tabela 4.1 exibe uma ilustração abstrata de uma matriz de peso
[4].
As colunas Ri e ARj i correspondem à relação Ri e o atributo A j de Ri , respectivamente, enquanto que uma coluna ARj i representa os valores que o atributo A j da relação
Ri 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).
Os detalhes das etapas individuais da Figura 4.1 são descritas nas subseções
seguintes.
4.2.1
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.
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])
employees
department
research
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
0
100
0
92
0
0
0
70
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Cálculo dos pesos intrínsecos dos termos de valor do banco de dados
Para computar os pesos intrínsecos para os termos de valor, a Keymantic explora
a informação a respeito do domínio do atributo e decide se uma palavra-chave pertence
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
3
4
5
6
7
8
9
SW ← [0, 0, ..., 0]
∑ ← {Synonyms(w,t), Hyponyms(w,t), Hypernyms(w,t),
StringSimilarity(w,t) . . .}
foreach w ∈ Q do
foreach e ∈ T do
sim ← 0;
foreach m ∈ ∑ do
if m(w,e) > sim then
sim ← m(w, e)
end
end
if ssim ≤ threshold then
sim ← 0;
12
13
end
end
SW [w, c] = ssim ∗ 100
16
end
O conceito de semantic relatedness SR(x, y) de dois termos x e y é definido
f (x),log f (y)}−log f (x,y)}
como: SR(x, y) = e−2NXD(x,y) , onde NXD(x, y) = {max{log
com f(x)
{log N−min{log f (x),log f (y)}}
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.
4.2 Análise Semântica segundo a Keymantic
46
Tabela 4.3: Pesos intrínsecos da Submatriz VW (inspirado em [4])
employees
department
research
4.2.2
D.Dna
D.Dnu
D.Mgr_ss
D.Mgr_st
1
1
1
0
0
0
1
1
1
0
0
0
E.Fn E.Mi E.Ln E.Ssn E.Bd E.Ad E.Sex E.Sa E.Su E.Dno
1
1
1
1
1
1
1
1
1
1
1
1
0
0
0
1
1
1
1
1
1
0
0
0
1
1
1
0
0
0
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 M1S , M2S , ..., MnS 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 MiS , 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 4.2.2. 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
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”
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
89*
0
0
0
100*
0
0
0
0
0
0
0
0
0
0
0
0
0
0
52
0
0
0
0
0
0
0
0
0
0
0
0
0
0
52
0
0
68
100*
3. Senão, se uma coluna contêm mais de um peso caracterizado como máximo,
todos os máximos da coluna, exceto aquele com maior valor, deixam de ser
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 4.2.3.
• 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
4.2 Análise Semântica segundo a Keymantic
49
Tabela 4.5: Primeira matriz gerada a partir do mapeamento da
Tabela 4.4
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
-100
0
0
0
100
0
0
0
0
0
0
0
0
0
0
0
0
0
0
52
0
0
0
0
0
0
0
0
0
0
0
0
0
0
52
0
0
68
100
Tabela 4.6: Segunda matriz gerada a partir do mapeamento da
Tabela 4.4
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
89
0
0
0
-100
0
0
0
0
0
0
0
0
0
0
0
0
0
0
52
0
0
0
0
0
0
0
0
0
0
0
0
0
0
52
0
0
68
100
Tabela 4.7: Terceira matriz gerada a partir do mapeamento da
Tabela 4.4
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
89
0
0
0
100
0
0
0
0
0
0
0
0
0
0
0
0
0
0
52
0
0
0
0
0
0
0
0
0
0
0
0
0
0
52
0
0
68
-100
de dados, dada uma matriz de pesos. A expressão HUNGARIANExt se refere à versão
estendida proposta pela Keymantic.
Algoritmo 4.2: Keyword to db term mapping selection (retirado de [4])
Input : I(ii j ) where I ≡ SW or I ≡ VW
Output: M I = {M1I , ..., MzI }: Mappings generated by I
Algoritmo: Mapping(I,WMAX )
2
3
4
5
6
8
9
10
11
tempM = i pt ← HUNGARIANExt ∗ (I)
W ← ∑ i pt
M I ← tempM
if W > c * WMAX then
WMAX ← W
S
end
while W > c * WMAX do
foreach i pt ∈ tempM do
i pt ∈ I ← −100
Mapping(I, WMAX )
end
end
4.2.3
Contextualização de VW e Seleção dos Melhores Mapeamentos
para os termos de valor (Passo 3)
Para cada mapeamento parcial MiS 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.
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 MiS .
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 4.2.3.
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 4.2.2. O resultado é uma série
V , com k = 1..m , onde i identifica o mapeamento M S que foi
de mapeamentos parciais Mik
i
i
considerado para atualizar a submatriz VWi .
Em resumo, dado um mapeamento parcial MiS , 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 MiS . 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
V , assim referenciados porque as palavras-chave já mapeadas para termos de
parcias Mik
V irá conter
esquema no mapeamento MiS não são consideradas, ou seja, o mapeamento Mik
apenas os mapeamentos das palavras-chave que não haviam sido mapeadas em MiS . O
V , formando
mapeamento total das palavras-chave da consulta é formado pelo par MiS , Mik
uma configuração. O processo de geração das configurações será descrito na Subseção
4.2.4.
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, MiS 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 MiS .
Definição 4.3 Free trailing keywords de uma palavra-chave k, denotado como T(k), é
o conjunto máximo k1 , k2 , ..., km , de palavras-chave consecutivas em K que estão na
consulta entre duas palavras-chave ks e ke , onde ks = k e MiS é definido para ks e ke , e
indefinido para cada ki com i = 1..m [4]. Ou seja, ks e ke são palavras-chave mapeadas
para termos de esquema em MiS , enquanto que cada ki permanece não mapeada.
Definição 4.4 Free preceding keywords de uma palavra-chave k, denotado como P(k),
é o conjunto máximo k1 , k2 , ..., km , de palavras-chave consecutivas em K que estão na
consulta entre duas palavras-chave ks e ke , onde ke = k e MiS é definido para ks e ke , e
indefinido para cada ki com i = 1..m [4].
Quando mais de um peso é caracterizado como máximo em uma mesma coluna,
todos os pesos são descaracterizados, exceto o maior. Desta forma, tem-se que 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.
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 MiS , 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
S
em Mi , é 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
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 [k0 , R.A] ← SW [k0 , 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
3
4
5
foreach k ∈ Q do
t ← x : ∃(k, x) ∈ M
if t = null then
continue
end
if t is a relation R then
foreach attribute A of R do
foreach k0 ∈ T (k) ∪ P(k) do
VW[k0 , R.A] ← VW [k0 , R.A] + ∆w
7
8
9
10
end
end
else if t is an attribute A of a relation R then
foreach attribute A0 of R with A’ 6= A do
foreach k0 ∈ T (k) ∪ P(k) do
VW[k0 , R.A] ← VW [k0 , R.A] + ∆w
13
14
15
16
end
end
foreach attribute A0 of R0 s.t. ∃ join path from A0 to A do
foreach k0 ∈ T(k) ∪ P(k) do
VW[k0 , R.A] ← VW[k0 , R.A] + ∆w
19
20
21
end
end
end
end
4.2 Análise Semântica segundo a Keymantic
4.2.4
54
Geração das Configurações (Passo 4)
Até este momento, durante o Passo 2 foi gerado uma série de mapeamentos
parciais MiS , que representam os mapeamentos para termos de esquema, e durante o Passo
V , que representam os mapeamentos
3 foi gerado uma série de mapeamentos parciais Mik
para termos de valor.
V , M S > é um mapeamento total das palavras-chave
Cada par de mapeamento <Mik
i
para os termos do banco de dados, formando uma configuração Cik . 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.
4.2.5
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.
4.3 Consideração Finais
4.3
55
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.
CAPÍTULO 5
Contribuições à Analise Semântica
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
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
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.
5.2 Modificações à abordagem da Keymantic
Algoritmo 5.1: Modificação do Algoritmo 4.1
Input : Q: Keyword Query
T: Schema Database Terms
Output: SW matrix
1
2
3
4
5
6
7
8
SW ← [0, 0, ..., 0]
∑ ← {Cosseno(w, e), Jaccard(w, e), Levenshtein(w, e)}
foreach w ∈ Q do
foreach e ∈ T do
sim ← 0;
media ← 0;
foreach m ∈ ∑ do
media ← media + m(w, e);
end
media ← media/3;
if media ≤ threshold then
S ← Synonyms(w);
max ← 0;
foreach s ∈ S do
media ← 0;
foreach m ∈ ∑ do
media ← media + m(s, e);
10
11
12
13
14
15
16
17
end
media ← media/3;
if media > max then
max ← media;
19
20
21
end
end
if max ≤ threshold then
sim ← 0;
24
25
else
sim ← max;
SW [w, e] = sim ∗ 90;
26
27
28
end
else
sim ← media;
SW [w, e] = sim ∗ 100;
30
31
32
end
end
end
59
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, 0.79. 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 0.67. Dessa forma, apenas o último par de strings possui similaridade acima do limiar,
em outras palavras, uma similaridade considerada alta, o que de fato é verdade.
Normalização de pesos para Submatriz VW
Utilizando a mesma idéia de normalização, a modificação aplicada à etapa 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.
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
employees
department
research
D
E
D.Dna
D.Dnu
D.Mgr_ss
D.Mgr_st
E.Fn
E.Mi
E.Ln
E.Ssn
E.Bd
E.Ad
0
100*
0
89*
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
51*
Como explicado na Subseção 4.2.2, após gerar o melhor mapeamento, os 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
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
employees
department
research
D
E
D.Dna
D.Dnu
D.Mgr_ss
D.Mgr_st
E.Fn
E.Mi
E.Ln
E.Ssn
E.Bd
E.Ad
0
100*
0
89*
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
-100
Tabela 5.3: Mapeamento parcial das palavras-chave para termos
de valor
employees
department
research
D.Dna
D.Dnu
D.Mgr_ss
D.Mgr_st
E.Fn
E.Mi
E.Ln
E.Ssn
E.Bd
E.Ad
0
0
11*
0
0
0
0
0
11
0
0
0
0
0
11
0
0
11
0
0
11
0
0
11
0
0
0
0
0
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 0.65. 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.
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.
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 k0 .
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
employees
department
research
5.3
D.Dna
D.Dnu
D.Mgr_ss
D.Mgr_st
E.Fn
E.Mi
E.Ln
E.Ssn
E.Bd
E.Ad
0
0
11*
0
0
0
0
0
11
0
0
0
0
0
6
0
0
6
0
0
6
0
0
6
0
0
0
0
0
6
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
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.
CAPÍTULO 6
Aplicação do Método Proposto
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.
6.1 Estudos de Caso
6.1.1
67
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.
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
6.1 Estudos de Caso
69
Tabela 6.1: Pesos intrínsecos da Submatriz SW (consulta “quantity
employees for each department order by name”)
employees
department
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
0
100
0
89
0
0
0
0
83
0
0
0
0
0
0
0
0
0
0
0
83
0
0
0
0
0
83
0
0
0
0
0
0
0
0
0
0
0
0
0
0
83
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”)
employees
department
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
65
65
65
0
0
0
65
65
65
0
0
0
65
65
65
65
65
65
65
65
65
65
65
65
0
0
0
65
65
65
65
65
65
65
65
65
0
0
0
65
65
65
Seleção dos Melhores Mapeamentos para os termos de esquema (Passo 2)
Nesse passo, o maior peso de cada linha é considerado como máximo. Caso 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”
employees
department
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
0
100*
0
89*
0
0
0
0
83*
0
0
0
0
0
0
0
0
0
0
0
83
0
0
0
0
0
83
0
0
0
0
0
0
0
0
0
0
0
0
0
0
83
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
6.1 Estudos de Caso
70
Tabela 6.4: Primeiro mapeamento gerado a partir do mapeamento
da Tabela 6.3
employees
department
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
0
100*
0
-100
0
0
0
0
83*
0
0
0
0
0
0
0
0
0
0
0
83
0
0
0
0
0
83
0
0
0
0
0
0
0
0
0
0
0
0
0
0
83
Tabela 6.5: Segundo mapeamento gerado a partir do mapeamento
da Tabela 6.3
employees
department
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
0
-100
0
89*
0
0
0
0
83*
0
0
0
0
0
0
0
0
0
0
0
83
0
0
0
0
0
83
0
0
0
0
0
0
0
0
0
0
0
0
0
0
83
Tabela 6.6: Terceiro mapeamento gerado a partir do mapeamento
da Tabela 6.3
employees
department
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
0
100*
0
89*
0
0
0
0
-100
0
0
0
0
0
0
0
0
0
0
0
83*
0
0
0
0
0
83
0
0
0
0
0
0
0
0
0
0
0
0
0
0
83
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
(272 ∗ 0.9 = 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
employees
department
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
0
100*
0
-100
0
0
0
0
-100
0
0
0
0
0
0
0
0
0
0
0
83*
0
0
0
0
0
83
0
0
0
0
0
0
0
0
0
0
0
0
0
0
83
Tabela 6.8: Segundo mapeamento gerado a partir do mapeamento
da Tabela 6.6
employees
department
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
0
-100
0
89*
0
0
0
0
-100
0
0
0
0
0
0
0
0
0
0
0
83*
0
0
0
0
0
83
0
0
0
0
0
0
0
0
0
0
0
0
0
0
83
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.
6.1 Estudos de Caso
71
Tabela 6.9: Terceiro mapeamento gerado a partir do mapeamento
da Tabela 6.6
employees
department
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
0
100*
0
89*
0
0
0
0
-100
0
0
0
0
0
0
0
0
0
0
0
-100
0
0
0
0
0
83*
0
0
0
0
0
0
0
0
0
0
0
0
0
0
83
Tabela 6.10: Mapeamento gerado a partir do mapeamento da Tabela 6.9
employees
department
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
0
100*
0
89*
0
0
0
0
-100
0
0
0
0
0
0
0
0
0
0
0
-100
0
0
0
0
0
-100
0
0
0
0
0
0
0
0
0
0
0
0
0
0
83*
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,
100 + 83 = 183. Ao gerar o segundo mapeamento, o valor 100 da segunda linha será
negativado e o mapeamento irá possuir pontuação 89 + 83 = 172. Ao gerar o terceito
mapeamento, o valor 83 da terceira linha será negativado resultando em uma pontuação
100 + 89 = 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 6.10.
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
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
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”
employees
department
department
Depa
0
100*
100
E
89*
0
0
Depe
0
67
67*
Dept
0
0
0
P
0
0
0
W
0
0
0
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.
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
16
17
18
/* Interpretação do caminho de junção entre
* 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.
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
16
17
18
/* Interpretação do caminho de junção entre
* 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
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
10
11
/* 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
20
21
/* 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
30
31
/* 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
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.
6.1.2
Estudo de Caso - Valores Compostos
No método proposto, valores que são compostos por mais de uma palavra-chave,
são apresentados entre aspas simples. No caso da consulta “ employees ‘Houston Tx’ ”,
o fato das palavras-chave Houston e Tx estarem entre aspas simples sugere que 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
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
0
0
89
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
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’ ”)
employees
‘Houston Tx’
D.Dna
D.Dnu
65
65
0
0
D.Mgr_ss E.Fn E.Mi E.Ln E.Ssn E.Bd E.Ad
65
65
65
65
65
65
65
65
65
65
0
0
65
65
E.Sex E.Su E.Dno P.Pl
65
65
65
65
0
0
W.Es
65
65
0
0
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 6.14.
Tabela 6.14: Mapeamento da consulta “employees ‘Houston Tx”’
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
0
0
89*
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
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
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 6.15.
Tabela 6.15: Submatriz VW contextualizada com base no mapeamento da Tabela 6.14
employees
‘Houston Tx’
D.Dna
D.Dnu
0
65
0
0
D.Mgr_ss E.Fn E.Mi E.Ln E.Ssn E.Bd E.Ad
0
65
0
75
0
75
0
75
0
75
0
0
0
75
E.Sex E.Su E.Dno P.Pl
0
75
0
75
0
0
0
65
W.Es
0
0
Durante o processo de contextualização é realizado um passo de inicialização,
onde os pesos referentes às linhas das palavras-chave já mapeadas são definidos 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
6.16.
Tabela 6.16: Mapeamento para termos de valor (consulta “employees ‘Houston TX”’)
employees
‘Houston Tx’
D.Dna
D.Dnu
0
65
0
0
D.Mgr_ss E.Fn E.Mi E.Ln E.Ssn E.Bd E.Ad
0
65
0
75*
0
75
0
75
0
75
0
0
0
75
E.Sex E.Su E.Dno P.Pl
0
75
0
75
0
0
0
65
W.Es
0
0
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
employees
‘Houston Tx’
D.Dna
D.Dnu
0
65
0
0
D.Mgr_ss E.Fn
0
65
0
-100
E.Mi E.Ln E.Ssn E.Bd E.Ad
E.Sex E.Su E.Dno P.Pl
0
75*
0
75
0
75
0
75
0
0
0
75
0
75
0
0
0
65
W.Es
0
0
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 (75 ∗ 0.9 = 67 > 65), sendo então desconsiderado e encerrado o algoritmo de seleção de mapeamento.
6.1 Estudos de Caso
80
Tabela 6.18: Mapeamento gerado após negativar os pesos iguais
à 75
employees
‘Houston Tx’
D.Dna
D.Dnu
0
65
0
0
D.Mgr_ss E.Fn
0
65
0
-100
E.Mi
E.Ln
E.Ssn
0
-100
0
-100
0
-100
E.Bd E.Ad
0
0
0
-100
E.Sex
E.Su
0
-100
0
-100
E.Dno P.Pl
0
0
0
65
W.Es
0
0
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.
6.1 Estudos de Caso
81
Código 6.4 Código SQL gerado para consulta “ employees ‘Houston Tx’ ”
1
2
3
4
5
select distinct employee.minit, employee.lname, employee.ssn,
employee.bdate, employee.address, employee.sex, employee.salary,
employee.super_ssn, employee.dno
from employee
where employee.fname like ’%houston%’ AND employee.fname like ’%tx%’
6
7
8
9
10
11
select distinct employee.fname, employee.lname, employee.ssn,
employee.bdate, employee.address, employee.sex, employee.salary,
employee.super_ssn, employee.dno
from employee
where employee.minit like ’%houston%’ AND employee.minit like ’%tx%’
12
13
14
15
16
17
select distinct employee.fname, employee.minit, employee.ssn,
employee.bdate, employee.address, employee.sex, employee.salary,
employee.super_ssn, employee.dno
from employee
where employee.lname like ’%houston%’ AND employee.lname like ’%tx%’
18
19
20
21
22
23
select distinct employee.fname, employee.minit, employee.lname,
employee.bdate, employee.address, employee.sex, employee.salary,
employee.super_ssn, employee.dno
from employee
where employee.ssn like ’%houston%’ AND employee.ssn like ’%tx%’
24
25
26
27
28
29
select distinct employee.fname, employee.minit, employee.lname,
employee.ssn, employee.bdate, employee.sex, employee.salary,
employee.super_ssn, employee.dno
from employee
where employee.address like ’%houston%’ AND employee.address like ’%tx%’
30
31
32
33
34
35
select distinct employee.fname, employee.minit, employee.lname,
employee.ssn, employee.bdate, employee.address, employee.salary,
employee.super_ssn, employee.dno
from employee
where employee.sex like ’%houston%’ AND employee.sex like ’%tx%’
36
37
38
39
40
41
select distinct employee.fname, employee.minit, employee.lname,
employee.ssn, employee.bdate, employee.address, employee.sex,
employee.salary, employee.dno
from employee
where employee.super_ssn like ’%houston%’ AND employee.super_ssn like ’%tx%’
6.2 Comparação com a Keymantic
82
Ranking do resultados
Cada uma dessas interpretações é executada e os seus resultados retornados 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.
6.2.1
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.
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.
6.2.2
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
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
employees
department
research
Depa
E
Depe
Dept
D.Dna
D.Dnu
E.Fn
E.Mi
E.Ln
E.Ad
Depe.De
P.Pn
0
100
0
89
0
0
0
67
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
66
0
0
0
0
Tabela 6.20: Pesos intrínsecos da Submatriz SW calculados pela
Keymantic
employees
department
research
Depa
E
Depe
Dept
D.Dna
D.Dnu
E.Fn
E.Mi
E.Ln
E.Ad
Depe.De
P.Pn
0
100
0
94
0
0
0
81
0
0
67
0
0
70
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
77
0
0
70
0
Como se pode notar, os pesos de ambas tabelas não são iguais. Isso se deve à
modificação realizada na etapa de Cálculo dos pesos intrínsecos para termos de esquema.
No MP, os pesos são calculados com base na média dos valores retornados pelas mé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
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 6.22.
Tabela 6.21: Pesos intrínsecos da Submatriz VW calculados pelo
MP
Depa.Dna Depa.Dnu Depa.Mgr_ssE.Fn
employees
department
research
65
65
65
0
0
0
65
65
65
65
65
65
E.Mi E.Ln E.Ssn E.Bd E.Ad E.Sex E.Su
65
65
65
65
65
65
65
65
65
0
0
0
65
65
65
65
65
65
65
65
65
Depe.Es
65
65
65
Depe.De
Depe.Se
65
65
65
65
65
65
Depe.Re
65
65
65
Tabela 6.22: Pesos intrínsecos da Submatriz VW calculados pela
Keymantic
Depa.Dna Depa.Dnu Depa.Mgr_ssE.Fn
employees
department
research
1
1
1
0
0
0
1
1
1
1
1
1
E.Mi E.Ln E.Ssn E.Bd E.Ad E.Sex E.Su
1
1
1
1
1
1
1
1
1
0
0
0
1
1
1
1
1
1
1
1
1
Depe.Es
1
1
1
Depe.De
Depe.Se
1
1
1
1
1
1
Depe.Re
1
1
1
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
employees
department
research
Depa
E
Depe
Dept
D.Dna
D.Dnu
E.Fn
E.Mi
E.Ln
E.Ad
Depe.De
P.Pn
0
100*
0
89*
0
0
0
67
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
66
0
0
0
0
6.2 Comparação com a Keymantic
86
Tabela 6.24: Mapeamento gerado pela Keymantic
employees
department
research
Depa
E
Depe
Dept
D.Dna
D.Dnu
E.Fn
E.Mi
E.Ln
E.Ad
Depe.De
P.Pn
0
100*
0
94*
0
0
0
81
0
0
67
0
0
70
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
77
0
0
70
0
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 (189 ∗ 0.9 = 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 (194 ∗ 0.9 = 174). Este
mapeamento é apresentado na Tabela 6.25. 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)
employees
department
research
Depa
E
Depe
Dept
D.Dna
D.Dnu
E.Fn
E.Mi
E.Ln
E.Ad
Depe.De
P.Pn
0
-100
0
94*
0
0
0
81*
0
0
67
0
0
70
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
77
0
0
70
0
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
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
employees
department
research
0
0
75
0
0
0
0
0
75
0
0
70
E.Mi E.Ln E.Ssn E.Bd E.Ad E.Sex E.Su
0
0
70
0
0
70
0
0
70
0
0
0
0
0
70
0
0
70
0
0
70
Depe.Es
0
0
65
Depe.De
0
0
65
Depe.Se
0
0
65
Depe.Re
0
0
65
Tabela 6.27: Submatriz VW contextualizada com base no mapeamento da Tabela 6.24 (Keymantic)
Depa.Dna Depa.Dnu Depa.Mgr_ssE.Fn
employees
department
research
0
0
11
0
0
0
0
0
11
0
0
11
E.Mi E.Ln E.Ssn E.Bd E.Ad E.Sex E.Su
0
0
11
0
0
11
0
0
11
0
0
0
0
0
11
0
0
11
0
0
11
Depe.Es
0
0
1
Depe.De
0
0
1
Depe.Se
0
0
1
Depe.Re
0
0
1
Tabela 6.28: Submatriz VW contextualizada com base no mapeamento da Tabela 6.25 (Keymantic)
Depa.Dna Depa.Dnu Depa.Mgr_ssE.Fn
employees
department
research
0
0
1
0
0
0
0
0
1
0
0
11
E.Mi E.Ln E.Ssn E.Bd E.Ad E.Sex E.Su
0
0
11
0
0
11
0
0
11
0
0
0
0
0
11
0
0
11
0
0
11
Depe.Es
0
0
11
Depe.De
0
0
11
Depe.Se
0
0
11
Depe.Re
0
0
11
Considere as tabelas 6.26 e 6.27. 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
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 (75 ∗ 0.9 = 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 89+100+75 = 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 89+100+70 = 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 94 + 100 + 11 = 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 94 + 81 + 11 = 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.
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 9 ∗ 3 + 11 ∗ 1 = 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 6.29.
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 6.29. 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
6.2 Comparação com a Keymantic
90
Tabela 6.29: Conjunto de consultas com palavras-chave
1
2
3
4
Consulta com palavras-chave
department
department employee
department project
department project newbenefits
5
6
location project productx
employee dependent daughter
7
8
9
project name employee John
employee address project 1
hours employee works project productz
10
project location employee salary 30000
Semântica pretendida
lista de informações sobre os departamentos da empresa
lista de empregados de cada departamento
lista de projetos de cada departamento
informações do departamento responsável pelo projeto
Newbenefits
localização do projeto cujo nome é ProductX
informações dos empregados que tem filha como dependente
nome do projeto no qual o empregado John trabalha
endereço do empregado que trabalha no projeto 1
quantidade de horas trabalhadas por cada empregado
do projeto ProductZ
localização do projeto no qual trabalha o empregado
cujo o salário é 30000
redução possui impacto importante no custo do processo, e possibilita ao usuário 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,
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
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
department
number
location
Depa
Depe
Dept
Depa.Dnu
Dept.Dnu
Dept.Dlo
100*
0
66
81
0
0
67
0
76
0
85*
0
0
85
0
0
0
88*
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 81 + 85 + 88 = 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 100 + 85 + 88 = 273.
E o terceiro e último mapeamento é gerado negativando o valor 88 da terceira linha e
escolhendo o valor 76, resultando na pontuação 100 + 85 + 76 = 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])
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.
CAPÍTULO 7
Conclusão
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
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.
7.2 Trabalhos Futuros
7.2
96
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
7.3 Produção Bibliográfica
•
•
•
•
7.3
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.
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.
Referências Bibliográficas
[1] A DITYA , B.; B HALOTIA , G.; C HAKRABARTI , S.; H ULGERI , A.; N AKHE , C.; PARAG .;
S UDARSHANXE , 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. 1083 – 1086. Morgan Kaufmann, San Francisco, 2002.
[2] AGRAWAL , S.; C HAUDHURI , S.; DAS , G. Dbxplorer: a system for keyword-based
search over relational databases. In: Data Engineering, 2002. Proceedings. 18th
International Conference on, p. 5 –16, 2002.
[3] B ERGAMASCHI , S.; D OMNORI , E.; G UERRA , F.; O RSINI , M.; L ADO, R. T.; V ELE GRAKIS ,
Y. Keymantic: semantic keyword-based searching in data integration
systems. Proc. VLDB Endow., 3:1637–1640, September 2010.
[4] B ERGAMASCHI , S.; D OMNORI , E.; G UERRA , F.; T RILLO L ADO, R.; V ELEGRAKIS , 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. 565–576, New York, NY, USA, 2011. ACM.
[5] B ERGMAN , M. K. The deep web: Surfacing hidden value, 2000.
[6] C OFFMAN , J.; W EAVER , A. An empirical performance evaluation of relational
keyword search techniques. Knowledge and Data Engineering, IEEE Transactions
on, PP(99):1, 2012.
[7] C OFFMAN , J.; W EAVER , A. C. A framework for evaluating database keyword
search strategies. In: Proceedings of the 19th ACM international conference on
Information and knowledge management, CIKM ’10, p. 729–738, New York, NY, USA,
2010. ACM.
[8] E LMASRI , R.; N AVATHE , S. B. Fundamentals of Database Systems (6th Edition).
Addison-Wesley, 2011.
Referências Bibliográficas
99
[9] FAKHRAEE , S.; F OTOUHI , F. Effective keyword search over relational databases
considering keywords proximity and keywords n-grams. In: Database and Expert
Systems Applications (DEXA), 2011 22nd International Workshop on, p. 190 –194,
29 2011-sept. 2 2011.
[10] FAKHRAEE , S.; F OTOUHI , F. Dbsemsxplorer: semantic-based keyword search
system over relational databases for knowledge discovery. In: Proceedings of
the Third International Workshop on Keyword Search on Structured Data, KEYS ’12,
p. 54–62, New York, NY, USA, 2012. ACM.
[11] F OUNDATION , A. W. M. Dublin core metadata initiative. Disponível em: http:
//dublincore.org/. Acesso em: 21 fev. 2013.
[12] F OUNDATION , A. W. M. Open archives initiative. Disponível em: http://www.
openarchives.org/. Acesso em: 21 fev. 2013.
[13] G ANTI , V.; H E , Y.; X IN , D. Keyword++: a framework to improve keyword search
over entity databases. Proc. VLDB Endow., 3:711–722, September 2010.
[14] G U, J.; K ITAGAWA , H.
Extending keyword search to metadata on relational
databases. In: Information-Explosion and Next Generation Search, 2008. INGS ’08.
International Workshop on, p. 97 –103, april 2008.
[15] H ASSAN , M.; A LHAJJ, R.; R IDLEY, M. J.; B ARKER , K.
Simplified access to
structured databases by adapting keyword search and database selection. In:
Proceedings of the 2004 ACM symposium on Applied computing, SAC ’04, p. 674–
678, New York, NY, USA, 2004. ACM.
[16] H RISTIDIS , V.; G RAVANO, 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. 850–861. VLDB Endowment,
2003.
[17] H RISTIDIS , V.; PAPAKONSTANTINOU, Y. Discover: Keyword search in relational
databases. In: Bernstein, P. A.; Ioannidis, Y. E.; Ramakrishnan, R.; Papadias, D.,
editors, VLDB ’02: Proceedings of the 28th International Conference on Very Large
Databases, p. 670 – 681. Morgan Kaufmann, San Francisco, 2002.
[18] KONG , Z.; Z HANG , K. Summarizing keyword search in relational database. In:
Intelligent Human-Machine Systems and Cybernetics (IHMSC), 2011 International
Conference on, volume 2, p. 152 –155, aug. 2011.
Referências Bibliográficas
100
[19] KOUTRIKA , G.; Z ADEH , Z. M.; G ARCIA -M OLINA , 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. 391–402, New York, NY, USA, 2009. ACM.
[20] KOWATA , E. T. Metadados de bancos de dados relacionais: Extração e exposição com o protrocolo OAI-PMH. Dissertação de mestrado, Instituto de Informática,
UFG, Goiânia, 2011.
[21] L I , F.-Z.; L UO, D.; X IE , D. Fuzzy search on non-numeric attributes of keyword
query over relational databases. In: Computer Science Education, 2009. ICCSE
’09. 4th International Conference on, p. 811 –814, july 2009.
[22] L I , G.; F ENG , J.; Z HOU, X.; WANG , J. Providing built-in keyword search capabilities in rdbms. The VLDB Journal, 20:1–19, 2011.
[23] L I , G.; J I , S.; L I , C.; F ENG , J. Efficient type-ahead search on relational data:
a tastier approach.
In: Proceedings of the 2009 ACM SIGMOD International
Conference on Management of data, SIGMOD ’09, p. 695–706, New York, NY, USA,
2009. ACM.
[24] L IU, F.; Y U, C.; M ENG , W.; C HOWDHURY, A. Effective keyword search in relational
databases. In: Proceedings of the 2006 ACM SIGMOD international conference on
Management of data, SIGMOD ’06, p. 563–574, New York, NY, USA, 2006. ACM.
[25] L UO, Y.; WANG , W.; L IN , X. Spark: A keyword search engine on relational databases. In: Data Engineering, 2008. ICDE 2008. IEEE 24th International Conference
on, p. 1552 –1555, april 2008.
[26] M ORO, M. M. Entrevista com John E. Hopcroft. SBC Horizontes, 4(1):24–27, Apr.
2011.
[27] P ENG , Z.; Z HANG , J.; WANG , S.; WANG , C. Bring user feedback into keyword
search over databases. In: Web Information Systems and Applications Conference,
2009. WISA 2009. Sixth, p. 210 –214, sept. 2009.
[28] P U, K.; Y U, X. Frisk: Keyword query cleaning and processing in action. In: Data
Engineering, 2009. ICDE ’09. IEEE 25th International Conference on, p. 1531 –1534,
29 2009-april 2 2009.
[29] R AMADA , M. S.; F ILGUEIRAS , A. C.; S ILVA , 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.
Referências Bibliográficas
101
[30] S AYYADIAN , M.; L E K HAC, H.; D OAN , A.; G RAVANO, L. Efficient keyword search
across heterogeneous relational databases. In: Data Engineering, 2007. ICDE
2007. IEEE 23rd International Conference on, p. 346 –355, april 2007.
[31] WANG , S.; Z HANG , K.-L.
Searching databases with keywords.
Journal of
Computer Science and Technology, 20:55–62, 2005.
[32] WANG , W.; L IN , X.; L UO, Y. Keyword search on relational databases. In: Network
and Parallel Computing Workshops, 2007. NPC Workshops. IFIP International Conference on, p. 7 –10, sept. 2007.
[33] W IKIPÉDIA , A . E . L . Deep web, 2013. Disponível em: http://pt.wikipedia.org/
w/index.php?title=Deep_web&oldid=35666350. Acesso em: 7 maio 2013.
[34] Y U, B.; L I , G.; S OLLINS , K.; T UNG , A. K. H. Effective keyword-based selection
of relational databases. In: Proceedings of the 2007 ACM SIGMOD international
conference on Management of data, SIGMOD ’07, p. 139–150, New York, NY, USA,
2007. ACM.
APÊNDICE A
Estrutura da Tabela de Metadados para
Exposição (TME)
O Código A.1 apresenta a estrutura da tabela TME.
Código A.1 Código SQL para a criação da Tabela de Metadados para Exposição (TME) [20]
1
2
3
--- Estrutura da Tabela de Metadados para Exposição
--
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
CREATE TABLE IF NOT EXISTS TME (
serial int(11) NOT NULL AUTO_INCREMENT,
provider varchar(255) DEFAULT NULL,
url varchar(255) DEFAULT NULL,
email varchar(255) DEFAULT NULL,
oai_set varchar(255) DEFAULT NULL,
dispquery enum(’false’,’true’) NOT NULL
COMMENT ’Disponível para consulta externa’,
dc_title varchar(255) DEFAULT NULL,
dc_creator text,
dc_subject varchar(255) DEFAULT NULL,
dc_description text,
dc_contributor varchar(255) DEFAULT NULL,
dc_publisher varchar(255) DEFAULT NULL,
dc_date date DEFAULT NULL,
dc_type varchar(255) DEFAULT NULL,
dc_format varchar(255) DEFAULT NULL,
dc_identifier varchar(255) DEFAULT NULL,
dc_source varchar(255) DEFAULT NULL,
dc_language varchar(255) DEFAULT NULL,
dc_relation varchar(255) DEFAULT NULL,
dc_coverage varchar(255) DEFAULT NULL,
dc_rights varchar(255) DEFAULT NULL,
loginbd varchar(15) NOT NULL
COMMENT ’Login do banco de dados’,
passwordbd varchar(15) NOT NULL
COMMENT ’Senha de acesso ao banco de dados’,
PRIMARY KEY (serial)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1;
APÊNDICE B
Banco de dados COMPANY
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.
Apêndice B
B.2
104
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 COMPANY 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.
Apêndice B
105
3. A entidade Projeto (Project) possui os atributos Nome (Name), Numero (Number)
e Localizacao (Location). Tanto (Name) como (Number) são atributos-chave (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.
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.
Apêndice B
107
Código B.1 Esquema físico do banco de dados COMPANY
1
2
create database COMPANY;
use COMPANY;
3
4
5
6
7
8
9
10
11
12
13
14
15
16
create table employee (
fname varchar(20) not null,
minit char(1) not null,
lname varchar(20) not null,
ssn char(9) not null,
bdate date not null,
address varchar(40) not null,
sex char(1) not null,
salary numeric(20,2) not null,
super_ssn char(9),
dno int not null,
primary key (ssn),
foreign key (super_ssn) references employee(ssn));
17
18
19
20
21
22
23
24
25
create table department (
dname varchar(20) not null,
dnumber int not null,
mgr_ssn char(9) not null,
mgr_start_date date not null,
primary key (dnumber),
unique(dname),
foreign key (mgr_ssn) references employee(ssn));
26
27
28
29
30
31
32
create table dept_locations (
dnumber int not null,
dlocation varchar(20) not null,
primary key ( dnumber, dlocation ),
foreign key(dnumber) references department (dnumber));
33
34
35
36
37
38
39
40
41
create table project (
pname varchar(20) not null,
pnumber int not null,
plocation varchar(20) not null,
dnum int not null,
primary key (pnumber),
unique (pname),
foreign key (dnum) references department (dnumber));
42
43
44
45
46
47
48
49
create table works_on (
essn char(9) not null,
pno int not null,
hours numeric(3,1),
primary key(essn,pno),
foreign key (essn) references employee (ssn),
foreign key (pno) references project(pnumber));
50
51
52
53
54
55
56
57
58
create table dependent (
essn char(9) not null,
dependent_name varchar(20) not null,
sex char(1) not null,
bdate date not null,
relationship varchar(15) not null,
primary key(essn, dependent_name),
foreign key (essn) references employee (ssn));