Implementação de Aspectos Temporais em Bancos de Dados Convencionais

(1)

Implementação de Aspectos Temporais em Bancos de Dados

Convencionais

Juliana de Morais Posser1, Giliane Bernardi2

1

Universidade Federal do Rio Grande do Sul – UFRGS - Instituto de Informática Av. Bento Gonçalves, 9500 – Bairro Agronomia – Porto Alegre – RS – Brasil

CEP 91501-970 – Caixa Postal: 15064 2

Centro Universitário Franciscano - UNIFRA

Rua dos Andradas, 1614 – Bairro Centro – Santa Maria – RS – Brasil CEP: 97.010-032

juposser@inf.ufrgs.br, giliane@unifra.br Abstract

The temporal databases were projected to handle relative information about the present, past and future through the association between information and time. Therefore, the time acts to present the information evolution. Despite the needs, the nowadays commercial databases do not support the entirely temporal aspects. However, these databases can be use to implement temporal aspects using a correct mapping between the temporal model and the conventional database. This paper presents an implementation of temporal information with a conventional database.

Resumo

Os bancos de dados temporais foram projetados para tratarem com as situações que envolvem informações referentes ao presente, passado e futuro, através da associação da informação com o tempo. Assim, o tempo age sobre os dados de maneira dinâmica, mostrando a evolução das informações. Apesar da necessidade, os bancos de dados comerciais atuais não suportam completamente os aspectos temporais. Logo, os mesmos podem ser utilizados para a implementação dos aspectos temporais se existir um correto mapeamento entre o modelo temporal e o banco de dados a ser utilizado. Este artigo apresenta a implementação de informações temporais utilizando um banco de dados convencional.

1 Introdução

Tradicionalmente, um banco de dados é implementado para guardar os dados mais recentes de uma organização bem como suas atividades. Porém, à medida que as modificações são efetuadas no banco de dados, as informações antigas são descartadas. Desta forma, os bancos de dados convencionais capturam somente a visão estática da realidade, não armazenando a visão dinâmica, ou seja, a maneira como evoluiu a informação, sua história [AMO, 1995].

Na tentativa de solucionar este problema, os bancos de dados temporais foram projetados para tratarem com as situações que envolvem informações referentes ao presente, passado e futuro. A idéia de tempo associada à informação vem sendo estudada por mais de 20 (vinte) anos, onde diversos conceitos foram desenvolvidos, vários modelos elaborados, porém, pouquíssimos sistemas foram implementados [EDE, 1994].

(2)

Enquanto os bancos de dados convencionais manipulam dados estáticos que apresentam somente as informações atuais, os bancos de dados temporais trabalham com as informações dinâmicas, nas quais são mantidos históricos para preservar os dados antigos. Conseqüentemente, o tempo é uma informação dinâmica e não estática, caracterizando um sistema de informação que irá possuir um banco de dados temporal e uma modelagem que retém informações com aspectos temporais.

Ainda, apesar da grande necessidade, os bancos de dados comerciais atuais não suportam completamente os aspectos temporais. Logo, a utilização de um modelo de dados temporal para especificação de uma determinada aplicação não implica, necessariamente, na utilização de um SGBD (Sistema de Gerenciamento de Banco de Dados) Temporal específico para a implementação do modelo. Assim, os bancos de dados comerciais tradicionais podem ser utilizados somente se existir um correto mapeamento entre o modelo temporal e o banco de dados a ser utilizado [HÜB, 1999b]. Sendo assim, este artigo apresenta a implementação de informações temporais utilizando um banco de dados convencional. Para validar a implementação, um estudo de caso foi desenvolvido, onde a modelagem do mesmo foi realizada utilizando o modelo temporal TempER.

2 Estudo de Caso

