|
"
What, then is time? If tio one asks me, I know; but if I want to explain
it to a questioner, I don't know"
Augustine of Hippo
(Confessiones XI, XIV).[1]
Muitos sistemas necessitam vincular as informações processadas à dimensão
temporal. A evolução da tecnologia, possibilitando altas capacidades de
armazenamento e desempenhos cada vez melhores no acesso aos dados, tem
permitido aos desenvolvedores de sistemas maior liberdade no projeto de
aplicações que guardam e manipulam dados históricos. Entretanto, ao introduzir
o tempo como um componente do domínio do problema, algumas questões importantes
surgem e merecem atenção. Neste artigo procurar-se-á mostrar, de maneira
informal, algumas delas.
Por que preocupar-se com a dimensão temporal?
Alguns dos motivos que levam os analistas de sistemas a preocupar-se com
a dimensão do tempo são as seguintes:
- A necessidade de se armazenar informações "vencidas" mas sobre
as quais deseja-se fazer inferências ou precisa-se ter acesso por força
de lei.
Exemplo:
O Banco Central quer ter acesso às informações relativas aos lançamentos
que ocorreram entre janeiro/93 e julho/94 nas contas ativas e encerradas,
de determinadas pessoas físicas e jurídicas para efeito de fiscalização.
Em muitos casos estas informações "vencidas" são excluídas dos
bancos de dados. No entanto, mantê-las arquivadas pode ser vital para
se conhecer o comportamento histórico de uma organização. Cada vez mais
os desenvolvedores de sistemas de informação de grande porte têm sido
levados a se preocupar com o armazenamento de dados históricos de forma
a apoiar os processos operacionais e gerenciais que ocorrem dentro das
organizações. Permitir que se façam pesquisas sobre o passado e se efetuem
comparações entre o passado e o presente é um excelente meio para se planejar
ações futuras. Uma outra forte motivação para o armazenamento de informações
"vencidas" é a necessidade de atender determinações legais,
tributárias ou jurídicas.
- A necessidade de se conhecer os diversos estados por que passaram determinados
objetos armazenados em um banco de dados, bem como a evolução dos relacionamentos
entre estes objetos ao longo do tempo.
Exemplos:
Precisa-se saber quais técnicos operaram o equipamento de raio-X
E32-1, por mais de 2 dias consecutivos, ou 4 dias não consecutivos, entre
as duas manutenções ocorridas em março e abril deste ano.
Precisa-se selecionar 5 programadores (entre 300) que tenham nos últimos
4 anos trabalhado no mínimo 10 meses com a linguagem C e no mínimo 6
meses em projetos de desenvolvimento de softwares do tipo "reactive
system".
Os elementos do tempo
Podemos abordar o tempo de forma discreta ou contínua. Em sistemas de
informação, tal qual nos negócios e afazeres do dia a dia, o senso comum
escolheu tratar o tempo como sendo um eixo de elementos discretos. O melhor
exemplo disto é o calendário, onde os elementos discretos são os dias.
Da mesma forma, quando dividimos o dia em horas, a hora em minutos e o
minuto em segundos, estamos modelando o tempo de forma discreta.
Ao modelarmos o tempo como um conjunto ordenado de elementos discretos
tornamos possível estabelecer intervalos de tempo associados a pontos
do tempo, ou seja, um intervalo de tempo possui dois pontos que o delimitam
(um inicial e um final) e entre eles um conjunto finito de pontos de tempo,
fazendo surgir a seguinte questão: os valores dos dados devem ser associados
com pontos isolados do tempo, ou com intervalos de tempo?
Na maioria dos casos vincular as informações a pontos específicos do tempo
tem satisfeito a necessidade dos sistemas de informação, entretanto, já
surgem propostas de incorporar o conceito do intervalo de tempo como sendo
uma primitiva mais poderosa no apoio a inferências sobre os bancos de
dados. Esta tendência é originada da área de inteligência artificial.
Como exemplo de utilização de pontos de tempo, analisemos o seguinte caso:
Em uma determinada empresa um empregado chamado Platão trabalhou em
dois departamentos: no departamento financeiro a partir de 10/02/94 e
no departamento de produção a partir de 15/07/94.
Ao modelarmos o relacionamento entre o empregado e os departamentos temos
o resultado mostrado na figura 1.

