親子階層のディメンションの作成と管理

親子階層とは、タイプがすべて同じメンバーの階層のことです。

これは、同一タイプのメンバーが単一レベルの階層にのみ出現するレベルベースの階層と対照的です。

この項では、次の項目について説明します。

親子階層について

現実世界で最も一般的な親子階層の例として、組織の階層図があげられます。

組織の階層図には、次のことが当てはまります。

組織内の各個人は従業員です。
各従業員は、1人のマネージャの直属となります(最上位のマネージャを除く)。
組織階層には多くのレベルがあります。

これらの条件は、親子階層の基本機能を示しています。それらの機能とは次のとおりです。

親子階層は1つの論理表(Employees表など)をベースとします。
表の各行には2つの識別キーが含まれます。1つはメンバー自身を識別するキー、もう1つはそのメンバーの親を識別するキーです。たとえば、Emp_IDとMgr_IDです。

この図は、複数レベルの親子階層の例を示しています。

GUID-904079E9-38E3-4DC0-8DFA-163D271BAE64-default.gifの説明

次の表は、Employees表の行とキー値によってこの親子階層を表す様子を示しています。

Emp_ID	Mgr_ID
Andrew	null
Barbara	Andrew
Carlos	Andrew
Dawn	Barbara
Emre	Barbara

特定の論理ディメンションをベースとするプレゼンテーション階層を作成することによって、Oracle BIアンサーのユーザーに親子階層の論理ディメンションを提示できます。プレゼンテーション・レイヤーに階層を作成することにより、ユーザーは階層ベースの問合せを作成することができます。詳細は、プレゼンテーション階層とプレゼンテーション・レベルでの作業を参照してください。

この項では、次の項目について説明します。

親子階層のレベルと距離について

レベルベース階層と異なり、親子階層のディメンション・メンバーはすべて1つの論理列に存在します。

親子階層では、メンバーの親は同じ論理列の、親キーが指す別の行にあります。これは、メンバーの親が同じ行の別の論理列にあるレベルベース階層とは異なります。つまり、親子階層のナビゲーションはデータ値に従い、レベルベース階層のナビゲーションはメタデータ構造に従います。

レベルベース階層では、各レベルは名前が付けられ、分析に役立つと見なされる現実世界の属性またはカテゴリに対応する、階層の位置を占めます。設計時にレベルの数が固定されるレベルベース階層とは異なり、親子階層の深さには制限がなく、深さは新しいデータに応じて実行時に変更できます。

すべてのOracle BIサーバー親子階層には、2つのシステム生成エンティティ(「合計」と「詳細」)があり、それらは、論理ディメンションが作成されるときに親子階層ごとに自動的に定義されます。「詳細」エンティティには、すべての階層メンバーが含まれます。

これら2つのシステム生成エンティティは、親子階層内の祖先と子孫の間にある暗黙のメンバー間レベルとは異なるものです。この項では、これらの暗黙のレベルは親子階層レベルと呼びます。

レベルと緊密に関連付けられているのは、親子階層内の距離という概念です。別のメンバーからあるメンバーまでの距離が、そのメンバーから祖先または子孫までの親子階層レベルの数です。たとえば、メンバーからその親までの距離は常に1であり、AndrewからEmreまでの距離は2です。この例の図は、親子階層についてを参照してください。

親子関係表について

リレーショナル表では、親子階層内の異なるメンバー間の関係は、関連付けられているベース表内の識別キーによって暗黙に定義されます。

ただし、リレーショナル表に定義されたOracle BIサーバーの各親子階層では、個別の親子関係表内にメンバー間の関係を明示的に定義する必要があります。

親子関係表には次の4つの列を含める必要があります。

メンバーを識別する列
メンバーの祖先を識別する列

注意:
この祖先は、そのメンバーの親の場合もあれば、より上位の祖先の場合もあります。
親子階層におけるメンバーから祖先までのレベルの数を指定する距離列
メンバーがリーフ・メンバーであるかどうかを指定するリーフ列(1=はい、0=いいえ)

列名はユーザーが定義することができます。列のデータ型は、次の条件を満たす必要があります。

メンバーを識別する列および祖先を識別する列は、階層メンバーが含まれる論理表内の関連する列と同じデータ型を持つ。

注意:
表に示す例では、可読性を考慮してテキスト文字列を使用しています。ただし通常は、member_keyおよびancestor_keyには整数の代理キーを使用します(それらがソースのディメンション表に存在する場合)。
距離列とリーフ列はINTEGER列です。

