# 階層データの処理

階層構造は、すべてのビジネス インテリジェンス ソリューションの重要な部分で、異なる粒度レベルを含む軸を説明するために使用します。シンプルで直感的なものもあれば、正しくモデルを構築するためによく考える必要がある複雑なものもあります。

メンバーは階層の最上部から最下部に向かって、段階的に詳細になっていきます。例えば、軸に市場、国、州、市というレベルがある場合、南北アメリカ大陸は階層の最上部に位置し、米国は 2 番目のレベル、カリフォルニアは 3 番目、サンフランシスコは最下部のレベルに表示されます。カリフォルニアは米国よりも範囲が狭く、サンフランシスコはカリフォルニアよりさらに詳細度が増しています。

リレーショナル モデルにおける階層の保存は、複数のソリューションがある場合、よく問題になります。これには、いくつかのアプローチがあります。

* 横方向の階層
* 隣接リスト モデル
* 経路列挙方法
* 入れ子集合モデル
* 先祖リスト

このチュートリアルの目的においては、クエリーで直接使用できる形式の階層を提示するために、先祖リストを作成します。その他のアプローチの詳細については、Qlik Community を参照してください。

## Hierarchy プレフィックス

Hierarchy プレフィックスはスクリプト コマンドで、隣接するノード テーブルをロードする LOAD または SELECT ステートメントの前に置きます。LOAD ステートメントには、少なくとも 3 つの項目 (ノードの一意のキーである ID、親ノードへの参照、名前) が必要です。

プレフィックスはロードされたテーブルを展開ノード テーブルに変換します。テーブルには多数の追加列 (階層の各レベルごとに 1 つ) が含まれています。

次の手順を実行します。

1. 新しいアプリケーションを作成し、名前を付けます。

2. データ ロード エディターで新しいスクリプト セクションを追加します。

3. このセクションを Wine と呼びます。

4. 右のメニューの [DataFiles] で、[データを選択] をクリックします。

5. Winedistricts.txt をアップロードして選択します。

6. [Select data from] (データの選択元) ウィンドウで、Lbound と RBound 項目を選択解除してロードされないようにします。

7. [追加] をクリックします。

8. LOAD ステートメントの上に次の内容を入力します。

   ```
   Hierarchy (NodeID, ParentID, NodeName)
   ```

   これで、スクリプトは次のようになります。

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

9. [データのロード] をクリックします。

