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