Zu Hauptinhalt springen
Handhabung hierarchischer Daten

AUF DIESER SEITE

Handhabung hierarchischer Daten

Hierarchien sind ein wichtiger Bestandteil von Business Intelligence Lösungen, die dazu herangezogen werden, Dimensionen zu beschreiben, die von Haus aus unterschiedliche Detailtiefen aufweisen. Manche sind einfach und intuitiv, während andere recht komplex sind und eingehend durchdacht werden müssen, um richtig dargestellt zu werden.

Die einzelnen Hierarchiepunkte nehmen von oben nach unten stets an Detailtiefe zu. Beispiel: In einer Dimension mit den Ebenen Markt, Land, Bundesland und Stadt befindet sich Amerika auf der obersten Hierarchieebene, die USA befinden sich auf der zweiten Ebene, Kalifornien auf der dritten Ebene und San Francisco auf unterster Ebene. Kalifornien ist spezifischer als USA und San Francisco wiederum spezifischer als Kalifornien.

Das Speichern von hierarchischen Strukturen in einem relationalen Modell ist eine häufig anzutreffende, anspruchsvolle Aufgabe, für die es mehrere Lösungen gibt. Es gibt diverse Lösungsansätze:

  • Die horizontale Hierarchie
  • Das Adjazenzlisten-Modell
  • Die Path Enumeration Method
  • Das Nested-Sets-Modell
  • Der Stammbaum

Im Rahmen dieses Tutorials erstellen wir einen Stammbaum, da dies eine hierarchische Struktur ist, die wir direkt für eine Anfrage verwenden können. Weitere Informationen zu den anderen Lösungsansätzen finden Sie in der Qlik Community.

Hierarchy -Zusatz

Der Hierarchy-Zusatz ist ein Skriptbefehl, der vor einem LOAD oder SELECT-Befehl zum Einsatz kommt, mithilfe dessen eine Tabelle mit benachbarten Knoten geladen wird. Der LOAD-Befehl muss mindestens drei Felder enthalten: eine ID als eindeutigen Schlüssel für den Knoten, eine Referenz zum übergeordneten Knoten und einen Namen.

Durch den Zusatz wird die geladene Tabelle in eine Tabelle mit erweiterten Knoten umgewandelt. Diese Tabelle verfügt über zusätzliche Spalten, eine Spalte für jede Hierarchieebene.

Gehen Sie folgendermaßen vor:

  1. Erstellen Sie eine neue App und geben Sie ihm einen Namen.
  2. Fügen Sie einen neuen Skriptabschnitt im Dateneditor hinzu.
  3. Rufen Sie den Abschnitt Wine auf.
  4. Klicken Sie im rechten Menü unter DataFiles auf Daten auswählen.

  5. Laden Sie Winedistricts.txt hoch und wählen Sie die Datei aus.
  6. Deaktivieren Sie im Fenster Daten auswählen aus die Felder Lbound und RBound, damit sie nicht geladen werden.
  7. Klicken Sie auf Skript einfügen.
  8. Geben Sie Folgendes oberhalb der LOAD-Anweisung ein:
  9. Hierarchy (NodeID, ParentID, NodeName)

    Ihr Skript sollte folgendermaßen aussehen:

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

  10. Klicken Sie auf Daten laden.
  11. Verwenden Sie zum Anzeigen der resultierenden Tabelle den Vorschau-Abschnitt der Datenmodellansicht.
  12. Die erstellte Tabelle mit aufgeschlüsselten Ebenen verfügen über exakt so viele Datensätze wie die Quelltabelle: einen pro Knoten. Die Tabelle mit aufgeschlüsselten Ebenen ist ziemlich praktisch, da sie eine Reihe entscheidender Voraussetzungen für die Analyse einer Hierarchie in einem relationalen Modell erfüllt:

    • Alle Knotennamen sind in einer Spalte aufgeführt, sodass sie für die Suche herangezogen werden können.
    • Zudem wurden die verschiedenen Knotenebenen auf jeweils ein Feld aufgeschlüsselt. Diese Felder können in Drilldown-Gruppen oder als Dimensionen in Pivottabellen verwendet werden.
    • Zudem wurden die verschiedenen Knotenebenen auf jeweils ein Feld aufgeschlüsselt. Diese Felder können für Drilldown-Gruppen verwendet werden.
    • Sie kann einen eindeutigen Pfad für den Knoten enthalten, der alle übergeordneten Knoten in der richtigen Reihenfolge auflistet.
    • Sie kann auch die Anzahl der Ebenen zwischen dem Knoten und der Wurzel enthalten.

    Die sich ergebende Tabelle sieht folgendermaßen aus:

    Tabelle mit Beispieldaten, die mit dem Hierarchy-Zusatz geladen wurden
    Table showing sample of data loaded using Hierarchy prefix.

InformationshinweisWeitere Informationen zu Hierarchien finden Sie in folgendem Blog-Eintrag in Qlik Community: Hierarchies (Hierarchien)

