Une base de données peut comporter de nombreuses tables. Chaque table peut être considérée comme une liste d'éléments, c'est-à-dire que chaque enregistrement de la liste représente une instance d'un type d'objet.
Si deux tables correspondent à des listes d'éléments différents, l'une étant par exemple une liste de clients et l'autre une liste de factures, et que les deux tables ont un champ en commun, tel que le numéro de client, cela signifie généralement qu'il existe une relation entre les deux tables. Dans les outils de requête SQL standard, les deux tables doivent presque toujours être jointes.
Les tables définies dans le script QlikView sont appelées des tables logiques. QlikView procède à des associations entre les tables en fonction des noms de champs et crée les jointures lorsque l'utilisateur effectue une sélection, par exemple une valeur de champ dans une liste de sélection.
Autrement dit, une association est pratiquement équivalente à une jointure. La seule différence réside dans le fait que la jointure est effectuée lors de l'exécution du script, la table logique étant généralement le résultat de la jointure. L'association, quant à elle, est réalisée après la création de la table, puisqu'elle est toujours établie entre des tables logiques.
Comparaison entre une association QlikView et une jointure externe (outer join) naturelle en code SQL
Une association QlikView s'apparente à une jointure externe (outer join) naturelle en code SQL. L'association est toutefois plus générale : une jointure externe (outer join ) en code SQL désigne généralement une projection à sens unique d'une table sur une autre. Une association établit toujours une jointure externe (outer join) naturelle complète (bidirectionnelle).
Informations de fréquence dans les champs d'association
L'utilisation de la plupart des champs d'association, c'est-à-dire les champs communs à plusieurs tables, est limitée. Lorsqu'un champ figure dans plus d'une table, QlikView a du mal à identifier la table à utiliser pour calculer les fréquences de données.
QlikView analyse les données pour vérifier s'il existe une manière non ambiguë d'identifier la table principale (c'est parfois le cas), mais la plupart du temps, le programme ne peut pas être sûr de son choix. Comme un mauvais choix pourrait avoir des conséquences graves (QlikView semblerait faire une erreur de calcul), le programme a été conçu pour interdire certaines opérations lorsque l'interprétation des données est ambiguë pour les champs d'association.
Limites relatives aux champs d'association
- Il est impossible d'afficher les informations de fréquence dans une liste de sélection contenant le champ.
- Les zones de statistiques correspondantes affichent n/a pour la plupart des entités statistiques.
- Dans les graphiques, il n'est pas possible de créer des expressions contenant des fonctions qui dépendent d'informations de fréquence (telles que Sum, Count et Average), à moins que le modificateur Distinct ne soit activé. Après chaque rechargement, QlikView analyse toutes les expressions de graphiques pour repérer les ambiguïtés susceptibles d'apparaître suite aux modifications apportées aux structures de données. Si des expressions ambiguës sont détectées, une boîte de dialogue d'avertissement s'affiche et l'expression est désactivée. Il est impossible d'activer l'expression tant que le problème n'est pas corrigé. Si un fichier journal est activé, toutes les expressions ambiguës y sont consignées.
Solution de contournement
Il existe un moyen simple de contourner ces limites. Rechargez le champ sous un nouveau nom à partir de la table où les décomptes de fréquence doivent être effectués. Utilisez ensuite ce nouveau champ pour créer une liste de sélection avec fréquence, une zone de statistiques ou des calculs dans les graphiques.