親子関係表内の行については、次の条件に注意してください。

各メンバーは、距離が0の自身を指し示す行を持つ必要があります。
各メンバーは、それぞれの祖先を指し示す行を持つ必要があります。ルート・メンバーの場合、これは親の値と距離の値がnullである終了行です。

この表は親子関係表の例を示しています。各行は、従業員のメンバー間の関係を表しています。親子階層についての図を参照してください。

Member_Key	Ancestor_Key	Distance	Isleaf
Andrew	Andrew	0	0
Barbara	Barbara	0	0
Carlos	Carlos	0	0
Dawn	Dawn	0	0
Emre	Emre	0	0
Andrew	null	null	0
Barbara	Andrew	1	0
Carlos	Andrew	1	1
Dawn	Barbara	1	1
Dawn	Andrew	2	1
Emre	Barbara	1	1
Emre	Andrew	2	1

親子階層の定義時に起動できるウィザードを使用して、親子関係表を作成および移入するスクリプトを生成します。スクリプトの作成およびロードについては次の点に注意してください。

作成スクリプトは1回のみ実行し、データ・ソース内に親子関係表を作成します。
ディメンション表内のデータに変更があった場合は、毎回ロード・スクリプトを実行する必要があります。このため、ロード・スクリプトは通常はETL処理時に呼び出します。ロード・スクリプトは親子関係表全体を再ロードします。インクリメンタル処理ではありません。

ウィザードを使用しない場合は、親子関係表を手動で作成し、その表を親子階層に関連付ける前に物理レイヤーにインポートする必要があります。またこの場合、親子階層内のメンバー間の関係を記述するのに必要なデータを表に移入するのもユーザーの役割です。

親子階層のディメンションの作成

親子階層で定義する必要のある主要な要素として、メンバーの識別列とメンバーの親の識別列があります。

この基本原則は、階層の派生元となるデータ・ソースにかかわらず、すべての親子階層に当てはまります。

リレーショナル表に基づく親子階層には、親子関係表が付属している必要があります。詳細は、親子関係表についてを参照してください。

親子階層のディメンションを作成するには:

管理ツールのビジネス・モデルとマッピング・レイヤーで、次のいずれかの手順を実行します。
- ビジネス・モデルを右クリックし、「新規オブジェクト」→「論理ディメンション」→「親子階層を持つディメンション」を選択します。このオプションは、ビジネス・モデル内にディメンションが関連付けられていない論理ディメンション表が1つ以上ある場合にのみ選択できることに注意してください。
- ディメンションが関連付けられていないディメンション表を右クリックし、論理ディメンションの作成→「親子階層を持つディメンション」を選択します。
「論理ディメンション」ダイアログの「一般」タブで、ディメンションの名前を入力します。
「メンバー・キー」フィールドの横の「参照」をクリックします。
「参照」ウィンドウに、ビジネス・モデル内の論理ディメンション表とその主キーが表示されます。
親子階層のメンバー・キーを選択し、「OK」をクリックします。
「親キー」フィールドの横の「参照」をクリックします。
「参照」ウィンドウに、ステップ4で選択した論理表の主キー以外の列が表示されます。
親子階層の親キーとなる列を選択し、「OK」をクリックします。
ステップ4で選択した論理表がリレーショナル表ソースに基づいていない場合は、「OK」をクリックしてディメンションの作成プロセスを終了します。
ステップ4で選択した論理表がリレーショナル表ソースに基づいている場合は、ディメンション定義プロセスを続行して、階層の親子関係表を設定する必要があります。詳細は、親子関係表の定義を参照してください。

親子関係表の定義

親子階層がリレーショナル表に基づく場合、親子関係表を定義する必要があります。

詳細は、親子関係表についてを参照してください。

親子関係表を作成するときには、次のいずれかのオプションを選択する必要があります。

以前に作成した親子関係表を選択します。
ウィザードを使用して、親子関係表の作成とデータ移入を行うスクリプトを生成します。

親子関係表を定義するには:

「論理ディメンション」ダイアログで「親子設定」をクリックします。
「親子関係表の設定」ウィンドウが表示されます。論理表および論理表ソースの値が設定されています。

この図は、「親子関係表の設定」ダイアログを示しています。