HierarchyBelongsTo-Zusatz

Wie der Hierarchy-Zusatz ist der HierarchyBelongsTo-Zusatz ein Skriptbefehl, der vor einer LOAD- oder SELECT-Anweisung zum Einsatz kommt, mithilfe dessen eine Tabelle mit benachbarten Knoten geladen wird.

Auch hier muss die LOAD-Anweisung mindestens drei Felder enthalten: eine ID als eindeutigen Schlüssel für den Knoten, eine Referenz zum übergeordneten Knoten und einen Namen. Dieser Zusatz wandelt die geladene Tabelle in eine Stammtabelle um. Diese Tabelle führt alle Kombinationen von übergeordneten und nachgeordneten Knoten in einem gesonderten Datensatz auf. Daher lassen sich alle übergeordneten und untergeordneten Knoten eines bestimmten Knotens einfach ausfindig machen.

Gehen Sie folgendermaßen vor:

  1. Ändern Sie die Hierarchy-Anweisung im Dateneditor wie folgt:
  2. HierarchyBelongsTo (NodeID, ParentID, NodeName, BelongsToID, BelongsTo)
  1. Klicken Sie auf Daten laden.
  2. Verwenden Sie zum Anzeigen der resultierenden Tabelle den Vorschau-Abschnitt der Datenmodellansicht.
  3. Die Stammtabelle erfüllt eine Reihe entscheidender Voraussetzungen für die Analyse einer Hierarchie in einem relationalen Modell:

    • Falls die Knoten-ID die einzelnen Knoten darstellt, stellt die ID der übergeordneten Knoten den gesamten Baum und die Teilbäume der Hierarchie dar.
    • Alle Knotennamen bestehen sowohl in der Rolle als Knoten als auch in der Rolle als Baum und beide können für die Suche herangezogen werden.
    • Die Stammtabelle kann auch die Tiefendifferenz zwischen der Knotentiefe und der Tiefe des übergeordneten Knotens enthalten, d. h. den Abstand von der Wurzel des Teilbaums.

    Die sich ergebende Tabelle sieht folgendermaßen aus:

    Tabelle mit den Daten, die mit dem HierarchyBelongsTo-Zusatz geladen wurden
    Table showing data loaded using HierarchyBelongsTo prefix.

Autorisierung

Hierarchien werden nicht selten für die Autorisierung verwendet. Ein Beispiel dafür ist die Organisationshierarchie. Ein Führungsverantwortlicher sollte Einsicht in alles haben, was zu seiner Abteilung gehört, auch in sämtliche Unterabteilungen. Er sollte jedoch nicht zwingend Einsicht in andere Abteilungen haben.

Beispiel einer Organisationshierarchie

Das bedeutet, dass unterschiedliche Personen andere Teilbäume der Organisation einsehen können. Die Autorisierungstabelle sieht möglicherweise folgendermaßen aus:

Autorisierungstabelle
ACCESS NTNAME PERSON POSITION PERMISSIONS
USER ACME\JRL John CPO Personal
USER ACME\CAH Carol CEO CEO
USER ACME\JER James Technischer Leiter Technik
USER ACME\DBK Diana CFO Finanzen
USER ACME\RNL Bob COO Verkauf
USER ACME\LFD Larry CTO Produkt

In diesem Fall kann Carol alles ansehen, was zu CEO und darunter gehört; Larry kann die Product-Organisation ansehen und James kann lediglich die Engineering-Organisation einsehen.

Example:  

Oft wird die Hierarchie in einer Tabelle mit benachbarten Knoten gespeichert. Laden Sie zur Behebung des Problems in diesem Beipiel die Tabelle mit benachbarten Knoten anhand von HierarchyBelongsTo und nennen Sie das Feld des übergeordneten Knotens Tree.

Wenn Sie Section Access verwenden möchten, laden Sie eine Kopie in Großbuchstaben von Tree und nennen Sie dieses neue Feld PERMISSIONS. Abschließend müssen Sie die Autorisierungstabelle laden. Die letzten beiden Schritte können mithilfe der folgenden Skriptzeilen durchgeführt werden. Beachten Sie, dass die TempTrees-Tabelle die Tabelle ist, die mit der HierarchyBelongsTo-Anweisung erstellt wurde.

Beachten Sie, dass es sich hierbei nur um ein Beispiel handelt. Es sind keine in Qlik Sense zu bearbeitenden Übungen vorhanden.

Trees: LOAD *, Upper(Tree) as PERMISSIONS Resident TempTrees; Drop Table TempTrees;   Section Access; Authorization: LOAD ACCESS, NTNAME, UPPER(Permissions) as PERMISSIONS From Organization; Section Application;

Mit diesem Beispiel wird das folgende Datenmodell erstellt:

Datenmodell: Tabellen Authorization, Trees, Fact und Nodes
Data model: Authorization, Trees, Fact, and Nodes tables.