Gestion des données hiérarchiques

Composante essentielle de toutes les solutions d'informatique décisionnelle (BI), les hiérarchies permettent de décrire des dimensions qui contiennent naturellement différents niveaux de granularité. Certaines sont simples et intuitives tandis que d'autres se révèlent complexes et exigent une réflexion approfondie pour être modélisées correctement.

À mesure que l'on descend dans la hiérarchie, ses membres font l'objet d'une description de plus en plus détaillée. Par exemple, dans une dimension comportant les niveaux Market, Country, State et City, le membre Americas figure au premier niveau de la hiérarchie, le membre U.S.A. au deuxième niveau, le membre California au troisième niveau et le membre San Francisco au dernier niveau. California est plus précis que U.S.A., et San Francisco est plus précis que California.

Le stockage de hiérarchies dans un modèle relationnel est une problématique courante aux solutions multiples. Il existe plusieurs approches :

• la hiérarchie horizontale ;
• le modèle de liste de contiguïté ;
• la méthode d'énumération Path ;
• le modèle d'ensembles imbriqués ;
• la liste des ancêtres.

Pour les besoins de ce didacticiel, nous allons créer une liste des ancêtres, car elle présente la hiérarchie sous une forme directement exploitable dans une requête. Vous trouverez des informations complémentaires sur les autres approches sur Qlik Community.

Préfixe Hierarchy

Le préfixe Hierarchy est une commande de script à placer devant l'instruction LOAD ou SELECT et qui charge une table de nœuds adjacents. L'instruction LOAD doit comporter au moins trois champs : un ID correspondant à une clé unique pour le nœud, une référence au parent et un nom.

Le préfixe permet de transformer une table chargée en table de nœuds étendus ; une table comportant un certain nombre de colonnes supplémentaires ; une par niveau hiérarchique.

Procédez comme suit :

1. Créez une application et nommez-la.
2. Ajoutez une nouvelle section de script dans l'éditeur de chargement de données.
3. Appelez la section Wine.

4. Sous DataFiles dans le menu droit, cliquez sur Sélectionner des données.

5. Téléchargez, puis sélectionnez Winedistricts.txt.
6. Dans la fenêtre Sélection de données provenant de, désactivez les champs Lbound et RBound pour qu'ils ne soient pas chargés.
7. Cliquez sur Insérer le script.
8. Insérez ce qui suit au-dessus de l'instruction LOAD :

Hierarchy (NodeID, ParentID, NodeName)

Le script devrait avoir l'aspect suivant :

Hierarchy (NodeID, ParentID, NodeName)
LOAD
    NodeID,
    ParentID,
    NodeName
FROM [lib://DataFiles/Winedistricts.txt] 
(txt, utf8, embedded labels, delimiter is '\t', msq);			

9. Cliquez sur Charger les données.
10. La section Aperçu du visionneur de modèle de données vous permet d'afficher la table résultante.

La table de nœuds étendus résultante comporte exactement le même nombre d'enregistrements que sa table source : un par nœud. La table de nœuds étendus est très pratique, car elle remplit plusieurs exigences relatives à l'analyse d'une hiérarchie dans un modèle relationnel :

• Tous les noms de nœud figurent dans une seule et même colonne, pour pouvoir être utilisés dans les recherches.
• De plus, les différents niveaux de nœud ont été étendus en un champ chacun ; ces champs sont utilisables dans des groupes hiérarchiques ou comme dimensions dans les tableaux croisés dynamiques.
• De plus, les différents niveaux de nœud ont été étendus en un champ chacun ; ces champs sont utilisables dans des groupes hiérarchiques.
• Elle peut être définie pour contenir un chemin propre au nœud, qui répertorie tous les ancêtres dans le bon ordre.
• Elle peut être définie pour contenir la profondeur du nœud, c.-à-d. la distance par rapport à la racine.

La table résultante a l'aspect suivant :

Préfixe HierarchyBelongsTo

Comme le préfixe Hierarchy, le préfixe HierarchyBelongsTo est une commande de script à placer devant l'instruction LOAD ou SELECT et qui charge une table de nœuds adjacents.

Dans ce cas également, l'instruction LOAD doit comporter au moins trois champs : un ID correspondant à une clé unique pour le nœud, une référence au parent et un nom. Le préfixe permet de transformer la table chargée en table des ancêtres, une table comportant chacune des combinaisons ancêtre/descendant répertoriées sous forme d'enregistrement distinct. Il est donc très facile de trouver tous les ancêtres ou tous les descendants d'un nœud donné.

Procédez comme suit :

1. Modifiez l'instruction Hierarchy dans l'éditeur de chargement de données de la manière suivante :

HierarchyBelongsTo (NodeID, ParentID, NodeName, BelongsToID, BelongsTo)

1. Cliquez sur Charger les données.
2. La section Aperçu du visionneur de modèle de données vous permet d'afficher la table résultante.

La table des ancêtres remplit plusieurs exigences relatives à l'analyse d'une hiérarchie dans un modèle relationnel :

• Si l'ID de nœud représente les nœuds individuels, l'ID de l'ancêtre correspond à des arborescences et sous-arborescences complètes de la hiérarchie.
• Tous les noms de nœud existent à la fois en tant que nœuds et en tant qu'arborescences, et les deux peuvent être utilisés dans les recherches.
• Elle peut être définie pour contenir la différence entre la profondeur du nœud et la profondeur de l'ancêtre, c.-à-d. la distance par rapport à la racine de la sous-arborescence.

La table résultante a l'aspect suivant :

Autorisation

Il n'est pas rare qu'une hiérarchie soit utilisée à des fins d'autorisation. Prenons l'exemple d'une hiérarchie organisationnelle. Dans une entreprise, chaque responsable doit être autorisé à accéder à tout ce qui concerne son service, sections sous-jacentes comprises. Cependant, il ne doit pas nécessairement avoir accès aux informations des autres services.

Autrement dit, tous les employés ne sont pas habilités à accéder aux mêmes sous-arborescences de l'entreprise. La table d'autorisations peut revêtir l'aspect suivant :

Dans ce cas, Carol est autorisée à voir tout ce qui concerne le niveau CEO et les niveaux inférieurs ; Larry a accès au niveau Product et James, au niveau Engineering uniquement.

 

La hiérarchie est souvent stockée dans une table de nœuds adjacents. Dans cet exemple, pour résoudre ceci, vous pouvez charger la table de nœuds adjacents à l'aide de HierarchyBelongsTo et nommer le champ de l'ancêtre Tree.

Si vous souhaitez utiliser Section Access, chargez une copie de Tree en majuscules et nommez ce nouveau champ PERMISSIONS. Enfin, il reste à charger la table d'autorisations. Ces deux dernières étapes peuvent être effectuées à l'aide des lignes de script suivantes : Notez que la table TempTrees correspond à la table créée par l'instruction HierarchyBelongsTo.

Notez qu'il s'agit uniquement d'un exemple. Il n'y a aucun exercice correspondant à terminer dans Qlik Sense.

Cet exemple devrait produire le modèle de données suivant :