| Oracle Business Intelligence Standard Edition Oneチュートリアル リリース10g（10.1.3.2.1） E05487-01 |
|
 戻る |
 次へ |
この章では、作成したBISE1_TUTORIALWHデータ・マートから、Oracle BIメタデータ・リポジトリを構築します。
この章の後半には、「上級者向け」と注記されている項があります。このチュートリアルの初回の学習時に、これらの項が不要と思われる場合は、省略してかまいません。
前提条件: この前の章までに記述された作業を完了していない場合は、BISE1_TUTORIALWHスキーマを移入しないと、この章に進めません。第2.2.2.3項「BISE1_TUTORIALWHスキーマ」で、この作業を行う方法について説明しています。
この章は次のトピックで構成されています。
Oracle BI Administration Toolは、BIメタデータ・リポジトリのメンテナンスに使用します。Oracle BI Administration Toolでは、リポジトリの3つのレイヤーである、a）「Physical」レイヤー、b）「Business Model and Mapping」レイヤー、c）「Presentation」レイヤーがグラフィカル表示されます。これら各レイヤーについては、この後の項で説明します。Oracle BI Server Administration Toolを使用して、次を実行します。
データベースなどのデータソースからメタデータをインポートして、BIリポジトリの物理レイヤーを作成します。
インポートしたメタデータを単純化して、ビジネス・モデルに再編成します。
ビジネス・モデルからプレゼンテーション・レイヤーを作成し、Oracle BI Answersを使用してビジネス・インテリジェンス情報をリクエストするユーザーに提示します。
「Physical」レイヤーは、Oracle BI Serverによるクエリーの発行先となるデータソースと、複数のデータソースに対するクエリーの処理に使用される物理データベースなどのデータソース間の関係を定義します。「Physical」レイヤーの移入には、データベースなどのデータソースからメタデータをインポートする方法をお薦めします。データソースが複数の場合、それらは同じタイプでも異なるタイプでもかまいません。既存のデータソースから、スキーマ全体またはスキーマの一部をインポートできます。さらに、オブジェクトを手動で「Physical」レイヤーに作成できます。
メタデータをインポートするときは、インポート・プロセス時に収集された情報に基づいて、データソースの多くのプロパティが自動的に構成されます。また、インポート後に、結合関係のように、物理データソースのメタデータに存在しない、他のデータソース属性を定義できます。「Physical」レイヤーには、データベース、スプレッドシート、XML文書などの、1つ以上のデータソースを配置できます。この例では、Warehouse Builderを使用してデータ・マートを作成したBISE1_TUTORIALWHスキーマから、表をインポートして構成します。
この項は次のトピックで構成されています。
データソースのスキーマ情報をOracle BI Serverリポジトリにインポートするには、ODBCデータソースが必要です。ODBCデータソースは、Oracle BI Standard Edition Oneのインストール時に事前作成されています。
次の手順に従って、ODBCデータソースが正しく構成されており、データベースに接続できることを確認します。
「スタート」→「すべてのプログラム」→「管理ツール」→「データ ソース (ODBC)」をクリックして、ODBC データ ソース アドミニストレータを起動します。「システム DSN」タブをクリックします。
「システム データ ソース」リストで「bise1db」を選択し、「構成」をクリックします。
「Oracle ODBC ドライバ構成」ダイアログ・ボックスで「接続テスト」をクリックします。「ユーザー名」を「BISE1_TUTORIALWH」に変更します。BISE1_TUTORIALWHデータベース・アカウントのパスワードを入力します。「OK」をクリックします。
BISE1_TUTORIALWHデータベース・アカウントのパスワードは、インストール時に定義されています。
「接続に成功しました」メッセージが表示されます。「OK」をクリックします。
「OK」をクリックして、ODBCデータ ソース アドミニストレータを終了します。
「システム データ ソース」リストにbise1dbがない場合は、次の手順に従って作成します。
「ODBC データ ソース アドミニストレータ」ダイアログ・ボックスで「追加」をクリックします。
「データ ソースの新規作成」ダイアログ・ボックスで「Oracle in BISE1Home1_1」データベース・ドライバを選択します。「完了」をクリックして、「Oracle ODBC ドライバ構成」ダイアログ・ボックスを開きます。
「Oracle ODBC ドライバ構成」ダイアログ・ボックスで、「データ ソース名」に「BISE1DB」を入力し、ドロップダウン・リストから適切なTNS サービス名である「BISE1DB」を選択し、スキーマの「ユーザー ID」として「BISE1_TUTORIALWH」を入力します。
「接続テスト」をクリックして、「Oracle ODBC ドライバ接続」ダイアログ・ボックスを開きます。BISE1_TUTORIALWHデータベース・スキーマのパスワードを入力し、「OK」をクリックします。
「接続に成功しました」メッセージが表示されます。「OK」をクリックします。
「Oracle ODBC ドライバ構成」ダイアログ・ボックスで「OK」をクリックします。ODBC データ ソース アドミニストレータにBISE1DBシステム・データソースが追加されていることを確認し、「OK」をクリックしてODBC データ ソース アドミニストレータを終了します。
この項では、次の手順に従って、Oracle BI Serverサービスを再起動し、bise1リポジトリをメモリーにロードします。
「スタート」→「すべてのプログラム」→「管理ツール」→「コンポーネント サービス」をクリックします。「サービス」をダブルクリックします。
Oracle BI Serverサービスを再起動します。Oracle BI Presentation ServerサービスとOracle BI Java Hostサービスが起動されていることを確認します。これらが起動されていない場合は起動します。サービスの起動順序は任意です。「コンポーネント サービス」ウィンドウを閉じます。
BISE1_TUTORIALWHスキーマからリポジトリにディメンション表とファクト表をインポートするには、次の手順を実行します。
「スタート」→「すべてのプログラム」→「Oracle Business Intelligence」→「Administration」をクリックして、Oracle BI Administration Toolを起動します。「File」→「Open」→「Online」をクリックします。
「Open Online AnalyticsWeb」ダイアログ・ボックスで、ユーザーIDおよびパスワードとして「Administrator」を入力します。パスワードは大文字と小文字が区別されます。「Open」をクリックします。
リポジトリがオンライン・モードで開き、「Physical」レイヤーにはBISE1_SALESWHが、「Business Model and Presentation」レイヤーにはそれに対応するGEC_DWが表示されます。GEC_DWは、事前構築済のデータ・マートBISE1_SALESWHから作成された、事前構築済のサブジェクト・エリアです。リポジトリの内容を確認してください。BISE1_TUTORIALWHデータ・マートに基づいて、同じようなBIメタデータ・リポジトリを作成します。
|
注意: オンライン・モードでは、Oracle BI Serverによってリポジトリ・ファイルが開き、オペレーティング・システムによってファイルに書込みロックがかけられます。このモードでは、Oracle BI ServerはAdministration Toolのエージェントとして動作できます。Oracle BI Serverは、Administration Toolからの指示を受け、インメモリー・リポジトリのコピーをAdministration Toolに送信します。次に、Oracle BI ServerはAdministration Toolからの変更メッセージをリスニングし、それらの変更をインメモリー・コピーに反映します。Administration Toolから指示があったときは、変更済のファイルを保存するようオペレーティング・システムに要求します。Administration Toolをオンライン・モードで起動するときは、編集対象のリポジトリ（つまり、DSNのデフォルト・リポジトリであるリポジトリ）をポイントするOracle BI ODBC DSNを選択します。変更内容はAdministration ToolによってOracle BI Serverに通知され、該当する変更がOracle BI Serverによってインメモリー・コピーに反映されます。 オフライン・モードでの作業も可能です。オフライン・モードの場合、Administration Toolとリポジトリ間の関係は、Windowsアプリケーションとファイル間の関係と同様です。アプリケーション（この場合はAdministration Tool）によってファイルが編集目的で開き、変更がインメモリー・コピーに反映され、オペレーティング・システムに変更済ファイルの保存を要求します。 通常の場合は、オフライン・モードでリポジトリを構築し、更新や変更がわずかな場合はオンライン・モードを使用します。 |
BISE1_TUTORIALWHスキーマから表をインポートします。「File」→「Import」→「from Database」を選択し、「BISE1DB」ODBC接続を選択します。「User Name」として「BISE1_TUTORIALWH」を入力します。BISE1_TUTORIALWHデータベース・アカウントのパスワードを入力します。「OK」をクリックします。
「Import」ダイアログ・ボックスで「BISE1_TUTORIALWH」スキーマ・フォルダを開き、[Ctrl]を押しながらクリックして、「CHANNELS」、「GEOGRAPHY」、「PRODUCTS」、「PROMOTIONS」、「SALES」、「TIMES」の各表を選択します。
|
注意: WB_RT_VERSION_FLAG表は、インポート対象として選択しないでください。これはOracle Warehouse Builderによって使用される内部表で、BIメタデータ・リポジトリには必要ありません。 |
「Tables」および「Keys」は、デフォルトで選択されるオプションです。基礎となるスキーマ構造については学習済であり、外部キーがすでに定義されていることがわかっているので、先に進み「Foreign Keys」オプションを選択して外部キーのインポートを選択します。外部キーのインポートに進むかどうかの確認を求められたら、「Yes」をクリックします。
スキーマ内の結合が不明な場合または作成するクエリーに異なる結合が必要な場合は、「Tables」と「Keys」のみを選択し、後で物理結合を作成することをお薦めします。
「Import」をクリックします。「Connection Pool」ダイアログ・ボックスが開きます。
「Connection Pool」ダイアログ・ボックスの「General」タブで、コール・インタフェースが正しく設定されていることを確認します。ドロップダウン・リストから「Default (OCI 10g)」を選択します。データソース名を適切なtnsnames.oraエントリ（このチュートリアルでは「BISE1DB」を使用）に変更します。これはTNSサービス名で、ODBC DSNでないことに注意してください。
残りの設定はそのままにして「OK」をクリックし、「Connection Pool」ダイアログ・ボックスを閉じます。
インポートが完了したら、「Close」をクリックして、「Import」ダイアログ・ボックスを閉じます。
リポジトリの「Physical」レイヤーで、「bise1db」→「BISE1_TUTORIALWH」スキーマ・フォルダを開き、正しい表がインポートされていることを確認します。
「BISE1_TUTORIALWH」フォルダを右クリックします。ポップアップ・メニューから「Rename」を選択し、フォルダ名を「GEC_DW_TUTORIAL」に変更します。
「File」→「Check In Changes」を選択し、変更をチェックインします。接続性を確認するには、「Tools」→「Update All Row Counts」を選択します。オブジェクトをチェックアウトするかどうかの確認を求められたら、「Yes」をクリックします。
「Update All Row Counts」が完了したら、Administration Toolの「Physical」レイヤーに行数が表示されていることを確認します。「Tools」→「Options」を選択します。「Show row count in physical view」を選択し、「OK」をクリックします。
図4-3のように、各表の行数が表示されます。
この項では、Oracle BI Administration Toolを使用して、リポジトリの「Business Model and Mapping」レイヤーを構築します。
Administration Toolの「Business Model and Mapping」レイヤーでは、データのビジネス・モデル、つまり論理モデルを定義し、そのビジネス・モデルと「Physical」レイヤーのスキーマ間のマッピングを指定します。このレイヤーは、物理スキーマを単純化し、ユーザーのデータ・ビューのベースを構築するレイヤーです。Administration Toolの「Business Model and Mapping」レイヤーには、1つ以上のビジネス・モデル・オブジェクトを配置できます。ビジネス・モデル・オブジェクトには、ビジネス・モデルの定義と、ビジネス・モデルの論理表から物理表へのマッピングが含まれます。
ビジネス・モデルの主要な目的は、ユーザーがビジネスを分析する際に使用するユーザーレベルのボキャブラリを取り込むことです。ビジネス・モデルは物理スキーマを単純化し、ユーザーのビジネス・ボキャブラリを物理ソースにマッピングします。大半のボキャブラリは、ビジネス・モデルの論理列に翻訳されます。論理列の集合が論理表になります。各論理列（結果として、各論理表）は、1つ以上の物理オブジェクトをソースとして持つことができます。
論理表には、ファクトとディメンションという2つの主要なカテゴリがあります。論理ファクト表には、各組織がビジネスの業績や成果を評価する際に使用する尺度が含まれています。論理ディメンション表には、ファクトの認定に使用されるデータが配置されます。
この項は次のトピックで構成されています。
ビジネス・モデルを作成する手順は次のとおりです。
「Business Model and Mapping」レイヤーで、空白の領域を右クリックし、「New Business Model」を選択します。
「Business Model」ダイアログ・ボックスで、ビジネス・モデル名に「GEC_DW_TUTORIAL」を指定し、「Available for queries」ボックスは未選択のままにします。「Description」フィールドは、自分または別の開発者用にコメントを書き記す場合に使用します。今回は空白のままにします。
「OK」をクリックして、「Business Model」ダイアログを閉じます。新しいGEC_DW_TUTORIALビジネス・モデルが「Business Model and Mapping」レイヤーに表示されます。ビジネス・モデルにマークされた赤い記号は、クエリーの実行がまだ有効になっていないことを表します。ビジネス・モデルへのクエリーの実行は、「Presentation」レイヤーを定義し、リポジトリがグローバルな整合性チェックに合格した後で有効にします。
ビジネス・モデルに論理表、論理結合および論理列を手動で定義できます。または、「Physical」レイヤーのオブジェクトを「Business Model and Mapping」レイヤーにドラッグするだけで、BI Administration Toolによってそれらを自動作成することもできます。このチュートリアルでは、自動定義を使用します。論理表、論理結合および論理列を手動作成する方法の詳細は、Oracle BI Administration Tool製品のドキュメントを参照してください。
ビジネス・モデルを移入する手順は次のとおりです。
「Physical」レイヤーで、「GEC_DW_TUTORIAL」フォルダのすべての表を選択し、それらを「GEC_DW_TUTORIAL」ビジネス・モデル・フォルダにドラッグします。
このアクションによって、「Business Model and Mapping」レイヤーに論理表が自動的に作成されます。SALES論理表の表アイコンが黄色で表示されていることがわかります。「Business Model and Mapping」レイヤーでは、このアイコンはファクト表を表します。ディメンション表は、白色の表アイコンで示されます。
「SALES」論理表→「Sources」を開き、自動作成された論理表のソースを表示します。論理表のソースは、論理表から物理表へのマッピングを定義します。論理表のSourcesフォルダには、論理表のソースが含まれています。論理表SALESのソース名は、物理表と同じ名前になります。ただし、それらの名前はマッピングに影響を与えることなく、「Business Model and Mapping」レイヤーで変更できます。
「Business Model and Mapping」レイヤーで、「AMOUNT」論理列をダブルクリックし、「Logical Column」ダイアログ・ボックスを開きます。「Aggregation」タブをクリックします。「Default aggregation rule」ドロップダウン・リストで「Sum」を選択します。「OK」をクリックします。
リポジトリを保存します。変更をチェックインする場合は「OK」をクリックし、整合性をチェックする場合は「No」と回答します。Administration Toolとリポジトリを開いたままにして、次の項に進みます。
|
注意: グローバルな整合性チェックでは、リポジトリ全体にエラーがないかどうかがチェックされます。「Business Model and Mapping」レイヤーと「Presentation」レイヤーでは、いくつかのより一般的なチェックを実行します。これらのレイヤーはまだ定義されていないため、リポジトリの他のレイヤーが構築されるまで、このチェックは無視します。整合性チェックの詳細は、このチュートリアルの後半で学習します。 |
ビジネス・モデル・オブジェクトの名前を変更する手順は次のとおりです。
「Tools」→「Utilities」をクリックします。「Utilities」ダイアログ・ボックスで「Rename Wizard」をクリックし、「Execute」をクリックします。
Rename Wizardで、中央のペインをスクロールします。「Business Model and Mapping」タブをクリックして「GEC_DW_TUTORIAL」ビジネス・モデルを選択し、「Add Hierarchy」ボタンをクリックします。「Next」をクリックします。
「Logical Table」と「Logical Column」のみを選択します。「Next」をクリックします。
「All text lowercase」を選択します。「Add」をクリックします。
「First letter capital」を選択します。「Add」をクリックします。
「Next」をクリックし、変更を確認します。「Next」をもう一度クリックします。
「Finish」をクリックし、「Business Model and Mapping」レイヤーの論理表と論理列が想定どおりに変更されていることを確認します。
Channels論理表の次の列の名前を変更します。
Total_nameをChannel_totalに変更
Class_nameをChannel_classに変更
|
注意: オブジェクトの名前を変更するには、そのオブジェクトを右クリックして、ポップアップ・メニューから「Rename」を選択します。または、列を選択してその名前をクリックし、編集ボックスを開く方法でも名前変更できます。 |
Times論理表の次の列の名前を変更します。
Calendar_year_nameをYearに変更
Calendar_month_descriptionをMonthに変更
Calendar_quarter_nameをQuarterに変更
Geography論理表の次の列の名前を変更します。
City_nameをCityに変更
Province_nameをProvinceに変更
Country_nameをCountryに変更
Subregion_nameをSubregionに変更
Region_nameをRegionに変更
Total_nameをGeography_totalに変更
Productsの次の列の名前を変更します。
Category_nameをProduct_Categoryに変更
Subcategory_nameをProduct_Subcategoryに変更
Promotionの次の列の名前を変更します。
Subcategory_nameをPromotion_Subcategoryに変更
Category_nameをPromotion_Categoryに変更
Salesでは、AmountをAmount_Soldに変更します。
リポジトリを保存します。変更をチェックインする場合は「OK」をクリックし、整合性をチェックする場合は「No」と回答します。
不要なビジネス・モデル・オブジェクトを削除する手順は次のとおりです。
「Business Model and Mapping」レイヤーのChannels論理表で[Ctrl]を押しながらクリックし、「Channel_id」、「Channel_source_id」、「Class_id」、「Class_source_id」、「Total_id」、「Total_source_id」の各論理列を選択します。ハイライト表示された列のいずれかを右クリックして「Delete」を選択し、列を削除します。また、キーボードの[Del]キーを使用することもできます。「Yes」をクリックして、削除を確認します。
図4-12に示すように、Channels論理表の論理列が4つのみになっていることを確認します。
前述の手順を繰り返し、Geography表のいくつかの論理列を削除します。この手順の完了後は、図4-13に示す論理列のみになるようにします。
前述の手順を繰り返し、Products表のいくつかの論理列を削除します。この手順の完了後は、図4-14に示す論理列のみになるようにします。
前述の手順を繰り返し、Promotion表のいくつかの論理列を削除します。この手順の完了後は、図4-15に示す論理列のみになるようにします。
前述の手順を繰り返し、Sales表のいくつかの論理列を削除します。この手順の完了後は、図4-16に示す論理列のみになるようにします。
Times表の列はいっさい削除しないでください。
リポジトリを保存します。変更をチェックインする場合は「OK」をクリックし、整合性をチェックする場合は「No」と回答します。
ディメンション階層は、ビジネス・モデルに正式な階層を導入することで、Oracle BI Serverによって有用な尺度を計算し、ユーザーがより詳細な情報にドリルダウンできるようにします。ビジネス・モデルでは、ディメンション階層は、1つの論理ディメンション表に属する論理列の階層的な構造を表現します。ビジネス・モデルでよく使用されるディメンション階層には、期間、製品、顧客、サプライヤなどがあります。
ディメンション階層は「Business Model and Mapping」レイヤーに作成され、エンド・ユーザーがOracle BI AnswersやInteractive Dashboardsなどのエンド・ユーザー・ツールでディメンション階層を見ることはありません。それぞれのディメンション階層では、そのディメンションの属性を階層レベルに編成します。これらのレベルは、ビジネスで要求される組織ルールとレポート・ニーズに対応します。レベルは、データのより詳細なビューを取得するために、ディメンション間のドリル操作にOracle BI Serverが使用する構造です。ディメンション階層のレベルは、集計ナビゲーションを実行するときや、レベルベースの尺度計算を構成するとき、さらにはOracle BIユーザーによるドリルダウン時にデータ・リクエストに表示される属性を指定するときに使用します。
ディメンション階層を構築する手順は次のとおりです。
「Channels」論理表を右クリックし、「Create Dimension」を選択します。オブジェクトをチェックアウトするかどうかの確認を求められたら、「Yes」をクリックします。この手順のアクションで作成した「ChannelsDim」オブジェクトを右クリックし、「Expand All」を選択します。
ChannelsDimディメンション階層が図4-17に示されている階層と同じであることを確認します。
「Channels Detail」レベルを右クリックし、「New Object」→「Parent Level」を選択します。「Logical Level」ダイアログ・ボックスで、論理レベルの名前を「Class」にし、「Number of elements at this level」を3に設定します。この数値は正確でなくてもかまいません。絶対的な数値よりも、あるレベルと次のレベル間の比率のほうが重要です。これらの数値は、どの集計ソースを選択するか（クエリーの正確さではなく最適化）にのみ影響します。「OK」をクリックして、「Logical Level」ダイアログ・ボックスを閉じます。新しいClassレベルが階層に追加されます。
「Class」レベルを右クリックし、「Expand All」を選択します。「Channel_class」列を「Channels Detail」レベルから「Class」レベルにドラッグして、この論理列を階層のこのレベルに関連付けます。
「Channel_class」を右クリックして、「New Logical Level Key」を選択します。「Logical Level Key」ダイアログ・ボックスで、「Channel_class」および「Use for drilldown」が選択されていることを確認します。レベル・キーは各論理レベルにおける一意の要素を定義します。各レベル・キーは、そのレベルの1つ以上の列で構成できます。
「OK」をクリックして、「Logical Level Key」ダイアログ・ボックスを閉じます。Channel_class列が、キーのアイコンとともに表示されるようになります。
「Class」レベルを右クリックし、「New Object」→「Parent Level」を選択します。「Logical Level」ダイアログ・ボックスで、論理レベルの名前を「Channel Total Attribute」にし、「Number of elements at this level」を1に設定します。ダイアログ・ボックスを閉じます。
「Channel Total Attribute」レベルを右クリックし、「Expand All」を選択します。「Channel_total」列を、「Channels Detail」レベルから「Channel Total Attribute」レベルにドラッグします。次に、「Channel_total」を右クリックして、「New Logical Level Key」を選択します。
「Logical Level Key」ダイアログ・ボックスで、「Channel_total」および「Use for drilldown」が選択されていることを確認します。「OK」をクリックして、ダイアログ・ボックスを閉じます。Channel_total列が、キーのアイコンとともに表示されるようになります。
「Channel_name」列を右クリックして、「New Logical Level Key」を選択します。「Logical Level Key」ダイアログ・ボックスで、「Use for drilldown」が選択されていることを確認します。「OK」をクリックして、「Logical Level Key」ダイアログを閉じます。Channel_nameとDimension_keyの両方が、キーのアイコンとともに表示されます。
「Channels Detail」レベルをダブルクリックして、「Logical Level」ダイアログ・ボックスを開きます。「Keys」タブをクリックします。「Channels Detail_Key」をクリックし、「Edit」をクリックします。
「Logical Level Key」ダイアログ・ボックスで、「Use for drilldown」の選択を解除します。
「OK」をクリックして、「Logical Level Key」ダイアログ・ボックスを閉じます。キーのアイコンが異なることに注意してください。Channel_nameはドリルダウン先として使用できますが、Channels Detail_Keyは使用できません。ユーザーがAnswersまたはダッシュボードでドリルダウン操作を行うとき、デフォルトのドリル先は、次の下位レベルで「Use for drilldown」が選択されているレベル・キーとなります。この例では、Channel Class列（次の上位レベル）からドリルダウンすると、デフォルトのドリルダウン先はChannels Detail_Key列ではなくChannel_name列となります。
「OK」をクリックして、「Logical Level」ダイアログ・ボックスを閉じます。完成したChannelsDim階層は、図4-29のようになります。
リポジトリを保存します。変更をチェックインする場合は「OK」をクリックし、整合性をチェックする場合は「No」と回答します。
次に、Products、Geography、Times、Promotionsの各論理表のディメンション階層を構築します。ガイドとして、前述の手順と、この後に示されている各図およびその他の特性を使用します。不確かな場合は、GEC_DWのディメンションを参照してください。GEC_DW_TUTORIALの定義はGEC_DWの定義と同じになります。
Products論理表のディメンション階層を構築します。ガイドとして、前述の手順、図4-30および次の特性を使用します。
ProductsDimディメンション階層には、次の特性を構成します。
Subcategoryレベルでは、「Number of elements at this level」を21に設定します。
Categoryレベルでは、「Number of elements at this level」を5に設定します。
Product Total Attributeレベルでは、「Number of elements at this level」を1に設定します。
Products Detailレベルでは、Products Detail_keyに対して「Use for drilldown」の選択を解除します。
ProductsDim階層の他のすべてのキーでは、「Use for drilldown」を選択します。
この手順が完了したら、リポジトリを保存します。全体の整合性はチェックしません。
Geography論理表のディメンション階層を構築します。ガイドとして、前述の手順と図4-31を使用します。各レベルで、要素のデフォルトの数値を受け入れます。
Times論理表のディメンション階層を構築します。ガイドとして、前述の手順と図4-32を使用します。各レベルで、要素のデフォルトの数値を受け入れます。
Promotions論理表のディメンション階層を構築します。ガイドとして、前述の手順と図4-33を使用します。各レベルで、要素のデフォルトの数値を受け入れます。
リポジトリを保存します。変更をチェックインする場合は「OK」をクリックし、整合性をチェックする場合は「No」と回答します。
この項では、Oracle BI Administration Toolを使用して、リポジトリの「Presentation」レイヤーを構築します。
「Presentation」レイヤーは、「Physical」レイヤーおよび「Business Model and Mapping」レイヤーの後に構築され、「Business Model and Mapping」レイヤーに抽象化のレベルを追加します。このレイヤーは、エンド・ユーザーがOracle BI Answersなどのクライアント・ツールやアプリケーションを使用して表示するデータのビューになります。「Presentation」レイヤーは、「Business Model and Mapping」レイヤーをエンド・ユーザーがさらに単純化またはカスタマイズする手段となります。たとえば、列をカタログやフォルダに整理できます。
ユーザー用にデータのビューを単純化することで、ユーザーにとって意味のあるデータのみを公開してユーザーが必要とする形式でデータを整理でき、さらには特定のユーザー・グループの必要に応じてデータ名を変更できるようになるため、ユーザーのビジネス・ニーズに基づいたクエリーの作成が容易になります。
通常、「Presentation」レイヤーのオブジェクトは、「Business Model and Mapping」レイヤーからオブジェクトをドラッグすることで作成します。対応するオブジェクトが「Presentation」レイヤーに自動的に作成されます。その後で、「Presentation」レイヤーのオブジェクトを名前変更したり再編成できます。
「Presentation」レイヤーを構築する手順は次のとおりです。
「GEC_DW_TUTORIAL」ビジネス・モデルを「Business Model and Mapping」レイヤーから「Presentation」レイヤーにドラッグして、「Presentation」レイヤーに「GEC_DW_TUTORIAL」カタログを作成します。「Presentation」レイヤーで「GEC_DW_TUTORIAL」カタログを開きます。「Presentation」レイヤーの表および列が、「Business Model and Mapping」レイヤーの表および列と完全に一致することに注意してください。また、ディメンション階層が表示されないことにも注意してください。
リポジトリを保存します。全体の整合性はチェックしません。
初期のビジネス・モデルの構築はこれで完了です。さらに開発を進めるには、リポジトリをテストする必要があります。最初に、整合性チェック・オプションを使用して、リポジトリにエラーがないかどうかをチェックします。次に、Oracle BI Answersを使用してクエリーを実行し、リポジトリをテストします。最後に、クエリーのログ・ファイルを調べ、Oracle BI Serverによって生成されたSQLを検証します。
この項は次のトピックで構成されています。
整合性チェックはAdministration Toolのユーティリティで、リポジトリが特定の要件を満たしているかどうかをチェックします。リポジトリとリポジトリ内のビジネス・モデルが整合性チェックに合格しないと、ビジネス・モデルをクエリーで使用できるようになりません。リポジトリまたはビジネス・モデルに整合性がない場合は、整合性のない状態を警告する詳細なメッセージが通知されます。
Consistency Check Managerには、次の3種類のメッセージが表示されます。
エラー・メッセージ: リポジトリの整合性を保つために修正が必要なエラーを示します。
警告メッセージ: Oracle BI Server管理者の意図に応じてエラーかどうかが決まる状況を示します。たとえば、Administratorユーザーのパスワードが空の場合は警告メッセージが通知されますが、これはリポジトリの整合性の要件ではありません。
ベスト・プラクティス・メッセージ: 状況に関する情報を提供しますが、整合性のないことを示すわけではありません。たとえば、キーが定義されていない物理表がある場合は、ベスト・プラクティス・メッセージが表示されます。物理表に対するキーを定義することがベスト・プラクティスですが、これはリポジトリの整合性を実現するための要件ではありません。
Consistency Check Managerには、メッセージごとに、メッセージ・タイプ、オブジェクト・タイプおよびオブジェクトが明示されると同時に、メッセージの詳細な説明が表示されます。選択したメッセージ・タイプのみを表示するオプション、修飾名を使用して結果を表示するオプション、リポジトリ内のすべてのオブジェクトをチェックするオプション、および別のファイルに結果をコピーするオプションがあります。
整合性チェックを実行する手順は次のとおりです。
「File」→「Check Global Consistency」を選択します。
リポジトリに整合性があることを知らせ、クエリーで使用できるようにするかどうかを尋ねるメッセージを受け取ります。GEC_DW_TUTORIALビジネス・モデルをクエリーで使用できるようにするには、「Yes」をクリックしす。オブジェクトをチェックアウトするかどうかの確認を求められたら、「Yes」をクリックします。Consistency Check Managerが表示されます。
Consistency Check Managerにエラー・メッセージが表示された場合は、リポジトリを編集して非整合性を修正し、整合性チェックを再度実行します。
警告メッセージおよびベスト・プラクティス・メッセージのみが表示された場合は、この時点ではメッセージを無視して「Close」をクリックします。
「Business Model and Mapping」レイヤーで、GEC_DW_TUTORIALビジネス・モデルのアイコンが変わり、そのビジネス・モデルがクエリーで使用可能になっていることを確認してください（1本線入りの赤い円マークがなくなっています）。
リポジトリを保存します。全体の整合性をチェックするかどうかを質問されたら、「No」をクリックします（チェックしたばかりなので）。
「GEC_DW_TUTORIAL」ビジネス・モデル・オブジェクトをダブルクリックして、「Business Model properties」ダイアログ・ボックスを開きます。オブジェクトをチェックアウトするかどうかの確認を求められたら、「Yes」をクリックします。「Available for queries」が選択されていることを確認します。「OK」をクリックして、ダイアログ・ボックスを閉じます。
クエリーのロギングを有効にする手順は次のとおりです。
「Manage」→「Security」を選択します。「Security Manager」の左側のペインで「Users」を選択します。右側のペインにAdministratorユーザーが表示されます。
右側のペインで「Administrator」をダブルクリックします。オブジェクトをチェックアウトするかどうかの確認を求められたら、「Yes」をクリックします。「User」ダイアログ・ボックスが開きます。「User」タブが選択されていることを確認します。「Logging level」フィールドの値を2に設定します。「OK」をクリックします。
リポジトリをテストするには、いくつかのクエリーを生成して結果を取得し、クエリー・ログを調べる必要があります。クエリーのアクティビティは、個々のユーザー・レベルでロギングします。ロギングの用途は、テスト、デバッグおよびテクニカル・サポートです。クエリーのロギングはサイズの大きなログ・ファイルを生成し、パフォーマンスに影響を与えるおそれがあるため、本番モードでは無効にするのが一般的です。
「Security Manager」ウィンドウを閉じます。
全体の整合性をチェックします。警告メッセージは無視してかまいません。「Consistency Check Manager」ダイアログ・ボックスで「Close」をクリックします。
リポジトリを保存します。
Oracle BI Answersを使用してクエリーを実行する手順は次のとおりです。
「スタート」→「すべてのプログラム」→「Oracle Business Intelligence」→「Presentation Services」を選択します。Administratorとして、パスワードをAdministratorにして、Oracle Business Intelligenceにログインします。
「アンサー」リンクをクリックして、サブジェクト・エリア「GEC_DW_TUTORIAL」をクリックします。
左側のペインで、「Geography」フォルダをクリックして開きます。Answersのフォルダおよび列が、リポジトリの「Presentation」レイヤーのフォルダおよび列と一致することに注意してください。
左側のペインの「Province」列をクリックして、右側のリクエスト検索条件に追加します。「Sales」フォルダの「Amount_Sold」列をクリックして、リクエスト検索条件に追加します。
「結果」タブをクリックします。デフォルトでは、結果は複合レイアウトで表示されます。これは、「タイトル」ビューと「テーブル」ビューで構成されます。
クエリー・ログを使用してクエリーを検証する手順は次のとおりです。
このページの右上にある「設定」→「管理」をクリックし、「Oracle BI Presentation Services Administration」ウィンドウを開きます。「セッションの管理」リンクをクリックして、「セッション管理」ウィンドウを開きます。
「セッション管理」ウィンドウの「カーソルキャッシュ」で、最後のエントリに該当する「ログの表示」リンクをクリックします。
Administratorによって最後に実行されたクエリーのログが表示されます。ログ・ファイルは、図4-42のようになります。
SQL Requestセクションを見てください。このセクションには、Answersによって実行された論理SQLが記録されています。
SQL Requestセクションの直後にあるGeneral Query Infoセクションを見てください。このセクションには、クエリーの実行対象となったリポジトリ、サブジェクト・エリアおよびプレゼンテーション・カタログが記録されています。
General Query Infoセクションの直後にあるSending query to database named BISE1_TUTORIALWHセクションを見てください。このセクションには、Oracle BI Serverの接続先の物理データソースと、生成された物理SQLが記録されています。
このファイルの残りのセクションには、クエリーのステータスや返された行の数などの情報が記録されています。
クエリー・ログを閉じます。「セッション管理」ウィンドウを閉じます。「Oracle BI Presentation Services Administration」ウィンドウを閉じます。Answersは開いたままにしておきます。
ビジネスでは、多くの状況で尺度の値の比較が要求され、その比較を表現する計算が必要になります。Oracle BI Serverには、多種多様な計算を実行する計算エンジンが組み込まれています。エンド・ユーザーは、計算尺度を使用することで、「第3四半期での売掛金の残高」や「受注数量と出荷数量の差異」のように、ビジネス上の質問ができるようになります。式ビルダーでは、SQLで作成する式と同様の式を作成できます。このレッスンの例では、式ビルダーを使用して、Answersのユーザーに対して列として表示される計算尺度を作成します。これにより、ユーザーは使い慣れた用語を使用してクエリーを簡単に構築できます。
Administration Toolには、計算尺度を作成する方法が複数用意されています。計算式のオブジェクトに既存の論理列を使用する方法、計算式のオブジェクトに物理列を使用する方法、およびCalculation Wizardを使用してプロセスを自動化する方法があります。このチュートリアルでは、これら3つの方法のすべてが説明されています。計算後に集計ルールを適用する必要のある計算には、物理列を使用します。計算前に集計ルールを適用する必要のある計算式には、論理列を使用します。また、Answersで計算尺度を作成することもできます。リポジトリに計算尺度を作成することのメリットは、尺度を一度作成すれば、すべてのユーザーが使用できることです。既存の論理列に基づいて論理列計算式を定義することのメリットは、一度の定義で済むことです。物理列に基づいて計算式を作成するときは、元となる各物理ソースに対するマッピングが必要になります。
この項は次のトピックで構成されています。
新しい尺度を作成する手順は次のとおりです。
Oracle BI Administration Toolに戻ります。「Business Model and Mapping」レイヤーで、「Sales」論理列の下の「Cost」論理列にナビゲートします。
「Cost」論理列の集計ルールを「Sum」に設定します。列をダブルクリックして「Logical Column properties」ダイアログ・ボックスを開き、「Aggregation」タブをクリックします。オブジェクトをチェックアウトするかどうかの確認を求められたら、「Yes」をクリックします。「OK」をクリックします。
「File」→「Check In Changes」をクリックするか、ツールバーの「Check In Changes」アイコンをクリックして、変更をチェックインします。
全体の整合性をチェックするかどうかの確認を求められたら、「Yes」をクリックします。Consistency Check Managerが開き、警告メッセージとベスト・プラクティス・メッセージが表示されます。メッセージを確認します。
「Close」をクリックして、Consistency Check Managerを終了します。リポジトリを保存します。
Answersに戻り、Answersで新規列をテストします。Answersが起動していない場合は、「スタート」→「すべてのプログラム」→「Oracle Business Intelligence」→「Presentation Server」を選択し、パスワードAdministratorを使用してAdministratorとしてログインし、「アンサー」リンクをクリックしてサブジェクト・エリア「GEC_DW_TUTORIAL」をクリックします。
Answersがすでに起動しており、Geography.Province列が（前述の項で作成したリクエストで）選択済の場合は、列名の下にある「X」をクリックして削除します。
「サーバーメタデータの再ロード」をクリックします。
Geography.Region, Sales.Amount_Sold, Sales.Costというリクエストを作成します。左側のナビゲーション・ツリーからこれらの列を選択し、「結果」タブをクリックすると、結果が表示されます。
この項では、計算式の定義に既存の論理列を使用して、Sales論理表にGross Profitという名前の新しい計算尺度を定義します。この尺度は、Answersの任意のリクエストで使用できます。GEC_DWにProfitという似たような計算尺度がありますが、この尺度はSales Analysisダッシュボードの一部のリクエストで使用されます。
論理列を使用して計算尺度を作成する手順は次のとおりです。
Oracle BI Administrator Toolで、「Sales」論理表を右クリックし、「New Object」→「Logical Column」を選択します。
「Logical Column」ダイアログ・ボックスで、論理列の名前を「Gross Profit」にし、「Use existing logical columns as the source」を選択します。
省略記号（...）をクリックして、式ビルダーを起動します。左側のペインで「Logical Tables」をクリックします。中央のペインの「Sales」を選択し、右側のペインの「Amount_Sold」をダブルクリックして計算式に追加します。
マイナス記号の演算子をクリックして計算式に追加します。右側のペインの「Cost」をダブルクリックして計算式に追加します。
「OK」をクリックして、式ビルダーを終了します。「Logical Column」ダイアログ・ボックスに、この計算式が表示されていることに注意してください。
「OK」をクリックして、「Logical Column」ダイアログ・ボックスを閉じます。ビジネス・モデルにGross Profit論理列が表示されます。変更をチェックインします。
「Gross Profit」論理列を「Presentation」レイヤーの「Sales」表にドラッグします。変更をチェックインします。リポジトリを保存してAnswersに戻ります。
Answersで「サーバーメタデータの再ロード」をクリックします。「Sales」を開き、AnswersにGross Profit列が表示されていることを確認します。次のリクエストを作成します。
Geography.Region, Sales.Amount_Sold, Sales.Cost, Sales.Gross Profit
「結果」をクリックします。図4-50に示す結果と同じ結果が表示されていることを確認します。
「設定」→「管理」→「セッションの管理」→「ログの表示」をクリックして、クエリー・ログを表示します。Gross Profitアイテムが使用されたことを確認します。
AMOUNTとCOSTの差異が、外側のクエリー・ブロック（図4-51の例では「SAWITH0.c2 - SAWITH0.c1 as c4」）で計算されていることに注意してください。論理列を使用してGross Profit計算を定義したため、最初に列が合計されてから、差異が計算されます。これらの結果を、次の項のクエリーの結果と比較してみてください。
クエリー・ログ、「セッション管理」ウィンドウおよび「Oracle BI Presentation Services Administration」ウィンドウを閉じます。
この項では、計算式の定義に物理列を使用して、Sales論理表にGross Profit Physicalという名前の新しい計算尺度を定義します。これを行う手順は次のとおりです。
Oracle BI Administration Toolに戻ります。「Business Model and Mapping」レイヤーで、「Sales」論理表を右クリックし、「New Object」→「Logical Column」を選択します。
|
注意: オブジェクトをチェックアウトするかどうかの確認を求められたら、「Yes」をクリックします。 |
「Logical Column」ダイアログ・ボックスで、論理列の名前を「Gross Profit Physical」にします。
「Aggregation」タブをクリックします。デフォルトの集計ルールを「Sum」に設定します。
「OK」をクリックして、「Logical Column」ダイアログ・ボックスを閉じます。ビジネス・モデルにGross Profit Physicalが追加されます。
「Sales」→「Sources」を開き、SALES論理表ソースをダブルクリックします。「Logical Table Source」ダイアログ・ボックスが開きます。「Column Mapping」タブをクリックします。
「Show unmapped columns」オプションを選択します。
Gross Profit Physical論理列に対応する省略記号（...）をクリックします。
式ビルダーで、「Physical Tables」→「SALES」→「AMOUNT」を選択し、「Insert」をクリックして列を計算式に追加します。マイナス記号の演算子をクリックして計算式に追加します。
「Physical Tables」→「SALES」→「COST」を選択し、「Insert」をクリックして列を計算式に追加します。
「OK」をクリックして、式ビルダーを終了します。「Logical Table Source」ダイアログ・ボックスに、この式が追加されていることに注意してください。
「Logical Table Source」ダイアログ・ボックスを閉じます。Gross Profit Physicalのアイコンが変わり、集計ルールが適用されていることが示されます。
「Gross Profit Physical」を「Presentation」レイヤーの「Sales」にドラッグします。変更をチェックインして、リポジトリを保存します。Answersに戻ります。「サーバーメタデータの再ロード」をクリックします。「Sales」を開き、AnswersにGross Profit Physical列が表示されていることを確認します。
次のリクエストを作成します。
Geography.Region, Sales.Amount_Sold, Sales.Cost, Sales.Gross Profit Physical
「結果」をクリックします。（物理列を使用して構築した）Gross Profit Physicalの実行結果が、（論理列を使用して構築した）Gross Profitの実行結果と同じであることを確認します。
論理列の計算式は「sum(Amount_Sold) - sum(Cost)」のようになりますが、それに対して、物理列の計算式は「sum(AMOUNT_SOLD -COST)」のようになります。演算の法則により、ColumnAとColumnBを合計してから、それらの合計の差異を計算した結果は、最初にそれぞれの差異を計算してから（行ごとにColumnAの値からColumnBの値を減算）、それらの差異を合計した結果と同じになります。そのため、この例では、論理列と物理列で計算結果が同じになります。
「設定」→「管理」→「セッションの管理」→「ログの表示」をクリックして、クエリー・ログを表示します。結果は、図4-58のようになります。
図4-58に示す例のsum(T9278.AMOUNT- T9278.COST)によって、Amount_SoldとCostの差異が最初に計算された後で合計されていることに注意してください。
すべてのウィンドウを閉じます。
ウィザードを使用して計算尺度を作成する手順は次のとおりです。
Oracle BI Administration Toolに戻ります。「Business Model and Mapping」レイヤーで、論理列の「Sales」→「Amount_Sold」を右クリックし、「Duplicate」を選択します。Amount_Sold#1という名前の新しい列が、ビジネス・モデルに追加されます。名前を「Amount_Sold#1」から「Category Sales」に変更します。
「Category Sales」をダブルクリックして、「Logical Column」ダイアログ・ボックスを開きます。「Levels」タブをクリックし、ProductsDimの論理レベルとして「Category」を選択します。「OK」をクリックします。
これで、Category Salesが、クエリーで使用されると、カテゴリ・レベルで販売総額を計算するレベルベースの尺度になりました。レベルベースの尺度は、占有率を表す尺度を作成するときに役立ちます。この後の手順では、Calculation Wizardを使用して、占有率を表す尺度を作成します。ダイアログ・ボックスを閉じます。
「Amount_Sold」を右クリックし、「Calculation Wizard」を選択します。Calculation Wizardが起動します。「Next」をクリックします。Amount_Soldと比較する列として「Category Sales」を選択します。「Next」をクリックします。
「Change」および「Percent Change」の選択を解除し、「Percent」を選択します。「Calculation Name」を「Share of Category Sales」に変更します。「Next」をクリックし、オブジェクトをチェックアウトするかどうかの確認を求められたら、「Next」をもう一度クリックします。「Finish」をクリックします。
ビジネス・モデルにShare of Category Salesが追加されます。「Category Sales」および「Share of Category Sales」を「Presentation」レイヤーの「Sales」にドラッグします。変更をチェックインします。リポジトリを保存します。
Oracle BI Answersで「サーバーメタデータの再ロード」をクリックします。「Sales」を開き、AnswersにCategory SalesとShare of Category Salesが表示されていることを確認します。
リポジトリに変数を使用することで、管理タスクを効率化すると同時に、メタデータの内容を動的に変更して、データ環境の変化に対応することが可能になります。1つの変数は、必ず1つの値を持ちます。変数は、Administration Toolの式ビルダーで、リテラルまたは定数の代わりに使用できます。Oracle BI Serverによって、各変数の値が、メタデータ内のその変数自体に代わって使用されます。
変数および初期化ブロックの定義には、Variable Managerを使用します。変数は、リポジトリ変数とセッション変数の2種類に分類できます。
1つのリポジトリ変数は、必ず1つの値を持ちます。リポジトリ変数には、静的変数と動的変数の2種類があります。静的リポジトリ変数の値は定数で、Oracle BI Serverが実行されている間は変化しません。動的リポジトリ変数の値は、初期化ブロックのクエリーから返されるデータによってリフレッシュされます。Variable Managerでは、リポジトリ変数は疑問符のアイコンで示されます。
セッション変数は、各ユーザーのログオン時に作成され、値を割り当てられます。セッション変数には、システム変数と非システム変数の2種類があります。システム変数の名前は予約されており、Oracle BI Serverによって、ユーザー認証など特定の目的に使用されます。非システム変数は、管理者によって作成されるアプリケーション固有の変数です。Variable Managerでは、システム変数も非システム変数も疑問符のアイコンで示されます。
初期化ブロックは、動的リポジトリ変数、システム・セッション変数および非システム・セッション変数の初期化に使用されます。
この項は次のトピックで構成されています。
セッション変数は、その値が初期化ブロックから取得される点では、動的リポジトリ変数と同じです。ただし、動的リポジトリ変数とは異なり、セッション変数の初期化は予定されていません。
ユーザーがセッションを開始したときに、Oracle BI Serverによって、セッション変数の新しいインスタンスが作成され初期化されます。リポジトリ変数とは異なり、1つのセッション変数には、Oracle BI Server上のアクティブなセッションと同数のインスタンスがあります。セッション変数の各インスタンスは、異なる値に初期化される場合があります。
セッションとは、クライアント・アプリケーションを実行するユーザーのインスタンスです。セッションはアプリケーションの起動時に開始され、アプリケーションの終了時に終了します。
セッション変数の初期化ブロックの内容を表示する手順は次のとおりです。
Oracle BI Administration Toolで、「Manage」→「Variables」をクリックして、Variable Managerを起動します。「Session」→「Initialization Blocks」をクリックします。
setUserという名前のセッション初期化ブロックがすでに作成されています。「setUser」をダブルクリックして、「Session Variable Initialization Block」ダイアログ・ボックスを開きます。
「Edit Data Source」をクリックして、「Session Variable Initialization Block Data Source」ダイアログ・ボックスを開きます。「Browse」をクリックし、「Select Connection Pool」ダイアログ・ボックスで「bise1db」→「Connection Pool」を選択します。
「Select」をクリックして、「Session Variable Initialization Block Data Source」ダイアログ・ボックスの「Connection Pool」フィールドに接続プールが表示されていることを確認します。
「Default Initialization String」フィールドで、初期化文字列を確認します。必要に応じて、右方向にスクロールし、次の文字列全体を参照します。
select ':USER', case when upper(':USER') = 'KURT' then 'Germany' when
upper(':USER') = 'KEIKO' then 'Japan' when upper(':USER')= 'CHARLES' then
'United Kingdom' when upper(':USER') = 'KAREN' then 'United States of America'
end, 'CountryManagers', 2 from Dual
「OK」をクリックして、「Session Variable Initialization Block Data Source」ダイアログ・ボックスを閉じます。「Session Variable Initialization Block」ダイアログ・ボックスに、初期化文字列と接続プールが表示されていることを確認します。「Edit Data Target」をクリックして、「Session Variable Initialization Block Variable Target」ダイアログ・ボックスを開きます。USER、UserCountry、GROUP、LOGLEVELという4つの変数が作成されていることに注意してください。
変数の順序に注目してください。この順序が重要です。変数の順序は、初期化ブロックの初期化文字列の変数値の順序と一致する必要があります。
「OK」をクリックして、「Session Variable Initialization Block Variable Target」ダイアログ・ボックスを閉じます。「Session Variable Initialization Block」ダイアログ・ボックスの「Variable Target」セクションに、変数が表示されます。すべてのダイアログ・ウィンドウを閉じます。
変更をチェックインして、リポジトリを保存します。
初期化ブロックおよびセッション変数をテストする手順は次のとおりです。
「Manage」→「Security」をクリックして、Security Managerを起動します。左側のペインで「Groups」をクリックします。右側のペインで、グループ「CountryManagers」をダブルクリックします。
「Permissions」をクリックして、「User/Group Permissions」ダイアログ・ボックスを開きます。「Filters」タブをクリックします。「Add」ボタンをクリックします。
「GEC_DW_TUTORIAL」を開き、「Geography」プレゼンテーション表をクリックします。
「Select」をクリックして、「User/Group Permissions」ダイアログ・ボックスの「Name」フィールドに「Geography」を追加します。
右側の省略記号（...）をクリックして、式ビルダーを起動します（ボタンの表示にはスクロールが必要な場合があります）。
「Logical Tables」→「Geography」→「Country」を選択し、「Insert」をクリックして、「Country」を計算式に追加します。等号（=）演算子をクリックして計算式に追加します。
「Session Variables」→「UserCountry」を選択し、「Insert」をクリックして、「UserCountry」をVALUEOF()関数の引数として計算式に追加します。図4-70の式と比較します。
「OK」をクリックして、式ビルダーを終了します。「User/Group Permissions」ダイアログ・ボックスにフィルタが追加されます。「User/Group Permissions」ダイアログ・ボックスを閉じます。
「Group」ダイアログ・ボックスを閉じます。Security Managerを終了します。変更をチェックインして、リポジトリを保存します。
Oracle BI Answersに進みます。Administratorとしてすでにログインしている場合は、いったんログアウトしてから、ユーザー名にKeikoを使用して、パスワードなしでログインします。
サブジェクト・エリア「GEC_DW_TUTORIAL」を選択します。GeographyにCountry、SalesにAmount_Soldを使用して、新しいリクエストを作成します。
「結果」タブをクリックします。表示される国がJapanのみであることに注意してください。
Answersは開いたままにしておきます。
動的リポジトリ変数を作成する手順は次のとおりです。
Oracle BI Administration Toolで、「Manage」→「Variables」をクリックして、Variable Managerを起動します。「Repository」→「Initialization Blocks」をクリックします。
空白の領域を右クリックして「New Initialization Block」を選択し、「Repository Variable Init Block」ダイアログ・ボックスを開きます。初期化ブロックに「getMaxSalesDate_01」という名前を付けます。
「Edit Data Source」をクリックして、「Repository Variable Init Block Data Source」ダイアログ・ボックスを開きます。「Browse」をクリックして、「Select Connection Pool」ダイアログ・ボックスを開きます。
「bise1db」→「Connection Pool」オブジェクトをダブルクリックして、「Repository Variable Init Block Data Source」ダイアログ・ボックスの「Connection Pool」フィールドに追加します。「Default Initialization String」フィールドに、次のSQLを入力します。
select dimension_key, calendar_year_name, calendar_month_description from times where dimension_key=(select max(times) from sales)
「OK」をクリックして、「Repository Variable Init Block Data Source」ダイアログ・ボックスを閉じます。「Repository Variable Init Block」ダイアログ・ボックスに、接続プールと初期化文字列が追加されます。
「Edit Data Target」をクリックして、「Repository Variable Init Block Variable Target」ダイアログ・ボックスを開きます。
「New」ボタンを使用して、3つの変数、maxSalesDate_01、maxYear_01およびmaxMonthDesc_01を作成します。この順序が重要です。変数の順序は、初期化文字列の列の順序と一致する必要があります。
「OK」をクリックして、「Repository Variable Init Block Variable Target」ダイアログ・ボックスを閉じます。「Repository Variable Init Block」ダイアログ・ボックスの「Variable Target」フィールドに、変数が表示されます。
「Edit Data Source」をクリックして、「Repository Variable Init Block Data Source」ダイアログ・ボックスを開きます。「Test」をクリックして、結果が図4-74のようになることを確認します。
「Results」を閉じます。「Repository Variable Init Block Data Source」ダイアログ・ボックスを閉じます。Variable Managerに、getMaxSalesDate_01初期化ブロックが表示されます。
「Repository」→「Variables」→「Dynamic」を選択して、Variable Managerに表示される変数を確認します。Variable Managerを終了します。変更をチェックインして、リポジトリを保存します。
Oracle BI Answersで、サブジェクト・エリア「GEC_DW_TUTORIAL」を使用して、次の条件を持つリクエストを構築します。
Times.Year, Sales.Amount_Sold
Year列の「フィルターの追加」ボタンをクリックします。「フィルターの作成と編集」ダイアログ・ボックスで、「追加」→「変数」→「リポジトリ」をクリックします。
「サーバー変数」フィールドに、「maxYear_01」と入力します。次に、「フィルターの作成と編集」ダイアログ・ボックスを閉じ、結果を確認します。結果は、図4-76のようになります。
適切な権限を持つユーザーは、バックエンドの物理データベースに対して、データベース・リクエストを直接作成および実行できます。リクエストの結果はOracle BI Answersで表示および操作でき、さらにはOracle BI Interactive DashboardsおよびOracle BI Deliversに組み込むことができます。
物理リクエストを作成および実行できるかどうかは、「Oracle BI Presentation Services Administration」の次の権限設定によって制御されます。
直接データベースリクエストの編集: この権限が設定されているユーザーは、直接データベース・リクエストを作成できます。デフォルトでは、この権限はPresentation Serverの管理者として定義されているユーザーに対してのみ設定されます。
直接データベースリクエストの実行: この権限が設定されているユーザーは、物理リクエストを実行できます。デフォルトでは、この権限はどのユーザーにも有効になっていません。Presentation Server管理者は、この設定を変更できます。
直接データベース・リクエストを実行する手順は次のとおりです。
Oracle BI Presentation ServicesにAdministratorアカウントでログインしていない場合は、いったんログアウトしてから、Administratorとしてログインしなおします。
Oracle BI Answersで、「設定」→「管理」をクリックします。「Oracle BI Presentation Services Administration」画面で「権限の管理」をクリックして、「権限の管理」画面を開きます。
「権限の管理」画面で、下にスクロールして「アンサー」を表示します。Presentation Server管理者グループに、「直接データベースリクエストの編集」権限が付与されていることを確認します。デフォルトでは、管理者ユーザーはこのグループのメンバーです。Presentation Server管理者グループにこの権限が付与されていない場合は付与します。
Oracle BI Answersで、「直接リクエストの作成」リンクをクリックします。「接続プール」フィールドに、GEC_DW_TUTORIALデータソースの接続プール名を、二重引用符で囲んで入力します（この例では、"bise1db"."Connection Pool"）。「SQL 文」フィールドに、「SELECT * FROM channels」と入力します。
「SQL を確認し、カラムを取得してください。」をクリックし、Channels表の列を表示します。
「結果」をクリックして、Channels表の内容を確認します。
「検索条件」をクリックして、直接データベース・リクエストの指定ページに戻ります。この状態で次の項に進みます。
集計表には、事前計算された結果が格納されます。これらはディメンション属性の組合せに対して、事前集計（通常は合計計算）された尺度となります。集計表の使用は、意思決定支援システムにおいて、クエリーの応答時間を短縮化するために使用される一般的な手法です。これによって、実行時における計算が不要になり、ユーザーへの結果の配信がより高速になります。計算は事前に実行され、その結果が表に格納されます。集計表の行数は非集計表よりも大幅に少なくなるため、処理時間が短縮化されます。
Oracle BI Serverの集計ナビゲーション機能では、クエリーの作者やツールがクエリーに集計表を指定しなくても、集計表に格納された情報を自動的に使用できます。Oracle BI Serverでは、最も高速に回答を提供する表はサーバーによって決定されるため、ユーザーは的確なビジネス上の質問を問いかけることに専念できます。Oracle BI Serverに集計表へのナビゲーションに必要な情報を持たせるには、リポジトリに専用のメタデータを構成する必要があります。また、集計表は、Oracle BI Administration ToolのAggregate Persistence Wizardユーティリティを使用して作成することもできます。
この項は次のトピックで構成されています。
直接データベース・リクエストを使用して集計表を作成する手順は次のとおりです。
Windowsエクスプローラを使用して、Oracle BI Standard Edition Oneのインストール先ディレクトリ（デフォルトのインストール・ディレクトリはc:\oracle\bise1）に移動します。tutorial\bi_adディレクトリに移動して、集計表用のSQLスクリプト・ファイルagg_table_sql.txtを開きます。
Oracle BI Answersの直接データベース・リクエストの「検索条件」ページで、「接続プール」フィールドが、二重引用符で囲まれたBISE1_TUTORIALWHデータソースの接続プール名のままであることを確認します（この例では、"bise1db"."Connection Pool"）。
agg_table_sql.txtファイルから、最初の表AGG_DAY_SALES_Fに対する最初のCREATE TABLE SQLをコピーし、それを「SQL 文」フィールドに貼り付けます。
「結果」をクリックします。「結果無しの場合」メッセージが表示されます。
「検索条件」タブをクリックします。「SQL 文」フィールドからCREATE TABLE SQLを削除し、「SQL 文」フィールドに「SELECT COUNT(*) FROM AGG_ DAY_SALES_F」と入力します。
「SQL を確認し、カラムを取得してください。」をクリックします。「結果」をクリックします。COUNT(*) = 229が表示されるはずです。
「検索条件」タブをクリックします。「SQL 文」フィールドから、SELECT COUNT(*) SQL文を削除します。agg_table_sql.txtファイルから、2番目の表AGG_PRODUCTS_CATEGORY_Dに対する2番目のCreate Table SQLをコピーし、それを「SQL 文」フィールドに貼り付けます。
「結果」をクリックします。「結果無しの場合」メッセージが表示されます。
「検索条件」タブをクリックします。「SQL 文」フィールドに、「SELECT COUNT(*) FROM AGG_PRODUCTS_CATEGORY_D」というSQLを入力します。
「結果」をクリックします。COUNT(*) = 6が表示されるはずです。
|
注意: 「結果」タブをクリックすると、「ダウンロード」ウィンドウが表示される場合があります。このウィンドウは無視してかまいません。 |
Oracle BI Administration Toolでは、BISE1_TUTORIALWHスキーマから2つの新しい集計表をインポートする必要があります。これを行う手順は次のとおりです。
「File」→「Import」→「from Database」を選択し、「BISE1DB」ODBC接続を選択します。BISE1_TUTORIALWHデータベース・アカウントのパスワードを入力します。「OK」をクリックします。
|
注意: リポジトリが開いていない場合は、「File」→「Open」→「Online」を選択すると、リポジトリを開くことができます。 |
「Import」ダイアログ・ボックスで「BISE1_TUTORIALWH」スキーマ・フォルダを開き、[Ctrl]を押しながらクリックして、次の各表を選択します。
AGG_DAY_SALES_F
AGG_PRODUCTS_CATEGORY_D
「Tables」オプションおよび「Keys」オプションが、デフォルトで選択されていることに注意してください。
「Import」をクリックします。「Connection Pool」ダイアログ・ボックスが開きます。オブジェクトをチェックアウトするかどうかの確認を求められたら、「Yes」をクリックします。
インポートが完了したら、「Close」をクリックして、「Import」ダイアログ・ボックスを閉じます。
「Physical」レイヤーで、インポートされた2つの表を、「BISE1_TUTORIALWH」フォルダから「GEC_DW_TUTORIAL」フォルダにドラッグします。
「BISE1_TUTORIALWH」フォルダを右クリックして「Delete」を選択し、「Physical」レイヤーから「BISE1_TUTORIALWH」フォルダを削除します。
「Physical」レイヤーで「GEC_DW_TUTORIAL」フォルダを開き、集計表が追加されていることを確認します。変更をチェックインします。
「Physical」レイヤーにある2つの集計表を選択して右クリックし、「Update Row Count」を選択して接続性を確認します。AGG_DAY_SALES_Fは229行、AGG_PRODUCTS_CATEGORY_Dは6行となるはずです。
変更をチェックインして、リポジトリを保存します。
集計表に物理結合を作成する手順は次のとおりです。
「Physical」レイヤーで、[Ctrl]を押しながらクリックし、2つの新しい集計表と「Times」表を選択します。ツールバーの「Physical Diagram」アイコンをクリックします。
Physical Diagramで「New Foreign Key」ボタンを使用して、次の結合を作成します。一致する表キーを作成するかどうかの確認を求められたら、「Yes」をクリックします。
AGG_PRODUCTS_CATEGORY_D. CATEGORY_ID = AGG_ DAY_SALES_F. CATEGORY_ID TIMES.DIMESION_KEY = AGG_SALES_F.TIMES
|
注意: デフォルトで選択されている結合列は正しくない場合があります。結合対象として正しい列が選択されていることを確認してください。 |
エラー・メッセージが表示された場合は、物理列のデータ型をチェックし、同じであることを確認します。「Physical Column」ダイアログ・ボックスで、データ型の手動変更が必要な場合があります。キーの作成が必要であることを伝えるメッセージが表示された場合は、「Yes」をクリックします。
変更をチェックインして、リポジトリを保存します。
集計列に論理列をマッピングする手順は次のとおりです。
表4-1の説明に従って、「Physical」レイヤーの列を「Business Model and Mapping」レイヤーの対応する列にドラッグすることで、既存の論理列を新しいソースにマッピングします。
「Business Model and Mapping」レイヤーで、「Sales」→「Sources」を開き、新しい論理表ソースAGG_DAY_SALES_Fが作成されていることを確認します。
「AGG_ DAY_SALES_F」論理表ソースをダブルクリックして「Logical Table Source」ダイアログ・ボックスを開き、「Column Mapping」タブをクリックしてマッピングを確認します。
「Content」タブをクリックします。「Logical Level」フィールドのドロップダウン・メニューを使用して、次の論理レベルを設定します。
ProductsDim = Category
TimesDim = Times Detail
ここでは、ファクト表の集計内容を、ディメンション階層において対応するレベルに設定しています。以降の手順では、ディメンション表の集計ソースに対して同種のレベルを設定します。設定後は、ユーザーが特定のレベルに対してクエリーを実行すると、Oracle BI Serverは詳細表ではなく集計表にアクセスします。
たとえば、集計内容の設定後にProduct Category別のAmount_Soldを問い合せた場合、サーバーは集計ファクト表AGG_DAY_SALES_Fと、対応する集計ディメンション表AGG_PRODUCTS_CATEGORY_Dにアクセスします。
Product SubcategoryやProduct Nameなど、ここで指定したレベルよりも下位のレベルに対してユーザーがクエリーを実行した場合は、サーバーは詳細表にアクセスします。論理レベル以上のレベルに対してクエリーが実行されたときは必ず集計表が使用されるため、Total_Nameなどの上位のレベルに対してクエリーを実行した場合は、集計表が使用されます。
「OK」をクリックして、「Logical Table Source」ダイアログ・ボックスを閉じます。
「Products」→「Sources」を開き、新しい論理表ソースAGG_PRODUCTS_CATEGORY_Dが作成されていることを確認します。
「AGG_PRODUCTS_CATEGORY_D」論理表ソースをダブルクリックし、「Column Mapping」タブをクリックしてマッピングを確認します。
「Content」タブをクリックします。「Logical Level」フィールドのドロップダウン・メニューを使用して次の論理レベルを設定し、集計表に格納する詳細レベルを指定します。
ProductsDim = Category
「OK」をクリックして、「Logical Table Source」ダイアログ・ボックスを閉じます。変更をチェックインします。整合性をチェックします。エラーがある場合は、先へ進む前に修正します。
リポジトリを保存します。「Presentation」レイヤーの変更が不要であることに注意してください。変更は、クエリーの処理方法とアクセスするソースに影響するビジネス・モデルに対して行います。Oracle BI Serverは、集計内容の指定に基づいて、クエリーの内容に適合する新しいソースを自動的に使用します。
集計をテストする手順は次のとおりです。
Oracle BI Answersで「サーバーメタデータの再ロード」をクリックします。
「アンサー」リンクをクリックします。サブジェクト・エリア「GEC_DW_TUTORIAL」を選択します。
次のクエリーを作成します。
Products.Products_Category, Sales.Amount_Sold
「設定」→「管理」→「セッションの管理」をクリックします。「カーソルキャッシュ」にある最後に実行されたクエリーの箇所に進み、「ログの表示」をクリックします。
ログを調べ、集計表AGG_CUSTOMER_STATE_DおよびAGG_DAY_SALES_Fがアクセスされていることを確認します。
すべてのウィンドウを閉じます。
ビジネスの業績を過去の期間と比較する機能は、ビジネス分析の基本です。ビジネスに期間比較を導入することで、複数の期間にわたるデータを分析し、データのコンテキストを明確にできます。しかし、Ralph Kimball氏が次に述べているように、SQLは時間軸で比較するように設計されていません。
「データ・ウェアハウスで最も困難な分野は、簡単なビジネス分析をSQLに翻訳することです。SQLはビジネス・レポートを考慮して設計されていません。SQLは、リレーショナルな表セマンティクスを便利でアクセス可能な形式で表現するために設計された暫定的な言語にすぎず、1970年代の中期に研究者や初期の開発者が最初のリレーショナル・システムの構築を進めることを目的としていました。このため、SQLには今年と昨年のデータを比較する直接的な方法がないのです。」
- Ralph Kimball氏
これに対するソリューションは、Oracle BIリポジトリに時系列データをモデル化することです。これによって、ユーザーは1つのリクエストで必要な結果を入手可能になります。Oracle BI Serverは、複数のクエリーをパラレルに実行して結果を取得します。バックグラウンドで実行され、時系列尺度をサポートするクエリーは、ユーザーには透過的です。
Oracle BI Serverには、時系列比較を実現する関数としてAgoおよびToDateが組み込まれています。これらの関数は、両方とも尺度に対して動作します。Ago関数は、現在の時間からシフトした特定期間における集計値を計算します。たとえば、Ago関数は、現在の四半期の毎月の販売額を、対応する四半期前の販売額とともに算出します。ToDate関数は、指定した期間の開始日から現在の表示時間までの尺度属性の集計に使用されます。たとえば、ToDate関数は、指定した年の月初来販売額を計算できます。これらの関数は、式ビルダー使用して適用します。
この項は次のトピックで構成されています。
時間ディメンションとしてディメンションを特定する手順は次のとおりです。
Oracle BI Administration Toolで、「Business Model and Mapping」レイヤーの「TimesDim」ディメンション階層をダブルクリックします。
「Dimension」ダイアログ・ボックスで「Time dimension」を選択します。「OK」をクリックして、「Dimension」ダイアログ・ボックスを閉じます。
「TimesDim」を「Times Detail」レベルまで開き、「Times Detail」レベルをダブルクリックして「Logical Level」ダイアログ・ボックスを開きます。「Keys」タブをクリックして、Times Detail_Keyに対して「Chronological Key」オプションを選択します。
「OK」をクリックして、「Logical Level」ダイアログ・ボックスを閉じます。
Month Ago尺度を作成する手順は次のとおりです。
「Sales」を右クリックして、「New Object」→「Logical Column」を選択し「Logical Column」ダイアログ・ボックスを開きます。論理列に「Month Ago Dollars」という名前を付けます。「Use existing logical columns as the source」を選択します。
省略記号（...）をクリックして、式ビルダーを起動します。「Functions」→「Time Series Functions」→「Ago」を選択します。「Insert」をクリックして、式ビルダーにAgo関数を追加します。
式の中の「<<expr>>」をクリックします。「Logical Tables」→「Sales」を選択し、「Amount_Sold」をダブルクリックして式に追加します。
式の中の「<<level>>」をクリックします。「Time Dimensions」→「TimesDim」を選択し、「Times Detail」をダブルクリックして式に追加します。
式の中の「<<integer>>」をクリックして、「1」と入力します。Ago関数は、今月から1か月前のAmount_Sold値を計算します。
「OK」をクリックして、式ビルダーを終了します。「Logical Column」ダイアログ・ボックスに、この計算式が表示されます。
「OK」をクリックして、「Logical Column」ダイアログ・ボックスを閉じます。
Change Month Ago尺度を作成するには、図4-91に示す式を使用して、「Change Month Ago Dollars」という名前の別の論理列を作成します。「Use existing logical columns as the source」を必ず選択してください。
ToDate尺度を作成するには、図4-92に示す式を使用して、「Year To Date Dollars」という名前の別の論理列を作成します。「Use existing logical columns as the source」を必ず選択してください。
時系列尺度をテストする手順は次のとおりです。
「Business Model and Mapping」レイヤーから「Sales」プレゼンテーション表に、3つの時系列尺度をドラッグします。
変更をチェックインします。全体の整合性をチェックし、リポジトリを保存します。
Oracle BI Answersで「サーバーメタデータの再ロード」をクリックします。
サブジェクト・エリア「GEC_DW_TUTORIALWH」を使用して、新しいリクエストを作成します。
「Times.Year」、「Times.Month」および「Times.Calendar_month_id」を選択します。
Year=2006に対するフィルタを追加します。
Calendar_month_idを昇順でソートします。次に、この列を非表示にします。これを行うには、Calendar_month_idに対して「カラムのプロパティ」をクリックし、「カラムフォーマット」タブで「隠す」オプションを選択します。
ここで、次の列を追加します。
Sales.Amount_Sold
Sales.Month Ago Dollars
Sales.Change Month Ago Dollars
Answersの結果は、図4-94のようになります。
「検索条件」で、「Sales.Month Ago Dollars」と「Sales.Change Month Ago Dollars」を削除し、「Sales.Year To Date Dollars」を追加します。
Answersの結果は、図4-95のようになります。
ビジネス・モデルの1つの論理表に必要なデータが、複数の物理ソースに分散していることはよくあります。論理表ソースに特定のレベルのデータのセット全体が含まれないときは、セット全体が含まれるように、その構成要素を指定する必要があります。特定のレベルの個々のソースに含まれる情報がドメインの一部、つまり断片である場合、クエリーに対する適切なソースを選択するには、ソースの内容をOracle BI Serverが把握している必要があります。目標は、ユーザーの観点から、シームレスで効率的なアクセスを実現することです。ソースが複数あるときは、Oracle BI Serverが適切なソースにナビゲートできるようにメタデータを構築します。これによって、Oracle BI Serverは、効率的な方法で、複数のソースにあるデータにシームレスにアクセスして処理でき、ユーザーのリクエストに対応可能となります。
この例では、販売の割当て額がExcelワークブックに格納されています。このワークブックQuota.xlsは、ユーザー自身のコンピュータにあります。この割当て額をビジネス・モデルに組み込み、割当て額からの差異と割当て達成率をレポートするビジネス尺度を作成します。
この項は次のトピックで構成されています。
ODBC DSNを作成する手順は次のとおりです。
「スタート」→「すべてのプログラム」→「管理ツール」→「データ ソース (ODBC)」をクリックして、ODBC データ ソース アドミニストレータを起動します。「システム DSN」タブをクリックし、「追加」をクリックします。
「データ ソースの新規作成」ダイアログ・ボックスが開きます。「データ ソースの新規作成」ダイアログ・ボックスで「Microsoft Excel Driver」を選択します。
「完了」をクリックして、「ODBC Microsoft Excel セットアップ」ダイアログ・ボックスを開きます。「ODBC Microsoft Excel セットアップ」ダイアログ・ボックスで、「データ ソース名」として「GEC_DW_TUTORIALQuota」と入力します。
「ブックの選択」をクリックして「ブックの選択」ダイアログ・ボックスを開き、Oracle BI Standard Edition Oneがインストールされている場所にナビゲートします。次に、tutorial\bi_adディレクトリに移動し、Quota.xlsファイルを選択して「OK」をクリックします。
「ODBC Microsoft Excel セットアップ」ダイアログ・ボックスに、ワークブックへのパスが表示されます。「OK」をクリックして、「ODBC Microsoft Excel セットアップ」ダイアログ・ボックスを閉じます。
ODBC データ ソース アドミニストレータにExcelシステム・データソースが追加されていることを確認し、「OK」をクリックしてODBC データ ソース アドミニストレータを終了します。
Excelデータソースをインポートする手順は次のとおりです。
BI Administration Toolで、「File」→「Import」→「from Database」を選択します。「Select Data Source」ダイアログ・ボックスで、前の手順で作成したODBC DSNを選択します。「User Name」および「Password」は空白のままにします。
「OK」をクリックします。「Import」ダイアログ・ボックスが開きます。「Import」ダイアログ・ボックスで、「GEC_DW_TUTORIALQuota」オブジェクトを選択します。「Tables」と「Keys」のみが選択されていることを確認し、「Import」をクリックします。
|
注意: Excelワークシート内の名前付きの各範囲が表として扱われます。 |
インポートが完了したら、「Close」をクリックして「Import」ダイアログ・ボックスを閉じ、4つの範囲がすべて「Physical」レイヤーにインポートされていることを確認します。
Country表は使用されません。
変更をチェックインして、リポジトリを保存します。
物理キーを作成する手順は次のとおりです。
「Physical」レイヤーで、「Quotas」物理表をダブルクリックします。
「Keys」タブをクリックし、「New」をクリックします。
キーの「Name」として、「Quotas_Key」と入力します。
「Prod Category」、「Year」および「Calendar Quarter Desc」を選択します。「OK」をクリックして、「Physical Key」ダイアログ・ボックスを閉じます。
「OK」をクリックして、「Physical Table」ダイアログ・ボックスを閉じます。
物理結合を作成する手順は次のとおりです。
[Ctrl]を押しながらクリックして、「Physical」レイヤーの表「ProdCategory」、「XLDates」および「Quotas」を選択します。3つの表のいずれかを右クリックして「Physical Diagram」→「Selected Object(s) Only」を選択し、「Physical Diagram」を開きます。
「Physical Diagram」で、「New foreign key」ボタンをクリックして結合を作成します。
「XLDates」をクリックし、その結合をクリックして「Quotas」にドラッグします。「Expression」フィールドに次の式を入力して、「OK」をクリックします。
XLDates.CALENDAR_YEAR = Quotas."Year" AND XLDates.CALENDAR_QUARTER_DESC = Quotas."Calendar Quarter Desc"
新しいキーを作成するかどうかの確認を求められたら、「Yes」をクリックします。
「ProdCategory」をクリックし、その結合をクリックして「Quotas」にドラッグします。「Expression」フィールドに次の式を入力して、「OK」をクリックします。
ProdCategory.PROD_CATEGORY = Quotas."Prod Category"
新しいキーを作成するかどうかの確認を求められたら、「Yes」をクリックします。
「Physical Diagram」は、図4-102のように表示されます。
「Physical Diagram」を閉じます。
変更をチェックインして、リポジトリを保存します。
ディメンション・キーを設定する手順は次のとおりです。
「Business Model and Mapping」レイヤーで、「TimesDim」ディメンションを開きます。
「Quarter」レベルをダブルクリックします。
「Logical Level」ダイアログ・ボックスで、「New」をクリックします。
「Calendar_quarter_description」を選択します。「OK」をクリックして、「Logical Level Key」ダイアログ・ボックスを閉じます。
「Logical Level」ダイアログ・ボックスで、Calendar_quarter_descriptionに対して「Chronological key」オプションを選択します。
「Quarter」を選択して「Delete」をクリックし、「Yes」をクリックして削除を確認します。
「OK」をクリックして、「Logical Level」ダイアログ・ボックスを閉じます。
論理ディメンション列をマッピングする手順は次のとおりです。
物理列の「CALENDAR_YEAR」を、「Physical」レイヤーの「XLDates」から「Business Model and Mapping」レイヤーの論理列「Times.Year」にドラッグします。新しい論理表ソースのXLDatesが自動的に作成されていることに注意してください。残りの物理列を、「Physical」レイヤーの「XLDates」から「Business Model and Mapping」レイヤーの「Times」表の対応する論理列にドラッグします。
「Times」→「Sources」フォルダの「XLDates」論理表ソースをダブルクリックして「Logical Table Source」ダイアログ・ボックスを開き、「Column Mapping」タブをクリックしてマッピングを確認します。「Show unmapped columns」の選択を解除します。
「OK」をクリックして、「Logical Table Source」ダイアログ・ボックスを閉じます。
手順を繰り返し、Products.Product_CategoryをProdCategory.PROD_CATEGORYにマッピングし、論理表ソースのマッピングを確認します。
Quota尺度を作成する手順は次のとおりです。
「Quotas.Quota」列を「Physical」レイヤーから「Sales」論理表にドラッグします。新しい論理表ソースのQuotasと新しい論理列のQuotaが作成されていることに注意してください。
「Sales.Quota」をダブルクリックして、「Logical Table」ダイアログ・ボックスを開きます。「Aggregation」タブをクリックして、集計ルールを「Sum」に設定します。「Logical Table」ダイアログ・ボックスを閉じます。
Quota論理列では割当て額が1000単位で表示されるため、名前を「Quota」から「Quota(000)」に変更します。
Quota(000)に基づいて実際の割当て額に対応する尺度を作成します。これを行うには、「Sales」を右クリックして、「New Object」→「Logical Column」を選択し「Logical Column」ダイアログ・ボックスを開きます。「General」タブをクリックし、「Use existing logical columns as the sourceを選択します。「Name」フィールドに「Quota」と入力します。
省略記号（...）をクリックして、式ビルダーを起動します。
次の計算式を指定します。
1000*"GEC_DW_TUTORIALWH"."Sales"."Quota(000)"
「OK」をクリックして、式ビルダーを終了します。
「OK」をクリックして、「Logical Column」ダイアログ・ボックスを閉じます。ビジネス・モデルにQuota列が追加されます。
Amount_SoldおよびQuotaに基づいて、さらに2つの尺度を作成します。「Sales.Amount_Sold」を右クリックし、「Calculation Wizard」を選択します。「Next」をクリックします。「Quota」列を選択します。
「Next」をクリックします。「Change」が選択されていることを確認してください。「Calculation Name」フィールドで、計算名を「Variance from Quota」に設定します。
「Percent Change」の選択を解除します。「Percent」を選択し、選択されたことを確認してください。「Calculation Name」フィールドの計算名は「% of Quota」のままにします。
「Next」をクリックします。「Finish」ウィンドウで、Calculation Wizardによって作成される計算を確認します。
「Finish」をクリックします。ビジネス・モデルに計算尺度が追加されます。
「Quota (000)」、「Quota」、「Variance from Quota」、「% of Quota」の各尺度を、「Presentation」レイヤーの「Sales」フォルダに追加します。
変更をチェックインします。全体の整合性をチェックします。エラー・メッセージが表示された場合は、手順を続行する前に、リポジトリを編集してエラーを修正します。リポジトリを保存します。
Quota尺度をテストする手順は次のとおりです。
Oracle BI Answersに戻ります。いったんログアウトし、パスワードにAdministratorを指定し、Administratorとしてログインしなおします。「サーバーメタデータの再ロード」をクリックします。
次のリクエストを作成します。
Times.Year, Sales.Amount_Sold, Sales.Quota, Sales.Variance from Quota, Sales.% of Quota
Quotaは2006年度に対してのみ割り当てられているため、図4-113に示すように、Year列が2006と等しくなるようにフィルタを作成します。
「結果」をクリックします。
「2006」をクリックして、その年の四半期にドリルダウンします。Answersの結果は、図4-115のようになります。
クエリー・ログを調べ、スプレッドシートのQuotasおよびXLDatesがアクセスされていることを確認します。クエリー・ログの表示方法の詳細は、第4.5.4項「クエリー・ログによるクエリーの検証」を参照してください。
