| Oracle® Business Intelligence Applications管理者ガイド 11gリリース1 (11.1.1.8.1) E56354-01 |
|
 前 |
 次 |
この章では、Oracle Business Intelligence ApplicationsにおけるETL機能のカスタマイズの概念と手法について説明します。また、Oracle BI Applicationsメタデータ・リポジトリをトリミングするために使用されるプロセスについても説明します。
この章の内容は次のとおりです。
この項では、Oracle Business Intelligence Applicationsのカスタマイズの概要について説明します。この項の内容は次のとおりです。
Oracle Business Intelligence Applicationsでは、カスタマイズは、新しい情報をビジネス・インテリジェンス・ダッシュボードで分析できるようにするための事前構成された動作の変更として定義されます。たとえば、データをフィールドHZ_CUST_ACCOUNTS.ATTRIBUTE1から抽出し、Oracle Business Analytics WarehouseのX_ACCOUNT_LOGフィールドに格納することによって、列をダッシュボードに追加する必要がある場合があります。
使用しているデータ・ソースのタイプによって、実行できるカスタマイズのタイプが決まります。データ・ソースは、次のいずれかのタイプになります。
パッケージされたアプリケーション(たとえば、Oracle FusionまたはEBS)。事前パッケージ済アダプタを使用します。
パッケージされていないデータ・ソース。汎用アダプタを使用します。
カスタマイズは、次のカテゴリに分類されます。
カテゴリ1。カテゴリ1のカスタマイズでは、事前にパッケージされているアダプタを持つソース・システムから列を追加し、データを既存のOracle Business Analytics Warehouse表にロードします。カテゴリ1のカスタマイズの実行の詳細は、第1.2項「カテゴリ1のカスタマイズ: 既存のファクト表またはディメンション表への列の追加」を参照してください。
カテゴリ2。カテゴリ2のカスタマイズでは、事前にパッケージされているアダプタを使用して、新しいファクト表またはディメンション表をOracle Business Analytics Warehouseに追加します。カテゴリ2のカスタマイズでは、通常、新しいSDEマッピングおよびSILマッピングを構築する必要があります。カテゴリ2のカスタマイズの実行の詳細は、第1.3項「カテゴリ2のカスタマイズ: 表の追加」を参照してください。
カテゴリ3。カテゴリ3のカスタマイズでは、汎用アダプタを使用して、事前にパッケージされているアダプタがないソースからデータをロードします。カテゴリ3のカスタマイズの実行の詳細は、第1.4項「カテゴリ3のカスタマイズ: 標準的なディメンション表に新しいデータを行全体として追加」を参照してください。
次の図に、データ・ソースのタイプおよび変更のタイプごとに実行できるカスタマイズのカテゴリがまとめられています。
表および命名規則の詳細は、『Oracle Business Analytics Warehouseデータ・モデル・リファレンス』を参照してください。
ETLのパッケージおよびインタフェースをカスタマイズするときは、通常、ODI Studioのデザイナ・ナビゲータの「プロジェクト」ビューにある\Oracle BI Applications\Mappingsフォルダで作業します。
注意: このカスタマイズ方法では、ETLタスクをコピーして、オリジナルとコピーの両バージョンを作成します。このとき、データストアはバージョニングのみが行われます。これらのバージョンを使用することで、必要に応じて機能を元に戻したり、カスタマイズ、パッチまたはアップグレードを通して取り込まれた変更内容を特定できます。
この章では、ビジネス分析とテクニカル分析を実行した後に、ETL機能をカスタマイズする方法について説明します。この章では、次に示す実行する必要があるタスク以外の通常のタスクについては説明しません。
ビジネス分析: カスタマイズを開始する前に、通常、現在のBIダッシュボードを分析し、ビジネスまたは組織をサポートするために必要な変更を判別します。
テクニカル分析: ビジネス要件を特定したら、変更する必要があるソース表、ステージング表、ターゲット表およびODIのパッケージとインタフェースを特定して、実行する必要があるテクニカル変更を判別する必要があります。
RPD変更: ETL機能のカスタマイズを実行したら、RPDを変更して、新しいデータをダッシュボードに公開する必要があります。RPDの変更の詳細は、Oracle Business Intelligence Enterprise Editionのドキュメント・ライブラリを参照してください。
この項では、パッチが適用済のオブジェクトにカスタマイズ内容を再適用する際に実行する必要がある作業について説明します。たとえば、Supply Chain and Order Managementアプリケーションを変更するOracle Business Intelligence Applicationsのパッチをインストールする場合、Supply Chain and Order Managementアプリケーションに対して行ったカスタマイズ内容を手動で再適用することが必要になる場合があります。
ETLタスクのカスタマイズの一環として(特定のタスク・フォルダの下にあるインタフェースとパッケージを含む)、カスタマイズ対象のタスク・フォルダをコピーして、オリジナル・バージョンとコピー・バージョンを作成します。オリジナル・タスクの現行バージョンにすべてのパッチが適用されます。ODIのバージョン比較ユーティリティを利用して、パッチによって取り込まれた変更を特定します。取り込まれた変更を分離できるようにするために、コピー・バージョンも作成されます。すべての変更内容をパッチで取り込まれた変更内容と比較し、競合がないことを確認してから、そのパッチで取り込まれた変更内容をカスタマイズ済のETLタスクに手動で適用します。ETLのカスタマイズ内容の変更とバージョニングの詳細は、第1.2.2項「Oracle Business Analytics Warehouseでのマッピング拡張の標準的な手順」を参照してください。
パッチによってインストールされるのは、作業リポジトリ全体ではなく、変更されたリポジトリ・オブジェクトのみです。したがって、パッチによって変更されたマッピングに対してのみカスタマイズ内容を再適用する必要があります。たとえば、パッチによってSupply Chain and Order Managementアプリケーションのみが変更される場合、Supply Chain and Order Managementアプリケーションに対して行ったカスタマイズ内容のみを手動で再適用する必要があります。他のアプリケーションのカスタマイズ内容は、パッチの影響を受けません。
注意
すべてのカスタマイズ手順で、カスタマイズ済のETLタスクを格納する「カスタム」アダプタ・フォルダを作成します。これは必須ではありませんが、カスタマイズされた内容を簡単に特定するためのベスト・プラクティスと考えられます。
カテゴリ1のカスタマイズでは、事前にパッケージされているアダプタを持つソース・システムから列を追加し、データを既存のOracle Business Analytics Warehouse表にロードします。
この項の内容は次のとおりです。
カテゴリ1のカスタマイズでは、事前にパッケージされたアダプタが含まれているソース・システム(Oracle eBusiness Suiteなど)から追加のカラムを抽出し、既存のOracle Business Analytics Warehouse表にデータをロードします。カテゴリ1のカスタマイズの場合、データはパッケージされていないソースからも入力されますが、この項では、このソースはすでに汎用アダプタでマッピングされ、追加の列を取り込むための拡張のみが必要であると想定しています。(汎用アダプタの初期マッピングは、カテゴリ3のカスタマイズで検討します。詳細は、第1.4項「カテゴリ3のカスタマイズ: 標準的なディメンション表に新しいデータを行全体として追加」を参照。)
Oracle Business Analytics Warehouseで追加の列を参照するには、まずその列がETLプロセスで渡されている必要があります。既存のマッピングと表は拡張可能です。Oracle Business Intelligence Applicationsでは、事前に構成済のマッピングを拡張し、これらの列を追加して、既存の表にデータをロードする方法論が提供されています。
Oracle Business Intelligence Applicationsには、拡張と変更という2種類のカスタマイズがあります。サポートされている拡張ロジックにより、既存オブジェクトに追加できます。たとえば、ソースから追加の列を抽出し、既存のマッピングを使用して追加の列を渡し、既存の表に新しい列を追加移入できます。一般的に、Oracle Business Intelligence Applicationsでは、既存のロジックまたは列を変更することはできません。別の列を使用するために既存の計算を変更することはできません。また、既存の列を別のソースからロードするように再マッピングすることもできません。
たとえば、既存のロジックと異なる方法で売上を計算する場合は、新しい列(X_REVENUEなど)を作成して、その列にカスタム・マッピング式を移入する必要があります。その後、Oracle Business Intelligenceリポジトリを再マッピングして、新しいX_REVENUE列を指すようにできます。
ほとんどのデータストアには、X_CUSTOMという名前のプレースホルダ列が1つあります。各ETLタスクには、この列にデータを移入するためのマッピング式があります。これらの式は、ODIのデータストアとインタフェースをカスタマイズする際のテンプレートとして機能します。新しいカスタム列の作成時には、カスタム列を識別できるようにX_接頭辞を含める命名規則に従います。
次の図では、事前に構成済のロジックがグレーで表示されています。これらのオブジェクトの内容には、どのような変更もできません。パッケージとインタフェースを新たに作成するのではなく、既存のオブジェクトにカスタマイズ部分を追加する必要があり、これにより既存のロジックとパラレルで追加部分を実行できます。
Oracle Business Analytics Warehouseを拡張する最も一般的な理由は、ソース・システムから既存の列を抽出して、Oracle Business Analytics Warehouseの既存の表(ファクトまたはディメンション)にマッピングするためです。このタイプの変更では通常、SILパッケージ内でのインタフェースの拡張が必要になります。パッケージ化されたソースからデータが取得される場合は、該当するSDEアダプタ・パッケージ内のインタフェースも拡張する必要があります。パッケージ化されていないソースからデータが取得される場合は、汎用アダプタ・パッケージを使用する必要があります。該当するパッケージが存在しない場合には、インタフェースとともに汎用アダプタ・パッケージを作成する必要があります。
Oracle Business Analytics WarehouseでODIパッケージを拡張するには:
SDEおよびSILアダプタの新しいフォルダを作成します(既存の「アダプタ」フォルダをコピーしないでください。サブフォルダがすべてコピーされてしまうからです)。フォルダの名前には、「Custom」または他のわかりやすい識別子を含めるようにし、また、既存の「アダプタ」フォルダのリリース・タグと一致するようにリリース・タグを設定します。SDEとSILの両方のフォルダに対してこれを実行します。
「マッピング」フォルダを右クリックして、「新規サブフォルダ」を選択します。
名前を「CUSTOM _<元のフォルダ名>」に設定します。たとえば、「CUSTOM_SDE_ORA11510_Adaptor」に設定します。CUSTOM_SILOSは、カスタムのSDEおよびSILフォルダを表します。
「デザイナ」タブで、「ナビゲータの接続」ボタンをクリックします。
「リリース・タグの編集」を選択します。
お使いのソースに対応するリリース・タグを選択します。たとえば、EBS_11_5_10を選択します。
作成したカスタムSDEフォルダを選択して、リリース・タグに追加します。
「次へ」をクリックします。
「終了」をクリックします。
CUSTOM_SILOSフォルダに対して前述の手順を繰り返し、BIA_11リリース・タグに関連付けます。
カスタマイズ対象となる事前構成済の「タスク」フォルダに対してバージョニングを有効にします。これがタスクのベース・バージョンであることをバージョン・コメントで示す必要があります。今後、このタスクに適用されるパッチでは、元のタスクと比較して変更内容を特定できるように、コメント内のバージョンを増やすことが必要になります。
「タスク」フォルダを右クリックして、「バージョン」→「バージョンの作成」を選択します。
デフォルトのバージョン番号である1.0.0.0を受け入れます。
これがこのタスクのオリジナル・バージョンであることを示す説明を追加します。
カスタマイズ対象となる「タスク」フォルダをコピーして複製します。コピーされた「タスク」フォルダを切り取って「カスタム」アダプタに貼り付け、名前を変更して、「…のコピー」という接頭辞を削除します。
手順2と同じ方法を使用して、コピーされた「タスク」フォルダのバージョニングを有効にします。これがオリジナル・バージョンであることをバージョン・コメントで示す必要があります。このバージョニングにより、カスタマイズされたタスクとオリジナル・バージョンのコピーの比較が可能になり、取り込まれたすべての変更を判別できます。
コピーされたタスクの別のバージョンを作成します。これがカスタマイズされたバージョンであることをバージョン・コメントで示す必要があります。前述の手順と同じ手順を使用します。
カスタマイズ対象のデータストアがたとえばOracle BI Applicationsに存在するように、モデルをバージョニングします。サブモデルとデータストアをバージョニングすることはできません。これがベース・バージョンまたはオリジナル・バージョンであることをバージョン・コメントで示す必要があります。
新しいバージョンのモデルを作成し、ここにカスタマイズ内容が取り込まれていることをバージョン・コメントで示します。これで、複数のモデルを比較して差異を示すことができます。モデルにパッチを適用する必要がある場合は、パッチ適用済のバージョンをカスタム・バージョンおよびオリジナル・バージョンと比較できるように、再度モデルをバージョニングする必要があります。
カスタマイズ内容をデータストアとタスクに適用します。カスタマイズ内容は、既存の内容を上書きするのではなく、できるかぎり追加するようにしてください。たとえば、特定の列を計算する方法が気に入らない場合、新しいカスタム列を追加して、好みの方法でマッピングします。RPDでは、論理列が、元の列ではなくこの新しいカスタム列を指すようにします。
シナリオを生成する前に、「シナリオ命名規則」ユーザー・パラメータが%FOLDER_NAME(2)%_%OBJECT_NAME%という値を持つようにします。
オリジナル・タスクに関連付けられたシナリオを削除し、オリジナルと同じシナリオ名を使用してカスタム・タスクの新しいシナリオを生成します。ODIでは一意のシナリオ名を強制しているので、カスタム・タスクに同じシナリオ名を使用する必要があります。これにより、ロード計画でオリジナルのETLタスクではなくこのETLタスクが実行されるようになります。
初期状態のシナリオを削除します。オリジナルの「タスク」フォルダ→「パッケージ」→<パッケージ名>→「シナリオ」→<シナリオ名>に移動します。シナリオ名をメモに取り、シナリオを右クリックして、「削除」を選択します。
カスタム・タスクのシナリオを生成します。カスタムの「タスク」フォルダ→「パッケージ」→<パッケージ名>に移動して、パッケージを右クリックし、「シナリオの生成」を選択します。メモを取ったオリジナルのシナリオ名を使用します。
「すべての下層オブジェクトがマテリアライズされるものとしてシナリオを生成」チェック・ボックスを選択します。
「OK」をクリックします。
「起動パラメータ」ドロップダウンから「すべてを使用」を選択します。
「OK」をクリックします。
これで、ロード計画を実行すると、オリジナル・タスクではなくカスタム・タスクが実行されるようになります。今後、インタフェースまたはパッケージのいずれかに変更を加えた場合、既存のシナリオを再生成するか、または新しいシナリオを生成できます。別のシナリオを必要とする場合を除き、既存のシナリオを再生成することをお薦めします。これを実行するには、シナリオを右クリックして、「再生成」を選択します。
ロード計画を再生成します。
ロード計画を実行します。
この項の内容は次のとおりです。
BI Applications ETLプロセスは、タイプIおよびタイプIIの緩やかに変化するディメンションの動作をサポートします。ディメンションには、タイプ1の動作についてのみ有効なものと、タイプIIの動作のサポートも有効なものがあります。タイプIIの動作をサポートするディメンションについては、様々なディメンション属性が、様々な緩やかに変化する動作を持っています(タイプIとして扱われるいくつかの属性を含む)。ディメンションに関連付けられたタイプIIの動作を有効または無効にするには:
注意: タイプIIのトラッキング・ロジックの変更が、出荷ロジックに加える必要がある唯一の変更です。
カテゴリ2のSCDトリガーを変更するには:
ODIデザイナで、ディメンション・データストアを変更します。
「モデル」ビューで、「Oracle BI Applications」フォルダ、「Oracle BI Applications (モデル)」および「ディメンション (サブモデル)」を展開します。
ディメンション表をダブルクリックします。
「定義」タブで、「OLAPタイプ」の値を「ディメンション」(タイプIの変更のみをサポート)または「緩やかに変化するディメンション」(タイプIIの変更をサポート)に変更します。
SILディメンション・タスクを変更します。
このディメンションにデータを移入するSILタスクに移動します。
「メイン」インタフェースをダブルクリックします。
「フロー」サブタブで、「ターゲット」(ORACLE_BI_APPLICATIONS)ウィンドウを選択します。
「プロパティ」ウィンドウが表示されない場合、メニュー・オプション・ビュー→「プロパティ・インスペクタ」をクリックして開きます。
「IKMセレクタ」の値を、「IKM BIAPPS Oracle緩やかに変化するディメンション」(タイプIIの動作を有効にする場合)または「IKM BIAPPS Oracle増分更新」(タイプIIの動作を削除する場合)に変更します。
シナリオを再生成します。
タイプIIの動作をサポートするように構成されているディメンションでタイプIまたはタイプIIとして扱われる列を変更する方法について次に説明します。タイプIの動作のみをサポートするようにディメンションが構成されている場合、すべての列がタイプIとして扱われるため、次の変更を行っても効果はありません。
ディメンションに関連付けられたタイプIIの動作を有効または無効にするには:
ODIデザイナで、ディメンション・データストアを変更します。「モデル」ビューで、「Oracle BI Applications」フォルダ、「Oracle BI Applications (モデル)」、「ディメンション (サブモデル)」および「列」を展開します。
SCD動作を変更する列をダブルクリックします。
「説明」サブタブの「緩やかに変化するディメンションの動作」ドロップダウン・リストで、列の動作を選択します。タイプIの動作を実装するには、「変更時に上書き」を選択します。タイプIIの動作を実装するには、「変更時の行の追加」を選択します。
カスタム・ディメンションに対してタイプIIの動作を有効にする場合は、次に示すように列を設定してください。
ROW_WID - サロゲート・キー
INTEGRATION_ID, DATASOURCE_NUM_ID - 自然キー
CURRENT_FLG - 現在のレコード・フラグ
EFFECTIVE_FROM_DT - 開始タイムスタンプ
EFFECTIVE_TO_DT - 終了タイムスタンプ
この項では、既存のファクトにディメンションを追加して、ディメンション・データストアとディメンション・ステージング・データストアおよび関連付けられたSDEプロセスとSILプロセスを追加する方法について説明します。この場合、新しいディメンションとの関連付けを反映するようにファクト表とファクト・ステージング表を拡張することも必要になります。この項の内容は次のとおりです。
カスタム・ディメンション・データストアとタスクを作成します。「Oracle BI Applications – ディメンション」モデルの下にWC_<ディメンション名>_Dデータストアを作成します。「Oracle BI Applications – ディメンション・ステージ」モデルの下にWC_<ディメンション名>_DSデータストアを作成します。WC_SAMPLE_DSおよびWC_SAMPLE_Dデータストアをテンプレートとして使用します。これらのデータストアには、必須のすべてのシステム列が含まれます。カスタム表は、出荷表と区別できるように、WC_命名規則に従う必要があります。
|
注意: 表が属する特定のサブモデルによって、表のメンテナンス動作が駆動されます。たとえば、ディメンション・ステージ・サブモデルの表は各ETLの実行時に常に切り捨てられますが、「ディメンション」サブモデルの表は完全なETLの実行時にのみ切り捨てられます。データストアを配置するための「カスタム」サブモデルを作成しないでください。これは、このようなサブモデルの表では、表のメンテナンスが適切に実装されないためです。 |
次に説明するように、ODIでディメンションを定義するには、データベースの表を作成するDDLを生成するか、またはデータベースの表を定義してBI Applications RKMによってその定義をODIにインポートします。RKMを使用する場合、インポートされた表は自動的に「その他」サブモデルに配置されるので、必要に応じてディメンション・ステージング・サブモデルおよび「ディメンション」サブモデルに移動する必要があります。また、ディメンションに対するOLAPタイプを必要に応じて、「ディメンション」または「緩やかに変化するディメンション」に設定することも必要になります。
ODIでのディメンション表の手動による作成
ODIでディメンションとタスクを手動で作成するには:
デザイナで、「モデル」→「Oracle BI Applications (フォルダ)」→「Oracle BI Applications (モデル)」→「ディメンション・ステージ (サブモデル)」に移動します。
WC_SAMPLE_DSデータストアを右クリックして、「選択の複製」を選択します。
新しいデータストアをダブルクリックして、その名前を変更します。「名前」と「リソース名」は、実際の表名に一致する必要があります。「別名」は、同じ値またはよりユーザー・フレンドリな値にすることができます。
「列」サブタブで、すべての列を追加します。
同じ手順を繰り返して、「ディメンション」サブモデルの下にWC_SAMPLE_Dデータストアをコピーすることによって、ディメンション表を作成します。
ディメンション表で、「OLAPタイプ」を「ディメンション」(タイプIのディメンションの場合)または「緩やかに変化するディメンション」(タイプIIのディメンションの場合)に設定します。
ODIへのカスタム・ディメンション表のインポート
ODIにカスタム・ディメンション表をインポートするには:
デザイナで、「モデル」→「Oracle BI Applications (フォルダ)」に移動して、「Oracle BI Applicationsモデル」をダブルクリックします。
「リバース・エンジニアリング」サブタブで、LIST_OF_TABLEオプションの下にインポート対象となる表を示します。複数の表をインポートする場合は、カンマ区切りリストで指定します。
「リバース・エンジニアリング」ボタンをクリックして、ODIに表をインポートするセッションを開始します。
「リバース・エンジニアリング」プロセスによって、「その他」サブモデルにすべての表が配置されます。W_%_DS表をディメンション・ステージ・サブモデルにドラッグ・アンド・ドロップし、W_%_D表を「ディメンション」サブモデルにドラッグ・アンド・ドロップします。
新しいディメンション・データストアをダブルクリックして、「OLAPタイプ」を「ディメンション」(タイプIのディメンションの場合)または「緩やかに変化するディメンション」(タイプIIのディメンションの場合)に設定します。
カスタム・ディメンションに対するODI順序の作成
カスタム・ディメンションのODI順序を作成します。ディメンションのROW_WID列にデータを移入するために、データベース順序が使用されます。データベースのデータベース・トリガーの作成に必要なDDLを生成するために、「DDLの生成」プロシージャが使用されます。テンプレートとしてWC_SAMPLE_D_SEQを使用します。
デザイナで、「プロジェクト」→「BI Appsプロジェクト」→「順序」に移動します。
「順序」フォルダを右クリックして、「新規順序」を選択します。
名前を「<ディメンション名>_SEQ」に設定します。
「ネイティブ順序」ラジオ・ボタンを選択します。
「スキーマ」をDW_BIAPPS11Gに設定します。
一般的に、名前の長さが30文字を超えないかぎり、ネイティブ順序名はODI名に一致する必要があります。30文字を超える場合は、この制限に合わせるために名前を短縮できます。これは、ROW_WID列にデータを移入するために作成されたデータベース・トリガーの名前です。
データベースの表を作成するDDLを生成します。注意: ODIのディメンションを手動で作成した場合、表と順序を両方作成するDDLを生成します。ディメンションをODIにインポートした場合、順序のみを作成するDDLを生成します。
SDEタスクとSILタスクの作成
カスタムのSDEおよびSILアダプタ・フォルダにSDEタスクとSILタスクを作成します。SDE_<製品ライン・コード>_SampleDimensionタスクおよびSIL_SampleDimensionタスクをテンプレートとして使用します。これらのタスクには、システム列にデータを移入するために必要なロジックが含まれます。最後に、これらのタスクのシナリオを生成します。
ロード計画ステップの追加
「3 SDE Dims X_CUSTOM_DIM <製品ライン・バージョン・コード>」ロード計画コンポーネントにロード計画ステップを追加します。
デザイナで、「ロード計画とシナリオ」→「BIAPPSロード計画」→「ロード計画開発コンポーネント」→ SDE - <製品ライン・バージョン・コード>に移動して、「3 SDE Dims X_CUSTOM_DIM <製品ライン・バージョン・コード>」ロード計画コンポーネントをダブルクリックします。
「ステップ」サブタブで、「X_CUSTOM_DIM」ステップを選択します。
右上の緑の「+」記号をクリックして、「シナリオ実行ステップ」を選択します。
「シナリオ名」を指定して、「バージョン」を「-1」に設定し、タスク名に一致するように「ステップ名」を設定します。「再開タイプ」を「失敗したステップから再開」に設定します。
ファクトに関連するデータストアとタスクは、新しいディメンションを反映するように拡張する必要があります。W_<ファクト名>_FSとW_<ファクト名>_Fの両方のデータストアを拡張する必要があります。
ファクトのデータストアとタスクをカスタマイズするには:
命名規則X_<名前>_IDに従うID列とデータ型VARCHAR2(80)を追加することにより、ファクト・ステージング・データストアを拡張します。
Oracle BI Applications Modelをあらかじめバージョニングしておく必要があります。
「モデル」→「Oracle BI Applications (フォルダ)」→「Oracle BI Applications (モデル)」→「ファクト・ステージ (サブモデル)」に移動して、「ファクト・ステージング表」をダブルクリックします。
「列」サブタブで、「X_CUSTOM」列を選択します。
緑の「+」記号をクリックして、「X_CUSTOM」列の下に列を追加します。
命名規則X_<名前>_WIDに従うWID列とデータ型NUMBER(10)を追加することにより、「ファクト」データストアを拡張します。前述と同じステップに従って、ファクト・データストアに列を追加します。
前に作成したカスタム・ディメンション表を参照する外部キー制約をファクト表に追加します。この外部キー制約により、生成されたロード計画にカスタムSILタスクが確実に含まれるようになります。生成されたロード計画にカスタムSDEタスクが含まれるのは、カスタムSILタスクのソースとして使用されるステージング表にデータを移入するためです。
「ファクト」データストアにドリル・ダウンします。
「ファクト」データストアの下の「制約」サブフォルダを右クリックして、「新規の参照」を選択します。
命名規則は、FK_<ファクト表>_<ディメンション表>です。同じディメンション表を参照する必要があるWID列が複数ある場合、それぞれに数字の接尾辞を付けて列挙します(たとえば、FK_WC_CUSTOM_F_WC_CUSTOM_D1)。「タイプ」は、「ユーザー参照」です。
「表」ドロップダウン・リストから「カスタム・ディメンション」を選択します。
「列」サブタブで、緑の「+」記号をクリックして、新しい列を追加します。
「外部表」列の場合は、ファクト表でカスタムWID列を選択します。「プライマリ表」列の場合は、ディメンション表でROW_WID列を選択します。
X_<名前>_WID列で一意でないビットマップ索引を追加します。
「ファクト」データストアにドリル・ダウンします。
「ファクト」データストアの下の「制約」サブフォルダを右クリックして、「新規キー」を選択します。
命名規則は、<ファクト表>_F<n>です。これらの索引のそれぞれに数字の接尾辞を付けて列挙します(たとえば、WC_CUSTOM_F1)。
「非一意索引」ラジオ・ボタンを選択します。
「列」サブタブで、シャトル・ボタンを使用してWID列を追加します。
「制御」サブタブで、「データベースで定義済」および「アクティブ」チェック・ボックスを選択します。
「フレックスフィールド」サブタブで、索引タイプの値をQUERYに設定し、ビットマップ索引の値をYに設定します。
ファクトSDEタスクを変更します。ソース表の値をステージング表のカスタムX_<名前>_ID列に渡します。マッピング式に、必要な変換関数を組み込んで、データをVARCHAR2(80)形式に変換します。
ファクトSILタスクを変更します。カスタム・ディメンションからROW_WID値を取得するロジックを追加します。これは通常、次の方法のいずれかで実行されます。これらの2つの方法の間に大きな差はありません。
SQ一時インタフェースでソースとしてディメンションを追加します。ファクト表のID列、ディメンション表のINTEGRATION_ID列、およびファクトとディメンションのDATASOURCE_NUM_ID列に関して結合を行います。ディメンションがタイプIIのディメンションの場合、ディメンションの有効日間におけるファクトの正規日に関する範囲結合を含めます。「左の外部結合」として結合を構成します。出力としてROW_WID列を渡します。
メイン・インタフェースでルックアップとしてディメンションを追加します。ルックアップ結合は、ファクト表のID列、ディメンション表のINTEGRATION_ID列、およびファクトとディメンションのDATASOURCE_NUM_ID列に関して行われます。ディメンションがタイプIIのディメンションの場合、ディメンションの有効日間におけるファクトの正規日に関する範囲結合を含めます。「ルックアップ・タイプ」を「FROM句内のSQL左外部結合」として構成します。
メイン・インタフェースでカスタムのWID列にデータを移入するマッピング式において、NULL値を0にデフォルト設定する関数にディメンション表のROW_WID列を埋め込みます。たとえば、COALESCE(SQ_W_AP_HOLDS_FS.PURCHASE_ORG_WID,0)となります。
このユースケースはファクトに標準のディメンションを追加する方法に似ていますが、このケースでは、日付ディメンションが使用されます。日付関連のディメンションは複数あり、それぞれ異なる方法(会計、企業など)および異なる間隔(日、週、月など)で日付を表します。
ファクトと日付ディメンション表間の結合は、日付固有のWID列上で行われます。この日付WID列は、YYYYMMDD形式で日付を表すスマート・キー値です。日付ディメンションのROW_WID列を解決するためにルックアップを実行する必要はありません。かわりに、ETLプロセスを通して日付列を渡して、この形式に変換します。
ファクト表ごとに1つずつ「正規の」日付固有のWID列があります。これは、様々な日付関連の計算を駆動するために使用されるプライマリ日付です。この列を識別する特定のメタデータはありませんが、ETLの有効日指定表のルックアップではこの列が使用され、RPDの様々な日付関連の式でもこの列が使用されます。パッケージ化されたファクト表はすべて、すでに識別された正規の日付を1つ持っています。カスタムのファクト表の作成時には、1つの日付WID列を正規日付として指定し、一貫して使用する必要があります。
ファクトにディメンションを追加する場合と同じステップに従います。ただし、次の変更点があります。既存の日付ディメンションを使用するので、カスタムのSDEを作成する必要はありません。
ファクトのデータストアとタスクのカスタマイズ
ファクトに関連するデータストアとタスクは、新しいディメンションを反映するように拡張する必要があります。W_<ファクト名>_FSとW_<ファクト名>_Fの両方のデータストアを拡張する必要があります。
命名規則X_<名前>_DTに従うDT列を追加することにより、ファクト・ステージング・データストアを拡張します。この列には形式DATE(7)を設定する必要があります。
カスタムのDT列とDT_WID列を両方追加することによって、「ファクト」データストアを拡張します。これらは、命名規則X_<名前>_DTおよびX_<名前>_DT_WIDに従います。
日付ディメンションに外部キー制約を追加します。同じ日付ディメンション表を参照する必要があるWID列が複数ある場合、それぞれに数字の接尾辞を付けて列挙します。
ファクトSDEタスクを変更します。ソース表の値をステージング表のカスタムX_<name>_DT列に渡します。必要な変換を適用して、データをDATE形式に変えます。
ファクトSILタスクを変更します。ステージング表のX_<名前>_DT値を、ファクト表の対応する列に渡します。メイン・インタフェースでカスタムのX_<名前>_DT_WID列にデータを移入するマッピング式において、DT_WID値を計算し、指定されたDTがNULLのときに0にデフォルト設定する関数にDT列を埋め込みます。たとえば、CALCULATE_DT_WID_DFLT(SQ_W_AP_HOLDS_FS.HOLD_DATE,0)となります。
カテゴリ2のカスタマイズでは、事前にパッケージされているアダプタを使用して、新しいファクト表またはディメンション表をOracle Business Analytics Warehouseに追加します。
この項の内容は次のとおりです。
この項では、ソース表から、抽出済ではないデータがロードされる、完全に新しい表の作成について説明します。たとえば、新しい「プロジェクト」ディメンション表の作成が必要になる場合があります。この場合は、新しいディメンション表とステージング表および新しい抽出を作成して、ETLマッピングをロードします。
新しいカスタム表を作成する場合、接頭辞WC_を使用して、Oracleが提供する表とカスタム表を区別し、Oracleが今後同様の名前の表をリリースした場合のネーミングの競合を回避します。たとえば、「プロジェクト」ディメンションに対して、WC_PROJECT_DS表およびWC_PROJECT_D表を作成できます。
新しいディメンション表またはファクト表を作成するときには、それぞれのOracle Business Analytics Warehouse表に含まれる必須のシステム列を使用して、整合性を維持し、既存の表構造を参照できるようにします。新しい表を作成するときには、最初に表と索引をODIデザイナModels領域で定義する必要があります。Oracle Business Analytics Warehouseの宛先モデルは、「Oracle BI Applications」です。
カスタム・ステージング表に必要な列は次のとおりです。
INTEGRATION_ID。 レコードの主キーまたは一意の識別子をソース表のように格納します。
DATASOURCE_NUM_ID。 データの抽出元のデータ・ソースを格納します。
ディメンション表およびファクト表には、INTEGRATION_ID列とDATASOURCE_NUM_ID列の他に、次の列も必要です。
ROW_WID。 ETLプロセスで生成される順序番号。Oracle Business Analytics Warehouseの一意の識別子として使用されます。
ETL_PROC_WID。 ETLプロセス情報のIDを格納します。
Oracle Business Analytics Warehouseのスキーマの表には、一意のユーザー・キーの一部としてDATASOURCE_NUM_IDが含まれています。通常、トランザクション・アプリケーションでは主キーが一意に維持されますが、複数のトランザクション・システム間で主キーが重複することは可能です。このデータをデータ・ウェアハウスにロードするときに問題が発生しないようにするために、ユーザー・キーの一部としてDATASOURCE_NUM_IDを含めると、一意性を維持できます。つまり、各データソースでこの列に異なる値が与えられている場合、それらの異なるソースの行を同じデータ・ウェアハウス表にロードできます。
この項では、Oracle Business Intelligence Applicationsのカスタマイズに関するその他の追加情報について説明します。
新しいファクト表およびディメンション表をロードするときには、ソース側でカスタム・プロセスを設計して、新規または変更されたレコードが検出されるようにします。SDEプロセスは、変更されたデータ(新規または変更済)のみをロードするように設計する必要があります。データが増分プロセスなしにロードされた場合、それ以前にロードされたデータが再度更新され、余分なコストのかかるプロセスになります。たとえば、事前に構成済のSILマッピング内のロジックは、INTEGRATION_IDおよびDATASOURCE_NUM_IDに基づいてロード先の表をルックアップし、これらの組合せが存在する場合にはROW_WIDを返します。その場合、レコードが更新されます。ルックアップでNULLが返された場合は、レコードが挿入されます。場合によっては、指定した列とともに、ターゲット表に格納されている最終更新日も比較され、挿入または更新が決定されます。詳細は、事前に構成済のフォルダ内の同様のマッピングを参照してください。
ステージング表には通常、索引は不要です。ステージング表に索引が必要かどうかは、慎重に判断してください。ETLでディメンションとファクトに使用されるすべての列に索引を作成します(たとえば、ディメンションとファクトのROW_WID、INTEGRATION_IDとDATASOURCE_NUM_ID、およびフラグ)。どの列または列の組合せのフィルタ条件が必要かを慎重に検討し、問合せのパフォーマンス向上につながる索引を定義します。参考用に事前に構成済のオブジェクトを検査します。新しく作成したすべての表に、WC_という名前を付けます。これにより、新しい表と事前構成済の表を見た目で区別できます。行ったカスタマイズの内容をきちんとドキュメントに残してください。データ・ウェアハウスをアップグレードするときに役立ちます。索引が決定したら、ODI Modelで登録します(詳細は、第1.5.2項「既存のファクト表またはディメンション表に索引を追加する方法」を参照)。
カスタム表は、事前構成済の表と区別できるように、WC_命名規則に従う必要があります。次の手順に従って、Oracle Business Analytics Warehouseに新しいファクト表を追加します。
新しいファクト表を追加するには:
カスタム・ファクト・データストアとタスクを作成します。「Oracle BI Applications – ファクト」モデルの下にWC_<ファクト名>_Fデータストアを作成します。「Oracle BI Applications – ファクト・ステージ」モデルの下にWC_<ファクト名>_FSデータストアを作成します。WC_SAMPLE_FSおよびWC_SAMPLE_Fデータストアをテンプレートとして使用します。これらのデータストアには、必須のすべてのシステム列が含まれます。
表が属する特定のサブモデルによって、表のメンテナンス動作が駆動されることに注意してください。たとえば、ファクト・ステージ・サブモデルの表は各ETLの実行時に常に切り捨てられますが、「ファクト」サブモデルの表は完全なETLの実行時にのみ切り捨てられます。
ODIでファクトを定義するには、データベースの表を作成するDDLを生成するか、またはデータベースの表を定義してBI Apps RKMによってその定義をODIにインポートします。RKMを使用する場合、インポートされた表は自動的に「その他」サブモデルに配置されるので、必要に応じて、ファクト・ステージング・サブモデルおよび「ファクト」サブモデルに移動する必要があります。また、ファクト表に対するOLAPタイプを「ファクト表」に設定することも必要になります。
ファクト表を手動で作成するには:
デザイナで、「モデル」→「Oracle BI Applications (フォルダ)」→「Oracle BI Applications (モデル)」→「ファクト・ステージ (サブモデル)」に移動し、WC_SAMPLE_FSデータストアを右クリックして、「選択の複製」を選択します。
新しいデータストアをダブルクリックして、その名前を変更します。「名前」と「リソース名」は、実際の表名に一致する必要があります。「別名」は、同じ値またはよりユーザー・フレンドリな値にすることができます。
「列」サブタブで、すべての列を追加します。
同じ手順を繰り返して、「ファクト」サブモデルの下にWC_SAMPLE_Fデータストアをコピーすることによって、ファクト表を作成します。
ファクト表に対して、OLAPタイプを「ファクト表」に設定します。
データベースの表を作成するDDLを生成します。
ODIにファクト表をインポートするには:
デザイナで、「モデル」→「Oracle BI Applications (フォルダ)」に移動して、「Oracle BI Applicationsモデル」をダブルクリックします。
「リバース・エンジニアリング」サブタブで、「LIST_OF_TABLE」オプションの下にインポート対象となる表を示します。複数の表をインポートする場合は、カンマ区切りリストで指定します。
「リバース・エンジニアリング」をクリックします。ODIに表をインポートするセッションが開始されます。
「リバース・エンジニアリング」プロセスによって、「その他」サブモデルにすべての表が配置されます。W_%_FS表をファクト・ステージ・サブモデルにドラッグ・アンド・ドロップし、W_%_F表を「ファクト」サブモデルにドラッグ・アンド・ドロップします。
新しいファクト・データストアをダブルクリックして、OLAPタイプを「ファクト表」に設定します。
データベースの表を作成するDDLを生成します。
このファクトに関連付けられているすべてディメンション表に外部キー制約を追加します。この外部キー制約により、生成されたロード計画にディメンションSILタスクが確実に含まれるようになります。生成されたロード計画にディメンションSDEタスクが含まれるのは、ディメンションSILタスクのソースとして使用されるステージング表にデータを移入するためです。
「ファクト」データストアにドリル・ダウンします。
「ファクト」データストアの下の「制約」サブフォルダを右クリックして、「新規の参照」を選択します。命名規則は、FK_<ファクト表>_<ディメンション表>です。同じディメンション表を参照する必要があるWID列が複数ある場合、それぞれに数字の接尾辞を付けて列挙します。たとえば、FK_WC_CUSTOM_F_WC_CUSTOM_D1となります。
「タイプ」を「ユーザー参照」に設定し、「表」ドロップダウン・リストからディメンションを選択して、「列」サブタブで、右上の緑の「+」記号をクリックして新しい列を追加します。
「外部表」列の場合は、ファクト表でカスタムWID列を選択します。「プライマリ表」列の場合は、ディメンション表でROW_WID列を選択します。
カスタムのSDEおよびSILアダプタ・フォルダにSDEタスクとSILタスクを作成します。SDE_<製品ライン・コード>_SampleFactタスクおよびSIL_SampleFactタスクをテンプレートとして使用します。これらのタスクには、システム列にデータを移入するために必要なロジックが含まれます。
「3 SDE Facts X_CUSTOM_FG <製品ライン・バージョン・コード>」ロード計画コンポーネントにロード計画ステップを追加します。
デザイナで、「ロード計画とシナリオ」→「BIAPPSロード計画」→「ロード計画開発コンポーネント」に移動します。
SDE - <製品ライン・バージョン・コード>に移動して、「3 SDE Facts X_CUSTOM_FG <製品ライン・バージョン・コード>」ロード計画コンポーネントをダブルクリックします。
「X_CUSTOM_FG」ステップを選択します。
右上の緑の「+」記号をクリックして、「シナリオ実行ステップ」オプションを選択します。
「シナリオ名」を指定して、「バージョン」を「-1」に設定し、「ステップ名」をタスク名に一致させます。「再開タイプ」を「失敗したステップから再開」に設定します。
「3 SIL Facts X_CUSTOM_FG」ロード計画コンポーネントにロード計画ステップを追加します。
デザイナで、「ロード計画とシナリオ」→「BIAPPSロード計画」→「ロード計画開発コンポーネント」に移動します。
SILに移動して、「3 SIL Facts X_CUSTOM_FG」ロード計画コンポーネントをダブルクリックします。
「X_CUSTOM_FG」ステップを選択します。
右上の緑の「+」記号をクリックして、「シナリオ実行ステップ」オプションを選択します。
「シナリオ名」を指定して、「バージョン」を「-1」に設定し、「ステップ名」をタスク名に一致させます。「再開タイプ」を「失敗したステップから再開」に設定します。
カテゴリ3のカスタマイズでは、汎用アダプタを使用して、事前にパッケージされているアダプタがないソースからデータをロードします。
この項の内容は次のとおりです。
次の手順に従って、Oracle Business Analytics Warehouseの標準的なディメンション表に、新しいデータを行全体として追加します。
標準的なディメンション表に、新しいデータを行全体として追加するには:
ステージング表の既存の構造を特定して理解します。表構造については、『Oracle Business Analytics Warehouseデータ・モデル・リファレンス』を参照してください。システム以外の列ではNULL値を使用できます。
カスタムSDEインタフェースを作成して、この目的のために作成されたカスタム・フォルダのステージング表にデータをロードします。パフォーマンス上の理由により、ステージング表には、増分データ(ETLプロセスの最終更新プロセス以後に追加または変更された行)を移入する必要があります。
INTEGRATION_ID列に、レコードの一意の識別子を移入します。
INTEGRATION_IDとDATASOURCE_NUM_IDの組合せは一意です。INTEGRATION_ID列に、レコードの一意の識別子を移入します。INTEGRATION_IDとDATASOURCE_NUM_IDの組合せは一意です。
ステージング表にデータが移入されたら、標準的なSILインタフェースを使用してディメンション・ターゲット表に移入します。
各アプリケーションには、特定のデータを特定のソースから抽出する事前にパッケージされたロジックがあります。この項では、Oracle Business Analytics Warehouseにロードする必要があるレコードのタイプおよびその必要がないレコードのタイプを処理することによって、レポートおよび非定型問合せに関するすべてのデータを取得する方法について説明します。項目は次のとおりです。
Oracle Business Analytics Warehouseでは、抽出マッピングおよび抽出インタフェースを構成して、追加のソース・データに対応できます。たとえば、会社が地域に基づいて顧客情報を別々の表に分けている場合は、これらの表からデータを含めるように抽出インタフェースを設定する必要があります。
抽出インタフェースは通常、ソース表、ターゲット列で使用される式およびステージング表で構成されています。既存のインタフェースを使用して新しいデータを抽出する場合には、次のタスクを実行して、新しいデータを含めるように抽出インタフェースを変更する必要があります。
既存のインタフェースを変更して新しいデータを含めるには:
既存のインタフェースを変更して、ソースから情報を抽出し、対応する拡張列に追加します。
必要な変換を実行するようにターゲット表の式を変更します。
変更内容を保存します。
シナリオを再生成します。
ステージング表内で、どのタイプの拡張列にデータをマッピングするかを決定する必要があります。抽出インタフェースを変更したら、対応するロード・インタフェース(SDEおよびSIL)も変更して、追加した拡張列がステージング表からターゲット・データ・ウェアハウス表までずっと接続されるようにする必要があります。
カンマ区切り(CSV)形式のソース・ファイルからデータをロードするときに、データにカンマ文字(,)が含まれている場合は、ソース・データに存在しないデリミタと呼ばれる適切な囲み文字を使用してソース・データを囲む必要があります。
注意: 別の方法として、自動的に適切な囲み文字でデータを囲むように、データ抽出プログラムを構成することもできます。
たとえば、CSVソース・データ・ファイルに次のデータが含まれているとします。
Months, Status January, February, March, Active April, May, June, Active
このデータを変更せずにロードした場合、ODIではMonthsの値として「January」をロードし、Statusの値として「February」をロードします。1つ目のレコードの残りのデータ(つまり、March, Active)はロードされません。
ODIでこのデータを正しくロードできるようにするには、次のようにMonthsフィールドのデータを二重引用符囲み文字(" ")で囲みます。
Months, Status "January, February, March", Active "April, May, June", Active
変更すると、データが正しくロードされるようになります。この例の1つ目のレコードでは、Monthsの値として「January, February, March」がロードされ、Statusの値として「Active」がロードされます。
ソース・ファイルのデリミタを設定するには:
ソース・データを含むCSVファイルを開きます。
あらかじめ選択した囲み文字(たとえば、("))でデータ・フィールドを囲みます。
ソース・データに存在しない囲み文字を選択する必要があります。囲み文字には一重引用符(')や二重引用符(")が一般的です。
CSVファイルを保存して閉じます。
ODIデザイナで、「モデル」ビューを表示し、「Oracle BI Applications」フォルダを展開します。
変更されたCSVファイルに関連付けられているデータ・ストアを特定します。変更したCSVファイルは、1つ以上のデータ・ストアに関連付けることができます。
次に示すように、ODIデザイナで、囲み文字を使用するように、これらのデータ・ストアそれぞれのプロパティを変更します。
データ・ソースをダブルクリックします。これにより「データストア: <名前>」ダイアログが表示されます。
「ファイル」タブを表示します。
「テキスト・デリミタ」フィールドを使用して、ステップ2で使用した囲み文字を指定し、データを囲みます。
「OK」をクリックして、変更内容を保存します。
これで、変更されたCSVファイルからデータをロードできます。
この項では、Oracle Business Intelligence ApplicationsでOracle Business Analytics Warehouseにデータをロードする方法をカスタマイズする方法について説明します。
プライマリ抽出セッションおよび削除セッションを有効にする前に、Oracle Business Analytics Warehouse内でのそれらの機能を理解することが重要です。プライマリ抽出マッピングおよび削除マッピングでは、分析システムでプライマリ抽出ステージング表を最新のOracle Business Analytics Warehouse表と比較することによって、ソース・システムから削除するレコードを決定できます。
プライマリ抽出マッピングは、ソース・システムから主キーの完全抽出を実行します。多くの行がこの抽出によって生成されますが、ソース表から抽出されるデータはキーIDおよびソースIDの情報のみです。プライマリ抽出マッピングは、これら2つの列を*_PE接尾辞でマークされたステージング表にロードします。
次の図は、抽出プロセスの開始例を示しています。これは、2日間のイベントのシーケンスを示しています。この期間に、ソース表の情報が変更されます。1日目、データは、ソース表から抽出され、Oracle Business Analytics Warehouse表にロードされます。2日目、販売オーダー番号3が削除され、新しい販売オーダーが受信され、2つの表間の販売オーダー情報の不一致が形成されます。
図1-4は、2日目の情報が抽出され、ソースからOracle Business Analytics Warehouseにロードされたときに発生するプライマリ抽出プロセスおよび削除プロセスを示しています。最初の抽出で、レコード4がOracle Business Analytics Warehouseに渡されます。次に、プライマリ抽出マッピングを使用して、キーIDとソースIDがソース表から抽出され、プライマリ抽出ステージング表にロードされます。
抽出マッピングは、プライマリ抽出ステージング表のキーと最新のOracle Business Analytics Warehouse表のキーを比較します。これは、Oracle Business Analytics Warehouseには存在するが、ステージング表には存在しないレコード(前の例では、レコード3)を探し、Source Adapterの削除フラグをYに設定し、対応するレコードに削除というマークを付けます。
抽出マッピングは、ソースには追加されたが、Oracle Business Analytics Warehouseにはまだ存在していない新しいレコード(この場合はレコード4)もすべて検出します。ステージング表の情報に基づいて、販売注文番号3がOracle Business Analytics Warehouseから物理的に削除されます(図1-4を参照)。抽出マッピングおよびロード・マッピングを実行すると、ウェアハウスに新しい販売注文が追加されます。
プライマリ抽出マッピング(*_Primary)および削除マッピング(*_IdentifyDeleteおよび*_Softdelete)は、ソース・システムから物理的に削除されたレコードを識別する際に重要な役割を果たします。ただし、プライマリ抽出マッピングおよび削除マッピングを無効または削除できる場合があります。たとえば、ソース・システムのデータベースから削除され、別のデータベースにアーカイブされたレコードをOracle Business Analytics Warehouseに保持する場合です。
削除マッピングでは、ソースIDとキーIDを使用して、削除されたデータが識別されるため、複数のソース・システムを使用している場合には、SQL問合せ文を変更して、削除マッピングで適切なソースIDが使用されていることを確認する必要があります。プライマリ抽出マッピングおよび削除マッピングに加えて、ロード・マッピングの削除フラグの構成でも、レコードの削除の処理方法を決定できます。
データの抽出と削除は、次の方法で管理できます。
ソースがアーカイブしたレコードの構成の削除
特定のソースからのレコードの削除
削除セッションおよびプライマリ抽出セッションの有効化
レコード削除フラグの構成
レコード却下フラグの構成
一部のソースは、レコードを別のデータベースにアーカイブして、メイン・データベースに現在の情報のみを保持します。削除マッピングを有効にしている場合は、Oracle Business Analytics Warehouseの削除マッピングを再構成して、アーカイブされたデータを保持する必要があります。
ソースがアーカイブしたレコードをOracle Business Analytics Warehouseで保持するには、LAST_ARCHIVE_DATEパラメータの値を、アーカイブの日付を反映するように適切に設定してください。削除マッピングは、アーカイブされたレコードに削除済というマークを付けません。抽出マッピングおよび削除マッピングの詳細は、第1.4.3.2項「プライマリ抽出マッピングおよび削除マッピングを使用した作業について」を参照してください。
この項では、Oracle Business Intelligence Applicationsのカスタマイズの3つのすべてのカテゴリに適用されるその他の情報について説明します。この項の内容は次のとおりです。
この項では、コード・ルックアップとディメンション・キーについて説明します。
デフォルトでは、ディメンション・キーの解決は、Oracle Business Analytics Warehouseのロード・マッピングで実行されます。ロード・インタフェースは、事前にパッケージされた再利用可能なルックアップ変換を使用して、事前にパッケージされたディメンション・キーの解決を実現します。この項では、ディメンション・キーのルックアップ方法および解決方法について説明します。
ディメンション・キーの解決には、一般に2種類の方法が使用されます。1つ目の方法は、最も使用される方法であり、ディメンション・キーへのルックアップを実行することです。2つ目の方法は、ファクト・ロード・マッピングに直接ディメンション・キーを提供することです。
ロード・インタフェースにデータベース結合によってディメンション・キーが提供されない場合には、ロード・マッピングでディメンション表内へのルックアップを実行します。ロード・マッピングでは、事前にパッケージされたルックアップ・インタフェースを使用してこの処理を実行します。ディメンション・キーをルックアップするには、ロード・インタフェースでINTEGRATION_ID、DATASOURCE_NUM_IDおよびルックアップ日付を使用します。次の表はこれらのポートについて説明しています。
表1-1 ロード・マッピングのディメンション・キー・ルックアップで使用される列
| ポート | 説明 |
|---|---|
|
INTEGRATION ID |
ソース・システム内でディメンション・エンティティを一意に識別します。ファクト表のSource Adapterにあるトランザクションで形成されます。 |
|
DATASOURCE_NUM_ID |
ソース・システムのインスタンスの一意の識別子。 |
|
ルックアップ日付 |
取引のプライマリ日付(受領日や販売日など)。 |
タイプIIの緩やかに変化するディメンションが有効な場合、ロード・マッピングでは、ディメンション・レコードの更新ごとに一意の有効日が使用されます。ディメンション・キーのルックアップ時には、ファクトのプライマリ日付または「正規の」日付を使用して適切なディメンション・キーが解決されます。有効日の範囲は、ディメンション・レコードの有効期間を指定します。タイプIIの緩やかに変化するディメンションであるため、同じエンティティで、有効日の異なる複数のレコードをディメンション表内に持つことができます。この有効日の範囲は、ディメンション内のレコードを正確に識別するために使用し、履歴において正確な方法で情報を表現します。
ロード・インタフェース・ルックアップに必要な4つの列(INTEGRATION ID、DATASOURCE_NUM_IDおよびルックアップ日付(EFFECTIVE_FROM_DTとEFFECTIVE_TO_DATE))が用意されています。このルックアップで、ROW_WID (ディメンションの主キー)が対応するファクト表のWID列(ファクト表の外部キー)に出力されます。
Oracle Business Analytics Warehouseのディメンション表とファクト表では、次の2種類の索引を使用します。
ETL索引
ETL索引は、一意/バイナリ・ツリー索引に使用されます。
問合せ索引
問合せ索引は、非一意/ビット・マップ索引に使用されます。
既存のファクト表またはディメンション表に索引を追加するには:
ODIデザイナで、「モデル」ビューを表示し、「Oracle BI Applications」フォルダを展開します。
必要に応じて、「ファクト」または「ディメンション」ノードを展開します。
索引を作成する表を展開します。
「制約」ノードを右クリックして、「キーの挿入」を選択し、「キー: 新規」ダイアログを表示します。
「説明」タブを表示します。
「代替キー」ラジオ・ボタンを選択し、「名前」フィールドの索引の名前を更新します。
「列」タブを表示します。
索引を作成する列を選択します。
「フレックスフィールド」タブを表示します。
この設定を使用して、次のように索引タイプを指定します。
「問合せ」タイプの索引(デフォルト)の場合、一意の索引に対して「代替キー」として索引を定義し、非一意の索引に対して「非一意索引」として索引を定義します。
「ETL」タイプの索引の場合、INDEX_TYPEパラメータのチェック・ボックスの選択を解除し、値を「ETL」に設定します。また、IS_BITMAPパラメータの値を「N」に設定し、一意の索引に対して「代替キー」として索引を定義し、非一意の索引に対して「非一意索引」として索引を定義します。
変更内容を保存します。
Oracle BI Applicationsリリース11.1.1.8.1は、すべてのBI ApplicationsモジュールおよびOperational Planning Applicationsに対するプロジェクトを含む完全なRPDファイルを提供しています。BIサーバーには、この完全なRPDがデプロイされます。自分のデプロイメントに関係するプロジェクトのみを含むように、RPDをトリミングできます。RPDのトリミングはオプションですが、BIサーバーの起動プロセスが高速化され、パッチの適用も迅速化されます。
RPDをトリミングする手順は、デプロイメントの状態によって変わります。
RPDが自分のデプロイメント向けにカスタマイズされていない場合は、所属する組織が購入した製品に対するプロジェクトを抽出します。マージを実行する必要はありません。手順は、第1.6.1項「完全なRPDからのプロジェクトの抽出」を参照してください。
RPDが自分のデプロイメント向けにカスタマイズされている場合は、リリース11.1.1.8.1に対する完全な(提供されている)RPDから適用可能なプロジェクトを抽出した上で、そのRPDを、カスタマイズ済のリリース11.1.1.8.1 RPDとマージします。手順は、第1.6.1項「完全なRPDからのプロジェクトの抽出」を参照してください。
次の手順に従って、完全なRPDからプロジェクトを抽出します。このプロセスの最終的な結果が、トリミングされたRPDになります。
購入した製品に対するプロジェクトをRPDから抽出するには:
BI Administration Toolがインストールされているコンピュータで、コマンド・ウィンドウを開きます。
WindowsにOracle BI EEをインストールした場合、bi-init.cmdを実行し、ご使用のOracleインスタンスに対して初期化されたコマンド・プロンプトを起動します。このユーティリティは次の場所にあります。
<MiddlewareHome>\instances\instance<n>\bifoundation\OracleBIApplication\coreapplication\setup
BIクライアント・インストーラを使用してBI Administration Toolをインストールした場合、bi_init.batを実行し、ご使用のOracleインスタンスに対して初期化されたコマンド・プロンプトを起動します。このファイルは次の場所にあります。
<Oracle BI Home>\oraclebi\orahome\bifoundation\server\bin
コマンド・プロンプト・ウィンドウで、次の説明に従って、ExtractProjectsを実行します。
WindowsにOracle BI EEをインストールした場合、ExtractProjects.exeは<Oracle Home for BI>\bifoundation\server\binに配置されています。
BIクライアント・インストーラを使用してBI Administration Toolをインストールした場合、ExtractProjects.exeは<Oracle BI Home>\oraclebi\orahome\bifoundation\server\binに配置されています。
次のコマンドのいずれかを実行します。
単一のプロンプトを抽出する場合:
ExtractProjects -B input_rpd -O output_rpd -I "project_name"
複数のプロンプトを抽出する場合:
ExtractProjects -B input_rpd -O output_rpd -I "project_name1" -I "project_name2"-I "project_name3" (and so on)
ここで、
input_rpdは、完全な(提供されている)リリース11.1.1.8.1 RPDの名前とパスであり、ここからプロジェクトを抽出します(OracleBIApps.rpdなど)。
output_rpdは、抽出されたプロジェクトを使用して作成するRPDの名前とパスです(OracleBIAppsTrimmed.rpdなど)。
project_nameは、抽出するRPDプロジェクトの名前です。
RPDに対する暗号化パスワードの入力が求められます(input_rpd)。
11.1.1.8.1 RPD内のプロジェクトのリストには、次のものが含まれます。
Financial Analytics Fusion Edition
Human Resources Analytics Fusion Edition
Marketing Analytics Fusion Edition
Partner Analytics Fusion Edition
Project Analytics Fusion Edition
Sales Analytics Fusion Edition
Supply Chain and Order Management Analytics Fusion Edition
Student Information Analytics
Service Analytics
Price Analytics
Manufacturing Analytics
Operational Planning
DataLineage_Project
注意: RPDには、前述のもの以外のプロジェクトも含まれています。これらのプロジェクトは、将来のコンテンツ配信やアップグレード・サポートのために含まれています。このリリースで使用可能なBI Applicationsを確認するには、Oracle BI Applicationsリリース11.1.1.8.1のシステム要件とサポートされているプラットフォームに関する項(http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html)を参照してください。
トリミングされたRPDを保存して名前を変更します。このRPDがトリミング済のRPDであることがわかるような名前にしてください(たとえば、OracleBIAppsTrimmed.rpd)。
デフォルトでは、ディメンション・キーの解決は、Oracle Business Analytics Warehouseのロード・マッピングで実行されます。ロード・インタフェースは、事前にパッケージされた再利用可能なルックアップ変換を使用して、事前にパッケージされたディメンション・キーの解決を実現します。この項では、ディメンション・キーのルックアップ方法および解決方法について説明します。
ディメンション・キーの解決には、一般に2種類の方法が使用されます。1つ目の方法は、最も使用される方法であり、ディメンション・キーへのルックアップを実行することです。2つ目の方法は、ファクト・ロード・マッピングに直接ディメンション・キーを提供することです。
ロード・インタフェースにデータベース結合によってディメンション・キーが提供されない場合には、ロード・マッピングでディメンション表内へのルックアップを実行します。ロード・マッピングでは、事前にパッケージされたルックアップ・インタフェースを使用してこの処理を実行します。ディメンション・キーをルックアップするには、ロード・インタフェースでINTEGRATION_ID、DATASOURCE_NUM_IDおよびルックアップ日付を使用します。次の表はこれらのポートについて説明しています。
表1-2 ロード・マッピングのディメンション・キー・ルックアップで使用される列
| ポート | 説明 |
|---|---|
|
INTEGRATION ID |
ソース・システム内でディメンション・エンティティを一意に識別します。ファクト表のSource Adapterにあるトランザクションで形成されます。 |
|
DATASOURCE_NUM_ID |
ソース・システムのインスタンスの一意の識別子。 |
|
ルックアップ日付 |
取引のプライマリ日付(受領日や販売日など)。 |
タイプIIの緩やかに変化するディメンションが有効な場合、ロード・マッピングでは、ディメンション・レコードの更新ごとに一意の有効日が使用されます。ディメンション・キーのルックアップ時には、ファクトのプライマリ日付または「正規の」日付を使用して適切なディメンション・キーが解決されます。有効日の範囲は、ディメンション・レコードの有効期間を指定します。タイプIIの緩やかに変化するディメンションであるため、同じエンティティで、有効日の異なる複数のレコードをディメンション表内に持つことができます。この有効日の範囲は、ディメンション内のレコードを正確に識別するために使用し、履歴において正確な方法で情報を表現します。
ロード・インタフェース・ルックアップに必要な4つの列(INTEGRATION ID、DATASOURCE_NUM_IDおよびルックアップ日付(EFFECTIVE_FROM_DTとEFFECTIVE_TO_DATE))が用意されています。このルックアップで、ROW_WID (ディメンションの主キー)が対応するファクト表のWID列(ファクト表の外部キー)に出力されます。
次の手順は、RPDをカスタマイズした後、RPDをトリミングしている場合にのみ実行してください。
リポジトリをマージするには:
Oracle BI Administration Toolで、第1.6.1項「完全なRPDからのプロジェクトの抽出」の手順で作成したトリミング済のOracle BI RPD(OracleBIAppsTrimmed.rpdなど)をオフラインモードで開きます。
メニュー・バーで、「ファイル」をクリックし、次に「マージ」をクリックします。
「元のリポジトリの選択」ダイアログ・ボックスで、リポジトリOracleBIApps.rpdを選択します。これは完全なRPDです。
元のリポジトリのパスワードを入力して、「OK」をクリックします。
「修正済リポジトリ」フィールドで「選択」をクリックします。「変更済リポジトリの選択」ダイアログ・ボックスが開きます。
「変更済リポジトリの選択」ダイアログが開きます。
RPDファイルに対して行ったカスタマイズ内容を含むリポジトリを選択します(たとえば、OracleBIAppsCustom.rpd)。
「開く」をクリックし、以前にカスタマイズしたRPDファイルのパスワードを入力して、「OK」をクリックします。
「デシジョン」ドロップダウン・リストで、リポジトリの変更に関して実行するアクションを選択するか、デフォルトのアクションを受け入れます。
空の「デシジョン」フィールドを含む後続の行を探すには、「デシジョン」のヘッダー・セルをクリックします。「デシジョン」フィールドのすべての行に値が設定されると、「マージ」ボタンが有効になります。
「マージ」をクリックします。
マージが正常に完了すると、メッセージが表示されます。
メニュー・バーで、「ファイル」をクリックし、次に「名前を付けて保存」をクリックします。新しい名前(OracleBIAppsFinal.rpdなど)を使用して現在のリポジトリを保存します。
