IEEE LATIN AMERICA TRANSACTIONS, VOL. 4, NO. 4, JUNE 2006
279
Uma Ferramenta para a Definição de Consultas
Baseada em Entidades e Papéis
S. N. Alves de Souza; E. G. Lino de Campos; A. R. D. Dos Santos
Universidade de São Paulo – USP, Escola Politécnica - Departamento de Engenharia de Computação e
Sistemas Digitais, São Paulo-SP-Brasil.
Resumo-- Para acessar aos dados armazenados num banco de
dados relacional usuários precisam conhecer linguagens de
consulta como a SQL e os conceitos envolvidos (entidades,
relacionamentos, atributos), além do esquema de dados que
descreve os elementos do domínio. Todavia, usuários leigos, não
familiarizados com linguagens de consulta e estruturas de banco
de dados, deveriam poder acessar os dados de uma forma mais
amigável. O objetivo deste artigo é apresentar uma ferramenta
que permita que usuários leigos construam suas consultas,
utilizando uma linguagem próxima à linguagem natural.
Palavras chave - bancos de dados, linguagens de consulta,
interface amigável, formulação de consultas.
I.
INTRODUÇÃO
Quando se aborda a questão de linguagens de consulta para
bancos de dados é importante ter em mente as diferentes
categorias de usuários que precisariam utilizá-la para acessar a
informação armazenada. Neste contexto, é possível dividir os
usuários em: (1) usuários especialistas (administradores de
banco de dados), (2) usuários experientes (profissionais de
computação que desenvolvem produtos de software ou
acessam diretamente o banco via linguagem de consulta), (3)
desenvolvedores de aplicativos (que acessam o banco de
dados via interfaces de programas previamente definidas), e
(4) usuários leigos (profissionais que precisam acessar
informações armazenadas, porém não têm conhecimento sobre
linguagens de acesso e modelos ou esquemas dos dados).
Todas as categorias apresentadas são importantes e devem ser
consideradas, porém, quando o objetivo é a definição de uma
linguagem de acesso para leigos, a facilidade de uso é um
fator de destaque. Tais usuários deveriam poder extrair
informações sem a necessidade de conhecer particularidades
de um modelo de dados ou de estruturas de armazenamento.
Uma linguagem de consulta como a SQL (Structured
Query Language), apesar de amigável, não atende aos
requisitos para usuários leigos. Para que possa ser utilizada, a
SQL exige de seus usuários conhecimento não só das
informações armazenadas no banco, mas também de detalhes
mais específicos associados à estrutura de armazenamento e
de conceitos de modelos de dados. Este conhecimento impede,
ou pelo menos dificulta muito uma utilização direta mais
abrangente do banco de dados por parte de leigos, que sentem
dificuldades ou não têm interesse nem necessidade de
conhecer detalhes específicos de um modelo de dados ou de
uma linguagem em particular.
A necessidade de criar uma linguagem de consulta para tal
finalidade originou pesquisas e propostas de novas linguagens
para acesso a banco de dados, tais como QMF [1]. Observa-se
porém, que estas linguagens dão ênfase a capacidade
funcional, assemelhando-se à SQL, ou são restritivas quanto
ao número de funções, pois dão ênfase a facilidade de uso, o
que limita as consultas possíveis [2]. No caso de linguagens
similares a SQL, é necessário estar familiarizado com
conceitos como entidades, relacionamentos, atributos, dentre
outros [3,4,5,6,7,8]. No outro caso, (QBE - Query-ByExample [8]), apesar de ser relativamente fácil de ser
utilizado, pode trazer alguma dificuldade para usuários leigos,
pois esses precisam além de conhecer o esquema de banco de
dados existente, ter de manipular caracteres especiais não
óbvios como “_x” ou “”. O emprego desses caracteres
dificulta a compreensão e formulação da consulta,
principalmente quando a consulta envolve mais de uma tabela.
Seria interessante, tendo em vista usuários leigos, que fosse
possível o acesso às informações sem a necessidade do
conhecimento prévio do esquema existente e, principalmente,
que fosse possível exprimir as consultas usando uma
linguagem próxima à natural, sem a necessidade de uso de
caracteres especiais.
Tendo em vista os problemas acima, neste artigo apresentase uma linguagem de consulta, próxima à linguagem natural,
com a qual usuários leigos podem extrair informações de
interesse; é apresentada, também, a ferramenta que a
implementa e permite a formulação de consultas e a produção
de resultados de forma interativa. Na concepção dessa
ferramenta deu-se prioridade à usabilidade. Assim, diversas
funcionalidades não foram implementadas, mas é possível
uma variedade de tipos de consultas, sendo sua formulação
mais natural ao usuário.
A organização deste artigo tem o seguinte formato: o item
II mostra a proposta geral da ferramenta e a forma de
interação sob a perspectiva do usuário; o item III apresenta a
arquitetura da ferramenta e aspectos de sua implementação;
finalmente, o item IV apresenta a conclusão do trabalho e
comentários sobre a utilização da ferramenta.
280
IEEE LATIN AMERICA TRANSACTIONS, VOL. 4, NO. 4, JUNE 2006
II.
PONTO DE VISTA DO USUÁRIO
Neste item, a palavra usuário será empregada no lugar de
usuário leigo.
A linguagem proposta é baseada na língua portuguesa, mas
pode ser facilmente traduzida para outros idiomas como o
inglês por exemplo. A idéia é que o usuário utilize a
ferramenta da forma mais natural possível, sendo conduzido,
passo a passo, na formulação da consulta até que defina a
consulta completa. A cada passo, a ferramenta apresenta um
conjunto de palavras ou frases, uma das quais o usuário
escolhe como parte da consulta. O processo é interativo e
prossegue até a consulta estar completa e submetida para
execução.
A.
Utilização da Ferramenta
O esquema Entidade-Relacionamento (E-R) da Figura 1,
referente ao contexto de uma aplicação exemplo, registra
informações sobre empresas e seus empregados, clientes,
fornecedores e seus respectivos fornecimentos.
Nesse
esquema, para não poluir o desenho, mostra-se o nome de
alguns dos papéis que entidades assumem no relacionamento
com outras entidades. A definição de papéis é útil para
melhor compreensão da ferramenta proposta.
F o rn e c e d o r
fo rn e c e
n
F o rn e c im e n to
n
E m p re s a
é c o n tra ta d a
por
n
C lie n te
1
n
C o n tra ta
T ra b a lh a
é a te n d id o
n
A te n d e
Fig. 2. Janela inicial
n
1
D e p e n d e n te
é ch efe
F u n c io n á rio
n
Tem
é
d e p e n d e n te
1
1
n
C h e fia
é
s u b o rd in a d o
Fig. 1. Esquema ER do exemplo
A Figura 2 mostra a janela inicial usada pelo usuário para a
formulação de consultas ao banco de dados. No lado direito e
inferior da janela, um conjunto de palavras, relativas ao
esquema do banco de dados, é apresentada ao usuário.
Ainda em relação à Figura 2, no lado esquerdo inferior da
janela, aparecem duas palavras-chaves: Qual(is) e Quanto(s),
que dão ao usuário informação sobre quais categorias de
consulta poderão ser definidas. Na parte superior da janela
(pergunta escolhida), a consulta que está sendo formulada é
apresentada, como uma forma de feedback ao usuário. Para
prosseguir, os botões voltar, avançar e executar (parte
superior da janela) devem ser utilizados. O botão avançar
conduz a uma nova janela (Figura 3).
Fig. 3. Segunda janela
Na Figura 3, na parte inferior (próximas opções para a
pergunta), um novo conjunto de palavras é listado para
escolha pelo usuário. Tais palavras são usadas para a
especificação do predicado que exprime uma condição.
Novamente, a pressão sobre o botão avançar dá
prosseguimento à definição da consulta, apresentando novas
palavras, neste caso, operadores de comparação, uma das
quais deve ser escolhida. E assim, passo a passo, o usuário
prossegue até que considere que a formulação da consulta
esteja finalizada. Neste ponto ele poderá pedir a execução da
consulta (botão executar), sendo que o resultado será
apresentado numa nova janela. Para melhor compreensão,
tendo em vista o esquema da figura 1, suponha-se a seguinte
consulta:
Quais empregados ganham salário acima de 2000 e
DE SOUZA et al.: A TOOL FOR QUERY FORMULATION
281
trabalham para a companhia Corporation S.A.?
Para formular tal consulta, o usuário iniciaria escolhendo a
opção Qual(is) e a seguir funcionário (figura 2). Após a
pressão do botão avançar, uma nova janela (figura 3), com
novas opções, é apresentada. Na parte superior desta (figura 3)
aparece à consulta que está sendo definida. O usuário então,
para o nosso exemplo, escolheria tem salário na parte inferior
da janela.
A figura 4 (a) e (b) mostra a continuidade da consulta, onde
o usuário escolheria o operador de comparação (maior que), e
na seqüência, forneceria o valor requerido para comparação
(no exemplo, 2000). O usuário continuaria fazendo, a cada
passo, a escolha apropriada à sua consulta e ao considerá-la
finalizada, pressionaria o botão executar, quando uma nova
janela, com o resultado, seria apresentada (figura 5).
(a)
Fig. 5. Resultado da consulta exemplo
Ainda em relação à figura 5, pode-se observar, na parte
superior da janela, um conjunto de botões correspondentes a
outras funcionalidades. Tais botões permitem ao usuário ir de
um registro a o outro (primeiro, anterior, próximo, último),
localizar um dado específico (localiza), usar um filtro
específico (filtra), ordenar o resultado por determinadas
colunas (ordena), definir quais colunas devem ser vistas ou
não no resultado (visão), ou ainda, exportar e imprimir dados
(exporta, imprime).
III.
ARQUITETURA DA FERRAMENTA
A ferramenta baseia-se no conceito de que os papéis
exercidos pelas entidades nos relacionamentos são “cidadãos
de primeira classe”, e criam os caminhos de navegação entre
as entidades, viabilizando a realização da inferência.
Assim sendo, idealizou-se a ferramenta com base em três
módulos (figura 6): interface para criação de consultas
(definição da consulta de forma interativa); conversor de
consultas para SQL (mapeamento da consulta de português
estruturado para uma sentença SQL válida); e apresentador
de resultados, que mostra o resultado da consulta e permite
sua manipulação através de várias funcionalidades que são
disponibilizadas neste módulo.
O módulo interface para criação de consulta é detalhado
a seguir. Apresenta-se também alguns detalhes do módulo
conversor de consultas para SQL.
(b)
Fig. 6. Módulos da ferramenta
Fig. 4. Terceira Janela
Para o exemplo dado, como apenas dois empregados que
trabalham para a companhia “Corporation S.A.” ganham
acima de 2000, somente dois registros apareceriam como
resultado (figura 5).
É importante destacar que a ferramenta não é um
interpretador da linguagem natural. Na interface para
criação de consulta, o usuário é levado a criar uma questão
em português estruturado. Assim, o conversor de consultas
para SQL consiste em um tradutor (parser), que converte a
sentença de português estruturado para a linguagem SQL.
282
IEEE LATIN AMERICA TRANSACTIONS, VOL. 4, NO. 4, JUNE 2006
A.
Interface para Criação de Consulta
Para a criação da consulta estruturada, duas questões
precisaram ser solucionadas:
perda de informação semântica e
utilização de papéis para a descrição de relacionamentos.
1)
Perda de informação semântica
O esquema conceitual contém certas informações que não
aparecem na implementação física. Observa-se a perda de
informação semântica na comparação das informações
contidas no esquema conceitual com as do esquema físico. Por
exemplo,
a tabela física raramente tem o mesmo nome da entidade
ou do relacionamento que a originou;
em geral, em relacionamentos de cardinalidade 1:N, o
nome do relacionamento é perdido quando passamos do
modelo conceitual para o modelo físico, ou seja, os três
objetos (duas entidades e um relacionamento)
transformam-se em apenas dois (duas tabelas);
também, normalmente, relacionamentos de cardinalidade
1:1 no modelo conceitual são implementados como uma
única tabela no modelo físico.
2) Utilização de papéis para a descrição de
relacionamentos
No esquema E-R, relacionamentos são descritos por um
único nome. Por outro lado, a utilização de papéis para a
descrição de relacionamentos tem sido a abordagem de
ferramentas de modelagem mais recentemente divulgadas
como a ORM (Object Role Modeling [9]-[10]) e a UML
(Unified Modeling Language [11]).
Nestas, os
relacionamentos são descritos pelos papéis que cada entidade
apresenta, por exemplo, o relacionamento “trabalha” (figura
1) entre as entidades “Companhia” e “Empregados” pode ser
descrito como: “Companhia é o empregador do Empregado” e
“Empregado trabalha para a Companhia”.
Tendo em vista que o objetivo foi o de encontrar um
mecanismo que permitisse, sempre que necessário, recuperar a
informação semântica e/ou os papéis contidos no esquema
conceitual, foram utilizadas tabelas auxiliares para o registro
de tais informações.
O processo completo de criação de uma consulta pode ser
descrito como uma máquina de estado. Passo a passo, o
sistema fornece ao usuário um novo conjunto de palavras e
opções. Isso significa passar de um estado a outro como
mostrado na figura 7. No estado 1, o usuário seleciona a opção
“Qual(is)” ou “Quanto(s)”. No estado 2, ele seleciona uma
das entidades do esquema. O usuário pode passar para o
estado 3, no qual ele escolhe um atributo de uma entidade
previamente selecionada, ou pode passar para o estado 4.
Neste estado, o usuário pode escolher outra entidade ou
retornar ao estado 3. A partir do estado 2 ou 3 o processo
poder ser finalizado e a consulta executada.
Fig. 7. Diagrama de estados
Contudo, a consulta deve, ao mesmo tempo, ser
compreensível em português, ou seja, ser inteligível pelo
usuário, e ter uma estrutura que possa ser convertida para a
SQL, ou seja, a linguagem precisa ter uma estrutura conhecida
e definida. A figura 8 mostra a estrutura da consulta. Os
elementos da estrutura são definidos a seguir.
Q {“Qual(is)”, “Quanto(s)”}
E H; onde H é o conjunto de todas as entidades de um
esquema.
A D; onde D é o conjunto de todos os atributos de um
determinado E.
O {“igual a”, “diferente de”, “menor que”, “menor ou
igual a”, “maior que”, “maior ou igual a”}.
V {R S D}; onde R é o conjunto dos números
Reais; S é o conjunto de cadeia de caracteres possíveis de
serem geradas com o alfabeto; D é o conjunto de datas
válidas.
P U; onde U é o conjunto de papéis que um determinado
E desempenha.
C é o conjunto das conjunções lógicas possíveis: {e, ou}
“que tem”, “que”, “tem” e “existe(m)” são conectores para dar
sentido na língua portuguesa.
Q
P
E
A
O
E
V
C
Fig. 8. Estrutura de uma consulta
A Figura 9 mostra uma consulta que exemplifica o uso da
estrutura da Figura 8, tendo como base esta estrutura pode-se
definir uma gramática formal para a ferramenta de criação de
DE SOUZA et al.: A TOOL FOR QUERY FORMULATION
consulta apresentada neste artigo. Pode-se usar um autômato
finito regular [12] para representar gramáticas. A Figura 10
mostra a gramática usada para gerar a estrutura definida na
Figura 9.
Fig. 9. Exemplo de uma consulta e sua estrutura
B.
Conversor de Consultas para SQL
A função do módulo conversor de consultas para SQL é
converter uma sentença estruturada em português para uma
consulta SQL válida equivalente. Sempre é possível criar um
parser que mapeie uma frase de estrutura conhecida e sem
ambigüidades para outra, também conhecida e sem
ambigüidades ([13]-[14]-[15]). Assim, pode-se converter a
consulta com a estrutura definida na figure 8 para uma
consulta SQL padrão.
Fig. 10. Autômato finito regular que representa a gramática adotada
A estrutura definida na figura 8 pode ser representada por
três cláusulas SQL: SELECT, FROM and WHERE. O módulo
usa as informações especificadas na sentença e, em alguns
casos, em tabelas auxiliares para construir cada cláusula SQL.
Para a cláusula SELECT, basta que a ferramenta identifique
o elemento Q na sentença. Se o elemento corresponder à
palavra “Qual(is)”, a cláusula SELECT será SELECT *, e se
for “Quanto(s)s”, será SELECT COUNT(*).
Para a cláusula FROM, a ferramenta percorre a estrutura da
consulta, identificando todos os elementos E. Na seqüência,
mapeia esses elementos aos nomes das tabelas físicas
283
correspondentes. Em alguns casos o mesmo elemento aparece
mais de uma vez na mesma consulta; nestas situações é
apropriado criar um alias para cada repetição. Para resolver
este problema, a ferramenta cria um número seqüencial para
cada uma das repetições do mesmo elemento.
Para a cláusula WHERE a ferramenta pode tomar duas
ações distintas: uma que consiste na definição de uma junção
natural e outra que utiliza filtros aplicados pelo usuário sobre
atributos específicos. No primeiro caso, a ferramenta
identifica a seqüência de elementos E, P e E. Cada seqüência
desse tipo representa, na representação física, uma tabela, uma
chave-estrangeira e outra tabela, sendo então possível
identificar as tabelas e respectivos atributos que devem ser
consistidos para a formulação da junção natural. O segundo
caso requer que a ferramenta identifique a seqüência E, A, O
e V, o que permite a criação de um filtro que tem o atributo A
da entidade E, o operador de comparação O e o valor V.
Finalmente, neste caso, a ferramenta mapeia os elementos A e
E, respectivamente, aos nomes do atributo e da tabela física
correspondentes.
IV.
CONCLUSÃO
Este artigo apresentou uma ferramenta para acesso a banco
de dados relacionais. Nesta ferramenta, todos os
relacionamentos são descritos através dos papéis que as
entidades apresentam em ambos os sentidos de cada
relacionamento. Outro aspecto importante, é que a informação
semântica do esquema conceitual é usada no nível físico. Com
isso pôde-se criar uma linguagem intermediária entre a SQL e
a linguagem natural que permite que o usuário recupere
informação de banco de dados relacionais, sem que seja
necessário conhecer SQL nem o esquema de dados.
Dois critérios podem ser usados na avaliação de uma
ferramenta de criação de consultas: a capacidade funcional ou
a usabilidade [2]. O foco da ferramenta aqui apresentada foi
usabilidade. Assim, algumas funcionalidades não foram
implementadas como funções agregadas, cláusulas group by
dentre outras, e as operações que alteram o estado de banco de
dados. Entretanto, as que foram permitem que um grande
número de consultas seja criado. Além disso, os conceitos
apresentados podem ser utilizados para implementações de
mais funcionalidades.
Foram realizados alguns testes de usabilidade da
ferramenta com usuários com pouco ou nenhum conhecimento
sobre banco de dados, mas acostumados com o uso de
computadores. Esses testes foram feitos com 20 usuários. O
objetivo foi avaliar a facilidade de aprendizado e de adaptação
ou a satisfação do usuário no uso do produto. Todos os
usuários conseguiram identificar os botões de comando,
fazendo a associação correta entre a imagem e
a
funcionalidade implementada. Na formulação de consultas,
testes foram feitos sem que o usuário tivesse conhecimento
prévio do esquema. Neste caso, três relataram dificuldade
quanto à compreensão do significado de algumas opções de
perguntas feitas pela ferramenta, ex. “tem empresa” (figura 3),
a qual pode ter diferentes interpretações dependendo da
284
IEEE LATIN AMERICA TRANSACTIONS, VOL. 4, NO. 4, JUNE 2006
vivência do usuário. Considerando que todos os nomes de
entidades e atributos foram mapeados diretamente do esquema
original, isso reforça um ponto importante, que é necessário
cuidado especial com aspectos ontológicos e na escolha de
nomes utilizados no esquema original.
Esses resultados
preliminares demonstraram que a ferramenta atende aos
objetivos iniciais.
V.
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
BIBLIOGRAFIA
J. Reinschmidt, C. Comsia and A. R. Santos, A DB2 Enterprise Query
Environment - Build it with QMF for Windows, vol. 1, IBM Corporation,
International Technical Support Organization, 1998, pp. 24.
T. Catarci et al, “Visual Query System for Databases: A Survey”,
Journal of Visual Languages and Computing, vol.8, pp. 215-260, Jun.
1997.
M. Chavda and Peter T. Wood, “A Visual Query Language for ODMGCompliant Databases – QUIVER”, in Proc. 1997 IEEE Symposium on
Visual Languages, pp. 125-126.
Y. Dennebouy, et al, “Super: Visual Interface for Object + Relational
Data Models”, in Proc. (1995) Visual Database System - DBMS Visual
Interfaces. pp. 365-380.
T. Angelaccio, T. Catarci and G. Santucci, “QBD*: A Graphical Query
Language with Recursion”, IEEE Trans. on Software Engineering, vol.
16, n. 10, pp. 1150-1163, Out. 1990.
T. Angelaccio, T. Catarci and G. Santucci, “QBD*: A Fully Visual
Query System”, Journal on Visual Languages and Computing, vol. 1,
pp. 255-273, Out. 1987.
T. Catarci, “What Happened When Database Researchers Met
Usability”, Information System, vol. 25, n. 3, pp. 177-212, 2000.
M. M. Zloof, “Query-By-Example: a Database Language”, IBM System
Journal, vol. 16, pp. 324-343, 1977.
T. A. Halpin, “Business Rules and Object Role Modeling”, Database
Programming & Design, vol. 9, n. 10, pp. 66-72, 1996.
T. A. Halpin, “Object-Role Modeling (ORM/NIAM)”, in Handbook on
Architectures of Information Systems, 1998, cap. 4.
G. Booch, J. Rumbaugh and I. Jacobson, “The Unified Modeling
Language User Guide”, Addison-Wesley, 1999.
H. R. Lewis and C. H. Papadimitriou, Elements of the Theory of
Computation, Prentice-Hall, 2q ed, 1997.
A. H. M. Ter Hofstede and T. P. Van Der Weide, “Exploring Fact
Verbalizations for Query Formulation”, Department of Computer
Science, The University of Queensland, Brisbane, Australia. 1997.
A. M. Turing, “On Computable Numbers, with an Application to the
Entscheidungs problem”, in Proc. London Mathematical Society, vol.
42, pp. 230-265 e vol. 43, pp. 544-546, 1936.
A. M. Turing, “On Computable Numbers, with an Application to the
Entscheidungs problem”, in Proc. London Mathematical Society, vol.
43, pp. 544-546, 1936.
VI.
BIOGRAFIAS
Solange Nice Alves de Souza. Graduação (1986) - Licenciatura em Física
pela Universidade Federal Fluminense, RJ ; Mestrado (1991) - Engenharia
Nuclear pela Universidade Federal do Rio de Janeiro, RJ; Pós-graduação
(Latu Sensu) (1991) - Análise de Sistemas pela Pontifícia Universidade
Católica do Rio de Janeiro, RJ; Doutorado (1998) - Engenharia Elétrica pela
Escola Politécnica da Universidade de São Paulo (USP). Docente da Escola
Politécnica da USP e do Centro Universitário Fundação Instituto de Ensino
para Osasco (UNIFIEO) nos cursos de graduação e pós-graduação.
Edit Grassiani Lino de Campos. Graduação (1972), Mestrado (1975) e
Doutorado (1982) Engenharia Elétrica na Escola Politécnica da Universidade
de São Paulo (EPUSP). Orientadora de Pós-Graduação na EPUSP e docente
de Pós-Graduação strictu sensu (Mestrado Profissional) no Instituto de
Pesquisas Tecnológicas do Estado de São Paulo (IPT).
André Roberto Doreto dos Santos. Mestre (2001) em Engenharia Elétrica
pela Escola Politécnica da Universidade de São Paulo.
Download