GUID-83848D5B-B72C-4D02-975D-1BC6EC65DAD8-default.gifの説明
階層の親子関係表を手動で定義するか、定義を実行するウィザードを起動します(後者をお薦めします)。
- 手動プロセスを開始するには、ステップ3に進みます。
- ウィザードを起動するには、ステップ7に進みます。
「親子関係表の選択」ボタンをクリックし、親子階層の親子関係表を手動で定義するプロセスを開始します。
親子階層の親子関係表の役割を果たす物理表を選択します。この表は、この時点で物理レイヤーに存在している必要があります。
親子関係表には、階層用に選択した論理表の中でメンバー間の関係がどのように導出されるかを示す列が4つ以上存在している必要があります。詳細は、親子関係表についてを参照してください。
次のように、物理的な親子関係表の4つの列を「親子表の列詳細」エリア内のフィールドにマップします。
- 「メンバー・キー」列を選択します。
- 「親キー」列を選択します。
- 「関係性」列を選択します。
- 「リーフ・ノード識別子」列を選択します。
「OK」をクリックし、再度「OK」をクリックして、親子関係表の手動定義プロセスを終了します。
「親子関係表の作成」ボタンをクリックしてウィザードを起動します。
親子関係表の生成ウィザードでは、親子関係表の作成とデータ移入を行うためのSQLスクリプトが生成されます。ウィザードの終了時にOracle BIサーバーによって、ウィザード・セッションの中で選択されたディレクトリにスクリプトが格納されます。スクリプトを実行すると、メタデータ・リポジトリで利用可能な親子関係表が作成されます。

このウィザードには次の3つの主要なウィンドウがあります。
- スクリプトの場所
- 親子関係表の詳細
- スクリプトのプレビュー
「親子関係表の生成」の「スクリプトの場所」画面で、親子表を生成するためのDDLスクリプトの「名前」を入力し、生成スクリプトが格納される「場所」を選択します。
「親子表を移入するためのDDLスクリプト」の「名前」を入力し、移入スクリプトが格納される「場所」を選択します。
「次」をクリックします。
「親子関係表の詳細」画面で、親子関係表の「名前」を入力します。
「カタログ/スキーマ」フィールドの横の「参照」をクリックし、親子関係表のカタログまたはスキーマを選択します。
「次」をクリックします。
「スクリプトのプレビュー」ウィンドウで、2つのスクリプトを参照することができます。
「終了」をクリックします。
「親子関係表の設定」ウィンドウで「OK」をクリックします。
「論理ディメンション」ウィンドウで「OK」をクリックします。
親子関係表の生成ウィザードを使用して作成スクリプトおよびロード・スクリプトを生成した場合は、スクリプトを実行して、データ・ソース内に親子関係表を作成しデータをロードします。

親子階層の集計のモデリング

レベル・ベース階層のファクト表には、単一レベルの階層のファクトのみが含まれている場合があります。

上位レベルのディメンション・メンバーのファクトを計算するには、下位レベルのファクト表から、または上位レベルのサマリー表からファクトを集計します。

その一方で、親子階層では、次に関連する追加の決定を行うためにデータ・モデラーが必要です。

ファクト表でのベース・ファクトの格納方法
親子階層の上位メンバーのファクトを取得するための、ベース・ファクトの集計方法

この項では親子階層のファクトの格納および集計方法について説明しており、次の内容で構成されています。

親子階層のファクトの格納

親子階層のファクト表にベース・ファクトを格納する場合、2つのオプションがあります。

次のオプションを使用できます。

親子階層のリーフ・メンバーのみのファクトを格納します。
親子階層でリーフ以外のメンバーを含むすべてのレベルのメンバーのファクトを格納します。

親子階層の非リーフ・メンバーのファクトをリーフ・メンバーのファクトから完全に派生させることができる場合は、最初のオプションが適しています。たとえば、親子製品階層を使用していて、その中で実際の製品メンバーが階層のリーフ・メンバーとしてのみ表示される場合は、収益ファクト表にその製品階層のリーフ・メンバーの収益ファクトのみを記録するのが合理的です。製品階層の非リーフ・メンバー(製品カテゴリなど)の収益の数字を完全に派生させるには、階層の最下位にあるリーフ製品メンバーのファクトを集計します。

この図は、親子階層のリーフ・メンバーのファクトのみが格納される場合のデータの例を示しています。

次の表では、ディメンション表PRODUCT_DIMのデータの例を示しています。

MemberKey	Name	ParentKey
P1	Product1	C1
P2	Product2	C1
C1	Category1	C2
C2	Category2	C3
C3	Category3	-

次の表では、ファクト表REVENUE_FACTSのデータの例を示しています。

