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

Transcrição

1 1 Implementação de Aspectos Temporais em Bancos de Dados Convencionais Juliana de Morais Posser 1, Giliane Bernardi 2 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 Caixa Postal: Centro Universitário Franciscano - UNIFRA Rua dos Andradas, 1614 Bairro Centro Santa Maria RS Brasil CEP: 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 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 3 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. FUNCIONÁRIO Tr FUNÇÃO Pe Entidade Transitória T Lotação Entidade Perene Preferência Relacionamento Temporal Relacionamento Intemporal 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.

4 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 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 5 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. DOCENTE Docente (1,1) Possui (1, N) Admissao RegTrabalho Tr (1,1) Tem (1, N) (1, 1) (1, N) Contém Progressao 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 Intemporal Identificador: CodDocente Entidade Docente (CodDocente e mais todos atributos intemporais da tabela acima); Identificador: CodDocente Entidade Admissao (CodAdmissao, DataAdmissao, InicioTrans, DataExoneracao, FimTrans); Identificador: CodAdmissao Entidade Progressao (CodProgressao, Classe, Nivel, DataInicio, InicioTrans, DataFim, FimTrans); Identificador: CodProgressao Entidade RegTrabalho (CodRegTrab, RegTrab, DataInicio, InicioTrans, DataFim, FimTrans); Identificador: CodRegTrab FIGURA 2 Mapeamento de uma Entidade Transitória para o Modelo ER Convencional 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

6 6 [HÜB, 1999a]. Entidade Docente (tabela base) CodDocente Nome Sexo EstCivil NumMatricula DataNasc... (demais) 01 José Masculino Solteiro /08/ Ana Feminino Casada /12/ Entidade Admissão CodDocente CodAdmissao DataAdmissao InicioTrans DataExoneracao FimTrans /03/ /03/2000 null null /08/ /08/1997 null null Entidade RegTrabalho CodAdmissao CodRegTrab RegTrab DataInicio InicioTrans DataFim FimTrans Parcial 01/03/ /03/ /05/ /05/ Integral 18/05/ /05/2002 null null 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). 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 Docente (tabela base) CodDocente Nome Sexo EstCivil NumMatricula DataNasc... (demais) 01 José Masculino Solteiro /08/ Ana Feminino Casada /12/ Entidade Admissão CodDocente CodAdmissao DataAdmissao InicioTrans DataExoneracao FimTrans /03/ /03/2000 null null /08/ /08/1997 null null Entidade Progressão 25/06/ /06/2002 CodAdmissao CodProgressao Classe Nível DataInicio InicioTrans DataFim FimTrans Assistente 1 01/03/ /03/ /03/ /03/ Assistente 2 01/03/ /03/2002 null null Entidade RegTrabalho 25/06/ /06/2002 CodAdmissao CodRegTrab RegTrab DataInicio InicioTrans DataFim FimTrans Parcial 01/03/ /03/ /05/ /05/ Integral 18/05/ /05/2002 null null 25/06/ /06/2002 FIGURA 4 Exoneração do Docente José Entretanto, ainda se pode validar uma informação que foi excluída. Como por

7 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 Docente (tabela base) CodDocente Nome Sexo EstCivil NumMatricula DataNasc... (demais) 01 José Masculino Solteiro /08/ Ana Feminino Casada /12/ Entidade Admiss o CodDocente CodAdmissao DataAdmissao InicioTrans DataExoneracao FimTrans /03/ /03/ /06/ /06/ /08/ /08/1997 null null /08/ /08/2002 null null Entidade Progress o CodAdmissao CodProgressao Classe Nível DataInicio InicioTrans DataFim FimTrans Assistente 1 01/03/ /03/ /03/ /03/ Assistente 2 01/03/ /03/ /06/ /06/ Assistente 1 01/08/ /08/2002 null null Entidade RegTrabalho CodAdmissao CodRegTrab RegTrab DataInicio InicioTrans DataFim FimTrans Parcial 01/03/ /03/ /05/ /05/ Integral 18/05/ /05/ /06/ /06/ Horista 01/08/ /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 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 [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 [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 [POS, 2001], POSSER, Juliana de Morais; BERNARDI, Giliane. Temporalidade em Sistemas de Informação. Disponibilidade em: Projetos/ BDTemporais.html