Adequando a perspectiva temporal aos modelos de dados relacionais

por João Marcelo Borovina Josko

Os objetos do negócio – Nota Fiscal, Apólice de Seguro, Contrato Imobiliário, para citar alguns – sofrem inúmeras modificações ao longo de sua vida, formando um conjunto de posições ou versões que constituem seu histórico. Durante bom tempo, a persistência desses objetos ocorreu em bancos de dados convencionais – ou instantâneos – em que somente a versão corrente – a última modificação – era de interesse.

O fim da distinção entre dados históricos e correntes – analíticos e operacionais, respectivamente –, advindo da nova visão de acompanhamento do negócio por parte das organizações, aumentou a demanda pelo encapsulamento da gestão do tempo nas bases de dados com o intuito de prover serviços temporais robustos, confiáveis e transparentes.

Concernente à estruturação dos dados, padrões de modelagem permitem a gestão do tempo dentro das restrições dos Sistemas Gerenciadores de Banco de Dados Relacionais – SGBDR – que, por sua vez, oferecem funcionalidades e linguagem de manipulação pouco adequada ao tratamento do aspecto temporal.

Conceitos básicos de Bancos de Dados Temporais

Um banco de dados é dito temporal quando é capaz de armazenar dados passados, presentes e futuros sobre os objetos de interesse para um negócio. Nessa categoria, por exemplo, temos os Sistemas de Apoio a Decisão, de Informação Geográfica, de Informação para a área médica, entre outros. O tratamento do aspecto temporal ocorre nos processos de modelagem de dados – da Conceitual a Física – e desenvolvimento das instruções de recuperação e manipulação.

O modelo de dados tradicional tem duas dimensões; uma representando as instâncias ou linhas de um objeto do negócio e outra os seus atributos. No modelo de dados com propriedades temporais, surge uma terceira dimensão cujo propósito é associar o elemento tempo ao valor de cada atributo, conforme ilustrado na figura 1 (EDELWEISS, 1998). Assim, enquanto que no primeiro modelo cada atributo de uma instância possui um único valor – o último –, o segundo é capaz de armazenar as transições dos valores da mesma instância.



A figura abaixo ilustra como um objeto de negócio evolui ao longo do tempo; da versão original a corrente. Essa também reflete a nomenclatura empregada neste trabalho – próxima a Orientação a Objeto – que difere daquela empregada na visão acadêmica do tema de banco de dados temporais.


Figura 2 – Estrutura de Classes e Instâncias no tempo

Padrões de tratamento do aspecto temporal

Um padrão é composto por uma proposta de modelo e um conjunto de regras necessárias ao tratamento da perspectiva tempo de forma a garantir a veracidade e a consistência dos dados durante as operações de manutenção. Cumpre lembrar que, pela falta de melhor suporte dos SGBDR, essas regras devem ser construídas, seja na camada do banco de dados ou da aplicação.

Assim, os padrões elencados abaixo serão descritos e exemplificados quanto à semântica no trato do tempo, enfocando a modelagem de dados lógica para SGBDR. São eles:

§  Sobreposição de Objeto do Negócio com Eliminação Lógica

§  Versionamento Simples de Objeto do Negócio

§  Versionamento Bitemporal de Objeto do Negócio

§  Versionamento Recorrente de Objetos do Negócio

Sobreposição de Objeto do Negócio com Eliminação Lógica

Representando o histórico menos expressivo, nesse padrão um objeto do negócio somente apresenta sua última posição e sua invalidade ocorre pelo assinalamento de uma data – “dat_fim_validade” – que, simultaneamente, representa a eliminação lógica. A ausência de versões implica que os estados anteriores do objeto são perdidos à medida que os valores anteriores são sobrepostos por operações de modificação, conforme exemplificado na figura 3.

Dentre as regras deste padrão, a principal obriga que a data de final de validade, quando preenchida, reflita o momento presente ou futuro do negócio e, daí em diante, não seja mais modificada. Utilizar datas retroativas ou modificar seu conteúdo após preenchimento é semanticamente incorreto, visto que altera as respostas obtidas sobre o passado o que, para muitas situações do negócio, não é aplicável. 



Figura 3 – Evolução histórica da opção de Sobreposição com Eliminação Lógica

Versionamento simples de Objeto do Negócio

Nesse padrão, as modificações sofridas por um objeto do negócio são preservadas, resultando em uma série de versões ordenadas cronologicamente e sem brechas – a validade de uma versão termina um instante de tempo anterior à data de início de validade da versão subseqüente. Essa composição, então, propicia a geração de respostas sobre um objeto em qualquer período do seu tempo de vida, como pode ser observado na figura 4. Nesta, o objeto ‘João dos Santos’, ao final da última operação, apresenta todas as linhas referentes às suas versões.

Apesar da capacidade supracitada, esse padrão não consegue atender necessidades específicas que envolva a reativação de objetos do negócio previamente eliminados – recorrência –, o tratamento de versão de objetos que nascem com período de vida pré-determinado – eliminação proativa – ou a realização de operações proativas sobre um fato do negócio.

