Modelos Temporais

Vários modelos para bancos de dados temporais como extensões do modelo relacional foram propostos. Esses modelos podem ser divididos em dois grandes grupos:

Modelos Agrupados

São modelos que associam tempo aos atributos individuais. Cada valor de um atributo tem um ou mais timestamps associados. Esses modelos são baseados em relações N1NF (Non-First Normal Form : Não-Primeira Forma Normal). O lifespan de um atributo é representado em uma única tupla através de elementos temporais. Um elemento temporal é uma união finita de intervalos disjuntos [Gadia&Nair 93] [Jensen

et al 94]. Uma relação temporal típica de um modelo agrupado tem o aspecto da Figura 5.2. Ela não está em primeira forma normal, seus atributos são multivalorados. O lifespan do atributo empregado é definido em apenas uma tupla.

Empregado Gerente [1, 4] ∪ [10, NOW] Jonas [1,2] Tom [2,4] Manoel [10, NOW] David [2,3] ∪ [6,9] João [2,3] Manoel [6,9] Luciano [1, NOW] Sérgio [1,2] Tom [2,4] Manoel [6,9] Luciano [10, NOW] David

Figura 5.2 – Relação temporal Empregado-Gerente num modelo agrupado.

Os modelos agrupados podem ser classificados em homogêneos e heterogêneos. Nos homogêneos todos os atributos de uma tupla são definidos em um mesmo período de tempo [Tansel 97]. Por exemplo, os atributos da primeira tupla da relação da Figura 5.2 estão definidos nos intervalos [1, 4] e [10, NOW]. Modelos heterogêneos não fazem esta restrição.

Como exemplo de modelos temporais agrupados podemos citar o HRDM [Clifford&Croker 93], o TRDM [Tansel 97] e o TempSQL [Gadia&Nair 93].

Modelos desagrupados

Modelos desagrupados associam tempo a tuplas individuais. Cada tupla tem um ou mais timestamps associados. As relações dos modelos desagrupados estão em 1NF (First Normal Form : primeira forma normal). A relação da Figura 5.2 é equivalente à relação da Figura 5.3 num modelo desagrupado.

Empregado Gerente Timestamp

Jonas Tom [1,2]

Jonas Manoel [2,4]

Jonas David [10, NOW]

João Manoel [2,3]

João Luciano [6,9]

Sérgio Tom [1,2]

Sérgio Manoel [2,4]

Sérgio Luciano [6,9]

Sérgio David [10, NOW]

Em tais modelos o lifespan de um atributo pode estar dividido entre várias tuplas como podemos observar na Figura 5.3. Note que a chave de uma relação temporal não pode ser apenas um atributo invariável no tempo. A chave deve ser composta de um atributo invariável mais um dos instantes inicial ou final do intervalo.

Alguns modelos implementam os timestamps como propriedades implícitas das relações. Um exemplo é o TSQL2 [Snodgrass et al 94] [Snodgrass 95]. Outros os implementam explicitamente como um atributo comum da relação. Exemplo : TRM [Navathe&Ahmed 93] e o IXRM [Lorentzos 93].

5.3

Meta-esquema Temporal em Estrela (MET*)

Um esquema baseado no MET* tem o aspecto geral da Figura 5.4. Neste esquema, o histórico de um atributo é guardado numa tabela separada chamada tabela de histórico. Um tabela de histórico pode guardar valores antigos de um atributo ou de um conjunto de atributos (veja HistóricoAtributo2-n). Uma tabela de histórico típica possui as seguintes colunas: #Dimensão, contém a chave que identifica à qual linha da dimensão pertence o atributo histórico (esse é um relacionamento de chave estrangeira como outro qualquer); AtributoHistórico, que guarda os valores antigos do atributo (ou conjunto de atributos) dimensional que sofre alterações ao longo do tempo; De e Até : que indica o período de tempo (intervalo) em que o valor contido em AtributoHistórico foi válido para o atributo dimensional.

Tomemos como exemplo o esquema em estrela da Figura 2.1. Para guardar os históricos do atributo Gerente da dimensão Loja e dos atributos de hierarquia de produto da dimensão Produto, estendemos tal esquema para o da Figura 5.5. A funcionalidade do MET*, tomando como exemplo a dimensão Loja, é a seguinte:

1. Para cada atributo (ou conjunto de atributos) de uma dimensão para o qual se deseja guardar o histórico (Gerente da tabela Loja, Figura 5.5) constrói-se uma tabela histórica (HistóricoGerente, Figura 5.5) com as seguintes colunas: chave da dimensão do(s) atributo(s) (Loja#, Figura 5.5), o(s) atributo(s) histórico(s) (Gerente, Figura 5.5) e os atributos De, o instante do tempo em que o registro se torna válido, e Até, o instante onde se encerra o ciclo de vida do registro;

2. Na dimensão (Loja, Figura 5.5) mantém-se o valor atual do atributo histórico (Gerente, Figura 2);

3. O valor atual também é mantido na tabela histórica. Neste caso Até contém a palavra-chave NOW para indicar que tal valor continua válido no instante atual, que é variável;

4. As chaves das tabelas de histórico são compostas pela chave da dimensão mais o atributo De. Os domínios dos atributos De e Até são o domínio da chave da dimensão Tempo (domínio de Tempo#, Figura 5.5). Note-se o relacionamento de chave estrangeira entre as tabelas históricas e a dimensão Tempo;

5. Cada vez que um atributo histórico for alterado, o atributo Até do valor antigo é atualizado para o tempo atual e o valor atual é apropriadamente incluído na tabela de histórico da dimensão correspondente; na tabela de dimensão, é mantido o novo valor atual.

Figura 5.5 – MET* para vendas no varejo. As vantagens do esquema MET* são:

v1 - O Star Squema original é preservado, portanto todas as operações OLAP não temporais continuam aplicáveis;

v2 – É possível manter o histórico integral dos atributos de interesse;

v3 - Os domínios dos atributos De e Até, sendo compatíveis com o domínio da chave da dimensão Tempo, permitem:

- fazer junção direta de tabelas históricas com a tabela de fatos (junção de HistóricoGerente e Vendas, com De θ Tempo# e/ou Até θ Tempo#). Isso é particularmente relevante porque as junções mais onerosas no esquema em estrela são aquelas feitas com as tabelas de fatos [Kimball 98], que geralmente são enormes;

- tornar iguais as granularidades de tempo das tabelas históricas e a granularidade de tempo da tabela de fatos (ou seja, a granularidade do DW continua sendo regida pela semântica da dimensão Tempo);

v4 - as tabelas históricas, como projetadas, são compatíveis com aquelas de modelos relacionais temporais formalmente definidos [Navathe&Ahmed 87] [Natvathe&Ahmed 93] [Lorentzos 93];

v5 - a transformação de um DW não temporal em um DW com um esquema MET* é bastante simples;

v6 - as versões de registros de dimensões são restritas aos atributos que mudam com o tempo, evitamos assim dados redundantes como encontrado em outras propostas.

A Figura 5.6 contém um exemplo de tabela de histórico para guardar o histórico do atributo Gerente da dimensão Loja.