Associações entre tabelas lógicas

Um banco de dados pode ter várias tabelas. Cada tabela pode ser considerada como uma lista de algo. Cada registro na lista representa uma instância de um objeto de algum tipo.

Exemplo:  

Se duas tabelas forem listas de itens diferentes, por exemplo, se uma for de clientes e a outra for de faturas, e as duas tabelas tiverem um campo em comum, como o número do cliente, normalmente é um sinal de que há um relacionamento entre as duas tabelas. Em ferramentas de consulta SQL padrão, as duas tabelas devem quase sempre ser unidas.

As tabelas definidas no script do QlikView são denominadas tabelas lógicas. O QlikView faz associações entre as tabelas com base nos nomes de campos e executa as junções quando uma seleção é feita, por exemplo, durante a seleção de um valor de campo em uma lista.

Isso significa que uma associação é quase o mesmo que uma junção. A única diferença é que a junção é feita quando o script é executado – a tabela lógica é geralmente o resultado da junção. A associação é feita depois da criação da tabela — as associações são feitas sempre entre as tabelas lógicas.

Quatro tabelas: uma lista de países, uma lista de clientes, uma lista de transações e uma lista de assinaturas, que estão associadas entre si pelos campos Country e CustomerID.

Associação do QlikView em comparação com a outer join natural SQL

Uma associação do QlikView é semelhante à uma outer join natural SQL. No entanto, a associação é mais geral: uma outer join no SQL é geralmente uma projeção unidirecional de uma tabela em outra. Uma associação sempre resulta em uma outer join natural completa (bidirecional).

Informações de frequência em campos associados

Há algumas limitações no uso da maior parte dos campos associados, isto é, campos que são comuns entre duas ou mais tabelas. Quando um campo ocorre em mais de uma tabela, o QlikView enfrenta problemas para saber qual das tabelas deve usar para calcular frequências de dados.

O QlikView analisa os dados para determinar se há uma forma não ambígua de identificar uma tabela principal para efetuar a contagem (às vezes há), mas na maior parte dos casos o programa pode fazer apenas uma suposição. Como uma suposição incorreta poderia ser fatal (o QlikView aparentaria fazer um erro de cálculo), o programa foi projetado para não permitir determinadas operações quando a interpretação de dados for ambígua para campos associados.

Limitações para associação de campos

  1. Não é possível exibir informações de frequência em uma lista que mostre o campo.
  2. As caixas de estatísticas do campo mostram n/a para a maior parte das entidades estatísticas.
  3. Em gráficos, não é possível criar expressões que contenham funções que dependam de informações de frequência (como funções Sum, Count e Average) sobre o campo, a menos que o modificador Distinct seja ativado. Depois de cada execução de script, o QlikView pesquisa todas as expressões de gráficos para verificar se ocorreu alguma ambiguidade como resultado de alterações nas estruturas de dados. Se forem encontradas expressões ambíguas, uma caixa de diálogo de atenção será exibida e a expressão será desabilitada. Não será possível habilitar a expressão até que o problema seja corrigido. Se um arquivo de log for habilitado, todas as expressões ambíguas serão listadas no log.

Solução alternativa

Há uma forma simples de superar essas limitações. Carregue o campo uma vez mais com um novo nome, a partir da tabela na qual as contagens de frequência devem ser feitas. Em seguida, use o novo campo para uma lista com frequência, para uma caixa de estatísticas ou para cálculos nos gráficos.