Comprendre le modèle associatif de Qlik

1Tout commence par un clic

Avant de parler de moteur, de cardinalité ou de modèle de données, faisons simplement ce que fait n’importe quel utilisateur de Qlik : sélectionnons une valeur.

Notre application analyse quelques ventes. Au départ, aucune sélection n’est active : toutes les valeurs sont possibles.

Cliquons sur Nord. La valeur devient verte. Mais le plus intéressant est ce qui arrive partout ailleurs.

2Notre mini-modèle

Gardons le même petit jeu de données pendant tout l’article. Les ventes sont reliées aux clients et aux produits par des champs communs.

Dans Qlik, les champs portant exactement le même nom dans plusieurs tables constituent les associations : le moteur ne devine pas leur relation métier. Le schéma ci-dessus représente des associations, pas des cardinalités 1→N déclarées comme contraintes de relation. Ici, ID_CLIENT et ID_PRODUIT permettent aux sélections de traverser le modèle.

Le jeu de données de référence

À partir d’ici, tous les exemples de l’article découlent exactement des mêmes données. Cela nous permettra de vérifier chaque valeur blanche, verte ou grise sans changer les règles en cours de route.

Vue à plat : le tableau ci-dessous sert uniquement à vérifier facilement les exemples. Dans le modèle Qlik présenté juste au-dessus, CLIENTS, VENTES et PRODUITS restent bien trois tables distinctes.

3Les états de sélection : les couleurs parlent

Les couleurs ne sont pas un simple habillage. Elles représentent l’état logique des valeurs par rapport aux sélections. Vert, blanc, gris clair et gris foncé sont les couleurs Qlik caractéristiques ; un thème personnalisé peut toutefois les modifier. C’est donc l’état logique qui compte, pas la teinte exacte.

Le vert et le blanc sont intuitifs. La vraie richesse apparaît souvent dans les gris : ils rendent visibles des relations qui ne font plus partie du résultat courant.

4Une sélection se propage dans tout le modèle

Avec Région = Nord, Qlik détermine les clients associés au Nord, puis les ventes reliées à ces clients, puis les produits présents dans ces ventes.

Une liste de valeurs, un tableau ou un graphique n’est donc pas isolé : tous travaillent avec le même contexte de sélection.

5Le gris est une information

Dans beaucoup d’outils, filtrer signifie surtout faire disparaître ce qui ne correspond pas au filtre. Qlik conserve au contraire ces valeurs visibles et indique qu’elles sont exclues.

Quels clients n’ont rien acheté dans cette région ? Quels produits ne sont pas associés à ce segment ? Quelles valeurs deviennent impossibles lorsqu’on ajoute une contrainte ? L’exclusion peut être aussi instructive que le résultat lui-même.

6Gris clair et gris foncé : le piège classique

Le gris clair — l’état alternatif — apparaît dans un champ qui contient déjà une sélection.

7Plusieurs sélections : ET entre les champs, OU dans un même champ

Jusqu’ici, nous n’avons sélectionné qu’une seule valeur. Dans une vraie application, on combine très vite plusieurs choix. Une règle simple permet de comprendre ce qui se passe.

Le deuxième clic resserre donc le contexte. Avec Nord ET PC, Alice et Benoît restent possibles ; Chloé, David et Emma sont exclus côté Client, tandis qu’Écran et Casque sont exclus côté Produit. Souris devient alternative dans Produit, puisque ce champ contient désormais la sélection PC. Les états sont recalculés après chaque sélection.

8« Sélectionné exclu » : le cinquième état en situation

C’est l’état le moins intuitif. Il faut distinguer deux choses : l’entrée — la valeur a-t-elle été sélectionnée ? — et la sortie logique — cette valeur reste-t-elle possible compte tenu des autres sélections ?

Chloé devient donc sélectionnée exclue : la coche rappelle qu’elle a été sélectionnée, tandis que le gris foncé indique que la nouvelle sélection l’a rendue impossible. Si l’on supprime la sélection qui l’exclut, elle peut redevenir sélectionnée.

9Et si une valeur n’a aucune correspondance ?

Emma existe dans CLIENTS, mais aucune des cinq lignes de VENTES ne lui correspond. Elle appartient donc bien au modèle sans avoir de vente associée.

Dans une liste de sélection Client, Emma peut donc rester visible comme valeur du champ. Dès qu’un contexte exige une association avec des ventes, son absence de correspondance peut se traduire par un état exclu. Cela ne signifie pas pour autant qu’Emma apparaîtra dans toutes les visualisations : leur contenu dépend des dimensions, mesures et données qu’elles utilisent.

Ce cas rend le « gris comme information » très concret et montre pourquoi il faut éviter de traduire mentalement tout le modèle Qlik en une gigantesque jointure SQL.

10Sous le capot : pourquoi parle-t-on d’associatif ?

Le mot « associatif » ne signifie pas que Qlik abandonne les tables. Le modèle chargé en mémoire est constitué de tables et de champs. Sa particularité est la manière dont les valeurs communes permettent au moteur de déterminer, à chaque sélection, quelles valeurs sont possibles ou exclues dans l’ensemble du modèle.

Pour quelqu’un venant du SQL ou d’un autre outil BI, c’est un changement de perspective : le modèle ne sert pas seulement à produire le résultat d’une requête prédéfinie. Il devient un espace que l’utilisateur explore par associations successives.

11Association Qlik ≠ jointure SQL

La comparaison avec une jointure SQL est tentante, mais elle devient vite trompeuse. Une jointure fabrique un résultat selon une condition et un type de jointure précis. Dans Qlik, les tables peuvent rester séparées et être reliées par leurs champs communs.

Prenons Emma, notre cliente sans vente. Avec un INNER JOIN entre CLIENTS et VENTES, sa ligne disparaîtrait du résultat. Avec un LEFT JOIN, elle resterait présente, mais nous aurions déjà choisi une façon précise de combiner les deux tables. Dans le modèle Qlik, CLIENTS et VENTES peuvent rester distinctes : Emma existe toujours dans CLIENTS. Dans une liste de sélection Client, son absence de correspondance avec VENTES peut alors devenir visible selon le contexte ; cela ne signifie pas qu’Emma apparaîtra automatiquement dans toutes les visualisations.

Contrairement à une jointure SQL, la relation entre deux tables Qlik n’est pas contrainte par un type de jointure prédéfini : ce sont les associations entre champs communs qui propagent les sélections. Ce n’est donc pas « un FULL OUTER JOIN partout ». Cette image peut dépanner quelques secondes, mais elle ne décrit pas correctement le fonctionnement du modèle.

12Et les calculs et les graphiques dans tout ça ?

Le contexte associatif ne sert pas uniquement à colorer des listes. Il détermine aussi l’ensemble de données sur lequel les expressions des objets sont évaluées. Quand vous sélectionnez Nord, un indicateur comme Sum(Montant) est recalculé sur les ventes possibles dans ce contexte.

C’est également ici qu’intervient le Set Analysis : il permet à une expression de travailler sur un ensemble défini différemment du contexte de sélection courant — par exemple pour comparer la région sélectionnée au total général.

13Associatif ne veut pas dire magique

La puissance du moteur ne dispense pas de construire un modèle cohérent. Si deux champs portent le même nom, Qlik peut les associer. Un mauvais nom de champ peut donc créer une association non souhaitée.