Banco_de_Dados_Temporal_teoria_e_pratica

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Bancos de Dados Temporais: Teoria e Prática 
Nina Edelweiss 
Instituto de Informática 
Universidade Federal do Rio Grande do Sul 
E-mail: nina@inf.ufrgs.br 
Resumo 
Bancos de Dados Temporais permitem armazenar todos os estados de uma 
aplicação (presentes, passados e futuros), registrando sua evolução com o 
passar do tempo. Informações temporais são associadas aos dados 
armazenados (tempo de transação e/ou tempo de validade) para identificá-
los ao longo do tempo. Modelos de dados temporais são também utilizados 
nos processos de modelagem de aplicações, devido ao seu poder de 
representar não somente os aspectos estáticos da aplicação, mas também 
seus aspectos dinâmicos e sua evolução temporal. Neste curso serão 
apresentados conceitos básicos de modelagem temporal e de bancos de 
dados temporais, aspectos relativos a consultas sobre bancos de dados 
temporais, análise da evolução de esquemas conceituais quando forem 
utilizados bancos de dados temporais, diferentes formas de implementação 
e algumas aplicações onde dados temporais são fundamentais. 
Abstract 
The whole temporal evolution of an application, including all the assumed 
states (past, present and future), can be available when Temporal 
Databases are used. The identification of data along time is made 
associating temporal information to stored data (transaction and/or valid 
time). Temporal data models are also used in application modeling 
processes, due to their ability of representing not only the static aspects, 
but also the dynamic ones and the evolution of the application with time. 
The issues presented in this course include basic concepts of temporal 
modeling and temporal databases, temporal queries, and considerations 
about schema evolution in temporal databases, different implementation 
forms, and some applications that require temporal data. 
1 Introdução 
A maior parte das aplicações atuais têm necessidade de manipular, de 
alguma maneira, informações históricas – dados relativos a estados 
passados da aplicação. Os SGBD convencionais, no entanto, não 
proporcionam suporte a estas informações. A necessidade de suprir esta 
lacuna fez com que nos últimos 20 anos muitas pesquisas tenham sido 
realizadas na área de Bancos de Dados Temporais, com o objetivo de 
definir conceitos e estratégias para tratar de informações históricas. As 
publicações destas pesquisas foram reunidas em diversas coletâneas de 
bibliografias [Bolour 82, McKenzie 86, Stam 88, Soo 91, Kline 93, Tsotras 
96, Wu 97]. 
Bancos de Dados Temporais permitem armazenar todos os estados de 
uma aplicação (presentes, passados e futuros), registrando sua evolução 
com o passar do tempo [Clifford 95, Edelweiss 94, Jensen 97, Özsoyoglu 
95, Tansel 93, Zaniolo 97]. Para que isto seja possível, informações 
temporais são associadas aos dados armazenados, identificando quando a 
informação foi definida ou o tempo de sua validade. 
A noção de tempo, como datas, períodos, duração de validade de 
informações, intervalos temporais, surge em diferentes níveis: (i) na 
modelagem de dados, (ii) na linguagem de recuperação e manipulação de 
dados, e (iii) no nível de implementação do SGBD. 
No presente curso serão abordados diversos aspectos relativos a 
Bancos de Dados Temporais. No capítulo 2 será feita uma breve 
apresentação de conceitos relativos a representação de informações 
temporais, sendo os diferentes tipos de Bancos de Dados Temporais 
apresentados no capítulo 3. O capítulo 4 apresenta algumas considerações 
a respeito de consultas realizadas sobre Bancos de Dados Temporais. 
Diferentes enfoques para modelos de dados temporais, base ados em 
modelos relacionais, E-R e orientados a objetos serão vistos no capítulo 5. 
A evolução do esquema conceitual com o passar do tempo é outro aspecto 
importante, necessário para a representação da evolução da aplicação que 
está sendo modelada. As implicações desta evolução quando se trabalha 
com Bancos de Dados Temporais são abordadas no capítulo 6. Alguns 
aspectos de implementação de BD Temporais são analisados no capítulo 7 
e, para concluir, no capítulo 8 são analisadas algumas áreas de aplicação 
nas quais a utilização deste tipo de bancos de dados é importante. 
2 Conceitos de Representação Temporal 
Este capítulo tem por finalidade introduzir o leitor nos principais conceitos 
relativos à representação de aspectos temporais em bancos de dados. A 
forma de representação escolhida se reflete em interpretações diferentes 
dos conceitos temporais. As definições completas dos conceitos aqui 
apresentados podem ser encontradas em [Jensen 94], num glossário 
consensual de termos relativos a Bancos de Dados Temporais elaborado 
pela comunidade desta área através de uma discussão realizada através de 
correio eletrônico. 
2.1 Dimensão Temporal 
Os modelos de dados tradicionais apresentam duas dimensões, 
representando (1) as instâncias dos dados (linhas de uma tabela), e (2) os 
atributos de cada instância (colunas desta tabela). Cada atributo de uma 
instância apresenta um só valor. Se for feita uma alteração deste valor, o 
anterior é perdido. Por exemplo, se o atributo representa o salário de um 
funcionário, o banco de dados somente armazena o último valor. 
Os modelos temporais acrescentam mais uma dimensão aos modelos 
tradicionais – a dimensão temporal. Esta dimensão associa alguma 
informação temporal a cada valor. Caso o valor de um atributo seja 
alterado, o valor anterior não é removido do banco de dados – o novo valor 
é acrescentado, associado a alguma informação que define, por exemplo, 
seu tempo inicial de validade. Todos os valores definidos ficam 
armazenados no banco de dados. No exemplo anterior, todos os valores do 
salário do funcionário ficam armazenados, cada um associado ao seu 
tempo de validade. Deste modo é possível acessar toda a história dos 
atributos, sendo possível analisar sua evolução temporal. 
2.2 Ordem no Tempo 
A dimensão temporal é composta por uma seqüência de pontos 
consecutivos no tempo, que recebe o nome de eixo temporal. A definição de 
uma ordem a ser seguida no tempo é fundamental quando utilizada 
alguma representação temporal. O mais comum é que se assuma que o 
tempo flui linearmente; isto implica em uma total ordenação entre 
quaisquer dois pontos no tempo. Em alguns casos pode ser considerado 
tempo ramificado ("branching time"). Para estes a restrição linear é 
abandonada permitindo a possibilidade de dois pontos diferentes serem 
sucessores (ramificação no futuro) ou antecessores (ramificação no 
passado) imediatos de um mesmo ponto. Uma ramificação no futuro 
implica que podem ser considerados múltiplos possíveis desenvolvimentos 
futuros do domínio (por ex., diferentes hipóteses da história futura), 
enquanto que uma ramificação no passado admite múltiplas histórias 
passadas do domínio em questão. A combinação "passado linear, futuro 
ramificado" trabalha com uma só história passada e admite múltiplas 
histórias futuras, representando desta maneira a realidade atual de uma 
forma bastante fiel. Uma última opção de ordenação temporal é considerar 
o tempo circular. Esta forma pode ser utilizada para modelar eventos e 
processos recorrentes. 
2.2.1 Tempo Totalmente Ordenado 
A maior parte dos modelos temporais se baseia no tempo linearmente 
ordenado. A ordenação total do tempo pode ser definida com mais precisão 
através da teoria dos conjuntos, conforme mostrado a seguir [Antunes 97]. 
Seja T o conjunto não vazio de todos os pontos do tempo. Por 
definição, T é um conjunto totalmente ordenado pela relação BEFORE 
(ANTES ), a qual satisfaz à seguinte condição: 
 " ta, tb : ta, tb Î T Ù ta ¹ tb ® (ta BEFORE tb Ú tb BEFORE ta) 
Para que a relação BEFORE seja uma relação de ordem estrita total é 
necessário que possua as seguintes propriedades: 
Irreflexibilidade:
" t : t Î T ® Ø(t BEFORE t) 
Transitividade: 
 " ta, tb, tc : ta, tb, tc Î T Ù ta BEFORE tb Ù tb BEFORE tc 
® ta BEFORE tc 
Assimetrias: 
 " ta, tb : ta, tb Î T Ù ta BEFORE tb ® Ø(tb BEFORE ta) 
A relação BEFORE é equivalente à relação “ < ” utilizada no âmbito dos 
números inteiros, sendo este operador muitas vezes utilizado para 
representar a ordem temporal. 
2.3 Tempo Absoluto e Tempo Relativo 
Outro conceito importante é o que diferencia tempo absoluto de relativo. 
Tempo absoluto consiste de uma informação temporal que define um 
tempo específico, definido com uma granularidade determinada, associado 
a um fato. Exemplo: Flávio nasceu no dia 30/08/73. 
Um tempo é relativo quando sua validade é relacionada à validade de 
outro fato, ou ao momento atual. Exemplo: o salário aumentou ontem; a 
loja abriu dois meses depois da abertura do Shopping. 
2.4 Variação Temporal 
Duas formas basicamente diferentes de variação temporal podem ser 
consideradas: tempo contínuo e tempo discreto. Supõe -se que o tempo é 
contínuo por natureza. Entretanto, sem grande perda de generalidade, o 
tempo pode ser considerado como discreto. Esta segunda forma de 
representação simplifica consideravelmente a implementação de modelos 
de dados. 
Modelos de dados que suportam uma noção discreta de variação 
temporal são baseados em uma linha de tempo composta de uma 
seqüência de intervalos temporais consecutivos, que não podem ser 
decompostos, de idêntica duração. Estes intervalos são denominados 
chronons. A duração particular de um chronon não é necessariamente 
fixada no modelo de dados, podendo ser definida em implementações 
particulares do modelo de dados. 
Considerando variação temporal discreta, a definição de informações 
ao longo do tempo, sob ponto de vista de sua validade, pode ser feita das 
seguintes formas (Figura 2.1): 
· variação ponto a ponto – o valor definido vale somente no ponto 
temporal onde foi definido. Não existe valor válido nos pontos para os 
quais não foram definidos valores; 
· variação por escada – o valor fica constante desde o ponto em que foi 
definido até o instante em que outro valor seja definido. Corresponde, 
geralmente, à definição de valores em conseqüência da ocorrência de 
eventos (variação por eventos); 
· variação temporal definida por uma função – existe uma função que 
define os valores e que permite a interpolação para obter os valores nos 
pontos não definidos. Esta função de interpolação pode ser definida 
pelo usuário ou incluída na modelagem conceitual. 
chronon
t
v
PONTO A PONTO
t
v
DEFINIDA POR UMA FUNÇÃO
t
v
EM ESCADA
 
Figura 2.1: Formas de variação temporal discreta 
2.5 Granularidade Temporal 
A granularidade temporal de um sistema consiste na duração de um 
chronon. Entretanto, dependendo da aplicação considerada, às vezes é 
necessário considerar simultaneamente diferentes granularidades 
(minutos, dias, anos) para permitir uma melhor representação da 
realidade. Por exemplo, em um determinado segmento modelado, a 
granularidade pode ser diária (o chronon equivale a um dia), enquanto que 
em outro segmento a granularidade pode ser mensal. Embora o chronon do 
sistema seja único, é possível manipular estas diferentes granularidades 
através de funções e operações disponíveis nos sistemas gerenciadores do 
banco de dados que implementam o mode lo. 
2.6 Elementos Primitivos de Representação Temporal 
2.6.1 Instante no Tempo 
O conceito de instante, representando um particular ponto no tempo, 
depende da forma de variação temporal considerada. Quando é 
considerado tempo contínuo, um instante é um ponto no tempo de 
duração infinitesimal. Neste caso os instantes são isomórficos com os 
números reais, o que significa que entre dois pontos do tempo sempre 
existe um outro ponto no tempo. 
Quando, no entanto, é considerada a variação temporal discreta, um 
instante é representado por um dos chronons da linha de tempo suportada 
pelo modelo. Na variação discreta, os instantes são isomórficos aos 
números inteiros ou a um subconjunto destes. Assim, entre dois pontos do 
tempo consecutivos não existe outro ponto do tempo. Diz-se que um 
evento ocorre no tempo t se ocorre em qualquer tempo durante o chronon 
representado por t. Um chronon, que é a menor duração de tempo 
suportada por um SGBD temporal, pertence à representação discreta de 
tempo. 
Considerando a ordem de variação temporal linear, temos a existência 
de um instante especial, correspondente ao instante atual (now), o qual 
se move constantemente ao longo do eixo do tempo. Este ponto define o 
que é considerado como passado (qualquer ponto anterior a este) e como 
futuro (qualquer ponto posterior a ele). 
2.6.2 Intervalo Temporal 
Um intervalo temporal é caracterizado pelo tempo decorrido entre dois 
instantes – um subconjunto de pontos do eixo temporal. Depende também 
da forma de representação temporal definida no modelo. Quando é 
considerado tempo contínuo, o intervalo consiste de infinitos instantes de 
tempo. Na variação discreta um intervalo é representado por um conjunto 
finito de chronons consecutivos. 
É representado pelos dois instantes que o delimitam. Dependendo da 
pertinência ou não dos instantes limites ao intervalo este pode ser aberto 
(os limites não pertencem ao intervalo), semiaberto (um dos limites 
pertence ao intervalo) ou fechado (ambos os limites pertencem ao 
intervalo). Quando um dos limites é representado pelo instante atual (now) 
temos a representação de um intervalo particular cujo tamanho varia com 
a passagem do tempo. 
Um intervalo temporal é representado por [t1, t2], onde t1 é o primeiro 
ponto do intervalo (limite inferior) e t2 é o último (limite inferior). O próprio 
eixo temporal T pode ser considerado um intervalo de tempo, 
identificado pela expressão [«, »], onde o símbolo « o instante temporal de 
início da contagem de tempo e o símbolo » representa o final. Para 
qualquer intervalo temporal, uma das duas fórmulas a seguir deve ser 
verdadeira: 
 t1 < t2 ou t1 = t2. 
A segunda representa um intervalo cuja duração é exatamente um 
chronon. 
Um intervalo temporal também é totalmente ordenado pela relação 
BEFORE, sendo possível, através dos operadores first e last [Clifford 88], 
extrair-lhe o primeiro e o último ponto de tempo. É o que se passa a 
demonstrar. 
Seja I, um intervalo de tempo e I Í T, então: 
first ( I ) é o elemento t Î I tal que, " t' Î I : t BEFORE t' Ú t = t' 
last ( I ) é o elemento t Î I tal que, " t' Î I : t' BEFORE t Ú t' = t 
Para que um conjunto de pontos do tempo seja realmente considerado 
um intervalo, é necessário que sejam consecutivos, isto é, não pode haver 
qualquer lacuna entre eles. Esta condição é formalmente representada 
pela expressão abaixo: 
Seja I Í T um intervalo, então 
 " ta Î I : ta ¹ last ( I ) ® $ tb Î I : ( ta BEFORE tb Ù 