Para o desenvolvimento de uma modelagem temporal e de uma implementação temporal, fez-se necessário a definição de um estudo de caso. O mesmo foi desenvolvido no setor Assessoria da Reitoria, do Centro Universitário Franciscano (UNIFRA), órgão responsável por realizar o controle de todas as atividades desempenhadas por cada um dos docentes pertencentes à Instituição, bem como de manter atualizada a titulação dos mesmos. No caso das atividades, o controle é realizado por meio da carga horária semanal desenvolvida por cada docente, sendo que toda atividade possui uma equivalência em horas. Existe uma classificação para as atividades: docência e não-docência. As atividades de docência são aquelas relacionadas com o professor. As atividades de não-docência estão ligadas aos cargos administrativos exercidos pelos docentes dentro da Instituição. Ainda, as atividades são divididas de acordo com o tipo, que pode ser Ensino, Pesquisa, Extensão e Administração.

A titulação do docente é responsável por determinar a base de seu piso salarial, ou seja, o valor da hora trabalhada. Desta forma, a titulação possibilita enquadrar os docentes em uma classe/nível. Ainda, dentro da hierarquia institucional encontram-se progressões que permitem que o docente possa mudar de classe ou de nível. A descrição completa do estudo de caso pode ser encontrada em [POS, 2001].

3 Modelagem do Estudo de Caso

Através do estudo de caso foram desenvolvidos dois modelos: o ER convencional e o Modelo temporal, este utilizando a abordagem TempER, proposta por [ANT, 1997]. Primeiramente, foi elaborado o modelo ER convencional, pois, a partir deste, torna-se mais fácil a definição dos atributos e relacionamentos que serão temporalizados, bem como podem ser vistas quais as entidades que recebem a classificação transitória ou perene. Quando um modelo é definido através da abordagem ER convencional, a associação das entidades e relacionamentos com o tempo materializa-se através da inclusão de atributos comuns (datas, horas, etc.).

Assim, a vantagem de se utilizar um modelo de dados temporal, no lugar de um convencional, está na sua capacidade de expressar a associação dos elementos com o

(3)

Relacionamento Temporal Relacionamento Intemporal

tempo e também de especificar as restrições decorrentes da temporalidade. Os modelos desenvolvidos podem ser encontrados com maiores detalhes em [POS, 2001].

O modelo temporal TempER é do tipo Entidade-Relacionamento (ER), que permite referenciar os objetos à dimensão temporal. Desta forma, é possível representar o relacionamento entre as entidades temporalizadas e as não-temporalizadas. No caso das entidades temporalizadas, a validade temporal é o subconjunto de pontos do eixo temporal, sendo assim denominada de entidade transitória. Já com relação às entidades não-temporalizadas, admite-se que a sua existência ocorre durante todo o eixo temporal, ou seja, a validade temporal é constante. Deste modo, foram classificadas como

entidades perenes.

Tanto as entidades transitórias como as perenes apresentam duas perspectivas: temporal e intemporal. No enfoque da perspectiva intemporal, a qual não leva em consideração a dimensão temporal, as entidades possuem duas dimensões: tupla x atributos intemporais, ou seja, as entidades não apresentam associado a elas um conjunto de pontos do tempo. Na perspectiva temporal são identificadas três dimensões: tupla x atributos temporais x eixo temporal. Os relacionamentos ou as entidades associam-se entre si na perspectiva temporal – relacionamentos temporais; ou na perspectiva intemporal – relacionamentos intemporais.

Toda entidade, no TempER, é uma instância de um conjunto-entidade, assim como todo o relacionamento é uma instância de um conjunto-relacionamento. A Figura 1 refere-se à notação de conjuntos-entidade e conjuntos-relacionamento. Os atributos são propriedades das entidades e dos relacionamentos, os quais não são representados graficamente e sim, por meio de um dicionário de dados associado ao diagrama ER. No nível de modelagem, considera-se apenas um eixo temporal, o qual representa o tempo de validade, não sendo necessário especificar o tempo de transação, pois este se trata de um aspecto inerente à implementação física.

FIGURA 1 – Notação de conjuntos-entidade e conjuntos-relacionamento 4 Implementação do Banco de Dados Temporal