ProductKey	YearKey	Revenue
P1	2011	100,000
P1	2012	105,000
P2	2011	75,000
P2	2012	80,000

親子階層の任意のレベルのメンバーに対するファクトが格納される2番目のオプションは、非リーフ・メンバーのファクトがリーフ・メンバーのファクトから完全に派生していない場合に必要です。好例として、営業員の上司であるマネージャも営業員であるような営業員階層があります。マネージャも含めて、個人の営業員にそれぞれ異なる収益の数字を指定し、それをファクト表に格納できます。

この表は、この状況のデータの例を示しています。

リーフ・メンバーと非リーフ・メンバー両方のファクトの格納

次の表では、ディメンション表SALES_REP_DIMのデータの例を示しています。

MemberKey	Name	ParentKey
101	Phillip	201
102	Vivian	201
201	Jacob	301
202	Audrey	301
301	Ryan	-

次の表では、ファクト表REVENUE_FACTSのデータの例を示しています。

SalesRepKey	YearKey	Revenue
101	2012	1,200,000
102	2012	1,100,000
201	2012	250,000
202	2012	1,400,000

リーフ・メンバーと非リーフ・メンバー両方のファクトの格納が適切である別のケースとして、親子階層の集計ルールが複雑である場合や、問合せ時点での階層の集計が消耗的であり、問合せレスポンス時間が非常に長い場合などがあります。この場合、ファクト表には、リーフ・メンバーに対して格納されたファクトに加えて、非リーフ・メンバーに対して事前集計されたファクトも格納されます。

親子階層の集計

ファクト表に含まれているのがリーフ・メンバーと非リーフ・メンバー両方のデータであるか、またはリーフ・メンバーのみのデータであるかに関係なく、データ・モデラーは、親子階層の上位レベルの集計済ファクトを計算するために、格納済ファクトの集計方法を決定する必要があります。

データ・モデラーは、メジャーに対して適切な集計機能を選択するだけでなく、上位メンバーの値を計算するために、下位メンバーに記録されたファクト値をロールアップするかどうか決定する必要があります。親子階層の下位メンバーのファクトをロールアップすることが合理的である場合もあります。また、事前集計されたファクト表や、各メンバーのコントリビューションを個別に示すためのメジャーのように、親子階層の下位メンバーのファクトをロールアップすることが不適切な場合もあります。

親子階層の下位メンバーのファクトのロールアップ

ファクト表に親子階層のリーフ・メンバーのファクトのみが格納されている場合、またはファクト表に各メンバーの個別コントリビューションのみが記録されている場合は、親子階層の上位メンバーに対して適切な集計済ファクトを取得するために、ファクト表に格納された値のロールアップが必要になります。親子階層に沿ったファクトのロールアップは、親子関係表を使用してファクト表をディメンション表に結合することで実行できます。詳細は、モデルへの親子関係表の追加を参照してください。

例の製品収益ファクト表など、リーフ・メンバーのみのファクトを格納したファクト表の場合、このモデリング手法によって、リーフ・レベルのメンバーの全ファクトを適切に要約した集計値が計算されます。

リーフ・メンバーと非リーフ・メンバー両方の個別コントリビューションを格納したファクト表の場合、この手法によって、メンバーと、そのメンバー下の全メンバーの個別コントリビューションを要約した階層集計が計算されます。

個別コントリビューション・メジャーのモデリング

複数メンバーの個別コントリビューションをロールアップした要約済の階層をレポートするだけでなく、各メンバーの個別コントリビューションをレポートできるようにするために、データ・モデラーは2つの別個のファクト論理表ソースを作成する必要があります。1つのファクト論理表ソースでは、ベース・ファクト表と親子関係表をマップします。これは、階層集計メジャーの論理表ソースです。もう1つのファクト論理表ソースでは、ファクト表の別名のみがマップされます。このファクト表の別名は、親子関係表を通して間接的に結合するのではなく、ディメンション表と直接結合する必要があります。これは、個別コントリビューション・メジャーの論理表ソースです。

事前集計済メジャーのモデリング

ファクト表の中には、事前集計されたデータが含まれ、それらが親子階層のすべてのメンバーに移入されるものがあります。たとえば、ルート・メンバーのファクト値が、そのすべての子孫メンバーのデータの集計とともに移入される場合があります。誤った結果が生じるのを避けるため、問合せではこのディメンションのメンバーを集計しないようにすることが重要です。

