Dimensão de hora e data no data warehouse

Question

Estou construindo um data warehouse. Cada fato tem que timestamp. Preciso criar relatórios por dia, mês, trimestre, mas por horas também. Olhando para os exemplos que vejo que as datas tendem a ser salvas em tabelas de dimensão.
_{(fonte: etl-tools.info)}

Mas acho que isso não faz sentido para o tempo. A tabela de dimensão cresceria e cresceria. Por outro lado, se unir à tabela de dimensão de data é mais eficiente do que usar as funções de data/hora SQL.

Quais são suas opiniões/soluções?

(Estou usando o InfoBright)

Answer 1

Meu palpite é que isso depende do seu requisito de relatório. Se você precisa de algo como

WHERE "Hour" = 10

Significando todos os dias entre 10:00:00 e 10:59:59, então eu usaria a dimensão do tempo, porque é mais rápido do que

WHERE date_part('hour', TimeStamp) = 10  

Porque a função date_part () será avaliada para cada linha. Você ainda deve manter o carimbo de data / hora na tabela de fatos para agregar os limites dos dias, como em:

WHERE TimeStamp between '2010-03-22 23:30' and '2010-03-23 11:15' 

o que fica estranho ao usar campos de dimensão.

Geralmente, a dimensão do tempo tem uma resolução minuciosa, então 1440 linhas.

Answer 2

Kimball recomenda ter dimensões separadas de tempo e data:

T-TIP-TIP-51-LATEST-PINCULING-ON-TIMENENSENSENSENSENSENÇÃO

Nos livros anteriores do Toolkit, recomendamos a construção de uma dimensão com os minutos ou segundos componente do tempo como compensação a partir da meia -noite de cada dia, mas percebemos que os aplicativos de usuário final resultantes se tornaram muito difíceis, especialmente ao tentar calcular a computação há mais tempo. Além disso, diferentemente da dimensão do dia do calendário, existem muito poucos atributos descritivos para o minuto ou o segundo específico em um dia. Se a empresa tiver atributos bem definidos para fatias de tempo dentro de um dia, como nomes de turnos ou slots de tempo de publicidade, uma dimensão adicional da hora do dia pode ser adicionada ao design em que essa dimensão é definida como o número de minutos (ou até segundos) depois da meia -noite. Assim, essa dimensão do horário do dia teria 1440 registros se os grãos fossem minutos ou 86.400 registros se os grãos fossem segundos.

Answer 3

O tempo deve ser uma dimensão nos data warehouses, pois você frequentemente deseja agregar sobre isso. Você poderia usar o Snowflake-Schema Para reduzir a sobrecarga. Em geral, como apontei no meu comentário, as horas parecem uma resolução incomumente alta. Se você insistir neles, tornando a hora do dia uma dimensão separada pode ajudar, mas não posso dizer se isso é um bom design.

Answer 4

Eu recomendaria ter uma dimensão separada para data e hora. A dimensão da data teria 1 registro para cada data como parte da faixa válida identificada de datas. Por exemplo: 01/01/1980 a 31/12/2025.

E uma dimensão separada para o tempo com 86400 registros, cada segundo ter um registro identificado pela chave do tempo.

Nos registros de fato, onde você precisa de data e hora, adicione as duas teclas com referências a essas dimensões conformadas.