Fala pessoal, beleza?
Sempre após a entrega de relatórios que exibem o resultado de vendas, a curiosidade bate a porta: Eu sei o que vendeu e o que mais vendeu, mas quais são os produtos que não venderam? Quais vendedores não venderam?
Eita… se não vendeu quer dizer que o registro/dado não existe, e agora?
Como dito anteriormente, se queremos saber “o que não vendeu” então sabemos que esses registros não existem em nossa tabela.
Existem algumas maneiras de tentar resolver esse tipo de problema:
- Set Analysis
- Estado Alternativo
- Incluir registros faltantes
O problema de se tentar resolver esse tipo de relatório por expressões (Set Analysis ou Estado Alternativo) é porque não são muito flexíveis e para alguns casos a solução pode ficar bastante complexa fazendo com que o desempenho reduza drasticamente para este relatório.
Incluir registros faltantes pode facilitar bastante para criar novos relatórios desse tipo, porém o volume de registros, na tabela fato, pode crescer MUITO fazendo com que o desempenho de TODA a nossa aplicação reduza drasticamente.
A maneira que estou propondo para resolver esse tipo de “problema” é adicionar registros, porém de uma forma mais inteligente: adicionar registros nas tabelas dimensionais e não na tabela fato.
A melhor maneira de entender isso é com um exemplo, vamos lá 🙂
Objetivo
Neste exemplo temos uma tabela fato que possui as informações de Vendas por AnoMes, Vendedor e Produto. Quero montar uma tabela que exiba todas as vendas e também o que não foi vendido para conseguir responder algumas perguntas, como por exemplo: Quais os produtos que determinado vendedor não vendeu? Quando? Quais meses ficou sem vender?
Cenário
Abaixo a nossa tabela Fato:
Script de criação e dados:
Ah, já sei: O Yuri não vendeu Monitor no mês de Janeiro. Em Fevereiro ele não vendeu NADA! Em Março ele não vendeu teclado e nem monitor……………
A resposta é essa, mas vamos criar a solução no QlikView 🙂
Criando as tabelas dimensionais
Como no meu exemplo só tenho uma tabela Fato e não quero poluí-la com registros, vou criar minhas tabelas dimensionais através da tabela Fato. Pule esse passo caso vocês já possuam a tabela Fato separada das dimensionais.
As tabelas ficarão ligadas a Fato, então precisamos renomear os campos da tabela Fato para que estes representem chaves.
Renomeando campos chaves
Agora nossa tabela Fato ficará dessa forma:
Criando a tabela Calendário
Criando a tabela Produto
Criando a tabela Vendedor
Resultado
Agora conseguimos chegar no cenário que eu queria (poderia ter criado assim desde o começo rsrs)
A solução
Agora vem a parte mais interessante que consiste em adicionar os registros nas tabelas dimensionais para conseguirmos responder as perguntas iniciais, mas não é simplesmente adicionar os registros, iremos criar um “joguinho de chaves” que representam todo o conjunto de dados daquela tabela e depois criar esse mesmo “joguinho de chaves” na tabela Fato.
No começo do post eu disse que não adicionaremos registros na tabela Fato, mas na verdade adicionaremos UMA LINHA apenas. Uma pequena mentirinha rsrs
Vou fazer a primeira modificação na tabela de vendedor:
Reparem que fiz uma leitura da própria tabela Vendedor, devido a desempenho, e no campo de chave (com a tabela Fato) chamado pk_Vendedor, criei o valor fictício ‘Todos Registros’. Na tabela Fato não existe o valor ‘Todos Registros’ para o campo pk_Vendedor, porém podemos adiciona-lo com o valor zero para a coluna VolumeVendas (Esse é o pulo do gato!).
Vamos fazer a mesma coisa para as tabelas: Calendário e Produto para depois criar o registro na tabela Fato.
Chegou o grande momento de criar a referência ‘Todos Registros’ na tabela Fato:
Veja o resultado no gráfico:
Ah Yuri, mas para isso acontecer é só desmarcar a opção “Ocultar Zeros” na aba apresentação do gráfico.
Realmente você deve desmarcar essa opção, mas se não fizermos todo aquele procedimento não conseguiremos fazer filtros para manter o resultado e identificar a “não venda”:
Aplicação de exemplo
Para fazer o download da aplicação de exemplo, clique aqui!
Conclusão
Eu gosto desse método porque o usuário vai conseguir trabalhar com os filtros e ainda conseguir identificar o que realmente não vendeu e quando; o melhor de tudo é que não precisou adicionar um volume grande de dados na tabela Fato (Apenas em uma linha) e nem criar expressões muito complexas para isso.
Até a próxima semana pessoal!
Bacana … !! continue assim …
Ótima Dica!
Isso é realmente útil! Já tive que mostrar esse tipo de resultado e acredito que não tenha ficado da melhor forma!
Parabéns mais uma vez!
Simplesmente GENIAL !!!
Como ficaria em um esquema “snowflake”?
Essa solução é funcional apenas para modelos de ligações diretas
Neste caso a sua fato não possui uma linkdata entre a fato e a calendário. Em um modelo que tenha esse relacionamento, é possível aplicar o seu exemplo?