SCD no Looker: Mantenha seus dados históricos no controle

O mundo dos negócios está sempre em movimento. Clientes mudam de endereço, produtos ganham novas características e a estrutura das empresas evolui. Para quem trabalha com análise de dados, capturar essas mudanças de forma precisa é fundamental. É aí que entram as Slowly Changing Dimensions (SCDs), que ajudam a manter o contexto histórico nos seus relatórios, mostrando o que era verdade em cada momento, e não apenas o que é atual.

Modelar SCDs corretamente no Looker garante que analistas e usuários de negócio obtenham insights confiáveis, mesmo com as frequentes alterações nos dados. Este artigo vai te explicar o que são SCDs, por que elas são tão importantes e como implementá-las de forma eficiente usando o LookML.

Entendendo as Slowly Changing Dimensions (SCDs)

SCDs são tabelas de dimensão cujos valores mudam ocasionalmente, mas não de forma contínua. Pense em:

• Um cliente que atualiza seu e-mail ou endereço.
• A categoria de um produto que é modificada.
• Um vendedor que é realocado para outra região.

É essencial que essas mudanças sejam registradas de um jeito que preserve o histórico. Sem isso, seus relatórios podem apresentar resultados inconsistentes ou até enganosos.

Os Tipos de SCDs Mais Comuns

No universo do data warehouse, três tipos de SCDs se destacam:

• Tipo 1: Sobrescrever o Valor Antigo - O novo dado simplesmente substitui o antigo, sem guardar nenhum histórico. É útil quando as mudanças passadas não importam.
• Tipo 2: Criar um Novo Registro - Cada alteração gera uma nova linha na tabela. Geralmente envolve campos como chave substituta, chave de negócio, data de início de validade, data de fim de validade e um indicador de registro atual. É o tipo mais usado para manter o histórico completo e confiável.
• Tipo 3: Guardar Histórico Limitado - Uma nova coluna é adicionada para armazenar o valor anterior. Funciona bem para rastrear apenas algumas poucas mudanças históricas.

Entre esses, o Tipo 2 é o campeão de uso em análise, pois oferece um histórico temporal completo e preciso.

Por que Modelar SCDs no Looker é Crucial

O Looker depende diretamente do modelo dimensional do seu data warehouse. Quando as SCDs são modeladas do jeito certo:

• Relatórios históricos continuam precisos.
• Análises baseadas em tempo se tornam confiáveis.
• Explorações e drill-downs funcionam de maneira consistente.
• Junções entre tabelas de fato e dimensão são previsíveis.

Erros na modelagem de SCDs podem levar a contagens duplicadas, perda de histórico ou junções desalinhadas, comprometendo a qualidade dos seus insights.

Como Implementar SCDs no Looker

O Looker não cria a lógica de SCD por si só. Ele se baseia na forma como você modela suas SCDs no banco de dados e, em seguida, configura o LookML para utilizá-las corretamente. A abordagem de modelagem no LookML vai depender do tipo de SCD que você escolheu implementar no seu schema.

Modelando SCD Tipo 2 no LookML

Como o Tipo 2 é o mais comum, o Looker oferece um jeito elegante de lidar com ele, utilizando a chave primária e a lógica de junção adequada. Um registro TIPO 2 normalmente inclui campos como:

• dimension_key (chave substituta)
• business_key
• effective_start_date
• effective_end_date
• is_current flag

Exemplo: Dimensão de Cliente Tipo 2

Uma estrutura de tabela de exemplo pode ser:

customer_key (PK)
customer_id
customer_name
customer_city
effective_start_date
effective_end_date
is_current

No LookML:

view: customer_dim {
  primary_key: customer_key
  dimension: customer_id { type: number }
  dimension: customer_name { type: string }
  dimension: customer_city { type: string }
  dimension_group: effective_period {
    type: time
    timeframes: [raw, date]
    sql_start: ${TABLE}.effective_start_date ;;
    sql_end: ${TABLE}.effective_end_date ;;
  }
  dimension: is_current { type: yesno }
}

Isso garante que cada versão de um cliente seja tratada como uma linha separada.

Junção com Dados de Fato

Sua tabela de fatos geralmente armazena a chave substituta da dimensão:

explore: orders {
  join: customer_dim {
    relationship: many_to_one
    sql_on: ${orders.customer_key} = ${customer_dim.customer_key} ;;
  }
}

Dessa forma, cada pedido é associado aos atributos do cliente que estavam válidos naquele momento específico.

Junção por Chave de Negócio e Data

Em alguns casos, a tabela de fatos não contém a chave substituta. Você pode então usar a chave de negócio e a data do pedido para encontrar o registro correto na dimensão:

join: customer_dim {
  relationship: many_to_one
  sql_on: ${orders.customer_id} = ${customer_dim.customer_id}
    AND ${orders.order_date} >= ${customer_dim.effective_start_date}
    AND ${orders.order_date} < ${customer_dim.effective_end_date} ;;
}

Essa abordagem pode ser mais lenta, mas assegura o mapeamento histórico correto.

Modelando SCD Tipo 1 no LookML

O Tipo 1 é bem direto, pois a dimensão contém apenas os valores mais recentes. Modele-o como qualquer outra tabela de dimensão padrão:

view: product_dim {
  primary_key: product_id
  dimension: product_name { type: string }
  dimension: product_category { type: string }
}

A junção com a tabela de fatos é simples.

Modelando SCD Tipo 3 no LookML

O Tipo 3 guarda o valor atual e um valor anterior. O LookML trata isso como qualquer outra coluna, sem precisar de lógica especial.

Exemplo de colunas:

• current_category
• previous_category

Boas Práticas para Modelagem de SCDs no Looker

1. Prefira SCDs Tipo 2 para Relatórios Precisos: As mudanças históricas importam na maioria das análises de negócio.
2. Sempre Use Chaves Substitutas em Tabelas de Fato: Isso garante junções limpas e rápidas.
3. Garanta que os Intervalos de Datas de Validade Não se Sobreponham: Sobreposições quebram as junções históricas.
4. Indexe Colunas de Data de Validade: Melhora o desempenho das junções baseadas em datas.
5. Use Datagroups e PDTs Apenas Quando Necessário: Deixe seu banco de dados cuidar das transformações de SCD sempre que possível.

Erros Comuns a Evitar

• Usar chaves de negócio em vez de chaves substitutas para junções Tipo 2.
• Permitir datas de validade sobrepostas.
• Esquecer de definir uma chave primária no LookML.
• Juntar apenas com registros atuais, perdendo a precisão histórica.
• Modelar SCDs dentro do Looker em vez de no banco de dados.

Esses deslizes podem levar a contagens infladas ou a um histórico inconsistente.

Exemplo de Caso de Uso

Imagine que um cliente mudou de cidade em maio. Com uma SCD Tipo 2:

• Pedidos feitos antes de maio mostrarão a cidade antiga.
• Pedidos feitos depois de maio mostrarão a nova cidade.

Seus relatórios de vendas permanecerão historicamente corretos, exatamente como as equipes de negócio esperam.

Conclusão

As Slowly Changing Dimensions são essenciais para manter a precisão histórica nas suas análises. O Looker depende do design de SCDs do seu banco de dados, então modelá-las corretamente tanto no schema quanto no LookML garante junções eficientes, relatórios consistentes e análises de tendências confiáveis. As SCDs Tipo 2 são as mais valiosas para construir uma camada analítica robusta, pois preservam o histórico completo e se alinham perfeitamente com a abordagem de modelagem semântica do Looker. Quando feitas da maneira certa, a modelagem de SCDs fortalece a qualidade e a confiabilidade do seu ambiente de BI.