Linguagens declarativas são utilizadas para especificar ...



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++] 22

INTEGRAÇÃO ENTRE LINGUAGENS DE PROGRAMAÇÃO E CONSULTAS 23

A LINGUAGEM DE CONSULTA 25

INTERFACES vISUAIS DE CONSULTAS 30

EVOLUÇÃO DAS INTERFACES PARA BANCOS DE DADOS 31

INTERFACES TABULARES 31

INTERFACES DIAGRAMÁTICAS 32

INTERFACES ICÔNICAS 32

INTERFACES HÍBRIDAS / MULTIMODAIS 33

EVOLUÇÃO DAS ESTRATÉGIAS DE INTERAÇÃO 34

MANIPULAÇÃO DA ESTRUTURA 34

MANIPULAÇÃO DO CONTEÚDO 35

ALGUMAS INTERFACES VISUAIS 37

CONCLUSÃO 39

REFERÊNCIAS BIBLIOGRAFICAS 40

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.

DATALOG 2

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).

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

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.

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 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:

i) condição de desigualdade para cada objetivo. Por exemplo

Z >24.3;

ii) igualdade entre colunas contendo a mesma variável, e;

iii) igualdade entre uma coluna e uma constante.

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).

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, 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).

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).

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 = (S0,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 Kfamilia_doutor( ).nome( ) = ”James”;

Exemplo 2: Selecionar as pessoas que são tratadas pelo Dr. James.

Set 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.

Exemplo 3: Recuperar os nomes e as idades do pacientes com mesmo de 10 anos.

Class Novo_Obj

{

Novo_Obj ( Nome&, int& );

}

Set 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 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.

INTERFACES VISUAIS

DE CONSULTAS

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 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 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 homem-má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 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 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.

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 sub-esquema 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 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 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.

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.

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 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.

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.

REFERÊNCIAS

BIBLIOGRÁFICAS

|[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):1150-1163,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. |

| | |

| | |

|[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. |

|[FS97] |S.L. Fernandes-Silva, “Integrando Aspectos Temporais no Acesso e na Usabilidade de Interfaces Visuais Adaptativas a |

| |Bancos de Dados Históricos” , 1997. |

|[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 155-175, 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] |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. |

|[LH93] |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. |

|[Lyn91] |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] |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. |

-----------------------

EMPREGADOS

IDADE

0 SALARIO 1000

19 60

SALÁRIO

SALÁRIO

27 950

IDADE

100

← ((

← ( (((

← (

← ((( (

← ( ( ( (

← ( (( ( ( (

(( ( ( ( (

0

7

9

Arte Treinamento

NOME

Ana Zélia

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download