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

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

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

4. ∀ 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):

5. • 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.
v v
t t
PONTO A PONTO EM ESCADA
v
chronon
t
DEFINIDA POR UMA FUNÇÃO
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

6. 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 é re presentado 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.

7. 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 e lemento
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 n ecessidade 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
interva los [1992, 1995] U [1997, »].

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

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

10. 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 800 01/jan/92
t2 900 01/jun/92
1000 01/jan/93
t3
tpresente Momento Atual
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.
(800, 01/jan/92) 03/jan/92
t1
(900, 01/jun/92) 25/mai/92
t2
(1000, 01/jan/93) 10/jan/93
t3
Momento Atual
tpresente
História do salário de João
Tempo
Figura 3.3: Banco de Dados de Tempo de Transação

11. 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.
800 01/jan/92
t1
t2 900 01/jun/92
1000 01/jan/93
t3
Momento Atual
tpresente
História do salário de João
Tempo
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.

12. 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.
01/jan/92 Tempo de Transação
800
800
03/jan/92
900
900 25/mai/92
01/jun/92 1000
1000
10/jan/93
01/jan/93
Momento
Atual
História das transações
do salário de João
História da validade
Tempo de Validade do salário de João
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 e m 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.

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

14. 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 conhe cidas. 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:

15. 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ór ia 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.

16. 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 listas ou conjuntos também podem
ão
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.

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

18. 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 represent adas; (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.

19. 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
e lementares 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 armazena das 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

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

21. 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.
TV TV
15 15
(João, compras) (João, compras )
10 10
5 5
0 0
0 5 10 15 20 25 30 0 5 10 15 20 25 30
TT TT
TV TV
15 15
(João, vendas)
(João, compras) (João, compras)
10 10
5 5
0 0
0 5 10 15 20 25 30 0 5 10 15 20 25 30
TT TT
Figura 5.1: Interpretação do elemento bitemporal

22. TV
20
15
10 Emp Dept Ts Te Vs Ve
5 João compras 5 9 10 15
0 João compras 10 14 5 20
0 5 10 15 20 25 TT
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 infor maçã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”

23. 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 exemp abaixo:
lo
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;

24. • 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);

25. • 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
Empregado Lotação Depto
( 1, N ) ( 0, N )
entidade EMPREGADO
relacionamento entidade DEPTO
atributos: atributos:
LOTAÇÃO
( cod: NATURAL ;
atributos: ( sigdep: STRING ;
nome: STRING ; nomdep: STRING ;
( datinicLot: DATE ;
sal: REALP;
datfimLot: DATE ) datCriação: DATE ;
datAdmissão: DATE ; datFecham: DATE )
datDemissão: DATE )
identificador: (sigdep)
identificador: (cod )
Modelo ER temporal - TempER
Tr T Tr
Empregado ( 1, 1 ) Lotação ( 0, N )
Depto
entidade EMPREGADO relacionamento entidade DEPTO
atributos: LOTAÇÃO atributos:
( cod: NATURAL, Intemporal; atributos: ( - ) ( sigdep: STRING, Intemporal;
nome: STRING, Intemporal; nomdep: STRING, Intemporal )
at-sal: REALP, Temporal ) identificador: (sigdep)
identificador: (cod )
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

26. 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.
Entidade Empregado Relacionamento Lotação
Existência OID cod nome at-sal Validade OID OID
Temporal EMPREGADO DEPTO
[ 3,10 ] U 1001 e1 Gadia 180 [ 3, 6 ]
[ 3, 10 ] U 1001 9011
[ 20, » ] 220 [ 7, 10] U [ 20, 25]
[ 20, 30 ]
250 [ 26, » ]
[ 31, » ] 1001 9013
[ 7, 35 ] 1002 e2 Segev 110 [ 7, 20]
180 [ 21, 35] [ 7, 20 ] 1002 9011
[ 2, 20 ] U 1003 e3 Clifford 200 [ 2, 20] U [ 30, 35] [ 21, 35 ] 1002 9014
[ 30, » ] 250 [ 36, » ]
[ 2, 10 ] U 1003 9011
[ 25, » ] 1004 e6 Snodgrass 100 [ 25, 30 ] [ 15, 18] U
130 [ 31, » ] [ 30, 35 ]
[ 5, 25 ] 1005 e8 Jajodia 100 [ 5, 25 ] [ 11,14 ] U 1003 9012
[ 19, 20 ]
[ 10, » ] 1006 e4 Tansel 170 [ 10, 20]
190 [ 21, » ]
[ 36, » ] 1003 9014
[ 25, » ] 1004 9014
Existência OID sigdep nomdep
[ 5, 15 ] 1005 9012
[ 1, » ] 9011 defin financeiro
Entidade
Depto [ 3, 20 ] 9012 desis sistemas [ 16, 25 ] 1005 9013
[ 10, » ] 9013 depro produção [ 10, 20 ] 1006 9012
[ 21, » ] 9014 deinf informática
[ 21, » ] 1006 9014
[ 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;

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

28. 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
pape l 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>]

29. 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 espe cificação: DATE (quando
solicitada uma data de validade), TRANSACTION_DATE (data de

30. 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]:

31. • 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 e squemas 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.

32. • 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 maiori a
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

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

34. 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” B conjunto de esquemas corretos
A C
seqüência de estados
do BD Temporal
*
a3 b1 c1
* * c3
a1
b2 b3
a4
a2 c2
conjunto de estados do BD conjunto de estados do BD
conjunto de estados do BD
válidos para o esquema inicial A válidos para o esquema B válidos para o esquema C
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

35. 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 (me ta-)
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 referenci ada 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 a daptar as estruturas e os valores armazenados

36. 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.
t1 t2 t3
Esquema
Extensão
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 a ssociada 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 ada ptaçõ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 , t 2 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

37. 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.
t1 t2 t3
Esquema
Extensão
transformação transformação transformação
de ocorrências de ocorrências de ocorrências
Figura 6.3: Esquema de tempo de tr ansaçã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 t . Em t3 é feita
1

38. outra alteração no esquema, também válida somente em t 4 . 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 t e t3 não
2
ficam armazenados - somente o tempo t4 é associado às alterações
definidas.
t1 t2 t3 t4
Esquema
Extensão
transformação transformação
de ocorrências de ocorrências
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 ve rsã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.

39. 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 ,…, a n |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),