Inteligência e criatividade já foram definidas como misturar coisas com um propósito e atingir outro. Eu tive o melhor exemplo disso há pouco, durante uma aula.

Explicando a gravação de uma fato, e peculiariedades de cada tipo de fato (snapshot, acumulating etc.), ela me perguntou:

Ah, então eu posso gravar a fato com a Table Output, e se quiser atualizar uso um Dimension Lookup/Update?”

De cara eu não entendi a pergunta – “Comparar table output com dimension lookup/update? Mas não tem nada a ver…” – foi quando eu parei para pensar e vi que era não só uma pergunta lógica, como óbvia.

Sim, claro, o D L/U (Dimensio Lookup/Update) é um passo dedicado a gravar dimensões, mas a lógica dele se presta a qualquer gravação/atualização que envolva uma chave composta e “coisas” (métricas!) que variem (ou não.)

Eu resolvi fazer um teste. Essa é a transformação que grava a fato pedido da Beltrano S/A, tirada do meu livro Pentaho na Prática:

Transformação que carrega a fato, usando passo "normal" Insert/Update.
Transformação que carrega a fato, usando passo “normal” Insert/Update.

Eu então troquei o Update no final por um D L/U – e não mexi em mais nada:

Transformação que carrega a fato, usando passo D L/U.
Transformação que carrega a fato, usando passo D L/U.

E essa ficou sendo a configuração do passo (eu tratei o tipo de pagamento como uma degeneração, mas sem querer coloquei como métrica):

Configuração do passo D L/U para gravar uma fato.
Configuração do passo D L/U para gravar uma fato.

Resultado? Bom, depois que eu criei a fato com o botão de SQL do D L/U e carreguei, ela ficou assim:

Fato gravada pelo passo D L/U. Repare que todos campos de controle da dimensão foram chamados de fut_ext_x (futuras extensões), e que agora ela possui uma chave primária.
Fato gravada pelo passo D L/U. Repare que todos campos de controle da dimensão foram chamados de fut_exp_x (futuras extensões), e que agora ela possui uma chave primária.

Ou seja, é a fato, mas com os campos de controle da dimensão. Eu nomeie todos eles como futuras expansões (fut_exp). A chave delegada também está lá, mas agora na função de uma chave primária! Compare com a fato “normal”:

A tabela fato gravada com um passo normal. (As chaves zeradas são um bug da minha transformação, que está bagunçada (sabe como é, próxima versão do livro...)
A tabela fato gravada com um passo normal. (As chaves zeradas são um bug da minha transformação, que está bagunçada (sabe como é, próxima versão do livro…)

Os zeros nas chaves decorrem do fato de a minha transformação estar em mudança – por algum motivo eu não recuperei as chaves (pau do banco?) – mas normalmente dá certo. Por favor, releve como ruído no material do livro, que está sendo revisado.

Conclusão? Dá certo! (Claro que dá, mas… como é que eu nunca pensei nisso antes???) Será que é alguma vantagem usar o D L/U para isso? Será que simplifica alguma lógica? A ver!

Genial! :-)

2 comentários sobre “Gravar Fato com Dimension Lookup/Update

  1. Fabio,
    seguindo sua linha de raciocínio, imaginemos uma empresa de seguro onde cada apólice n alinha do tempo sofre alteração de status. (NOVA, EM ANÁLISE, EMITIDA, CANCELADA, etc). Durante sua vigência de 12 meses ela pode sofrer N alterações em um intervalo indeterminado.
    Caso o usuário queira comparar períodos da empresa, utilizando snapshots, qual a melhor forma de eu armazenar essas alterações de uma apolice? Utilizando snapshots cumulativos?
    O Pentaho da suporte para traçar esse comparativo entre snapshots? Como?

    Desde já agradeço,
    Marcelo

    1. São duas questões: 1) como armazenar e 2) como usar. A primeira resposta é fácil e tem duas opções: A) Data Vault ou B) Modelo Dimensional. O Data Vault vai cuidar de tudo meio que automaticamente: se uma apólice é um hub, então seus atributos podem ser um satélite, e a partir disso o processo de modelagem do DV cuida de tudo. Se você escolher o Modelo Dimensional há a opção de uma estrela em que cada apólice é fotografada diariamente. Suas dimensões precisariam ter os atributos cuja variação você quer capturar. Ou seja, neste caso você guardaria o histórico na fato – não é uma coisa da qual eu sou muito fã, mas este caso se resolve bem com essa técnica.

      Depois, o consumo: se você adotar a solução multidimensional, o consumo decorre automaticamente: basta modelar um cubo em cima. Se adotar o DV, vai precisar montar uma estrela contra qual fazer suas análises.

      Era isso? ;-)

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s