Ø$ tc Î T : ta BEFORE tc Ù tc BEFORE tb ) 
2.6.3 Elemento Temporal 
Elemento temporal é uma união finita de intervalos de tempo. Estes 
intervalos podem ser disjuntos, o que realmente o diferencia dos demais e 
enriquece o seu poder de expressão – por exemplo, um possível elemento 
temporal seria a união dos intervalos [25, 40] e [51, 70]. O elemento 
temporal é fechado para as operações de união, interseção e complemento 
da teoria dos conjuntos, isto é, qualquer destas operações sobre um 
elemento temporal produz um novo elemento temporal. Como estas 
operações encontram contrapartida nos operadores booleanos or, and e 
not, isto produz uma substancial simplificação na habilidade do usuário de 
expressar consultas temporais. Tendo em vista que todos os intervalos 
temporais são subconjuntos do eixo temporal T, um elemento
temporal, 
sendo composto por diversos intervalos temporais, também o é. Tanto um 
intervalo temporal como um instante temporal ([t, t]) são elementos 
temporais. 
Em termos de modelagem, o elemento temporal se mostra superior ao 
uso da primitiva intervalo de tempo pois, quando os intervalos são usados 
como rótulos temporais, os objetos são fragmentados em várias tuplas, 
uma para cada intervalo. Outro aspecto importante desta primitiva 
temporal é que possibilita a representação da “reencarnação” de objetos 
com facilidade. Um exemplo da necessidade deste aspecto seria uma 
pessoa ser funcionário de uma empresa durante o intervalo [1992, 1995], 
tendo saído da empresa em 1995 e sendo readmitida dois anos depois 
(1997). A validade da existência desta pessoa na empresa seria a união dos 
intervalos [1992, 1995] U [1997, »]. 
2.6.4 Duração Temporal 
A representação de um duração temporal pode também ser considerada 
como primitiva. Durações temporais podem ser basicamente de dois tipos, 
dependendo do contexto em que são definidas: fixas e variáveis. Uma 
duração fixa independe do contexto de sua definição. Um exemplo típico de 
uma duração fixa é uma hora que tem sempre, independentemente do 
contexto de sua utilização, a duração de 60 minutos. Já a duração variável 
depende do contexto, sendo um exemplo típico a duração de um mês, que 
pode ser de 28, 29, 30 ou 31 dias. 
2.7 Limites do Tempo 
O conceito de limites no tempo pode variar dependendo da representação 
temporal utilizada. Quando considerados somente pontos no tempo, os 
limites do tempo se referem a considerar ou não o tempo como infinito. O 
conceito de tempo infinito consiste em considerar que todo ponto no tempo 
apresente sempre um sucessor e um antecessor. Em modelos orientados a 
objetos este conceito fica limitado, por exemplo, ao tempo de vida de um 
objeto. No caso das teorias baseadas em intervalos, os limites do tempo se 
referem geralmente à pertinência ou não dos pontos limites ao intervalo, 
definindo se os intervalos são abertos ou fechados em um ou em ambas as 
extremidades. 
2.8 Representação Temporal Expl ícita e Implícita 
A definição de tempo pode ser feita de forma explícita, através por exemplo 
da associação de um valor temporal a uma informação na forma de um 
rótulo temporal (timestamping), ou de forma implícita através da utilização 
de uma linguagem de lógica temporal. 
A associação explícita de tempo às informações consiste em associar a 
cada valor atribuído a um atributo, o valor que corresponde à sua 
primitiva temporal. A representação temporal implícita é feita através da 
manipulação de conhecimentos sobre a ocorrência de eventos ou do 
relacionamento de intervalos de tempo como, por exemplo: a aula de lógica 
temporal ocorreu ontem. 
2.9 Tempo de Transação e Tempo Válido 
Três diferentes conceitos temporais podem ser identificados em aplicações 
de bancos de dados [Snodgrass 85]: (i) tempo de transação, tempo no 
qual o fato é registrado no banco de dados; (ii) tempo de validade, tempo 
em que o valor é válido na realidade modelada; e (iii) tempo definido pelo 
usuário, consistindo de propriedades temporais definidas explicitamente 
pelos usuários em um domínio temporal e manipuladas pelos programas 
de aplicação. Estes tempos são ortogonais, podendo ser tratados 
separadamente ou em conjunto. O tempo de transação é suprido 
automaticamente pelo sistema gerenciador de banco de dados, enquanto 
que o tempo de validade é fornecido pelo usuário. 
O tempo de validade pode ser representado de formas distintas, 
dependendo do elemento temporal básico utilizado no modelo. Quando for 
utilizado o elemento temporal ponto no tempo, o tempo de validade pode 
ser representado: (i) através de um ponto no tempo indicando o início da 
validade, permanecendo o valor válido até que inicie o tempo de validade 
de outro valor; ou (ii) através de dois pontos no tempo, o primeiro 
indicando o início da validade e segundo, o final da validade. Nos modelos 
que utilizam o intervalo temporal como elemento temporal básico, o tempo 
de validade é definido através do intervalo de validade do valor. 
3 Bancos de Dados Temporais 
Um banco de dados temporal é aquele que apresenta alguma forma 
implícita de representação de informações temporais. Podem ser utilizados 
o tempo de transação e/ou o de validade para representar esta informação 
temporal. Conforme a forma utilizada, os bancos de dados podem ser 
classificados em quatro tipos diferentes: bancos de dados instantâneos, de 
tempo de transação, de tempo de validade e bitemporais. 
3.1 Bancos de Dados Instantâneos 
Corresponde aos bancos de dados convencionais, onde são armazenados 
somente os valores presentes. A cada modificação no valor de uma 
propriedade, o valor anteriormente armazenado é destruído e somente o 
último valor está disponível. A figura 3.1 apresenta algumas atualizações 
feitas em momentos diferentes em um banco de dados instantâneo. Cada 
estado do banco de dados corresponde a um instantâneo (snapshot). A 
manutenção de informações temporais neste tipo de banco de dados 
somente pode ser realizada explicitamente, pela inclusão de atributos 
definidos sobre o domínio tempo, e pela sua manipulação através dos 
programas de aplicação. 
Estados Passados
Estado Atual 
João Silva, 01/jan/92, 800,00
 Mara Dias, 01/mar/91, 1.200,00
 
Figura 3.1: Banco de Dados Instantâneo 
3.2 Bancos de Dados de Tempo de Transação 
Uma alternativa para armazenamento de informações temporais é associar 
a cada valor definido o tempo de transação, sob forma de um rótulo 
temporal (timestamp). Este tempo é fornecido automaticamente pelo 
SGBD, sendo esta operação transparente ao usuário. A alteração do valor 
de uma propriedade não destrói o valor anteriormente definido, ficando 
todos os valores armazenados no banco de dados. O estado atual do BD é 
composto pelos últimos valores definidos para cada uma das propriedades. 
Bancos de dados deste tipo são denominados de bancos de dados de 
tempo de transação. Na figura 3.2 estão representadas atualizações do 
salário de um funcionário. 
t1
t2
t3
tpresente
01/jan/92
01/jun/92
01/jan/93
Momento Atual
900
1000
800
História do salário de João
Tempo
 
Figura 3.2: Banco de Dados de Tempo de Transação 
Caso o dia em que é procedida a atualização do salário não coincida com o 
dia em que começa a sua validade, a data de início de validade pode ser 
armazenada como um atributo explícito, como mostrado na figura 3.3. 
t1
t2
t3
tpresente
03/jan/92
25/mai/92
10/jan/93
Momento Atual
(900, 01/jun/92)
(1000, 01/jan/93)
(800, 01/jan/92)
História do salário de João
Tempo
 
Figura 3.3: Banco de Dados de Tempo de Transação 
3.3 Bancos de Dados de Tempo de Validade 
Um terceiro tipo de banco de dados, denominado banco de dados de 
tempo de validade, associa a cada informação somente o tempo de sua 
validade no mundo real. Este pode representar o início de sua validade 
(ponto no tempo, variação por degraus), a validade somente naquele ponto 
no tempo (variação discreta), ou seu intervalo de validade. O tempo de 
validade deve sempre ser fornecido pelo usuário. Em bancos de dados de 
tempo de validade não se tem acesso ao tempo em que a informação foi 
definida, sendo armazenado somente o tempo em que a mesma é válida. A 
figura 3.4 apresenta um exemplo deste tipo de banco de dados, também 
atualizando o salário de um funcionário. 
t1
t2
t3
tpresente
800
900
1000
01/jun/92
01/jan/92
01/jan/93
Tempo
História do salário de João
Momento Atual
 
Figura 3.4: Banco de Dados de Tempo de Validade 
Este tipo de banco de dados permite se sejam corrigidas informações 
do passado - se alguma das informações tiver sido registrada 
incorretamente, é feita uma nova
definição com a data de validade 
correspondente, sendo que somente a versão atual dos dados é a 
disponível. 
3.4 Bancos de Dados Bitemporais 
A forma mais completa de armazenar informações temporais são os 
bancos de dados bitemporais, nos quais os tempos de transação e de 
validade são associados a cada informação. Toda a história do banco de 
dados fica armazenada. É possível ter acesso a todos os estados passados 
do banco de dados - tanto a história das transações realizadas, como a 
história da validade dos dados. O estado atual do banco de dados é 
constituído pelos valores atualmente válidos. Valores futuros podem ser 
definidos através do tempo de validade, sendo possível recuperar o 
momento em que estes valores foram definidos para eventuais alterações. 
Como exemplo deste tipo de banco de dados apresentamos, na figura 3.5, 
toda a história da atualização do salário do funcionário João. Pode -se 
saber não somente o valor atual do salário, como o valor que era válido em 
qualquer data passada e ainda aqueles valores que se acreditava como 
válidos mas que em datas posteriores foram modificados. 
História das transações
do salário de João
História da validade
do salário de João
01/jan/92
800
800
900
900
1000
1000
03/jan/92
25/mai/92
10/jan/93
01/jun/92
01/jan/93
Tempo de Transação
Momento
Atual
Tempo de Validade
 
