Tables déconnectées

Une table déconnectée est une table où la logique associative normale de QlikView a
été désactivée en interne. Cela signifie que les sélections dans un champ ne sont pas
répercutées à tous les autres champs de la table. Ce chapitre donne quelques
exemples de la façon dont des tables déconnectées modifient la logique QlikView.

Exemple de base

Regardez les trois zones Tables suivantes, chacune représentant une table lue
dans QlikView :
Si vous sélectionnez la valeur 2 dans le champ B, voici ce qui arrivera :
La sélection se répercute dans toutes les tables. Gardons maintenant cette
sélection, mais déconnectons Tab2. Cela signifie que la logique sera coupée
entre les champs A et C dans Tab2. Le résultat ressemblera à ceci :
Attention : Tab2 ici est une zone Table et non la table elle-même. La zone
Table affichera toutes les combinaisons possibles entre les champs de ses
colonnes. Comme il n'y a pas de logique entre les champs A et C, toutes les
combinaisons de leurs valeurs possibles respectives sont affichées.

Éviter les références circulaires

L'exemple suivant montre comment des tables déconnectées peuvent être
utiles pour éviter des références circulaires dans la structure des données :
En fait, cette structure de données n'est pas très bonne puisque le nom de
champ Pays est utilisé à deux fins différentes. Dans une table, il indique où le
propriétaire de la voiture habite, et dans l'autre, il indique où réside le
fabricant de la voiture. Avec les données des tables, on se trouve face à une
situation logique impossible. Où que l'on fasse la sélection, on peut suivre
des associations passant par toutes les cellules des trois tables.
Vous devez décider lequel du pays de résidence ou du pays de fabrication de
la voiture est le plus important. Si vous déconnectez la table Fabricant
automobile, les associations de Cadillac à États-Unis et de Volvo à Suède
seront rompues. En cliquant sur Suède, vous obtiendrez Björn Borg et
Cadillac. En cliquant sur Volvo, vous obtiendrez George Bush et États-Unis.
Si vous préférez vous concentrer sur les fabricants automobiles, il est plus
intéressant de déconnecter la table Domicile à la place.

Autre exemple

Considérons une autre situation courante où les tables déconnectées peuvent
être utiles. Vous trouverez ci-dessous trois tables à la structure plutôt
habituelle : une table de transaction et deux tables de dimension reliées à la
première par un champ chacune.
Maintenant, admettons que vous souhaitiez un tableau croisé dynamique
affichant les ventes par an et le groupe de produits. Si nous en créons un par
rapport à deux listes de sélection affichant les champs de dimension, cela
donnera ceci :
Même si c'est un tableau croisé dynamique correct, les effets de la logique
associative de QlikView pourraient donner ici des résultats indésirables. Si
nous sélectionnons l'année 2000, nous obtiendrons la présentation suivante :
Le groupe de produits Z a « disparu ». C'est normal, puisque la valeur Z du
champ GrpProd a été exclue par la sélection de la valeur 2000 du champ
Année. Pourtant, le Directeur voudra sûrement voir Z dans le graphique avec
un 0 dans la colonne sum(Quantité), afin qu'il soit clair pour tout le monde
que le groupe de produits Z existe et que rien n'a été vendu en 2000.
Vous pourriez répondre que les deux champs Année et GrpProd n'ont
vraiment rien à voir et qu'ils ne devraient donc pas interagir simplement
parce qu'ils se trouvent être liés par la table Trans. Résolvons donc le
problème en déclarant la table Trans déconnectée. Notre présentation sera
tout de suite différemment :
La table a maintenant l'apparence voulue. Notez que la sélection dans la liste
Année n'exclut pas de valeurs de la liste GrpProd.
En résumé, on peut dire que cette situation, avec une ou plusieurs tables de
transaction entourées d'un certain nombre de dimensions qu'on ne veut pas
exclure, est tout à fait courante. Les tables déconnectées sont alors une façon
de traiter de tels cas.

Tables déconnectées et sous-totaux

Lorsqu'on utilise des tables déconnectées avec des données de dimension
non hiérarchiques, les sous-totaux des tableaux croisés dynamiques peuvent
devenir incorrects. L'exemple ci-dessous est très semblable au précédent,
mais le produit B appartient maintenant à deux groupes de produits, X et Y.
Le produit D a disparu et cette vente est maintenant remplacée par le
produit B.
Cela signifie que la quantité totale vendue est la même, ce que l'on peut
constater dans le tableau croisé dynamique maintenant développé avec Prod
comme troisième dimension :
Comme vous pouvez le déduire de l'absence du groupe de produits Z dans
l'année 2000, aucune table n'a été déconnectée. QlikView traite correctement
les sous-totaux, c'est-à-dire que les deux occurrences de B chaque année ne
sont comptées qu'une fois dans les sous-totaux. C'est l'effet de la logique
associative normale de QlikView.
Déconnectons maintenant la table Trans, comme nous l'avons fait
auparavant. Le tableau croisé dynamique aura l'apparence suivante :
Une fois l'association dans la table Trans rompue, QlikView ne peut plus
garder trace de ce qui a déjà été comptabilisé dans les sous-totaux. Les deux
occurrences de B sont comptées deux fois et les sous-totaux sont trop élevés.
Cette situation doit être évitée, et les tables déconnectées doivent donc être
utilisées avec prudence avec des dimensions non hiérarchiques.
Remarque Les Totaux (tels qu'ils sont définis dans l'onglet Expressions du
graphique) sont réglés sur Total de l'expression (option par
défaut) dans tous les cas ci-dessus. Si vous utilisez le mode
Somme de lignes, il n'y a pas de différence entre les deux cas.