Figura 1
- Vinculando a informação a um ponto do tempo.
Como a informação está vinculada a apenas um determinado ponto no tempo,
presume-se que Platão trabalhou no departamento financeiro até o dia anterior
à sua transferência para o departamento de produção, isto é, determina-se
o fim de um período de tempo em função única e exclusivamente do início
do próximo período. Normalmente isto seria suficiente. Entretanto se incluíssemos
a seguinte complicação no caso acima descrito, teríamos que lançar mão
de um artifício de modelagem:
Platão, na verdade, ficou alocado ao departamento financeiro até o
dia 01/07/94. Do dia 02/07/94 até o dia 14/07/94 (dia anterior à sua transferência
ao departamento de produção) não ficou alocado a qualquer departamento
da empresa, ficou no "Iimbo" como se diz popularmente existindo
portanto um gap de tempo entre as duas lotações.
A figura 2 mostra como tratar o gap de tempo em que o empregado
Platão não ficou alocado a qualquer departamento da empresa.

Figura 2
- Introduzindo um artifício para modelar o gap de tempo
Como pode ser notado, foi incluída urna instância entre as duas que se
refere aos departamentos reais. Esta instância é um artifício, pois é
necessário simular a existência de um "departamento limbo" apenas
para acomodá-la no banco de dados. Tal providência não se justifica do
ponto de vista conceitual, entretanto muitas vezes o projetista é obrigado
a adotá-la em virtude de restrições de desempenho do sistema.
Uma forma de evitar o uso de artifícios desta natureza é utilizar como
primitiva de modelagem do tempo o conceito de intervalo de tempo, como
pode ser visto na figura 3. Um intervalo de tempo é um conjunto seqüencial
e consecutivo de pontos de tempo, identificado pelo seu ponto de início
e seu ponto de fim.

