親子階層の集計について
親子階層の上位レベルのメンバーの集計ファクトを計算するには、ストアド・ファクトの集計方法を決定する必要があります。
メジャーに対して適切な集計関数を選択するだけでなく、上位メンバーの値を計算するために、下位メンバーに記録されたファクト値をロールアップするかどうか決定する必要があります。 親子階層の下位メンバーのファクトをロールアップすることが合理的である場合もあります。 また、事前集計されたファクト表や、各メンバーのコントリビューションを個別に示すためのメジャーのように、親子階層の下位メンバーのファクトをロールアップすることが不適切な場合もあります。
親子階層の下位レベル・メンバーからのファクトのロールアップ
ファクト表に親子階層のリーフ・メンバーのファクトのみが格納されている場合、またはファクト表に各メンバーの個別コントリビューションのみが記録されている場合は、親子階層の上位メンバーに対して適切な集計済ファクトを取得するために、ファクト表に格納された値のロールアップが必要になります。 親子関係表を介してファクト表をディメンション表に結合することにより、親子階層に沿ってファクトをロールアップできます。「セマンティック・モデルへの親子関係表の追加」を参照してください。
リーフ・メンバーのみのファクトを格納したファクト表(製品収益ファクト表など)の場合、このモデリング手法によって、リーフ・レベルのメンバーの全ファクトを適切に要約した集計値が計算されます。
リーフ・メンバーと非リーフ・メンバー両方の個別コントリビューションを格納したファクト表の場合、この手法によって、メンバーと、そのメンバーの全メンバーの個別コントリビューションを要約した階層集計が計算されます。
個々の拠出金メジャーのモデリング
複数メンバーの個別コントリビューションをロールアップした要約済の階層をレポートするだけでなく、各メンバーの個別コントリビューションをレポートするには、2つの別個のファクト論理表ソースを作成する必要があります。 1つのファクト論理表ソースでは、ベース・ファクト表と親子関係表をマップします。 これは、階層集計メジャーの論理表ソースです。 もう1つのファクト論理表ソースでは、ファクト表の別名のみがマップされます。 このファクト表の別名は、親子関係表を介して間接的に結合するのではなく、ディメンション表と直接結合する必要があります。 これは、個別コントリビューション・メジャーの論理表ソースです。
事前集計済メジャーのモデリング
ファクト表の中には、事前集計されたデータが含まれ、それらが親子階層のすべてのメンバーに移入されるものがあります。 たとえば、ルート・メンバーのファクト値が、そのすべての子孫メンバーのデータの集計とともに移入される場合があります。 誤った結果が生じるのを避けるため、問合せではこのディメンションのメンバーを集計しないようにすることが重要です。
こうした種類の親子階層を正しくモデル化するには、IsAncestorやIsDescendantなどの階層フィルタ関数をサポートするため、親子関係表を作成する必要があります。 親子関係表を通じて結合することなく、親子ディメンション表とファクト表を直接結合することができます。これにより、すべての子孫をロールアップするのではなく、事前集計済のメンバーの値が返されるようになります。
self行のみが含まれるように親子関係表スクリプトを修正することは避けてください。そのような変更を行うと、IsAncestor関数およびIsDescendant関数が正しく動作しなくなります。
この種類のディメンションの集計を正しく行うには、親子階層が集計される際に総計としてどのようなデータが必要かを特定する必要があります。 たとえば、階層に1つのルート・メンバーが含まれており、このルート・メンバーにおいて事前集計された値を表示するとします。 親子階層の合計レベルにマップされた追加のファクト論理表ソースを最初に作成する必要があります。 次に、論理表ソースにおいてルート・メンバーのみを選択するWHERE句フィルタを作成します。
このモデルを使用すると、親子階層の合計レベルにある問合せの場合、Oracle Analytics問合せエンジンは集計論理表ソースを選択し、ルート・メンバーのWHERE句フィルタを適用します。 詳細レベルの問合せの場合、Oracle Analytics問合せエンジンは詳細な論理表ソースを選択し、事前に集計されたメンバー値を返します。 いずれの場合でも、各レベルに事前集計されたソースが存在するため、集計ルールがどのように設定されているかは関係ありません。
このアプローチは、問合せが親子階層の合計レベルまたは詳細レベルである場合にのみ使用します。 親子ディメンションの一意ではない属性によってグループ化された問合せの場合、集計は正しくない可能性があります。 たとえば、EmployeeディメンションにLocation属性があり、問合せがEmployee.Locationでグループ化される場合、従業員は同じ場所の別の従業員の部下であることが一般的であるため、二重のカウントが生じる可能性があります。 このため、ファクト表に事前集計されたメンバー値が含まれている場合は、親子ディメンションの一意ではない属性でグループ化することは避けてください。 こうした属性によるグループ化が避けられない場合は、個別のディメンションとしてモデル化する必要があります。