O que é um star schema, e quando você normalizaria uma dimensão em snowflake?

Um star schema tem uma tabela fato cercada por tabelas de dimensão desnormalizadas, então a maioria das consultas precisa de um join por dimensão. O snowflake normaliza uma dimensão em subtabelas, o que economiza armazenamento e centraliza atributos compartilhados, mas adiciona joins. Em um warehouse colunar, armazenamento é barato e joins custam mais do que duplicação, então star é o padrão. Use snowflake quando a dimensão é realmente grande, hierárquica ou compartilhada por muitos marts.

Um star é uma tabela fato em uma granularidade definida com dimensões desnormalizadas penduradas nela, então o analista escreve um join por dimensão e recebe nomes de coluna legíveis. Eu adoto isso como padrão, porque em um warehouse colunar repetir o nome de um país em dois milhões de linhas comprime para quase nada, e a dimensão pequena vai por broadcast de qualquer jeito. O snowflake faz sentido quando a dimensão é de fato grande e hierárquica, por exemplo uma dimensão de produto com uma árvore de categorias que vários marts precisam compartilhar, já que manter essa hierarquia em um lugar só é melhor do que duplicá-la em cinco. O ponto que eu levantaria antes dos dois é a granularidade. Decidir que a tabela fato tem uma linha por item de pedido em vez de por pedido determina tudo o que vem depois, e errar isso é o que produz o clássico bug de receita contada em dobro. Eu já tive que reconstruir um mart porque a granularidade estava misturada, e isso é muito mais caro do que qualquer debate sobre normalização.