de consultas - Computação UFCG

CONSULTAS A BANCOS DE DADOS E
SEU PROCESSAMENTO
Marinaldo Nunes
SUMÁRIO
INTRODUÇÃO .................................................................................................................................................... 3
DATALOG ........................................................................................................................................................... 4
PROGRAMAS DATALOG SEGUROS ............................................................................................................ 6
CONVERTENDO DATALOG PARA A ÁLGEBRA RELACIONAL ............................................................. 7
REGRAS RECURSIVAS .................................................................................................................................. 9
DATALOG1S ...................................................................................................................................................... 11
CONSULTAS RECURSIVAS ......................................................................................................................... 14
OBJECT SQL ................................................................................................................................................... 16
MODELO DE OBJETOS OSQL ..................................................................................................................... 17
OBJETOS ........................................................................................................................................................ 17
TIPOS .............................................................................................................................................................. 18
FUNÇÕES ....................................................................................................................................................... 18
SISTEMA DE TIPOS OSQL ........................................................................................................................... 18
SISTEMA DE FUNÇÕES OSQL .................................................................................................................... 19
LINGUAGEM DE CONSULTA ..................................................................................................................... 20
OQL[C++] .......................................................................................................................................................... 21
INTEGRAÇÃO ENTRE LINGUAGENS DE PROGRAMAÇÃO E CONSULTAS ...................................... 22
A LINGUAGEM DE CONSULTA .................................................................................................................. 24
INTERFACES VISUAIS DE CONSULTAS ................................................................................................... 29
EVOLUÇÃO DAS INTERFACES PARA BANCOS DE DADOS ................................................................. 30
INTERFACES TABULARES ......................................................................................................................... 30
INTERFACES DIAGRAMÁTICAS ............................................................................................................... 31
INTERFACES ICÔNICAS .............................................................................................................................. 31
INTERFACES HÍBRIDAS / MULTIMODAIS ............................................................................................... 32
EVOLUÇÃO DAS ESTRATÉGIAS DE INTERAÇÃO.................................................................................. 33
MANIPULAÇÃO DA ESTRUTURA ............................................................................................................. 33
MANIPULAÇÃO DO CONTEÚDO ............................................................................................................... 34
ALGUMAS INTERFACES VISUAIS ............................................................................................................ 36
CONCLUSÃO .................................................................................................................................................... 38
REFERÊNCIAS BIBLIOGRAFICAS ............................................................................................................. 39
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
2
INTRODUÇÃO
1
Este trabalho faz parte da disciplina Bancos de Dados Avançados ministrada pelo
professor Ulrich Schiel. Seu objetivo é mostrar alguns tipos de consultas, sobre dados em
bancos de dados, levando em consideração o aspecto ‘processamento’.
No capítulo 2, falamos sobre Datalog, linguagem, baseada em lógica, para consultas a
bancos de dados. Na capítulo 3, abordamos uma extensão temporal de Datalog, o Datalog 1s.
Em seguida, mostramos rapidamente uma nova funcionalidade disponibilizada pelo padrão
SQL3, as consultas recursivas. Nos capítulos 4 e 5, discutimos duas extensões de linguagens
procedurais para suportar consultas, prover persistência de dados, bem como oferecer outras
funcionalidades comuns aos bancos de dados, são elas: OSQL e OQL[C++]. No capítulo
seguinte discutimos uma nova forma de interação entre usuários e bancos de dados, ou seja,
as interfaces visuais de consultas, mostrando os diversos tipos de interfaces existentes, as
formas de manipulação dos dados disponibilizadas por tais interfaces e por fim alguns
exemplos. Finalizando temos as conclusões e referências bibliográficas.
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
3
2
DATALOG
Linguagens declarativas são utilizadas para especificar regras em bancos de
dados (BD) dedutivos. Tal denominação vem do fato que, este tipo de linguagem
especifica o que o programa deve fazer, e não, como fazer. Os BD dedutivos trabalham
baseado na lógica, tendo como ponto de partida, a linguagem de programação Prolog.
Segundo [EN94], Datalog é um subconjunto de Prolog usado para definir regras
declarativamente em conjunção com um conjunto de relações, as quais, são elas
próprias, tratadas como literais da linguagem.
Bancos
de
Dados
Dedutivos
utilizam
principalmente
dois
tipos
de
especificações: fatos e regras. Fatos são predicados lógicos onde todos os seus
argumentos são constantes. Regras são similares à visões relacionais, com a diferença
que podem ser recursivas.
Datalog é baseado em predicados com nomes únicos. Cada predicado tem um
significado implícito, sugerido a partir do seu nome, e um número de argumentos, sendo
que, se todos os argumentos de um predicado forem constantes, tal predicado indica que
um fato é verdade. Por outro lado, se entre os argumentos existir alguma variável, este é
considerado uma consulta, parte de uma regra ou uma restrição.
Em Datalog, um banco de dados é visto como um conjunto de fatos. Cada fato
representa uma tupla de uma tabela em um banco de dados relacional, e o nome de tal
tabela, é determinado pelos nomes dos predicados que a formam. Por exemplo, temos
os seguintes fatos:
estudante (‘Maria”, 17,’Computação’).
estudante(‘João’,16,’Computação’).
estudante(‘Lucia’,18,’Engenharia Elétrica’).
conceito(‘Maria’, 9.2).
conceito(‘Joao’, 8.9).
conceito(‘Lucia’, 9.1).
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
4
o banco de dados relacional equivalente teria as tabelas “estudante” e “conceito”
com as seguintes organizações
Estudante
NOME
IDADE
CURSO
Maria
17
Computação
João
16
Computação
Lúcia
18
Engenharia Elétrica
Conceito
NOME
NOTA
Maria
9.2
João
9.1
Lúcia
8.9
Na construção de um Datalog as seguintes convenções são adotadas:
-
Constante => palavras iniciando com letras minúsculas, números e palavras
este apóstrofos ( ‘ ), por exemplo ‘Maria’;
-
Variáveis => palavras iniciando com letras maiúsculas.
Outra característica relevante de um predicado para um programa Datalog é a
aridade, determinada pelo número de argumentos do predicado. Por exemplo, o
predicado estudante(‘Maria’,17,’Computação’) tem aridade igual a 3 (três), onde Maria,
17 e Computação são respectivamente primeiro, segundo e terceiro argumentos.
Regras constituem a principal construção em programas Datalog, pois através
delas, novos fatos são gerados visando satisfazer uma consulta submetidas ao banco de
dados, que na verdade é um banco de fatos. Por exemplo, para a regra,
cursa_Eletrica(Nome) :- estudante ( Nome, _ , ‘Engenharia Elétrica’) um novo
conjunto de fatos é gerado virtualmente, onde cada fato gerado possui o formata da
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
5
cabeça da regra, cursa_Eletrica(Nome).
Uma regra pode ter mais de um predicado no seu corpo, separados por virgula,
indicando uma conjunção de objetivos. Por exemplo, encontrar os estudante de
Computação com nota média maior que nove
maiorNove(Nome) :- estudante(Nome, ’Computação’), conceito(Nome, Nota), Nota > 9.
os fatos gerados pela regra satisfazem todas as condições impostas por cada predicado.
Um disjunção é formada por várias regras com a mesma cabeça. Por exemplo,
encontrar os estudantes de Computação ou Engenharia Elétrica que têm média maior
que nove
maiorNove(Nome) :- estudante (Nome , ’Computação’), conceito (Nome,
Nota ), Nota > 9.
maiorNove(Nome) :- estudante (Nome , ’Engenharia Eletrica’), conceito
(Nome, Nota ), Nota > 9.
o conjunto de fatos, gerados em resposta a uma disjunção, é composto pela união dos
fatos resultantes de cada regra que a compõe.
PROGRAMAS DATALOG SEGUROS
Um programa ou uma regra é seguro se gera uma conjunto finito de fatos. Em
geral, determinar se um conjunto de regras é seguro, é um problema indecidível, ou seja,
não existe uma procedimento computacional definido para a solução de tal problema.
Uma maneira de evitar programas inseguros, é limitar o domínio o qual cada variável de
uma regra pode varrer. Por exemplo, para a regra maior_de_idade(Y) :- Y > 18 a
variável Y pode assumir todos os valores acima de 18, sem restrição, gerando assim, um
conjunto infinito de fatos. Mas, se a regra for reescrita da seguinte forma
maior_de_idade(Y) :- estudante(X,Y,_ ), Y> 18.
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
6
o resultado não será infinito, pois os valores que Y pode assumir estão restritos as
idades de alguns estudantes do banco de dados.
Concluímos que, um programa seguro é formado por regras seguras. Uma regra
é segura se todas as suas variáveis são limitadas. Em [EN94] uma variável X é limitada
se:
I ) aparece no corpo da regra em um predicado regular, ou seja, um predicado
que não contém operadores comparativos ( =, <, >, <=, >= );
II ) aparece no corpo da regra em um predicado da forma X=c ou c=X ou ( c1
<= X and X <= c2), onde c, c1 e c2 são constantes; ou
III ) aparece no corpo da regra em um predicado da forma X=Y ou Y=X, onde
Y é uma variável limitada.
CONVERTENDO DATALOG PARA A ÁLGEBRA RELACIONAL
Apenas programas Datalog seguros podem ser mapeados para expressões
equivalentes da Álgebra Relacional. Para todo Datalog seguro existe uma expressão da
Álgebra Relacional.
A seguir mostramos o algoritmo de mapeamento de um programa Datalog
seguro, e não recursivo, P para Álgebra Relacional.
Passo 1 => P é transformado em um programa equivalente P’ sem nenhum
comparador de igualdade. Por exemplo para a regra abaixo
r: s(Z, b ,W) :- q(X, X ,Y), p(Y, Z ,a), W=Z, W >24.3.
temos
r: s(Z, b ,Z) :- q(X, X ,Y), p(Y, Z ,a), Z >24.3.
Passo 2 => O corpo da regra é traduzido para a expressão AR (Álgebra
Relacional) chamada Bodyr. Bodyr consiste de um produto cartesiano de toda a base ou
de relações derivadas do corpo da regra, seguidas por uma seleção F, onde F é a
conjunção das seguintes condições:
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
7
i)
condição de desigualdade para cada objetivo. Por exemplo
ii)
igualdade entre colunas contendo a mesma variável, e;
iii)
igualdade entre uma coluna e uma constante.
Z >24.3;
Por exemplo, a condição Z > 24.3 é convertida em uma seleção do tipo $5 > 24.3,
enquanto as duas ocorrências de X são traduzidas em $1 = $2 e para as Ys temos $3 =
$4 e a constante na ultima coluna de p é mapeado em $6 = a. Assim obtemos Bodyr = 
$1=$2, $3=$4, $6=a, $5 > 24.3 (QxP);
Passo 3 => Cada regra r é transformada em uma projeção em Bodyr de acordo com a
cabeça de r. Para a regra r obtemos S =  $5,b,$5 Bodyr
Passo 4 => Múltiplas regras com a mesma cabeça são traduzidas em uma união de suas
expressões equivalentes.
Este mapeamento pode ser generalizado para traduzir regras com predicados
negados. Por exemplo, r :- b(a,Y), c(Y), ~d(Y).
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
8
REGRAS RECURSIVAS
Imagine que queremos montar uma lista de todos os componentes que compõe um
objeto. O problema aqui é, um componente pode ser formado por componentes menores que
por sua vez são formados por peça básicas, que não podem ser mais divididas. Considere as
tabelas abaixo.
CUSTO_PEÇA
PEÇA
FORNECEDOR
CUSTO
TEMPO
Assento
Columbus
20,00
14
Assento
Biker
15,00
20
Raio
Columbus
6,00
4
Pneu
Cinelli
20,00
15
Pneu
Suntour
22,00
12
Parafuso
Araya
3,00
6
Aro
Columbus
5,00
4
Freio
Mavic
8,00
7
Pedal
Mavic
7,00
7
MONTAGEM
OBJETO
PARTE
QTD
Bicicleta
Roda
2
Bicicleta
Assento
1
Roda
Raio
36
Roda
Aro
1
Roda
Pneu
1
O predicado montagem (Objeto, Parte, Qtd) indica o objeto, suas partes imediatas e
a quantidade destas partes que formam o objeto. O predicado custo_Peça(Peça, Fornecedor,
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
9
Custo, Time) descreve a peça, seu fornecedor, seu custo em cada fornecedor e o tempo para
entrega da peça por fornecedor.
Assuma agora que, queremos encontrar todas as partes de um dado objeto. Regras
recursivas como,
todas_peças (Objeto, Peça) :- montagem (Objeto, Peça, _).
todas_peças (Objeto, Peça2) :- todas_peças (Objeto, Peça1),
montagem (Peça1, Peça2, _).
são necessárias para expressar este tipo de consulta. Uma regra é recursiva se sua cabeça
aparece no corpo da regra. Uma regra não recursiva como todas_peças (Objeto, Peça)
:-
montagem (Objeto, Peça, _) definindo um predicado recursivo é denominada regra saída ou
regra de parada.
A seguir mostrando exemplos de consultas que usam regras recursivas.
Consulta 1: Encontrar para cada objeto, suas partes principais e para cada parte suas peças
componentes, por exemplo, uma bicicleta possui duas rodas que possuem dois pneus, aros,
raios ( uma peça é ela própria seu componente básico).
partesBasicas( Basica, Basica) :- custo_peca (Basica, _, _, _).
partesBasicas( Obj, Basica) :- montagem (Obj, SubParte, _),
partesBasicas( SubParte, Basica).
Consulta 2: Encontrar para cada peça, o menor tempo de entrega.
mais_rapida (Peça, Tempo) :- custo_peça ( Peça, Fornecedor, Custo, Tempo),
~mais_rapida (Peça, Tempo).
mais_rapida(Peça, Tempo) :- custo_peça ( Peça, Fornecedor, Custo, Tempo),
custo_peça ( Peça, Fornecedor2, Custo2, Tempo2), Tempo2 < Tempo.
Consulta 3: Encontrar o tempo necessário para as subpartes de um dado objeto.
tempoParaPeça (Parte, Peca, Tempo) :- partesBasicas (Parte, Peça), mais_rapida
(Peça,Tempo).
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
10
DATALOG1S
3
Em Datalog1s, os predicados possuem um argumento especial que determina o tempo,
denominado argumento temporal. Tal argumento assume valores de um domínio temporal
discreto. Um domínio temporal discreto consiste de termos construídos usando a constante 0
e uma função unária +1.
Por questão de simplicidade denotaremos ( ...( ( 0+1 ) +1 ) ...+1 ) por n. Também, se
T é uma variável no domínio temporal, então T, T+1, e T+n são termos temporais válidos,
onde T+n é uma forma abreviada para ( ... ( ( T+1 ) +1 ) ...+1 ).
O programa Datalog1s abaixo modela o sucessão das estações climáticas:
quarter(0,winter).
quarter( T+1, spring ) :- quarter( T,winter ).
quarter( T+1 , summer) :- quarter ( T, spring ).
quarter( T+1 , fall ) :- quarter ( T, summer ).
quarter( T+1 , winter ) :- quarter ( T, fall ).
Datalog1s prover um formalismo natural para modela eventos e histórias que ocorrem
em um domínio discreto, por exemplo um domínio isomórfico aos inteiros. A granularidade
do termo usado, entretanto, depende da aplicação. No exemplo acima, a granularidade de
tempo foi as estações do ano. A seguir, mostramos um exemplo que lista a escala de horários
dos trens para Newcastle, a granularidade do tempo em tal exemplo são horas.
Trens para Newcastle parte de duas em duas horas, iniciando as 8:00h e finalizando as
22:00h. O programa Datalog1S para tal é:
before22 ( 22 ).
before22 ( Hora ) :- before22 ( Hora+1 ).
leaves ( 8, newcastle ).
leaves ( T+2, newcastle ) :- leaves (T, newcastle ), before22 (T).
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
11
Assim a consulta ?leaves ( When, newcastle ) irá gerar os horários de partida para
Newcastle.
Datalog1s é o Datalog padrão com uma interpretação temporal agregada.
Outro ponto importante sobre Datalog1s é que ela é capaz de representar o raciocínio
temporal da mesma forma que uma linguagem temporal de propósito especial com
operadores modais. Tomemos como exemplo, a Lógica Temporal Linear Proporsicional
(LTLP) que é baseada na noção que existe uma sucessão de estados H = (S 0,S1, ...) chamada
historia. Então, operadores modais são usados para definir em qual estado o predicado p é
verdadeiro.
Por exemplo, o programa dos trens de Newcastle pode ser modelado por um
predicado newcstl, que é verdadeiro nos seguintes estados S8, S10, S12, S14, S16, S18, S20, S22,
sendo falsos nos outros estados.
Então os predicados temporais que pertencem a H são definidos da seguinte forma:
1. Átomos: Seja p um predicado proposicional atômico. Considere p como o estado
inicial S0 da H.
Além dos
operadores proposicionais V, & e ~. LTLP oferece os seguintes
operadores:
2. Próximo: Próximo p, denotado por Op, é verdadeiro na história H, quando p
pertence a história H1={S1,S2,….}.
Consequentemente, Onp, n  0, denota que p é verdadeiro na história (Sn,Sn+1, ...)
3. Eventualmente: Eventualmente q denotado por Fq indica que, para algum n, Onq
4. Ate: p até q, denotado pUq, indica que para algum n, Onq, e para todo estado
K<n, OKp.
Outros operadores podem ser derivados dos operadores acima. Por exemplo, o fato
que q nunca será verdadeiro pode ser definido como ~Fq. Já o fato que q é sempre
verdadeiro, é simplesmente definido como ~(F(~q); a notação Gq é usada para indicar que
q é sempre verdadeiro. O operador p antes q, é denotado por pq.
LTLP encontra muitas aplicações, incluindo consultas temporais e prova de
propriedades de sistemas dinâmicos. Por exemplo, a questão “Existe trem para Newcastle que
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
12
é seguido por outro uma hora depois?” pode ser expressa pela seguinte consulta:
?F( newcstl & Onewcstl )
Toda consulta em LTLP pode ser expressa em Datalog1s.. Por exemplo, a consulta
anterior pode ser escrita da seguinte forma ?parte_para_newcstl onde
parte_para_newcstl :- newcstl (J) & newcstl (J+1).
Portanto, a interpretação “para algum J” atribuída ao argumento temporal J de um
predicado Datalog1s é suficiente para modelar o operador F de LTLP, enquanto O é
simulado por +1. A tradução de outros operadores são, entretanto, mais complexas.
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
13
CONSULTAS RECURSIVAS
4
O novo padrão SQL3 inclui suporte para consultas recursivas. Por exemplo, a
consulta Datalog
todas_peças(Objeto, Peça) :- montagem(Objeto, Peça, _).
(1)
todas_peças(Objeto, Peça2) :-todas_peças(Objeto, Peça), montagem(Peça,Peça2, _). (2)
em SQL3 é escrita como uma visão da seguinte forma,
CREATE RECURSIVE view todas_pecas ( Principal, Sub) AS
SELECT OBJETO, PARTE
FROM montagem
UNION
SELECT all.Principal, pc.PARTE
FROM todas_pecas all, montagem pc
WHERE all.Sub = pc.OBJETO
O comando SELECT antes do UNION é equivalente a regra de saída (1), enquanto o
comando SELECT depois do UNION corresponde a regra recursiva (2). Tais partes de visão
serão referenciados como exit select e recursive select respectivamente.
Como todas_peças é uma visão virtual, é preciso materializá-la, ou parte dela, para
que uma consulta real possa ser feita. Por exemplo a consulta
SELECT *
FROM todas_pecas
requer a materialização de toda a visão.
O construtor WITH prover uma outra maneira, mais direta, para expressar recursão
em SQL3. Por exemplo, a consulta para encontrar todas as partes básicas que contém a peça
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
14
raio como componente, pode ser expressa da seguinte forma:
WITH RECURSIVE todas_partes ( Principal, Menor) AS
(
SELECT Objeto, Parte
FROM montagem
UNION
SELECT assb.Objeto, all.Menor
FROM montagem assb, todas_partes all
WHERE assb.Parte = all.Principal
)
SELECT *
WHERE Menor = ‘raio’
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
15
OBJECT SQL
5
Object SQL (OSQL) é uma linguagem para bancos de dados que combina uma
linguagem procedural orientada a expressão com uma linguagem de consulta declarativa de
alto nível. Foi desenvolvida como parte do projeto Iris dos Laboratórios da Hewlett-Packard
[Fea89][Lyn91][WLH90]. O desenvolvimento de OSQL foi influenciado pelo trabalho em
modelos de banco de dados semânticos e funcionais, notavelmente a linguagem Daplex
[Shi81] e a linguagem Taxis [MBW80]. A linguagem OSQL combina características da
orientação a objetos encontradas nas linguagens de programação, como C++ [ES90] por
exemplo, com uma capacidade de pesquisa que é um superconjunto da linguagem SQL.
Consequentemente, OSQL prover muitas das vantagens da orientação a objetos, como
aumento da produtividade, reutilização de código, extensibilidade e etc, com características
da tecnologia atual de banco de dados, por exemplo, otimização de consultas, restrições de
integridade, acesso multi-usuário, autorização e segurança.
Os objetivos do desenvolvimento de OSQL são que ela deveria:

Ser baseada em um modelo ortogonal simples orientado a objeto e sistema de
tipos;

Ser computacionalmente completa e independente de linguagens de programação
para aplicações específicas;

Prover meios para especificar consultas declarativas e permitir que tais consultas
sejam compiladas e otimizadas de forma similar as oferecidas em linguagens de
consultas relacional;

Ser extensível - isto é, permitir ao usuário definir novos tipos e operações;

Criar distinções não artificiais entre objetos meta-dados e objetos definidos pelos
usuários;

Permitir separar definições da interface de um objeto (tipo) e a(s)
correspondente(s) implementação(ões).
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
16
OSQL é orientada a objetos no sentido de que ele prover identificação de objeto, um
sistema de tipos com múltipla herança, polimorfismo de funções e objetos agregados built-in,
como conjunto (set) e listas. Em OSQL o estado de um objeto não é uma parte intrínseca do
próprio objeto, mas é definido pelas funções que modelam os atributos, relacionamentos
entre objetos e comportamento dos objetos. O sistema de tipos de OSQL permite ao
compilador OSQL fazer a checagem de tipos em tempo de compilação. Entretanto, como
OSQL permite a criação de objetos e funções dinamicamente, ou seja, a checagem em tempo
de compilação é complementada por uma checagem em tempo de execução. Uma outra
característica importante é que o estado de um objeto não é uma parte intrínseca de um
objeto, mas é definido pelas funções que modelam atributos, relacionamentos e
comportamento.
Funções podem ser implementada como stored procedures
ou podem ser
computadas. A implementação de uma função computada é especificada por uma expressão,
o “corpo” da função; a lista de parâmetros e o valor retornado pela função. OSQL também
suporta funções externas, ou seja, escritas em outras linguagens de programação, como C,
C++, Cobol, etc.
MODELO DE OBJETOS OSQL
A linguagem OSQL é centrada em volta de três conceitos básicos: objetos, tipos e
funções.
OBJETOS
Objetos representam entidades do mundo real e conceitos do domínio da aplicação do
banco de dados.
Em OSQL, objetos podem ser classificados em três categorias:

Literais – por exemplo, inteiros, string e objetos binários;

Agregados – por exemplo, uma lista ou tupla contendo dados de um paciente,
como nome, idade, endereço, etc;

Surrogates – por exemplo, paciente e clínica.
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
17
Cada objeto do tipo surrogate possui uma única identificação ( OID ) associado e
podem ser explicitamente criados e excluídos.
TIPOS
Tipos são usados para classificar objetos em termos de propriedades e/ou
comportamento e para definir “assinaturas” de funções (seus argumentos e tipo retornado).
As extensões de tipos é o conjunto de objetos que são eles próprios instâncias de tipo. Tipos
Surrogate têm extensões dinâmicas que mudam dependendo dos tipos e ordem em que tais
objetos são criados e excluídos. Tipos agregados e objetos agregados podem ser construídos
de outros tipos e objetos, respectivamente, usando tipos agregados definidos pelo sistema e
construtores de objetos.
Tipos relacionam-se em uma hierarquia de subtipos/supertipos que suporta múltipla
herança.
Tipos definidos pelo usuário podem ser adicionados como um subtipo do tipo
UserSurrogate.
FUNÇÕES
Funções são usadas para modelar atributos, relacionamentos entre objetos e o
comportamento de tais objetos.
Uma função OSQL recebe um objeto como um argumento e pode retornar um objeto
como resultado. Funções OSQL podem ser sobrecarregadas – isto é, pode haver múltiplas
funções como o mesmo nome, mas diferentes tipos de argumentos. OSQL não permite
sobrecarga de função em termos de valores de retorno. Uma função sobrecarregada é
referenciada como uma função genérica (generic function). Os resolventes de uma função
genérica são denominados de funções específicas (specific functions).
SISTEMA DE TIPOS OSQL
Para construir um sistema em OSQL, uma grande quantidade de objetos, tipos e
funções precisam ser definidos. O tipo objeto raiz é chamado Object e é o supertipo de todos
os outros tipos de objetos. Subtipos de objetos são:
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
18

TypeRef – tipo cuja extensão é o conjunto de todos os tipos de objetos, incluindo
tipos agregados;

Surrogate – o supertipo de todos os tipos onde suas instâncias têm
OIDs
associados, incluído Function, Type, Index. User, UserGroup e UserSurrogate;

UserSurrogate – supertipo de todos tipos definidos pelo usuário, por exemplo,
paciente, aluno, etc;

Type – tipo cuja extensão é o conjunto de todos os tipos surrogate, por exemplo,
todos tipos diferentes dos tipos agregados;

Transient – supertipo de todos os tipos de objetos transitórios, ou seja , objetos
cujo instâncias são temporários, por exemplo, Transaction, Savepoint, Session e
Cursor;

Aggregate – o supertipo de todos os objetos agregados;

Tipos Literais – os tipos literais suportados por OSQL incluem Number ( Integer,
SmallInteger, Double, Real), Char, Binary, Date, Time, DateTime e Interval;

Void – Void é um subtipo de todos os tipos, exceto tipos agregados; sua extensão
é o conjunto vazio.
SISTEMA DE FUNÇÕES OSQL
Existe um grande número de funções, definidas pelo sistema, que provêem as
funcionalidades necessárias para implementar um gerenciamento adequado de dados
orientados a objeto.

CreateType – cria um novo tipo e cria uma ou mais funções que têm novos tipos
como seus argumentos;

CreateFunction – cria uma nova (definida pelo usuário) função;

ImplStored – implementa uma função ou conjunto de funções como um stored
procedure;

ImplOSQL – implementa uma função como uma expressão OSQL, como uma
expressão em uma linguagem procedural ou como uma expressão de consulta;
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
19

ImplExternal – implementa uma função como um programa arbitrário, escrito em
uma linguagem de programação externa;

CreateObj – cria um novo objeto, uma instancia de um tipo definido pelo usuário,
opcionalmente inicializando uma ou mais funções para um novo objeto.
LINGUAGEM DE CONSULTA
OSQL suporta uma linguagem de consulta cuja semântica é baseada no domínio de
cálculos, com suporte a domínios agregados, funções e multiconjuntos (bags).
A função OSQL SELECT prove as facilidades básicas de consulta de OSQL e
assemelha-se com o comando Select de SQL. Tal função tem a seguinte sintaxe
Select : = resStruct: ResStruct
ResList: Expr+
ForEach: Declaration*
Where : Expr
GroupBy : Group*
Having: Expr
OrderBy: orderSpec*;
Todas as partes do select acima são opcionais, exceto resList.
Por
exemplo,
utilizando
a
sintaxe
concreta
usada
pelo
OpenODB
[AD92][AC93][HP92] para recuperar o nome de uma pessoa, avaliaremos a seguinte
expressão:
select nome(p)
O
compilador
de
consultas
inferirá
que
o
tipo
desta
expressão
é
BagType(TupleType(Char)). Podemos utilizar a opção resStruct para mudar o tipo do
resultado retornado. Por exemplo, para retornar apenas o primeiro nome, nós adicionamos a
palavra-chave single na expressão da seguinte forma, select single atomic nome(p).
Expressões select são avaliadas e convertidas em chamadas para uma função select
pré-definida no sistema, em seguida seus argumentos são passados sem nenhuma avaliação.
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
20
OQL[C++]
6
O desenvolvimento de linguagens de consulta é um dos maiores desafios para os
desenvolvedores de sistemas de bancos de dados orientado a objetos (SBDOOs).
Devido a falta de padrão dos modelos de dados, um método comum para construir
BDOOs consiste em adotar o sistema de tipos de uma linguagem de programação orientado a
objetos e estendê-lo para suportar características de banco de dados tais como persistência,
transações e consultas.
Nos sistemas gerenciadores de bancos de dados tradicionais, aplicações de bancos de
dados são escritas usando comando de consulta embutidos em linguagens de programação de
propósito geral, tais linguagens são referenciadas como linguagens hospedeiras. Tal
estratégia tem cinco problemas:
1. O modelo de dados do banco de dados e o sistema de tipos da linguagem de
programação não "casam". Dessa forma, o conjunto de objetos retornado pela
consulta não pode ser manipulada diretamente pela linguagem de programação em
uso. Isto acontece em virtude de que, grande parte das linguagens de programação
não dispõe do tipo conjunto entre seus tipos básicos;
2. A falta de checagem de tipos dá margem a introdução de inconsistências no banco
de dados pela aplicação;
3. Consultas podem apenas serem formuladas em objetos persistentes do BD
(relações); elas não podem ser formuladas sobre objetos temporários;
4. Comandos de consulta e comando de linguagens de programação não podem ser
combinados livremente;
5. A sintaxe e semântica das duas linguagens são completamente diferentes e o
programador necessita aprender tais diferenças.
Visando eliminar tais problemas, uma extensão de C++ com persistencia e suporte a
consultas, denominado OQL[C++], foi proposto.
OQL[C++] possui as seguintes características
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
21
-
Suporta consultas em coleções de tipos semanticamente diferentes, abstração de
dados, herança e objetos complexos;
-
Suporta uma checagem de tipos uniforme em toda a aplicação, incluindo consultas
e expressões da linguagem de programação (LP) em uso;
-
Permite consultas em dados persistentes e temporários;
-
Permite que expressões da linguagem de programação possam ser usados na
construção das consultas;
-
Consultas podem operar sobre uma coleção de tipos semanticamente diferentes;
-
As noções de tipos e tipos estendido são separadas, possibilitando assim,
a
criação e consulta em múltiplas coleções de tipos em uma aplicação.
INTEGRAÇÃO ENTRE LINGUAGENS DE PROGRAMAÇÃO E CONSULTAS
Não existem critérios ou formalismo para determinar uma boa integração entre
linguagens de consulta e linguagens de programação. Mostraremos a seguir, alguns requisitos
que contribuem para definir tal aspecto. Tais requisitos são derivados de observações das
deficiências da integração entre linguagens de consultas e linguagens de programação
hospedeiras. Os requisitos são:
-
Sistema de Tipos de Linguagens = Modelo de Dados
Unificando o sistema de tipos de linguagem de programação e o modelo de dados
suportados pelo sistema de banco de dados reduz-se substancialmente o problema de
impedance mismatch.
-
Checagem de Tipos
Uma boa integração deve suportar uma forte checagem de tipos, tanto para a LP e os
comandos de consultas. Falta de checagem de tipos pode permitir erros em tempo de
execução causados pela aplicação, a uma operação, de operandos de tipos errados, os quais
podem comprometer a integridade do banco de dados.
OQL[C++] realiza a combinação de checagem de tipos estática ou dinâmica.
Checagem em tempo de execução assegura que apenas tipos de objetos corretos são
transferidos entre a base de objetos e o espaço da aplicação. Checagem em tempo de
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
22
compilação assegura que um vez os objetos estejam no espaço da aplicação, eles são
manipulados consistentemente.
-
Separação entre Tipos e Tipos Estendidos
Um linguagem de consulta a objetos deve pode operar em tipos semanticamente
diferentes . Um corolário para este requisito é a separação entre os conceitos de tipos e tipos
estendidos no modelo de dados.
Tipos estendidos, ou implícitos, é uma coleção de todas as instâncias de um particular
tipo. Uma coleção explicita é uma coleção definida e mantida explicitamente pela aplicação.
O suporte a tipos estendidos prover mais flexibilidade ao programador, permitindo a
definição de múltiplas coleções de tipos e compartilhamento de objetos entre múltiplas
coleções. Coleções explicitas são disponibilizadas por serem o escolha mais natural para os
programadores de LPs convencionais.
-
Combinando Comando de Linguagens de Consulta e Comandos de
Linguagens de Programação
Uma linguagem de consulta bem integrada deve permitir a especificação de
expressões de linguagens de programação, onde fizer sentido, dentro da consulta. Da mesma
forma, expressões de consulta devem ser permitir ser passadas como argumentos para um
expressão da LP.
OQL[C++] permite que expressões definidas pelo usuário possam ser usadas como
predicados em uma cláusula WHERE. Objetos e variáveis podem ser especificados como
alvos para a consulta na cláusula FROM. A declaração de variáveis de escopo na cláusula
FROM é idêntica a declaração de variáveis em C++. OQL[C++] permite a criação de novos
objetos como resultado de uma consulta através de tipos construtores em C++.
-
Unificação de Sintaxe e Semântica de Consulta e Comandos de LP
Idealmente , a sintaxe e semântica de uma extensão de consulta deve ser compatível
com a linguagem de programação de esta sendo estendida. Algumas linguagens de consultas
generalizam a sintaxe de linguagens de consultas relacionais, por exemplo, SQL ou QUEL,
para suportar objetos. Alguns linguagens de programação para banco de dados (Taxis, por
exemplo) e linguagens de programação persistentes (O++, por exemplo) generalizam a
sintaxe de comandos interativos para suportar predicados. Finalmente, algums linguagens de
consulta possuem sintaxe completamente diferentes, por exemplo, ObjectStore’s.
Outros requisitos importantes que podemos citar são: suporte a tipos abstratos de
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
23
dados e suporte uniforme a pesquisa em dados persistentes e temporários.
A LINGUAGEM DE CONSULTA
Um comando de pesquisa em OQL[C++] é uma extensão de um bloco de consulta
SQL representado da seguinte forma:
<resultado> = SELECT <objetos>
FROM <variável de escopo> IN <conjunto de objetos>
WHERE <predicado>
A cláusula SELECT identifica o tipo de objetos no conjunto de objetos que serão
retornados pela consulta. A cláusula FROM declara a variável de escopo e o conjunto de
objetos que será consultado. Várias variáveis de escopo sobre vários conjunto de objetos
podem ser declaradas nesta cláusula. A cláusula WHERE especifica o predicado que define
as propriedades a serem satisfeitas pelo objetos que serão recuperados. OQL[C++] aceita
certas expressões em C++ quando ela faz sentido na consulta. Dessa forma combinando
aspectos de SQL e da sintaxe de C++ será disponibilizada uma capacidade de consulta a
objetos que atende tanto a desenvolvedores de banco de dados e programadores em C++.
A seguir mostraremos, através de exemplo de consultas no esquema da figura 01,
algumas das característica de OQL[C++].
Class Pessoa{
Public:
Pessoa ( Nome& ,Endereço&, Nascimento&);
Int idade();
String sexo();
Nome nome();
Endereço Residencia();
Virtual void_print ();
Void conjunto_nome();
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
24
Void conjunto_endereço();
…};
class Fisioterapeuta: public Pessoa {
public:
String Especialidade();
Endereço Consultorio();
String Telefone();
Virtual void print();
…};
class Registro_Medico{
public:
int N_Paciente();
Date data;
String diagnostico();
List <Lab_Teste> lab_testes();
List <Raio_X> raio_x_testes();
};
class Paciente: public Pessoa{
public:
int identidade();
Fisioterapeuta doutor_da_familia();
Set <Registro_Medico> registros();
Virtual void print ();
…
};
Figura 01. Esquema de um BD em OQL[C++]
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
25
Exemplo 1: Quais os pacientes que são tratados pelo Dr. James.
Set <Paciente> result;
Result = SELECT p FROM Paciente p IN Pacientes
WHERE p.familia_doutor( ).nome( ) = ”James”;
Nesta consulta a variável de escopo p refere-se aos objetos de um conjunto chamado
Pacientes do tipo Set<Paciente>. A expressão p.familia_doutor( ).nome( ), chamada de path
expression, permite a navegação através do grafo de composição de objetos de maneira
simplificada. Path expression provêem um mecanismo uniforme para a formulação de
consultas que envolvem composição de objetos e funções herdadas.
O resultado da consulta é um conjunto de objetos do tipo Set<Paciente>, o qual é
atribuído a uma variável result do mesmo tipo.
Esta consulta pode ser reescrita utilizando recursos como ponteiros tendo como
resposta o mesmo resultado, ou seja,
Result = SELECT p FROM Paciente *p IN Pacientes
WHERE p-->familia_doutor( ).nome( ) = ”James”;
Exemplo 2: Selecionar as pessoas que são tratadas pelo Dr. James.
Set<Pessoa> result;
Result = SELET (Pessoa) p FROM Paciente p IN Pacientes
WHERE p.familia_doutor ( ).nome( ) = “James”;
Neste exemplo, podemos verificar que os tipos retornados pelas consultas podem ser o
mesmo tipo dos objetos sendo consultados, no caso Pacientes, tipo ancestrais a tais objetos ou
um novo tipo. A consulta do Exemplo 3 mostra uma consulta que retorna um novo tipo de
objeto, ou seja, usa os construtores C++ como parte da cláusula SELECT para criar um
conjunto de objetos de um novo tipo.
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
26
Exemplo 3: Recuperar os nomes e as idades do pacientes com mesmo de 10 anos.
Class Novo_Obj
{
Novo_Obj ( Nome&, int& );
}
Set <Novo_Obj> result;
Result =SELECT Novo_Obj (p.nome( ), p.idade( ))
FROM Paciente p IN Pacientes
WHERE p.paciente( ) < 10
É possível usa funções definidas pelo usuário nas cláusulas FROM e WHERE da
consulta. O exemplo 4 mostra um exemplo do uso de tal recurso.
Exemplo 4: Recuperar os pacientes cujo raio X indica um caso de Tuberculose.
Set<Paciente> result;
result = SELECT p FROM Paciente
WHERE EXISTS (
SELECT * FROM Registro_Medico r IN p.registros( )
WHERE EXISTS ( SELECT * FROM Raio_x x IN r.raio_x_testes( )
WHERE raio_x_igual(x.figura( ), padrao )
)
);
onde raio_x_igual é uma função booleana definida pelo usuário que compara a representação
digital de x.figura( ) de um raio-x com a variável padrão do tipo Bitmap, tendo como
conteúdo um raio-x típico de um tuberculoso.
Além de comandos de consultas, OQL[C++] suporta, como SQL, comandos de
modificações do tipo UPDATE, INSERT e DELETE aplicados para modificar o estado de
um subconjunto de objetos especificados por um predicado.
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
27
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
28
INTERFACES VISUAIS
DE CONSULTAS
7
Visando proporcionar aos usuários uma forma rápida e simples para acessar grandes
volumes de dados, diversas pesquisas tem sido feitas em torno do desenvolvimento de
ferramentas visuais de consultas a bancos de dados.
Algumas interfaces visuais de consultas foram propostas como forma de suprir as
deficiências de linguagens de consulta não procedurais, tais como QUEL ou SQL. Estas
linguagens embora eficientes na formulação de consultas ad hoc, são restritas a usuários
especialistas na área. As primeiras linguagens visuais de consulta foram a Cupid [MS75] e
QBE ( Query-by-Example) [Zlo77].
Existem outros fatores que estimulam à adoção de técnicas visuais nas interfaces de
consultas modernas, são [FS97]:

O usuário pode construir sua consulta especificando seus componentes em
qualquer ordem;

O usuário tem uma visão da sua consulta na tela como ela está sendo construída, e
pode adicionar/retirar componentes da consulta até que a visão corrente represente
a consulta desejada;

O usuário não precisa conhecer a estrutura do banco de dados para formular a
consulta;

A utilização de imagens, ao invés de linguagens textuais;

O surgimento do paradigma de orientação a objetos;


O crescimento da complexidade das aplicações de bancos de dados;
Crescimento da necessidade de acessar BD’s por usuários não especializados.
Propostas iniciais surgiram de explorar os conceitos representados graficamente dos
modelos semânticos como construtores de linguagens de consulta. Mais tarde, esta
abordagem foi aplicada aos modelos orientado a objetos, onde o acesso aos dados é feito
através da "navegação" sobre a estrutura complexa de um esquema conceitual ( intenção do
banco de dados), percorrendo sobre as classes e relacionamentos hierárquicos entre classes. A
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
29
visualização do domínio da aplicação se torna mais próxima da visão real que o usuário tem
sobre os dados.
Sistemas com o propósito de extrair informações de um banco de dados têm sido
desenvolvidos, dentre eles podemos citar os Sistemas Visuais de Consultas (SVC)[Cea97].
Os SVCs incluem uma linguagem de consulta para expressar consultas em um formalismo
visual e uma estratégia de consulta e interação. Eles são uma alternativa às linguagens
textuais de consulta, que são dificilmente exploradas por usuários novatos; e são orientados a
um amplo espectro de usuários que tem habilidades técnicas limitadas e geralmente, não tem
conhecimento da estrutura interna do BD.
EVOLUÇÃO DAS INTERFACES PARA BANCOS DE DADOS
As interfaces visuais têm evoluído consideravelmente nos últimos anos. Em [FS97] é
feito uma avaliação para SVCs. Utilizando-se de tal avaliação mostraremos os SVCs
abordando os seguintes aspectos:
1. Evolução das principais representações visuais;
2. Evolução e surgimento de novas estratégias de interação;
As representações visuais mais utilizadas nos SVCs são: tabular, diagramática,
icônica e híbrida. Tais representações serão descritas a seguir.
INTERFACES TABULARES
Na representação tabular, os dados são organizados e visualmente representados como
tabelas e os relacionamentos entre os dados como uma justaposição de retângulos. Esta
representação é bastante adequada para a estrutura do modelo relacional. A primeira interface
tabular conhecida mundialmente é a linguagem QBE (Query-By-Example)
Em QBE as tabelas são mostradas visualmente, sobre as quais o usuário formula sua
consulta preenchendo os atributos da tabela com exemplos e restrições necessárias para o
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
30
resultado da consulta. QBE tornou-se melhor que as linguagens textuais desde que, os
usuários não precisam memorizar os nomes dos componentes de uma tabelas.
Na década de 90, mesmo com o paradigma de orientação a objeto integrado ao banco
de dados, novas interfaces tabulares foram surgindo devido a simplicidade da representação
tabular e do modelo relacional. A estas novas interfaces tabulares foram incorporadas novas
características que possam satisfazer a demanda de novas aplicações.
INTERFACES DIAGRAMÁTICAS
Diagramas em um SVC representam visualmente entidades e relacionamentos entre
entidades, de uma forma similar a estrutura de um grafo. Sua popularidade surgiu a partir da
representação visual dos modelos semânticos, em particular o modelo E-R.
A primeira interface diagramática surgiu em 75, a interface Cupid, baseado na
álgebra relacional. Como o QBE, Cupid foi projetada como uma interface para um banco de
dados relacional e utiliza símbolos para representar componentes de uma consulta. O usuário
seleciona componentes relevantes e constrói sua consulta a partir destes componentes.
Assim como as interfaces tabulares, novas abordagens foram incorporadas às
interfaces diagramáticas de forma a fortalecer o seu poder de visualização.
Como exemplo de interfaces diagramáticas podemos citar: Picasso [KKS88], G-OQL
[Ty88], GOOD [GPT93], ConTOM [FS95], QBD* [ACS90] , WINONA [RK95]e AMAZE
[BFG95] ( ambas com visualização diagramática tridimensional), etc.
Recentemente os diagramas são utilizados para facilitar a visualização da estrutura
dos documentos na Web.
INTERFACES ICÔNICAS
As interfaces icônicas representam um aperfeiçoamento na interação homemmáquina. Isto se deve ao poder de metáfora que os ícones proporcionam na representação
visual de um conceito ou de uma função. Foi a partir da representação icônica que surgiu a
metáfora mais popular dentro das plataformas Macintosh, Ms-Windows e X-Windows, a
metáfora desktop. Em uma metáfora desktop, arquivos, programas e dispositivos são
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
31
representados como entidades gráficas que simulam objetos que podem ser encontrados em
um ambiente de escritório: documentos, diretórios, caixas de correio, etc.
Os ícones em um SVC representam tanto as entidades do mundo real como as
funcionalidades disponíveis do sistema. Contudo, a representação icônica não se tornou
popular em banco de dados pelo seguinte motivo: o esquema conceitual do banco de dados
não é visualizado explicitamente nos SVCs icônicos, desde que não se consegue representar
explicitamente o relacionamento entre as entidades.
A primeira interface icônica para banco de dados que se tem notícia é a
IconicBrowser [Tea90], depois vieram as interfaces Iconografer [DW91] e QBI [MC95].
Recentemente surgiu uma interface icônica para bancos de dados orientado a objetos,
denominada Oggetto Desktop [KMS96], que integra a metáfora desktop com a orientação a
objeto. Esta interface permite a navegação sobre os relacionamentos é-um e instância-de,
utilizando os componentes diretórios ( representando uma classe ou subclasse) e arquivos (
representado um objeto instância de uma classe), amplamente usados em sistemas
operacionais. Outras interfaces recentes são Marmota [CMP96], que realiza consultas
remotas na Web e uma interface que manipula bancos de dados de pinturas, através da
filtragem de um subconjunto dos dados , feitas por ícones representando cores, dentro das
categorias de tonalidades, luminosidade e saturação.
INTERFACES HÍBRIDAS / MULTIMODAIS
Devido ao crescimento da complexidade das aplicações e dos diversos tipos de
usuários que as utilizam, novas interfaces surgiram permitindo o acesso aos dados através da
combinação de diferentes representações visuais. Uma interface interativa que suporta estas
características são denominadas de interface híbridas ou multimodal.
Em
interfaces
multimodais,
os
modos
de
interação
são
manipulados
independentemente, enquanto que, na abordagem híbrida os diferentes modos são integrados.
A abordagem híbrida surgiu como uma forma de compensar a deficiência de uma única
representação visual em alguns aspectos, por exemplo, ícones relacionados através de
conectores como os diagrama, podem representar visualmente um esquema conceitual.
Os SVCs híbridos/multimodais surgiram na década de 80. Recentemente surgiram
novas interfaces híbridas/multimodais tais como interface que implementam consultas
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
32
dinâmicas. Podemos citar como exemplos de interfaces híbridas/multimodais: SKI[KM84],
Sicon [GN88], Pasta-3 [KM89], IDDS [Nor93], MIGI [LH93], Medusa [HN93] , Visionary
[BMR96], etc.
Visionary é uma linguagem visual de consulta diagramática e icônica. Sua filosofia
consiste na abordagem ponto-de-vista do usuário, definida por uma entidade correspondente
ao objetivo principal da consulta. A partir de uma seqüência de transformações internas,
transparentes ao usuário, o ponto-de-vista do usuário é gerado como uma árvore direcionada
sobre o grafo do banco de dados, cuja raiz deve ser a entidade objetivo. A partir deste grafo,
o sistema gera uma visão para o usuário e dentro desta visão o usuário formula sua consulta.
EVOLUÇÃO DAS ESTRATÉGIAS DE INTERAÇÃO
Em [FS97] é feito uma análise da evolução das interfaces para banco de dados
segundo duas estratégias de interação: manipulação da estrutura e manipulação do conteúdo.
Na primeira estratégia o usuário manipula a estrutura do esquema conceitual de forma a
acessar os dados, enquanto que na segunda o usuário percorre sobre o conteúdo do banco de
dados, sem precisar ter conhecimento da estrutura conceitual do mesmo. A seguir faremos
um descrição da evolução destas duas estratégias.
MANIPULAÇÃO DA ESTRUTURA
A forma de navegação depende da representação visual adotada.
Considerando a representação tabular, uma estratégia de navegação mais popular foi
adotada pela interface tabular QBE: a abordagem by-example. Dentro desta abordagem, o
usuário fornece um exemplo da resposta e o sistema identifica o objetivo generalizando tal
exemplo. Todas as linguagens by-example adotaram esta estratégia.
Considerando a representação icônica, a maioria das interfaces utilizaram a
abordagem de composição de conceitos. De uma forma simplificada, as consultas são
0especificadas através da seleção e sobreposição de ícones.
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
33
Na representação diagramática, diversas estratégias de interação foram propostas, a
mais popular for a simplificação/navegação sobre os diagramas, onde o usuário extrai do
esquema original os componentes necessários para a sua consulta e o sistema gera uma subesquema denominado esquema de interesse.
O usuário “navega” sobre o esquema de
interesse formando um path correspondente a sua consulta. Um path é constituído de uma
seqüência ordenada de junção entre pares <entidade, relacionamente> dentro do esquema
conceitual, seguindo por uma seleção final e projeção.
MANIPULAÇÃO DO CONTEÚDO
Na manipulação do conteúdo, o usuário faz uma navegação sobre os dados ao invés
da navegação estrutural. A técnica mais popular de manipulação de conteúdo é o browsing,
onde o usuário percebe o relacionamento entre os metadados através da navegação sobre os
dados.
Entre as interfaces de acesso ao conteúdo podemos destacar LID [Fog84] e G+
[CMW88]. Em LID, o usuário navega sobre uma tupla e visualiza o banco de dados dentro da
perspectiva daquela tupla, ou seja, a interface mostra os relacionamentos em que aquela tupla
participa assim como as entidades relacionadas.
Houve um crescimento de interfaces para bancos de dados com acesso ao conteúdo na
década de 90. Isto se deve a três fatores:

Os problemas em se manipular a estrutura conceitual dos dados;

A popularização das ferramentas browsing na Web;

A nova abordagem de consulta dinâmica utilizada em algumas interfaces.
Consultas dinâmicas envolvem o controle interativo do usuário sobre parâmetros
visuais de consulta que geram um rápido e animado display visual do resultado do banco de
dados. A interação com as interfaces que utilizam a abordagem de consulta dinâmica se
processa da seguinte forma: tanto os dados de entrada como o de saída são visualizados de
uma mesma forma. O usuário obtém os seus dados de interesse através da manipulação direta
de componentes gráficos, por exemplo, um slider, que representa um domínio de valores
numéricos ou uma seqüência de nomes correspondente a um atributo da aplicação.
Na
figura a seguir mostraremos um exemplo de uma consulta dinâmica. O lado esquerdo da
figura representa um display de pontos dentro do espaço salário-idade, onde cada ponto
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
34
representa um empregado com seu correspondente salário e idade. O formato de cada ponto
representa o departamento do empregado. O lado direito da figura é ocupado por sliders, um
slider para cada atributo (os atributos são idade, salário, nome e departamento). Os extremos
dos sliders representam o valor mínimo e o valor máximo do atributo.
EMPREGADOS
100
19



IDADE
 


 

 
 

  

 

 
IDADE

60
27
950
SALÁRIO
Ana
Zélia
NOME
Arte
Treinamento
SALÁRIO
0
0
SALARIO
1000
Figura 02. Representação de uma Consulta Visual
A cada manipulação do slider, o resultado da consulta se modifica dinamicamente e
rapidamente, ou seja, os pontos desaparecem ou reaparecem, dependendo da mudança de
valor dos atributos.
Aplicativos que utilizam consultas dinâmicas começaram a surgir somente na década
de 90. Aplicações geográficas são perfeitamente adequadas para consultas dinâmicas.
Algumas interfaces mais recentes utilizam o conceito de consultas dinâmicas, por exemplo,
HIBROWSE [EFP95] e TVQL [HR95], esta ultima utiliza sliders para uma análise temporal.
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
35
ALGUMAS INTERFACES VISUAIS
A seguir faremos uma breve descrição de algumas interfaces visuais de consulta
existentes.
- G-OQL é uma interface visual para linguagens de consulta orientada a objeto OQL.
Uma consulta OQL é considerado uma função, que aplicada ao BD, retorna um sub-BD com
o mesma estrutura do BD original. A estrutura de um esquema de BD em OQL consiste
basicamente de classes e associações entre estas classes dentro de um diagrama, e na entrada
de operadores de associações entre as classes relacionadas;
- O sistema PICASSO apresenta uma linguagem de consulta visual para BD’s sob o
modelo de Relação Universal. A formulação da consulta é feita sobre hipergrafos utilizando o
mouse com três botões, o botão da esquerda é usado para seleção de atributos, o do centro
para elaboração de predicados, e o da direita para escolha de opções no menu de
processamento de consultas. Uma ferramenta de apoio permite a navegação sobre o resultado
da consulta e a construção de consultas complexas a partir do resultado de consultas simples;
- A interface do sistema GOOD apresenta três componentes básicos: esquema
conceitual, esquema de consulta e instância de BD’s. Os três componentes estão dentro de
uma mesma representação visual, denominados de grafos de esquema, grafo de consulta e
grafo de instância, respectivamente. O grafo de consulta é abstraído a partir da aplicação de
uma primitiva sobre o grafo de esquema, através da duplicação e identificação de nodos e
ligações componentes deste grafo;
- A interface IQL é uma proposta de interface visual para banco de dados relacional.
Além de fornecer uma interação visual durante a formulação da consulta SQL, fornece
mecanismos de otimização das mesmas. Usuários têm a seu dispor uma variedade de
mecanismos de abstração, tais como, denominação de consultas e uso de parâmetros,
permitindo uma reutilização modular e genérica, possibilitando, desta forma, uma abordagem
de orientação a objetos;
- O sistema GOODIES vem com uma abordagem inteiramente nova para o
desenvolvimento de interfaces para BD’s. Tal sistema não vem acoplado a um SGBDOO
específico, ele se fundamente nas principais características de um modelo de dados orientado
a objetos e foi construído de modo independente de uma implementação específica destas
características. As informações sobre esquemas e dados em GOODIES, são apresentadas
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
36
textualmente, em janelas padronizadas, com facilidades de organização, navegação e consulta
sobre as mesmas.
- ConTOM (Consultas TOM) é um sistema gráfico de consultas sob o modelo de
dados orientado a objetos TOM (Temporal Object Model ). ConTOM é constituído de
operadores gráficos, de forma a expressar as consultas, e uma variedade de funcionalidades
que facilitam a interação com o usuário. A especificação a nível de representação visual de
um esquema conceitual, utilizando o modelo TOM, é denominada de Esquema Conceitual
Gráfico (ECG).
Uma consulta em ConTOM é expressa visualmente através da manipulação direta
sobre qualquer componente de um ECG. A elaboração de uma consulta implica na criação de
esquemas intermediários, obtidos pelos operadores gráficos sobre as classes componentes do
esquema, denominados Operadores Gráficos de Consultas (OGC), até a formulação completa
da consulta, gerando um sub-esquema do ECG, denominado de Esquema de Resposta (ER).
O ER especifica qual a porção do BD a ser recuperada pela consulta e possui a mesma
estrutura do EG original, podendo ser salvo como uma visão e reutizaá-lo para consultas
posteriores.
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
37
CONCLUSÃO
8
Através deste estudo sobre consultas e seus processamentos percebemos que esta é
uma área onde pesquisas são feitas buscando melhorar a interação usuário-BD. Este fato fica
bem claro em tratando-se de interfaces visuais de consultas.
Em tratando-se de Datalog e Datalog1s, é usado todo o poder expressivo da lógica para
construir sistemas de bancos de dados. Uma das características de maior expressividade neste
tipo de sistema é a capacidade de efetuar consultas recursivas sobre os dados.
Outro aspecto que merece destaque, é a tentativa de estender linguagens procedurais
convencionais em linguagens procedurais com persistência e capacidade de consultas a dados
(objetos). Este caminho deve-se ao fato de linguagens procedurais oferecem sistemas de
tipos bem mais sofisticados que as linguagens puramente de consulta, por exemplo SQL.
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
38
REFERÊNCIAS
BIBLIOGRÁFICAS
9
[AC93]
Ahad, R., and Cheng, T. 1993, OpenODB – An Object-Oriented Database
Management System for Commercial Applications, HP Journal, Vol 44 No. 3,
20-30.
[ACS90]
M.Angelaccio, T. Catarci, and G. Santucci. QBD*: A graphical query language
with recursion. IEEE Transaction on Software Engineering, 16(10):11501163,1990.
[AD92]
Ahad, R., and Dedo, D. 1992. OpenODB from Hewlett-Packard: A Commercial
OODBMS. Journal of Object Oriented Programming, Vol. 4 No. 9
[BMR96]
F. Benzi, D. Maio and R Rizzi. Visionary: Visual query language based on the
user viewpoint approach. In KennedyJ., editor, Third Internacional Workshop
on User Interfaces to Database Systems – Endinburgh, 1996.
[Cea97]
T. Catarci et al. Visual query systems: Analysis and comparison. Journal of
Visual Languages and Computing,(8):215-260, 1997.
[CMW88] I.F. Cruz, A.O.Mendelzon, and P.T. Wood. G+: Recursive queries without
recursion. In Proc. Of the 2nd int. Conference on Expert Database Systems,
pages 355-368, 1998.
[DW91]
S.W. Draper and K.W. Waite. Iconographer as a visual programming system. In
Diaper D. and Hammond N., editors, HCI 91 People and Computers VI:
Usability Now !, Cambridge University Press, pages 171-185, 1991.
[EFP95]
G.P.Ellis, G.E. Finlay, and A.S. Pollitt. Hibrowser for hotels: Bridging the gap
between user and system views of a database. In Sawier P., editor, Interface to
Datadase Sysyems, Lancaster 1994, Workshop in Computing, Springer-Verlag,
London, pages 46-92, 1995.
[EN94]
R. Elmasri & S.B.Navathe, “ Fundamentals of Database Systems”, 1994.
[ES90]
Ellis, M. A. and Stroustrup, B. 1980. The Annotated C++ Reference Manual,
Addison-Wesley, Reading, Mass.
[ES94]
H. Korth & Silberschatz, “ Sistemas de Bancos de Dados” , Makron Books,
1994.
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
39
[FEA89]
Fishman, D.H. et. Al. 1989. Overview of the Iris DBMS. In: Object Oriented
Concepts, Databases and Applications. W.Kim and F.H. Lochovsky, eds. ACM,
New York.
[Fog84]
D. Fogg. Lessons from a “living in a database”graphical query interface. In
ACM SIGMOD Conf. On the Management of Data, pages 100-106, 1984.
[FS95]
S.L.Fernandes-Silva, “ConTOM – Um Sistema de Consultas Gráficas a um
Banco de Dados Temporal Orientado a Objetos”, Dissertação de mestrado,
COPIN/UFPB, 1995.
S.L. Fernandes-Silva, “Integrando Aspectos Temporais no Acesso e na
Usabilidade de Interfaces Visuais Adaptativas a Bancos de Dados Históricos” ,
1997.
[FS97]
[GN88]
I.P. Groette and E.G. Nilsson. Sicon: An icon presentation module for an e-r
database. In Proc. Of the 7th Conf. On Entity-Relationship Approach, Roma,
Italy, pages 271-289, 1998.
[GPT93]
M. Gemis, J. Paredaens, and I. Thyssens. A visual database management
interface based on good. In Cooper R., editor, Interface to Database System,
Glasgow 1992, Workshop in Computing, Spriner-Verlag, London, pages 155175, 1993.
[HN93]
P. Hietala and J. Nummenmaa. A multimodal database user interface and
framework supporting user learning and user interface evaluation. In Cooper R.,
editor, Intefaces to Database System , Glasgow 1992, Workshop in Computing,
Springer-Verlag. London, pages 392-405, 1993.
[HP92]
Hewlett-Packard. 1992. OpenODB Reference Manual B3185A.
[HR95]
S. Hibino and E. Rundensteiner. Visual query language for identifying temporal
trends in video data. In Int. Workshop on Multimedia Database Management
System, New York, pages 74-81, 1995.
[Kim95]
W. Kim , “Modern Database Systems”, Assison Weslwy, 1995.
[KKS88]
H. J. Kim, H. F Korth, and A Silberschatz. Picasso: A graphical query language.
Software Practice and Experience, 18(3)169-203, 1998.
[KM89]
M. Kuntz and R. Melchert. Pasta-3’s graphical query language; Direct
manipulation, cooperative queries, full expressive power. In. Proc. Of the 15th
Int. Conf. On Very large Databases, Amsterdam, Holland, 1989.
[KMS96]
A.
Kadyamatimba, J. Mariani, and P. Sawyer. Desktop objects: Directly
manipulating data and metadata. In Kennedy J., editor., Third International
Workshop on User-Interfaces to Database Systems, Edinburgh, 1996.
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
40
[LH93]
[Lyn91]
J. Littlehales and P. Hancox. The problems of integrating to publicity available
databases. In Cooper R., editor, Interfaces to Database System, Glasgow 1992,
Workshop in Computing, Springer-Verlag, London, pages41-55, 1993.
Lyngbaek, P. 1991. OSQL: A Language for Object Databases. Hewlett-Packard
Laboratories technical report HPL-DTD-91-4.
[MBW80] Mylopoulos, J., Bernstein, P.A.. and Wong, H.K.T. 1980. A Language Facility
for Designing Database-Intensive Applications. Proceedings of ACM
Transactions on DatabaseSystems, Vol 5 No.2.
[MC95]
A. Massari and P.K. Chrysanthis. Visual query ofencapsulated objects. In Proc.
Of the 5th Int. Workshop on Research Issues on Data Engineering, Taipei,
Taiwan, pages18-25, 1995.
[MS75]
N. McDonald and M Stonebraker. Cupid- the friendly query language. In Proc.
ACM Pacific 75 Conf., pages 271-131, 1975.
[Nor93]
M.C. Norrie. Specification of Database Systems. Workshop in Computing
Series, Springer-Verlag, 1992.
[RK95]
M. Rapley and J. Kennedy. Three dimensional interface for an object-oriented
database. In Cooper R., editor, Interface to Database System, Lancaster 1994,
Workshop in Computing, Springer-Verlag, London, pages 143-167, 1995.
[Shi80]
Shipman, D. 1981. The Functional Data Model and the Data Language
DAPLEX. ACM Trans. On Database Systems, Vol 6 No. 1
[Tea90]
K. Tsuda et al. Iconic browser: An iconic retrieval system for object-oriented
databases. Journal of Visual Languages Computing, 1(1):59-76, 1990.
[Ty88]
F. Ty. G-opl: Graphical interface to the object-oriented query language oql.
Master’s thesis, University of Florida, 1998.
[WLH90]
Wilkinson, K., Lynbaek, P.,and Hasan, W. 1990. The Iris Architecture and
Implementation . IEEE Transactions on Knowledge and Data Engineering, Vol
2. No.1.
[ZCF97]
C. Zaniolo, S. Ceri, C.Faloutsos, R. Snodgrass, V. Subrahmanian & R Zicari,
“Advanced Database Systems” , Morgan Kaufmann, 1997.
[Zlo77]
M. Zloof. Query-by-example. IBM Systems Journal, 21(3):324-343, 1977.
UFPB/CCT/DSC/COPIN – BDs AVANÇADOS - CONSULTAS E SEUS PROCESSAMENTOS
41