Fala pessoal, tudo bom?
Essa semana estou iniciando um novo quadro aqui no blog: “Pediu? Tomou!” 😀
Esse quadro foi criado para responder as solicitações feitas pelos leitores do blog, sejam solicitações através de meu e-mail, pelos comentários no blog ou pela página no facebook.
Dentro do possível estarei criando um post para cada solicitação 🙂
O assunto dessa semana será….
Fala pessoal! Tudo bom?
Voltando ao assunto de Melhores Práticas, quero falar sobre o Include!
Quando estamos em um cliente, ou em nossa empresa, em que o ambiente de QlikView seja pequeno não percebemos a importância do Include (Mas o que é isso? Calma! rsrs). Houve uma mudança na estrutura de diretórios do ambiente? Entro no QVW do meu projeto e altero a variável de caminho (Espero que você tenha esse costume de colocar variáveis com os caminhos dos arquivos 😀 !)
Como citei anteriormente, se o meu ambiente é pequeno, com poucos qvws, entro em cada um deles e altero, mas e se meu ambiente esta grande? Vou perder algumas belas horas para alterar tudo!
Fala pessoal, tudo bom?
Essa semana a Qlik nos anunciará no em seu blog, assim que isso ocorrer postarei aqui o link 🙂
ATUALIZAÇÃO: A Qlik acabou de anunciar, segue o link: aqui.
Ontem eles liberaram os cards dos MVPs e gostaria de postar o meu aqui para vocês.
Estou bastante feliz com esse título!! Muito obrigado Qlik!
Para quem não acompanhou na época, segue um descritivo sobre o título que recebi: aqui!
Pessoal, ainda não fiz o post da semana, mas estou preparando um bem legal !! Fiquem ligados!!
Fala pessoal, tudo bom?
Mais um post sobre os CUIDADOS que devemos ter em nosso script para evitar erros!
Dessa vez quero falar sobre a leitura de múltiplos arquivos através dos caracteres curinga* (ahn? ajuda aí!)
Wikipedia diz: Em computação os caracteres-curinga são utilizados em casamento de padrões para substituir algum outro carácter desconhecido em uma sequência de caracteres.
É muito utilizado ao realizar um glob para procurar arquivos cujo nome ou caminho completo são desconhecidos. Nos interpretadores de comandos, o caractere asterisco (*) é reconhecido como um caractere-curinga que casa com qualquer número de caracteres desconhecidos e o caractere interrogação (?) é um curinga que casa com um único caractere desconhecido.
(entendido? rsrs! retornando ao texto) quando utilizamos em conjunto de união de tabelas (JOIN! – Neste exemplo o CONCATENATE não é um erro, mas falo disso no final).
É um erro bobo, mas fácil de ser cometido. Sabe por quê? Porque conhecemos os conceitos e comportamentos do QlikView.
Sabemos que o QlikView possui o comportamento de unir (transformar em apenas uma) tabelas que possuem os mesmos campos (com a mesma nomenclatura), por esta razão quando utilizamos o caractere curinga para fazer uma leitura múltipla de arquivo, o QlikView “faz o favor” de unir todas essas tabelas (desde que respeite a regra anterior que falamos) em apenas uma.
Imagine um cenário com em que precisamos carregar planilhas com notas fiscais. Cada uma das planilhas possui informação de apenas um mês/ano.
Lista de arquivos: NF_jan12.xls, NF_fev12.xls, NF_mar12.xls e NF_abr12.xls.
Esses arquivos estão perfeitos para serem carregados de uma única vez através do caractere curinga “*”.
Ah, vale lembrar que esses arquivos estão todos do mesmo padrão, isso inclui: nome das colunas e nome da aba a serem carregadas.
Em nosso script do qlikview:
Resultado:
A leitura dos quatros arquivos se resumiram em apenas uma tabela devido ao comportamento do QlikView.
Agora vamos para o exemplo em que podemos se esquecer desse comportamento e cometer um erro grave.
Agora temos uma tabela principal com o nome das empresas de um grupo, conforme imagem:
Queremos exibir os dados de faturamento, mas mostrando todas as empresas, ou seja, mesmo que a empresa não tenha faturado nada, esta deve exibir no relatório.
Tecnicamente, iremos carregar primeira a tabela com a descrição das empresas e depois fazer o LEFT JOIN utilizando a tabela de nota fiscal. Nosso script seria:
Executando o script, veja o resultado:
O resultado ficou como esperado! As empresas 4 e 5 estão sendo exibidas sem nenhuma nota fiscal e o restante das informações fez a ligação com a descrição da empresa.
Opa, mas peraí! Carreguei informações de Jan/2013, Fev/2013, Mar/2013 e Abr/2013… Por quê esta aparecendo somente os dados de Abr/2013?
Aparentemente fizemos tudo certo, mas um grande detalhe de comportamento nos atrapalhou: leitura múltipla de arquivos em conjunto com união de tabelas.
Seguindo o comportamento de execução do Qlikview, em primeiro lugar carregamos a tabela Empresas e passamos a chama-la de Fato, tendo essa tabela carregada (em memória), realizamos a leitura múltipla das tabelas de notas fiscais e fazemos a união desta tabela com a data Fato através da coluna COD_EMPRESA.
Durante a execução, após ter a tabela fato em memória, da leitura múltipla, o QlikView, faz a leitura do primeiro arquivo encontrado que é “NF_abr13.xls” (Por quê esse? Ordem Alfabética!) e realiza o LEFT JOIN com a tabela fato, depois disso o QlikView faz a leitura do próximo arquivo “NF_fev12.xls” e realiza o LEFT JOIN com a tabela fato. OPA !!!! neste momento a tabela Fato já possui as colunas do arquivo de Empresas: COD_EMPRESA e DES_EMPRESA, e as colunas do arquivo de Nota Fiscal: NF_NUMERO, NF_DT_PAGAM, NF_VL_PAGAM e COD_EMPRESA, ou seja, ao tentar fazer o LEFT JOIN do segundo arquivo “NF_fev12.xls”, o QlikView não vai encontrar (match) a combinação de registros das colunas (NF_NUMERO, NF_DT_PAGAM, NF_VL_PAGAM e COD_EMPRESA).
Não entendi!
No primeiro arquivo, a chave de ligação do LEFT JOIN é apenas a coluna COD_EMPRESA (essa é a chave correta), porém a partir do segundo arquivo, a chave de ligação passa a ser: COD_EMPESA, NF_NUMERO, NF_DT_PAGAM, e NF_VL_PAGAM porque essas colunas já foram carregadas no primeiro arquivo carregado.
Logicamente, essa nova chave não fará mais nenhuma ligação por não termos essa combinação de registros.
Desenhando (esse momento foi muito difícil pra mim rsrs!!!)
Bom, se o comportamento do QlikView é esse, então nestes casos é sempre importante termos um passo antes para carregar todos esses arquivos e guardar em uma tabela temporária, para depois fazer o JOIN. Dessa forma:
Para concatenate não tem problema, pois o processo é de forçar a concatenação, independente de quais colunas estejam nas tabelas.
É muito importante conhecermos a fundo os conceitos e comportamentos do QlikView. Neste caso, nossa cabeça pensa que o QlikView vai carregar todos os arquivos (concatenando-os) para depois fazer o JOIN, porém aprendemos que o QlikView não se comporta dessa forma.
Para quem deseja, segue a aplicação de exemplo para download.
Até a próxima semana pessoal!
Fala pessoal, tudo bom?
É sempre bom conhecermos e entendermos (se possível rsrs) a fundo o funcionamento da ferramenta em que trabalhamos para evitarmos alguns erros.
Neste post quero tratar a função DISTINCT e suas pegadinhas!
Como sabemos, essa função vai eliminar linhas com registros iguais.
Por exemplo: Se tivermos uma tabela de cadastro de usuários com duas colunas: Numero e Nome, e o seguinte conteúdo:
Ao realizar um select nesta tabela, teremos duas linhas com o número 1 e o nome Yuri, porém se fizermos um select com distinct, então essa tabela passará a ter somente três linhas, uma para YURI, outra para JULIAN e outra para o DAVID.
Até aqui esta tudo normal!
Quando estamos desenvolvendo a modelagem dos dados, é muito provável que utilizamos o DISTINCT junto à um processo de união de tabelas, seja por CONCATENATE ou por JOIN. Isso é normal e faz parte do processo!
Vamos imaginar a seguinte situação:
Reparem que temos linhas repetidas, porém essas linhas não podem sumir ou nosso resultado ficará incorreto.
Neste caso temos:
Yuri: 900
Julian: 750
Queremos ligar essa tabela com a de Supervisor:
Nesta tabela as linhas 2 e 3 são idênticas.
Se fizermos o código tentarmos unir essa tabela por JOIN, conforme código abaixo:
Nosso resultado será:
Veja, Yuri 900, ok! Julian, 1500? Opa! Então o cadastro duplicado da tabela Supervisor duplicou os registros do Julian.
Simples, se o cadastro esta duplicado, então simplesmente irei fazer um DISTINCT nesta tabela e tudo se resolve, ufa!
Pronto, agora faço uma recarga e….
Eita… como assim Yuri com 700 e Julia 650? Os valores corretos não eram: Yuri 900 e Julian 750??? O que aconteceu?
Apesar do comportamento não ser o nosso esperado, ele é bem simples de entender: Usar o DISTINCT no mesmo processo de união de tabelas, eliminará TODAS as linhas resultantes que estiverem duplicadas, independente se o DISTINCT foi utilizado na primeira, na segunda ou na última tabela do processo, em outras palavras, o comportamento do DISTINCT será aplicado na tabela final que a união resultará.
Outro caso: Se você colocarmos o DISTINCT na primeira tabela? Teremos o mesmo resultado! Lembre-se, o DISTINCT terá efeito na tabela final (Tabela Fato) e não simplesmente na tabela em que colocamos o DISTINCT.
Talvez você já tenha utilizado o DISTINCT no meio do processo de união de tabelas e nem percebeu que ele possui esse comportamento (BINGO!! Eu também não havia percebido até a semana passada!! rsrs).
Calma! No nosso exemplo queremos remover apenas os registros duplicados da tabela Supervisor, então devemos criar uma passo temporário (fora do processo de união das tabelas Vendas e Supervisor) removendo as linhas iguais e depois, em outro processo, fazemos a união da tabela.
Ficaria mais ou menos assim:
E o resultado:
É muito importante entendermos o comportamento de algumas funções dentro do QlikView e isso diminui bastante possíveis erros em nossos dados.
A utilização do DISTINCT sempre resultará na diminuição, e precisamos ser atentos aos nossos dados para esse problema não ocorra quando não queremos. Existem situações em que precisamos eliminar as linhas duplicadas, mas em outras não!
IMPORTANTE: Esse processo vai ocorrer seja por um JOIN ou um CONCATENATE!
Lembro de códigos que desenvolvi em que utilizei diversas vezes o DISTINCT (em várias tabelas diferentes) dentro de um processo de união, mas a partir de agora sei que não preciso, apenas um simples DISTINCT em alguma tabela do processo resolve! 🙂
Até a próxima semana pessoal!
Blog do Nicolett 