| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 12c (12.2.1.4.0) E96106-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 12c (12.2.1.4.0) E96106-04 |
|
|
前 |
次 |
この章のトピックは、次のとおりです:
ビジネス・モデルとマッピング・レイヤーにおいて、ディメンション・オブジェクトは論理列(属性)の階層構造を表します。
1つ以上の論理ディメンション表を、1つのディメンション・オブジェクトに関連付けることができます。
一般的なディメンションには、期間、製品、市場、顧客、仕入先、プロモーション条件、原材料、製造工場、輸送手段、メディアの種類、時刻などがあります。ディメンションは、ビジネス・モデルとマッピング(論理)レイヤーおよびプレゼンテーション・レイヤー内に存在します。
各ディメンションで、階層の構造に論理列を編成します。この構造は、業務で要求される組織ルールとレポート要件を示し、データの詳細ビューを取得するためにOracle BI Serverでディメンションへドリルインおよびドリルアクロスして使用するメタデータを提供します。
レベルベース階層(構造階層)を持つディメンション
レベルベース階層には、いくつかのタイプのメンバーが含まれており、同じタイプのメンバーが1つのレベルにのみ存在します。
親子階層(値階層)を持つディメンション
親子階層では、メンバーはすべて同じタイプを持ちます。
マルチディメンション・データ・ソース用のディメンションはソース内で定義されているため、ディメンション・レベル・キーは作成しません。ディメンションは特定のマルチディメンション・データ・ソースに固有です。ディメンションを個別に作成および操作することはできません。データ・ソース内の各キューブは、ビジネス・モデルとマッピング・レイヤー内に1つ以上のディメンションと1つのメジャーを持つ必要があります。
特定の論理ディメンションをベースとするプレゼンテーション階層オブジェクトを作成することによって、Oracle BIアンサーのユーザーにディメンションを提示できます。プレゼンテーション・レイヤーに階層を作成することにより、ユーザーは階層ベースの問合せを作成できます。「プレゼンテーション階層とプレゼンテーション・レベルでの作業」を参照してください。
プレゼンテーション・レイヤーのサブジェクト領域に各階層レベルの列を1つ以上追加することによって、ディメンション階層を提示することもできます。Oracle BIアンサーは、これらの階層列のドリルダウンをサポートしています。
各ビジネス・モデルは1つ以上のディメンションを持つことができ、各ディメンションは1つ以上の論理レベルを持つことができ、各論理レベルには1つ以上の属性(列)を関連付けることができます。
次の各項では、ディメンションの作成方法について説明します。
ディメンションには2つ以上の論理レベルが含まれます。論理レベルを作成する場合は、総計レベルを作成し、次に子レベルを作成して、一番下のレベルまでこれを繰り返す必要があります。
ディメンションの構成要素を次に示します。
総計レベル
総計レベルは、ディメンションのすべての合計の総計を表します。各ディメンションが持つことのできる総計レベルは1つのみです。総計レベルにはディメンションの属性は含まれず、レベル・キーはありません。総計レベルにはメジャーを関連付けることができます。それらのメジャーの集計レベルは、ディメンションの総計になります。総計レベルは列なしで存在できます。
レベル
レベルには1つ以上の列が存在している必要があります。表のすべての列を論理レベルに明示的に関連付ける必要はありません。論理レベルに関連付けられていない列は、ディメンション表に対応するディメンションの一番下のレベルに自動的に関連付けられます。同じディメンション表内のすべての論理列は、同じディメンションに関連付ける必要があります。
ディメンションのレベルの数に制限はありません。非常に複雑なSQL問合せを使用する場合、ディメンション内の2つか3つのレベルが問合せのパフォーマンスに影響を及ぼす可能性があります。
階層
各ディメンションには1つ以上の階層が含まれます。すべての階層に共通リーフ・レベルが必要です。たとえば、時間ディメンションには会計上の階層とカレンダ上の階層が含まれることがあり、それらは共有の日のレベルを持つことがあります。この例では、日には会計年度とカレンダ年の2つの親があり、それらはいずれも全ルート・レベルの子となります。
ビジネス・モデルとマッピング・レイヤーの論理階層は、プレゼンテーション・レイヤーの階層と異なり、独立したメタデータ・オブジェクトとして定義されません。論理階層はレベル間の関連を通じて暗黙に存在します。
1つのレベルで非常に多くのメンバーが指定されるのを避けるために、階層に中間レベルを定義できます。たとえば、500車種のモデルに関するデータを追跡する自動車会社に対してProductディメンションを作成する場合、グレインのより細かい階層レベル(ミニバン、サブコンパクト、中型セダンなど)を作成する場合があります。問合せパフォーマンスが向上し、読取りとナビゲーションの容易なレポートやダイヤグラムを作成できます。
レベル・キー
それぞれの論理レベル(総計レベルを除く)には、レベル・キーを構成する1つ以上の属性が存在する必要があります。レベル・キーは、各論理レベルの一意の要素を定義します。ディメンション表の論理キーをディメンションの一番下のレベルに関連付ける必要があります。
論理レベルは複数のレベル・キーを持つことができます。論理レベルに複数のレベル・キーがある場合、レベルの主キーとしてキーを指定します。特定のレベルに集計コンテンツを持つすべてのディメンション・ソースには、そのレベルの主キーとなる列が含まれている必要があります。それぞれの論理レベルは1つのレベル・キーを持つ必要があります。このレベル・キーは、Oracle BIサーバーのユーザーがオブジェクトを選択してドリルダウンするときに表示されます。レベルへのユーザー・アクセスを提供するために任意のレベル・キーを使用できます。
一意のレベル・キーを作成する必要があります。月は一意のレベル・キーではありません。月を含む一意のレベル・キーを作成するには、年属性をキーの一部として含めます。
より上位のレベルの属性を含めることによって、レベル・キーを確実に一意のものにしておかないと、問合せで予期しない結果が返されることがあります。たとえば、Oracle BIサーバーで、複数の物理問合せからの結果セットを結合する必要がある場合、結果に含まれていると予期される行がいくつか削除されている可能性があります。それは、それらの行がレベル・キー定義に照らして一意であると見なされないためです。
time_key='1023793'などの生成された代理キーではなく、Month_name='2010 July'などの共通のビジネス・キーを使用して有効なレベル・キーを作成します。生成された代理キーは、ソース表の単一のインスタンスにのみ適用される物理アーティファクトです。ビジネス・キーはその論理列の物理インスタンスにマップできます。たとえば、month_nameは、詳細な表、集計スターからの集計表およびフェデレーテッド・スプレッドシートの列にマップできます。物理レイヤーは結合で代理キーを使用します。ビジネス・キーを使用すると、ビジネス・モデルにパフォーマンスまたは柔軟性のペナルティが課せられません。
時間ディメンションおよび時系列キー
ディメンションを時間ディメンションとして指定することができます。時間ディメンションでは、少なくとも1つのレベルに時系列キーが存在する必要があります。時間ディメンションを設定および使用する場合は、次のガイドラインに従います。
時間ディメンションの1つ以上のレベルに時系列キーが必要です。「時間ディメンション内の時系列キーの選択とソート」を参照してださい。
AGO関数、TODATE関数およびPERIODROLLING関数を使用するすべての時系列メジャーは、時間レベル上にある必要があります。派生論理列として、AGO、TODATEおよびPERIODROLLINGの集計が作成されます。
AGO、TODATEおよびPERIODROLLING機能は、断片化されたディメンション論理表ソース、または同じ時間ディメンションでフラグメント化されたファクト・ソースのいずれに対してもサポートされていません。ファクト・ソースは他のディメンションでフラグメント化される場合があります。
「時系列関数について」を参照してください。
不均衡または不規則な階層とは、リーフ(子を持たないメンバー)の深さが必ずしも一定ではない階層を指します。たとえば、現在の月は日レベルでデータを持ち、前月は月レベルでデータを持ち、過去5年間は四半期レベルでデータを持つよう選択できます。
ユーザー・アプリケーションは、ISLEAF関数を使用することによって、特定のメンバーから下に移動することが可能かどうかを判断できます。
データ・ソース内の存在しないメンバーについては、そのメンバーの値としてnull値が実装されます。すべての計算では、null値はその親の中の個別の子として扱われます。レベルベースのメジャーおよび集計計算では、存在しないすべてのノードがグループ化されます。
不均衡階層は、必ずしも親子階層と同じではありません。親子階層は生来不均衡です。不均衡なレベルベースの階層が可能です。
スキップレベル階層とは、特定の祖先レベルに値を持たないメンバーが存在する階層を指します。たとえば、Country-State-City-Districtの階層において、Washington, D.C.というCityはStateには属しません。この場合、Countryレベル(USA)からCityレベル(Washington, D.C.)以降にドリルダウンします。
問合せで、スキップ・レベルは表示されず、計算に影響を与えません。階層順にソートすると、メンバーは最も近い祖先の下に表示されます。
データ・ソース内の特定のレベルにおいて存在しないメンバーについては、そのメンバーの値としてnull値が実装されます。すべての計算では、null値はその親の中の個別の子として扱われます。レベルベースのメジャーおよび集計計算では、スキップされたすべてのノードがグループ化されます。
この図は、不均衡とスキップレベルの両方の特徴を持つ階層を示しています。たとえば、A-Brand 4、B-LOB 3およびType 5は不均衡なブランチであり、A-Brand 2とType 3の間やB-LOB 2とProduct 6などの間には、スキップが存在します。
ディメンション階層レベルの使用方法を学習します。
ディメンション階層レベルを使用して、次の操作を実行できます。
集計ナビゲーションを設定する
レベルベース・メジャーの計算を構成します。「レベルベース・メジャーの計算」を参照してください。
Oracle BIプレゼンテーション・サービスのユーザーがデータ要求をドリルダウンするときにどの属性が表示されるかを決定する
レベルベース階層で階層レベルを作成および管理する方法を学習します。
次の各項で説明されているタスクを実行します。
ディメンションを作成した後、1つ以上の論理ディメンション表内の属性(列)、および論理ファクト表内のレベルベース・メジャーに、各ディメンションを関連付けることができます。
論理列をディメンション・レベルに関連付けると、それらの列が存在する表が「ディメンション」ダイアログの「表」タブに表示されます。「物理階層オブジェクトでの作業」を参照してください。
ノート:
物理レイヤーに設定されている物理階層タイプと、ビジネス・モデルとマッピング・レイヤーで選択するディメンション・プロパティを一致させることを、ベスト・プラクティスとしてお薦めします。
また、問合せが動作するためには、不規則なディメンションやスキップ・レベルのディメンションのプロパティが正しく設定されていることを確認する必要があります。
ディメンション内に論理レベルを作成するときには、レベルのタイプを特定し子レベルを定義することによって階層も作成します。
「マルチディメンション・データ・ソースに対するビジネス・モデル・オブジェクトの自動作成」を参照してください。
このレベルを総計レベルとして定義する場合は、このフィールドを空白のままにします。デフォルト値は1です。
この数は必ずしも正確である必要はありませんが、論理レベル間の数の比率は正確である必要があります。リレーショナル・ソースの場合、レベル・キーの行数を取得し、その数を要素数として使用することができます。多次元ソースの場合、そのレベルのメンバー数を使用することができます。
Oracle BIサーバーは、使用する集計ソースを選択する際にこの数を使用します。たとえば、集計ナビゲーションが使用される場合、異なるグレインに複数のファクト・ソースが存在します。Oracle BIサーバーは、それぞれの修飾ソースの合計行数を推測する方法として、その修飾ソースの各レベルの要素数を乗算します。次にOracle BIサーバーは、各ソースの結果を比較し、要素数の合計が最も少ないソースを選択して、問合せに回答します。要素数の合計が最も少ないソースが最も高速であると想定されます。
ディメンション内にすべての論理レベルを作成したら、総計レベルを除くすべての論理レベルに、ディメンション表から1つ以上の列をドラッグ・アンド・ドロップします。
ディメンションに最初に列をドラッグするとき、そのディメンションに論理表が関連付けられます。ドラッグ・アンド・ドロップ操作によって、該当するディメンションのレベルに論理列を関連付けます。論理列に論理レベルを関連付けるには、ある論理レベルの列を別の論理レベルにドラッグします。
ディメンション表の論理キーを構成する論理列は、ディメンションの最下位レベルに関連付ける必要があります。
ディメンションのレベルに論理列を関連付けると、「ディメンション」ダイアログの「表」タブに、それらの列が存在する表が表示されます。
例については、次の項を参照してください。
時間ディメンションの場合、ソース表内の時間に関連するすべての列を時間ディメンション内で定義するようにしてください。たとえば、時間に関連する論理表にMonth Name列およびMonth Code列が含まれている場合、ディメンション内の適切なレベルに両方の列をドラッグする必要があります。この図は、論理列を論理レベルに関連付ける方法について示しています。
レベルベース・メジャーとは、集計の特定のレベルにおいて値が常に計算される列です。
その場合、CountryRevenue、RegionRevenueおよびCityRevenueを測定する列を設定することができます。たとえば、ある企業が国、地域および都市に基づいて収益を測定するとします。
プレゼンテーション階層を含む問合せにレベル・ベースのメジャーの列が含まれており、問合せグレインがその列固有の集計レベルよりも上位の場合、問合せの結果としてnullが返されます。リクエストに通常の列のみが含まれていて、階層列が含まれていない場合は、レベルベースのメジャーはnullに置換されません。
メジャーAllProductRevenueは、総計レベルのレベルベース・メジャーの例です。レベルベース・メジャーでは、1回の問合せで複数の集計レベルのデータを返すことができます。レベルベースのメジャーはシェア・メジャーを作成する際にも便利です。シェア・メジャーは、なんらかのメジャーをレベルベース・メジャーで除算してパーセントを算出することにより計算します。たとえば、営業担当者の売上を地域の売上で除算することによって、その地域で各営業担当者が貢献した売上の比率を計算することができます。
たとえば、これらの計算を設定するには、Grandtotal、Country、RegionおよびCityのレベルを含むリポジトリ内にディメンション階層を構築する必要があります。この階層には、CountryとRegionの間に1対多の関係を定義し、RegionとCityの間に1対多の関係を定義するメタデータが含まれます。各国には多くの地域がありますが、各地域は1つの国の中にあります。同様に、各地域には多くの都市がありますが、各都市は1つの地域の中にあります。
ディメンション階層を構築したら、CountryRevenue、RegionRevenue、およびCityRevenueのそれぞれに1つの論理列を作成する必要があります。これらの列は、ソースとしてRevenue論理列を使用します。Revenue列にはデフォルトの集計ルールSUMがあり、基礎となるデータベース内にソースがあります。
CountryRevenue列、RegionRevenue列およびCityRevenue列を、それぞれCountryレベル、RegionレベルおよびCityレベルにドラッグします。これらの列のいずれかを要求する問合せでは、そのレベルで集計された売上が返されます。
この図は、この例のビジネス・モデルとマッピング・レイヤー内のビジネス・モデルを示しています。
売上に総計ディメンション階層を使用する方法を学習します。
TotalProducts (総計レベル)、Brands、およびProductsの各レベルと、合計のデフォルト集計ルールで定義されたRevenue列を持つ製品ディメンション階層があると、AllProductRevenue論理列を作成できます。AllProductRevenue列は、ソースとしてRevenueを使用します。AllProductRevenue列を総計レベルにドラッグします。AllProductRevenue列を含む問合せは、すべての製品の総売上を返します。BrandsまたはProductsのいかなる制約にも関係なく値が返されます。
他の表内の列に制約がある場合、総計は問合せのスコープに制限されます。たとえば、問合せのスコープが1999年および2000年のデータを要求する場合、製品売上の総計は、1999年および2000年のすべての製品の売上となります。
A、B、Cの3つの製品があり、それぞれの売上の合計が100、200、300である場合、製品売上の総計は600です(各製品の売上の合計)。この例で説明しているリポジトリを設定している場合の問合せとその結果を示します。
SELECT product, productrevenue, allproductrevenue FROM sales_subject_area WHERE product IN 'A' or 'B'
結果は次のとおりです。
PRODUCT;;PRODUCTREVENUE;;ALLPRODUCTREVENUE A;;;;;;;;100;;;;;;;;;;;;;600 B;;;;;;;;200;;;;;;;;;;;;;600
AllProductRevenue列は、問合せで制約が設定された製品に関係なく、常に600の値を返します。
レベルの主キーを特定するには、「論理レベル」ダイアログの「キー」タブを使用します。
管理ツールのビジネス・モデルとマッピング・レイヤーで、ディメンションを展開し、ディメンションの最上位のレベル(総計レベル)を展開します。
総計レベルの下の論理レベルをダブルクリックします。
「論理レベル」ダイアログで「キー」タブをクリックします。
「キー」タブで、「主キー」のリストからレベル・キーを選択します。
レベル・キーが1つしかない場合は、それがデフォルトで主キーとなります。
リストに列を追加するには、次のステップを実行します。
「論理レベル」ダイアログで「新規」をクリックします。
「論理レベル・キー」ダイアログで、キーの名前を入力します。
「論理レベル・キー」ダイアログで、列を選択するか、または「追加」をクリックします。
「追加」をクリックした場合は、「参照」ダイアログで列を選択し、「OK」をクリックします。
選択した列が「論理レベル・キー」ダイアログの「列」リストに表示され、自動的に選択されます。
ノート:
LOOKUP関数の結果である派生論理列を、1次論理レベル・キーの一部として使用することはできません。集計が行われた後にLOOKUP操作が適用されるため、この制限が存在します。ただし、レベル・キー列によって集計の計算粒度が定義されるため、レベル・キー列は集計を行う前に使用可能にしておく必要があります。
LOOKUP関数の結果である派生論理列は、2次論理レベル・キーとして使用できます。
時間ディメンション内のレベルである場合は、時系列キーを選択し、名前によってキーをソートすることができます。
(オプション)キーの説明を入力し、「OK」をクリックします。
ステップ2 - ステップ7を繰り返し、他の論理レベルに主キーを追加します。
「論理レベル」ダイアログで「OK」をクリックします。
時間ディメンションでは、少なくとも1つのレベルに時系列キーが存在する必要があります。任意のレベルで1つ以上の時系列キーを選択し、レベル内でキーをソートすることができますが、使用されるのは最初の時系列キーのみです。
時系列キーにおける列の順序に多数の列がある場合は注意してください。SQLのORDER BY句を使用して、Oracle BI管理ツールの「時系列キー」ダイアログで、現実的な時系列順序を反映する列に対して列の順序を設定します。1年に四半期の範囲は1から4までであるため、年の前に四半期を使用してORDER BY句を使用する(Quarter, Year)ことは、正しい使用方法ではありません。正しくない順序だと、すべての第1四半期がすべての年にわたって表示され、その次に第2四半期があれば表示されるというように続きます。結果を修正するには、ORDER BY句で(Year, Quarter)を使用します。
ディメンションを時間ディメンションとして認識するためには、「ディメンション」ダイアログの「一般」タブで「時間」を選択する必要があります。
「優先ドリル・パス」タブでは、Oracle BIプレゼンテーション・サービスのユーザーがデータ要求をドリル・ダウンする際に使用するドリル・パスを特定します。
このタブは、ディメンション・レベル階層によって定義される通常のドリル・パスの外部にあるドリル・パスを指定する場合にのみ使用します。このドリル・パスはほとんどの場合、あるディメンションから別のディメンションにドリルするのに使用されます。ドリル・パスから論理レベルを削除したり、ドリル・パス内の論理レベルを並べ替えることができます。
時間ディメンションへの絶対または相対順序番号の追加は、時系列関数を最適化し、問合せ時間が改善する場合があります。
デフォルトでは、Oracle BIサーバーは、複雑なRANK物理SQL式を使用して時間ディメンションの順序番号を生成します。時間ディメンションの論理レベルへの絶対または相対順序番号の追加は、ランク式のあらかじめ計算された結果を含む時間ディメンション表の直接の列参照を提供します。オプションのこのマッピングは、データ・ソースに対してOracle BIサーバーが実行しやすい簡単な問合せを生成します。
順序番号は、特定のレベルの時間ディメンション・メンバーの列挙です。ギャップがなく(密度が高い)列挙を使用してください。列挙は実際の時間順序に対応する必要があり、たとえば、年の月に1から12を列挙できます。
順序番号型のオプションは次のとおりです。
絶対 - 列に参照なしで時間ディメンションのメンバーを列挙する場合に絶対順序番号を構成するには、このオプションを選択します(たとえば、カレンダ年)。
相対 - 親レベルに対して相対的な時間ディメンションのメンバーを列挙する列がある場合に相対順序番号を構成するには、このオプションを選択します(たとえば、1年の月は1から12になります)。
「ディメンションの作成」オプションを利用できるのは、選択されている論理表が1:Nの論理結合によって定義されたディメンション表であり、この表にディメンションが関連付けられていない場合のみです。
次のルールが適用されます。
自動的に作成されたディメンションでは、論理表と同じ名前が使用され、接尾辞としてDimが付加されます。たとえば、表の名前がPeriodsである場合、ディメンションの名前は「Periods Dim」となります。
総計レベルには、自動的に「logical_table_name Total」という名前が付けられます。たとえば、Periods Dim表の総計レベルは「Periods Total」となります。
ソース内に複数の表が存在する場合、ソース内の表の間の結合関係によって、最下位のレベルの属性が含まれる物理表が決定されます。階層内の最下位レベルは、「logical_table_name Detail」という名前になります。たとえば、periods表の最下位レベルは「Periods Detail」となります。
ディメンション表の論理キーは、階層の最下位レベルにマップされ、レベル・キーとして指定されます。この論理列は、ディメンション・ソース内の最下位レベルの表のキー列にマップされます。
ソース内に2つ以上の物理表が存在する場合、それらの表のキーにマップされる列は、追加の論理レベルとなります。これらの追加のレベルの名前には、それらのキー列の論理列の名前が使用されます。
結合の順序によって、論理レベルの階層内の配置が決定されます。これらの新しい論理レベルのレベル・キーは、ソース内の表のキーにマップされる論理列として設定されます。
複数の論理表ソースが存在する場合、ツールは属性マッピングおよび物理結合を使用して、物理ソース内の表の階層順序を決定します。たとえば、3つのソース(A、B、C)があり、それぞれに1つの物理表と、10個、15個、3個の属性の属性マッピングが含まれているとします(他の論理列から作成された列は数えません)。この表のディメンションを自動作成した際の結果を次に示します。
管理ツールによって、4つの論理レベルが含まれ、総計と詳細レベルを計算するディメンションが作成されます。
ソースB内の表のキー(このキーはマップされている列数が最も多く、論理表キーの列マッピングが含まれています)は、詳細レベルのレベル・キーになります。
詳細レベルの親は、ソースA内の物理表のキーにマップされる論理列の名前を持つ論理レベルになります。
AとBの両方にマップされるすべての属性は、レベルAに関連付けられます。
レベルAの親は、ソースC内の物理表のキーにマップされる論理列の名前を持つ論理レベルになります。
AとCの両方にマップされるすべての列は、レベルCに関連付けられます。
物理ソース内の表結合は、階層の分割を生じさせるパターンを持つ可能性があります。たとえば、Product表がFlavor表およびSubtype表に結合しているとします。これにより、productの詳細レベルには、flavorレベルとsubtypeレベルの2つの親が生じる可能性があります。
次の場合、ディメンションの自動作成はできません。
結合とレベルを持つディメンションがすでに作成されている場合、右クリック・メニューに「ディメンションの作成」は表示されません。
表が他の表とまだ結合されていない場合、その表はファクト表と見なされるため、このオプションは利用できません。
スノーフレーク・スキーマにおいて、ソースが1つのみの表を使用してディメンションを自動作成すると、子表が自動的に階層内に組み込まれます。子表は、総計レベルと詳細レベルの間の中間のレベルを形成します。ディメンション表に複数の子表が存在する場合、階層は分割階層になります。
論理ディメンション表にディメンションが存在しない場合、その表から論理ディメンションを自動的に設定することができます。
ディメンションを自動的に作成する際には、管理ツールは論理表ソースとそれらのソース内の列マッピングを調べ、論理表ソース内の物理表の間の結合を使用して、論理レベルおよびレベル・キーを決定します。ベスト・プラクティスとして、ディメンション表にすべての論理表ソースが定義された後にディメンション表を作成します。
レベル評価を使用すると、1つ以上のディメンション階層に自動的にレベル数を設定できます。
レベル数は、最適な問合せ計画を決定して、システムの全体的なパフォーマンスを向上するために問合せエンジンで使用されます。
オンライン・モードでリポジトリを開き、問合せに対してビジネス・モデルが使用できることを確認する必要があります。「ビジネス・モデルとマッピング」レイヤーで、次の論理レイヤー要素を選択して、レベル評価コマンドを実行できます。
ビジネス・モデル。ビジネス・モデル・オブジェクトを選択すると、Oracle BI管理ツールは、ビジネス・モデル内のすべてのオブジェクトをチェックアウトしようとします。
ディメンション。ディメンションの整合性チェックを実行し、ディメンションが論理的に正当であるかどうかを確認します。
ビジネス・モデルとディメンションの組合せ。複数のディメンションと複数のビジネス・モデルを個別に選択できます。
レベル評価コマンドを実行すると、次に説明するように、レベル数に対する整合性チェックが起動されます。
レベル・キーが有効であるかチェックします。レベル内の列は参照整合性を持ちます。
親子関係をチェックします。親のレベル数が子のレベル数よりも大きい場合、エラーが返されます。
評価されたすべての数、およびエラーまたは整合性に関する警告がリストされた実行レポートが生成されます。
11gバージョンを使用している場合、問合せとエラーはOracle BIサーバーのnqquery.logに記録されます。Oracle BI EE 12cを使用している場合、問合せとエラーはDOMAIN_Home/servers/obis1/logs内のobis1_query.logに記録されます。
これらの情報をログ・ファイルに記録するには、ログ・レベルを4以上に設定します。『Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle Business Intelligenceの問題の診断と解決に関する項を参照してください。
オブジェクトをチェックインするときに、リポジトリのグローバル整合性をチェックすることができます。
親子階層とは、タイプがすべて同じメンバーの階層のことです。
これは、同一タイプのメンバーが単一レベルの階層にのみ出現するレベルベースの階層と対照的です。
この項では、次の項目について説明します。
現実世界で一般的な親子階層の例として、組織の階層図があげられます。
組織の階層図には、次のことが該当する可能性があります。
組織内の各個人は従業員です。
各従業員は、1人のマネージャの直属となります(最上位のマネージャを除く)。
組織階層には多くのレベルがあります。
これらの条件は、親子階層の基本機能を示しています。それらの機能とは次のとおりです。
親子階層は1つの論理表(Employees表など)をベースとします
表の各行には2つの識別キーが含まれます。1つはメンバー自身を識別するキー、もう1つはそのメンバーの親を識別するキーです(たとえば、Emp_IDとMgr_ID)。
この図は、複数レベルの親子階層の例を示しています。
次の表は、Employees表の行とキー値によってこの親子階層を表す様子を示しています。
| Emp_ID | Mgr_ID |
|---|---|
Andrew |
null |
Barbara |
Andrew |
Carlos |
Andrew |
Dawn |
Barbara |
Emre |
Barbara |
特定の論理ディメンションをベースとするプレゼンテーション階層を作成することによって、Oracle BIアンサーのユーザーに親子階層の論理ディメンションを提示できます。プレゼンテーション・レイヤーに階層を作成することにより、ユーザーは階層ベースの問合せを作成することができます。「プレゼンテーション階層とプレゼンテーション・レベルでの作業」を参照してください。
この項では、次の項目について説明します。
親子階層のディメンション・メンバーはすべて1つの論理列に存在します。
親子階層では、メンバーの親は同じ論理列の、親キーが指す別の行にあります。レベルベース階層では、メンバーの親が同じ行の別の論理列にあります。親子階層のナビゲーションはデータ値に従い、レベルベース階層のナビゲーションはメタデータ構造に従います。
レベルベース階層では、各レベルは名前が付けられ、分析に役立つ現実世界の属性またはカテゴリに対応する、階層の位置を占めます。レベルベース階層では、レベル数は設計時に固定されます。親子階層の深さに制限はなく、深さは実行時に新しいデータにより変更されることがあります。
すべての親子階層には、2つのシステム生成エンティティ(「合計」と「詳細」)があり、それらは、論理ディメンションが作成されるときに自動的に定義されます。「詳細」エンティティには、すべての階層メンバーが含まれます。これら2つのシステム生成エンティティは、親子階層内の祖先と子孫の間にある暗黙のメンバー間レベルとは異なるものです。この暗黙のレベルは親子階層レベルと呼びます。
レベルと緊密に関連付けられているのは、親子階層内の距離という概念です。別のメンバーからあるメンバーまでの距離が、そのメンバーから祖先または子孫までの親子階層レベルの数です。たとえば、メンバーからその親との距離は常に1です。例は、「親子階層について」を参照してください。
リレーショナル表では、親子階層内の異なるメンバー間の関係は、関連付けられているベース表内の識別キーによって暗黙に定義されます。
ただし、リレーショナル表に定義されたOracle BIサーバーの各親子階層では、個別の親子関係表内にメンバー間の関係を明示的に定義する必要があります。
親子関係表には次の4つの列を含める必要があります。
メンバーを識別する列
メンバーの祖先を識別する列
祖先は、そのメンバーの親の場合もあれば、より上位の祖先の場合もあります。
親子階層におけるメンバーから祖先までのレベルの数を指定する距離列
メンバーがリーフ・メンバーであるかどうかを指定するリーフ列(1=はい、0=いいえ)
列名はユーザーが定義することができます。列のデータ型は、次の条件を満たす必要があります。
メンバーを識別する列および祖先を識別する列は、階層メンバーが含まれる論理表内の関連する列と同じデータ型を持つ。
距離列とリーフ列はINTEGER列です。
親子関係表内の行については、次の条件に注意してください。
各メンバーは、距離が0の自身を指し示す行を持つ必要があります。
各メンバーは、それぞれの祖先を指し示す行を持つ必要があります。ルート・メンバーの場合、これは親の値と距離の値がnullである終了行です。
表に示す例では、可読性を考慮してテキスト文字列を使用していますが、通常は、member_keyおよびancestor_keyには整数の代理キーを使用します(それらがソースのディメンション表に存在する場合)。
この表は親子関係表の例を示しています。各行は、従業員のメンバー間の関係を表しています。親子階層についての図を参照してください。
| 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つ存在する場合のみです。「参照」ウィンドウに、ビジネス・モデル内の論理ディメンション表が、それぞれその主キーおよび表内にある他の列とともに表示されます。
論理表がリレーショナル表ソースに基づいている場合は、ディメンション定義プロセスを続行して、階層の親子関係表を設定する必要があります。
次のステップを使用して、リレーショナル表に基づく親子階層の親子関係表を定義します。
親子関係表を作成するときには、次のいずれかのオプションを選択する必要があります。
(推奨される方法)ウィザードを使用して、親子関係表の作成とデータ移入を行うスクリプトを生成します。
「親子関係表の作成」を選択すると、親子関係表の生成ウィザードにより、親子関係表の作成とデータ移入を行うためのSQLスクリプトが生成されます。ウィザードの終了時にOracle BIサーバーによって、ウィザード・セッションの中で選択されたディレクトリにスクリプトが格納されます。スクリプトを実行すると、メタデータ・リポジトリで親子関係表を使用できるようになります。
「親子関係表の生成」ウィザードで、親子表を生成するためのDDLスクリプトの入力名を指定し、生成スクリプトを格納する場所を選択します。また、親子関係表の名前を入力し、親子関係表のカタログまたはスキーマを選択します。生成されたスクリプトをプレビューできます。
以前に作成した親子関係表を選択します。
親子関係表には、階層用に選択した論理表の中でメンバー間の関係がどのように導出されるかを示す列が4つ以上存在している必要があります。「親子関係表について」を参照してください。
レベル・ベース階層のファクト表には、単一レベルの階層のファクトのみが含まれている場合があります。
上位レベルのディメンション・メンバーのファクトを計算するには、下位レベルのファクト表から、または上位レベルのサマリー表からファクトを集計します。
その一方で、親子階層では、次に関連する追加の決定を行うためにデータ・モデラーが必要です。
ファクト表でのベース・ファクトの格納方法
親子階層の上位メンバーのファクトを取得するための、ベース・ファクトの集計方法
この項では親子階層のファクトの格納および集計方法について説明しており、次の内容で構成されています。
親子階層のファクト表にベース・ファクトを格納する場合、2つのオプションがあります。
次のオプションを使用できます。
親子階層のリーフ・メンバーのみのファクトを格納します。
親子階層でリーフ以外のメンバーを含むすべてのレベルのメンバーのファクトを格納します。
親子階層の非リーフ・メンバーのファクトをリーフ・メンバーのファクトから完全に派生させることができる場合は、最初のオプションが適しています。たとえば、親子製品階層を使用していて、その中で実際の製品メンバーが階層のリーフ・メンバーとしてのみ表示される場合は、収益ファクト表にその製品階層のリーフ・メンバーの収益ファクトのみを記録するのが合理的です。製品階層の非リーフ・メンバー(製品カテゴリなど)の収益の数字を完全に派生させるには、階層の最下位にあるリーフ製品メンバーのファクトを集計します。
この図は、親子階層のリーフ・メンバーのファクトのみが格納される場合のデータの例を示しています。
次の表では、ディメンション表PRODUCT_DIMのデータの例を示しています。
| MemberKey | 名前 | 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 | 名前 | 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年前、1月前などの売上を比較できます。
SQLには時間による比較を直接行うための方法がないため、Oracle BIリポジトリ内で時系列データをモデル化する必要があります。最初に、データ・ウェアハウス内の期間表に基づいて時間ディメンションを設定します。次に、この時間ディメンションを活用するメジャーを定義することによって、AGO、TODATE、PERIODROLLINGの関数が使用できるようになります。問合せ時には、時間オフセットの処理を可能なかぎりデータベースにまかせる、高度に最適化されたSQLがOracle BIサーバーによって生成され、最良のパフォーマンスと機能が実現されます。
この項では、次の項目について説明します。
時系列関数は、時系列的なディメンションを操作します。
特定のディメンションでこれらの関数を使用するには、そのディメンションを時間ディメンションとして指定し、1つ以上のキーを1つ以上のレベルで時系列キーとして設定する必要があります。これらのキーは、ディメンション・レベル内のメンバーの時系列の順序を特定します。
時系列関数には、TODATEおよびPERIODROLLINGがあります。これらの関数を使用することによって、物理表に別名を付けて論理的にモデル化することなく、時系列計算を行う論理関数を式ビルダーを使用して呼び出すことができます。時系列関数では、SQLの標準の日付操作関数ではなく、データ・ウェアハウス内のカレンダ表に基づいて、AGO関数、TODATE関数およびPERIODROLLING関数を計算します。
この図は、時系列関数を使用して導出されたいくつかのメジャーを含むレポートを示しています。
時間問合せでは様々なグレインが使用できます。次に例を示します。
問合せグレイン
要求の中で最も小さな時間グレインです。
時系列グレイン
時系列グレインは、
AGO関数およびTODATE関数で集計またはオフセットを要求するグレインです。図のレポートの例では、時系列グレインは四半期です。時系列問合せは、時系列グレインが問合せグレインと同じか、またはそれより大きい場合にのみ有効です。PERIODROLLING関数は時系列グレインを持たず、関数の開始期間と終了期間はユーザーが指定します。記憶域グレイン
例に表示されているように、毎日または毎月の売上からレポートを生成できます。ソースのグレインは記憶域グレインと呼ばれます。問合せが動作するためには、このレベルに時系列キーを定義する必要があります。ただし、問合せグレインにも時系列キーを定義することによって、一般的に大きなパフォーマンスの向上が得られます。
時系列データに対する問合せが、問合せキャッシュにアクセスするには、完全一致する必要があります。
次の項では、時系列変換の関数を説明しています。
AGO関数は、過去のデータを表示するために時間ディメンションをオフセットさせます。
この関数は比較を行う際に便利です(「ドル」と「1四半期前のドル」の比較など)。
ノート:
2008/08の月におけるDollars Qagoは、2008/05の月におけるDollarsと同じです。
この図は、DollarsおよびDollars Qagoのメジャーの値の例を示しています。
前述の図の例では、Dollars QagoのメジャーはDollarsのメジャーから導出されています。
式ビルダーでは、AGO関数には次のテンプレートがあります。
Ago(<<Measure>>, <<Level>>, <<Number of Periods>>)
<<Measure>>は、導出元となる論理メジャーの列を表します。この例では、既存の論理ファクト表からメジャー"Dollars"を選択します。
<<Level>>は、オプションで使用する時系列グレインです。この例では、時間ディメンションから"Quarter"を選択します。
<<Number of Periods>>はオフセットのサイズ(<<Level>>引数で指定されるグレインが単位)です。たとえば、<<Level>>がQuarterで、<<Number of Periods>>が2の場合、この関数は2四半期前のドルを表示します。
この関数テンプレートを使用することによって、次のような1四半期前のメジャーの式を作成することができます。
Ago("Sales"."Base Measures"."Dollars" , "Sales"."Time MonthDim"."Quarter" , 1)
<<Level>>パラメータはオプションです。AGO関数で時系列グレインを指定しない場合、問合せグレインが時系列グレインとして使用されます。
たとえば、Dollars_AgoをAgo(Dollars, 1)として定義したとします。この場合、次の論理問合せを実行できます。
SELECT Month, Dollars, Dollars_Ago
この結果は、Dollars_AgoをAgo(Dollars, Month, 1)として定義した場合と同じです。または、次の論理問合せを実行できます。
SELECT Quarter, Dollars, Dollars_Ago
この結果は、Dollars_AgoをAgo(Dollars, Quarter, 1)として定義した場合と同じです。
『Oracle Business Intelligence Enterprise Edition論理SQLリファレンス・ガイド』のAGOに関する項を参照してください。
TODATE関数は、時系列グレインの開始期間から現在表示されている問合せグレインの期間までのメジャーを合計します。
たとえば、次の図はDollars QTDメジャーを使用したレポートを示しています。このメジャーは、Dollarsメジャーの「現時点までの四半期」バージョンです。
例では、2008/05の月のDollars QTDは、2008/04と2008/05のドル建ての合計金額です。Dollars QTDは、現在の時系列グレインの期間(四半期)の、すべての問合せグレイン期間(月)の値の合計です。次の四半期には別の加算が始まります。
例では、Dollars QTDのメジャーはDollarsのメジャーから導出されています。
式ビルダーでは、TODATE関数では次の形式が使用されます。
ToDate(<<Measure>>, <<Level>>)
<<Measure>>は、導出元となる論理メジャーの列を表します。この例では、既存の論理ファクト表からメジャーDollarsを選択します。
<<Level>>は、使用する時系列グレインです。この例では、時間ディメンションからQuarterを選択します。
この関数の書式を使用すると、次のようなメジャーの式を作成できます。
ToDate("Sales"."Base Measures"."Dollars" , "Sales"."Time MonthDim"."Quarter" )
問合せグレインは実行時に問合せ自体に指定されます。たとえば、このメジャーは日付グレインにおけるその時点までの四半期を表示しますが、加算は四半期の最後まで続きます。
『Oracle Business Intelligence Enterprise Edition論理SQLリファレンス・ガイド』のTODATEに関する項を参照してください。
PERIODROLLING関数では、固定の時系列グレインの中で集計を実行するのではなく、一連の問合せグレインの期間を指定することによって集計を実行します。
最も一般的な使用方法は、移動平均の作成です(13週間の移動平均など)。
PERIODROLLING関数には時系列グレインがないため、移動シーケンスの長さは問合せグレインによって決定されます。たとえば、ドルの3期間の移動平均は、問合せグレインが月である場合は過去3か月の値の平均が計算され、問合せグレインが年である場合は過去3年の値の平均が計算されます。
この図は、これら2つのメジャーを使用したレポートを示しています。
前述の例では、ドルの3期間の移動合計のメジャー、およびドルの3期間の移動平均のメジャーはドルのメジャーから導出されています。
式ビルダーでは、PERIODROLLING関数の書式は次のようになります。
PeriodRolling(<<Measure>>, <<Starting Period Offset>>, <<Ending Period Offset>>)
<<Measure>>は、導出元となる論理メジャーの列を表します。ドルの3期間の移動合計のメジャーを作成するには、既存の論理ファクト表からメジャーDollarsを選択します。
<<Starting Period Offset>>および<<Ending Period Offset>>では、移動集計の最初の期間と最後の期間を指定します。この整数は、表示されている期間からの相対的な期間の数です。この例では、問合せグレインは月であり、3か月の移動合計は2期間前から始まり、現在の期間も含まれます。つまり、月が2008/07の場合は、2008/05、2008/06および2008/07を含めた移動合計になります。ドルの3期間の移動合計のメジャーを作成するには、これらのオフセットを示す整数を-2と0にします。
この関数の書式を使用すると、次のようなメジャーの式を作成できます。
PeriodRolling("Sales"."Base Measures"."Dollars" , -2, 0)
この例では、3か月の移動平均も示されます。このメジャーを計算するには、前に作成した移動合計を3で割って、3期間の移動平均を算出します。3で割るという前提は、移動合計の<<Starting Period Offset>>と<<Ending Period Offset>>のフィールドの-2と0が根拠になります。
3か月の移動平均の式は次のとおりです。
PeriodRolling("Sales"."Base Measures"."Dollars" , -2, 0) /3
移動平均の作成には、AVG関数を使用しません。AVG関数では、記憶域グレインでアクセスされるデータベース行の平均を計算します。移動平均を実行する場合は、分母が問合せグレインでの移動期間の数になる平均が必要になります。
PERIODROLLING関数には、オプションの4番目の階層引数があります。この引数では、yr、mon、dayなど、時間ウィンドウの計算に使用する時間ディメンション内の階層の名前を指定します。このオプションは、時間ディメンション内に複数の階層がある場合、または複数の時間ディメンションを区別する場合に便利です。『Oracle Business Intelligence Enterprise Edition論理SQLリファレンス・ガイド』のPERIODROLLINGに関する項を参照してください。
時間ディメンションを作成するには、時間オプションを選択し、すべてのディメンション階層のすべてのレベルに時系列キーを割り当てる必要があります。
時系列データをモデル化する際には、次のガイドラインを使用します。
データ・ソースに履歴が含まれている場合、時系列関数を使用します。履歴が含まれるリレーショナル・データベースでは、明示的な時間ディメンション表を持つスター・スキーマまたはスノーフレーク・スキーマを使用することがあります。正規化された履歴データベースには、スノーフレークに似たスキーマ状のレベルを持つ時間階層が含まれることがあります。単純な日付フィールドは、時系列関数とともに使用するには適切ではありません。
Oracle Business Intelligenceでは、時間ディメンションの物理表、または正規化された表のセットは、関連する物理ファクト表から分離している必要があります。
一般的なソース・スキーマ・パターンは、時間ディメンション列がファクトおよび他のディメンションと同じ表にある完全非正規化関係表またはフラット・ファイルです。この一般的なソース・スキーマ・パターンを時間ディメンションとみなすことはできません。それは、時間ディメンション表はファクト表と結合されているためです。ソース・モデルを変更できないため、個別物理時間ディメンション表として機能する時間列を含む物理表の不透明なビューを作成できます。不透明なビューの時間ディメンションは、ファクトを含む物理表に結合する必要があります。
物理レイヤーでは、時間ディメンション表または正規化/スノーフレークの場合は最下位の表は、介在する表を使用せずに直接ファクト表と結合する必要があります。この結合を外部キー結合として作成します。
時間ディメンションを含む物理モデル内の表は、最も詳細なレベルを除き、他のデータ・ソースと結合させることはできません。
メンバーの値、リレーショナル・ソース内の行は、すべての期間、すべての階層レベルにおいて物理的に存在する必要があります。順序でスキップされる行が含まれないようにします。ファクト・データがない期間はあってもかまいません。完全であることが必要なのはディメンション・データのみです。
month、half、yearなど、メンバー間の距離のそれぞれの単位は、個別の階層レベルでモデル化する必要があります。
「論理ディメンション」ダイアログの「一般」タブで「時間」オプションを選択すると、このディメンションで時系列関数が有効になります。
時系列関数AGO、TODATEおよびPERIODROLLINGで時間ディメンションとして使用できるのは、「時間」オプションが選択された論理ディメンションのみです。
この図は、「論理ディメンション」ダイアログの「時間」オプションを示しています。
各ディメンション階層のすべてのレベルに時系列キーを割り当てます。
時系列キーは、標準のSQL ORDER BY句と同等である必要があります。時系列キーのORDER BY句は、そのキーによって表される時間ディメンション・メンバーの現実的な時系列順序を反映している必要があります。たとえば、時間ディメンション・メンバーがJan-3-2013、Jan-4-2013、Jan-5-2013である場合、同じ順序で次の時系列キー、1、5、9をこれらのメンバーに割り当てることができます。ただし、2、1、3などの時系列キーを割り当てると、その結果はJan-4-2013、Jan-3-2013、Jan-5-2013となって、時系列順序として正しくありません。
Oracle BIサーバーは、時系列キーを使用して、「1月+ 2か月= 3月」など数学的に正しい時系列予測を作成します。すべてのレベル(「総計」レベルを除く)に対して時系列キーを設定し、十分なパフォーマンスを保ってすべてのレベルに対して時系列操作を実行できるようにする必要があります。これにより、何会計月前、何カレンダ年前、何日前など、すべての時間ディメンション階層のすべてのレベルに対してAGO、TODATEまたはPERIODROLLING関数を使用できます。
理論上は、「論理ディメンション」の最下位レベル・キーのみが時系列であれば、時系列関数は正しく処理を実行します。ただし、実際には、これはパフォーマンスの問題を起こします。それは、物理問合せで最も小さいグレインの使用を強制するので、桁違いに多数の行の結合が実行されるためです(たとえば、「年前」に対して「日」のグレインで365回行を結合する)。
あらゆるレベル・キーと同様に、キーはそのレベルにおいて一意であるようにしてください。たとえば、"1月"などのシンプルな月名が含まれている列は、年の名前が含まれている列と連結しないかぎり、一意にはなりません。
この図は、「論理レベル」ダイアログで時系列キーを指定する方法を示しています。
ベース・メジャーから派生した式を作成することによって、時系列メジャーを構築することができます。
派生式を作成するには、新しい論理列を作成して「式を使用して既存の列から派生」を選択し、式ビルダーを開いて適切な時系列関数を構築する必要があります。
時系列関数をモデル化する際には、次のガイドラインに従います。
時系列関数は、断片化形式のフェデレーションを使用するメジャーから派生できません。このルールによって、1つのソースのいくつかの時間ディメンション行を別のソースのファクト行のいくつかに結合する必要性など、問合せ生成および結果マージにおける複雑な境界条件およびソース間の想定を防ぎます。メンテナンスを軽減し、正確性を高めるために、1つの基準となるメジャーを作成し、それから時系列メジャーのファミリを派生させることをお薦めします。たとえば、基準となるメジャーから始めて、月前、年前および過去1か月間のバリエーションを定義します。
時間ディメンション内に構築された時系列キーを利用できるようにするため、この単位は時間ディメンションのレベルとして定義する必要があります。
次の例は、AGOメジャーを構築する方法を示しています。その他の時系列関数(TODATEおよびPERIODROLLING)の詳細な構文は、Oracle Business Intelligence Enterprise Edition論理SQLリファレンス・ガイドを参照してください。
AGOメジャーの作成
この例は、Sampleappデモンストレーション・リポジトリにAGOメジャーの派生を作成する方法を示しています。
