Olá pessoal, como estão?!

No post de hoje quero compartilhar com vocês as duas últimas dimensões do meu data warehouse, que são:

  • Dimensão Cliente
  • Dimensão Data

Estas são as duas últimas pois são as que apresentam algo novo para tratar aqui, evitando assim, a repetição. 

Dito isso, começarei pela dimensão Data, que é a mais simples e depois veremos a dimensão cliente.

CRIANDO A DIMENSÃO DATA E O CONCEITO DE ROLEPLAY DIMENSION

Há muitos posts atrás, quando criei a minha dimensão data no banco stage (aqui), eu disse que tinha retirado a base do site do Kimball, utilizando o arquivo Excel como base.

Depois de carregar este arquivo para a stage,  o que precisei fazer foi extrair desta área e criar um arquivo csv que iria alimentar o DW.

Aqui nós temos um esquema simples de criação da dimensão, e como disse, utilizando o arquivo XLS como fonte. Repare no step de input.

Até aqui, a única ação que precisei foi de renomear as colunas e ajustar os data types. Se perceber, os nomes estão fora do padrão para um banco de dados e mais, manter os tipos de dados corretos evita erros na transformação e carga.

Feito a carga, posso utilizar como fonte o arquivo csv gerado ao final desta transformação para carregar minha dimensão no Data Warehouse.

CONCEITO DE ROLEPLAY DIMENSION

Antes de entrar no conceito, quero deixar claro que esse recurso é feito com views e não do modo que fiz aqui. 

As roleplay dimensions são dimensões que são criadas a partir da dimensão original, mas que possuem um papel mais específico no data warehouse. Este recurso é muito comum com as dimensões de Data, agregando ainda mais na qualidade das análises.

Neste exemplo, criei uma roleplay para DeliveryDate, pois futuramente, quero analisar como estão as entregas dos produtos.

Destacado em vermelho está o  trecho que crio a roleplay. Perceba que vem da fonte primária, que é a tabela Dimensão Data, da minha área de stage.

Assim como na stage, o processo foi bem simples e precisei apenas corrigir os datatypes antes de carregar no DW e para minha roleplay, apenas alterei o nome da coluna e adicionei o WAIT para não ocasionar lock no processo.

Aqui está a alteração do nome da coluna que irá receber a surrogate key.

E aqui, a criação da roleplay física, de forma resumida.

Utilizei o step insert/update para teste, neste caso, poderia ser o Table Output, não teria problema.

E aqui, o esquema final do job que carrega a dimensão Data no data warehouse.

DIMENSÃO CLIENTE

A dimensão cliente foi uma dimensão peculiar por precisar lidar com arquivo XML que estava armazenado no banco.

Como mostrei aqui, quando criei a dimensão na stage, precisei extrair dados deste formato para enriquecer a dimensão e por consequência, as análises. 

Outro aspecto que preciso ressaltar é que diferente das outras, precisei acessar diretamente o banco para extrair os dados, não utilizando batchs.  Como já mostrei o processo de extração para a stage, vamos direto para o warehouse.

O processo de limpeza não foi de grande dificuldade, a parte mais repetitiva que me deparei foi quando precisei normalizar o endereço dos clientes, por ter muita abreviação.

Irei separar o processo por partes para exemplificar melhor.

Nesta primeira parte, eu normalizo as colunas que apresentam os ganhos, sexo, estado civil, endereço e etc.

Faço uso do replace string para substituir os valores inconformes das colunas.

Uma situação que não recomendo é quanto ao uso do concat fields para unir as colunas de Nome e Endereço como fiz. Se puder, evite; o resultado não é ‘agradável’.

Para a coluna YearlyIncome, precisei dividi-la em 3. Como possuía os valores mínimos e máximos agrupados e separados pelo travessão, precisei quebrá-la em múltiplas.

Utilizando o split field, veja como ficou.

E para criar as colunas YearlyMin e Max, bastou separar a YearlyIncome1, em duas, utilizando novamente o travessão como delimitador e, substitua o 0 da coluna YearlyIncomeMax pela coluna 3 utilizando o replace string.

Na segunda etapa, parti para normalizar o Nome, Endereço, e calcular a idade dos clientes. Em vermelho, replace string para substituir os valores mencionados anteriormente.

Para calcular a idade basta utilizar  a transformação  formula  e digitar a fórmula now(), captura o dia, data e hora do sistema. Não esqueça de atribuir o data type.

Para o endereço, novamente o replace, mas desta vez, repetindo inúmeras vezes até padronizar a coluna. Esta foi de fato a parte mais chata.

Precisei de dois steps deste para concluir a tarefa, postei este mais resumido para não ficar muito extenso. Quando terminar este portfólio, posto as transformações por completo.

Abaixo, o uso do calculator para obter a idade dos clientes utilizando a coluna BirthDate e a coluna Today, obtida pela transformação formula.

Demonstração da coluna Age.

Finalizando com a terceira etapa da transformação e preparando para a carga final, realizo um lookup no arquivo txt da futura tabela fato, pareando as colunas CustomerID, para verificar se existe algum cliente sem compra. 

O processo está destacado em vermelho e utilizei o stream lookup.

Utilizei o filter rows para caso a coluna Inativos gerada pelo stream lookup retorne NULL, ele irá mandar para um dummy.

Realizando uma breve execução, veja que não há cliente inativo.

Como mesmo após o tratamento, algumas colunas ainda possuíam muitos valores nulos, utilizei a transformação If field value is null, baseando sua substituição nos data types.

Por fim, os dados foram devidamente carregados e o csv final, criado.

Veja a consulta no banco, na tabela DimCliente. Resumida.

CONTROLE DE MUDANÇAS – BREVE RESUMO

Sabendo da importância da dimensão cliente e da quantidade de insights que ela gera, é importante ter um controle apurado da tabela, claro, por ser uma dimensão que pode crescer bastante dependendo do negócio, o controle histórico deve ser bem criterioso.

Sabendo disso, assim como a dimensão Produto (aqui e aqui) e Vendedor (aqui e aqui) criei o mesmo modelo de controle de mudanças, o controle híbrido. Acessem na ordem para entender o ‘histórico’.

Não irei postar todo o processo aqui pois se tornaria repetitivo, peço que revejam estes quatro passos que explicam todo o processo que passei até chegar ao final dele. Está bem pavimentado.

Por fim, este é o meu job de tratamento para a dimensão cliente.

CONCLUSÃO

Concluo aqui o post sobre as dimensões Data e Cliente para o meu portfólio.

O processo de criação foi até bem simples e não houve grandes complexidades, a pior parte foi normalizar o endereço dos clientes.

Tomem cuidado com certas colunas que são do tipo string, em algumas situações de comparação, elas podem acabar acusando diferença e isso compromete por exemplo, o controle de mudanças. Farei um post sobre isso em breve.

No mais, espero que os ajudem e clarifique as questões!

Deus os abençoe e saúde.