| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 12c (12.2.1.3.0) E90110-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 12c (12.2.1.3.0) E90110-03 |
|
|
前 |
次 |
この章のトピックは、次のとおりです:
論理表ソースは、1つの論理表から1つ以上の物理表へのマッピングを定義します。
物理レイヤーとビジネス・モデルとマッピング・レイヤーとの間で発生する変換を指定したり、集計ナビゲーションと断片化を可能にするために、物理から論理へのマッピングを使用します。
ビジネス・モデルとマッピング・レイヤーで論理表ソースを表示できます。
論理表には、多数の物理表ソースがあることがあります。1つの論理列が、列にマップされた集計表(問合せがその列に対する該当するレベルの集計を要求している場合など)を含めて、複数の物理表の多数の物理列にマップされていることがあります。
この項では、次の項目について説明します。
システムでは、基準を使用して、問合せに回答するためのファクト論理表ソースを選択します。
次の基準は、優先度の高いものから低いものへという順番でリストされています。
論理表ソースの優先度グループ論理表ソースは、優先度の高いものから順番に使用されます。これは、より優先度の高いソースがより詳細なグレイン・レベルにある場合でも当てはまります。数値が低いほど優先度が高くなります。「論理表ソースの優先度グループ番号の設定」を参照してください。
論理表ソースのグレイン 優先度グループ番号が同じである場合、論理表ソースは、グレイン・レベルの高いものから順番に使用されます。
このレベルの要素数グレインの比較ができない場合は、「このレベルの要素数」フィールドに指定されている数値が考慮されます。
たとえば、LTS1(year, city)とLTS2(month, state)という、グレインの比較ができない2つの論理表ソースがあるとします。10年、100市、120か月および9都道府県という要素がある場合、LTS1の最悪ケース・サイズは10 x 100 = 1000、LTS2の最悪ケース・サイズは120 x 9 = 1080となります。要素数の合計が最も少ないソースが最も高速であると想定されるため、このシナリオでは、LTS1が選択されます。
「ディメンション内の論理レベルの作成」を参照してください。
リストされている最初の論理表ソース他のすべての基準が等しい場合、「ビジネス・モデルとマッピング」レイヤーに示されているように、リストされている最初の論理表ソースが選択されます。
問合せ内のすべての列は、これらの予期されるパフォーマンス要因に基づいて単一の論理表ソースから提供されます。問合せでは、複数の論理表ソース間での負荷分散は行われません。
適切なファクト論理表ソースが選択された後、システムは、問合せに回答するための最適なディメンション論理表ソースを選択します。
Oracle BIサーバーでは次の基準に従って、ディメンション論理表ソースを選択します。基準は、優先度の高いものから低いものへという順番で記載されています。
論理表ソースの優先度グループ
優先度の高いディメンション論理表ソースが優先度の低いディメンション論理表ソースよりも先に使用されます。数値が低いほど優先度が高くなります。
低い結合コスト
優先度グループのメンバーが同じである場合、結合コストの最も低いディメンション論理表ソースが、結合コストの高いディメンション論理表ソースよりも先に選択されます。
上位レベル
優先度グループと結合コストが同じである場合は、上位レベルの論理表ソースが選択されますが、その理由は、論理表ソースでは結合する行数の低減が要求される可能性があるためです。
論理表ソースのデフォルトの選択基準を変更して、上位レベルの論理表ソースを検討する前に、ファクト論理表ソースと同じレベルにあるディメンション論理表ソースを優先させることができます。
Oracle BI管理ツールで、セッション変数DIMENSION_LTS_JOIN_RESTRICTIONSをPREFER_SAME_LEVELに設定します。
ファクト論理表ソースと同じレベルに適切なディメンション論理表ソースが存在しない場合は、Oracle BIサーバーにより、ファクトに結合可能な最上位のディメンション論理表ソースが選択されます。これらの要因は、優先度グループと結合コストの後にのみ検討されます。
セッション変数DIMENSION_LTS_JOIN_RESTRICTIONSのPREFER_SAME_LEVELの値によって、問合せに回答するためにディメンション論理表ソースを選択する際の基準が次のように設定されます。
論理表ソースの優先度グループ
低い結合コスト
ファクト論理表ソースと同じレベル
ファクト論理表ソースと同じレベルに他の論理表ソースがない場合、その他のディメンション論理表ソースよりも上位である
DIMENSION_LTS_JOIN_RESTRICTIONSがNONE (デフォルト値)に設定されていると、ファクトと同じレベルに別の結合可能なディメンション論理表ソースが存在していても、ファクト論理表ソースを上位のディメンション論理表ソースに結合できます。
ソース内のデータの整合性を確認することが重要です。
たとえば、時間ディメンションに対する年レベルの論理表ソースと月レベルの論理表ソースは同じ期間をカバーしている必要があります。
ソース内のデータに関する整合性の問題は、null抑制をオーバーライドする問合せを発行したときに(つまり、Oracle BIアンサーで分析を作成して「NULL値を含む」を選択したときに)、顕在化することがあります。たとえば、集計表によっては、nullファクト値に対応するディメンション・レコードが含まれていないことがあります。たとえば、売上のない年度を含まない年次売上集計表などが考えられます。結果に含まれるnull値に対して、年次ディメンションのすべての年度が存在している必要があります。
物理レイヤーからのドラッグ・アンド・ドロップによって論理表と列を作成すると、論理表ソースは自動的に生成されます。
物理レイヤーからのドラッグ・アンド・ドロップによって論理表と列を作成すると、論理表ソースは自動的に生成されます。手動で論理表を作成する場合は、ソースも手動で作成する必要があります。
複数の物理表を情報のソースにする場合も、新しい論理表ソースを追加します。たとえば、売上に関する情報は多くの表に含まれていることがあります。売上情報の取得元として、それぞれに独自の注文システムを持つ3つの異なるビジネス・ユニットが存在するかもしれません。また別の例では、注文システムまたは財務システムから定期的に売上情報をまとめて、その表をより高次のレポートで使用するかもしれません。
「マップされていない表を許可」オプションを「A > B > C」構成のスノーフレーク物理表に使用します。その構成では、論理表は、AとCの列にのみマップされていますが、AとCの間の結合パスにBがあるため、それを論理表ソースに含める必要があります。
問合せで要求された列のセットを満たす論理表ソースが複数存在する場合、問合せでどの論理表ソースが使用されるかを決定するために、優先度グループ番号を設定できます。
たとえば、データ・ウェアハウスとOLTPソースのいずれによっても実現されるユーザー問合せが存在するとします。通常、業務系システムへのアクセスはコストが高くなり、データ・ウェアハウスへのアクセスはコストが低くなります。この場合、データ・ウェアハウスに高い優先度を割り当てることによって、すべての問合せは可能なかぎりデータ・ウェアハウスによって実現されるようにすることができます。
特定の論理表ソースに優先度グループを割り当てても、必ずしもそのソースによって問合せが実現されるとはかぎりません。優先度グループの割当ては、特定の問合せで選択される論理表ソースを決定する際にOracle BIサーバーが使用する多くの要素の1つでしかありません。ただし、論理表ソースの優先度は最も重要なメトリックであり、他のコスト・メトリックの前に考慮されます。
優先度グループ番号を割り当てるには、論理表ソースを数値でランク付けします(0が最も優先度の高いソースです)。複数のソースに同じ番号を割り当てることができます。たとえば、2つの論理表ソースに優先度グループ0を割り当て、別の2つの論理表ソースに優先度グループ1を割り当てることができます(以下同様)。2つの優先度グループ(0と1)しか必要ない場合がよくあります。
優先度グループの割当てはオプションです。デフォルトでは、すべての論理表ソースに優先度0が設定されます。問合せに回答するために使用する論理表ソースの選択を微調整する方法として優先度グループを使用しないことは重要です。Oracle BIサーバーは、最適な論理表ソースを自動的に使用しようとしますが、これは同じ優先度グループの範囲内にかぎられます。論理表ソースごとに異なる優先度グループが設定されていると、 Oracle BIサーバーは次善の論理表ソースを使用する可能性があります。
問合せの実行時に、論理表ソースの通常の優先度ランキングを逆にしたい場合があります。これを行うには、セッション変数およびリクエスト変数と、論理表ソースの優先度グループの組合せを使用します。この機能によって、ユーザーの好みに応じて実行時にソースを動的に選択する方法が提供されます。
この動的な選択を実現するには、最初にリポジトリ内にREVERSIBLE_LTS_PRIORITY_SA_VECセッション変数を作成する必要があります。この変数は、行単位のセッション初期化ブロックを使用する文字列ベクトル・セッション変数として作成します。REVERSIBLE_LTS_PRIORITY_SA_VECには、論理表ソースの優先度ランキングの反転をユーザーに許可するサブジェクト・エリアのリストを設定します。優先度ランキングの反転を有効にするには、この変数を定義する必要があります。
優先度ランキングの反転を許可する一連のサブジェクト・エリアを定義すると、ユーザーは問合せにリクエスト変数REVERSE_LTS_PRIORITYを含めることによって、論理表ソースの優先度ランキングを反転させることができます。このリクエスト変数に1を設定すると論理表ソースの優先度は逆になり、0を設定すると通常の優先度のままになります。
問合せの実行時にリクエスト変数を使用する以外の別の方法として、論理表ソースの優先度が永続的に反転されるサブジェクト領域のセットをあらかじめ定義しておくという方法があります。これを行うには、リポジトリ内にセッション変数REVERSED_LTS_PRIORITY_SA_VECを作成します。この変数は、行単位のセッション初期化ブロックを使用する文字列ベクトル・セッション変数として作成します。REVERSED_LTS_PRIORITY_SA_VECには、論理表ソースの優先度を永続的に逆に設定するサブジェクト領域のリストを設定します。
「セッション変数の作成」を参照してください。
REVERSIBLE_LTS_PRIORITY_SA_VEC
SUBJECT_AREA_NAMEとREVERSIBLEの2つの列を持つSA_TABLEという名前の表を作成します。この表には、次に示すように、サブジェクト・エリアの名前をその反転値(1または0)にマッピングする行を格納しておきます。
| SUBJECT_AREA_NAME | REVERSIBLE |
|---|---|
my_sa_1 |
1 |
my_sa_2 |
0 |
次に、行単位のセッション初期化ブロックを持つ、REVERSIBLE_LTS_PRIORITY_SA_VECという名前の文字列ベクトル・セッション変数を作成します。この初期化ブロックの初期化文字列は次のようになります。
SELECT 'REVERSIBLE_LTS_PRIORITY_SA_VEC', SUBJECT_AREA_NAME FROM SA_TABLE WHERE REVERSIBLE=1
この図は、この例における「セッション変数初期化ブロック」ダイアログを示しています。
論理列を物理列にマップするには、「論理表ソース」ダイアログの「列マッピング」タブを使用します。
物理から論理へのマッピングは、物理レイヤーと、ビジネス・モデルとマッピング・レイヤーの間の変換を指定するのにも使用されます。この変換は、整数データ型を文字に変更するような単純なものから、数式を使用して単位人口あたりの売上の比率を算出するような複雑なものまで利用できます。これらの変換を適用することは、通常「計算項目の作成」と呼ばれます。
論理列のデータ型は、その列の論理表ソースへのマッピングによって決定されます。たとえばある論理列が、null値不可なVARCHAR(50)のデータ型を持つ1つの物理ソースと、null値可能なVARCHAR(20)のデータ型を持つ別の物理ソースにマッピングされている場合、この論理列のデータ型はnull値可能なVARCHAR(50)になります。この最終的な型はプロモートされた型と呼ばれます。論理表ソースのマッピングを管理するルールによって、物理ソースをプロモート可能なデータ型にマップすることはできません(INTとVARCHARのマッピングなど)。
「列マッピング」タブの「論理列から物理列へのマッピング」エリアでは、列ヘッダーをクリックすることによって行をソートできます。
ソースを正しく使用するには、Oracle BIサーバーはビジネス・モデルの観点で各ソースに何が含まれているかを知る必要があります。
したがって、ファクト表の各論理表ソースの集計内容を定義する必要があります。集計内容のルールは、このファクト表内に格納されているデータの粒度のレベルを定義します。このファクト論理表に関連する各ディメンションに対して粒度のレベルを定義します(関連するすべてのディメンションが定義されるようにします)。「集計対象のファクト・データのソース作成による集計ナビゲーションの設定」を参照してください。
論理表のソースが断片のセットである場合、すべての断片を同じ列のセットにマップする必要はありません。ただし、列のマップの方法に応じて、サーバーは異なる回答を返します。
論理表のすべての断片が同じ列のセットにマップされている場合、断片化されたソースのセットは、その論理表の論理表ソースの全体的なユニバースであると見なされます。これは、断片のセットに基づいてメジャーの集計が計算されることを意味します。
マップされた列のセットが断片間で異なる場合は、Oracle BIサーバーは、断片がすべて揃ってなく、集計ロールアップの計算を行うことは不適切であると想定します(いくつかの断片が欠けているため)。この場合、メジャー集計としてサーバーからNULLが返されます。
注意:
すべての断片を同じ列のセットにマップすることをお薦めします。
「論理表ソース」ダイアログの「コンテンツ」タブを使用して、すべての集計表のコンテンツの定義、ソースの断片化された表の定義、およびWHERE句(返される行数を制限する場合)を定義します。「集計ナビゲーションの断片化の内容の設定」を参照してください。
結合によって、Oracle BIサーバーに、物理集計ディメンション表内の値に結合され、その値によって制約される物理集計ファクト表に問合せを送信する場所が伝えられます。
論理レベルは「集計の内容、グループ化」オプションとしてのみ使用することをお薦めします。1つのビジネス・モデル内では、論理レベルによる集計と列による集計を混在させないようにしてください。
「WHERE句フィルタについて」および「集計ナビゲーションの断片化の内容の設定」を参照してください。
「断片化の内容」テキスト・エリアに直接計算式を入力するか、式ビルダーをクリックできます。「断片化の内容」の「式ビルダー」で、既存の論理列に関する内容を指定できます。「集計ナビゲーションの断片化の内容の設定」を参照してください。
このレベルにあるすべての断片が非結合の場合、「このソースはこのレベルの他のソースと組み合せる必要がある」を選択します。次の例を参考にしてください。
例2 - 2000年以前の売上(断片化の述語に準拠)と2001年以後の売上(断片の述語に準拠)の2つの断片があるとします。断片が重複しないため、「このソースはこのレベルの他のソースと組み合せる必要がある」オプションを選択する必要があります。Oracle BIサーバーでは、問合せ述語または断片の述語の互換性に基づいて不適格にできない、このレベルのすべての論理表ソースを結合します。
「論理表ソース・オプション・リファレンス」を参照して、「論理表ソース」ダイアログでどのオプションを使用するかを習得します。
物理レイヤーの集計ファクト表と集計ディメンション表の間の結合を作成する必要があります。
結合を確認するために、ファクト論理表を選択し、ビジネス・モデル図(「選択された表と直接結合」)を開くことができます。この図には、このファクト論理表に直接結合されているディメンション論理表のみが表示されます。論理ファクトおよびディメンション・ソース内で同じ物理表が使用されている場合は、ディメンション表は表示されません。
この図は、「選択された表と直接結合」ビューの「ビジネス・モデル図」にある「Fact - Assess」論理ファクト表を示しています。
この表は、「Fact - Assess」ファクト表に直接結合されている各ディメンション表の論理レベルのリストです。
| ディメンション | 論理レベル |
|---|---|
Account Geography |
Postal Code Detail |
Person Geography |
Postal Code Detail |
Time |
Day Detail |
Account Organization |
Account Detail |
Opportunity |
Opty Detail |
Primary Visibility Organization |
Detail |
Employee |
Detail |
Assessment |
Detail |
Contact (W_PERSON_D) |
Detail |
FINS Time |
Day |
Positions |
Details |
「論理表ソース」ダイアログのオプションを使用する方法を習得します。
| オプション | 説明 |
|---|---|
| 集計の内容、グループ化 |
コンテンツの集計方法を指定します。 |
| コピー |
「コピー」オプションはファクト表とのみ使用できます。集計の内容をWindowsのクリップボードにコピーします。 式が空の場合、「コピー」は使用できません。 |
コピー元 |
「コピー元」オプションは、ファクト表およびディメンション表に対して使用できます。同じビジネス・モデルの別の論理表ソースから集計の内容をコピーします。集計内容のコピー元のソースを指定する必要があります。複数のビジネス・モデルが表示されますが、現在のビジネス・モデルの論理表ソースのみが選択可能です。 |
レベルの取得 |
「レベルの取得」オプションはファクト表に対してのみ使用できます。集計の内容を変更します。ファクト表のソースとディメンション表のソースの間に結合が存在しない場合、たとえば両方のソース内に同じ物理表がある場合、管理ツールによって決定される集計内容には、このディメンションの集計内容は含まれません。 |
レベルのチェック |
「レベルのチェック」オプションはファクト表に対してのみ使用できます。ディメンション表ソースではなく、論理ファクト表ソースの集計内容をチェックします。返される情報は、ディメンション表ソースの表とファクト表ソースの表との間における物理結合、および論理レベルと論理キーを持つ階層およびディメンションの存在に応じて異なります。ファクト・ソースとディメンション・ソースに同じ表が存在しており、それらのソースの表の間に物理結合がない場合は、「レベルのチェック」には、このディメンションの集計内容は含まれません。 |
| 断片化の内容 |
データ・ソースの内容のビジネス・モデルの観点からの説明です。同じレベルの集計の情報がデータの値に応じて複数の表に分割される場合、データは断片化します。一般的な状況として、期間によってデータが断片化することがあります。 |
| このソースはこのレベルの他のソースと組み合せる必要がある |
同じレベルの集計のデータ・ソースに重複する情報が含まれない場合、このオプションを選択します。この場合、集約のこのレベルにおける完全な情報を得るには、すべてのソースが結合される必要があります。 |
| 個別値の選択 |
ソースの値が一意である場合に使用します。 |
WHERE句フィルタは、論理表ソース内で参照される物理表を制約するのに使用されます。
集計ソースに制約がない場合は、WHERE句フィルタは空のままにします。
各論理表ソースには、集計レベルの単一の交差のデータが含まれている必要があります。たとえば、BrandとManufacturerの両方のレベルに販売データを持つようなソースは作成したくない場合があります。物理表内の複数のレベルにデータが含まれている場合は、適切なWHERE句制約を追加して、単一のレベルになるように値をフィルタ処理します。
WHERE句フィルタのすべての制約は、ソース内の物理表に対して作成されます。
論理表が、リレーショナル表をベースとする親子階層を持つディメンションの一部である場合について学習します。
この場合、この論理表には、物理ソースと、親子階層で必要となる親子関係表のソースの両方が含まれます。親子関係表は、親子階層のメンバー間の関係を明示的に定義します。
通常、親子関係表の論理表ソースは、親子表の生成ウィザードによって作成されたスクリプトを実行すると自動的に作成されます。このウィザードには「親子表の設定」ダイアログからアクセスします(ディメンション・オブジェクトで利用可能です)。
親子表の生成ウィザードの機能は、「論理表ソース」ダイアログからは利用できません。親子関係表を生成するためのスクリプトを作成するには、ディメンション・オブジェクトに移動する必要があります。
親子関係表ソースの詳細は、「論理表ソース」ダイアログの「親子設定」タブで確認できます。このタブには次の情報が表示されます。
親子表: ソースのベースとなっている親子関係表の名前が表示されます。
メンバー・キー: 親子関係表内でメンバーを特定する列の名前です。
親キー: 親子関係表内でメンバーの祖先を特定する列の名前です。
関係性: 親子関係表内で、メンバーから祖先までの親子階層のレベル数を指定する列の名前です。
リーフ・ノード識別子: 親子関係表内でメンバーがリーフ・メンバーであるかどうかを識別する列の名前です(1=はい、0=いいえ)。
「親子階層のディメンションの作成」を参照してください。
集計表には、ディメンション属性のセットに対して集計される、あらかじめ計算されたメジャーからの結果が格納されます。
集計表の各列には、特定のレベルのセットのデータが含まれます。たとえば、月間売上表には、各月の各店舗での各製品の収益の合計があらかじめ計算されて含まれます。このメタデータは、「論理表ソース」ダイアログの「コンテンツ」タブで構成します。
集計ファクト表の論理表ソースを作成するには、対応する論理ディメンション表ソースを同じ集計レベルに作成する必要があります。
集計の各レベルに1つ以上の論理ディメンション表ソースが必要になります。各レベルにソースがすでに存在する場合は、新しいソースを作成する必要はありません。
たとえば、製品ごと、店舗ごと、月ごとの売上の事前計算された合計を格納する月次販売ファクト表があるとします。次の3つの別のディメンション表ソースが必要になります(この例で参照される各論理ディメンション表に1つずつ)。
次のコンテンツの指定のいずれかを満たす製品論理表のソース:
論理レベルによる: ProductDimension.ProductLevel
列による: Product.Product_Name
次のコンテンツの指定のいずれかを満たす店舗論理表のソース:
論理レベルによる: StoreDimension.StoreLevel
列による: Store.Store_Name
次のコンテンツの指定のいずれかを満たす時間論理表のソース:
論理レベルによる: TimeDimension.MonthLevel
列による: Time.Month
問合せの実行時には、Oracle BIサーバーは最初に、問合せに回答するのに十分な詳細を持つソースがどれであるかを判断します。Oracle BIサーバーはこれらのソースから、問合せに回答するのに最も集計の度合いが高いソースを選択します(それが最も高速であると想定されるため)。最も集計の度合いの高いソースは、要素の乗数が最も小さいソースです。各レベルの要素数の指定方法の詳細は、「ディメンション内の論理レベルの作成」を参照してください。
指定されたレベルのデータのセット全体が論理表ソースに含まれていない場合、実際に含まれているセットの一部(断片)を指定する必要があります。
「論理表ソース」ダイアログの「コンテンツ」タブの「断片化の内容」ボックスに、論理列に基づくコンテンツの説明を入力します。
この項の例では、ソースの断片化の内容を指定する際のテクニックおよびルールを示しています。
この項では、次の項目について説明します。
IN述語は、1つの等価述語、またはOR結合で区切られた複数の等価述語で置き換えることができます。
断片1:
logicalColumn IN <valueList1>
断片n:
logicalColumn IN <valueListN>
論理表ソースに特定のレベルのデータのセット全体が含まれないときは、セット全体が含まれるように、そのセットの断片を指定する必要があります。
断片1:
logicalColumn >= valueof(START_VALUE) AND logicalColumn < valueof(MID_VALUE1)
断片2:
logicalColumn >= valueof(MID_VALUE1) AND logicalColumn < valueof(MID_VALUE2)
断片n:
logicalColumn >= valueof(MID_VALUEN-1) AND logicalColumn < valueof(END_VALUE)
開始点、中間点、終了点は注意深く選択してください。
注意:
>=述語および<述語を使用して、断片の内容の記述が重ならないようにしてください。各断片では、上限値を<として表す必要があります。<=を使用すると、エラーが発生します。BETWEEN述語を使用して断片の範囲の内容を記述することはできません。
ここで参照されるvalueofはリポジトリ変数の値です。式の中でリポジトリ値を使用する場合、次の構文は断片2に対して動作しません。
logicalColumn >= valueof(MID_VALUE1)+1 AND logicalColumn < valueof(MID_VALUE2)
valueof(MID_VALUE1)+1のかわりに別のリポジトリ変数を使用します。
同じ変数(たとえばvalueof(MID_VALUE1))が両方の断片の内容に含まれている必要はありません。別の変数を設定し、次の形式の文を作成することができます。
断片1:
logicalColumn >= valueof(START_VALUE) AND logicalColumn < valueof(MID_VALUE1)
断片2:
logicalColumn >= valueof(MID_VALUE2) AND logicalColumn < valueof(MID_VALUE3)
「Oracle BI Repositoryでの変数の使用」を参照してください。
各コンテンツ・フィルタには、異なる列に任意の数の述語を含めることができます。各列の述語は値ベース、範囲ベースのいずれでも構いません。
断片1:
<logicalColumn1 predicate> AND <logicalColumn2 predicate > ... AND <logicalColumnM predicate>
断片n:
<logicalColumn1 predicate> AND <logicalColumn2 predicate > ... AND <logicalColumnM predicate>
すべての断片が同じM列に述語を持つのが理想的です。論理列に述語制約がない場合、Oracle BIサーバーは断片にその列のすべての値のデータが含まれていると想定します。OR述語の使用における例外については、並列コンテンツ記述の指定を参照してください。
並列のORを使用して、日付範囲内で複数年または複数月にわたるなど、複数の論理列にわたる日付を処理します。
並列のORテクニック使用して、論理列をまたがる複数の階層関係を処理します(年→年月→日、月→年月→日など)。たとえば、年と月など、異なる時点によって示される断片を考えます。履歴断片の選択のみを可能にするのであれば、年をさかのぼって制約を適用することで十分です。これは、次の例に示すように、並列のORテクニックによってサポートされます。この例では、スナップショットの月は1999年4月1日午前12:00であると想定しています。
断片1 (履歴):
EnterpriseModel.Period."Day" < VALUEOF("Snapshot Date") OR
EnterpriseModel.Period.MonthCode < VALUEOF("Snapshot Year Month") OR
EnterpriseModel.Period."Year" < VALUEOF("Snapshot Year") OR
EnterpriseModel.Period."Year" = VALUEOF("Snapshot Year") AND
EnterpriseModel.Period."Month in Year" < VALUEOF("Snapshot Month") OR
EnterpriseModel.Period."Year" = VALUEOF("Snapshot Year") AND
EnterpriseModel.Period."Monthname" IN ('Mar', 'Feb', 'Jan')
断片2 (現在):
EnterpriseModel.Period."Day" >= VALUEOF("Snapshot Date") OR
EnterpriseModel.Period.MonthCode >= VALUEOF("Snapshot Year Month") OR
EnterpriseModel.Period."Year" > VALUEOF("Snapshot Year") OR
EnterpriseModel.Period."Year" = VALUEOF("Snapshot Year") AND
EnterpriseModel.Period."Month in Year" >= VALUEOF("Snapshot Month") OR
EnterpriseModel.Period."Year" = VALUEOF("Snapshot Year") AND
EnterpriseModel.Period."Monthname" IN ('Dec', 'Nov', 'Oct', 'Sep', 'Aug', 'Jul',
'Jun', '', 'Apr')
論理モデルにおいて日付レベルの詳細が不要な場合は、前出の例のEnterpriseModel.Period."Day"の述語を省略します。
並列コンテンツ記述トラックをサポートするために、OR結合が使用されていることに注目してください。
これらの例は、断片の内容の記述にラベルを使用する方法を示しています。
この例のTrack番号のラベルは、この例と後述の説明の関連をわかりやすくするために示されています。実際の断片化の内容の文には、これらのラベルは含めないでください。
断片1 (履歴)
Track 1 EnterpriseModel.Period."Day" < VALUEOF("Snapshot Date") OR
Track 2 EnterpriseModel.Period.MonthCode < VALUEOF("Snapshot Year Month") OR
Track 3 EnterpriseModel.Period."Year" < VALUEOF("Snapshot Year") OR
Track 4 EnterpriseModel.Period."Year" = VALUEOF("Snapshot Year") AND
EnterpriseModel.Period."Month in Year" < VALUEOF("Snapshot Month") OR
Track 5 EnterpriseModel.Period."Year" = VALUEOF("Snapshot Year") AND
EnterpriseModel.Period."Monthname" IN ('Mar', 'Feb', 'Jan')
たとえば、EnterpriseModel.Period."Day"の最初のトラックについて考えてみましょう。この履歴の断片では、<述語は、Oracle BIサーバーに対して、スナップショットの日付の前の日を制約するすべての問合せは履歴の断片内にあるということを通知します。反対に、日付の現在の断片内の>=述語は、現在の断片の中にスナップショットの日付の前のデータが含まれていないことを通知します。
2番目のトラックのMonthCode (たとえば、199912)は日付と似ています。月には重なる部分が存在しないため(スナップショットの日付は4月1日であるため)、このトラックでは<述語と>=述語を使用します。覚えておくべき重要なルールとして、追加されたそれぞれの並列トラックは異なる列セットを参照する必要があるという点があげられます。共通の列を使用することは可能ですが、列セット全体は一意である必要があります。Oracle BIサーバーは、この列セットを使用して最も適切なトラックを選択します。
3番目のトラックのYear (履歴の断片内では<、現在の断片内では>)は、Oracle BIサーバーに対して、年を制約する問合せに対する最適な(単一の)断片選択が可能であることを通知します。たとえば、「Year IN (1997, 1998)」の論理問合せは履歴の断片にのみヒットします。同様に、「Year = 2000」の問合せは現在の断片にのみヒットします。ただし、1999年にヒットする問合せは、このトラックに記述されているコンテンツでは回答できず、以降のトラックに追加の情報がないかぎり両方の断片にヒットします。
4番目のトラックは、Year (month integer)の形式で年と月の断片セットを記述しています。以前に説明した、複数列コンテンツ記述のテクニックに注目してください。また、これらの2つの列にはあいまいさや重なりがないため、<述語と>=述語を使用していることに注目してください。
5番目のトラックは、年と月の名前によって断片化の内容を記述しています。このトラックでは、値ベースのIN述語のテクニックを使用しています。
参考までに、スナップショットの日付がある月の特定の日付となる場合を考えます。したがってこの場合、複数列のコンテンツの年と月のみの記述は特定のスナップショットの月において重なります。このあいまいさを指定するには、<=述語と>=述語を使用します。
断片1 (履歴):
EnterpriseModel.Period."Day" < VALUEOF("Snapshot Date") OR
EnterpriseModel.Period.MonthCode <= VALUEOF("Snapshot Year Month") OR
EnterpriseModel.Period."Year" < VALUEOF("Snapshot Year") OR
EnterpriseModel.Period."Year" = VALUEOF("Snapshot Year") AND
EnterpriseModel.Period."Month in Year" <= VALUEOF("Snapshot Month") OR
EnterpriseModel.Period."Year" = VALUEOF("Snapshot Year") AND
EnterpriseModel.Period."Monthname" IN ('Apr', 'Mar', 'Feb', 'Jan')
断片2 (現在):
EnterpriseModel.Period."Day" >= VALUEOF("Snapshot Date") OR
EnterpriseModel.Period.MonthCode >= VALUEOF("Snapshot Year Month") OR
EnterpriseModel.Period."Year" > VALUEOF("Snapshot Year") OR
EnterpriseModel.Period."Year" = VALUEOF("Snapshot Year") AND
EnterpriseModel.Period."Month in Year" >= VALUEOF("Snapshot Month") OR
EnterpriseModel.Period."Year" = VALUEOF("Snapshot Year") AND
EnterpriseModel.Period."Monthname" IN ('Dec', 'Nov', 'Oct', 'Sep', 'Aug', 'Jul',
'Jun', '', 'Apr')
注文入力アプリケーションでは、履歴の断片と現在の断片の間の時間ベースの断片化では不十分です。
たとえば、レコードがスナップショットの日付の前にデータベースに入力された履歴レコードであったとしても、それらのレコードは揮発性である場合があります。
次の例では、未処理の注文は、その注文の発送が行われるかキャンセルされるまで、アプリケーションによって直接更新されることがあると想定します。ただし、注文の発送が行われた後にその注文に対して行われる変更は、個別の返品トランザクションの入力のみです。
次のコンテンツの記述には2つの並列トラックがあります。最初のトラックでは、前の項で説明した、複数列の並列トラックのテクニックが使用されています。ShippedまたはCanceledの注文状態の複数列コンテンツの記述の中で、カッコによって並列カレンダの記述がネストしていることに注目してください。
2番目の並列トラックは現在の断片の中にのみ存在し、すべての未処理レコードが現在の断片の中のみにあることを指定しています。
断片1 (履歴):
Marketing."Order Status"."Order Status" IN ('Shipped', 'Canceled') AND
Marketing.Calendar."Calendar Date" <= VALUEOF("Snapshot Date") OR
Marketing.Calendar."Year" <= VALUEOF("Snapshot Year") OR
Marketing.Calendar."Year Month" <= VALUEOF("Snapshot Year Month")
断片2 (現在):
Marketing."Order Status"."Order Status" IN ('Shipped', 'Canceled') AND
Marketing.Calendar."Calendar Date" > VALUEOF("Snapshot Date") OR
Marketing.Calendar."Year" >= VALUEOF("Snapshot Year") OR
Marketing.Calendar."Year Month" >= VALUEOF("Snapshot Year Month") OR
Marketing."Order Status"."Order Status" = 'Open'
並列トラックが存在する場合の重なり合いは許容されるため、2つの断片内で年と月が重なり合っても問題は生じません。このルールは、少なくとも1つのトラックに重なり合いが生じない必要があるというものです。他のトラックには重なり合いがあっても構いません。
集計の特定のレベルの情報が複数の物理表に格納されている場合があります。
集計の特定のレベルの情報が複数の物理表に格納されている場合があります。特定のレベルの個々のソースにドメインの一部または断片の情報が含まれている場合、Oracle BIサーバーは、問合せで適切なソースを選択するためにソースのコンテンツを知る必要があります。
たとえば、すべての店舗でのソフト・ドリンクの売上を追跡するデータベースがあるとします。データの詳細レベルは店舗レベルです。この図に示すように、CokeとPepsiの売上の集計情報が都市レベルで格納されますが、7‐Upや他のソーダの売上に関する集計情報はありません。
このタイプの構成の目的は、集計表を最大限に活用することです。問合せでCokeとPepsiの売上額を求める場合、データは集計表から返されます。問合せですべてのソフト・ドリンクの売上額を求める場合、CokeとPepsiに関しては集計表が使用され、他のブランドに関しては詳細データが使用されます。
Oracle BIサーバーは、このタイプの部分集計ナビゲーションを扱います。ドメインが複数の断片に及んでいる問合せで集計断片が使用されるようにリポジトリを構成するには、集計データの各レベルのドメイン全体を定義する必要があります。これは、集約の度合いの低い物理ソースをベースとして集計断片を構成する必要がある場合でも同様です。
この項では、次の項目について説明します。
論理表ソースのマッピング内に集計表ナビゲーションを構成します。
ソフト・ドリンクの例では、集計表には都市レベルのCokeおよびPepsiの売上データが含まれています。この集計コンテンツの指定(「論理表ソース」ウィンドウの「コンテンツ」タブ)は次のようになります。
論理レベルでのグループ化:
GeographyDim. CityLevel, ProductDim.ProductLevel
この断片化の内容の指定は次のようになります(これも「論理表ソース」ダイアログの「コンテンツ」タブにあります)。
SoftDrinks.Products.Product IN ('Coke', 'Pepsi')
このコンテンツの指定は、Oracle BIサーバーに対して、2つの製品の都市および製品のレベルのデータがソース表に格納されていることを通知します。また、このソースはこのレベルにおけるデータの断片であるため、「論理表ソース」ダイアログの「コンテンツ」タブで「このソースはこのレベルの他のソースと組み合せる必要がある」を選択して、このソースを他のソースと同じレベルで組み合せることを指示する必要があります。
ドメインの残りの部分のデータ(他の種類のソーダ)は、すべて店舗レベルで格納されています。
集計レベル、たとえば都市や製品でドメイン全体を定義するには、このレベルにおけるドメインの残りの部分が格納されているソースが必要になります。店舗レベルのデータは都市レベルのデータより下位にあり、より詳細なため、ある都市のすべての店舗の製品売上データを加算することによって、店舗および製品の詳細から都市および製品レベルの詳細を計算することが可能です。店舗および製品レベルの表を含む問合せを使用できます。
これを行う方法の1つとして、物理レイヤー内に店舗レベルの計算を返すSelect文を使用する表を定義するという方法があります。この表を定義するには、SELECT文が問合せに使用する物理スキーマ・オブジェクト上で物理レイヤーに表を作成し、新しい物理表を選択します。「表タイプ」のリストから「選択」を選択し、「デフォルトの初期化文字列」ボックスにSQL文を入力します。
このSQL文では、他の集計表のレベルでドメインを完全にする仮想表を定義する必要があります。この場合、既存の集計表が1つ存在し、その中には都市ごとのCokeとPepsiのデータが格納されています。したがって、このSQL文は、CokeとPepsiのデータを除くすべてのデータを都市レベルで返す必要があります。
ドメインの残りの部分を都市および製品レベルでカバーする売上列の新しい論理表ソースを作成します。
このソースには、前の項で作成した仮想表が含まれます。この仮想表の中でDollars論理列をUS Dollars物理列にマップします。
このソースの集計コンテンツの指定(「論理表ソース」ダイアログの「コンテンツ」タブ)は次のようになります。
論理レベルでのグループ化:
GeographyDim.CityLevel, ProductDim.ProductLevel
これは、Oracle BIサーバーに対して、このソースには都市および製品レベルのデータがあることを通知します。
断片化の内容の指定は次のようになります。
SoftDrinks.Products.Product = '7-Up'
またこれは、ドメインを完全にするために都市および製品レベルのCokeとPepsiのデータを格納する表と組み合されるため、「論理表ソース」ダイアログの「コンテンツ」タブ内のオプションを選択して、このソースが他のソースと同じレベルで組み合されることを指定します。
論理結合を構築する方法について、図を使用して説明します。
仮想表に適切な物理結合を構築します。次の図で、CityProductSales2がCities表およびProducts表と結合されていることに注目してください。
この例では、ソーダの売上のドメイン全体が2つのソースによって構成されています。ドメインは多くのソースを持つことができます。これらすべてのソースは、「各レベルには、組み合せることによってそのレベルの値のドメイン全体が構成されるソースが含まれていなければならない」というルールに従う必要があります。各レベルに完全なドメインを設定することは、Coke、Pepsiおよび7-Upを求める問合せで7-Upが欠落しないようにするのに役立ちます。またこれは、事前に計算され集計表に格納されている情報を要求する問合せにおいて、その問合せではこの集計表に含まれない他の情報も要求する場合であっても、該当する情報は必ずその集計表から取得されるようにするのに役立ちます。
