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 si 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 Qlik Sense sont appelées des tables logiques. Qlik Sense procède à des associations entre les tables en fonction des noms des champs et crée les jointures lorsque l'utilisateur effectue une sélection, par exemple une valeur de champ dans un volet de filtre.
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.
Quatre tables (une liste de pays, une liste de clients, une liste de transactions et une liste de membres), qui sont associées entre elles par les champs Country et CustomerID.
Comparaison entre une association Qlik Sense et une jointure externe naturelle en code SQL
Une association Qlik Sense s'apparente à une jointure externe naturelle en code SQL. L'association est toutefois plus générale : une jointure externe 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 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, Qlik Sense a du mal à identifier la table à utiliser pour calculer les fréquences de données.
Qlik Sense 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 (Qlik Sense 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 un volet de filtre 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, Qlik Sense 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 le nouveau champ pour créer un volet de filtre avec fréquence, une zone de statistiques ou des calculs dans les graphiques.