Para definirmos de forma simples o comportamento de um componente de lookup, poderíamos dizer que estes funcionam como uma cláusula SELECT com WHERE. Basicamente tentamos recuperar um ou mais valores baseados na comparação entre colunas e seus valores.
Ex: Select NOME, ENDEREÇO From tabela Where ID = (valor numérico)
Ex: Select NOME, ENDEREÇO From tabela Where ID = (valor numérico)
O componente Database Lookup, como o próprio nome sugere, faz uma busca de valores em uma tabela de um banco de dados. Para usar este componente, assim como o Table Input, também será necessário ter ao menos uma conexão configurada.
O comportamento do Stream Lookup é parecido, porém a busca de valores é feita dentro do próprio fluxo. de dados. Esta afirmação sugere que o componente receba duas fontes de dados diferentes. No Database Lookup isso não é necessário, pois uma das fontes de dados é a própria tabela.
O Database Lookup é extremamente útil em diversas ocasiões. Entre elas, podemos destacar principalmente a fase de estagiamento de um DW.
Utilizamos como exemplo o preenchimento de uma tabela FatoVendas, onde precisaremos:
O Database Lookup é extremamente útil em diversas ocasiões. Entre elas, podemos destacar principalmente a fase de estagiamento de um DW.
Utilizamos como exemplo o preenchimento de uma tabela FatoVendas, onde precisaremos:
- Buscar o código dos clientes na base relacional
- Compará-lo com a tabela de Dimensão de Clientes
- Buscar o seu novo código correspondente na Dimensão e, então,
- Preencher a linha da tabela fato com o código correspondente, ou seja, o cliente que participou de uma determinada venda.
- Fazer um lookup na tabela Dim_Clientes, passando o código do cliente que veio da base relacional e comparando-o com um campo cd_cliente_relacional da tabela Dim_Cliente, que possui a referencia do codigo do cliente na base relacional.
- Teremos, então, como retorno, o campo ID_CLIENTE, do tipo Integer, que é o ID daquele cliente dentro do DW, conforme mostra a figura abaixo.
Importante lembrar que um valor (cliente, por exemplo), NUNCA deve ter o mesmo código na base relacional e na dimensão de um DW. Esta prática não é aconselhada.
Os números da figura acima correspondem:
- Escolher a conexão que será utilizada
- Escolher a tabela onde serão procurados os valores
- Puxar todos os valores da tabela e deixá-los em cache. Ideal nao habilitar quando há muitos valores na tabela, pois carregará muitos dados na memória
- Campo da tabela a ser comparado
- Campo do fluxo comparado ao campo da tabela
- Campo a ser retornado caso a comparação anterior seja verdadeira. É possível definir o tipo do campo e um valor "Default", caso os valores comparados não existam.
Como a busca de dados pelo componente Database Lookup nao utiliza o NOLOCK, existe o risco de deadlock quando a busca é pesada, longa e há várias outras operações acontecendo na mesma tabela ao mesmo tempo (Inserts, updates, etc).
Para isso, recomendo um Select feito em um Table Input, utilizando o NOLOCK, e aí então, utilizar o Stream Lookup para buscar os valores desejados. Dessa forma, o Kettle coloca as linhas em memória, não sendo necessário utilizar e acessar o banco diversas vezes durante o fluxo de dados.
Este exemplo está ilustrado na figura a seguir:
O comportamento do componente Stream Lookup, assim como suas opções e formas de uso serão discutidos no próximo post.
Olá Luciano,
ResponderExcluirEstou precisando fazer um passo de uma transformação, em que é preciso ir em uma tabela e verificar se um determinado campo existe (isso o database lookup faz, certo?). Mas se não existe, eu queria colocar um valor default. Tentei fazer com o database lookup mas o kettle sempre retorna ORA-02291: restrição de integridade violada - chave mãe não localizada.
Podes me ajudar?
Olá Camila,
ExcluirO Database Lookup possui exatamente esta função. Quanto ao erro, geralmente ele ocorre quando tentamos inserir ou atualizar um registro com um valor de chave estrangeira não localizado na tabela com a chave primária. Você está utilizando algum step de Insert ou Update em sua transformation?
Como o comportamento do Database Lookup é semelhante a um simples "select" no banco, o problema pode não ter relação direta com ele.
Qualquer coisa pode mandar um print ou a própria transformation para lpeixoto87@hotmail.com.
Luciano, muito obrigada pela ajuda.
ResponderExcluirDeu tudo certo.
=)
Ola Luciano.
ResponderExcluirEstou fazendo um ETL dos Dados originalmente do facebbok, porem o retorno é uma massa de dados todo misturado, em uma só linha. Como posso tratar estes dados de forma separada?
Ex: Uma linha para o id, outra para nome, etc..?
Obrigado
Luciano, Boa tarde.
ResponderExcluirSei que o post é bem antigo,porém, estou com uma duvida de como fazer essa etapa do meu processo.
Estou tentando usar o Pentaho para fazer a integração de dois sistemas.
A situação é a seguinte:
Imagine empresarial que tem varias salas (escritorios) e a cada solicitação de limpeza, é gerado um registro no banco.
Tenho dois registros pertinentes a mesma sala. Uma de limpeza e outra de manutenção.
Quero trabalhar de forma condicional esses dois registros para resultar em uma única linha. Vi que existe uma forma de fazer o merge
Consigo fazer esse tratamento dentro do Pentaho?
Olá Rodrigo,
ExcluirÉ possível fazer este tratamento sim.
No seu caso, eu recomendo o uso do step Merge Join ou Database Join, pois o Database Lookup tem mais utilidade para selecionar ou procurar um
determinado valor no banco.
É importante lembrar que, na escolha do step mais adequado, você deverá sempre levar em conta quais os dados estão passando pelo seu fluxo naquele momento.
Abraço!
É possível usar um select genérico para fazer uma busca de valor em todas as tabelas de um banco?
ResponderExcluirEx.: Tenho em cada tabela uma coluna "id" e quero pesquisar quais tabelas possuem o "id" = 5... é possível?