| 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つ以上の物理表へのマッピングを定義します。物理レイヤーとビジネス・モデルとマッピング・レイヤーとの間で発生する変換を指定したり、集計ナビゲーションや断片化を可能にしたりする場合にも、物理から論理へのマッピングが使用されることもあります。
それぞれの論理表には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が選択されます。
このフィールドの詳細は、「ディメンション内の論理レベルの作成」を参照してください。
リストされている最初の論理表ソース。他のすべての基準が等しい場合、「ビジネス・モデルとマッピング」レイヤーに示されているように、リストされている最初の論理表ソースが選択されます。
問合せ内のすべての列は、これらの予期されるパフォーマンス要因に基づいて単一の論理表ソースから提供されるものであることに注意してください。問合せでは、複数の論理表ソース間での負荷分散は行われません。
適切なファクト論理表ソースが選択された後、システムは、問合せに回答するための最適なディメンション論理表ソースを選択します。ディメンション論理表ソースは、ファクト論理表ソースと同様に、優先度グループの基準に基づいて選択されます。ただし、ファクト論理表ソースとは異なり、ディメンション論理表ソースの選択では、グレインは重要な役割を果たしません。かわりに、問合せ計画内の物理表の数が最小になるように選択が行われます。
物理レイヤーからのドラッグ・アンド・ドロップによって論理表と列を作成すると、論理表ソースは自動的に生成されます。手動で論理表を作成する場合は、ソースも手動で作成する必要があります。
複数の物理表を情報のソースにする場合も、新しい論理表ソースを追加します。たとえば、売上に関する情報は多くの表に含まれていることがあります。売上情報の取得元として、それぞれに独自の注文システムを持つ3つの異なるビジネス・ユニットが存在するかもしれません。また別の例では、注文システムまたは財務システムから定期的に売上情報をまとめて、その表をより高次のレポートで使用するかもしれません。
論理表ソースの全般的なプロパティを定義するには、「論理表ソース」ダイアログの「一般」タブを使用します。
管理ツールのビジネス・モデルとマッピング・レイヤーで論理表を右クリックし、「新規オブジェクト」→「論理表ソース」を選択します。
「論理表ソース」ダイアログの「一般」タブで、論理表ソースの名前を入力します。
「無効」を選択してこの論理表ソースを非アクティブにするか、選択を解除したままにしてこの論理表ソースをアクティブにします。
「マップされていない表を許可」を選択し、論理列にマップされていない物理表をこの論理表ソースに含められるようにします。このオプションは、「A > B > C」構成のスノーフレーク物理表に便利です。その構成では、論理表は、AとCの列にのみマップされていますが、AとCの間の結合パスにBがあるため、それを論理表ソースに含める必要があります。
「追加」ボタンをクリックします。「参照」ダイアログで、結合を参照したり、論理表ソースの表を選択したりすることができます。論理表ソース内に複数の表がある場合は、それらすべての表の間に結合が定義されている必要があります。
結合を参照するには、「参照」ダイアログで「表示」をクリックします。「物理表」ダイアログで結合を確認したら、「取消」をクリックします。
表ソースに表を追加するには、「名前」リストで目的の表を選択し、「選択」をクリックします。
オプションで、「優先度グループ」フィールドに、この論理表ソースの優先度グループ番号を入力します。詳細は、「論理表ソースの優先度グループ番号の設定」を参照してください。
「論理表ソース」ダイアログで「列マッピング」タブをクリックし、各フィールドに入力します。詳細は、「物理から論理表ソースへのマッピングと計算項目の作成」を参照してください。
「論理表」ダイアログで「コンテンツ」タブをクリックし、各フィールドに入力します。詳細は、「論理表ソースのコンテンツの定義」を参照してください。
「OK」をクリックします。
問合せで要求された列のセットを満たす論理表ソースが複数存在する場合、問合せでどの論理表ソースが使用されるかを決定するために、優先度グループ番号を設定することができます。
たとえば、データ・ウェアハウスとOLTPソースのいずれでも実現可能なユーザー問合せが存在するとします。業務系システムへのアクセスはコストが高く、データ・ウェアハウスへのアクセスはコストが低い場合がよくあります。この場合、データ・ウェアハウスに高い優先度を割り当てることによって、すべての問合せは可能なかぎりデータ・ウェアハウスによって実現されるようにすることができます。
特定の論理表ソースに優先度グループを割り当てても、必ずしもそのソースによって問合せが実現されるとは限らないことに注意してください。優先度グループの割当ては、特定の問合せで選択される論理表ソースを決定する際にOracle BIサーバーが使用する多くの要素の1つでしかありません。ただし、論理表ソースの優先度は最も重要なメトリックであり、他のコスト・メトリックの前に考慮されます。
優先度グループ番号を割り当てるには、論理表ソースを数値でランク付けします(0が最も優先度の高いソースです)。複数のソースに同じ番号を割り当てることができます。たとえば、2つの論理表ソースに優先度グループ0を割り当て、別の2つの論理表ソースに優先度グループ1を割り当てることができます(以下同様)。2つの優先度グループ(0と1)しか必要ない場合がよくあります。
優先度グループの割当てはオプションです。デフォルトでは、すべての論理表ソースに優先度0が設定されます。
問合せの実行時に、論理表ソースの通常の優先度ランキングを逆にしたい場合があります。これを行うには、セッション変数およびリクエスト変数と、論理表ソースの優先度グループの組合せを使用します。この機能によって、ユーザーの好みに応じて実行時にソースを動的に選択する方法が提供されます。
この動的な選択を実現するには、最初にリポジトリ内に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
図11-1は、この例における「セッション変数初期化ブロック」ダイアログを示しています。
図11-1 REVERSIBLE_LTS_PRIORITY_SA_VECの例における「セッション変数初期化ブロック」ダイアログ
論理列を物理列にマップするには、「論理表ソース」ダイアログの「列マッピング」タブを使用します。物理から論理へのマッピングは、物理レイヤーと、ビジネス・モデルとマッピング・レイヤーの間の変換を指定するのにも使用されます。この変換は、整数データ型を文字に変更するような単純なものから、数式を使用して単位人口あたりの売上の比率を算出するような複雑なものまで利用できます。これらの変換を適用することは、通常「計算項目の作成」と呼ばれます。
論理列のデータ型は、その列の論理表ソースへのマッピングによって決定されます。たとえばある論理列が、null値不可のVARCHAR(50)のデータ型を持つ1つの物理ソースと、null値可能なVARCHAR(20)のデータ型を持つ別の物理ソースにマッピングされている場合、この論理列のデータ型はnull値可能なVARCHAR(50)になります。この最終的な型はプロモートされた型と呼ばれます。論理表ソースのマッピングを管理するルールによって、物理ソースをプロモート不可能なデータ型にマップすることはできません(INTとVARCHARのマッピングなど)。
管理ツールのビジネス・モデルとマッピング・レイヤーで、論理表ソースをダブルクリックします。
「論理表ソース」ダイアログで「列マッピング」タブをクリックします。
「列マッピング」タブで、すべてのコンテンツが表示されるようにダイアログを最大化または拡大します(図11-2を参照)。
「列マッピング」タブの「論理列から物理列へのマッピング」エリアでは、列の見出しをクリックすることによって列をソートすることができます(昇順、降順、元の順序の復元を切り替えることができます)。
「物理表」列で、マップする列を含む表を選択します。
「物理表」列内のセルを選択すると、リストが表示されます。ここには、この論理表ソース内に現在含まれている表のリストが表示されます。
「式」列で、各論理列に対応する物理列を選択します。
「式」列内のセルを選択すると、リストが表示されます。ここには、この論理表ソース内に現在含まれている物理列のリストが表示されます。
式ビルダーを開くには、「式ビルダー」ボタンをクリックします。
物理式の作成に使用されるすべての列は、論理表ソース内に含まれる表の中にある必要があります。ソースに含まれていない表内の列を含む式は作成できません。
式ビルダーを使用して計算項目を作成することができます。計算項目内の数式は、事前集計を実際に適用したものです。たとえば、units_sold列およびunit_weight列を使用したメジャー"tons sold"を作成するには、事前集計の数式(fact.units_sold*product.unit_weight)を適用し、メジャー・オブジェクト内に集計ルールSUMを適用します。別の例として、アンサーや他のクライアントに高速に表示するために、CASTを使用してTIMESTAMP型の列をDATE型の列に変換するという使用法があります(例: CAST("DB"."."TABLE"."COL" AS DATE))。
物理データの変換を実行する式を作成することによって、ソースを適合させることもできます。たとえば、CAST関数を使用して文字データ型の列を整数データ型に変換することによって、別の論理表ソースからのデータを一致させることができます。他の例として、CONCATENATEまたは数学関数を使用して、物理データに対して同様の変換を実行する方法があります。
集計後に必要な計算は、「派生列の作成」を参照してください。
列マッピングを削除するには、「削除」ボタンをクリックします。「削除」ボタンを見つけるには、右にスクロールしなければならない場合があります。
該当する列のマップが終わったら、「OK」をクリックします。
ソースを正しく使用するには、Oracle BIサーバーはビジネス・モデルの観点で各ソースに何が含まれているかを知る必要があります。したがって、ファクト表の各論理表ソースの集計内容を定義する必要があります。集計内容のルールは、このファクト表内に格納されているデータの粒度のレベルを定義します。このファクト論理表に関連する各ディメンションに対して粒度のレベルを定義します(関連するすべてのディメンションが定義されるようにします)。詳細は、「集計対象のファクト・データのソース作成による集計ナビゲーションの設定」を参照してください。
論理表のソースが断片のセットである場合、すべての断片を同じ列のセットにマップする必要はありません。ただし、列のマップの方法に応じて、サーバーは異なる回答を返します。
論理表のすべての断片が同じ列のセットにマップされている場合、断片化されたソースのセットは、その論理表の論理表ソースの全体的なユニバースであると見なされます。これは、断片のセットに基づいてメジャーの集計が計算されることを意味します。
マップされた列のセットが断片間で異なる場合は、Oracle BIサーバーは、断片がすべて揃ってなく(いくつかの断片が欠けているため)、集計ロールアップの計算を行うことは不適切であると想定します。この場合、メジャー集計としてサーバーからNULLが返されます。
|
注意: すべての断片を同じ列のセットにマップすることをお薦めします。 |
「論理表ソース」ダイアログの「コンテンツ」タブを使用して、すべての集計表のコンテンツの定義、ソースの断片化された表の定義、およびWHERE句(返される行数を制限する場合)を定義します。詳細は、「集計ナビゲーションの断片化の内容の設定」を参照してください。
このソース・コンテンツ情報は、Oracle BIサーバーに対して、適切な物理集計ファクト表に問合せを送信するために知る必要のある情報を伝えます(適切な物理集計ディメンション表内の値に結合され、その値によって制約される)。物理レイヤーの集計ファクト表と集計ディメンション表の間に結合が存在することを確認してください。
結合を確認するための推奨方法の1つに、ファクト論理表を選択し、ビジネス・モデル図(「選択された表と直接結合」)を開くという方法があります。この図には、このファクト論理表に直接結合されているディメンション論理表のみが表示されます。論理ファクトおよびディメンション・ソース内で同じ物理表が使用されている場合は、ディメンション表は表示されません。
図11-3は、ビジネス・モデル図(「選択された表と直接結合」)のビューに「Fact - Assess」ファクト論理表が表示される様子を示しています。
表11-1は、図11-3に示されている「Fact - Assess」ファクト表に直接結合されている各ディメンション表の論理レベルのリストです。
表11-1 「コンテンツ」タブに表示されるディメンションおよび論理レベル
| ディメンション | 論理レベル |
|---|---|
|
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 |
管理ツールのビジネス・モデルとマッピング・レイヤーで、論理表ソースをダブルクリックします。
「論理表ソース」ダイアログで「コンテンツ」タブをクリックし、表11-2に基づいて次の手順を実行します。
論理ソースが集計表であり、論理ディメンションを定義している場合は、「集計の内容、グループ化」のリストから「論理レベル」を選択します。次に、「論理レベル」のリストから、論理ファクト表の結合先となる各論理ディメンション表の適切なレベルを選択します。
総計レベルを指定している場合を除き、すべてのディメンションに論理レベルを指定する必要があります。レベルが指定されていないディメンションは、最も詳細なレベルであると解釈されます。
|
注意: 論理レベルまたは列ごとに集計コンテンツを指定するオプションもありますが、論理レベルのみを使用することをお薦めします。列ごとにコンテンツを定義する必要がある場合は、次の操作を実行します。
1つのビジネス・モデル内では、論理レベルによる集計と列による集計を混在させないようにしてください。 |
ソースの断片化された表の定義を指定するには、「断片化の内容」ボックスを使用して、ソースが集計の特定のレベルのデータの部分を表す場合にソースに含まれる値の範囲を記述します。
ボックスに計算式を直接入力することも、ボックスの右にある「式ビルダー」ボタンをクリックすることもできます。「断片化の内容」の「式ビルダー」で、既存の論理列に関するコンテンツを指定できます。詳細は、「集計ナビゲーションの断片化の内容の設定」を参照してください。
「このソースはこのレベルの他のソースと組み合せる必要がある」を選択します。
このオプションは、同じ集計レベルに複数のソースがある場合にのみ有効です。たとえば、ある論理表ソースは名字がA - Mで始まる人のレコードを指し示し、別の論理表ソースは名字がN - Zで始まる人のレコードを指し示す場合がこれに該当します。
(オプション)結果表でソースによって使用される行数を制限するには、「このWHERE句フィルタを使用して、返される行を制限します(WHEREを除く)」というラベルのボックスにWHERE句フィルタを指定します。WHERE句を直接入力するか、「式ビルダー」ボタンをクリックして、「式ビルダー」を開き、WHERE句を作成して「OK」をクリックできます。
詳細は「WHERE句フィルタについて」を参照してください。
ソースの値が一意である場合は、「個別値の選択」オプションを選択します。
表11-2 「論理表ソース」の「コンテンツ」タブのオプション
| オプション | 説明 |
|---|---|
|
集計の内容、グループ化 |
コンテンツの集計方法です。 |
|
「詳細」ボタン |
「詳細」をクリックすると次のオプションが表示されます。
|
|
断片化の内容 |
データ・ソースの内容のビジネス・モデルの観点からの説明です。同じレベルの集計の情報がデータの値に応じて複数の表に分割される場合、データは断片化します。一般的な状況として、期間によってデータが断片化することがあります。詳細は、「集計ナビゲーションの断片化の内容の設定」を参照してください。 |
|
このソースはこのレベルの他のソースと組み合せる必要がある |
同じレベルの集計のデータ・ソースに重複する情報が含まれない場合、このオプションを選択します。この場合、集約のこのレベルにおける完全な情報を得るには、すべてのソースが結合される必要があります。 |
|
個別値の選択 |
ソースの値が一意である場合に使用します。 |
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)
開始点、中間点、終了点は注意深く選択してください。
|
注意: >=述語および<述語を使用して、断片の内容の記述が重ならないようにしてください。各断片では、上限値は<として表す必要があります。<=を使用するとエラーが発生します。同様に、 |
ここで参照される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)
変数の詳細は、第19章を参照してください。
各コンテンツ・フィルタには、異なる列に任意の数の述語を含めることができます。各列の述語は値ベース、範囲ベースのいずれでも構いません。
断片1:
<logicalColumn1 predicate> AND <logicalColumn2 predicate > ... AND <logicalColumnM predicate>
断片n:
<logicalColumn1 predicate> AND <logicalColumn2 predicate > ... AND <logicalColumnM predicate>
すべての断片が同じM列に述語を持つのが理想的です。論理列に述語制約がない場合、Oracle BIサーバーは断片にその列のすべての値のデータが含まれていると想定します。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 nというラベルが記載されています。実際の断片化の内容の文には、これらのラベルは含めないでください。
例11-1 断片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サーバーは、問合せで適切なソースを選択するためにソースのコンテンツを知る必要があります。
たとえば、すべての店舗でのソフト・ドリンクの売上を追跡するデータベースがあるとします。データの詳細レベルは店舗レベルです。図11-4に示すように、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論理列をUSDollars物理列にマップします。
このソースの集計コンテンツの指定は次のようになります(「論理表ソース」ダイアログの「コンテンツ」タブ内)。
論理レベルでのグループ化:
GeographyDim.CityLevel, ProductDim.ProductLevel
これは、Oracle BIサーバーに対して、このソースには都市および製品レベルのデータがあることを通知します。
断片化の内容の指定は次のようになります。
SoftDrinks.Products.Product = '7-Up'
またこれは、ドメインを完全にするために都市および製品レベルのCokeとPepsiのデータを格納する表と組み合されるため、「論理表ソース」ダイアログの「コンテンツ」タブ内のオプションを選択して、このソースが他のソースと同じレベルで組み合されることを指定します。
仮想表に適切な物理結合を構築します。図11-5でCityProductSales2がCities表およびProducts表と結合されていることに注目してください。
この例では、ソーダの売上のドメイン全体が2つのソースによって構成されています。ドメインは多くのソースを持つことができます。これらすべてのソースは、「各レベルには、組み合せることによってそのレベルの値のドメイン全体が構成されるソースが含まれていなければならない」というルールに従う必要があります。各レベルに完全なドメインを設定することは、Coke、Pepsiおよび7-Upを求める問合せで7-Upが欠落しないようにするのに役立ちます。またこれは、事前に計算され集計表に格納されている情報を要求する問合せにおいて、その問合せではこの集計表に含まれない他の情報も要求する場合であっても、該当する情報は必ずその集計表から取得されるようにするのに役立ちます。