10. 結果テーブルを確認するには、データ モデル ビューアの [プレビュー] セクションを使用してください。

    結果の展開ノード テーブルには、ソース テーブル (ノードごとに 1 つ) と同じ数のレコードがあります。展開ノード テーブルは、リレーショナル モデルの階層を解析する、次のような多数の必要条件を満たしているため非常に実用的です。

    * すべてのノード名は 1 つの同じ列に存在するため、検索に使用できます。
    * さらに、さまざまなノード レベルがそれぞれ 1 つの項目 (ドリルダウン グループで、またはピボット テーブルの軸として使用可能な項目) に展開されます。
    * さらに、異なるノード レベルがそれぞれ 1 つの項目に展開されるため、項目をドリルダウン グループで使用することができます。
    * ノード固有のパスを含むように作成して、すべての祖先を正しい順番でリストすることができます。
    * ノードの深度 (ルートからの距離) も含めるよう作成することができます。

    この結果、テーブルは次のようになります。

    Hierarchy プレフィックスを使用してロードしたサンプル データのテーブル

    Hierarchy プレフィックスを使用してロードしたサンプル データのテーブル

    HierarchyHierarchy プレフィックスを使用してロードしたサンプル データのテーブル ![Hierarchy プレフィックスを使用してロードしたサンプル データのテーブル。](https://help.qlik.com/ja-JP/cloud-services/Subsystems/Hub/Content/Resources/Images/tutorial-hierarchyprefix-table.png)

## HierarchyBelongsTo プレフィックス

Hierarchy プレフィックス同様、HierarchyBelongsTo プレフィックスはスクリプト コマンドで、隣接するノード テーブルをロードする LOAD または SELECT ステートメントの前に置きます。

ここでもまた、LOAD ステートメントには、少なくとも 3 つの項目 (ノードの一意のキーである ID、親ノードへの参照、名前) が必要です。プレフィックスはロードされたテーブルを展開ノード テーブルに変換します。テーブルにはあらゆる先祖の組み合わせおよび、個別レコードとして子孫がリストされています。よって、特定ノードの先祖または子孫はすべて簡単に検索できます。

次の手順を実行します。

1. データ ロード エディターで、Hierarchy ステートメントを次のように修正します。
   ```
   HierarchyBelongsTo (NodeID, ParentID, NodeName, BelongsToID, BelongsTo)
   ```

1) [データのロード] をクリックします。
2) 結果テーブルを確認するには、データ モデル ビューアの [プレビュー] セクションを使用してください。

   先祖テーブルは、リレーショナル モデルの階層を解析する、次のような多数の要件を満たしています。
   * ノード ID が単一ノードを表す場合、先祖 ID 階層のツリー全体およびサブツリーを表します。
   * すべてのノード名は、ノードとしての役割およびツリーとして役割の両方に存在し、両方とも検索に使用できます。
   * ノード深度とサブツリーのルートからの距離である先祖深度の間の深度差異を含むよう、作成することもできます。

   この結果、テーブルは次のようになります。

   HierarchyBelongsTo プレフィックスを使用してロードしたデータのテーブル

   HierarchyBelongsTo プレフィックスを使用してロードしたデータのテーブル

   HierarchyBelongsToHierarchyBelongsTo プレフィックスを使用してロードしたデータのテーブル ![HierarchyBelongsTo プレフィックスを使用してロードしたデータのテーブル。](https://help.qlik.com/ja-JP/cloud-services/Subsystems/Hub/Content/Resources/Images/tutorial-hierarchybelongsto-table.png)

### [Authorization] (権限)

階層を承認に使用することは、珍しいことではありません。1 つの例としては、組織的な階層が挙げられます。各マネージャーが、すべてのサブ部門含め、自分の部門に関連するあらゆる権限を持っている必要があります。ですが、必ずしも他の部門を管理する権限を持つべきではない、というわけではありません。

組織的な階層の例

組織的な階層の例

組織的な階層の例 ![](https://help.qlik.com/ja-JP/cloud-services/Subsystems/Hub/Content/Resources/Images/ex_gen_Authorization1.png)

これは、閲覧を許可される組織内のサブツリーは人によって異なるということを意味します。承認テーブルは、例えば、以下のようになります。

承認テーブル

| ACCESS | NTNAME | PERSON | POSITION | PERMISSIONS |
| --- | --- | --- | --- | --- |
| USER | ACME\JRL | John | CPO | HR |
| USER | ACME\CAH | Carol | CEO | CEO |
| USER | ACME\JER | James | エンジニアリング部長 | エンジニアリング |
| USER | ACME\DBK | Diana | CFO | 財務 |
| USER | ACME\RNL | Bob | COO | 売上 |
| USER | ACME\LFD | Larry | CTO | 製品 |

この場合、Carol は CEO とその下の関係するすべての組織を閲覧でき、Larry はProduct 組織を、James は Engineering 組織のみを閲覧できます。

多くの場合、階層は隣接ノード テーブルに保存されます。この例では、これを解決するために、HierarchyBelongsTo を使用して隣接ノード テーブルをロードし、先祖項目Tree に名前を付けます。

Section Access を使用する場合は、Tree の大文字コピーをロードし、この新しい項目を PERMISSIONS とします。最後に、承認テーブルをロードする必要があります。最後の 2 つのステップは、次のスクリプト行を使用して実行することが可能です。TempTrees テーブルは HierarchyBelongsTo ステートメントによって作成されるテーブルです。

これはあくまで例です。Qlik Sense で行う付随する演習はありません。

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;

この例では、次のデータ モデルが生成されます。

データ モデル:Authorization、Trees、Fact、および Nodes テーブル

データ モデル:Authorization、Trees、Fact、および Nodes テーブル

データ モデル:AuthorizationAuthorization、TreesTrees、FactFact、および NodesNodes テーブル ![データ モデル: Authorization、Trees、Fact、Nodes の各テーブル。](https://help.qlik.com/ja-JP/cloud-services/Subsystems/Hub/Content/Resources/Images/ex_gen_Authorization3.png)