tipos de dimensões

Data Warehouse – Tipos de dimensões

Existem 5 tipos de dimensões que você precisa conhecer e entender como funcionam para conseguir entrar para o time dos Data Warehouse Designers.

São elas:

  • Degenerate Dimension
  • Slowly changing dimension
  • Role-playing dimension
  • Conformed dimension
  • Junk dimension
  • Bônus

 

Degenerate Dimension

É a dimensão que não mereceu ser uma dimensão e foi inserida como coluna na fato. Quando a gente vai definir uma dimensão, existem algumas perguntas que fazemos.

Imagina uma fato venda em que a pessoa quer ver o código da transação da compra.

Às vezes você precisa ter aquela informação ali para fazer um filtro. Quando é algo desse tipo, que não dá para criar uma dimensão, você faz uma degenerada.

Pensa, você vai criar uma dimensão de transação. O que vai ter nela? O código da transação, talvez um nome da transação, se for ser a transação de uma vendedora ou de um produto, aí já são outras dimensões.

Nesse caso você só quer pôr aquele número porque o usuário precisa dele por algum motivo.

E se não vai criar uma dimensão para isso, vai colocar onde? Muitas vezes isso entra na fato transacional. A fato venda, com a qual você está trabalhando, é transacional, você coloca todas as transações linha por linha.

E onde vai isso? Basicamente, você vai na fato e cria uma coluna. Eu costumo marcar quando é dimensão degenerada, por exemplo: “código transação (DD)”.

 

Slowly changing dimension (SCD)

De uma forma resumida e bem direto ao ponto, é uma técnica para atualizar a dimensão. Tem um nome todo pomposo, mas é como você vai atualizar a dimensão.

Todas as dimensões são SCD, porque elas vão precisar atualizar para se manterem sincronizadas com o transacional.

A única exceção é a dimensão de tempo, que a gente chama de tipo 0, porque depois que os dados foram inseridos, não precisa mais atualizar.

Vou mostrar os 2 tipos mais utilizados da vida real. Se você for olhar aí na literatura tem até 6 tipos, mas ninguém usa.

 

Tipo 1

Nesse exemplo, tem a tabela de clientes da origem e a dimensão de cliente, com os mesmos dados nas duas.

Depois, a cidade foi alterada na tabela de clientes.

Na dimensão, quando é SCD tipo 1, ela atualiza também mantendo igual ao original e com a mesma Surrogate Key.

 

Tipo 2

Essa, além de todas as colunas igual a anterior, tem 3 a mais, que é a data de início, data de fim e uma flag que indica se está ativo ou não, para controlar o registro.

A função disso é poder armazenar histórico.

Então toda alteração que acontece é inserida em uma nova linha e essas 3 colunas são usadas para controlar as alterações.

Por exemplo:

Na data de início, é colocada a data em que foi feita a inserção, na data de fim você coloca 01/01/1900 porque não existe ainda, e na flag indica que está ativo.

Aí a mesma coisa de antes, mudou o endereço na tabela cliente, e na hora de atualizar a dimensão, como ela era tipo 2, insere uma nova linha com uma nova Surrogate Key e os novos dados.

Depois disso, ela atualiza a linha anterior, colocando a data de fim e desativando a flag de ativo.

Ou seja, a data inicial dessa nova linha vira a data final da anterior.

Agora você consegue filtrar a cidade atual onde o cliente mora, mas também tem o histórico de todas as atualizações que foram feitas.

Para que serve isso?

Imagina que enquanto eu morava em Porto Alegre, gastava R$100,00 de café por mês. Aí eu vou morar em Florianópolis. Se a dimensão for do tipo 1, vai atualizar com a mesma Surrogate Key e todas as compras que eu fiz vão ser transferidas para a loja de Florianópolis, vai aparecer para eles que eu gastava R$100,00 lá todo mês, e isso não é verdade, eu gastei em Porto Alegre. Isso afeta muito quando tem metas de vendas, por exemplo.

Mas é importante você ficar ligado que essas alterações impactam na carga. No momento que você fez todo esse trabalho, aumentou a complexidade da carga.

Tem ferramentas, como Pentaho e ODI, que controlam essa questão do SCD, mas algumas não fazem isso, e o próprio ETL vai ter que controlar de alguma forma.

 

Role-playing dimension

No Data Warehouse, as dimensões muitas vezes são utilizadas para múltiplos objetivos.

Como assim? Quando você quer fazer uma análise de vendas e nessa análise precisa mensurar quantidade vendida, você quer ver essa quantidade pela data do pedido, pela data do envio do pedido e pela data do recebimento do pedido.

Quando acontece essa situação, nós precisamos ter as Surrogate Keys na fato para que você possa analisar de forma separada.

Em muitos casos, quando as pessoas não entendem de modelagem dimensional, copiam a dimensão de tempo 3x.

Então ela repete lá, data do pedido, data do recebimento do pedido e data do envio do pedido. Você até pode ter essa visão lógica do Data Warehouse, mas fisicamente, isso não precisa existir, porque você vai deixar seu Data Warehouse 3x maior.

Nesse caso, você só precisa referenciar a mesma dimensão de tempo 3x na fato, assim:

Conformed dimension

É uma dimensão que tem o mesmo significado para todas as fatos com que se relaciona. Uma boa prática é deixar todas as dimensões conformadas. Quem bate muito nessa tecla é o próprio Ralph Kimball.

Por quê?

Porque assim todo mundo fala a mesma língua, uma dimensão conformada nada mais é que: as fatos e métricas classificadas e descritas da mesma forma em toda a empresa, ou seja, a verdade única.

Quando falamos de um Data Warehouse corporativo, você tem uma dimensão relacionando com mais de uma fato, e dimensão conformada é quando essa dimensão tem todos os dados que as duas precisam.

 

Junk dimension

A junk dimension normalmente é esquecida e não é ensinada em quase nenhum curso. Eu e alguns outros especialistas em DW dizemos que o nome dessa dimensão ficou um pouco errado, porque quando você fala em dimensão de lixo, tem a impressão de que são coisas que não prestam mais.

Vou usar como exemplo um dos projetos que participei, onde a consultoria anterior fez um Star Schema para o cliente.

Eles criaram uma fato colaborador e várias dimensões de tipos, como tipo de remuneração, tipo de contrato, tipo disso, tipo daquilo, e mais dezenas (sim, mais de 40) de outras dimensões de tipos.

O problema é que essas dimensões de tipo, pensando fisicamente em um banco de dados, poderiam ser junk dimensions.

Não é a única forma de fazer, mas é bom para quando você tem uma característica de dimensões com a cardinalidade muito baixa ou com a densidade muito esparsa.

O que isso quer dizer? Que essas dimensões têm basicamente 3 colunas, a Surrogate Key e a Natural Key e uma descrição.

Se usasse a técnica de junk dimension, você teria somente 1 dimensão com essas 3 colunas, e colocaria todas as dezenas de tipos nela, eliminando aquele monte de dimensão que tinha antes.

Mas é importante você entender que essa solução aqui é para quando não tem onde colocar as coisas.

 

Bônus

Hierarquia de Dimensões

Basicamente, é uma forma hierárquica de organizar os dados nas dimensões.  

Existem vário tipos, e hoje, vou apresentar a hierarquia chamada pai-filho, que é a mais conhecida no mercado.

Qual a ideia? Como o próprio nome já diz, é uma hierarquia que tem um pai e um filho. Ela não precisa ter só dois níveis, é claro.

Alguns exemplos de hierarquia para você entender:

  • ano, mês e dia
  • categoria, subcategoria e produto
  • capitão, sargento, cabo e soldado
  • avô, pai e filho

hierarquia

É comum existir apenas uma hierarquia por dimensão, mas não é erro ter duas na mesma. Trabalhei em um projeto (da Sodexo) onde o time de logística olhava o produto de uma forma e o de planejamento de outra, e foi preciso criar duas hierarquias para cada um analisar da forma que precisava.

O menor nível da hierarquia é o grão, onde é armazenado o dado. Então olhando a imagem de exemplo, as cinco cabecinhas de baixo na imagem acima são chamadas de grão ou de nível zero.

A contagem de níveis começa no zero e vai subindo. Então os cinco de baixo são o nível zero, os três de cima são o nível um e o bem de cima, o nível dois.

Você pode ver mais sobre o que é o grão no post onde explico sobre Star Schema.

Tenho aqui o exemplo de uma dimensão de produto:

dimensão hierarquica

Como que essa hierarquia é construída?

Basicamente, a gente tem o código e nome da categoria, o código e nome da subcategoria, e então o código e nome do produto.

Ali no lado do exemplo tem uma tabela explicando a hierarquia:

  • nível zero = produto
  • nível um = subcategoria
  • nível dois = categoria

Mas como eu cheguei nesses dados?

Em todo sistema transacional que eu já vi, quando existe a necessidade de uma hierarquia, ela está lá. O que nós estamos fazendo aqui é a desnormalização dos dados.

Nesse caso, a categoria era uma tabela no transacional, a subcategoria era outra e o produto também.

Mas e quando tem um cliente que quer hierarquia e não tem ela no legado? Pode deixar para ele arrumar isso no transacional ou você cria uma nova hierarquia no Data Warehouse, lá na parte de ETL. De qualquer forma, não vai interferir em nada aqui.

A gente não insere dados na subcategoria porque o nosso grão é o produto, então quando precisar analisar a quantidade de venda da subcategoria, é só somar a quantidade de vendas de todos os produtos pertencentes àquela subcategoria.

É importante você entender esse conceito porque é muito comum o cliente querer esse tipo de hierarquia para poder ir descendo ou subindo o nível da informação, que é o que chamamos de drill down e drill up. Assim você pode ter uma visualização por ano e fazer um drill down, tendo a visualização por mês e depois por dia.

 

Esses são os tipos fundamentais de dimensões que você precisa entender. Saber as características de cada uma e entender quando devem ser utilizadas é primordial para você se tornar um especialista em BI/DW.

 

Ah, e se quiser que eu te avise dos novos posts conforme eles forem saindo, é só deixar seu e-mail abaixo!

 

Deixe um comentário 🙂

Leia também:

mautic is open source marketing automation