Pela importância dada ao aspecto temporal na maior parte das aplicações do mundo real, faz-se necessário estabelecer uma maneira de implementar banco de dados temporais. Uma alternativa para isto é realizar o mapeamento do modelo de dados temporal para um banco de dados comercial tradicional, onde todas as informações temporais, implícitas no modelo temporal, devem ser, explicitamente, representadas e manipuladas [HÜB, 1999a].

Assim como algumas informações não variam com a passagem do tempo (estáticas/atributos intemporais), outras mudam com o passar do tempo (dinâmicas/atributos temporais), portanto, há a necessidade de distingui-las, claramente, dentro da aplicação. Para os atributos temporais foram escolhidos os intervalos, como primitiva temporal, e os rótulos temporais estabelecidos foram o tempo de transação e o tempo de validade. Desta forma, tem-se um banco de dados bitemporal.

Entidade Transitória Entidade Perene

FUNCIONÁRIO Tr _FUNÇÃO Pe

T

Preferência Lotação

(4)

O banco de dados comercial escolhido para a implementação foi o Interbase 6, pois o permite o uso de gatilhos (triggers), os quais foram utilizados para controlar as restrições temporais e manter a integridade do banco de dados temporal.

4.1 Mapeamento do Modelo ER Temporal para um Banco de Dados Relacional

Depois de realizada a modelagem dos dados em um modelo temporal, deve-se mapear estes dados e todas as informações temporais implícitas no modelo temporal para um modelo ER convencional. A tabela escolhida para a implementação é a tabela DOCENTE, que é uma entidade transitória, ou seja, apresenta atributos temporais e atributos intemporais dentro de uma mesma entidade. A partir desta tabela pode-se perceber como se realiza a implementação tanto das informações estáticas (atributos intemporais), como das informações dinâmicas (atributos temporais).

Na realização do mapeamento cada entidade é representada por uma tabela base, onde são armazenados todos os atributos intemporais. Conseqüentemente, ocorre uma divisão da entidade transitória, onde todos os dados estáticos permanecem numa tabela base e cada dado dinâmico é armazenado numa tabela específica, para assim guardar a evolução da informação temporal. Pelo fato do atributo temporal ser flexível, faz-se necessário criar uma tabela para cada atributo dinâmico, associando a cada um dos valores destes atributos um intervalo de tempo de transação e um de tempo de validade. Cada tabela dinâmica apresentará, para cada uma de suas tuplas, um valor correspondente ao tipo de dado do atributo e quatro informações temporais: (i) início do tempo de validade; (ii) fim do tempo de validade; (iii) início do tempo de transação; e (iv) fim do tempo de transação.

Por intermédio da Figura 2, pode-se notar como foi realizado o mapeamento da entidade transitória (Docente), pertencente ao modelo TempER, para o modelo ER convencional, definindo, deste modo, a estrutura de armazenamento dos dados na aplicação.

4.1.1 Atualização e remoção em um banco de dados bitemporal

Diferentemente do banco de dados convencional, onde o usuário pode realizar as operações de atualização e remoção em qualquer tupla, desde que possua a devida permissão, o banco de dados que armazena a evolução das informações não apresenta tal facilidade. Isto, porque são utilizadas regras para controlar as atualizações e remoções, visando assegurar a consistência e a integridade das informações armazenadas.

No caso das atualizações, podem ser atualizadas as informações: (i) somente do futuro; (ii) do presente e do futuro; (iii) do passado, presente e futuro; e, (iv) passado e futuro. Para manter a real história das informações, optou-se, no estudo de caso, por realizar somente as atualizações referentes às informações presentes e futuras.

O fato de não se alterar as informações referentes ao passado, deve-se ao principal objetivo de um banco de dados temporal que é proporcionar a evolução das informações, mantendo um histórico de todas as informações armazenadas. Pois, quando se alterar o passado, altera-se a história da informação.

