Dimensão Temporal
A dimensão data é o exemplo clássico de uma tabela de dimensão empresarial com um tamanho gigantesco dado que está presente em todos os aspectos de um data warehouse. O desenho desta dimensão tem que ser devidamente avaliado de acordo com as utilizações previstas. As utilizações podem dividir-se em fáceis, moderadas e difíceis.
Fáceis
Se nos limitarmos a questões relativas a dias de per si e pusermos de lado os minutos e os segundos, as queries habituais neste caso poderão ser, por exemplo:
1.Quais são as aquisições de serviços feitas num determinado intervalo de tempo?
2. Será que a viagem alfa se realizou neste intervalo de tempo?
3. Os intervalos de tempo poderão ser definidos utilizando conceitos complexos de navegação temporal, incluindo estações do ano, períodos fiscais, dias em número ou feriados.
Para estes três exemplos é necessária uma única coluna do tipo timestamp na tabela de factos. No caso 1) a query terá que ir buscar todas as aquisições com um timestamp registado num intervalo de tempo definido pelo utilizador. Na segunda situação é seleccionado um timestamp de alfa que depois é comparado com um espaço de tempo. Para o último caso tem que obrigatoriamente utilizar-se à dimensão data que está ligada à tabela de factos por intermédio de uma chave estrangeira. Com esta ligação – básica e muito simples – é possível restringir uma data segundo um numeroso critério de descritores.
Em navegações complexas no calendário as queries tornam-se muito mais simples na presença de marcadores de inicio e de fim de período como, por exemplo, “último dia do período de Natal”. Neste caso o campo conterá um valor negativo em todos os dias exceptuando o último dia da época mencionada em que conterá uma anotação positiva. Estas marcas especiais permitem que períodos complexos dos processos de negócio sejam facilmente traduzidos em queries. Como é óbvio a utilização destes descritores implica que já não seja possível utilizar o timestamp da tabela de factos.
Moderadas
Um segundo grupo de queries temporal mais complexo inclui, por exemplo:
1. Quais são as aquisições de serviços na área de engenharia num determinado intervalo de tempo?
2. Qual foi o último trabalho como engenheiro de um funcionário num certo espaço temporal?
3. Qual é o balanço de eficiência de um processo energético num ponto temporal arbitrário?
Neste novo nível de dificuldade continuamos a assumir que os intervalos de tempo são balizados unicamente por dias. Apesar de continuar a ser possível responder aquelas questões utilizando uma única marca temporal, as queries resultantes são demasiado complexas e, consequentemente, pouco eficientes conduzindo a baixas performances das aplicações. Para responder à interrogação 3) é necessário o conjunto de todas as deficiências encontradas para a última ocorrência antes do desejado ponto temporal, o que em SQL tem que ser feito através de um sub-select embebido noutro mais geral. Além de lento é um procedimento que está em geral fora do alcance das ferramentas geradoras de código de SQL.
Para queries temporais de média e alta complexidade as aplicações poderão ser muito beneficiadas se cada linha da tabela de factos tiver associada um par de selos temporais, que indicam o início e o terminus do intervalo temporal em que ocorre uma transacção (caso das tabelas de factos de tipo transaccional) ou uma métrica agregada. A abstracção associada a este conceito é imaginar-se que uma ocorrência é um episódio com um valor constante num intervalo temporal.
A utilização de marcas temporais gémeas podem resolver as seguintes queries complexas:
1. Pesquisar quais são as aquisições em aberto com a data de início no ou antes do termo do intervalo temporal, e com a data final ocorrendo no ou após o início do período.
2. Procurar por uma única transacção com a data inicial no ou antes do fim do espaço temporal, e com a data final no ou após o término do tempo.
3. Pesquisa por uma única transacção com a data de início em ou antes de um ponto qualquer no tempo, e com a data de término em ou depois desse ponto arbitrário.
A maioria, se não todas, das queries temporais mais complexas podem ser resolvidas utilizando a cláusula between, dado que a sintaxe “value between two fields” é perfeitamente exequível. A maior desvantagem da utilização de marcas gémeas temporais é a necessidade de visitar duas vezes cada linha da tabela de factos: uma para registar a linha, e outra quando é possível fechar a data da transacção ou agregação. A ocorrência de valores not null na data de fim tem que ser devidamente acautelada para minimizar os erros no processamento da cláusula between: com o registo de uma data virtual localizada num futuro longínquo, ou utilizando uma sintaxe mais complexa no SQL.
Difíceis
Para resolver as situações mais complexas, como o registo de minutos e segundos, pode considerar-se a inclusão de quarto timestamps para cada linha da tabela de factos. Duas são campos sql-date vulgares que registam o detalhe pretendido, e as restantes são dias de calendário funcionando como chaves estrangeiras da dimensão data. Assim, é possível responder a pedidos temporais muito precisos, mas também a questões mais abrangentes como “Quais são as aquisições feitas no Dia de Natal?”.