Tal cenário decorre, em parte, pelo duplo significado atribuído às datas “dat_inicio_validade” e “dat_fim_validade”: i) a validade de um fato para o negócio e ii) uma transação para o sistema. Esse fato obriga que as manutenções sobre um objeto ocorram na data efetiva para o negócio, nem antes e nem depois.

Figura 4 – Evolução histórica da opção de Versionamento simples de Objeto do Negócio

A outra parte é decorrente das regras necessárias para manter a semântica desse padrão. Além daquelas associadas na garantia de que não haja sobreposições e intervalos entre as versões, ainda vale destacar:

§ Para a 1ª. Versão, a data de fim de validade não deve ser preenchida. Não podemos encerrar algo que ainda não começou;

§ Um objeto é indicado como eliminado por meio do assinalamento da data de fim de validade sobre a versão corrente, a última;

§ Não podem existir novas versões após a eliminação de um objeto, assim como todas as versões existentes devem possuir data de início de validade inferior à data de eliminação.

Versionamento Bitemporal de Objeto do Negócio

Uma forma de suplantar a restrição para operações proativas – acrescentar fatos do negócio antes do seu início de validade – é aplicar o recurso da bitemporalidade cujo propósito é utilizar dois conjuntos de datas conceitualmente distintas; um representando a validade de fatos do negócio e outro a transação para o sistema, conforme ilustrado na série de operações proativas da figura 5. Essa é a característica essencial que difere esse padrão do supracitado sendo as demais – inclusive regras – similares.

Contudo, o poder de efetuar operações retroativas e proativas, proporcionada pela bitemporalidade, aumenta a possibilidade da geração de enganos. Seu uso, portanto, requer o conhecimento dos seus resultados e das regras modificadas em relação ao padrão anterior. São elas:

§ São inconsistentes as operações de inclusão ou atualização retroativas,  pois conforme já discutido, são semanticamente incorretas à medida que modificam o passado;

§ É acrescentar uma nova versão de um objeto do negócio que passará ter validade no futuro – inclusão proativa. Porém, o versionamento somente pode ocorrer após o inicio de validade da versão corrente, pois não é possível versionar algo que ainda não existe perante o sistema;

§ É possível de indicar o fim da validade da versão de um objeto do negócio já no momento de sua inclusão – eliminação proativa. Novamente, essa operação somente pode ocorrer após o inicio de validade da versão corrente. Não é possível eliminar algo que ainda não existe perante o sistema.

Figura 5 – Evolução histórica da opção de Versionamento Bitemporal do Objeto de Negócio

Versionamento Recorrente de Objeto do Negócio

Existem negócios cujos objetos podem reaparecer certo tempo após sua eliminação, como é o caso, por exemplo, dos Cartões de Crédito. Contudo, os padrões acima descritos não propiciam essa capacidade de recorrência, pois aplicam regras que impedem que um objeto de negócio seja versionado após eliminação e que existam intervalos – gaps – entre as versões.

Esse padrão apresenta as mesmas características do padrão “Versionamento simples de Objeto do Negócio”, salvo em relação às regras acima que são modificadas para atender a necessidade de recorrência. Sendo elas:

§ Nas versões recorrentes, ou seja, aquela acrescentada imediatamente à versão previamente eliminada, é permitido intervalo desde que a data de início de validade da primeira seja superior a data de fim de validade da segunda;

§ Para as versões não recorrentes, continua ativa a regra que impede a existência de intervalos.

Figura 6 – Evolução histórica da opção de Versionamento Recorrente de Objeto do Negócio

Conclusão

Os pontos discutidos acima representam uma introdução ao assunto de Banco de Dados Temporal nos SGBDR cuja complexidade está além da mera colocação de datas em uma tabela. Os conceitos aqui abordados, bem como outros relativos às melhores abordagens para a implementação física de modelo de dados temporal, as melhores abordagens para a recuperação de dados temporais, questões envolvendo as chaves estrangeiras em objetos versionados, entre outros, representam conceitos essenciais para aqueles que tratam de sistemas com necessidades de informações no passado, presente e futuro.

Além desse propósito, procura alertar que a escolha do padrão deve ser feita com absoluta consciência do que é necessário para atender os requisitos do negócio e não por motivação puramente técnica. Esse conhecimento é imprescindível para determinar a prevalência de um padrão em relação a outro.

Por fim, vale mencionar que a perspectiva filosófica de preservar as versões dos objetos do negócio, adotada neste trabalho, difere substancialmente daquela presente na modelagem multidimensional ou star-schema – proposta por Ralph Kimball – que prioriza os eventos do negócio. A primeira permite chegar à segunda, mas não o inverso.

Referências bibliográficas

EDELWEISS, Nina. “Banco de dados temporais: teoria e prática”. Porto Alegre: UFRGS, 1998.

EDELWEISS, Nina; OLIVEIRA, J.P.M. “Modelagem de aspectos temporais de sistemas de informação”. Recife: IX Escola de Computação - UFPE, 1994.