{sharethis}
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:
- Quais são as aquisições de serviços feitas num determinado intervalo de tempo?
- Será que a viagem alfa se realizou neste intervalo de tempo?
- 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:
- Quais são as aquisições de serviços na área de engenharia num determinado intervalo de tempo?
- Qual foi o último trabalho como engenheiro de um funcionário num certo espaço temporal?
- 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:
- 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.
- 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.
- 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?”.
The following two tabs change content below.
Carlos Pampulim Caldeira
Professor Auxiliar | Assistant Professor at Universidade de Évora
Latest posts by Carlos Pampulim Caldeira (see all)
- Protocolo de Entrega de Trabalhos de IPAI - 21/01/2022
- Design e Tuning - 29/11/2021
- Fase 2 – Dicionário DDL - 25/10/2021