Deve-se ter um certo cuidado em relação às informações atualizadas no presente, pois está diretamente ligada à granularidade utilizada na implementação do banco de dados temporal [HÜB, 1999a]. Por exemplo, a granularidade considerada na aplicação é de 1 (um) dia, e pela manhã é realizada uma consulta no regime de trabalho do docente “José” e obtém-se o resultado “parcial” para este atributo. Logo em seguida, um usuário

(5)

Admissao

Progressao Docente

RegTrabalho

modifica para “integral” o regime de trabalho do “José”. À tarde é realizada novamente outra consulta, no mesmo atributo do docente “José”, que apresenta um novo resultado. Assim, pesquisas realizadas em diferentes momentos geraram duas histórias distintas, para um mesmo atributo no mesmo dia. Logo, o valor válido será sempre o último atualizado.

FIGURA 2 – Mapeamento de uma Entidade Transitória para o Modelo ERConvencional

Portanto, as alterações realizadas nas informações temporais devem procurar manter a consistência do banco de dados, por meio de algumas precauções, tais como: inserir uma nova tupla para armazenar as alterações, nas quais as datas de início de validade e início de transação deverão ser preenchidas com seus respectivos valores e, ainda, a tupla anterior deverá receber, para a data de fim de validade, o valor da data de início de validade da tupla alterada e para a data de fim de transação o valor da data do sistema.

Baseado no exemplo anterior a Figura 3 mostra como é realizada a alteração em um banco de dados temporal, para a entidade “RegTrabalho”.

A remoção não deveria ser permitida, mas pode ser um mecanismo importante quando se deseja excluir do banco de dados as informações muito antigas ou sem relevância, porém deve-se ressaltar que a remoção das informações altera a história [HÜB, 1999a].

A solução, para que não se perca a consistência das informações do banco de dados é fazer com que tuplas que iniciaram sua validade no passado e que são válidas no presente (aquelas que possuem o valor “null” para as datas de validade final e de transação final) sejam, teoricamente, removidas, encerrando-se a sua validade, onde o atributo “data de validade final” irá receber a data na qual a tupla deixará de valer e “data de transação final” a data do sistema no qual o encerramento da tupla foi realizado

Atributos:

CodDocente: Intemporal Nome: Intemporal Sexo: Intemporal EstCivil: Intemporal

DataAdmissao: Temporal RegimeTrab: Temporal

Classe: Temporal Nivel: Temporal

NumMatricula: Intemporal DataNasc: Intemporal Nacionalidade: Intemporal Naturalidade: Intemporal NumCPF: Intemporal NumCartTrab: Intemporal Serie: Intemporal NumRG: Intemporal Orgao: Intemporal DataEmissao: Intemporal Endereco: Intemporal Numero: Intemporal Complemento: Intemporal Bairro: Intemporal CEP: Intemporal Cidade: Intemporal Estado: Intemporal TelefoneConv: Intemporal TelefoneCel: Intemporal Email: Intemporal Identificador: CodDocente

Entidade Docente

Atributos:

(CodDocente e mais todos atributos intemporais da tabela acima); Identificador: CodDocente (1,1) (1, N) Possui Contém (1, 1) (1, N) (1,1) (1, N) Tem Entidade Progressao Atributos:

(CodProgressao, Classe, Nivel, DataInicio, InicioTrans, DataFim, FimTrans); Identificador: CodProgressao Entidade Admissao Atributos: (CodAdmissao, DataAdmissao, InicioTrans, DataExoneracao, FimTrans); Identificador: CodAdmissao Entidade RegTrabalho Atributos: (CodRegTrab, RegTrab, DataInicio, InicioTrans, DataFim, FimTrans); Identificador: CodRegTrab DOCENTE Tr

(6)

[HÜB, 1999a].

Entidade Docente (tabela base)

CodDocente Nome Sexo EstCivil NumMatricula DataNasc ... (demais)

01 José Masculino Solteiro 0546-2002 31/08/1975 ...

02 Ana Feminino Casada 0837-1999 12/12/1968 ...

Entidade Admissão