Figura 3.5: Banco de Dados Bitemporal 
4 Consultas a Bancos de Dados Temporais 
Quando é utilizado um banco de dados temporal, é importante que 
também esteja disponível uma linguagem de consulta temporal. Esta 
linguagem deve possibilitar a recuperação de todas as informações 
armazenadas no banco de dados (temporais ou não), de modo a que seja 
tirado real proveito do acréscimo da dimensão temporal. Consulta 
temporais permitem: 
· fornecer valores de propriedade s cujo domínio é temporal. Exemplo: 
fornecer o valor da propriedade que armazena a data de nascimento de 
uma pessoa; 
· se referir a um determinado instante ou intervalo temporal. Exemplo: 
qual o valor do salário no dia 01/01/94; 
· recuperar valores com base em restrições temporais. Exemplo: 
recuperar todos os valores do salário antes do dia 01/01/94; 
· fornecer informações temporais (datas, intervalos). Exemplo: qual a 
data em que foi alterado o salário de um funcionário. 
Para que isto seja possível, as linguage ns de consultas temporais 
devem ser enriquecidas para manipular a dimensão temporal, e ter 
capacidade de dedução sobre tempo com base nas informações temporais 
armazenadas. Isto é possibilitado através da utilização de lógica temporal, 
a qual permite inferências de valores não explicitamente armazenados. 
4.1 Problemas no Processamento de Consultas Temporais 
O processamento de consultas temporais apresenta diversos problemas 
além daqueles usualmente enfrentados. Entre eles podemos citar: 
· o grande volume de dados armazenado em um banco de dados 
temporal implica na necessidade de novos métodos de indexação 
(estruturas e algoritmos de busca); 
· métodos tradicionais de indexação só podem ser utilizados para valores 
com algum tipo de ordenação completa, com estruturas de acesso para 
intervalos; 
· manipulação de informações incompletas, devido a valores incompletos 
ou inexistentes, a partir dos quais devem ser inferidas informações. 
Podem ser devido (i) à incerteza quanto à existência do objeto em certos 
pontos no tempo, ou (ii) à indeterminação temporal, causada por 
eventos cujo tempo de ocorrência não é conhecido 
4.2 Tipos de Bancos de Dados e Diferentes Histórias 
As consultas temporais que podem ser formuladas a um banco de dados 
temporal dependem do tipo de banco de dados e da história considerada. 
Os bancos de dados instantâneos não apresentam suporte para 
informações temporais, não permitindo portanto consultas temporais. 
Nos bancos de dados de tempo de transação podem ser feitas consultas 
a (i) valores atuais das informações armazenadas, (ii) valores definidos em 
tempos passados. O tempo de transação associado implicitamente à 
informação identifica o instante para o qual se quer a informação. A 
validade das informações somente pode ser armazenada através de 
atributos explícitos, e sua recuperação seria através destes atributos. 
Exemplo: recuperar o salário de um funcionário no dia (tempo de 
transação) 01/01/97. 
Nos bancos de dados de tempo de validade podem ser recuperadas 
informações válidas em momentos presentes e passado s, além de valores 
armazenados sob forma de previsão para o futuro, de acordo com a atual 
percepção da história dos dados. Exemplo: recuperar o salário válido de 
um funcionário no dia 01/01/98. 
Os bancos de dados bitemporais permitem que sejam feitas consultas a 
respeito de valores atuais, passados e futuros, considerando o tempo de 
transação e o de validade. Qualquer estado do banco de dados pode ser 
consultado (atual, passado, ou previsto para o futuro). Quando 
considerado o estado atual do banco de dados, a recuperação é sobre a 
atual percepção dos dados. Os estados passados representam valores que 
se acreditava válidos em datas passadas e que, posteriormente, foram 
redefinidos. O conjunto de todos estes estados (passados, atual e futuros) 
de um banco de dados caracteriza a sua história. Um banco de dados 
bitemporal permite que se tenha registro de todas as histórias passadas. A 
história presente corresponde ao conhecimento presente a respeito do 
presente, a respeito do passado e a respeito do futuro. Uma história 
passada corresponde ao conhecimento que existia naquele momento a 
respeito do presente, do passado e do futuro, sendo definida por um tempo 
de transação – informações definidas após este tempo não devem ser 
consideradas, uma vez que não eram conhecidas. A consulta deve definir, 
através de alguma cláusula que define o tempo de transação que deve ser 
considerado como limite, o instante correspondente à história considerada. 
4.3 Consultas Temporais 
Vamos analisar, a seguir, as diferentes formas que podem apresentar as 
consultas quando utilizados bancos de dados temporais. Para maior 
generalidade serão considerados somente bancos de dados bitemporais, os 
quais englobam os outros tipos de bancos de dados. Uma consulta 
apresenta dois componentes ortogonais: um componente de seleção e um 
de saída (projeção). 
O componente de seleção geralmente é representado através de uma 
condição lógica. Quando a condição envolve valores temporais é utilizada 
lógica temporal. Diversos operadores para tratar valores temporais são 
necessários, tais como operadores booleanos (antes, depois, durante) e 
operadores que retornam valores temporais (depois, agora, 
início_de_intervalo, distância_temporal). As condições podem envolver 
valores de dados e valores temporais associados aos dados (tempo de 
transação e/ou de validade). 
Conforme o componente de seleção, as consultas ser classificadas em: 
(1) consultas de seleção sobre dados - quando as condições são 
estabelecidas somente sobre valores de dados. Exemplo: selecionar o 
salário do funcionário de nome Carlos. É importante ressaltar que 
quando forem utilizados tipos de dados temporais, tais como datas e 
horas, a utilização destes na condição de seleção representa uma 
seleção sobre dados e não uma seleção temporal. Exemplo deste último 
caso: selecionar o nome dos empregados que apresentam data de 
nascimento posterior a 01/01/1980; 
(2) consultas de seleção temporal - são as consultas nas quais somente 
informações temporais associadas aos dados (tempo de transação e/ou 
tempo de validade) são analisadas pela condição de seleção. Exemplo: 
selecionar todos os empregados da empresa durante o período de 
01/01/96 a 01/01/97. 
(3) consultas de seleção mista - a condição de seleção atua não somente 
nos dados mas também nas informações
temporais associadas a eles. 
Exemplo: selecionar todos os empregados do departamento 
denominado entregas que estavam habilitados para dirigir automóveis 
durante o período de 01/01/95 a 01/07/95. 
Analisando agora o componente de saída, na consulta podem ser 
solicitados valores de dados e/ou valores relativos às informações 
temporais associadas aos dados. Podemos ter, portanto: 
(1) consultas de saídas de dados - nas quais as informações selecionadas 
correspondem exclusivamente a valores de dados. Exemplo: selecionar 
o nome dos funcionários do departamento entregas”; 
(2) consultas de saídas temporal - recuperam informações abstraídas das 
informações temporais associadas aos dados. Deste modo podem ser 
recuperados pontos no tempo, intervalos temporais e durações 
temporais. Exemplo: selecionar todos os períodos nos quais qualquer 
empregado do departamento de entregas estava habilitado a dirigir 
automóveis; 
(3) consultas de saída mista - recuperam simultaneamente valores de 
dados e valores temporais associados a estes dados. Exemplo: 
selecionar os valores de salário com os respectivos tempos de validade 
para o empregado chamado João entre 01/01/95 e 01/01/96”. 
Analisando as possíveis combinações entre os componentes de seleção 
e de saída de uma consulta observamos que a única combinação que não 
pode ser utilizada é a de seleção temporal com saída temporal - devemos 
ter algum dado envolvido em pelo menos um dos componentes. 
A recuperação de valores de uma determinada história do banco de 
dados depende da condição estabelecida no componente de seleção. Por 
exemplo, para recuperar informações relativas a dados de um determinado 
dia do passado é necessário que o componente de seleção apresente 
alguma seleção temporal - a seleção do instante passado considerado. Para 
recuperar dados referentes a uma história passada o componente de 
seleção deve definir a data-base desta história (algo como conforme se 
acreditava em 01/01/60). 
Na recuperação de dados históricos podem ser considerados valores 
válidos (considerando o tempo de validade associado ao valor) ou instantes 
em que os valores foram definidos (ao considerar o tempo de transação. 
Pode-se, por exemplo, consultar o valor válido para o salário de um 
funcionário em um determinado dia, e a data em que este valor foi 
definido. 
4.4 Consultas e o Paradigma de Orientação a Objetos 
Modelos de dados orientados a objetos requerem propriedades especiais 
para a recuperação de informações. Os objetos apresentam atributos 
(propriedades) cujos valores são definidos em domínios específicos. Os 
domínios podem ser simples (como, por exemplo, inteiros e reais) ou 
complexos, representados por nomes de classes, listas e conjuntos. Os 
valores assumidos por estas propriedades são instâncias das classes 
especificadas como domínios. Assim, o valor de uma propriedade cujo 
domínio é uma classe será uma instância desta classe – um objeto. 
Várias soluções podem ser adotadas para a recuperação de valores de 
propriedades cujos domínios são classes, como por exemplo: (i) devolver o 
identificador do objeto recuperado, embora este identificador seja 
usualmente interno ao sistema e, portanto, não acessível ao usuário; (ii) 
listar os valores de todas as propriedades do objeto, identificando os 
objetos referentes às propriedades recursivamente até que todas as 
propriedades sejam definidas em domíni os simples; (iii) listar somente os 
valores referentes a propriedades simples do objeto identificado; ou (iv) 
fornecer o(s) valor(es) de alguma(s) propriedade(s) identificada(s) pelo 
modelo como especial para esta finalidade. 
As propriedades cujo domínio são listas ou conjuntos também podem 
apresentar objetos (instâncias de classes). A recuperação de informações 
para estes casos requer que todos os objetos sejam devolvidos pela 
linguagem de consulta. 
Outro problema envolvido na recuperação de informações em um 
modelo de dados orientado a objetos consiste na possível hierarquia de 
classes existente. Uma classe pode apresentar um conjunto de subclasses 
e um conjunto de superclasses. Quando o domínio de uma propriedade for 
uma classe, todas as subclasses desta (diretas ou indiretas) são também 
possíveis domínios desta propriedade. A recuperação de informações deve 
navegar através de toda a hierarquia para fornecer todos os valores 
definidos. 
Informações temporais são geralmente associadas aos objetos 
(representando a vida do objeto – tempo de criação, eventuais intervalos de 
suspensão e tempo em que sua existência terminou) e aos atributos 
(representando os tempos de definição de seus valores). Nos dois casos 
podem ser utilizados tempos de transação e/ou de validade. A linguagem 
de consulta deve permitir a recuperação de valores temporais de objetos e 
de seus atributos, os quais devem ser analisados em conjunto com a 
solução adotada para a recuperação de informações de domínios 
complexos. 
4.5 Linguagens de Consulta Textuais e Visuais 
A maioria dos modelos de dados temporais apresentam linguagens de 
consulta textuais, geralmente derivadas do SQL. Dentre estas, a mais 
conhecida é TSQL2, a ser apresentada na seção 5.1.2 deste texto. A 
linguagem textual de consulta exige que o usuário conheça sua sintaxe, 
esteja bastante familiarizado com o esquema do banco de dados e saiba 
quais os objetos que podem mudar de valor ao longo do tempo. Uma 
linguagem visual de consulta permite a recuperação de informações sem 
que o usuário conheça a sintaxe da linguagem de consulta. A consulta 
pode ser realizada de uma forma amigável, através da utilização de 
símbolos visuais (ícones, diagramas, sinais) e um conjunto de regras para 
utilização dos mesmos na recuperação de informações. A representação 
visual dos objetos do banco de dados e de seus relacionamentos, 
possibilita ao usuário uma melhor percepção da realidade, o que não 
acontece com o uso de linguagens de consulta textual, como SQL. 
Algumas propostas de linguagens visuais de consulta pa ra bancos de 
dados temporais têm sido publicadas recentemente [Carvalho 97, 
Kouramajian 95, Oberweis 94]. No Visual Query System TF-ORM [Carvalho 
97] a consulta é realizada através de um interface gráfico, formado por 
diversas janelas. Uma destas apresenta uma representação gráfica do 
esquema conceitual (Figura 4.1) no modelo TF-ORM [Edelweiss 93]. O 
usuário realiza a consulta navegando sobre este esquema gráfico e 
selecionando os elementos de interesse para elaboração da consulta. Os 
elementos selecionados vão sendo apresentados em outra janela, onde 
aparece somente a parte do esquema conceitual envolvida na consulta, e 
sobre a qual se definem as condições impostas à consulta. 
 
 
Figura 4.1: Esquema conceitual TF-ORM gráfico 
 
Além destas duas janelas, o sistema possui um conjunto de janelas 
para serem utilizados no complemento da consulta - definição de 
restrições, temporais ou não, sobre os elementos selecionados no esquema 
conceitual gráfico ou sobre a consulta como um todo (Figuras 4.2). 
 
 
Figura 4.2: Janela onde é definido o tempo de consulta 
5 Modelos de Dados Temporais 
A representação dos aspectos temporais na especificação de um sistema de 
informação é importante por mais de um motivo: (i) o sistema pode 
apresentar informações temporais a serem introduzidas no banco de dados 
que o representa, sob forma de informação propriamente dita; (ii) 
processos a serem executados podem apresentar interações temporais, 
interações estas que devem também ser representadas; (iii) determinadas 
tarefas podem apresentar pré-condições à sua execução, as quais podem 
ser representadas através de restrições temporais; e (iv) condições de 
integridade temporal do banco de dados podem ser necessárias. Para que 
isto tudo seja possível, é necessário que seja utilizado um modelo de dados 
temporal
adequado. 
Um modelo de dados deve apresentar uma estrutura de objetos que 
podem ser manipulados por esta linguagem, uma linguagem para atualizar 
estes objetos (update), uma linguagem de consulta, e algum mecanismo 
para expressar restrições de integridade. 
Os modelos de dados temporais também devem apresentar estas 
características, acrescentando a possibilidade de representar informações 
temporais, efetuar consultas temporais, e permitir a definição de restrições 
de integridade temporal. Para este último aspecto geralmente é utilizada 
lógica temporal de primeira ordem. 
Os seguintes aspectos devem ser considerados ao ser analisado um 
modelo de dados temporal: 
· identificar o tipo de rótulo temporal utilizado pelo modelo (ponto no 
tempo, intervalo temporal, elemento temporal, duração); 
· analisar a forma de variação temporal dos atributos (podem ou não 
variar com o tempo, todos ou alguns); 
· verificar se os rótulos temporais são explícitos ou implícitos; 
· homogeneidade temporal; 
· apresentação e funcionalidades da linguagem de consulta. 
Em lugar de definir novos modelos para tratar dos aspectos temporais, 
diversos modelos de dados tradicionais foram estendidos para possibilitar 
a representação de aspectos temporais. 
5.1 Extensões do Modelo Relacional 
Os modelos relacionais se baseiam na representação de relacionamentos 
entre elementos. Ao ser utilizado um modelo temporal, estes 
relacionamentos devem ser representados ao longo do tempo. Informações 
adicionais a serem acrescentadas: 
· tempo de início do relacionamento; 
· variação do relacionamento com o tempo; 
· término do relacionamento; 
· reincarnação de relacionamentos; 
· restrições de integridade referencial com respeito à dimensão temporal. 
Um banco de dados relacional apresenta um conjunto de relações, 
sendo que cada relação é composta por um conjunto de tuplas. Uma 
instância deste banco de dados é definida pelo conjunto de relações e de 
todas suas tuplas. 
Ao ser feita a extensão temporal para um banco de dados relacional, 
três formas podem ser utilizadas para representar a temporização, 
dependendo do nível ao qual o tempo é associado: 
(1) ao banco de dados como um todo – neste caso, cada estado do banco 
de dados é armazenado completo, com o rótulo temporal. Alterações 
elementares do BD criam um novo estado; 
(2) às relações – cada relação é temporizada. Para cada estado, todas as 
tuplas desta relação devem ser armazenadas, com o rótulo temporal 
correspondente. Informações globais sobre existência da relação podem 
ser armazenadas desta maneira; 
(3) às tuplas – cada tupla é temporizada. Uma alteração elementar de 
valores de uma relação definem uma nova tupla, e somente esta 
precisa ser armazenada. 
Como importantes extensões do modelo relacional podem ser citados 
os modelos HRDM (Historical Relational Data Model) [Clifford 87, 93], IXRM 
(Interval-extended Relational Model) [Lorentzos 93] e TRM (Temporal 
Relational Model) [Navathe 88, 93]. 
5.1.1 TSQL2 – Temporal Structured Query Language 
As pesquisas em bancos de dados temporais vêm sendo desenvolvidas já 
há 15 anos, resultando na proposta de diversos modelos e linguagens de 
consulta temporais. A consolidação destas propostas está sendo buscada 
pela comunidade que pesquisa a área, através da definição de uma 
linguagem de consulta temporal de consenso. A construção desta 
linguagem foi feita através de uma discussão via correio eletrônico, que 
teve início em 1993. Foram envolvidos na discussão pesquisadores de 8 
países, abrangendo 4 continentes. A linguagem resultante foi denominada 
TSQL2 [Snodgrass 95]. 
A linguagem se baseia em SQL por ser esta a linguagem de consulta 
mais utilizada atualmente. As seguintes característica foram buscadas na 
definição do TSQL2: 
· suporte a períodos de tempo. Em SQL somente date, time, timestamp, 
interval; 
· suporte a múltiplas granularidades. Em SQL somente year, month, 
day, hour, minute, second. Incluir: semestre - semana - estações do 
ano - ...; 
· suporte a múltiplas representações. Exemplo: terceira semana de 
1999. Em SQL: dia/mes/ano; 
· suporte a múltiplas linguagens. Exemplo: 29 de setembro de 1997; 
· suporte a múltiplos calendários (lunar – acadêmico – fiscal - eras 
geográficas); 
· suporte a tempo indeterminado. Exemplo: entre 1 e 15 de julho; 
· suporte a tempo histórico. 
A linguagem TSQL2 [Snodgrass 95] foi definida para o modelo temporal 
relacional BCDM – Bitemporal Conceptual Data Model. 
O Modelo BCDM 
Trata-se de um modelo conceitual muito simples, que captura a semântica 
essencial das variações temporais das relações. O modelo foi definido sem 
levar em consideração problemas de capacidade de armazenamento, que 
sem dúvida, estão presentes em implementações de bancos de dados 
temporais. 
No modelo BCDM o tempo é considerado linear e discreto. É feito 
suporte a ambos os tempos – de transação e de validade, implementando, 
portanto, um BD bitemporal. São utilizados rótulos que representam 
elementos bitemporais. A associação temporal é implícita, sendo o rótulo 
temporal associado às tuplas, na forma abaixo: 
 X = ( a1, a2, … , an / t ) 
onde ai são os valores dos atributos da tupla, e t representa o rótulo 
bitemporal. 
A cada tupla é associado um subconjunto arbitrário do domínio dos 
tempos válidos – um fato é válido na realidade modelada durante cada um 
dos chronons deste subconjunto. Por sua vez, a cada chronon de tempo de 
validade é associado um subconjunto dos tempos de transação – o fato é 
válido durante este particular chronon, ou seja, está presente na relação 
durante cada um dos chronons de tempo de transação do subconjunto. 
Este o conceito de elemento bitemporal. 
O exemplo a seguir mostra este tipo de rótulo temporal. Considere a 
seguinte relação com tuplas definidas (UC: until changed): 
Empregado Depto T 
João compras { (5,10),…, (5,15),…, (9,10),…, (9,15), 
(10,5),…, (10,20),…, (14,5),…, (14,20), 
(15,10),…,(15,15),…,(19,10),…,(19,15) } 
João vendas { (UC,10),…,(UC,15) } 
A primeira tupla associa João ao departamento de compras, durante 
diversos intervalos temporais. A segunda associa este mesmo funcionário 
ao departamento de vendas. A interpretação dos rótulos temporais está 
apresentada nas figuras 5.2 e 5.3. 
 
0 5 10 15 20 25 30
0
5
10
15
TT
TV
0 5 10 15 20 25 30
0
5
10
15
TT
TV
0 5 10 15 20 25 30
0
5
10
15
TT
TV
0 5 10 15 20 25 30
0
5
10
15
TT
TV
(João, compras) (João, compras)
(João, compras)
(João, vendas)
(João, compras)
 
Figura 5.1: Interpretação do elemento bitemporal 
0 5 10 15 20 25 TT
0
5
10
15
20
TV
Emp Dept Ts Te Vs Ve
João compras 5 9 10 15
João compras 10 14 5 20
João compras 15 19 10 15
João vendas 20 UC 10 15
elemento bitemporal particionado pelo tempo de transação
 
Figura 5.2 – Interpretação do elemento bitemporal – tempo de transação 
 
A Linguagem de consulta TSQL2 
Na linguagem TSQL2 a seleção e a projeção são feitas sobre o rótulo 
temporal, envolvendo, portanto, tempo de transação e de validade. Foram 
definidos diversos operadores de seleção: 
· extratores – que têm por objetivo extrair alguma informação temporal 
do rótulo. Por exemplo, o operador BEGIN extrai o início de validade de 
uma atributo; 
· construtores – constróem elementos temporais a partir de elementos 
temporais. Por exemplo, INTERSECT retorna o conjunto de intervalos 
temporais resultante da interseção de dois intervalos considerados; 
· de comparação – operadores lógicos que comparam intervalos 
temporais. Por exemplo, OVERLAPS verifica
se dois intervalos têm 
intervalos temporais em comum. 
Exemplos de consultas em TSQL2 
“Listar o nome dos funcionários que estiveram empregados em janeiro de 
1992” 
SELECT Name 
FROM Employee 
WHERE VALID (Employee) OVERLAPS PERIOD ‘[01/01/1992, 
01/31/1992]’ 
“Listar o nome dos funcionários que foram registrados como empregados 
em janeiro de 1992” 
SELECT Name 
FROM Employee 
WHERE TRANSACTION(Employee) OVERLAPS PERIOD ‘[01.01.92, 
31.01.92]’ 
“Listar o nome de todos os empregados que trabalharam na empresa ao 
mesmo tempo em que João esteve no departamento de brinquedos” 
SELECT E1.Name 
FROM Employee E1, Employee E2 
WHERE E2.Name = João AND E2.Dept = “Brinquedos” 
AND VALID(E1) OVERLAPS VALID(E2) 
Suporte à indeterminação temporal no TSQL2 
Na linguagem de consulta TSQL2 foi providenciado suporte à 
indeterminação temporal, pois esta está presente na maioria das 
aplicações. A linguagem permite consultas tais como: 
· recuperar valores válidos durante um determinado dia; 
· um fato registrado para ocorrer daqui a 6 meses; 
· um fato que ocorreu a mais de 5 anos. 
Para que isto possa ser possível, os atributos sobre os quais se pode 
fazer consultas incompletas devem ser identificados como tal durante a 
definição do esquema. Por exemplo: 
CREATE TABLE Employee (Birthdate INDETERMINATE DATE) 
Pode, também, ser definida a faixa de credibilidade que se quer na 
resposta solicitada, como no exemplo abaixo: 
SELECT Warehouse, Lot#, Part# 
VALID R 
FROM Receive AS R, InProduction AS IP WITH CREDIBILITY 0 
WHERE MODEL = ‘ABC’ AND R OVERLAPS IP WITH PLAUSIBILITY 65 
5.2 Extensões do Modelo E-R 
Os seguinte requisitos foram identificados como necessários a um modelo 
ER temporal [Antunes 97]: 
· a dimensão temporal deve estar “embutida” no modelo. Desta forma, 
enquanto que no modelo ER convencional os conjuntos de entidades 
apresentam apenas duas dimensões, a das tuplas e a dos atributos, no 
modelo ER temporal passam a apresentar três: a das tuplas, a dos 
atributos e a do tempo; 
· deve oferecer uma notação especial para diferenciar entidades 
temporizadas (que estão associadas ao tempo) de entidades não 
temporizados (que não estão associadas com o tempo); 
· deve permitir que uma entidade temporizada se associe com uma 
entidade não temporizada; 
· deve permitir que um relacionamento entre entidades possa ser 
definido como temporizado ou como não temporizado, não importando 
qual seja a classificação temporal destas entidades; 
· deve permitir que em uma mesma entidade possam conviver atributos 
temporizados e atributos não temporizados; 
· a restrição de cardinalidade que define o grau de participação de uma 
entidade em um conjunto de relacionamentos temporizados deve 
considerar os pontos do tempo. Por outro lado, em se tratando de 
conjunto de relacionamentos não temporizados, a cardinalidade não 
deve levar em conta os pontos do tempo, mantendo a mesma 
semântica do modelo ER convencional. 
Várias extensões à abordagem entidade -relacionamento original têm 
sido propostas com o objetivo de incorporar a possibilidade de modelar 
propriedades temporais, entre as quais se destacam: a abordagem ERT 
(Entity Relationship Time Model) [Loucopoulos 91], a abordagem TER 
(Temporal Entity-Relationship Model) [Tauzovich 91], a abordagem TEER 
(Temporal Enhanced Entity-Relationship Model) [Elmasri 93] e a abordagem 
TempER [Antunes 97]. 
5.2.1 O Modelo TempER 
Este modelo foi desenvolvido com o objetivo de atender a todos os 
requisitos colocados no início da seção 5.2. O modelo foi concebido com 
base, principalmente, no modelo ERT. As principais diferenças entre as 
abordagens situam-se na simbologia e na primitiva temporal adotada - o 
elemento temporal em lugar do intervalo de tempo. Em uma visão geral, as 
principais características do modelo de dados TempER são as seguintes: 
· oferece uma simbologia que diferencia elementos temporizados de 
elementos não temporizados, semelhante à do modelo ERT; 
· permite que se associe em um mesmo diagrama entidades 
temporalizadas com não temporalizadas. As entidades não 
temporalizadas passam a ser denominadas de “perenes”, sendo 
assumido que estas também apresentam uma dimensão temporal 
implícita, igual a todo o conjunto de pontos do eixo temporal. As 
entidades temporalizadas passam a ser denominadas de “transitórias”; 
· qualquer que seja a classificação das entidades em relação ao tempo, 
sejam elas perenes ou transitórias, ortogonalmente sempre apresentam 
duas perspectivas: uma não temporal e uma temporal. Quando se 
focaliza os conjuntos de entidades pela perspectiva não temporal 
estes apresentam apenas duas dimensões (tuplas x atributos não 
temporais). Por outro lado, quando se focaliza estes mesmos conjuntos 
pela perspectiva temporal, eles apresentam três dimensões (tupla x 
atributos temporais x eixo temporal); 
· no tocante aos relacionamentos, ou as entidades se associam entre si 
na perspectiva temporal (relacionamentos temporais) ou na perspectiva 
não temporal (relacionamentos não temporais); 
· possibilita que as restrições de cardinalidade levem em consideração os 
momentos do tempo de validade de um relacionamento temporal; 
· faz uso de um dicionário de dados para descrever os atributos, 
evitando que estes sejam explicitados graficamente. Isto contribui para 
tornar os diagramas mais administráveis visualmente. 
As figuras 5.3 e 5.4 apresentam, respectivamente, um esquema 
TempER e seu correspondente ER convencional, e um exemplo de 
povoamento de entidades e de relacionamentos para este esquema. 
 
Modelo ER convencional 
entidade EMPREGADO 
 atributos: 
 ( cod: NATURAL ;
 nome: STRING ;
 sal: REALP;
 datAdmissão: DATE ;
 datDemissão: DATE )
 identificador: (cod )
entidade DEPTO
 atributos:
 ( sigdep: STRING ;
 nomdep: STRING ;
 datCriação: DATE ;
 datFecham: DATE )
 identificador: (sigdep)
relacionamento
LOTAÇÃO
 atributos:
 ( datinicLot: DATE ;
 datfimLot: DATE )
Modelo ER temporal - TempER 
Empregado Lotação Depto( 1, 1 ) ( 0, N )
Tr T
entidade EMPREGADO 
 atributos: 
 ( cod: NATURAL, Intemporal;
 nome: STRING, Intemporal;
 at-sal: REALP, Temporal )
 identificador: (cod )
relacionamento
LOTAÇÃO
 atributos: ( - ) 
entidade DEPTO
 atributos:
 ( sigdep: STRING, Intemporal;
 nomdep: STRING, Intemporal ) 
 identificador: (sigdep)
Empregado Lotação Depto( 1, N ) ( 0, N )
Tr
 
Figura 5.3 – Exemplo de esquema TempER e o correspondente ER 
5.3 Extensões de Modelos Orientados a Objetos 
O tratamento de tempo em modelos de dados orientados a objetos está 
presente em diversos modelos recentemente apresentados [Cheng 93, Su 
91, Wuda 92, Wuu 93]. Entretanto, a representação de aspectos temporais 
em bancos de dados orientados a objetos tem sido feita nestes modelos de 
uma forma bastante limitada. Em sua grande maioria os aspectos 
temporais são tratados da mesma forma como o foram nos modelos 
relacionais, não sendo levada em consideração a natureza da orientação a 
objetos e dos problemas que podem advir da utilização deste paradigma. 
 
[ 3,10 ] U 1001 e1 Gadia 180 [ 3, 6 ]
 [ 20, » ] 220 [ 7, 10] U [ 20, 25]
250 [ 26, » ]
 [ 7, 35 ] 1002 e2 Segev 110 [ 7, 20]
180 [ 21, 35]
[ 2, 20 ] U 1003 e3 Clifford 200 [ 2, 20] U [ 30, 35]
 [ 30, » ] 250 [ 36, » ]
 [ 25, » ] 1004 e6 Snodgrass 100 [ 25, 30 ]
130 [ 31, » ]
 [ 5, 25 ] 1005 e8 Jajodia 100 [ 5, 25 ]
 [ 10, » ] 1006 e4 Tansel 170 [ 10, 20]
190 [ 21, » ]
O I D cod nome at-salExistência
Entidade Empregado
O I D
EMPREGADO
O I D
DEPTO
Validade
Temporal
[ 3, 10 ] U 1001 9011
[ 20, 30 ]
[ 31, » ] 1001 9013
[ 7, 20 ] 1002 9011
[ 21, 35 ] 1002 9014
[ 2, 10 ] U 1003 9011
[ 15, 18] U
[ 30, 35 ]
[ 11,14 ] U 1003 9012
[ 19, 20 ]
[ 36, » ] 1003 9014
[ 25, » ] 1004 9014
[ 5, 15 ] 1005 9012
[ 16, 25 ] 1005 9013
[ 10, 20 ] 1006 9012
[ 21, » ] 1006 9014
Relacionamento Lotação
Entidade
 Depto
O I D sigdep nomdepExistência
[ 1, » ] 9011 defin financeiro
[ 3, 20 ] 9012 desis sistemas
[ 10, » ] 9013 depro produção
[ 21, » ] 9014 deinf informática
[ 7, 30 ] 9015 demat materiais
 
Figura 5.4 – Exemplo de povoamento de entidades e relacionamentos em 
TempER 
A utilização de um modelo temporal orientado a objetos tem por 
finalidade a representação de todos os estados assumidos pelo objeto 
durante sua existência. Para que isto seja possível é necessário que o 
modelo permita a representação do comportamento que o objeto deve 
apresentar durante sua evolução. Os seguintes aspectos devem ser 
considerados nestes modelos: 
· a forma utilizada para a representação temporal - a temporização pode 
ser efetuada em dois níveis diferentes: (1) nos objetos, representando a 
evolução do objeto como um todo, sendo registrados o instante em que 
o objeto é criado, suas eventuais suspensões de atividade, o final de 
sua existência, e possíveis ressurreições; e (2) nos atributos, 
representando a variação temporal do valor de um atributo de um 
objeto; 
· como se dará a alteração durante a evolução, tanto no nível de classes 
como no de objetos das classes – de forma contínua, discreta ou por 
degraus; e 
· a possibilidade de migração de objetos entre classes; e 
· a eventual evolução dos esquemas conceituais (criação de novas 
classes, alterações nas hierarquias de generalização/agregação, 
alteração de atributos, etc.). 
Deste aspectos acima citados, o mais complexo é a possibilidade de 
migração de objetos entre classes. Quando permitido, geralmente é restrito 
à migração entre classes / subclasses. A migração genérica entre 
quaisquer duas classes apresenta restrições semânticas muito fortes. 
Mesmo nos casos de migração entre classes / subclasses, diversas 
restrições e mecanismos são impostos a esta migração. Entre elas: (1) 
quando a migração é por especialização com herança simples, novas 
propriedades são acrescentadas ao objetos, devendo seus valores ser 
definidos pelo usuário ou considerados nulos; (2) quando for por 
especialização com herança múltipla, todas as propriedades das novas 
superclasses devem ser adicionadas ao objeto, sendo seus valores também 
definidos pelo usuário ou considerados nulos; (3) quando for por 
generalização por herança simples, todas as propriedades específicas das 
subclasses devem ser removidas do objetos; e (4) quando for por 
generalização por herança múltipla, além das propriedades específicas das 
subclasses, todas aquelas que foram herdadas de outras subclasses devem 
também ser removidas. 
5.3.1 TF-ORM 
TF-ORM (Temporal Functionality in Objects With Roles Model) [Edelweiss 
93, 94a] é um modelo de dados orientado a objetos que utiliza o conceito 
de papéis para representar os diferentes comportamentos dos objetos. 
Neste modelo é considerada a representação temporal dada por rótulos 
bitemporais, sendo o elemento temporal primitivo o ponto no tempo. A 
variação temporal é discreta, por escada, e a menor granularidade o 
minuto. 
O modelo TF-ORM apresenta três diferentes tipos de classes: (i) recurso 
- define a estrutura de um recurso (dado ou documento) em termos dos 
papéis que este recurso pode apresentar durante seu ciclo de vida, com 
propriedades, mensagens permitidas e estados; (ii) agente - nas quais pode 
ser representada a parcela de trabalho não estruturado dos sistemas de 
informação, que é o poder decisão humana; (iii) processo - integram as 
classes de recursos e agentes, permitindo a descrição do trabalho 
realizado. Cada classe é definida por um nome, um papel básico e um 
conjunto de outros papéis. 
A utilização do conceito de papéis tem por objetivo separar a 
representação dos aspectos estáticos de um objeto dos seus aspectos 
dinâmicos. Através da utilização deste conceito são evitados problemas de 
migração entre classes - um mesmo objeto pode desempenhar 
simultaneamente mais de uma papel, pode mudar de papel 
dinamicamente (mudar seu comportamento) e pode, ai nda, desempenhar 
mais de uma instância de uma mesmo papel no mesmo momento. 
Um papel básico descreve as características iniciais de uma instância e 
as propriedades globais que controlam sua evolução. As propriedades do 
papel básico se aplicam a todos os demais papéis e ao contrário dos outros 
papéis que podem ser instanciados mais de uma vez, somente pode 
apresentar uma instância. Cada papel é definido por: (i) um nome; (ii) um 
conjunto de propriedades; (iii) um conjunto de estados, que o objeto neste 
papel pode apresentar; (iv) um conjunto de mensagens que o papel pode 
receber ou enviar; (v) um conjunto de regras de transição de estado e 
regras de integridade. Através das regras de transição de estados são 
definidos os diferentes comportamentos possíveis quando desempenhando 
um determinado papel. A figura 5.5 apresenta um exemplo de modelagem, 
expresso na linguagem de definição TF-ORM. É feita a definição de uma 
classe de agente PERSON (pessoa), que apresenta três papéis além do 
papel básico: employee (empregado), teacher (professor) e student 
(estudante). Cada um destes papéis apresenta propriedades próprias, e 
regras que definem seu comportamento. 
O tempo é acrescentado tanto ao nível de objetos (para definir criação, 
suspensões, término das instâncias) como ao nível das propriedades. As 
propriedades podem ser estáticas (tem o mesmo valor durante todo o ciclo 
de vida da instância) ou dinâmicas (a propriedade pode assumir diferentes 
valores com o passar do tempo). As propriedades dinâmicas possuem um 
rótulo bitemporal - tempo de transação e um tempo de validade - 
associados. Uma informação é considerada válida quando o tempo de 
validade é atingido e continuará neste estado até o início da validade de 
outro valor. Para definição das propriedades, o modelo apresenta um 
conjunto de classes pré-definidas para serem usadas como domínio, 
chamadas tipos de dados. O modelo apresenta ainda um conjunto de 
propriedades pré -definidas como oId, rId, class_instance e class_end, 
destinadas a armazenar respectivamente o identificador da classe, o 
identificador do papel, o início de vida da instância da classe e o momento 
em que ela deixa de existir. 
A linguagem de consulta [EDE 94b] apresenta a seguinte estrutura: 
SELECT <cláusula de especificação> 
 FROM <cláusula de identificação> 
 WHERE/WHEN <cláusula de busca> 
 [ ON <cláusula de instante temporal>] 
agent class ( 
 PERSON, 
 < base_role, 
 static properties = {(person_id, integer)}, 
 dynamic properties = { (name, string), (address, string)}, 
 rules = { ... } >, 
 < employee, 
 dynamic properties = {(department, string), (salary, real), 
(hired, date), 
 (holidays, interval(closed, date), … }, 
 states = {hired, in_holidays, fired}, 
 messages = { 
 new_salary(Oid, Value) from Control.Salaries, 
 ask_vacations(oid, Period) to Control.Holidays, … }, 
 decisions = { get_vacations( Period), … }, 
 rules = { 
 init: add_role Þ state( hired ), 
 holidays: state(hired), decision(get_vacancies( Period) Þ 
 msg(ask_vacancies(oid, Period), state (hired), 
 salary: state(hired), msg(new_salary(oid, Value) Þ 
sate(hired); 
 (Value > salary), 
 … } > 
 < teacher, 
 dynamic properties = { (gratification, real), (start, date), … }, 
 … > 
 < student, 
 static properties = { (student_number, integer) }, 
 dynamic properties = { (courses, string), (start, date), … }, 
 … > ) 
 
Figura 5.5 – Exemplo de modelagem
TF-ORM 
A cláusula de especificação SELECT, define as saídas da consulta. Três 
tipos de saídas são identificadas: saída de dados, saída temporal e saída 
mista. A saída de dados é obtida quando são especificadas as partes do 
objeto que devem ser mostradas pela consulta. Para obter uma saída de 
dados a cláusula de especificação pode ser composta: (i) pelo nome de uma 
ou mais propriedades; (ii) pelo símbolo especial "*", quando forem 
solicitados os valores de todas as propriedades do(s) objeto(s) 
identificado(s). Para obter a saída temporal, as seguintes palavras 
especiais podem ser utilizadas na cláusula de especificação: DATE (quando 
solicitada uma data de validade), TRANSACTION_DATE (data de 
transação), PERIOD (intervalo limitado por datas de validade). A saída 
mista é obtida quando os elementos da saída de dados e da saída temporal 
forem combinados na cláusula de especificação. 
A cláusula FROM é utilizada para identificar as classes e papéis 
participantes da consulta. A qualificação do papel através do nome da 
classe a que corresponde não se faz necessária quando o esquema sobre o 
qual está sendo definida a consulta apresentar todos os papéis com nomes 
únicos. 
A cláusula WHERE é utilizada para buscar informações 
correspondentes ao instante de tempo considerado (snapshot do banco de 
dados). A utilização da cláusula WHEN aumenta o universo de busca, 
incluindo dados passados e futuros, além dos atuais. O acréscimo da 
cláusula AS ON fixa uma história anterior à história atual do banco de 
dados, de acordo com a qual os valores devem ser recuperados. Todas as 
informações que foram inseridas no banco de dados após a data 
especificada na cláusula AS ON são desconsideradas na consulta. 
6 Evolução de Esquemas em Bancos de Dados Temporais 
O esquema conceitual de um banco de dados representa os requisitos de 
dados da aplicação. Durante a existência de um sistema de banco de 
dados seu esquema conceitual pode mudar (evoluir) devido a modificações 
ocorridas, por exemplo, na legislação vigente, nos requisitos dos usuários e 
nos requisitos dos dados. As modificações de um esquema com o passar 
do tempo são uma regra e não uma exceção na vida de um banco de 
dados. 
A maioria dos sistemas cedo ou tarde apresenta a necessidade de 
alterar sua representação (caracterizada pelo esquema), para adaptar-se a 
situações tais como [Moreira 97]: 
· ocorrência de mudanças na parte da realidade que é relevante ao 
sistema; 
· alterações nos requisitos ou erros ocorridos durante as fases de análise 
e projeto do sistema; 
· aumento do domínio do sistema; 
· necessidade de melhoria no desempenho do sistema. 
Três são as possíveis modificações feitas em um esquema durante 
sua evolução: adicionar novas informações (por ex., definir um novo 
atributo), remover informações do esquema (por ex., remover um atributo), 
e modificar informações existentes (por ex., modificar o tipo de um 
atributo). 
A modificação do esquema conceitual pode afetar o sistema de diversas 
formas. Dois problemas fundamentais devem ser considerados [Goralwalla 
97]: 
· semântica da alterações efetuadas no esquema – efeitos das 
alterações no esquema na representação da aplicação, podendo ser 
perdidas informações importantes. O enfoque tradicional para 
solucionar este problema é definir um conjunto de invariantes do 
esquema que devem ser preservadas nas modificações efetuadas (por 
ex., atributos que não podem mudar). Sempre que uma nova versão do 
esquema é definida, deve ser feita uma verificação da integridade deste 
esquema, analisando as invariantes do esquema. As invariantes 
geralmente são representadas através de condições que devem ser 
sempre satisfeitas, representando as restrições de integridade 
estrutural do modelo de dados. A nova versão do esquema somente 
deve ser aceita se as invariantes forem satisfeitas; 
· propagação das alterações – consiste nos efeitos da alteração na 
consistência da base de dados já existente. Este problema é 
tradicionalmente resolvido através de adaptação da base dados 
existente ao novo esquema - no instante de tempo em que uma nova 
versão de um esquema se torna válida, algumas adaptações se fazem 
necessárias na extensão do banco de dados, para que os valores 
válidos naquele momento, definidos de acordo com o esquema anterior, 
possam corresponder à nova versão do esquema. Esta adaptação não 
deve destruir os dados passados, como era feito nos bancos de dados 
estáticos. Como exemplo de adaptação, quando na nova versão do 
esquema é removido um atributo temporal, todos os valores definidos 
para este atributo devem ter sua validade temporal terminada. A 
evolução do esquema pode também afetar a implementação de métodos 
e dos programas de aplicação. 
Vários estudos sobre a evolução de esquemas foram desenvolvidos 
considerando modelos relacionais, entidade -relacionamento e orientados a 
objetos. Entretanto, a maioria destes estudos não trata de bancos de 
dados temporais - somente uma versão do esquema pode existir a cada 
instante, devendo toda extensão do banco de dados ser adaptada para esta 
versão. Recentemente tem sido analisada a possibilidade de tratar da 
evolução de esquemas quando utilizados bancos de dados temporais na 
extensão do BD [Ariav 91, Kim 95, McKenzie 90, Roddick 92] e também 
para armazenar as diferentes versões de esquemas [DeCastro 95-97, 
Goralwalla 97, Edelweiss 95-97, Roddick 94, Zaniolo 97]. 
6.1 Modificação, Evolução e Versionamento de Esquemas 
Estes três termos têm sido utilizados como sinônimos. No glossário de 
conceitos de bancos de dados temporais [Jensen 94] são apresentadas as 
três definições a seguir. 
· Modificação de Esquemas – uma modificação de esquema ocorre 
quando o SGBD permite modificações na definição do esquema de uma 
base de dados populada; 
· Evolução de Esquemas – ocorre quando o SGBD permite modificações 
da definição do esquema de uma base de dados populada sem causar 
perda de informações. Estas alterações devem ser propagadas de modo 
a garantir a consistência e a integridade dos dados armazenados; 
· Versionamento de Esquemas – acontece quando o SGBD permite a 
visualização de todos os dados, tanto retrospectivamente quanto 
prospectivamente, através das várias versões de esquemas definidas 
pelo usuário. Pode ser parcial, quando são permitidas somente 
alterações sobre o esquema corrente, ou total, quando as alterações 
podem ser efetuadas sobre qualquer versão do esquema. Como alguns 
dos aspectos relativos a versionamento de esquemas total ainda estão 
em aberto, somente o versionamento parcial é considerado na maioria 
dos trabalhos sobre este assunto, assim como neste texto – portanto, 
somente o esquema atual pode ser modificado. 
6.2 Como Tratar Evolução de Esquemas em Bancos de Dados 
Temporais 
Sistemas de bancos de dados não temporais apresentam um esquema 
estático e uma correspondente base de dados também estática. Para 
manipular a evolução de esquemas, o enfoque tradicional tem sido o de 
modificar o esquema conceitual e fazer as alterações necessárias na 
extensão do banco de dados, de modo a adaptá-la ao novo esquema. Desta 
forma, somente o último esquema (atual) fica armazenado. 
Quando é utilizado um banco de dados temporal, a utilização desta 
forma de manipulação da evolução do esquema implica em eventual perda 
ou alteração das informações passadas – os dados passados continuam 
disponíveis, mas precisam ser adaptados ao novo esquema, para que 
possam ser consultados de acordo com o esquema atual. Como o princípio 
que rege o conceito de bancos de dados temporais é o de não perder 
informações passadas, a evolução do esqu ema conceitual deveria permitir 
a recuperação de informações passadas de acordo com o esquema vigente 
naquele momento. Uma melhor representação da realidade requer que, 
quando ocorrer
a evolução do esquema conceitual, todas as versões deste 
esquema (a atual e as passadas) estejam disponíveis. 
As seguintes formas podem ser utilizadas para armazenar os dados e 
os esquemas em bancos de dados temporais: 
· múltiplos repositórios – esta solução requer a criação de tantos 
repositórios quantas forem as versões do esquema. Neste caso, cada 
repositório é formado de acordo com a versão do esquema 
correspondente. Quando um novo repositório é inicializado, as tuplas 
são copiadas do repositório antigo de acordo com as mudanças 
aplicadas ao esquema; 
· repositório único com esquema global – é utilizado um repositório único 
para os dados da extensão, armazenados de acordo com um esquema 
global que inclui todos os atributos introduzidos pelas sucessivas 
mudanças do esquema. Se algum atributo for excluído ou tiver seu 
domínio restringido, a mudança não será executada fisicamente, mas 
será gravada em um catálogo, já que nenhum dado pode ser 
descartado do repositório, sob pena de jamais poder ser recuperado 
novamente. Se, ao contrário, a mudança propuser a adição de um novo 
atributo ou a extensão de um domínio, todo o repositório vai ter de ser 
convertido para o novo formato. Se a mudança para o novo domínio 
produzir um novo domínio incompatível com o antigo, dois atributos 
deverão ser mantidos com o mesmo nome às vistas do usuário, 
correspondendo a domínios diferentes e pertencendo a diferentes 
versões do esquema; 
· repositório único com múltiplos esquemas – é também utilizado um 
repositório único, mas todas as diferentes versões do esquema ficam 
disponíveis. As diversas versões do esquema ficam armazenadas em 
um (meta-) banco de dados, também temporal. A recuperação de 
informações é feita de acordo com o esquema válido no momento 
considerado, possibilitando desta maneira uma representação mais fiel 
da realidade. Existe, evidentemente, um aumento do tempo despendido 
para avaliar as consultas, uma vez que o esquema adequado deve ser 
selecionado - é possível que uma mesma consulta utilize mais de uma 
versão do esquema conceitual. A este caso denominamos banco de 
dados temporal generalizado, e será detalhado mais adiante. 
Um conceito importante na utilização de bancos de dados temporais é 
o de vacuuming (gerar vácuo) [Snodgrass 95]. Neste caso é permitida a 
eliminação física de dados temporais não relevantes, para os quais o custo 
de armazenamento é significativo. O mesmo conceito pode ser estendido 
para o armazenamento de esquemas – eliminar versões antigas do 
esquema, principalmente aquelas às quais não correspondem dados 
armazenados na extensão. 
6.3 Banco de Dados Temporal Generalizado 
Um novo tipo de sistema de banco de dados temporal, ao qual 
denominamos banco de dados temporal generalizado [Edelweiss 95], mais 
geral do que os sistemas temporais convencionais, deveria ser utilizado 
para permitir a evolução de esquemas em bancos de dados tempor ais. 
Trata-se de um sistema de banco de dados que apresenta um esquema 
temporal. Cada versão do esquema constitui um novo esquema, ao qual é 
associada alguma informação temporal (tempo de transação e/ou validade 
do esquema). Um esquema temporal é estruturado como uma ou duas (no 
caso bitemporal) seqüências de esquemas. 
 
"meta-esquema" caracterizado pelas
 invariantes do esquema
seqüência de esquemas que constitui o
 “ esquema dinâmico” conjunto de esquemas corretos
 conjunto de estados do BD
válidos para o esquema inicial A
conjunto de estados do BD
 válidos para o esquema B
conjunto de estados do BD
válidos para o esquema C
seqüência de estados
 do BD Temporal
A
B
C
* *
*
a1
a2
a3
a4
b1
b2 b3
c1
c2
c3
 
Figura 6.1: Parte da vida de um sistema de banco de dados temporal 
“generalizado”. 
Na figura 6.1 é apresentada uma idéia geral do comportamento de um 
banco de dados temporal generalizado. Quando um banco de dados 
temporal generalizado é criado, apresenta um esquema inicial (esquema A 
da figura 6.1) e um correspondente estado inicial da extensão do banco de 
dados (a1). Durante o tempo em que este esquema é válido são feitas 
atualizações no banco de dados, criando novos estados do banco de dados 
(a2, a3 e a4), todos pertencendo ao mesmo universo de bancos de dados 
estáticos que satisfazem o esquema A. Os estados a1, a2, a3 e a4 
compõem o banco de dados dinâmico do esquema. 
Uma modificação no esquema gera um novo esquema (B), e um novo 
estado do banco de dados (b1), correspondendo a este novo esquema, deve 
ser construído. Este novo estado do banco de dados deve pertencer ao 
universo de bancos de dados estáticos aceitos pelo esquema B. Quando a 
construção do novo estado do banco de dados (b1) é feita adequadamente, 
os dois estados a4 e b1 apresentam os mesmos conteúdos de informações 
- qualquer informação que um usuário possa obter de a4 também pode ser 
obtida de b1, e vice-versa. Entretanto, sendo os dois esquemas 
correspondentes a estes estados diferentes, a sintaxe da consulta a ser 
construída para obter a informação em a4 possivelmente será diferente da 
sintaxe da consulta de b1. Também a apresentação das respostas nos dois 
casos pode ser diferente. O importante é que a “essência”, a informação 
que está sendo recuperada, seja a mesma. 
Neste tipo de banco de dados os esquemas e as correspondentes 
extensões do banco de dados podem variar com o passar do tempo, sendo 
que todas as diferentes situações que existiram no passado são sempre 
acessíveis. Consultas temporais podem ser feitas neste tipo de banco de 
dados, e para avaliar estas consultas devem ser considerados tanto a 
evolução do esquema conceitual como a evolução da extensão do banco de 
dados. A existência de diversas versões do esquema deve ser levada em 
consideração nas operações de recuperação de informações passadas, 
quando deve ser utilizado o esquema válido naquele momento. Caberá ao 
sistema gerenciador do ba nco de dados a tarefa de identificar os dados 
através de sua correspondente versão de esquema. Esta necessidade 
aumenta a complexidade do sistema como um todo, uma vez que requer o 
armazenamento de múltiplas versões do esquema conceitual. 
6.4 Formas de Armazenar Múltiplos Esquemas 
Uma forma de armazenar as diferentes versões dos esquemas é através da 
utilização de um (meta-) banco de dados temporal. Deste modo, a evolução 
de esquemas pode ser tratada de modo similar à evolução da extensão do 
banco de dados. Informações temporais devem ser acrescentadas às 
diferentes modificações efetuadas no esquema, representando o tempo de 
transação e/ou tempo de validade de cada modificação. A forma utilizada 
para representar estas informações temporais define o tipo do (meta-) 
banco de dados temporal que armazena a evolução do esquema conceitual. 
Considerando os quatro tipos de bancos de dados temporais vistos 
anteriormente, o esquema conceitual pode ser representado por um banco 
de dados instantâneo (caso normal), de tempo de transação, de tempo de 
validade ou bitemporal. 
Esquemas Instantâneos 
O esquema visto como um meta-banco de dados instantâneo tem, em 
qualquer instante de tempo considerado, somente uma instância ou uma 
versão. A transição de uma versão de um esquema pa ra outra versão deve 
obedecer às invariantes do esquema, associadas ao modelo de dados 
utilizado para representar o esquema. Nenhuma informação temporal é 
associada às modificações do esquema, sendo que somente a última 
versão do esquema pode ser referenciada em uma consulta. 
A extensão de um banco de dados que utiliza um esquema instantâneo 
pode ser de qualquer dos tipos de bancos de dados vistos - instantâneo ou 
temporal. A definição de uma nova versão para o esquema conceitual 
implica na necessidade de adaptar as estruturas e os valores armazenados
na extensão do banco de dados de modo a satisfazer o novo esquema 
conceitual. Quando na extensão são utilizados dados históricos, estes 
também devem ser adaptados ao novo esquema, pois será este a ser 
utilizado para recuperar estas informações. A figura 6.2 representa um 
esquema que evolui, apresentando modificações em três tempos diferentes 
(t1, t2 e t3). Em cada um destes instantes de tempo são efetuadas as 
necessárias modificações na extensão do banco de dados. 
 
Esquema
Extensão
t1 t3t2
transformação
de ocorrências
transformação
de ocorrências
transformação
de ocorrências
 
Figura 6.2: Esquema instantâneo 
Esquemas de Tempo de Transação 
Quando a evolução do esquema conceitual é representada através de um 
meta-banco de dados de tempo de transação as sucessivas versões do 
esquema conceitual são acessíveis, cada uma delas associada com o 
correspondente tempo de validade. Transformações elementares no 
esquema (como por exemplo, a definição de um novo atributo) geram uma 
nova versão do esquema. Como neste tipo de banco de dados não são 
utilizados tempos de validade, uma nova versão do esquema se torna 
válida no momento de sua definição, permanecendo válida até que nova 
versão seja definida. A cada vez que uma modificação elementar no 
esquema for efetuada, definindo uma nova versão do esquema, devem ser 
feitas as necessárias adaptações na extensão do banco de dados. Na figura 
6.3 estão representadas três versões de um esquema conceitual, cada uma 
delas válidas a partir do instante de tempo de sua definição (t1, t2 e t3). As 
três versões ficam acessíveis para eventuais consultas. 
A extensão do banco de dados pode ser representada por qualquer um 
dos três tipos de bancos de dados temporais: de tempo de transação, de 
tempo de validade ou bitemporal. A utilização de um meta-banco de dados 
temporal para armazenar a evolução de um esquema não faz sentido 
quando utilizado um banco de dados instantâneo na extensão. Quando na 
extensão for utilizado um banco de dados de validade ou um banco de 
dados bitemporal pode acontecer de uma determinada informação, 
inserida no banco de dados sob uma determinada versão do esquema, se 
tornar válida somente sob outra versão do esquema - as adaptações feitas 
na extensão cada vez que uma nova versão de esquema for definida devem 
considerar a possibilidade desta situação. 
Esquema
Extensão
t3t2
transformação
de ocorrências
t1
transformação
de ocorrências
transformação
de ocorrências
 
Figura 6.3: Esquema de tempo de transação 
Esquemas de Tempo de Validade 
A representação da evolução de um esquema conceitual através de um 
meta-banco de dados de tempo de validade é feita associando a cada 
alteração efetuada no esquema o instante de tempo em que esta alteração 
se tornará válida. O tempo em que é efetuada a transação no meta-banco 
de dados não é registrado. Uma nova versão do esquema se torna válida a 
cada instante em que um novo tempo de validade de uma alteração é 
alcançado. O mesmo tempo de validade pode ser associado a mais de uma 
modificação elementar do esquema - desta maneira um conjunto de 
alterações simultâneas podem ser efetuadas, definindo uma nova versão 
do esquema. A consistência do esquema será testada para o conjunto de 
alterações, de uma só vez. 
Não faz muito sentido modificar um esquema para tempos passados. 
Isto significaria uma modificação retroativa na extensão do banco de dados 
relativa ao esquema modificado, o que não é nem possível nem 
significativo. As modificações permitidas em tempos de validade para 
esquemas conceituais deveriam ser efetuadas somente sobre tempos 
futuros - em partes do esquema que se tornarão válidas em tempos 
posteriores à modificação realizada. 
Na figura 6.4 está representada a evolução de um esquema 
representado através de um banco de dados de tempo de validade. No 
tempo t1 iniciou a validade de uma versão deste esquema, sendo feitas as 
necessárias adaptações na extensão do banco de dados. Em t2 é definida 
uma alteração que terá validade a partir do tempo t4. A versão do esquema 
válida em t2 continua sendo a anterior, que iniciou em t1. Em t3 é feita 
outra alteração no esquema, também válida somente em t4. A versão de 
esquema válida continua sendo aquela definida no tempo t1. Ao ser 
alcançado o tempo t4 as alterações feitas anteriormente iniciam sua 
validade, definindo uma nova versão do esquema. Neste momento são 
feitas as necessárias transformações na extensão do banco de dados, para 
adequá-lo à nova versão do esquema. Como está sendo utilizado um meta-
banco de dados de tempo de validade, os instantes de tempo t2 e t3 não 
ficam armazenados - somente o tempo t4 é associado às alterações 
definidas. 
t1 t4t2
Esquema
Extensão
transformação
de ocorrências
transformação
de ocorrências
t3
 
Figura 6.4: Esquema de tempo de validade 
Esquemas Bitemporais 
A evolução de um esquema conceitual também pode ser representada 
através de um meta-banco de dados bitemporal. Neste caso, a cada 
alteração efetuada no esquema são associados dois tempos - o tempo de 
transação e o tempo de validade. O tempo de transação informa quando foi 
efetuada a alteração, enquanto que o tempo de validade define a partir de 
que instante esta transformação do esquema se torna válida. Também 
neste caso o tempo de validade deveria ser igual ou posterior ao tempo de 
transação, pois não faz sentido alterar versões passadas do esquema. 
A consistência de uma nova versão do esquema conceitual é verificada 
a cada vez que é alcançado um novo tempo de validade associado a 
alguma transformação. Neste momento também são efetuadas as 
necessárias alterações na extensão do banco de dados, para satisfazer a 
nova versão válida do esquema. Os tempos de transação armazenados 
somente servem para informar quando foram efetuadas as transformações 
do esquema - na recuperação de informações do banco de dados sempre 
são consideradas as versões válidas do esquema, portanto, os tempos de 
validade associados às informações do meta-banco de dados. A figura 6.4 
também pode ser interpretada como representando esquemas bitemporais, 
sendo que neste caso os tempos t2 e t3 também devem ser armazenados. 
6.5 Exemplo de Versionamento de Esquemas em TSQL2 
As possibilidades de evolução de um esquema conceitual e as 
conseqüentes alterações que devem ser efetuadas na extensão do banco de 
dados dependem do modelo de dados que estiver sendo utilizado. A 
linguagem de consulta TSQL2 [Snodgrass 95] apresenta suporte a 
versionamento de esquemas de tempo de transação, sendo os esquemas 
prévios armazenados sob forma de versões. Somente o esquema atual pode 
ser modificado (versionamento parcial). 
No modelo de dados do TSQL2 os fatos são representados por tuplas 
compostas de um número arbitrário de atributos explícitos e de um 
atributo temporal implícito (tempo de transação e/ou tempo de validade). 
A introdução de versionamento de esquemas neste modelo afeta a 
composição e os métodos de recuperação e atualização dos atributos 
explícitos. 
Seja R = (A1, … , An) um esquema relacional bitemporal. Se não 
existisse versionamento de esquema, a tupla x teria a forma (a1,…, an|t). 
Com a introdução do versionamento de esquema, o esquema relacional R é 
considerado completo – R contém a união de todos os atributos que foram 
definidos durante a existência da tabela. O domínio de cada atributo desta 
tabela é tal que contenha todos os dados armazenados para cada 
esquema. Uma função de visualização V(t1) mapeia Rt1 a um subconjunto 
dos atributos no esquema St1, ativo no momento t1. A função V’(t2) mapeia 
de St2 para R. Deste modo, os dados armazenados em t1 podem ser 
mapeados para o formato especificado em t2 através de função V(V’(t1), t2). 
O exemplo a seguir, apresentado em [Snodgrass 95], ilustra
como é feita a 
evolução de esquemas neste modelo. 
 Consideremos a seguinte história estrutural da tabela Empregado: 
01/01/93 – tabela Empregado: 
 Id NUM(6), 
 Nome CHAR(30), 
 Salario NUM(5,2) 
01/02/93 – acréscimo dos seguintes atributos: 
 Sexo CHAR(1), 
 Estadocivil CHAR(1) 
01/03/93 – removido o atributo Estadocivil 
01/04/93 – o atributo Salario é redefinido: 
 Salario NUM(5) 
02/04/93 – o atributo é novamente redefinido como: 
 Salario NUM(5,2) 
Após feitas todas estas modificações, o esquema completo para esta 
tabela é o seguinte: 
Id NUM(6), 
Name CHAR(30), 
Estadocivil CHAR(1), 
Salario NUM(5,2). 
As funções V e V’ estão disponíveis em todos os pontos de tempo, para 
converter do esquema armazenado para o esquema completo R, e depois 
do esquema R para o esquema que deve ser considerado na consulta. 
6.6 Exemplo de Evolução de Esquemas em um Modelo Temporal 
Orientado a Objetos 
Considerando um modelo temporal orientado a objetos, a história de um 
objeto pode ser representada pela seqüência de valores assumidos por 
seus atributos durante sua existência. Na extensão de um banco de dados 
temporal são armazenados: (1) valores de propriedades estáticas, que não 
apresentam rótulos temporais, uma vez que são sempre válidas, e (2) 
valores de propriedades dinâmicas, rotuladas com os tempos de transação 
e/ou de validade. 
Neste exemplo consideramos que as versões do esquema são 
armazenadas em um meta-banco de dados de tempo de validade - uma 
nova versão do esquema será, portanto, produto de um conjunto de 
alterações e lementares na versão anterior do esquema. Ao ser alcançado o 
tempo de início de validade de uma nova versão do esquema, esta deve ser 
validada, sendo verificado se está de acordo com as invariantes do modelo. 
No caso da versão ser válida, a extensão do banco de dados deve ser 
adaptada a ela. 
6.6.1 As Invariantes de um Modelo Temporal Orientado a Objetos 
Um modelo temporal orientado a objetos genérico apresenta, pelo menos, 
as seguintes invariantes: 
· unicidade de nomes: 
¨ as classes devem apresentar nomes únicos; 
¨ em uma classe, nomes de propriedades e de mensagens 
(representando os métodos) devem ser únicos; 
· para toda propriedade deve ser definido um domínio; 
· todos os nomes de classes e propriedades utilizados em condições (pré 
e pós- condições e regras de integridade ) devem estar definidos; 
· toda superclasse referenciada em uma subclasse deve estar definida; 
· todas as classes componentes de uma classe agregada devem estar 
definidas. 
6.6.2 A Evolução do Esquema 
Existem modificações elementares que não podem ocorrer sozinhas - 
modificações complementares são necessárias para garantir a corretude do 
esquema. Este é o motivo pelo qual foi escolhido um meta-banco de dados 
de validade para armazenar o esquema. 
As modificações elementares que podem ser efetuadas no modelo aqui 
utilizado são as seguintes: 
· criação de uma nova classe, destruição de uma classe existente, 
renomeação de uma classe; 
· criação de uma nova propriedade, destruição de uma propriedade, 
renomeação de uma propriedade, modificação do domínio de uma 
propriedade, alteração do tipo (estático - dinâmico) de uma 
propriedade; 
· alterações de interfaces de comunicação entre classes - criação de uma 
nova mensagem (método), remoção ou renomeação de uma mensagem 
existente, modificação nos parâmetros de uma mensagem. 
Nas figuras 6.5 e 6.6 é apresentado um exemplo de evolução de um 
esquema (2 versões), utilizando um DDL genérica. Na primeira versão 
(figura 6.5) é definida apenas uma classe de empregados de uma empresa 
(Employee), que apresenta duas propriedades - uma propriedade 
considerada inicialmente como estática, o nome do empregado (name) e 
uma propriedade dinâmica para representar seu salário (salary). Na 
segunda versão deste esquema (figura 6.6) o tipo da propriedade que 
representa o nome foi trocado para dinâmica pois foi constatado que o 
nome de uma pessoa pode mudar (casamento, separação). Além disso, na 
segunda versão foi acrescentada outra classe para modelar os 
departamentos da empresa (Department), apresentando as propriedades 
dinâmicas nome do departamento (dept_name) e o gerente do 
departamento (dept_manager). O gerente do departamento é um 
empregado, sendo representado por uma instância desta classe. Na classe 
dos empregados foi, ainda, acrescentada um propriedade dinâmica para 
indicar qual o departamento em que este empregado está trabalhando 
(dept). 
 
(Class Employee 
 static properties = {(name, string)} 
 dynamic properties = {(salary, real)} 
 messages = { reg(Name: string, Salary: real) from Outer_World, 
 new_sal (Salary: real) from Outer_World, 
 end_employment from Outer_World } ) 
Figura 6.5: Primeira versão do esquema 
 
Figura 6.6: Segunda versão do esquema 
6.6.3 Adaptação da Extensão do Banco de Dados como Conseqüência 
da Evolução do Esquema 
As seguintes adaptações são necessárias na extensão do banco de dados 
temporal que implementa um modelo orientado a objetos: 
· criação de uma nova classe – não implica em adaptação da extensão; 
· remoção de uma classe existente – terminar a validade de todas as 
propriedades dos objetos desta classe e fechar o intervalo de existência 
dos objetos desta classe; 
· renomeação de uma classe – como os objetos da extensão são 
identificados pelos seus identificadores próprios (oId), não será 
necessária nenhuma adaptação da extensão. Deverá, entretanto, 
existir uma forma de identificar os nomes das duas classes como 
correspondendo à mesma classe (por ex., um dicionário de sinônimos); 
· definição de nova propriedade estática – a definição desta propriedade 
deve ser feita na extensão para todas as instâncias desta classe, com o 
valor inicial null; 
· definição de nova propriedade dinâmica – não implica em adaptação, 
uma vez que valores para esta propriedade somente serão definidos a 
partir deste momento; 
· remoção de uma propriedade estática – não implica em adaptação, uma 
vez que não será definido nenhum valor para esta propriedade segundo 
o novo esquema; 
· remoção de uma propriedade dinâmica – terminar a validade dos 
valores definidos para esta propriedade; 
(Class Employee 
 dynamic properties = { (name, string), (salary, real), (dept, 
DEPARTMENT)} 
 messages = { reg(Name: string, Salary: real, Dept: DEPARTMENT) 
from Outer_World, 
 new_sal(Salary: real) from Outer_World, 
 new_dept(Dept: DEPARTMENT) from Outer_World, 
 end_employment from Outer_World } ) 
(Class Department 
 dynamic properties = {(dept_name, string), dept_manager, 
EMPLOYEE)} 
 messages = { dept_name(Name: string) from Outer_World, 
 new_mgr(Mgr: EMPLOYEE) from Outer_World, 
 dismiss_mgr from Outer_World } ) 
· renomeação de uma propriedade – neste caso também deverá ser 
introduzida a correspondência entre os dois nomes em um dicionário de 
sinônimos; 
· alteração no tipo (domínio) de uma propriedade – adaptações devem ser 
feitas em todos os valores armazenados para esta propriedade, para 
adaptá-los ao novo domínio. Os valores válidos de propriedades 
dinâmicas devem ter sua validade encerrada quando terminar a 
validade do esquema anterior. Se o valor que a propriedade apresentar 
puder ser adaptado ao novo tipo (ex., inteiro para real), deverá ser feita 
esta adaptação e o valor adaptado tem seu início de validade 
coincidente com o início da validade do novo esquema. Se, no entanto, 
isto não for possível (ex., inteiro para string), um novo valor deverá ser 
definido pelo usuário, juntamente com o início de sua validade. A 
mesma adaptação de tipos de valores deve ser feita para as 
propriedades estáticas; 
· modificação de propriedade estática para dinâmica – todas as 
instâncias da classe deverão
receber a definição desta propriedade com 
o novo tipo, com o valor que a propriedade estática apresentava e com o 
tempo de validade igual ao do início da validade da nova versão do 
esquema; 
· quando uma propriedade dinâmica tem seu tipo alterado para estático é 
necessária a definição da propriedade estática para todas as instâncias 
da classe, com o último valor válido da propriedade dinâmica; 
· alterações em mensagens – não se refletem na extensão da base de 
dados. 
7 Implementação de Bancos de Dados Temporais 
Embora as pesquisas em BD temporais se estendam já por mais de 20 
anos, poucos sistemas realmente utilizáveis existem. Existem, sim, várias 
experiências sob forma de protótipos, nos quais se baseiam estudos de 
problemas encontrados (de armazenamento e recuperação de informações), 
e mapeamentos de modelos temporais para BD tradicionais, nos quais os 
rótulos temporais são explicitamente representados e manipulados. 
Como exemplos de implementações de BD Temporais, podemos citar o 
Temporal ODBMS TIGUCAT [Özsu 95], em desenvolvimento na 
Universidade de Alberta, no Canadá; o BD Postgres, que apresenta suporte 
ao tempo de transação. 
A implementação do conceito de tempo pode ser realizada de três 
formas de acordo com o grau de integração crescente do conceito de tempo 
no SGBD. Estas categorias são [Edelweiss 94]: 
· a manipulação dos dados temporais é realizada explicitamente pelo 
usuário. O SGBD só pode armazenar dados dos tipos tradicionais como 
inteiros, strings, reais etc. Toda a semântica associada ao tempo está 
contida na lógica dos programas de aplicação. Neste nível o usuário 
deve conhecer a semântica associada ao tempo e assegurar a validade 
das operações sobre os dados temporais; 
· a manipulação dos dados temporais é realizada por meio de ações 
associadas a propriedades definidas como temporais. Isto corresponde a 
extensões semânticas de tipos de dados normais. Esta solução pode ser 
aplicada em SGBDs extensíveis pela definição de ações semânticas 
associadas a tipos de dados temporais. Neste caso todas as aplicações 
compartilham o código associado aos novos tipos de dados. A grande 
fraqueza é o isolamento entre as operações e o esquema conceitual. É 
impossível representar as propriedades temporais no esquema 
conceitual pois a semântica temporal é definida por modificações na 
manipulação de dados tradicionais (reais, string). Uma solução deste 
tipo é apresentada como uma extensão do SGBD INGRES [Overmeyer 
82]; 
· as propriedades temporais são tratadas por uma extensão do modelo de 
dados e da linguagem de manipulação. Neste caso a semântica 
temporal se torna estrutural, isto é, ela pertence ao modelo de dados e, 
portanto, não pode ser alterada pelas aplicações. A definição de um 
esquema conceitual inclui as propriedades temporais. O principal 
inconveniente consiste na necessidade de ser desenvolvida uma nova 
versão do SGBD incluindo as extensões. 
7.1 Aspectos Fundamentais na Implementação de BD Temporal 
O conceito de BD Temporais supõe que o conceito de tempo seja implícito, 
como no caso da terceira categoria acima apresentada. Segundo [Tansel 
93], acrescentar suporte temporal a um SGBD ocasiona um impacto 
importante sobre todos os seus componentes. A arquitetura simplificada 
de um SGBD convencional é apresentada na figura 7.1. O administrador 
do BD (DBA) e sua equipe projetam o BD, gerando o esquema conceitual 
físico. Este esquema, expresso em uma linguagem de definição de dados 
(DDL), é processado pelo compilador desta linguagem e armazenado no 
catálogo do sistema. Os usuários, por sua vez, preparam suas consultas, e 
as submetem ao processador de consultas. Cada consulta é, inicialmente, 
analisada léxica e sintaticamente, com base nas informações que constam 
do catálogo do sistema, sendo depois otimizada, para que sua execução 
seja eficiente. Um plano de avaliação da consulta é enviado ao avaliador da 
consulta. Enquanto a consulta está sendo avaliada, este componente 
acessa o BD através do gerenciador de dados armazenados, o qual 
implementa controle de concorrência, gerenciamento de transações, 
recovery, buffering e métodos de acesso a dados. 
DBA
DDL
Compilador 
DDL
Catálogo do 
Sistema
Usuários
Consultas
Processador de 
Consultas
Avaliador da
Consulta
Gerenciador de Dados
Compartilhados
BD Temporal
 
Figura 7.1 – Arquitetura simplificada de um SGBD tradicional [Tansel 93] 
O acréscimo de informações temporais implícitas ao BD influencia 
cada uma das partes do SGBD, que devem ser adaptadas para permitir 
consultas eficientes. A seguir, vamos analisar superficialmente alguns 
aspectos influenciadas pelo acréscimo de tempo ao BD (detalhes podem 
ser encontrados em [Tansel 93]. 
(1) DDL – as linguagens de consulta também são utilizadas para definição 
de dados (por ex., CREATE TABLE do SQL) e para atualização de dados 
(por ex., INSERT, DELET e UPDATE do SQL). Para manipular 
informações temporais, estas linguagens de consulta devem permitir a 
definição de domínios temporais e oferecer suporte a tempo de 
transação e/ou validade. 
(2) Catálogo do Sistema – vai depender do tipo de BD temporal utilizado. 
Geralmente é feito suporte somente a esquemas de tempo de 
transação. 
(3) Otimização de Consultas – a otimização de consultas temporais é bem 
mais complicada do que no caso de consultas convencionais. O 
primeiro problema para a otimização é o grande número de dados 
envolvidos. O tempo despendido na consulta pode ser muito elevado 
dependendo do volume de dados, justificando que seja despendido um 
tempo maior na otimização da consulta. Um segundo problema para a 
otimização são os predicados envolvidos em consultas temporais, que 
são mais difíceis de serem otimizados, gerando cada um diversos 
predicados de consultas tradicionais (por exemplo, o operador 
OVERLAP é traduzido por dois predicados aplicados sobre os rótulos 
temporais). Por outro lado, existe maior possibilidade de otimizar uma 
consulta quando envolve tempo – como o tempo está sempre 
avançando, em uma só direção, o ponto no tempo mais recente é o 
maior valor do seu domínio. Esta ordenação natural pode auxiliar na 
otimização da consulta – por exemplo, no caso de dados relativos a 
salários com rótulos temporais de intervalos de validade, onde termina 
a validade de um salário inicia imediatamente a validade de outro 
valor. A otimização semântica de consultas pode utilizar as restrições 
de integridade definidas para a aplicação (como no caso do salário), 
além de condições adicionais. A otimização de consultas pode ser local 
(de uma só consulta) e/ou global (de diversas consultas 
simultaneamente), sempre envolvendo a geração de um plano de 
otimização, o qual consiste de uma expressão algébrica associada a 
métodos de acesso. 
(4) Avaliação de Consultas – várias técnicas foram analisadas para melhor 
a eficiência da avaliação de consultas. Entre elas podemos citar: (i) a 
proposta de separar os dados históricos dos atuais (técnica 
denominada de particionamento temporal). Como um grande número 
de consultas se refere a dados atuais, e como estes geralmente são 
estáveis, a separação tem apresentado bons resultados; (ii) para 
proporcionar avaliação eficiente das consultas diversos novos métodos 
de indexação temporal têm sido propostos para BD temporais, 
procurando evitar que um número muito elevado de dados seja 
analisado para a consulta; e (iii) por serem uma das operações mais 
comuns e ao mesmo tempo mais dispendiosas na avaliação de 
consultas, os joins têm sido muito analisados, sendo desenvolvidos 
vários algoritmos novos para esta operação. 
(5) Gerenciador dos Dados Armazenados – com relação aos dados 
armazenados, três aspectos importantes devem ser analisados: as 
estruturas de armazenamento (incluindo layout de página), o controle 
de
concorrência, e a recuperação (recovery). 
¨ Estruturas de armazenamento - várias estruturas de 
armazenamento têm sido propostas, incluindo encadeamento 
reverso (todas as versões históricas de uma determinada chave são 
encadeadas em ordem reversa), listas de acesso (um bloco de 
valores temporais e de identificadores de tuplas associadas entre o 
armazenamento corrente e o histórico), clustering (armazenar 
versões históricas em conjunto, em um conjunto de blocos), 
stacking (armazenando um conjunto fixo de versões históricas) e 
encadeamento celular (encadeando blocos de versões históricas 
“clusterizadas”). 
¨ Controle de concorrência – diversos pesquisadores têm analisado a 
possibilidade de adaptar técnicas existentes de controle de 
concorrência e de gerência de transações para apresentar suporte 
ao tempo de transação. Também tem sido analisada a forma de 
rotular com tempo conjuntos distribuídos, e como fazer a 
integração de índices temporais com o controle de concorrência. 
¨ Recovery – BD de tempo de transação podem ser facilmente 
utilizados para recuperação, em caso de falhas, uma vez que todos 
os estados passados estão disponíveis. Mesmo que parte dos dados 
atuais seja perdida devido à falha, um estado passado pode ser 
reconstruído. 
7.2 Implementações sobre Bancos de Dados Comerciais Tradicionais 
A utilização de um modelo de dados temporal no nível de modelagem, com 
grande poder de expressão, não implica que seja necessária a existência de 
um banco de dados correspondente a este modelo. Podem ser utilizados 
BD comerciais, com todas as características de robustez que apresentam, 
desde que seja possível mapear adequadamente o modelo temporal para o 
modelo do BD utilizado. Além disso, é interessante que o modelo de 
consulta do modelo temporal seja também mapeado para a linguagem de 
consulta do BD utilizado, de modo a tornar a implementação totalmente 
transparente ao usuário. 
Diversos trabalhos têm sido realizadas mapeando modelos ricos em 
expressividade para bancos de dados comerciais, inclusive apresentando 
outras formas de representação conceitual [Oliveira 95]. 
Por exemplo, uma forma genérica de mapear um modelo temporal OO 
para o modelo relacional tradicional é descrita a seguir. Para cada classe é 
criada uma tabela, onde são armazenados o identificador do objeto (OId) e 
suas propriedades estáticas (que não apresentam variação com o tempo). 
Para cada propriedade dinâmica deve ser criada uma tabela especial, que 
traz todos os valores da propriedade com as informações temporais 
associadas (tempo de transação e/ou validade, pontos no tempo ou 
intervalos). As tabelas são unidas pelo valor do OId. A cada novo valor de 
uma propriedade dinâmica, uma nova tupla é inserida nesta tabela. Nota-
se, portanto, que em lugar de uma tabela a implementação deve trabalhar 
com diversas tabelas, representando explicitamente todos os valores 
temporais na forma de atributos. 
8 Modelagem de Aplicações através de Modelos 
Temporais 
Informações temporais, tais como valores temporais, restrições temporais e 
características de evolução temporal, estão presentes em grande número 
de aplicações do mundo real. Modelos de dados temporais podem ser 
utilizados para modelar (especificar) estas aplicações. Isto porque, ao 
construir a especificação de um sistema de informação, não só a estrutura 
dos dados manipulados deve ser definida, mas também sua dinâmica - seu 
comportamento com a passagem do tempo. A representação dos aspectos 
temporais na especificação de um sistema de informação é importante por 
mais de um motivo: (i) o sistema pode apresentar informações temporais a 
serem introduzidas no banco de dados que o representa, sob forma de 
informação propriamente dita; (ii) processos a serem executados podem 
apresentar interações temporais, interações estas que devem também ser 
representadas; (iii) determinadas tarefas podem apresentar pré-condições 
à sua execução, as quais podem ser representadas através de restrições 
temporais; e (iv) condições de integridade temporal do banco de dados 
podem ser necessárias. 
A modelagem de aspectos temporais é um importante tópico da 
modelagem de sistemas de informação. Através destes aspectos são 
representadas as características dinâmicas das aplicações e a interação 
temporal entre diferentes processos. A possibilidade de armazenar, 
manipular e recuperar dados temporais deve ser considerada quando da 
escolha de um método de modelagem. 
Diversas aplicações nas quais as informações temporais são 
fundamentais, podem ser identificadas. Entre elas podemos citar: 
(1) registros de informações acadêmicas, nas quais devem ser 
armazenados todos os conceitos obtidos pelos alunos nos respectivos 
semestres; 
(2) em diversas áreas de empresas, tais como contabilidade (datas de 
contas a pagar e receber, pagamentos efetuados e recebidos, fluxo de 
caixa), orçamento (previsão do orçamento futuro em função das 
despesas passadas e dos prováveis despesas e de prováveis 
recebimentos, tomadas de decisão (ba seadas em informações 
históricas), controle de estoques e em processos de importação / 
exportação; 
(3) aplicações financeiras, como no mercado de ações, aplicações 
bancárias; 
(4) companhias seguradoras, no planejamento de planos a serem 
oferecidos e onde os valores das apólices geralmente são baseados 
nas informações passadas dos clientes; 
(5) sistemas de reservas (de companhias aéreas, de hotéis, de trens); 
(6) Sistemas de Informação Geográficos, para a representação da 
evolução das áreas representadas e para o planejamento de obras 
futuras; 
(7) área médica, onde o registro das informações históricas de pacientes 
é fundamental; 
(8) bancos de dados multimídia, onde evolução da apresentação é 
fundamental; 
(9) modelagem de workflow (fluxo de trabalho), onde o modelo a ser 
construído deve representar não somente os aspectos estáticos da 
aplicação, mas também seus aspectos dinâmicos e sua possível 
evolução. 
A seguir serão analisadas um pouco mais a fundo as últimas áreas acima 
apresentadas. 
8.1 Sistemas de Informação Geográficos 
Sistemas de Informação Geográficos (SIGs) são sistemas automatizados 
usados para armazenar, analisar, manipular e visualizar dados 
geográficos, ou seja, dados que representam objetos e fenômenos em que a 
localização geográfica é uma característica inerente à informação e 
indispensável para analisá-la [Câmara 96]. Caracterizam-se por integrar, 
em uma única base de dados, dados espaciais, descritivos (convencionais) 
e temporais. 
Os seguintes aspectos caracterizam um dado geográfico (georrefenciado) 
[Lisboa 97]: 
· a descrição da entidade geográfica que cada dado representa; 
· a localização geográfica da entidade que o dado representa; 
· o relacionamento entre a entidade geográfica com outras entidades 
representadas no sistema; e 
· o momento ou intervalo de tempo em que a entidade geográfica existe 
ou é válida. 
Um dos aspectos fundamentais para a representação de dados geográficos 
é, portanto, a possibilidade de representação de aspectos temporais 
associados aos dados. O tempo é um conceito essencial para a 
compreensão e a modelagem de fenômenos espaciais em diversas 
aplicações, tais como: ciências biofísicas, pesquisa epidemiológica, ciências 
políticas, econômicas e sociais, e várias aplicações de tempo real para 
gerenciamento e planejamento [Faria 98]. 
A utilização, em SIGs, de um modelo espaço-temporal aumenta a sua 
capacidade de análise, possibilitando o estudo da evolução dos fenômenos 
geográficos [Garaffa 98]. Exemplos de evolução de entidades geográficas 
são (i) o surgimento de novas entidades geográficas, como no caso em que 
uma propriedade agrícola é dividida em duas, (ii) a mutação em entidades, 
como no caso de alteração de limites de uma propriedade, (iii) a fusão de
entidades, como no caso de uma propriedade ser englobada em uma outra 
que lhe era vizinha, e (iv) o desaparecimento de uma entidade, que pode 
ocorrer quando uma árvore é cortada. 
A variação temporal das entidades geográficas pode ocorrer de forma 
contínua, como no caso da alteração do perfil do solo em razão de erosão, 
ou discreta, como no exemplo anterior de alteração de limites de 
propriedades. Para que toda a história de uma região seja conhecida é 
necessário que a evolução da entidades desta região seja registrada, 
possibilitando a recuperação de situações passadas. 
As consultas a SIGs podem envolver tanto o estado de um fenômeno 
quanto a sua distribuição espacial e temporal. Os sistemas gerenciadores 
de SIGs devem responder consultas que devolvam valores de atributos, 
localizações e períodos temporais. Deve, ainda, permitir relacionamentos 
espaciais entre entidades (por ex., proximidade, vizinhança), simulação e 
comparação de cenários alternativos baseados na combinação de camadas 
de dados, e previsões para o futuro através de análise de tendências. 
8.1.1 Modelos temporais para SIGs 
Nas aplicações de SIGs atuais a representação de aspectos temporais não 
têm sido levada em consideração. A maior parte dos sistemas existentes 
não considera tempo ou, no máximo, associa alguma informação temporal 
a alguns atributos, sob forma de datas. Não existem mecanismos para a 
manipulação de versões antigas dos dados geográficos. Entretanto, a 
identificação da necessidade de representação de aspectos temporais em 
aplicações de SIGs têm originado diversas pesquisas de implementação de 
SIGs temporais, procurando representar os requisitos temporais 
específicos desta área, além de definir operações de recuperação de 
informações temporais, e de manipulação de versões. Em alguns modelos 
para SIGs já aparece alguma representação temporal: 
· o modelo GeoOOA [Kosters 97] diferencia classes temporais de não-
temporais. Classes temporais armazenam as informações temporais 
relativas à evolução do objeto como um todo (tempo de criação e de 
término de sua existência) em um atributo especial; 
· projeto “TEMPEST” [Peuquet 95] da Universidade de Pensylvania, USA; 
· na modelagem do estudo de caso apresentado em [Garaffa 98], 
integrado no programa Pró-Guaíba da Secretaria de Coordenação e 
Planejamento do Estado do Rio Grande do Sul, foi incluída alguma 
representação temporal. Na modelagem foi utilizado um modelo 
orientado a objetos, proposto em [Lisboa 96], sendo este estendido com 
alguns aspectos temporais. A temporização é feita à nível de 
propriedades, através da utilização de domínios temporais. São 
identificadas as classes que apresentam atributos cujos valore s devem 
ser armazenados; 
· alguns trabalhos acadêmicas estão em desenvolvimento, como por 
exemplo, a implementação de um banco de dados espaço-temporal 
para aplicações de SIGs, usando o SGBDOO O2 [Faria 98]. 
8.2 Aplicações Médicas 
O registro do histórico de paci entes é fundamental para os diagnósticos. 
Nestes registros geralmente constam informações relativas a 
medicamentos utilizados (quando e durante quanto tempo), seus efeitos, 
sintomas apresentados e diagnósticos efetuados (quando), duração de 
enfermidades e resultados de exames realizados (quando). A análise destas 
informações pode ser utilizada para diversas finalidades: 
· pelo médico pessoal do paciente, como apoio a novos diagnósticos; 
· pelo sistema de saúde, para análises epidemiológicas, procurando em 
um conjunto significativo de pacientes encontrar os mesmos sintomas 
e os mesmos diagnósticos em determinados períodos; 
· por pesquisadores, analisando também conjuntos de registros de 
pacientes, procurando verificar, por exemplo, quais os medicamentos 
mais eficazes para um determinado diagnóstico, em relação ao tempo 
de cura. 
Os projetistas de sistemas de informação médica perceberam, há longo 
tempo, a necessidade de armazenar e manipular as informações 
relacionadas com o tempo. Um dos primeiros sistemas a atender esta 
necessidade foi Time Oriented Database: TOD desenvolvido por Wiederhold 
e outros em Stanford [Wiederhold 75, Edelweiss 94]. No sistema TOD as 
informações clínicas relativas a consultas são organizadas de forma 
cronológica, sendo preenchido um formulário para cada visita realizada 
pelo paciente. 
8.3 Bancos de Dados Multimídia 
Os objetos constituintes de Bancos de Dados Multimídia apresentam 
claramente um dimensão temporal, que se refere à ordem de apresentação 
dos objetos. Isto pode ser observado em situações como as que seguem: 
· o objeto X deve ser apresentado antes do objeto Y; 
· o objeto X deve ser apresentado simultaneamente ao objeto Y – por ex., 
apresentação de uma imagem e de voz ao mesmo tempo; 
Como pode ser observado nos exemplos acima, nestes tipos de aplicação o 
tempo é relativo, não absoluto. Além disso, muitas vezes temos um 
relacionamento forte entre o tempo e o espaço a ser utilizado pelo objeto 
em sua apresentação. Exemplo: “Encontre todas as seqüências de vídeos 
nas quais um automóvel, após virar à esquerda, vira para a direita”. Neste 
exemplo, existe uma combinação de inferência espacial (fazer curva) e 
temporal (primeiro à esquerda, depois à direita). 
A utilização de linguagens temporais de manipulação e de consulta neste 
tipo de aplicações, permite: 
· fazer consultas temporais a estes bancos de dados; 
· construir apresentações multimídia. 
Bancos de dados de áudio e de vídeo são um exemplo claro da 
necessidade de representar aspectos temporais neste tipo de aplicações 
[Hjelsvold 95]. Um banco de dados de vídeo pode ser visto como uma 
coleção de conjuntos parcialmente ordenados, na qual existem 
relacionamentos temporais entre os elementos de uma mesma seqüência 
de imagens e de sons. 
8.4 Modelagem de Workflow 
Um workflow (fluxo de trabalho) é geralmente definido como uma 
seqüência de tarefas (processos) a serem executados por sistemas 
automatizados ou por pessoas, com o objetivo de realizar um processo de 
negócio [Georgakoupoulos 95, Joosten 94]. Workflows estão sendo 
utilizados em diversas áreas de negócios, tais como aplicações bancárias, 
médicas e de comércio eletrônico. Um dos maiores problemas detectados 
na gerência de workflow é o controle dos problemas decorrentes da 
coordenação das atividades. Mesmo nos processos administrativos mais 
comuns não é possível controlar todas as atividades envolvidas – além da 
complexidade natural dos processos desenvolvidos, existe um grande 
volume de informações manipuladas por diversas pessoas. A necessidade 
de desenvolver sistemas que gerenciem o workflow com efici ência levou ao 
desenvolvimento de técnicas de modelagem específicas para estas 
aplicações. A representação de todos os processos que compõem uma 
aplicação, através de um modelo, tem por objetivo permitir o entendimento 
do conjunto de processos e da seqüência de sua execução. Desta análise 
pode resultar uma eventual reengenharia dos processos envolvidos, com o 
objetivo de sanar erros detectados e de obter uma melhor distribuição do 
trabalho. O modelo obtido servirá como base, mais tarde, para o processo 
de gerência deste workflow. 
No modelo de um workflow deverão ser representados, além dos 
processos, das atividades de que os processos são compostos, dos agentes 
responsáveis por cada atividade, as restrições temporais à execução de 
cada uma das atividades. Estas restrições temporais é que definem a 
seqüência válida de atividades serem executadas, e o seu sincronismo 
entre atividades. A possibilidade de representar informações temporais em 
um modelo de workflow é de fundamental importância, para possibilitar a 
representação deste sincronismo. Diferentes técnicas têm sido propostas 
para modelagem de workflow. Não se tratam, entretanto, de modelos 
temporais – os aspectos de tempo necessários
à representação do 
sincronismo entre atividades devem ser definidos explicitamente. Em 
[Nicolao 98] existe uma proposta de utilização do modelo temporal TF-ORM 
neste tipo de modelagem. O sincronismo entre as atividades (papéis de 
classes processo) é representado através das regras de transição de estado, 
condicionadas pelas condições expressas em lógica temporal. 
9 Conclusões 
Analisando as pesquisas realizadas na área de BD temporais, os estágios a 
seguir podem ser identificados [Jensen 97]: 
(1) desenvolvimento de conceitos – 1956 a 1985 
¨ análise dos diferentes tipos de tempo (transação e validade) 
¨ desenvolvimento de modelos conceituais temporais 
(2) linguagens de consulta temporais – 1978 a 1994 
¨ Relacional – 1978 a 1990 
¨ OO – 1990 a 1994 
(3) implementação – 1988 em diante 
¨ estruturas de armazenamento 
¨ algoritmos de operação 
¨ indexação temporal 
(4) consolidação – 1993 em diante 
¨ terminologia [Jensen 94] 
¨ TSQL2, SQL/Temporal no SQL3 
Existe, ainda, muito a ser feito nesta área. Principalmente na parte de 
implementação de BD temporais, e nas pesquisas em áreas que 
necessitam dos conceitos de tempo, tais como SIGs, Data Warehousing, 
Sistemas de Suporte à Decisão, mineração de dados, etc. 
Neste texto procuramos trazer os principais conceitos envolvidos na 
área de Bancos de Dados Temporais, desde os conceitos teóricos, 
nomenclatura empregada, possibilidade de evolução dos esquemas e como 
pode ser tratada, até chegar a formas de implementação, e analisar 
algumas aplicações que podem ser beneficiadas deste tipo de 
armazenamento de dados. É um texto básico, podendo mais detalhes ser 
encontrados nas referências bibliográficas indicadas. 
Referências Bibliográficas 
[Antunes 97] ANTUNES, D.C. Modelagem temporal de sistemas: uma abordagem 
fundamentada em redes de Petri. Porto Alegre: CPGCC da UFRGS, 1997. 
Dissertação de Mestrado. 
[Ariav 91] ARIAV, G. Temporally oriented data definitions: managing schema 
evolution in temporally oriented databases. Data & Knowledge Engineering , v.6, 
p.451-467, 1991. 
[Bolour 82] BOLOUR, A. et al. The Role of time in information processing: A 
survey. SigArt Newletter, v.80, p.28-48, Apr. 1982. 
[Câmara 96] CÂMARA, G.; CASANOVA, M.A.; HEMERLEY, A.S.; MAGALHÃES, 
G.C.; MEDEIROS, C.M.B. Anatomia de Sistemas de Informação Informação 
Geográfica. Campinas: Instituto de Computação, UNICAMP, 1996. (10a Escola 
de Computação). 
[Carvalho 97] CARVALHO, T.P. de; EDELWEISS, N. A Visual query system 
implementing a temporal object-oriented model with roles on a relational 
database. Proceedings of the 17th International Conference on the Chilean 
Computer Science Society, , Valparaiso, Chile, Nov. 10-15, 1997. p. 38-47. 
[Cheng 93] CHENG, T.S.; GADIA, S.K. An Object-oriented model for temporal 
databases. Proceedings of the International Workshop on an Infrastructure for 
Temporal Databases, June 14-16, Arlington, Texas, 1993. 
[Clifford 87] CLIFFORD J.; CROCKER, A. The Historical relational data model 
(HRDM) and algebra based on lifespans. Proceedings of the 3rd International 
Conference on Data Engineering, Los Angeles, California, 1987. p.528-537. 
[Clifford 93] CLIFFORD J.; CROCKER, A. The Historical relational data model 
(HRDM) revisited. In: A.U. TANSEL et al. (eds.) Temporal Databases: Theory, 
Design, and Implementation. Redwood City, California: Benjamin/Cummings, 
1993. p.6-27. 
[Clifford 95] CLIFFORD, J.; TUZHILIN, ª (Eds.) Recent Trends in Temporal 
Databases. Great Britain: Springer, 1995. 360p. 
[DeCastro 95] DE CASTRO, C.; GRANDI, F.; SCALAS, M.R. On Schema versioning 
in temporal databases. Recent Advances in Temporal Databases , J. Clifford, A. 
Tuzhilian (Eds.), Springer Verlag, 1995, p.272-291. 
[DeCastro 97] DE CASTRO, C.D.; GRANDI, F.; SCALAS, M.R. Schema Versioning 
For Multitemporal Relational Databases. Information Systems , v.22, n.5, 1997, 
p.249-290. 
[Edelweiss 93] EDELWEISS, N; Oliveira, J.P.M. de; Pernici, B. An Object -Oriented 
Temporal Model. Proceedings if the 5th International Conference on Advanced 
Information Systems Engineering - CAISE'93, Paris, France, June 8-11, 1993. 
p.397-415. (Lecture Notes in Computer Science 685). 
[Edelweiss 94] EDELWEISS, N.; OLIVEIRA, J.P.M. Modelagem de aspectos 
temporais de sistemas de informação. Recife: Universidade Federal de 
Pernambuco, 1994. (9a Escola de Computação). 
[Edelweiss 94a] EDELWEISS, N.; OLIVEIRA, J.P.M.; PERNICI, B. An Object-
oriented approach to a temporal query language. Proceedings of the 5th 
Database and Expert Systems Applications Conference - DEXA'94, Athens, 
Greece, Sept. 7-9, 1994. pp.225-235. (Lecture Notes in Computer Science 856). 
[Edelweiss 95] EDELWEISS, N.; OLIVEIRA, J.P.M.; CASTILHO, J.M.V. Evolução de 
Esquemas em Bancos de Dados Temporais. Anais do XXII Simpósio Brasileiro 
de Software e Hardware (XXII SEMISH), XXI Conferencia Latinoamericana de 
Informatica (PANEL’95), Canela, RS, 31 jul - 4 ago, 1995. p.375-386. 
[Edelweiss 97] EDELWEISS, N.; OLIVEIRA, J.P.M. de; KUNDE, G. Evolução de 
Esquemas Conceituais: o Conceito de Papel. Anais da XXIII Conferencia 
Latinoamericana de Informatica - PANEL’97, Valparaiso, Chile, 10 a 13 de 
novembro, 1997. p. 1-12. 
[Elmasri 93] ELMASRI, R.; WUU, G.T. J.; KOURAMAJIAN, V. A temporal model 
and query language for EER Databases. In: TANSEL, A. et al. (Eds.). Temporal 
databases: theory, design and implementation. Redwood City: The 
Benjamin/Cummings Publishing, 1993. p. 212-229. 
[Faria 98] FARIA, G. Um Banco de Dados Espaço-Temporal para Desenvolvimento 
de Aplicações em Sistemas de Informação Geográfica. Universidade Estadual de 
Campinas, 1998. (Dissertação de mestrado). 
[Garaffa 98] GARAFFA, I.M. Análise da Adequação de uma Hierarquia de Classes 
básicas para Modelagem Conceitual de SIG, através de um Estudo de Caso. 
Dissertação de mestrado a ser apresentada ao CPGCC/UFRGS. 
[Georgakoupoulos 95] GEORGAKOUPOULOS, D.; HORNICK, M.; SHETH, A. An 
Overview of Workflow Management: from process modeling to workflow 
automation infrastructure. ACM Distributed and Parallel Databases, n.3, p.119-
153, Sept. 1995. 
[Goralwalla 97] GORALWALLA, I.A.; SZAFRON, D.; ÖZSU, M.T.; PETERS, R.J. 
Managing Schema Evolution using a Temporal Object Model. To appear in the 
Proceedings of the 16th International Conference on Conceptual Modeling 
(ER’98), Nov. 1997. 
[Hjelsvold 95] HJELSVOLD, R.; MIDTSTRAUM, R.; SANDSTA, O. A Temporal 
foundation of video databases. In: CLIFFORD, J.; TUZHILIN, A. (Eds.) Recent 
Trends in Temporal Databases. Great Britain: Springer, 1995. p.295-314. 
[Jensen 94] JENSEN, C.S. et al. A Consensus glossary of Temporal Database 
Concepts. SIGMOD Record, v.23, n.1, p.53-63, Mar. 1994. 
[Jensen 97] JENSEN, C.S. Tutorial on Temporal Databases. SBBD´97, Fortaleza, 
CE, 1997. 
[Joosten 94] JOOSTEN, M.; STEF, M. Trigger Modelling for Workflow Analysis. 
Design Methodology Group, Center for Telematics and Information Technology, 
University or Twente, P.O. Box 217, 7500 AE Enschede, the Netherlands. 
[Kim 95] KIM, W.S.; CHANG, C.C.; LIM, T.Y.; SHIN, Y.H. Temporal object-oriented 
data model for the schema modification. Proceedings of the 4th International 
Conference on Database Systems for Advanced Applications, Singapore, April 
10-13, 1995. 
[Kline 93] KLINE, N. An Update on the temporal database bibliography. ACM 
SIGMOD Record, v.22, n.4, p.66-80, Dec 1993. 
[Kosters 97] KOSTERS, B.; PAGEL, B.; SIX, H. GIS-application development with 
GeoOOA. International Journal of Geographical Information Systems , v.11, n.4, 
p.307-335, 1997. 
[Kouramajian 95] KOURAMAJIAN, V.; GERTZ, M.; A graphical query language for 
temporal databases. Proceedings of the OOER´95 - Object-Oriented and Entity-
Relantionship Modeling. Berlin, 1995.
[Lisboa 96] LISBOA, F.J.; IOCHPE, C. Adaptando o modelo de dados OMT para 
modelagem conceitual de aplicações de SIG. Anais da 1a SEGEO – Semana 
Estadual de Geoprocessamento do Estado do Rio Grande de Janeiro. Rio de 
Janeiro: Escola de Engenharia, 1996. 
[Lisboa 97] LISBOA, F.J. Modelos Conceituais de Dados para Sistemas de 
Informação Geográficas . Porto Alegre: CPGCC da UFRGS, 1997. 119p. EQ-12. 
[Lorentzos 93] LORENTZOS, N.A. The Interval-extended Relational Model and its 
applications to valid-time databases. In: A.U. TANSEL et al. (eds.) Temporal 
Databases: Theory, Design, and Implementation. Redwood City, California: 
Benjamin/Cummings, 1993. p.67-91. 
[Loucopoulos 91] LOUCOPOULOS, P.; THEODOULIDIS, C.; WANGLER, B. The 
entity relationship time model and conceptual rule language. Proceedings of 
the 10th Int. Conf. on the Entity-Relationship Approach, San Mateo, California, 
1991. 
[McKenzie 86] McKENZIE, M. Bibliography: Temporal databases. ACM SIGMOD 
Record, v.15, n.4, p.40-52, Dec. 1986. 
[McKenzie 90] MCKENZIE, E.; SNODGRASS, R. Schema evolution and the 
relational algebra. Information Systems , v.15, n.2, p.207-232, 1990. 
[Moreira 97] MOREIRA, V.P. Evolução de Esquemas em Bancos de Dados 
Temporais. Porto Alegre: CPGCC da UFRGS, 1997. (Trabalho Individual 662). 
[Navathe 88] NAVATHE, S.B.; AHMED, R. TSQL: A Language interface for history 
databases. In: ROLLAND, C.; BODART, F.; LEONARD, M. (Eds.) Temporal 
Aspects in Information Systems . Amsterdam: North-Holland, 1988. p.109-122. 
[Navathe 93] NAVATHE, S.B.; AHMED, R. Temporal extensions to the relational 
Model and SQL. In: A.U. TANSEL et al. (eds.) Temporal Databases: Theory, 
Design, and Implementation. Redwood City, California: Benjamin/Cummings, 
1993. p.92-109. 
[Nicolao 98] NICOLAO, M.; EDELWEISS, N. Workflow Modelling using a Temporal 
Object-Oriented Model. Proceedings of the EDBT Workshop on Workflow 
Management Systems, March 27-28, 1998, Valencia, Spain. O. Bukhres, J. 
Eder, S. Salza (Eds.) p. 71-79. 
[Oberweis 94] OBERWEIS, A.; SÄNGER, V. GTL - A graphical language for 
temporal data. Proceedings of the 7th International Working Conference on 
Scientific and Statistical Database Management. IEEE Computer Press, 1994. 
[Oliveira 95] OLIVEIRA, J.P.M., EDELWEISS, N., ARRUDA, E., LAENDER, A.H.F., 
CAVALCANTI, J.M.B. Implementation of an Object-Oriented Temporal Model. 
Proceedings of the International Workshop and Conference on Database and 
Expert Systems Applications - DEXA’95, London, U.K., September 1995. 
[Overmeyer 82] OVERMEYER, R.; STONEBRAKER, M. Implementation of a Time 
Expert in a Data Base System. ACM SIGMOD Record, v. 11, n. 3, p. 51, Apr 82. 
[Özsoyoglu 95] ÖZSOYOGLU, G.; SNODGRASS, R. T. Temporal and real-time 
databases: a survey. IEEE Transactions on Knowledge and Data Engineering, 
New York, v.7, n.4, p.513-532, Aug. 1995. 
[Özsu 95] ÖZSU, M.T. et al. TIGUCAT: A Uniform Behavioral Objectbase 
Management System. The VLDB Journal , v.4, p.100-147, Aug. 1995. 
[Peuquet 95] PEUQUET, D.J. An Event-based spatiotemporal data model (ESTDM) 
for temporal analysis of geographical data. International Journal of Geographical 
Information Systems , v.9, n.4, 1995. 
[Roddick 92] RODDICK, J.F.; PATRICK, J.D. Temporal semantics in information 
systems - a survey. Information Systems , v.17, n.3, p.249-267. 
[Roddick 94] RODDICK, J.F. A Modelfor Temporal Inductive Inference and Schema 
Evolution in Relational Database Systems . La Trobe University, Department of 
Computer Science and Computer Engineering, 1994. Ph.D. Thesis. 
[Snodgrass 85] SNODGRASS, R.; AHN, I. A Taxonomy of time in databases. 
Proceedings of the ACM SIGMOD International Conference on Management of 
Data, Texas, May 28-31, 1985. p.236-46. 
[Snodgrass 95] SNODGRASS, R. The TSQL2 Temporal Query Language, Kluwer 
Academic Publishers Northwell, MA, 1995. 
[Soo 91] SOO, M.D. Bibliography on temporal databases. ACM SIGMOD Record, 
v.20, n.1, p.14-23, Mar. 1991. 
[Stam 88] STAM, R.; SNODGRSS, R.T. Bibliography on temporal databases. IEEE 
Database Eng., v.7, n.4, p.231-239, Dec. 1988. 
[Su 91] SU, S.Y.W.; CHEN, H.-H. M. A Temporal knowledge representation model 
OSAM*/T and its query language OQL/T. Proceedings of the 17 th International 
Conference on Very Large Data Bases, Barcelona, Spain, 1991. p.431-442. 
[Tansel 93] TANSEL, A.U. et al. (eds.) Temporal Databases: Theory, Design, and 
Implementation. Redwood City, California: Benjamin/Cummings, 1993. 
[Tauzovich 91] TAUZOVICH, B. Towards temporal extensions to the entity-
relationship model. Proceedings of the 10th Int. Conf. on the Entity-Relationship 
Approach, San Mateo, California, 1991. 
[Tsotras 96] TSOTRAS, V.J.; KUMAR, A. Temporal database bibliography update. 
ACM SIGMOD Record, v.25, n.1, p.41-51, Mar. 1996. 
[Wiederhold 75] WIEDERHOLD, G. et al. Structured Organization of Clinical 
Database. Proceedings of the AFIPS National Conference, Anhein, U.S.A., 1975. 
[Wuda 92] WUDA, G.; DAYAL, U. A Uniform model for temporal object-oriented 
databases. Proceedings of the 8th IEEE Data Engineering Conference, 1992. 
[Wu 97] WU, Y.; JOJODIA, S.; WANG, X.S. Temporal Database Bibliography 
Update. http://isse.gmu.edu/~csis/tdb/bib97/bib97.html. 
[Wuu 93] WUU, G.T.J.; DAYAL, U. A Uniform model for temporal and versioned 
object-oriented databases. In: A.U. TANSEL et al. (eds.) Temporal Databases: 
Theory, Design, and Implementation. Redwood City, California: 
Benjamin/Cummings, 1993. p.230-247. 
[Zaniolo 97] ZANIOLO, C.; CERI, S.; FALOUTSOS, C.; SNODGRASS, R.T.; 
SUBRAHMANIAN, V.S.; ZICARI, R. Advanced Database Systems . San 
Francisco, CA: Morgan Kaufmann Publishers, 1997. 574p. 
[Zicari 91] ZICARI, R. A Framework for schema updates in an object-oriented 
database system. 7th Data Engineering, Kobe, Japan, April 8-12, 1991. p.2-12.