Normalement, on effectue les sélections explicitement en cliquant sur les valeurs de champs qui nous intéressent. Pourtant, on peut aussi faire des sélections indirectement par des liens sémantiques. Ils sont similaires aux valeurs de champs, à la différence qu'ils décrivent les relations entre les objets plutôt que les objets eux-mêmes. Ils apparaissent sous la forme d'une liste de boutons.
Quand on clique sur un lien sémantique, une sélection est effectuée dans un autre champ.
Règles pour les tables sémantiques
On crée des liens sémantiques en chargeant des tables contenant les relations entre les objets.
- La table doit contenir exactement trois ou quatre colonnes.
- Une table sémantique doit contenir des relations soit entre les valeurs de différents champs, soit entre les valeurs d'un même champ. On ne peut mélanger les deux.
- L'instruction LOAD ou SELECT qui charge une table sémantique doit être précédée d'un qualificateur semantic pour montrer qu'il ne s'agit pas d'une table logique.
Normalement, on utilise quatre colonnes, la première contenant les valeurs qui ont une relation à une autre valeur de champ et la troisième contenant cette dernière valeur. La deuxième colonne doit contenir les noms des relations, et enfin, la quatrième doit contenir les noms des relations réciproques.
Si on utilise trois colonnes, aucun nom explicite n'est donné aux relations réciproques. Les noms de la deuxième colonne sont utilisés à la fois pour la relation et pour la relation réciproque. Ils sont alors précédés ou suivis de flèches.
Si les relations concernent des valeurs du même champ, la première et la troisième colonnes doivent avoir le même nom. De même, les noms des deuxième et quatrième colonnes, c'est-à-dire le type de relations, doivent être les mêmes. Toutefois, si les relations concernent des valeurs de différents champs, toutes les colonnes doivent porter des noms différents.
Extraction d'une table sémantique à partir de données
La table sémantique n'a pas forcément à exister comme table en dehors de QlikView. Il est plus facile d'extraire cette table de la table d'objets existante par une instruction LOAD séparée.
Dans l'exemple des présidents (presidents) du répertoire d'exemples de QlikView, le script servant à générer les liens Predecessor et Successor pourrait correspondre à celui-ci :
Directory presidents;
LOAD * from presdnts.csv (ansi, txt, delimiter
is ',', embedded labels);
Semantic LOAD
No -1 as No,
'Successor' as Relation,
No,
'Predecessor' as Relation
from presdnts.csv (ansi, txt, delimiter is ',',
embedded labels) where No > 1;
La deuxième instruction LOAD donne une table qui ressemble à celle de droite, et cette table est chargée comme table sémantique. La clause where sert à omettre le premier enregistrement, car le premier président serait autrement lié au président 0, qui n'existe pas.
Notez également que cette instruction LOAD contient deux champs nommés No et deux champs intitulés Relation. Une telle instruction LOAD provoquerait une erreur d'exécution du script si elle était utilisée pour charger une table interne, puisque la procédure de chargement pour une seule table interne exige qu'aucun champ n'ait le même nom qu'un autre. L'instruction SELECT correspondante n'est pas possible non plus, car la plupart des pilotes ODBC ont cette même exigence. On doit utiliser à la place la structure suivante si la table des présidents se trouve dans une base de données :
Connect to DataBase;
SELECT * from presdnts;
Alias No2 as No, Relation2 as Relation;
Semantic SELECT
No -1 as No,
'Successor' as Relation,
No as No2,
'Predecessor' as Relation2
from presdnts where No > 1;
L'exemple des présidents n'est qu'un exemple simple de l'utilisation des liens sémantiques. Il est également possible d'utiliser les liens sémantiques en généalogie, où ils peuvent correspondre, par exemple, au cousin, au frère ou à la sœur, à la grand-mère, etc., ou encore pour le personnel d'entreprises où les liens peuvent signifier supérieur, subordonné à, secrétaire (superior, reports to, secretary), etc.
Utilisation des valeurs liées comme noms de relations
Parfois, il est plus parlant d'utiliser la valeur de champ liée comme nom de la relation. Dans le cas des présidents, vous pouvez rassembler tous les prédécesseurs dans une colonne et tous les successeurs dans une autre :
Pour créer ces liens, le script suivant est nécessaire :
LOAD
No as DuplicateOfNo,
FirstName & ' ' & LastName as Name,
*
from presdnts.csv;
Semantic LOAD
No -1 as No,
FirstName & ' ' & LastName as Successor,
No as DuplicateOfNo,
'Dummy1'
from presdnts.csv where No > 1;
Semantic LOAD
No +1 as No,
FirstName &' ' & LastName as Predecessor,
No as DuplicateOfNo,
'Dummy2'
from presdnts.csv;
Lorsque vous cliquez sur un lien sémantique, une sélection est effectuée dans le champ de la troisième colonne, DuplicateOfNo, qui correspond toujours, dans la table sémantique, au numéro du président affiché sur le lien sémantique.
Cela peut ne pas apparaître évident au premier abord, mais les relations réciproques dans la construction ci-dessus sont presque inutiles. Elles montreraient le nom d'un président et, quand on cliquerait dessus, sélectionneraient le prédécesseur/successeur du président affiché. C'est pourquoi elles sont appelées Dummy1 et Dummy2, et seule la première relation (deuxième colonne) est utilisée.
Comme on ne veut pas que les relations de test apparaissent dans les listes de sélection, on doit traiter la deuxième et la quatrième colonne comme des types de relations différents. Cela signifie que la première et la troisième colonne doivent avoir des noms de champs distincts. Cela explique la présence de deux colonnes contenant le numéro du président, No et DuplicateOfNo.
Deux instructions semantic différentes sont nécessaires puisque l'on veut obtenir deux listes de sélection différentes avec relations.
Cet exemple peut également être reproduit avec des tables sémantiques à trois colonnes mais les listes de sélection contenant les relations réciproques troubleront alors très vraisemblablement l'utilisateur.