CodDocente CodAdmissao DataAdmissao InicioTrans DataExoneracao FimTrans

01 01 01/03/2000 05/03/2000 null null

02 02 01/08/1997 17/08/1997 null null

Entidade RegTrabalho

CodAdmissao CodRegTrab RegTrab DataInicio InicioTrans DataFim FimTrans

01 01 Parcial 01/03/2000 05/03/2000 18/05/2002 19/05/2002

01 02 Integral 18/05/2002 19/05/2002 null null

FIGURA 3 – Alteração do Regime de Trabalho do Docente “José”

Para realizar a exoneração de um docente, basta encontrar a tupla válida correspondente ao período de admissão, isto é, a tupla que contém as datas de exoneração e fim de transação nulas, e atribuir a estas os seus devidos valores, encerrando-se a sua validade. Porém, não se deve esquecer que como se trata de uma exoneração, no qual o docente deixa de existir para a Instituição as entidades

Progressão e RegTrabalho também sofrem alterações nas datas de validade final e

transação final, onde são encerradas assim como na entidade Admissão. A Figura 4 mostra como fica cada entidade para um docente que foi exonerado.

Entidade Admissão

01 01 01/03/2000 05/03/2000 null null

02 02 01/08/1997 17/08/1997 null null

Entidade Progressão

CodAdmissao CodProgressao Classe Nível DataInicio InicioTrans DataFim FimTrans

01 01 Assistente 1 01/03/2000 05/03/2000 01/03/2002 10/03/2002

01 02 Assistente 2 01/03/2002 10/03/2002 null null

01 01 Parcial 01/03/2000 05/03/2000 18/05/2002 19/05/2002

01 02 Integral 18/05/2002 19/05/2002 null null

FIGURA 4 – Exoneração do Docente “José”

Entretanto, ainda se pode validar uma informação que foi excluída. Como por

o valor válido para a informação corresponde a última alteração, ou seja, mantém-se a informação anterior, mas a tupla vigente é a última alterada (onde a datas de validade final e de transação final estão em aberto).

25/06/2002 30/06/2002

(7)

exemplo, readmitir um docente. Se a sua exclusão deu-se por intermédio de uma exoneração, para tornar a informação do docente válida novamente, deve-se readmitir o docente inserindo uma nova tupla em cada uma das tabelas que contêm os atributos temporais, especificando os inícios de validade e transação das tuplas.

Assim, a readmissão do docente é realizada após a verificação de todas as tuplas não-válidas pertencentes ao período de admissão do docente, ou seja, verificar se todas as tuplas de determinado docente foram exoneradas, e readmiti-lo, inserindo-se, nas tabelas Admissao, Progressao e RegTrabalho, novas tuplas. Especificando apenas a nova data de admissão. A Figura 5, refere-se a readmissão de um docente.

Entidade Admiss o

01 01 01/03/2000 05/03/2000 25/06/2002 30/06/2002

02 02 01/08/1997 17/08/1997 null null

01 03 01/08/2002 09/08/2002 null null

Entidade Progress o

CodAdmissao CodProgressao Classe Nível DataInicio InicioTrans DataFim FimTrans

01 01 Assistente 1 01/03/2000 05/03/2000 01/03/2002 10/03/2002 01 02 Assistente 2 01/03/2002 10/03/2002 25/06/2002 30/06/2002

03 03 Assistente 1 01/08/2002 09/08/2002 null null

01 01 Parcial 01/03/2000 05/03/2000 18/05/2002 19/05/2002 01 02 Integral 18/05/2002 19/05/2002 25/06/2002 30/06/2002

03 03 Horista 01/08/2002 09/08/2002 null null

FIGURA 5 – Readmissão do Docente “José”

Basicamente, o que a implementação faz é controlar a admissão, readmissão e exoneração do docente. Portanto, quando um docente é admitido uma nova tupla é criada nas tabelas Docente, Admissão, Progressão e RegTrabalho. Neste caso, os valores, data de início de validade e data de início de transação devem ser especificados nas tabelas Admissão (DataAdmissao e InicioTrans), Progressao (DataInicio e InicioTrans) e RegTrabalho (DataInicio e InicioTrans). Porém, para auxiliar o usuário de forma que este não precise informar 3 (três) datas de início de validade, as tabelas