Figura 3
- Adotando intervalos de tempo para mapear as informações
Alguns intervalos podem apresentar apenas o seu ponto de início, pois
ainda continuam vigorando. Nestes casos é necessário utilizar uma constante
ou outra marca qualquer em lugar do seu ponto de fim, por exemplo a constante
"Em diante" da figura 3.
No momento que a informação está vinculada a um intervalo de tempo com
início e fim definido, fica dispensado o uso do "departamento limbo".
Entretanto é bom salientar que caso não haja gaps de tempo no
domínio do problema, o uso de intervalos de tempo provoca redundância
de informação, pois sempre será possível nestes casos deduzir o fim de
um período identificando o início do próximo.
A informação no tempo
A interação entre tempo e informação apresenta uma série de aspectos que
devem ser levados em conta pelo modelador:
Como o tempo e os valores de um atributo podem se relacionar:
de forma constante (sexo),
variando no tempo (salário),
valores que são o próprio tempo (data de nascimento).
Identificação de um objeto através do tempo
O identificador de um objeto deve permanecer com mesmo valor ao longo
do tempo. Os valores dos outros atributos, no entanto, podem variar.
"Nascimento" e "destruição" de objetos
Os objetos sob o ponto de vista de um sistema são criados (nascimento),
desenvolvem um ciclo de vida e podem desaparecer do domínio do sistema
(destruição). Muitas vezes é necessário manter registro das "reencarnações"
de um objeto. Por exemplo um empregado pode ser admitido, deixar a empresa
e depois ser readmitido. Duas alternativas são possíveis neste caso: ou
se cria um objeto novo, com um novo identificador, copiando todo o histórico
anterior para este objeto novo, ou se reabilita o identificador anterior
(reencarnação).
Eventos do mundo real
Em contraste com as propriedades que variam ao longo do tempo tais como
salário e endereço, uma outra forma em que o tempo interage com a informação
é através do registro de eventos que ocorrem no tempo real. Enquanto que
uma propriedade pode assumir diversos valores ao longo do tempo, um evento
deve ser considerado como um objeto que dura exatamente uma unidade de
tempo. A definição mais usada na área de sistemas de informação estabelece
que um evento é um acontecimento instantâneo de interesse ao empreendimento
em que vai estar inserido o sistema.
Evolução dos esquemas ao longo do tempo
Quando se considera como fazendo parte de um sistema de informações, além
dos dados propriamente ditos, os metadados (os esquemas), passa
a ser importante preocupar-se com as modificações que estes sofrem ao
longo do tempo, tais como, aparecimento de novas entidades, aparecimento
de novos relacionamentos, modificação de relacionamentos, modificação
de cardinalidades, etc. Existe pouca pesquisa a respeito deste problema.
Tempo do evento e tempo da transação
Tempo do evento é o momento do tempo em que o fato torna-se válido no
mundo real e tempo da transação é o momento do tempo em que o fato é registrado
no banco de dados.
Tempo extrínseco
Reflete o fato de que todas as declarações estão embutidas em um contexto
temporal seja este contexto formalmente ou não preservado. Por exemplo:
se a declaração "João leciona no Instituto de Informática"
foi feita em junho de 1994. estamos associando extrinsecamente a esta
declaração o índice-de-tempo "jun/1994".
Tempo intrínseco
Neste caso o tempo faz parte do conteúdo da declaração. Por exemplo, mesmo
que a declaração "João leciona no Instituto de Informática em
junho de 1994" tenha sido feita em outubro de 1994, ela está
associada ao tempo intrínseco "jun/94".
Um caso bastante ilustrativo de ocorrência de tempo extrínseco e intrínseco,
bem como da defasagem que pode acontecer entre o momento do tempo do evento
e momento do tempo do registro da transação, acontece em sistemas de contas
a receber.
Como exemplo tomemos um lançamento de recebimento de prestação, cujo vencimento
tenha ocorrido num domingo, mas que o pagamento tenha sido feito na segunda-feira
(o que vale como pagamento em dia) e que o registro no banco de dados
tenha ocorrido na terça-feira.
No mínimo três datas estão associadas a este lançamento:
- a data do efetivo pagamento ou data de entrada do dinheiro no
caixa, que é a segunda-feira;
- a data assumida do pagamento que é a própria data do vencimento,
pois deve ser considerado como pagamento em dia;
- a data do registro no sistema de informação - terça-feira. Antes
desta data o sistema não tem conhecimento do pagamento.
Neste tipo de transação, a data do efetivo pagamento, que é a do momento
do evento (segunda-feira), deve vir intrinsecamente informada no lançamento.
A data assumida de pagamento é obtida através de uma regra embutida na
aplicação que diz que quando o pagamento de uma prestação vencida em domingos
e feriados for feito no primeiro dia útil subseqüente, o pagamento deve
ser assumido como pagamento em dia. A data do registro no banco de dados
é extrinsecamente obtida pelo sistema de um calendário interno do computador.
Conclusão
Alguns aspectos da dimensão temporal que influenciam os sistemas de informação
foram apresentados neste artigo. Muitos outros existem e merecem investigação.
Na literatura técnica já existe uma série de propostas de técnicas de
modelagem de informações incorporando a dimensão temporal, entre elas
o modelo ERT [2] e o modelo TF-ORM [3]. Trata-se de um assunto que cada
vez mais vai exigir um tratamento adequado na análise e projeto dos sistemas
de informação.
Referências
[1] LOUCOPOULOS, P.; THEODOULIDIS, C. The time dimension in conceptual
modelling. Information Systems, vol. 16, n. 3, 1991.
[2] LOUCOPOULOS, P.; THEODOULIDIS, C.; WANGLER, B. A conceptual modelling
formalism for temporal database aplications. Information Systems,
vol. 16, n. 4, 1991.
[3] EDELWEISS, Nina; OLIVEIRA, José Palazzo M. Modelagem de aspectos
temporais de sistemas de informação. IX Escola de Computação,
UFPE, Recife, 1994.
dante@celepar.gov.br

|