Olá pessoal, tudo bem!?!
Na semana passada eu estava com planos de criar uma série de posts sobre lookup e como ele funciona para atualizar o Data Warehouse. Acontece que por um acaso do destino, decidi desviar um pouco a rota e estudar os tipos de join que o Pentaho possui, até para aprender mais sobre a ferramenta. E não é que eu fiz certo!!
Aprendendo sobre Join e vendo as opções que o software possui nesse quesito, me deparei com um tipo que para mim é a base da série de posts sobre os lookups – funcionamento e ação.
A transformação que eu quero mostrar hoje se chama MergeRowsDiff e vocês verão como ela é a base do lookup e como podemos utilizá-la em nosso favor!
MERGEDIFF
Essa transformação age da seguinte forma: após receber duas fontes de dados iguais, suponha nesse caso, a área de staging e a área de produção, ela irá comparar linha por linha, dependendo da coluna que utilizamos, e verificar se um determinado valor foi:
- Deletado.
- Modificado ou;
- Novo.
No meu exemplo, exportei a tabela do banco AdventureWorks – ProductCategory por ter poucos dados e ficar mais fácil de mostrar na prática. Lembrando, é um post introdutório.
Resultado do meu export para um arquivo txt e utilizado como fonte no Pentaho. Essa é a fonte original.
Após esse export, criei uma cópia do arquivo e fiz uma modificação qualquer em alguns valores para efeito de comparação.
Adicionei as tarefas de sort normalmente, como pede o join, e adicionei o step MergeRowsDiff a transformação com a seguinte configuração, veja:
O campo flagfield será o campo que terá o status para cada linha. Repare que as comparações são pelas colunas: ProductCategoryID e Name.
Na próxima imagem, veja o resultado final.
Como podemos ver no resultado final da comparação realizada, o step classificou os valores de acordo com o tipo de modificação feita. Se forem no início da sessão poderão confirmar que este foi o campo que eu modifiquei!
DESTINANDO AS MUDANÇAS
Tendo esse resultado obtido, podemos utilizar outros dois steps para dar o devido destino aos registros que foram modificados.
O primeiro seria utilizando o filter rows, filtrando pela coluna flagfield. Criando as devidas condições, podemos mandar cada linha para seu devido destino.
Configuração do filter rows.
Como neste exemplo eu tenho interesse somente nos campos categorizados como new, irei mandá-los para o step ‘TRUE’ em vermelho.
Vejam que as linhas foram devidamente separadas pela coluna flagfield sem misturar os valores.
Uma categorização mais completa pode ser feita pela transformação switch/case.
Uma observação importante: switch/case é case-sensitive, então, se o campo na coluna flagfield estiver em minúsculo, na transformação também deverá começar com minúsculo. Como no exemplo acima.
Por fim, a transformação utilizando o switch/case destinando para cada dummy um status diferente.
Como dito pessoal, utilizando este step temos um controle maior sobre o destino de cada registro categorizado e assim, podemos analisar a melhor foram de lidar com eles, sem perder nenhum dado durante a transformação.
Transformação final:
CONCLUSÃO
Como dito no início do post este foi um primeiro passo rumo ao assunto lookup e seu funcionamento.
Confesso que não conhecia esse tipo de transformação no Join e quando vi, rapidamente pensei nas possibilidades que o step permite criar e controlar.
Encerro temporariamente a série sobre joins, com o melhor pro final (ainda falta o join xml)! Deixando o caminho aberto para o assunto que talvez seja o mais importante: controle de mudanças com lookup.
Vejo vocês no próximo post e espero que tenham gostado, saúde!
ManageBI 