Olá pessoal, como estão?!

No ultimo post mostrei as duas últimas dimensões que julguei serem importantes para estarem aqui.

No post de hoje, quero iniciar uma pequena série de posts sobre a tabela fato e como podemos desmembra-la em outras que podem agregar ainda mais ao negócio. 

Deixo claro que o primeiro post será sobre o que chamei de tabela fato central, o lookup das chaves e sua carga no data warehouse. Nos próximos, veremos os outros tipos.

TABELA FATO – TRATAMENTO

Sei que tratar dados na tabela fato pode soar um pouco estranho, pois espera-se que esta tabela não possua dados inconformes, porém, como peguei uma fonte de dados um pouco comprometida, alguns tratamentos foram necessários.

Além desta situação, quero mostrar para vocês algo que pode acontecer quando extraímos dados do banco por comando de batch ou, se por algum motivo, tal coluna perde a configuração correta.

Uma situação que me ocorreu quando comecei a criar a fato, foi que as colunas de datas perderam a configuração aceita, causando conflito.

Veja na imagem, quando criei meu arquivo TXT que será transformado e carregado no warehouse.

Essa situação se repete na tabela do banco stage.

Veja que o mês nas colunas de data vieram com o nome extenso e não como estamos acostumados, trabalhando com o formato numérico. Eu não acredito que seja problemático trabalhar nesse formato, mas prefiro o modelo tradicional.

Não basta apenas modificar o formato com select values ou nas configurações na aba Fields, veja que a configuração está correta, mas ainda assim, os dados foram carregados daquela forma. Acredito que tenha sido a query de extração utilizada na batch.

Para corrigir esta situação, criei uma transformação para tratar deste problema e remover quaisquer nulos no fato.

Aqui está a transformação base.

O primeiro passo foi dividir os campos de data, começando pela coluna Orderdate utilizando o Split Field.

O delimitador não está em branco, há um carácter ali, o espaço. Por isso ele está vazio, pois é o limitador.

Aqui, temos a coluna Orderdate dividida em três, uma para dia, mês e ano.

Dividindo a coluna, fica mais fácil ajustar os valores pelo correto. Basta utilizar o value mapper para a coluna OMNTH substituindo cada mês extenso pelo seu devido número.

E o resultado da execução com o concat field, unindo os três novos campos em apenas um.

Basta repetir o mesmo processo para as outras colunas de datas que se encontram nesta situação e seu problema estará corrigido.

SUBSTITUINDO O ID PELAS CHAVES DAS DIMENSÕES – PIPELINE DE LOOKUPS

Ajustamos as colunas de data da tabela fato e agora, antes da primeira carga, precisamos substituir as colunas de ID’s, que vieram do OLTP, pelas surrogate Keys.

Existem algumas transformações no Pentaho que podem realizar esta operação com certa facilidade até, pretendo explorar outras formas em futuros posts. Para este exemplo, irei mostrar como utilizar o stream lookup.

Como sabemos, o stream lookup busca ou compara um determinado valor baseado em duas colunas chaves, as lookup  Keys. O único problema é que aqui só podemos lidar com uma coluna por stream lookup, por isso, a quantidade de transformação.

Todos os lookups estão sublinhados de vermelho e os que não estão, são as fontes de dados.

Quebrando a cadeia em parte menor para mostrar a configuração, utilizarei como exemplo a substituição da coluna SalesPersonID pela SalesPKey.

O lookup do Produto está na imagem apenas para mostrar que as transformações stream lookup estão ligadas umas as outras, isso me permite utilizar apenas uma única fonte do arquivo da minha tabela Fato, enquanto posso buscar e igualar diversas outras fontes sem precisar replicar a fonte.

  • Lookup Step (Marrom) – especifica onde será feito a busca, no caso, a fonte txt da dimensão vendedor.
  • Keys to lookup (vermelho) – igualamos as duas colunas a fim de saber qual a sua surrogate key na dimensão.
  • Fields to retrieve (roxo) – chave surrogada da dimensão que irá para a tabela fato.

Novamente, basta repetir este mesmo processo por todas as dimensões que desejar ligar na sua tabela fato e após carregar.

Para a dimensão data, o processo é similar, apenas garanta que as colunas possuam o mesmo formato.

Para eliminar as colunas de ID do seu banco relacional, basta utilizar a aba Remove do select values, colocando tais colunas lá. Certifique-se que estas colunas não estarão na aba Metadata.

Ao finalizar o desenvolvimento da estrutura, utilize o table output para carregar os dados na fato. É mais rápido do que utilizar dimension lookup/update.

Uma dica para vocês aplicarem na stream lookup é desmarcar essa caixa de diálogo. Com ela desmarcada, terá um maior custo de cpu, mas, será mais rápido.

Realizando uma breve consulta na tabela fato, a carga foi executada com sucesso.

CONCLUSÃO

Este foi o primeiro post para implementação da tabela fato e ao final, implementamos a primeira tabela.

No meu modelo, eu criei uma tabela fato que eu chamo de central e dela irei originar outras menores e mais pontuais; quero testar estas opções.

Como disse no início do post, existem formas de se implementar uma fato, neste exemplo, utilizei o stream lookup e achei que foi bem rápido, mas irei testar outros modelos para averiguar o funcionamento.

No mais, até que foi bem simples criar e carregar. Confesso que achei que fosse mais difícil! 

Espero que gostem, saúde!