Dimensões que mudam lentamente: sobrescrever, adicionar uma linha ou adicionar uma coluna

O que é

Os atributos de dimensão mudam de forma lenta e irregular, e um data warehouse precisa decidir se um fato registrado no ano passado deve ser reportado com o valor do atributo do ano passado ou com o de hoje. As páginas de técnicas do Kimball Group (citadas) definem as respostas básicas. Tipo 1: o valor antigo do atributo na linha da dimensão é sobrescrito pelo novo, de modo que o atributo sempre reflete a atribuição mais recente e o histórico é destruído; agregados construídos sobre o valor antigo precisam ser recalculados. Tipo 2: uma nova linha de dimensão é adicionada com os valores atualizados e uma nova chave primária substituta (surrogate key), à qual as linhas de fatos passam a se referir a partir do momento da mudança; a página exige pelo menos três colunas extras: data de início de vigência da linha, data de expiração da linha e um indicador de linha atual. O tipo 3 adiciona um atributo que preserva o valor antigo enquanto o atributo principal é sobrescrito, de modo que os relatórios podem agrupar tanto pelo valor atual quanto pelo antigo; a página descreve essa técnica como usada com relativa pouca frequência. Os snapshots do dbt (citados) implementam o tipo 2 sobre tabelas de origem mutáveis, adicionando dbt_valid_from e dbt_valid_to a cada versão; a estratégia timestamp detecta mudanças por meio de uma coluna updated_at, a estratégia check, comparando uma lista de colunas, e uma configuração define se as linhas excluídas na origem são ignoradas, invalidadas ou registradas como uma nova versão.

Por que importa

Sem uma política definida, o mesmo relatório dá respostas diferentes dependendo de quando é executado, e ninguém consegue dizer se "vendas por região" usa a região do cliente no momento da compra ou a atual. O tipo 2 responde às duas perguntas, mas multiplica as linhas da dimensão e exige que toda carga de fatos busque a chave substituta válida no momento do evento.

Como aplicar

• Decida por atributo, não por tabela: correções de erros de digitação são tipo 1; mudanças do mundo real que os relatórios precisam atribuir historicamente são tipo 2.
• Mantenha a chave natural em toda linha tipo 2 e crie um índice em (chave natural, valid_from) para consultas em um ponto no tempo (as-of); use de forma consistente um valor sentinela em aberto ou NULL para a linha atual, e documente qual dos dois.
• Execute os snapshots pelo menos com a mesma frequência do menor período de relatório; mudanças ocorridas entre dois snapshots se fundem em uma única versão.
• Carregue os fatos fazendo o join pela chave natural com o intervalo de validade que contém o timestamp do evento, e não com a linha atual.

Armadilhas

Mudanças de dimensão que chegam com atraso exigem refazer as chaves de fatos já carregados. O tipo 2 em atributos de alta rotatividade (como o último login) torna a dimensão maior que os fatos; mova esses atributos para a tabela de fatos ou para uma minidimensão separada.