Utilizando TimeDB na implementação de bancos de dados temporais Carlos Eduardo Santin 1, Willian Bruno Gomes Alves 1 1 Instituto de Informática Universidade Federal do Rio Grande do Sul (UFRGS) Caixa Postal 15.064 91.501-970 Porto Alegre RS Brazil {cesantin,wbgalves}@inf.ufrgs.br Abstract. Most of the current applications uses databases that just represent one state of the real world. However, more and more we noticed the need of work with information referring to several points in the time. For that, we needed to access databases that store data in its current state, as also in the past and in some cases in the future. For this objective appeared temporal databases. The temporal control of a database can be implemented directly in the application or really creating a new database or using a layer on an existent database that allows the translation of temporal operations for SQL default. In this last model is the TimeDB, a tool that makes possible the use of commercial databases as if they were temporal databases, however this tool still presents the lack of some resources. Resumo. A maioria das aplicações atuais utilizam bancos de dados que representam apenas um estado do mundo real. No entanto, cada vez mais notamos a necessidade de trabalharmos com informações referentes a diversos pontos no tempo. Para isso, necessitamos acessar bancos de dados que armazenem dados em seu estado atual, como também no passado e em alguns casos no futuro. Com este objetivo surgiram os bancos de dados temporais. O controle temporal de um banco de dados pode ser implementado diretamente na aplicação ou criando realmente um novo banco de dados ou ainda utilizando uma camada sobre um banco já existente que permita a tradução de operações temporais para operações SQL padrão. Neste último modelo enquadra-se o TimeDB, uma ferramenta que possibilita a utilização de bancos comerciais como se fossem bancos temporais, no entanto esta ferramenta ainda apresenta a carência de alguns recursos. 1. Introdução A grande maioria das aplicações que utilizam bancos de dados têm acesso apenas a um único estado do mundo real, geralmente o estado mais atual do banco, e uma atualização do mesmo resulta na perda dos dados antigos. Existem, no entanto, muitas aplicações em que é necessária a manipulação de outros estados do banco, como estados passados e até mesmo estados futuros. Exemplos dessas aplicações são: controle de estoque, sistemas de reserva, sistemas de suporte à decisão, etc. Com isso, surgem os bancos de dados temporais, que permitem armazenar todos os estados de uma aplicação, registrando sua evolução com o passar do tempo.
Na seção 2 é feita uma breve apresentação de bancos de dados temporais, sendo mostradas algumas características de um banco de dados temporal específico, o TimeDB, na seção 3. A seção 4 apresenta um estudo de caso utilizando o TimeDB e o Oracle 10g, e nas seções que seguem são exibidas algumas questões atuais, tendências futuras e as conclusões deste trabalho. 2. Bancos de Dados Temporais Como dito anteriomente, os bancos de dados não-temporais apenas dão suporte ao acesso de apenas um único estado do mundo real, geralmente o estado mais recente, e uma atualização nas informações desse banco significa a perda dos dados antigos. Contudo, existe um grande número de aplicações que necessitam ter acesso a não apenas o estado mais recente do banco, mas também a estados passados e futuros. Um dos primeiros passos na construção de bancos de dados temporais é a associação de informação de tempo aos dados, permitindo a distinção entre diferentes estados [Steiner 1999]. Para isso, diferentes noções do tempo são relevantes para a construção de bancos de dados temporais. O tempo de validade (valid time), que é o tempo no qual os dados são válidos no mundo real, e o tempo de transação (transaction time), que é o tempo em que os dados são inseridos no banco. Essas diferentes noções de tempo permitem a distinção entre tipos de bancos de dados temporais: bancos de dados de tempo de validade, bancos de dados de tempo de transação e bancos de dados bitemporais. Os bancos de dados convencionais são também conhecidos como snapshot database, por armazenarem um único estado do mundo real, geralmente o estado mais recente. São exemplos de aplicações que lidam com dados temporais: aplicações financeiras, sistemas de reserva, sistemas de gerenciamento de informações médicas, sistemas de suporte à decisão, etc. [Steiner 1999] afirma, que de fato, é difícil identificar domínios de aplicações que não envolvam o gerenciamento de dados temporais. 2.1. Implementação de Bancos de Dados Temporais [Steiner 1998] discute diferentes soluções para gerenciar dados temporais. Eles identificam quatro possibilidades: (i) utilizar o tipo DATE fornecido por SGBDs não temporais e construir todo o suporte temporal na própria aplicação, (ii) implementar um tipo abstrato de dado para o tempo, (iii) estender um modelo de dados não temporal para um modelo temporal, e (iv) generalizar um modelo de dados não-temporal para um modelo temporal. 3. TimeDB O TimeDB funciona como uma camada acoplada a bancos de dados comerciais, traduzindo expressões temporais para expressões SQL padrão. Desta forma é possível fazer uso de características já existentes em bancos de dados, como a persistência e concorrência, sem a necessidade de reimplementá-las. Com o TimeDB é possível armazenar e manipular diversos estados de uma base de dados. A grande vantagem de sua utilização é que bases de dados já existentes, armazenadas em SGBD comerciais, e aplicações que acessam estes dados podem continuar sendo utilizadas enquanto que novas aplicações que tratam dados temporais podem ser adicionadas.
O TimeDB utiliza a linguagem ATSQL2 que é um linguagem de pesquisa temporal baseada na linguagem SQL, que suporta alterações, visões, declarações e restrições temporais. Por ter sido baseada em SQL, qualquer expressão construída utilizando SQL padrão, também será suportada pela linguagem ATSQL2. Na versão 1.0 do TimeDB eram suportadas consultas, inserções, alterações, exclusões, criação de tabelas e visões, tudo isso de forma temporal, além de declarações e restrições temporais em tabelas. Nesta versão também era suportado tempo de validade e tempo de transação. O TimeDB foi reimplementado utilizando-se a linguagem de programação Java, tornando-se independente de plataforma. Nesta nova implementação algumas diferenças surgiram em relação a versão 1.0: TimeDB 2.0 utiliza JDBC, permitindo a conexão com diferentes bancos de dados; TimeDB 2.0 possui uma interface gráfica que permite a execução de consultas de uma forma mais fácil; TimeDB 2.0 é otimizado em relação a construção de tabelas auxiliares; TimeDB 2.0 possui uma interface de comunicação nativa que pode ser usada por aplicações Java para execução de expressões ATSQL2. Além disso, a versão 2.0 acrescentou a possibilidade de utilização de funções de agregação, cláusulas GROUP BY, cláusulas HAVING e restrições de colunas e tabelas, no entanto algumas características presentes na versão 1.0 não são mais suportadas, como as operações de alteração e operações de tempo de transação e bitemporais. Atualmente o TimeDB é compatível com os bancos Oracle, Sybase e IBM Cloudscape. 3.1. ATSQL2 Nesta seção mostraremos a sintaxe utilizada pelo ATSQL2 para criação, pesquisa e manutenção dos dados e na seção seguinte faremos uso dos comandos aqui exibidos para realização de um estudo de caso. Um exemplo da sintaxe do ATSQL2 pode ser visto na tabela 1. 3.2. Tipos especiais de dados O TimeDB trabalha com alguns tipos especiais de dados voltados para questões temporais que são o interval, o period e o date. O tipo interval permite especificar um intervalo de tempo que pode englobar dias, meses e anos (e.g., interval 3 year 2 month). O tipo period permite a especificação de períodos entre dois pontos no tempo (e.g., period [1990-1993)). O tipo date especifica que um determinado dado é uma data (e.g., date 1981-03-09 ). 4. Estudo de Caso Com objetivo de exemplificar o funcionamento do TimeDB para implementação de um banco de dados temporal, é mostrado nesta seção um cenário onde os dados podem ser modelados de forma temporal e uma implementação deste cenário utilizando o TimeDB em conjunto com o banco de dados Oracle 10g.
Criação de Tabelas Inserção de Dados Consulta de Dados Exclusão de Dados CREATE TABLE nometabela(campo1 tipo,..., campon tipo) AS VALIDTIME; /* Aceita somente tempo de validade */ VALIDTIME PERIOD [tempoinicial-tempofinal) INSERT INTO nometabela VALUES (valor1,..., valorn); /* TempoInicial e TempoFinal podem assumir os valores beginning e forever respectivamente para denotar infinito */ NONSEQUENCED VALIDTIME SELECT * FROM nometabela; /* Retorna os dados da tabela sem levar em consideração o tempo de validade */ VALIDTIME SELECT * FROM nometabela; /* Retorna os dados da tabela levando em consideração o tempo de validade */ VALIDTIME (SELECT * FROM nometabela) (PERIOD); /* Retorna as instâncias de um mesmo registro que são continuidade uma da outra em função do tempo em um único registro */ VALIDTIME PERIOD [tempoinicial-tempofinal) SELECT * FROM nometabela; /* Retorna os dados compreendidos entre um tempo inicial e um tempo final */ DELETE FROM nometabela WHERE condicao; /* Ao excluir um registro com tempo final igual a forever, este receberá como tempo final a data e horário da exclusão, não sendo fisicamente excluído */ Table 1. Comandos ATSQL2 4.1. Cenário Neste artigo é proposto como cenário um sistema para controle do departamento pessoal de uma empresa. O departamento pessoal mantém um cadastro dos funcionários que trabalham atualmente na empresa, bem como os que já trabalharam. No cadastro do funcionário é armazenado o seu nome, um código identificador único, seu cpf e rg, o seu salário, a data de sua admissão, seu cargo e o departamento ao qual pertence. O sistema também possui um cadastro de departamentos que apresenta o código único do departamento e o seu nome. Com o sistema atualmente implementado esta empresa passa pelo problema de perder informações antigas dos seus funcionários, informações essas que não são mais atualmente verdadeiras mas que são úteis para geração de algumas estatísticas. O usuário necessita que o salário anterior do funcionário não seja perdido após uma alteração de seu valor para que dessa forma possa ser realizada uma estatística do aumento ocorrido durante sua permanência na empresa. Também é necessário manter um histórico dos cargos que já foram assumidos pelo funcionário bem como os departamentos pelo qual ele passou. No primeiro momento o sistema deve apresentar a possibilidade de obtenção das seguintes informações: Dado o código de um funcionário, obter todos os cargos que ele já possuiu dentro da empresa; Dado o código de um funcionário, obter todos os departamentos nos quais ele já trabalhou; Obter a média de salário do funcionário durante todo o tempo em que esteve empregado; Obter o número de funcionários que trabalham atualmente na empresa; Obter o maior e o menor salário pago atualmente na empresa;
Obter o maior e o menor salário já pago na empresa; Listar os departamentos existentes na empresa e os maiores e menores salários atuais de cada departamento; Listar o número de funcionários existentes atualmente em cada departamento. Posteriormente novas consultas poderão ser necessárias. 4.2. Modelagem do banco de dados Para a implementação do sistema explicado na seção anterior, foi gerado o modelo ER exibido na figura 1. Figure 1. Modelo ER para o sistema de controle de funcionários 4.3. Implementação utilizando TimeDB e Oracle 10g Para a implementação foi utilizado o TimeDB versão 2.2 e a interface gráfica que o acompanha, através da qual foi feita a criação do banco de dados, operações de manutenção e consultas. Para possibilitar a criação de tabelas através da interface gráfica, a primeira coisa que deve ser feita é acessar o menu TimeDB e executar a opção Create DB. Ao realizar isso serão criadas cinco tabelas para o usuário no oracle, as tabelas ASSERTIONS, KEYS, TABLE TYPES, TABLE VIEW SCHEMES e VIEWS. Elas são utilizadas internamente pelo TimeDB para controle das informações temporais. A tabela Funcionario foi criada de forma temporal com o objetivo de permitir que dados do funcionário não sejam perdidos após uma alteração, como por exemplo, um aumento de salário. Para a criação das tabelas foi executado o seguinte script SQL: CREATE TABLE Departamento (codigo INTEGER PRIMARY KEY, nome VARCHAR(40)); CREATE TABLE Cargo (codigo INTEGER PRIMARY KEY, nome VARCHAR(40)); CREATE TABLE CargoDep (codigocargodep INTEGER PRIMARY KEY, codigocargo INTEGER, codigodep INTEGER, FOREIGN KEY (codigocargo) REFERENCES Cargo(codigo),FOREIGN KEY (codigodep) REFERENCES Departamento(codigo)); CREATE TABLE Funcionario (codigo INTEGER PRIMARY KEY, nome VARCHAR(40), cpf VARCHAR(14), rg VARCHAR(10), salario FLOAT, admissao DATE, codigocargodep INTEGER, FOREIGN KEY (codigocargodep) REFERENCES CargoDep(codigoCargoDep)) AS VALIDTIME; Ao criar a tabela Funcionario de forma temporal, o TimeDB automaticamente acrescentou duas colunas à tabela, a coluna de tempo de validade inicial e a coluna de
tempo de validade final, demonstrado na figura 2 através dos campos VTS TIMEDB e VTE TIMEDB respectivamente. Figure 2. Tabela Funcionario Tendo as tabelas criadas, o próximo passo foi populá-las com dados para posterior realização de consultas. Foram criados quatro departamentos: Testes, Desenvolvimento, Análise, Gerência. Também foram criados sete cargos: Estagiário, Testador, Programador Júnior, Programador Sênior, Analista de Sistemas Júnior, Analista de Sistemas Sênior e Gerente de Projetos. A relação entre os cargos e departamentos pode ser visualizada na tabela 2. Cargo Estagiário Estagiário Estagiário Testador Programador Júnior Programador Sênior Analista de Sistemas Júnior Analista de Sistemas Sênior Gerente de Projetos Departamento Testes Desenvolvimento Análise Testes Desenvolvimento Desenvolvimento Análise Análise Gerência Table 2. Relação Cargos X Departamentos A tabela Funcionario foi populada com dados que permitissem a realização das consultas necessárias citadas na definição do cenário. Logo após as seguintes consultas foram criadas: Dado o código de um funcionário, obter todos os cargos que ele já possuiu dentro da empresa: SELECT c.nome FROM cargo c WHERE EXISTS (SELECT cd.codigocargo FROM cargodep cd WHERE cd.codigocargo = c.codigo AND EXISTS (VALIDTIME SELECT f.codigocargodep FROM funcionario f WHERE f.codigo = :CODIGO AND f.codigocargodep = cd.codigocargodep)); A necessidade da criação de subselects foi devido a não aceitação por parte do TimeDB de realizar um VALIDTIME SELECT em tabelas que não foram criadas de forma temporal. Dado o código de um funcionário, obter todos os departamentos nos quais ele já trabalhou:
SELECT d.nome FROM departamento d WHERE EXISTS (SELECT cd.codigocargo FROM cargodep cd WHERE cd.codigodep = d.codigo AND EXISTS (VALIDTIME SELECT f.codigocargodep FROM funcionario f WHERE f.codigo = :CODIGO AND f.codigocargodep = cd.codigocargodep)); Obter a média de salário do funcionário durante todo o tempo em que esteve empregado: NONSEQUENCED VALIDTIME SELECT AVG(salario) FROM Funcionario WHERE codigo = :CODIGO; Obter o número de funcionários que trabalham atualmente na empresa: NONSEQUENCED VALIDTIME SELECT COUNT(f.codigo) FROM funcionario f WHERE (END(VALIDTIME(f)) = FOREVER); Obter o maior e o menor salário pago atualmente na empresa: NONSEQUENCED VALIDTIME SELECT MAX(f.salario) FROM Funcionario f WHERE (END(VALIDTIME(f)) = FOREVER); NONSEQUENCED VALIDTIME SELECT MIN(f.salario) FROM Funcionario f WHERE (END(VALIDTIME(f)) = FOREVER); Obter o maior e o menor salário já pago na empresa: NONSEQUENCED VALIDTIME SELECT MAX(f.salario) FROM Funcionario f; NONSEQUENCED VALIDTIME SELECT MIN(f.salario) FROM Funcionario f; Listar os departamentos existentes na empresa e os maiores e menores salários atuais de cada departamento: SELECT cd.codigodep, d.nome, MAX(f.salario) FROM CargoDep cd, Departamento d, Funcionario f WHERE f.codigocargodep = cd.codigocargodep AND cd.codigodep = d.codigo GROUP BY cd.codigodep, d.nome; SELECT cd.codigodep, d.nome, MIN(f.salario) FROM CargoDep cd, Departamento d, Funcionario f WHERE f.codigocargodep = cd.codigocargodep AND cd.codigodep = d.codigo GROUP BY cd.codigodep, d.nome; Listar o número de funcionários existentes atualmente em cada departamento: SELECT cd.codigodep, d.nome, COUNT(f.codigo) FROM CargoDep cd, Departamento d, Funcionario f WHERE f.codigocargodep = cd.codigocargodep AND cd.codigodep = d.codigo GROUP BY cd.codigodep, d.nome; 5. Questões Atuais Atualmente é difícil encontrar um suporte à informações temporais em SGBDs comerciais, o que dificulta bastante a construção de aplicações que necessitam manipular dados temporais por motivos já mostrados nas seções anteriores. O que é encontrado hoje são extensões de SGBDs que dão suporte à manipulação de dados temporais, porém em tais extensões os esforços são geralmente concentrados em algumas características especiais como estruturas de dados temporais, projeto da linguagem de consulta, álgebra temporal ou restrições de integridade temporal. Por esse motivo, [Steiner 1998] argumenta que esta abordagem está a metade do caminho da abordagem ideal, que seria a generalização de um modelo de dados.
6. Conclusões e Tendências Futuras A tendência natural é que seja criado um novo modelo de dados que tenha suporte à manipulação de informações temporais. Pois apesar das extensões de modelos de dados não-temporais proporcionarem essa manipulação, existem restrições as quais só podem ser eliminadas com a construção de um novo modelo. Com respeito a generalização das operações da álgebra temporal, um passo já foi tomado sendo definido o conceito de completeza temporal (temporal completeness) [Böhlen and Marti 1994] que introduz requerimentos proveitosos a respeito de dados e consultas temporais. Neste trabalho foi estudado o conceito de banco de dados temporais e a ferramenta TimeDB que serve como uma camada para tradução de SQLs temporais em SQLs padrões. O TimeDB mostrou-se uma ferramenta de grande valia no auxilio da implementação de aplicações temporais, no entanto algumas necessidades foram sentidas, como por exemplo, ao incluir um novo registro com o mesmo valor de chave primária de um registro com tempo final de validade forever, este não é finalizado. A finalização dos registros com o tempo final em aberto só foi realizada, em nossos testes, através do comando de exclusão. Ou seja, o TimeDB possibilita a realização de operações temporais em um banco de dados, no entanto em alguns casos é necessário que o programador interfira criando conjuntos de operações para atingir um estado do banco que poderia ser atingido de forma automática. References Böhlen, M. and Marti, R. (1994). On the completeness of temporal database query languages. In Gabbay, D. M. and Ohlbach, H.-J., editors, Temporal Logic: 1st International Conference (ICTL 94), pages 283 300. Springer, Berlin, Heidelberg. Steiner, A. (1998). A Generalisation Approach to Temporal Data Models and their Implementations. PhD thesis, Swiss Federal Institute of Technology. Steiner, A. (1999). TimeDB 2.0. http://www.timeconsult.com. Acessado em junho de 2006.