この項では、Oracle BI Applicationsで使用可能な統合ナレッジ・モジュール(IKM)について詳しく説明します。
この項には次のトピックが含まれます:
このIKMは、Oracleターゲット表にデータを追加モードで統合します。すべてのレコードは、キー・チェックなしで挿入されます。データの制御は、エラー表の無効なデータを分離してから、修正後にリサイクルすることで行えます。
前提条件
このIKMを使用するための前提条件は次のとおりです。
「ジャーナルからの削除の同期」プロセスを実行すると、ターゲットで削除した行がコミットされます。
FLOW_CONTROLおよびRECYCLE_ERRORSオプションを使用するには、インタフェースで更新キーを設定する必要があります。
機能のオプション
未指定のレコード。ターゲット表がディメンションの場合、このオプションをTRUEに設定して、未指定のレコードを自動的に挿入します。その他のディメンション・レコードが一致しない場合、これがファクトによって参照されます。デフォルトの列値は、ユーザー定義関数GET_UNSPEC_VALUEを使用して、モデルの命名標準で決定されます。
パフォーマンス・チューニングのオプション
ヒント: このIKMを使用すると、生成されたSQLにヒントを渡せます。詳細は、My Oracle SupportのOracle Business Intelligence Applicationsリリース11.1.1.7.1のパフォーマンス推奨事項(Doc ID 1539322.1)の記事を参照してください。
ALTER SESSIONリスト: KMで使用されるセッションに、ALTER SESSIONコマンドのリストを適用します。コマンド間はセミコロンで区切ります。接頭辞ALTER SESSIONは付けません。コマンドをソース接続で実行するか(LKMを使用する場合)、またはターゲット接続で実行するかによって、各コマンドに接頭辞SRCまたはTGTを付ける必要があります。次に例を示します。
SRC set TRACEFILE_IDENTIFIER='ODI_TRACE'; SRC set events '10046 TRACE NAME CONTEXT FOREVER, LEVEL 8'; TGT set TRACEFILE_IDENTIFIER='ODI_TRACE_TGT';
このIKMは、増分変更を処理するイベント・キューを使用して、Oracleターゲット表にデータを統合します。このIKMは、経時的にバージョン管理されるデータ(遅延変更ディメンションに類似している)を操作するときに使用します。フル・ロードの場合は、すべてのレコードが挿入されます。イベント・キューは、変化している自然キーと、変更が発生した最初の日付を追跡します。自然キーごとに、最初の変更以降の既存ターゲット・レコードはすべて削除され、新しいレコードが挿入されます。
有効開始日と有効終了日がある場合、これらがフル・ロードと増分ロードの両方で自動的に保持されます。
データの制御は、エラー表の無効なデータを分離することで行えますが、データのリサイクルはサポートされていません。
前提条件
このIKMを使用するための前提条件は次のとおりです。
イベント・キュー表は、「イベント・キュー表」オプションを使用して定義する必要があります。
EARLIEST_CHANGE_DATE列(DATE型)が含まれている必要があります。
標準命名規則に従って、末尾に_EQ_TMPを付加する必要があります。
ターゲット表とイベント・キューの間の結合は、「イベント・キューの結合」オプションを使用して定義する必要があります。
ターゲット表では、次の項目にSCD動作を設定する必要があります。
自然キー
開始/終了のタイムスタンプ
インタフェースでは、変化しているソース・データのみ(変化している自然キーおよび変更の最初の日付をリストするイベント・キューで制御されている)を選択する必要があります。
データは、増分データのみが格納された一時表やステージング表から選択するか
または
ネストされたIKM BIAPPS Oracle Event Queue Delete Appendを使用して、増分ロードのイベント・キューに結合を含めます。
「ジャーナルからの削除の同期」プロセスを実行すると、ターゲットで削除した行がコミットされます。
機能のオプション
イベント・キュー表。増分変更を保持するイベント・キュー表の名前です。このオプションは必須です。
このオプションの前提条件は次のとおりです。
イベント・キュー表には、EARLIEST_CHANGE_DATE列(DATEデータ型)が含まれている必要があります。
Oracle BI Applicationsの表の命名標準に従って、末尾に_EQ_TMPが付加されます。
イベント・キューの結合。ターゲット表の別名がTで、イベント・キュー表の別名がQであると想定して、ターゲット表とイベント・キュー表の間に等価結合を定義します。これは、「イベント・キューの更新」ステップと「イベント・キューの削除」ステップで使用されますが、どちらのステップも不要であるという、まれなケースでは省略してもかまいません。EARLIEST_CHANGE_DATEに対するフィルタは、結合オプションに含めることはできません。
イベント・キューの削除。増分ロードで処理されているターゲット表のレコードを削除するかどうか。ほとんどの場合、これは有効化する必要がありますが、複数のインタフェースでターゲット表をロードするという、まれなケースでは最初のインタフェースでのみ有効化する必要があります。
イベント・キューの更新。増分ロードの影響を受けるターゲット表のレコードで有効日を修正するかどうか。ほとんどの場合、これは有効化する必要がありますが、複数のインタフェースでターゲット表をロードするという、まれなケースでは最後のインタフェースでのみ有効化する必要があります。
高いデータ値。最大の終了タイムスタンプに使用するデフォルト値です。ほとんどの場合、#HI_DATEのデフォルト値で十分ですが、OLTPを反映する一部の永続化されたステージング表では、別の値(たとえば、#ORA_HI_DATE)を使用することがあります。
未指定のレコード。ターゲット表がディメンションの場合、これをTRUEに設定して、未指定のレコードを自動的に挿入します。その他のディメンション・レコードが一致しない場合、これがファクトによって参照されます。デフォルトの列値は、ユーザー定義関数GET_UNSPEC_VALUEを使用して、モデルの命名標準で決定されます。
パフォーマンス・チューニングのオプション
ヒント: このIKMを使用すると、生成されたSQLにヒントを渡せます。詳細は、My Oracle SupportのOracle Business Intelligence Applicationsリリース11.1.1.7.1のパフォーマンス推奨事項(Doc ID 1539322.1)の記事を参照してください。
ALTER SESSIONリスト: KMで使用されるセッションに、ALTER SESSIONコマンドのリストを適用します。コマンド間はセミコロンで区切ります。接頭辞ALTER SESSIONは付けません。コマンドをソース接続で実行するか(LKMを使用する場合)、またはターゲット接続で実行するかによって、各コマンドに接頭辞SRCまたはTGTを付ける必要があります。次に例を示します。
SRC set TRACEFILE_IDENTIFIER='ODI_TRACE'; SRC set events '10046 TRACE NAME CONTEXT FOREVER, LEVEL 8'; TGT set TRACEFILE_IDENTIFIER='ODI_TRACE_TGT';
このIKMは、Oracleターゲット表にデータを追加モードで統合します。すべてのレコードは、キー・チェックなしで挿入されます。データの制御は、エラー表の無効なデータを分離してから、修正後にリサイクルすることで行えます。
前提条件
このIKMを使用するための前提条件は次のとおりです。
LOAD_PARTITION_METADATAシナリオは、インタフェースの前に実行する必要があります。その際には、このKMを使用して、ターゲット表の名前をパラメータとして渡します。これにより、必要なメタデータとともにW_ETL_PART_TABLESおよびW_ETL_PART_TABLE_PARTSがロードされます。
機能のオプション
このIKMで使用可能なオプションについては、「IKM BIAPPS Oracle Incremental Update」のオプションの説明を参照してください。
このIKMは、Oracleターゲット表にデータを増分更新モードで統合します。新しいレコードが挿入され、既存のレコードは更新されます。データの制御は、エラー表の無効なデータを分離してから、修正後にリサイクルすることで行えます。
前提条件
このIKMを使用するための前提条件は次のとおりです。
更新キーはインタフェースで定義する必要があり、キー列は索引付けされている必要があります。
「ジャーナルからの削除の同期」プロセスを実行すると、ターゲットで削除した行がコミットされます。
機能のオプション
ソフト削除。ソフト削除オプションを有効にすると、いくつかの追加ステップを実行できます。#SOFT_DELETE_FEATURE_ENABLED(グローバル)および#SOFT_DELETE_PREPROCESS(ファクトまたはディメンション・グループごとに設定可能)変数により、どのステップを実行するかを正確に制御できます。
ソース・システムでの削除を効率的にキャプチャするトリガーが実装可能な場合は、負荷の高い前処理のステップ(全ソース・レコードを抽出して、それを全ターゲット・レコードと比較する)を無効にして、そのかわりに削除表への直接移入を行うことができます。
ステップ | アクション | 制御 |
---|---|---|
ソフト削除の前処理 |
「削除識別」ステップを実行します。このステップは、プライマリ抽出表とターゲット表のデータを比較して、廃止されたターゲット行を削除表に記録します。
|
#SOFT_DELETE_FEATURE_ENABLED #SOFT_DELETE_PREPROCESS |
ターゲットのソフト削除 |
「ソフト削除」ステップを実行します。このステップは、削除対象として識別されたレコードについて、ターゲット表のDELETE_FLG列を「Y」に更新します。 |
#SOFT_DELETE_FEATURE_ENABLED |
削除表の切捨て |
処理が終了したレコードを削除表から削除します。 |
#SOFT_DELETE_FEATURE_ENABLED |
これらのステップはすべて、ターゲット表へのその他の挿入および更新とともに、まとめてコミットされる点に注意してください。これにより、データ・ウェアハウスの一貫性が保たれます。
このオプションを使用するための前提条件は次のとおりです。
ターゲット表には、ETL_PROC_WIDおよびW_UPDATE_DTシステム列が必要です。
<target>_PEおよび<target>_DEL表は、インタフェース・キーの列で作成する必要があります。
ターゲット表にCREATED_ON_DT列が含まれていない場合は、#LAST_ARCHIVE_DATEをNULLにする必要があります。
#SOFT_DELETE_PREPROCESSは、Oracle BI Applications構成マネージャから、ロード・プラン・コンポーネント単位でリフレッシュする必要があります。
日付追跡。(遅延変更ディメンションの場合と同様に)ターゲット表の有効開始日と有効終了日を自動的に保持します。日付または数値(通常はYYYYMMDDなどの日付キー)を処理できます。これにより、現行フラグ列を設定することもできます。この列は、最新レコードの場合は「Y」になり、古いレコードの場合は「N」になります。
このオプションを使用するための前提条件は次のとおりです。
モデル内の次の表の列で、遅延変更ディメンションの動作を設定します。
- 自然キー
- 開始/終了のタイムスタンプ
- 現行フラグ(オプション)
自然キー列と開始タイムスタンプ列は、索引付けする必要があります(更新キー索引の対象でない場合)。インタフェースでは、有効終了日の列を、ターゲットで実行するように設定された定数の最大値(通常は#HI_DATE)にマップします。
現行フラグを使用する場合は、そのフラグを「Y」にマップします(再度ターゲットで実行する)。
ETL_PROC_WIDは、索引付けされている必要があります。
変更のキャプチャ。ターゲット表の変更をイメージ表にキャプチャすることで変更反映プロセスを集約し、合理化します。
ステップ | アクション | 制御 |
---|---|---|
変更イメージ表の切捨て |
イメージ表を消去して、現在のプロセスの変更をキャプチャする準備を整えます。 |
常に実行 |
事前ロードの変更のキャプチャ |
これから更新されるターゲット表のレコードをキャプチャします。 |
常に実行 |
ソフト削除の変更のキャプチャ |
これからソフト削除対象としてマークされるターゲット表のレコードをキャプチャします。 |
ソフト削除機能が有効な場合に実行 |
ロード後の変更のキャプチャ |
挿入または更新されたターゲット表のレコードをキャプチャします。 |
常に実行 |
これらのステップはすべて、ターゲット表へのその他の挿入および更新とともに、まとめてコミットされます。これにより、データ・ウェアハウスの一貫性が保たれます。
このオプションを使用するための前提条件は次のとおりです。
W_FACT_Fでは、ターゲット表のすべての列を含むイメージ表W_FACT_CMG、および次の列を作成する必要があります。
CHANGED_IN_TASK
PHASE_CODE
PHASE_MULTIPLIER
未指定のレコード。ターゲット表がディメンションの場合、これをTRUEに設定して、未指定のレコードを自動的に挿入します。その他のディメンション・レコードが一致しない場合、これがファクトによって参照されます。デフォルトの列値は、ユーザー定義関数GET_UNSPEC_VALUEを使用して、モデルの命名標準で決定されます。
パフォーマンス・チューニングのオプション
ヒント: このIKMを使用すると、生成されたSQLにヒントを渡せます。詳細は、My Oracle SupportのOracle Business Intelligence Applicationsリリース11.1.1.7.1のパフォーマンス推奨事項(Doc ID 1539322.1)の記事を参照してください。
ALTER SESSIONリスト: KMで使用されるセッションに、ALTER SESSIONコマンドのリストを適用します。コマンド間はセミコロンで区切ります。接頭辞ALTER SESSIONは付けません。コマンドをソース接続で実行するか(LKMを使用する場合)、またはターゲット接続で実行するかによって、各コマンドに接頭辞SRCまたはTGTを付ける必要があります。次に例を示します。
SRC set TRACEFILE_IDENTIFIER='ODI_TRACE'; SRC set events '10046 TRACE NAME CONTEXT FOREVER, LEVEL 8'; TGT set TRACEFILE_IDENTIFIER='ODI_TRACE_TGT';
ターゲットの分析: KMオプションのANALYZE_TARGETがTrueに設定されている場合、ロード前のターゲット表に関する統計が収集されます。デフォルトでは、Falseに設定されています。
フロー表の分析: KMオプションのANALYZE_FLOW_TABLEがTrueに設定されている場合、ロード後のフロー表(I$)に関する統計が収集されます。デフォルトでは、Falseに設定されています。このオプションは、フル・ロード時の有効日の計算方法にも影響します(日付追跡オプションが有効な場合)。フロー表が分析されていない場合、有効終了日の設定にUPDATE文が使用されます。それ以外の場合は、MERGE文が使用されます。
バルク・モード(#ETL_BULK_MODE変数): 有効にすると、バルク・モードでターゲットへのダイレクト・パス書込み(ヒントの追加)が使用され、I$表がバイパスされます(フロー制御、リサイクル・エラー、日付追跡などのその他のKMオプションが必要としない場合)。バルク・モード変数は、次の値に設定できます。
Y: 有効
F: フル・ロードにのみ有効
N: 無効
このIKMは、Oracleターゲット表にデータを統合します(期間ごとにデータを集計する)。新しいレコードは挿入されます。また、既存の期間に対する変更は、その期間の古いデータを削除してから、新しいデータを挿入することで処理されます。古い期間のデータは、パージされることがあります。データの制御は、エラー表の無効なデータを分離してから、修正後にリサイクルすることで行えます。
前提条件
このIKMを使用するための前提条件は次のとおりです。
「削除期間タイプ」オプションには、ターゲット表が基づいている期間タイプを指定する必要があります。
カレンダ期間では、ターゲット表に期間最終日キーの列を含める必要があります。
- 日付WID型(YYYYMMDD)にする必要があります。
- PERIOD_END_DT_WIDという名前にする必要があります。「UD1」チェック・ボックスを使用してマッピングで特定することもできます。
MCALカレンダ期間では、ターゲット表に次のものを含める必要があります。
- 期間キー。通常はMCAL_PERIOD_WIDまたはMCAL_DAY_WIDです。「UD1」チェック・ボックスを使用してマッピングで特定することもできます。
- カレンダ・キー。通常はMCAL_CAL_WIDです。「UD2」チェック・ボックスを使用してマッピングで特定することもできます。
前述のキー列に対するビットマップ索引。
カレンダ期間
サポート対象のカレンダ期間は、日、週、月、四半期および年です。これらの期間タイプの場合、増分ロードでは、インタフェースによって現行期間のみのデータがロードされていると想定します。増分更新は、現行期間の既存データを削除することで機能します。その後、現行期間用の新しいデータ・セットを挿入します。必要に応じて、「保持する期間数」オプションで、指定した経過期間より古いデータを自動的にパージできます。「削除する期間数」オプションは、カレンダ期間には適用されません。
MCALカレンダ期間
MCALカレンダ期間(MCAL日およびMCAL期間)がサポートされます。これらの期間タイプの場合、増分ロードでは、インタフェースによって現行期間のデータと、指定した数の前期間のデータがロードされていると想定します。増分更新は、該当する期間の既存データを削除することで機能します。その後、新しいデータ・セットを挿入します。「削除する期間数」オプションは、インタフェースによって増分ロードされている前期間(および現行期間)の数を制御します。たとえば、値が1の場合は、ロードするたびに現行期間とその前の期間が再処理されることになります。「保持する期間数」オプションは、MCALカレンダ期間には適用されません。
機能のオプション
削除期間タイプ: ターゲット表が基づいているカレンダ期間のタイプです。再処理のために現行期間を削除する場合や、廃止された期間をパージする場合に使用します。有効な値は次のとおりです。
カレンダ期間: CAL_DAY、CAL_WEEK、CAL_MONTH、CAL_QTR、CAL_YEAR。
MCALカレンダ期間: MCAL_DAY、MCAL_PERIOD。
このオプションを使用するための前提条件は次のとおりです。
カレンダ期間では、ターゲット表に期間最終日キーの列を含める必要があります。
- PERIOD_END_DT_WIDという名前にする必要があります。「UD1」チェック・ボックスを使用してマッピングで特定することもできます。
- 日付WID型(YYYYMMDD)にする必要があります。
MCALカレンダ期間では、ターゲット表に次のものを含める必要があります。
- 期間キー。通常はMCAL_PERIOD_WIDまたはMCAL_DAY_WIDです。「UD1」チェック・ボックスを使用してマッピングで特定することもできます。
- カレンダ・キー。通常はMCAL_CAL_WIDです。「UD2」チェック・ボックスを使用してマッピングで特定することもできます。
削除する期間数: このオプションは、MCALカレンダ期間のみの追加機能を構成するためのものです。カレンダ期間の場合は、デフォルト値(0: 現行期間のみ削除)のままにする必要があります。このオプションの値をN > 0に設定すると、削除期間タイプに基づいて、Nユリウス歴期間数分のデータが削除されます。たとえば、1に設定すると、現行期間とその前の期間が削除されます。
保持する期間数: このオプションは、カレンダ期間のみの追加機能を構成するためのものです。カレンダ期間の場合は、デフォルト値(0: すべての期間を保持)のままにする必要があります。このオプションの値をN > 0に設定すると、現在のユリウス歴期間よりNユリウス歴期間数分前の期間データが削除されます。
パフォーマンス・チューニングのオプション
ヒント: このIKMを使用すると、生成されたSQLにヒントを渡せます。詳細は、My Oracle SupportのOracle Business Intelligence Applicationsリリース11.1.1.7.1のパフォーマンス推奨事項(Doc ID 1539322.1)の記事を参照してください。
ALTER SESSIONリスト: KMで使用されるセッションに、ALTER SESSIONコマンドのリストを適用します。コマンド間はセミコロンで区切ります。接頭辞ALTER SESSIONは付けません。コマンドをソース接続で実行するか(LKMを使用する場合)、またはターゲット接続で実行するかによって、各コマンドに接頭辞SRCまたはTGTを付ける必要があります。次に例を示します。
SRC set TRACEFILE_IDENTIFIER='ODI_TRACE'; SRC set events '10046 TRACE NAME CONTEXT FOREVER, LEVEL 8'; TGT set TRACEFILE_IDENTIFIER='ODI_TRACE_TGT';
このIKMは、タイプ2遅延変更ディメンションとしてモデル化されたOracleターゲット表にデータを統合します。新しいレコードは挿入されます。また、既存のレコードに対する変更によって、挿入または更新のいずれかがトリガーされることがあります(タイプ2列に対する変更があるかどうかによる)。データの制御は、エラー表の無効なデータを分離してから、修正後にリサイクルすることで行えます。このオプションは、#TYPE2_FLGおよび#UPDATE_ALL_HISTORY変数を使用して動作を制御します。
前提条件
このIKMを使用するための前提条件は次のとおりです。
更新キーはインタフェースで定義する必要があり、キー列(通常は、INTEGRATION_ID、DATASOURCE_NUM_ID、SRC_EFF_FROM_DT)は索引付けされている必要があります。遅延変更ディメンションの動作は、すべてのターゲット表の列に対して設定(モデルで設定)されている必要があり、次のものを含める必要があります。
- サロゲート・キー(通常は、ROW_WID)
- 自然キー(通常は、INTEGRATION_ID、DATASOURCE_NUM_ID)
- 開始と終了のタイムスタンプ(通常は、EFFECTIVE_FROM_DTとEFFECTIVE_TO_DT)
- 現行フラグ(通常は、CURRENT_FLG)
終了タイムスタンプは、最大値(通常は、#HI_DATE)にマップされている必要があります。
現行フラグは、Yにマップされている必要があります。
ソースの開始日と終了日は、Nullにはできません(#LOW_DATEまたは#HI_DATEにデフォルト設定される)。
ETL_PROC_WIDは、索引付けされている必要があります。
列の分類
次の表では、ディメンションの列の分類方法と、分類ごとの異なる動作について説明します。分類は、モデル内の個別の表の列に対して行われます。
列 | 説明 | SCDの動作 | その他のフレックスフィールド |
---|---|---|---|
サロゲート・キー |
ウェアハウスで生成されたディメンション用の主キー |
サロゲート・キー |
|
自然キー |
ビジネス・キーまたはソース・キー(時間との組合せで一意になる) |
自然キー |
|
開始タイムスタンプ |
時間レコードの有効開始日 |
開始タイムスタンプ |
|
終了タイムスタンプ |
時間レコードの有効終了日 |
終了タイムスタンプ |
|
現行フラグ |
レコードが最新の有効日かどうか |
現行フラグ |
|
タイプ2列 |
タイプ2列のいずれかに変更がある場合は、レコードの新しいバージョンを作成(挿入)します |
変更時に挿入 |
|
更新履歴列 |
常に現行レコードからの値に設定されます |
変更時に上書き |
システム列ではありません |
その他のシステム列 |
挿入/更新として保持されます |
変更時に上書き |
システム列 |
変更列 |
該当する列に変更がない場合はレコードが拒否されます |
変更時に上書き |
変更列およびシステム列 |
SCD1キー |
ウェアハウスで生成された自然キーに対応するキー |
変更時に上書き |
SCD1 WID(列フレックスフィールド) |
遅延変更ディメンションの機能
タイプ2の変更: #TYPE2_FLG変数がオフ(「N」に設定)の場合、ディメンションはタイプ1ディメンションのように動作します。開始日/終了日のメンテナンスは実行されないため、自然キーは一意にする必要があります(履歴は使用不可)。#TYPE2_FLGがオン(「Y」に設定)の場合、新しいレコードは挿入されます。少なくとも1つのタイプ2列を更新する変更も挿入をトリガーします(いくつかの制限がある)。また、それ以外の変更は、既存のレコードを更新します。
タイプ2の変更は、次のようにトリガーされます。
- 入力レコードには、現在のディメンション・レコードと比較した場合に、相違があるタイプ2列が少なくとも1列含まれている必要があります。
- 新しいタイプ2レコードの開始タイムスタンプは、次のように計算されます。日付値がNull以外の変更列がある場合、その値を使用します(Oracle BI Applicationsの標準では、変更列としてCHANGED_ON_DTを使用します)。それ以外の場合は、現在のタイムスタンプ(sysdate)を使用します。
すべての履歴の更新: #TYPE2_FLGと#UPDATE_ALL_HISTORYの両方がオン(「Y」に設定)の場合、すべての更新履歴列は、現行バージョンのレコード(同一の自然キーを持つ最新のレコード)からの値で更新されます。
機能のオプション
未指定のレコード: ターゲット表がディメンションの場合は、これをTRUEに設定して、未指定のレコードを自動的に挿入します。その他のディメンション・レコードが一致しない場合、これがファクトによって参照されます。デフォルトの列値は、ユーザー定義関数GET_UNSPEC_VALUEを使用して、モデルの命名標準で決定されます。
SCD1キー: TRUEに設定すると、サロゲート自然キーまたはタイプ1キーが自動的に保持されます。これは、標準パターンに従って命名されたタイプ1表を使用して管理されます。ディメンション表がW_DIMENSION_Dの場合、タイプ1表はW_DIMENSION_T1_Dになります。タイプ1キーの生成シーケンスも標準パターンに従って命名されます。前述の例に従うと、W_DIMENSION_D_S1Wという名前になります。同じ単位(タイプ1)の追加列がUD1フラグでマークされている場合は、タイプ1表で自動的に保持できます。
W_DIMENSION_Dの前提条件は次のとおりです。
タイプ1キー列は、モデル内のSCD1 WIDフレックスフィールドで識別される必要があります。
タイプ1キー列は、ソースまたはステージングで定数値(例: 0)にマップされる必要があります。
タイプ1キー列は、挿入専用にする必要があります。
タイプ1表(W_DIMENSION_T1_D)には、少なくとも次の列を含める必要があります。
- タイプ1キー列
- 自然キー列
- システム列W_INSERT_DT、W_UPDATE_DTおよびETL_PROC_WID
- UD1としてマークされた列
タイプ1表(W_DIMENSION_T1_D)には、タイプ1キー列と自然キー列に対する索引を含める必要があります。
タイプ1キーのシーケンスを作成する必要があります(W_DIMENSION_D_S1W)。タイプ1キーのシーケンスを作成する必要があります(W_DIMENSION_D_S1W)。
間隔の補填: TRUEに設定すると、以前の日付をカバーするように最初のレコードが自動的に拡張されます。
ソフト削除。ソフト削除オプションを有効にすると、いくつかの追加ステップを実行できます。#SOFT_DELETE_FEATURE_ENABLED(グローバル)および#SOFT_DELETE_PREPROCESS(ファクトまたはディメンション・グループごとに設定可能)変数により、どのステップを実行するかを正確に制御できます。
ソース・システムでの削除を効率的にキャプチャするトリガーが実装可能な場合は、負荷の高い前処理のステップ(全ソース・レコードを抽出して、それを全ターゲット・レコードと比較する)を無効にして、そのかわりに削除表への直接移入を行うことができます。
ステップ | アクション | 制御 |
---|---|---|
ソフト削除の前処理 |
「削除識別」ステップを実行します。このステップは、プライマリ抽出表とターゲット表のデータを比較して、廃止されたターゲット行を削除表に記録します。
|
#SOFT_DELETE_FEATURE_ENABLED #SOFT_DELETE_PREPROCESS |
ターゲットのソフト削除 |
「ソフト削除」ステップを実行します。このステップは、削除対象として識別されたレコードについて、ターゲット表のDELETE_FLG列を「Y」に更新します。 |
#SOFT_DELETE_FEATURE_ENABLED |
削除表の切捨て |
処理が終了したレコードを削除表から削除します。 |
#SOFT_DELETE_FEATURE_ENABLED |
これらのステップはすべて、ターゲット表へのその他の挿入および更新とともに、まとめてコミットされる点に注意してください。これにより、データ・ウェアハウスの一貫性が保たれます。
このオプションを使用するための前提条件は次のとおりです。
ターゲット表には、ETL_PROC_WIDおよびW_UPDATE_DTシステム列が必要です。
<target>_PEおよび<target>_DEL表は、インタフェース・キーの列で作成する必要があります。
ターゲット表にCREATED_ON_DT列が含まれていない場合は、#LAST_ARCHIVE_DATEをNULLにする必要があります。
#SOFT_DELETE_PREPROCESSは、Oracle BI Applications構成マネージャから、ロード・プラン・コンポーネント単位でリフレッシュする必要があります。
パフォーマンス・チューニングのオプション
検出戦略: 変更が発生していない表の更新を避けるために、入力データが変更列のセットの既存レコードと比較されます。これはモデル列フレックスフィールド(OBI_CHANGE_COLUMN)で定義されます。そうでない場合は、すべての列が比較されます。常に変更を処理する場合は、このオプションを無効にできます。
「ヒント」および「全履歴」: このIKMを使用すると、生成されたSQLにヒントを渡せます。詳細は、My Oracle SupportのOracle Business Intelligence Applicationsリリース11.1.1.7.1のパフォーマンス推奨事項(Doc ID 1539322.1)の記事を参照してください。
ALTER SESSIONリスト: KMで使用されるセッションに、ALTER SESSIONコマンドのリストを適用します。コマンド間はセミコロンで区切ります。接頭辞ALTER SESSIONは付けません。コマンドをソース接続で実行するか(LKMを使用する場合)、またはターゲット接続で実行するかによって、各コマンドに接頭辞SRCまたはTGTを付ける必要があります。次に例を示します。
SRC set TRACEFILE_IDENTIFIER='ODI_TRACE'; SRC set events '10046 TRACE NAME CONTEXT FOREVER, LEVEL 8'; TGT set TRACEFILE_IDENTIFIER='ODI_TRACE_TGT';
ターゲットの分析: KMオプションのANALYZE_TARGETがTrueに設定されている場合、ロード前のターゲット表に関する統計が収集されます。デフォルトでは、Falseに設定されています。
ターゲット表に対して実行するカスタムSQL文を指定できるという点で、これは特異なIKMであるといえます。このSQL文は、インタフェースから返されたソース・レコードごとに1回実行されます。このSQL文の特定の実行に対して、ソース・レコードからの値をパラメータとしてSQLで参照できます。
このIKMのユース・ケースは多岐に亘りますが、そのインタフェースは、ODIインタフェースの標準的な方法に従って実装されていないため、カスタマイズされることのないシステム定義ロジックの実装用にのみ使用してください。
カスタムSQLがすべてのターゲット・テクノロジには適合しない場合、そのかわりにプラットフォーム固有のSQL文を指定できます。このIKMは、実行時にターゲット・テクノロジに対応するオプションでSQLを実行します(使用可能な場合)。それ以外の場合は、汎用オプションのSQLが使用されます。
前提条件
このIKMを使用するための前提条件は次のとおりです。
カスタマイズできないシステム・ロジックを実装してください。
パフォーマンスや互換性などの問題が原因で、汎用のSQLオーバーライドが特定のプラットフォームに適合しない場合は、プラットフォーム固有のSQLオーバーライド・オプションを指定する必要があります。
SQL文は、INSERT、UPDATEまたはDELETEキーワードで始まる必要があります。
SQLに、ヒントのプレースホルダが含まれていることを確認する必要があります。
必要な索引がすべて用意されていることを確認する必要があります。
ソース・データの参照
SQLオーバーライドでソース・データからのデータを使用するには、次の操作を行います。
参照対象のソース・データを、インタフェース上のいずれかのターゲット列にマップします。
SQLオーバーライドで、TARGET_COLUMN構文を使用して参照します。
機能のオプション
SQLオーバーライドのオプション: 汎用のSQLオーバーライド・オプションが使用できます。また、各種ターゲット・テクノロジの構文やパフォーマンスが異なる場合に備えて、プラットフォーム固有のオプションも用意されています。このオプションを使用するための前提条件は次のとおりです。
SQL文は、INSERT、UPDATEまたはDELETEキーワードで始めます。
パフォーマンスや互換性などの問題が原因で、汎用のSQLオーバーライドが特定のプラットフォームに適合しない場合は、プラットフォーム固有のSQLオーバーライド・オプションを指定する必要があります。
パフォーマンス・チューニングのオプション
ヒント: このIKMを使用すると、生成されたSQLにヒントを渡せます。詳細は、My Oracle SupportのOracle Business Intelligence Applicationsリリース11.1.1.7.1のパフォーマンス推奨事項(Doc ID 1539322.1)の記事を参照してください。
ALTER SESSIONリスト: KMで使用されるセッションに、ALTER SESSIONコマンドのリストを適用します。コマンド間はセミコロンで区切ります。接頭辞ALTER SESSIONは付けません。コマンドをソース接続で実行するか(LKMを使用する場合)、またはターゲット接続で実行するかによって、各コマンドに接頭辞SRCまたはTGTを付ける必要があります。次に例を示します。
SRC set TRACEFILE_IDENTIFIER='ODI_TRACE'; SRC set events '10046 TRACE NAME CONTEXT FOREVER, LEVEL 8'; TGT set TRACEFILE_IDENTIFIER='ODI_TRACE_TGT';
ネストされたインタフェースまたは一時インタフェースでこのIKMを使用することで、ネストされたSQLブロック用の生成されたSQLで追加の機能を提供できます。主な利点として、ヒントが追加できるようになることがあげられます。また、一部のアプリケーションでは、「ルックアップの集約」と「ソースSQLのオーバーライド」の機能が役立つこともあります。
機能のオプション
ルックアップの集約: ユーザー・フレックスフィールドを使用して、SQLブロックを集約します。このフレックスフィールドでは、レコードのグループ化を定義することで、グループごとの出力が1行に制限されるようにします。
このオプションを使用するための前提条件は次のとおりです。
インタフェースでは、次のユーザー・フレックスフィールドを設定する必要があります。
- UD1: GROUP BY列。通常、この列が結合の対象になります。
- UD2: 集約列。返されるフィールドです。
- UD3: アクティブ・ルックアップ(LKP_ACTIVE)の列。これは、1に設定されます。
ソースSQLのオーバーライド: 生成済のネストされたSQLブロックをオーバーライドできるようにします。これは、SQLをより動的なものにする必要がある場合に役立ちます(動的な表の参照に変数を使用する場合など)。
このオプションを使用するための前提条件は次のとおりです。
ターゲット・インタフェース列ごとに、同じ別名の列がSQLオーバーライドのSELECT句に存在している必要があります。
このオプションの使用はお薦めしません。実装前に、Oracle BI Applications標準化グループが、そのユース・ケースをレビューするようにしてください。
パフォーマンス・チューニングのオプション
ヒント: このIKMを使用すると、生成されたSQLにヒントを渡せます。詳細は、My Oracle SupportのOracle Business Intelligence Applicationsリリース11.1.1.7.1のパフォーマンス推奨事項(Doc ID 1539322.1)の記事を参照してください。
メイン・インタフェースの一部として、このIKMをイベント・キュー制御の更新で使用する際には、ネストされたインタフェースまたは一時インタフェースでもこのIKMを使用することで、ネストされたSQLブロック用の生成されたSQLで追加の機能を提供できます。主な利点として、増分ロードではイベント・キュー表を駆動表として使用しながらも、フル・ロードではイベント・キュー表全体を除外できることがあげられます。また、ヒントの使用もサポートされています。
ネストされたKMを使用する場合の前提条件
メイン・インタフェースでは、このKMを使用する必要があります。
イベント・キュー表は、「イベント・キュー表」オプションで指定する必要があります。
インタフェースには、次のもののみを含める必要があります。
メイン・ソース表
イベント・キュー表
これらの間の結合(ANSI構文を使用)
イベント・キュー列のマッピング
ある場合、親インタフェースでのイベント・キュー列の参照が必要になります。この列がUD1フレックスフィールドで識別されているときは、ネストされたインタフェースで直接マップできます。これにより、生成されたSQLブロックにその列が含められます(増分ロードでイベント・キュー表も含まれている場合)。フル・ロードの場合は、イベント・キュー表と、その表からマップされた列が除外されます。
機能のオプション
イベント・キュー表: 増分ロードを制御するイベント・キュー表に、明示的に名前を付けます。これは、ネストされたインタフェースの2つのソース表のいずれかにする必要があります。
パフォーマンス・チューニングのオプション
ヒント: このIKMを使用すると、生成されたSQLにヒントを渡せます。詳細は、My Oracle SupportのOracle Business Intelligence Applicationsリリース11.1.1.7.1のパフォーマンス推奨事項(Doc ID 1539322.1)の記事を参照してください。