BDT-Resumo - Computação UFCG

BANCOS DE DADOS TEMPORAIS: Um Resumo
Ed Porto Bezerra
1. Introdução
Um Banco de Dados Temporal é aquele que dá um tratamento diferenciado a informações
temporais, evitando sua remoção do banco de dados quando ocorre uma atualização. Em [Sn92] foi
apresentada uma classificação de Bancos de Dados Temporais que, após algumas alterações,
continua sendo utilizada até hoje. Foram identificados dois possíveis tempos que podem ser
associados às informações em um banco de dados. O tempo de validade é o tempo onde o fato foi
verdadeiro na realidade modelada e tempo de transação é o tempo quando o fato foi armazenado
no banco de dados.
De acordo com sua capacidade de processar diferenciadamente estes tempos, podem ser
identificados quatro tipos de bancos de dados temporais:
- Bancos de dados instantâneos: são aqueles que não incorporam nenhum parâmetro temporal. O
banco de dados reflete tão somente, a situação atual do sistema.
- Bancos de dados de tempo de transação: são os em que é registrado o instante em que uma
informação é adicionada ao banco de dados e quando ela é corrigida. Com isso pode-se percorrer o
banco de dados no passado.
- Bancos de dados de tempo de validade: são aqueles em que é possível informar além das novas
informações o tempo quando elas se tornaram ou tornarão válidas na realidade.
- Bancos de dados bitemporais: são os que suportam tempo de transação e tempo de validade e
combina as características dos dois tipos anteriores. Eles permitem mudanças retro-ativas e pós-
ativas;
a história completa destas mudanças e os valores originais mudados estão todos
disponíveis.
Em um Banco de Dados Temporal associam-se intervalos de tempo às informações de
interêsse (entidades, atributos, relacionamentos), significando o tempo de validade destas
informações. Na terminologia do modelo relacional, fala-se em versionamento de tuplas se os
tempos são associados às tuplas e em versionamento de atributos se cada atributo pode ter o seu
tempo, refletindo o histórico deste atributo.
Mostraremos, no próximo parágrafo, um formalismo sobre como informações temporais
podem estar relacionadas entre si, permitindo assim desenvolver um raciocínio temporal. Em
seguida introduzimos a linguagem TSQL2, que se propõe a ser um padrão de acesso a bancos de
dados temporais. A penúltima parte será dedicada a discussão da relação dos bancos de dados
temporais com bancos de dados dedutivos, bancos de dados ativos e informação incompleta;
enquanto que na última parte faremos as conclusões.
2. A Lógica de Intervalos de Allen
A lógica de intervalos de Allen [Al83] é baseada em intervalos e discute as propriedades
que se mantêm sobre os mesmos. Ela é usada como base em vários modelos e linguagens de
consulta temporais, inclusive em TSQL2 [Sn95].
Há um conjunto básico de relações primitivas, mutuamente exclusivas, entre intervalos
temporais. Cada relação é representada por um predicado na lógica os quais são mostrados na
tabela abaixo:
RELAÇÃO
1) X antes de Y
SÍMBOLO
<
SÍMBOLO PARA O
INVERSO
>
ILUSTRAÇÃO
xxxx yyyy
2) X igual a y
=
=
3) X encontra Y
4) X sobrepõe Y
e
o
ei
oi
5) X durante Y
d
di
6) X inicia Y
s
si
7) X termina Y
f
fi
xxxx
yyyy
xxxxyyyy
xxxxx
yyyyy
xxx
yyyyyyy
xxxx
yyyyyyyyy
xxx
yyyyyyyyy
São 13 relações contando-se a principal e sua inversa, exceto no caso da igualdade onde a inversa e
a pricipal são a mesma.
Nesta lógica, está incluida uma tabela de transitividade para derivação de novos fatos a
partir dos já conhecidos. Por exemplo, uma regra é:
s(X,Y) & o(Y,Z)  <(X,Z)  o(X,Z)  e(X,Z)
3. A Linguagem de Consulta Temporal TSQL2:
Foi desenvolvida, como esforço conjunto de 18 pesquisadores uma extensão da linguagem
de consulta SQL para processar informações temporais em bancos de dados relacionais,
denominada TSQL2 [Sn95]. Abordaremos, por meio de exemplos, numa espécie de pequeno
tutorial, tópicos da TSQL2 como: especificação de esquemas, cláusula FROM (reestruturação),
seleção de tempo de validade, projeção de tempo de validade, comandos de atualização, tempo de
transação, indeterminação temporal, granularidade temporal e versionamento de esquema.
Utilizamos um cenário de registros de pacientes incluindo informação sobre drogas
prescritas para cada paciente. A tabela prescrição é especificada pelo seguinte comando:
CREATE TABLE prescricao
(nome, medico, droga, dosagem, frequencia INTERVAL MINUTE)
AS VALID DAY AND TRANSACTION
Esta tabela é do tipo tabela bitemporal, como denotado pela cláusula AS VALID [STATE]
<GRANULARIDADE> [AND TRANSACTION]. O tempo de validade tem a granularidade de dia
e especifica o período durante o qual a droga foi prescrita. A granularidade do tempo de transação é
definida pelo sistema. Para inserir uma nova prescrição, poder-se ia ter:
INSERT INTO prescricao
VALUES (‘Joana’, ’Dr. Zen’, ‘Prozac’, ’100 mg’, INTERVAL‘8:00’ MINUTE)
VALID PERIOD ‘[1993/01/01-1993/06/30]’
Podem ser efetuadas atualizações tanto nos dados como no tempo de validade por comandos
DELETE e UPDATE adequados. Ilustramos os efeitos de atualizações pela figura abaixo.
Podemos “voltar” o banco de dados, utilizando o tempo de transação. Vejamos a seguinte consulta:
qual a história de prescrição de Joana até 01/06/1994 ?
SELECT droga
FROM prescricao AS P
WHERE nome = ‘Joana’ AND
TRANSACTION (P) OVERLAPS DATE ‘1994/06/01’
Observe-se que o tempo de transação é um intervalo que, no exemplo, deve sobrepor-se com
1.6.1994.
TSQL2 utiliza versionamento de tuplas mas, a cada alteração de algum atributo, toda a tupla é
renovada com o novo tempo deste novo valor de atributo. Assim os históricos de um atributo
específico ou da tupla como um todo (histórico do atributo chave) ficam espalhados por diversas
tuplas da tabela. TSQL2 possui uma função CAST(VALID(atributo)) que funde o histórico
espalhado retornando um intervalo único a ser usado em uma consulta. A próxima consulta mostra
o uso da função CAST, para retornar um histórico completo: quem tem usado a mesma droga por
mais de 6 meses?
SELECT nome, droga
FROM prescricao(nome, droga) AS P
WHERE CAST (VALID (P) AS INTERVAL MONTH)
> INTERVAL ‘6’ MONTH
Nesta consulta, prescrição foi reestruturada segundo os tempos de validade dos atributos
nome e droga.
Também podem ser pesquisados fatos válidos durante um tempo especificado: que drogas
foram prescritas para Joana durante 1994?
SELECT droga
VALID INTERSECT(VALID(prescricao),PERIOD ‘1994’ DAY)
FROM prescricao
WHERE nome = ‘Joana’
O resultado é uma lista de drogas, cada uma associada com um conjunto de períodos durante 1994
onde elas foram prescritas para Joana.
Um componente interessante da TSQL2 é sua capacidade de modelar indeterminação
temporal, ou seja, aos dados podem ser associados tempos possíveis. A qualidade dos dados
(chamada credibilidade) pode ser controladas via uma frase WITH CREDIBILITY na cláusula
FROM e a “plausibilidade” dos predicados será expressa por uma frase WITH PLAUSIBILITY na
cláusula WHERE. Credibilidade e “plausibilidade” são valores entre 0 e 100, sendo 100 o valor
admitido na omissão da cláusula.
Em SQL, uma mudança no esquema de uma tabela provoca a perda do esquema anterior. Já em
TSQL2, se a tabela é do tipo tempo de transação ou bitemporal, o esquema é versionado, ou seja, é
criada uma nova versão do esquema e não é perdida a versão anterior. Com isso consultas que se
referem a tempos de transação antigos podem acessar dados de um esquema diferente.
4. Áreas afins
Em um banco de dados convencional, todas as informações estão armazenadas
explicitamente no banco de dados e alterações só ocorrem com a execução, pelo usuário, de alguma
operação de atualização do banco de dados. Esta situação pode ser modificada com a inclusão de
regras de dedução e regras de produção. Um sistema que além dos dados armazena regras de
dedução pode, a partir dos dados explícitos e das regras, deduzir uma grande quantidade de
informações implícitas (Banco de Dados Dedutivo). Com as regras de produção em certas
situações o sistema dispara automaticamente ações de atualização do banco de dados (Banco de
Dados Ativos). Vejamos dois sistemas que aplicam estes avanços aos bancos de dados temporais:
DATALOG1S (Bancos de Dados Dedutivos):
DATALOG é uma linguagem formal, baseada em cláusulas de Horn, para descrição de
aplicações de bancos de dados [Ul88]. Baseado neste formalismo, foi desenvolvido DATALOG1S
[TCG+93] (DATALOG com um sucessor), que permite acrescentar um parâmetro temporal aos
predicados. Elementos temporais são uma constante 0, uma variável T e um termo derivado T+1.
Por exemplo, um modelo que descreve um processador sequencial de dados X, Y, ..., definido por
processa(X, T), poderia ser definido por:
processa(X,T)  processa-primeiro(X,T)
processa(Y, T+1)  segue(Y,X) , processa(X,T)
Considerando os fatos válidos processa-primeiro(reclamação, 0), segue(encaminhamento,
reclamação) e segue(decisão, encaminhamento) pode-se deduzir o fato processa(decisão, 3)
A linguagem EPL (Bancos de Dados Ativos):
Vejamos agora um método de especificação de combinações complexas de eventos
envolvendo dados temporais para a execução automática de ações de um banco de dado ativo. As
regras de produção são descritas em uma linguagem denominada EPL - Event Pattern Language
[MZ95]. Expressões em EPL são convertidas em DATALOG1S para definir o significado formal.
Na sintaxe baseada em regra de EPL, sequências de metas especificam sequência de eventos; sendo
que cada meta pode corresponder a: um evento básico; um evento básico qualificado por
predicados, ou um evento composto construído usando sequências, repetições, conjunções,
disjunções e negações de outros eventos (possivelemente compostos).
Um programa EPL é organizado em módulos que podem ser compilados e tratados
independentemente. A seção de declaração de eventos de um módulo, define o conjunto de tipos de
evento básico relevantes, monitorados pelo módulo. Um tipo de evento básico é denotado como
insert (Rname), delete (Rname) e update (Rname), onde Rname é o nome da relação do banco de
dados.
Um módulo EPL possui uma seção de regras. Vejamos, como exemplo, uma relação de
contas bancárias
CONTA (Num-conta, Cliente, Tipo, Saldo)
e uma regra que avisa grandes movimentos em contas de poupança.
begin MonitorConta
monitor insert (CONTA), update (CONTA), delete (CONTA)
MovimentoRelevante:
update( CONTA(X),
X.Tipo = “poupança”, X.Saldo-anterior - X.Saldo-atual > 1000)
 write (“Movimento da conta %d no tempo %s “,
X.Num-conta, asctime(X.evtime) ).
end.
A regra MovimentoRelevante é verificada a cada atualização do saldo de poupança. Se houver um
saque acima de 1000, este lançamento é comunicado. O valor de evtime será o tempo de ocorrência
do evento.
A ação associada a uma regra pode ser uma ação de escrita (como no exemplo), um
comando SQL ou uma chamada ao sistema operacional.
Informação Incompleta
Há um interesse crescente no tratamento de tempo impreciso em Bancos de Dados Temporais
[BCTP95]. Os pontos inicial e final dos intevalos de validade podem ser especificados de maneira
imprecisa. Neste caso, pode-se representar o fato de que uma tupla é válida em um período que
começou entre duas datas d1 e d2 e acabou após outra data d3. Extensões a Bancos de Dados
Relacionais Temporais tem sido propostas para tratar com informação temporal imprecisa e
qualitativa [SO87, BCTP95, GNP92]. Outras formas de imprecisão podem ser [SO87]:
1) valores nulos qualificados. Por exemplo: João ganha o mesmo que Maria, daria
tem-salario(Joao, x1) & tem-salario(Maria, x1)
2) valores negativos. Por exemplo: João não é casado com Maria, daria
casado-com(Joao, ~Maria)
3) valores relativos. Por exemplo: João ganha menos do que Maria, daria
tem-salario(Joao, < salario(Maria))
É claro que respostas de um banco de dados com informação imprecisa, também podem ser
imprecisas. Assim, considerando o exemplo da forma (3), se o salário de Maria é R$ 1.500,00, a
resposta a uma pergunta João ganha R$ 1.700,00? será NÃO; se a pergunta for João ganha menos
que R$ 1.000,00? a resposta será TALVEZ.
Também deve ser feita uma distinção entre valores de atributos que não se aplicam sempre,
por exemplo número do fax, e os que existem mas não são conhecidos e, eventualmente, alguma
informação imprecisa é disponível e seria interessante usá-la. Por exemplo, a data exata e a
localização de um encontro futuro podem não estar disponíveis, mas sabemos que acontecerá em
janeiro em Natal ou Mossoró. Esta informação imprecisa pode ser útil. Neste exemplo, todas as
recepcionistas saberiam que não podem gozar férias em janeiro. Se um gerente necessita de uma
lista de encontros em janeiro, então este encontro pode figurar na lista.
5. Conclusão
Tentamos mostrar alguns dos aspectos da pesquisa e utilização atual na área de Bancos de
Dados Temporais [TK96]. Eles têm uma importância significativa para certos tipos de aplicações e
a existência de linguagens e gerenciadores específicos, pode facilitar bastante o desenvolvimento
destas aplicações garantindo uma maior qualidade dos sistemas desenvolvidos.
Em [Bö96] são apresentados alguns protótipos desenvolvidos que poderão ser a base para o
lançamento de gerenciadores comerciais com características temporais.
- Referências bibliográficas:
[Al83] J.F.Allen, “Maintaining Temporal Knowledge about Temporal Intervals”, CACM
vol.26, no. 11, November 1983.
[BCW93] M.Baudinet, J.Chomicki e P.Wolper, Temporal Deductive Databases, em
Temporal Databases; Theory, Design and Implementation, Tansel et.al. (eds.),
Benjamin/Cummings, chap. 13, pp. 294-320, 1993.
[BCTP95] V.Brusoni, L.Console, P.Terenziani e B.Pernici, “Extending Temporal
Relational Databases to Deal with Imprecise and Qualitative Temporal Information”,
J.Clifford and A.Tuzhilin (Eds), Recent Advances in Temporal Databases, Proc. Int’l
Workshop on Temporal Databases, Zurich, Switzerland, pp.3-22, Sept. 1995.
[Bö96] M.H.Böhlen, “Temporal Database System Implementations”, SIGMOD Record,
vol.24, no.4, December 1995.
[MZ95] I. Motakis e C. Zaniolo “Composite Temporal Events in Active Databases: A
Formal Semantics”, em J.Clifford and A.Tuzhilin (Eds), Recent Advances in Temporal
Databases, Proc. Int’l Workshop on Temporal Databases, Zurich, Switzerland, pp.332351, Springer Verlag, Sept. 1995.
[GNP92] S.K.Gadia, S.S.Nair e Y.-C. Peon, “Incomplete Information in Relational
Temporal Databases”, em Proc. 18th. Conf. on Very Large Databases, Vancouver, 1992.
[SO87] U. Schiel e B.A. Oresotu “Representation and Retrieval of Incomplete Data and
Temporal Information” Tech. Report DSC-02/87, Fed. Univ. of Paraíba, 1987.
[Sn92] R.T.Snodgrass, “Temporal Databases”, Proc. of The International Conf. On GIS From Space to Territory : Theories and Methods of Spatial Reasoning, LNCS 639, pp.
22-63, 1992.
[Sn95] R.T.Snodgrass (ed.), I.Ahn, G.Ariav, D.S.Batory, J.Clifford, C.E.Dyreson,
R.Elmasri, F.Grandi, C.S.Jensen, W.Käfer, N.Kline, K.Kulkanri, C.Y.T.Leung,
N.Lorentzos, J.F.Roddick, A.Segev, M.D.Soo e S.M.Sripada, The TSQL2 Temporal
Query Language, Kluwer Academic, 1995.
[TCG+93] A.Tansel, J.Clifford, S.Gadia, S.Jajodia, A.Segev e R.Snodgrass Temporal
Databases: theory, design, and implementation, Benjamin/Cummings, Redwood City,
CA, 1993.
[TK96] V.J.Tsotras e A.Kumar, “Temporal Database Bibliography Update”, SIGMOD
Record, vol.25, no. 1, March 1996.
[Ul88] J. Ullman Principles of Database and Knowledge-Base Systems, Vol. 2, Computer Science
Press, 1988.