Progressao e RegTrabalho recebem para a data de início de validade o próprio valor da

data de admissão do docente, ou seja, quando se insere um docente, a única data que precisa ser especificada é a de admissão.

Quanto à alteração, as únicas tabelas que sofrem realmente uma alteração temporal são a Progressao e RegTrabalho. Para a tabela Admissao, a alteração é efetuada por intermédio da exoneração e readmissão em conjunto. Já a tabela Docente sofre alterações não-históricas, que ocorrem de forma convencional, gravando a alteração por cima do último valor até então definido como válido. Assim, as principais

(8)

restrições para controlar a integridade de um banco de dados temporais localizam-se nas operações de atualização e remoção de informações.

5 Conclusões

Os bancos de dados atuais não possuem, na sua maioria, a capacidade de armazenar a história das informações, apenas armazenam os dados presentes. Por este motivo, os sistemas de informação temporais passaram a ser especialmente estudados, bem como os modelos e bancos de dados temporais. Assim, este artigo procurou expor os principais conceitos ligados à temporalidade e um estudo mais detalhado de como se realizar uma implementação de bancos de dados temporais, utilizando um SGBD convencional.

Pela implementação desenvolvida, foi possível verificar como funciona o desenvolvimento de um banco de dados bitemporal. Além disso, notou-se que o número de restrições é maior no sistema temporal do que em relação ao convencional.

Constatou-se também que a utilização de um banco de dados temporal não só será apropriada para a Instituição, como de grande importância, pois permitirá um maior controle das atividades exercidas pelos docentes por períodos de tempos contínuos, armazenando-se, desta forma, toda a carreira profissional do docente, tanto na UNIFRA como em outras Instituições.

Um problema que talvez poderá surgir com o tempo, caso seja implementado o modelo desenvolvido em sua totalidade, diz respeito ao fluxo de informações armazenadas no banco de dados. Considerando-se que o número de docentes da Instituição não é pequeno e que toda sua história profissional deverá ser armazenada no banco, um volume muito grande de informações poderá ser gerado.

Como trabalho futuro pretende-se implementar o restante do modelo proposto, de forma que possa ser implantado na instituição e possíveis testes possam ser realizados.

6 Referências Bibliográficas

[AMO,1995] AMO, Sandra A. Introdução aos bancos de dados temporais. In: XV Congresso da Sociedade Brasileira de Computação. Anais... Recife. p. 97.

[EDE, 1994] EDELWEISS, Nina.; OLIVEIRA, José Palazzo M. Modelagem de

aspectos temporais de sistemas de informação. Recife: IX Escola de Computação

– UFPE.

[ANT, 1997] ANTUNES, Dante C.; HEUSER, Carlos A.; EDELWEISS, N. TempER:

uma abordagem para modelagem temporal de banco de dados. Porto Alegre:

Instituto de Informática – UFRGS. Revista de Informática Teórica e Aplicada, v.4, n.1, p. 49-85.

[HÜB, 1999a] HÜBLER, Patrícia Nogueira. Implementação de um banco de dados

temporal utilizando um SGBD convencional. In: Conferencia Latinoamericana de

informática. Memorias. Assuncion: Universidad Autonoma de Asuncion. v.1, p. 99-110.

[HÜB, 1999b] HÜBLER, Patrícia Nogueira. Implementação de um sistema

gerenciador de banco de dados temporal para o modelo TF-ORM. In: Semana

Acadêmica do PPGC. Porto Alegre: PPGC. Anais... v.1, p. 55-58.

[POS, 2001], POSSER, Juliana de Morais; BERNARDI, Giliane. Temporalidade em

Sistemas de Informação. Disponibilidade em: http://cpd-srv03.unifra.br/~giliane/