Bancos de dados convencionais, por seu próprio conceito, guardam somente o último valor associado aos registros de suas tabelas significando que, uma vez atualizadas ou excluídas, o valor anterior das tuplas não pode ser mais recuperado. Tais bancos de dados são chamados transitórios. Mas a necessidade de guardar o histórico das alterações nos dados, bem como do esquema das tabelas, foi se mostrando crescente com o passar dos anos, surgindo as linhas de pesquisa em bancos de dados temporais (ou TDB – do inglês Temporal Data Bases).
Com relação às alterações de estado dos dados, Golfarelli e Rizzi (2009) apresentam as duas principais dimensões temporais que as tuplas de um TDB podem ter: tempo de validade e tempo de transação. O primeiro indica quando uma certa tupla no banco de dados é válida para o negócio (ou o tempo no mundo real), enquanto o segundo indica quando a tupla é registrada e válida no banco de
Capítulo 2 - Fundamentação Teórica 26
dados (ou o tempo no sistema). De acordo com a capacidade de um banco de dados em lidar com essas dimensões temporais, pode-se classificá-los em bancos de dados de tempos de validade, bancos de dados de tempos de transação ou bancos de dados bitemporais. Ainda de acordo com Golfarelli e Rizzi (2009), o principal benefício de um banco de dados bitemporal (que tem a capacidade de guardar ambos os tempos de validade e de transação dos dados) é a capacidade de se obter o mesmo resultado de uma consulta independente do momento em que esta é feita.
A Tabela 1 exemplifica uma sequência de registros contendo tempos de validade e tempos de transação. Nela podemos ver um cadastro de centros de distribuição com seus endereços e capacidades. A validade do registro para o negócio é dado pelas colunas V_Inicial e V_final enquanto a validade para o sistema é dado por T_inicial e T_Final. O centro de distribuição 1 (C1) está apenas cadastrado no sistema mas ainda não é considerado como válido para o negócio. Já o centro de distribuição 2 (C2) foi cadastrado inicialmente no endereço 2 mas percebeu-se que o cadastro estava errado procedendo-se o encerramento do registro para o sistema (preenchimento de T_Final) e criando-se um novo registro. O mesmo centro de distribuição começou a ser considerado válido para o negócio em fevereiro (preenchimento da V_Inicial) e ainda estava válido quando o registro foi encerrado no sistema. Note-se que a data de validade do negócio pode ser anterior à validade de sistema mostrando a independência entre os conceitos – o centro de distribuição 2 já era válido para o negócio antes de ser cadastrado no sistema e continuava válido até ser finalizado neste. O caso do centro de distribuição 3 (C3) é provavelmente o mais comum onde o registro é cadastrado no sistema (T_inicial é preenchida), depois fica válido para o negócio (V_inicial é informada) e, depois de um tempo de atividade, para de ser válido para o negócio e é invalidado no sistema alguns dias após (V_Final e T_Final, respectivamente, são preenchidas).
Tabela 1: Exemplo de registros com tempos de validade e transação de um TDB CDist Capacidade Endereço V_Inicial V_Final T_Inicial T_Final
C1 300 End1 - - 2013/01/15 -
C2 200 End2 - - 2013/02/10 2013/02/14
C2 200 End3 2013/02/10 - 2013/02/14 2013/05/13
Capítulo 2 - Fundamentação Teórica 27
Apesar de poder ser implementado com tecnologia de bancos de dados convencionais, tal esquema torna extremamente difícil decidir quais registros são válidos para o sistema ou para o negócio, uma vez que todas as consultas precisam ser escritas tomando-se em consideração tais datas de validade. Além disso, se implementados sem a devida segurança, os campos de validade podem ser alterados à revelia do sistema e causar inconsistências nos registros. Para diminuir tais problemas, os pesquisadores têm procurado desenvolver extensões da linguagem SQL para facilitar o desenvolvimento dos sistemas que utilizam TDBs. Tais diretivas temporais são incorporadas normalmente através de reescrita de consultas. É o caso da SQL-92 e da sua evolução chamada TSQL2. Houve movimentação para incluir uma evolução das construções propostas na TSQL2 na especificação ISO da linguagem SQL3 (chamada SQL/Temporal) mas uma discordância entre os autores atrapalhou os esforços fazendo com que o comitê fosse desfeito em 2001. Entretanto, conceitos e construções da SQL/Temporal foram incluídas no padrão SQL:2011 e implementados em bases de dados como Oracle (chamado “flashback queries”), Teradata e IBM DB2 (SNODGRAS, s.d.).
Quanto à captura das alterações de esquema dos bancos de dados, Roddick (1995) introduz três tipos de alteração possíveis: i) Modificação de Esquema; ii) Evolução de Esquema e iii) Versionamento de Esquema. O primeiro acontece quando o banco de dados permite alterações no esquema, mas não oferece garantia quanto à integridade dos dados, enquanto o segundo permite a alteração de esquema e também garante a integridade dos dados. Além de permitir a alteração e garantir a integridade dos dados, o terceiro tipo permite o acesso aos dados tanto anteriores quanto posteriores à última versão do esquema. Este último tipo pode ser ainda dividido em versionamento de esquema parcial (quando somente os dados da última versão podem ser alterados – apesar de permitir acesso a todos os dados) ou versionamento de esquema total (quando a alteração é permitida em todas as versões). Implementar tais bancos de dados normalmente requer a introdução de metadados descrevendo o esquema através do tempo e funções de conversão entre versões. A reescrita de consultas é também uma técnica comum para adequar o que é consultado à versão apropriada do esquema. Um exemplo de tais implementações é o metamodelo COMET (EDER, KONCILIA e MORZY, 2006) que faz o uso de tabelas e relacionamentos para descrever a evolução do esquema de dados e como eles se relacionam para que o processamento das consultas possa ser adequado à
Capítulo 2 - Fundamentação Teórica 28
temporalidade envolvida. O modelo prevê condições para uma evolução segura, funções de transformação dos dados entre versões e facilidades para decidir quando a reescrita das consultas precisa extrapolar versões ou não, a fim de melhorar o desempenho da reescrita e execução das mesmas.
Seguindo o esquema proposto nesta pesquisa, apenas o conceito de validade de transação será exercitado. O problema de alteração de esquema também não será considerado nesta pesquisa, sendo o foco apenas a alteração de instâncias.
Análise do exemplo proposto utilizando-se BDTs
A partir do exemplo proposto no item 2.1.1, pode-se inferir que o projeto do produto pode utilizar conceitos de bases de dados bitemporais com as datas de transação e validade alterando a visibilidade do produto entre as várias áreas (engenharia, PCP, vendas) sem a necessidade de estruturas de controle alternativas. O mesmo se aplica aos centros de distribuição que podem ser alocados e estocados sem interferirem com o plano de vendas da empresa antes do tempo esperado.