こうした種類の親子階層を正しくモデル化するには、IsAncestorやIsDescendantなどの階層フィルタ関数をサポートするため、親子関係表を作成する必要があります。ただし、親子関係表を通じて結合することなく、親子ディメンション表を直接結合することができます。これにより、すべての子孫をたどることはせずに、事前集計されたメンバー値が返されるようになります。

注意:

"self"行のみが含まれるように親子関係表スクリプトを修正することは避けてください。そのような変更を行うと、IsAncestor関数およびIsDescendant関数が正しく動作しなくなります。

この種類のディメンションの集計を正しく行うには、最初に、親子階層が集計される際に総計としてどのようなデータが必要かを特定する必要があります。たとえば、階層に1つのルート・メンバーが含まれており、このルート・メンバーにおいて事前集計された値を表示するとします。この場合、親子階層の合計レベルにマップされた追加のファクト論理表ソースを最初に作成します。次に、論理表ソースにおいてルート・メンバーのみを選択するWHERE句フィルタを作成します。

このモデルを採用した場合、親子階層の合計レベルの問合せでは、Oracle BIサーバーは集計論理表ソースを選択し、ルート・メンバーのWHERE句フィルタを適用します。詳細レベルの問合せでは、Oracle BIサーバーは詳細論理表ソースを選択し、事前集計されたメンバー値を返します。いずれの場合でも、各レベルに事前集計されたソースが存在するため、集計ルールがどのように設定されているかは関係ありません。

このアプローチは、問合せが親子階層の合計レベルまたは詳細レベルのいずれかである場合にのみ動作することに注意してください。ただし、親子ディメンションの一意ではない属性によってグループ化された問合せの場合、集計は正しくない可能性があります。たとえば、EmployeeディメンションにLocation属性があり、問合せがEmployee.Locationでグループ化される場合、ある従業員は同じ場所の別の従業員の部下であることが一般的であるため、二重のカウントが生じることになります。このため、ファクト表に事前集計されたメンバー値が含まれている場合は、親子ディメンションの一意ではない属性でグループ化することは避けてください。こうした属性によるグループ化が避けられない場合は、個別のディメンションとしてモデル化する必要があります。

モデルへの親子関係表の追加

下位メンバーからのファクトをロールアップして集計する必要のあるファクト表のメジャーについては、親子関係表が含まれるように物理レイヤーの結合を編集する必要があります。

また、適切な論理表ソースにその親子関係表を追加する必要があります。

注意:

親子階層または個別コントリビューション・メジャーに対して事前集計されたデータが含まれているファクト表については、親子関係表を通して結合するのではなく、親子ディメンション表をファクト表と直接結合する必要があります。

親子ディメンション表とファクト表を直接結合することで、すべての子孫をロールアップするのではなく、事前集計済の値または個別のコントリビューション値が返されるようになります。すべてのメンバーに事前集計されたデータを移入するときには、重複カウントを防ぐために親子階層表を論理表ソースに追加しないでください。詳細は、事前集計済メジャーのモデリングを参照してください。

親子関係表をモデルに追加するには:

管理ツールのリポジトリの物理レイヤーで物理図を開き、親子関係表とそれに関連するディメンション表およびファクト表を表示します。これを行うには、該当する物理表を右クリックし、「物理図」→「選択されたオブジェクトのみ」を選択します。
ディメンション表から各ファクト表への直接結合を削除します。
次に示すように、親子関係表を経由して各ファクト表からディメンション表への結合を作成します。
1. 祖先キーを使用して、親子関係表からディメンション表への結合を作成します。
2. メンバー・キーを使用して、ファクト表から親子関係表への結合を作成します。
ビジネス・モデルとマッピング・レイヤーで、親子階層で使用している論理ファクト表の論理表ソースをダブルクリックします。
「論理表ソース」ダイアログの「一般」タブで、「追加」ボタンをクリックします。
物理レイヤー内で親子関係表を見つけ、「選択」をクリックします。
「論理表ソース」ダイアログで「OK」をクリックします。

リレーショナル表をベースとした親子階層の維持

親子階層がリレーショナル表に基づく場合、親子関係表のデータは、ディメンション内のメンバー間関係を正確に反映する必要があります。

親子関係表の作成とデータ移入のためのスクリプトを手動で作成したか、親子関係表の生成ウィザードを使用してスクリプトを作成しました。それらのスクリプトを実行する必要があります。また、階層内の親子関係の整合性を保つために、必要に応じて何度でもスクリプトを適合させる必要があります。通常は、移入スクリプトをETLプロセスに追加して、ディメンション表が更新されたらそのスクリプトも実行されるようにします。