| Oracle® Fusion Middleware Oracle Data Integratorナレッジ・モジュール開発者ガイド 12c (12.1.2) E49826-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Data Integratorナレッジ・モジュール開発者ガイド 12c (12.1.2) E49826-02 |
|
前 |
次 |
この章では、データを戦略領域にロードするために使用するロード戦略について説明します。これらの戦略はロード・ナレッジ・モジュールに実装されます。
この章では、次の項目について説明します。
ロード・プロセスは、ソース・データを戦略領域にロードする必要がある場合に必要になります。このロードは、ステージング領域で変換が行われ、ソース・スキーマがステージング領域と同じサーバーに配置されない場合に必要になります。ステージング領域は、ロード・フェーズのターゲットです。
一般的なロード・プロセスは、次のように機能します。
一時的なロード表が削除され(存在する場合)、ステージング領域に作成されます。
データは、ロード・メソッドloading methodを使用して、ソースからこのロード表にロードされます。
アクション1と2が、ステージング領域に移動する必要があるすべてのソース・データに対して繰り返されます。
データは統合フェーズで使用され、統合表にロードされます。
統合フェーズの後で、マッピングが完了する前に、一時的なロード表が削除されます。
ロード・プロセスはステージング領域にロード表を作成します。このロード表は一般的には接頭辞C$が付けられます。
ロード表はソース・データストアではなく実行ユニットを表しています。ソース・データストアとロード表との間には直接のマッピングはありません。実行ユニットはマッピング・エディタの物理ダイアグラムに表示されます。
次のケースは、実行ユニットの概念を示しています。
ソースのCUSTOMER表に、マッピングに使用されるCUST_NAMEとCUST_IDの2つの属性のみがあり、ステージング領域に結合がある場合、ロード表にはこれらの2つの属性のイメージのみが含まれます。統合フローに必要ない残りの属性は、ロード表には表示されません。
CUSTOMER表がソース上でCUST_AGEでフィルタされると、CUST_AGEはその後使用されず、ロード表にはCUST_AGEは含まれません。ロード・プロセスはフィルタ処理をソース・データ・サーバーで行い、ロード表にはフィルタされたレコードを含めません。
CUSTOMERとSALES_REPSの2つの表を、ソース上で結合を使用して結合すると、結果として作成される実行ユニットがステージング領域で行われる変換に使用されます。ロード表にはCUSTOMERとSALES_REPSから結合された属性が含まれます。
ソース・データストアのすべての属性がマップされ、このデータストアがソース上で結合されない場合、実行ユニットがソース・データストア全体になります。この場合、ロード表はソース・データストアの正確なイメージです。これはファイルなどの転送機能のないソース・テクノロジの場合です。
ロード・メソッドは、データをソースからステージング領域にロードする際に最適なパフォーマンスを得るために重要です。複数のロード・メソッドがあり、次のカテゴリに分類できます。
実行エージェントは、ソース・サーバー上でJDBCを使用して結果セットを読み取り、JDBCを使用してこの結果セットをステージング領域のロード表に書き込むことができます。このメソッドを使用するには、ナレッジ・モジュールに、ソース上にSELECTとターゲット上に対応するINSERTのコマンドが含まれている必要があります。
このメソッドでは、配列フェッチ機能を使用してデータが配列の行ごとに読み取られ、バッチ更新機能を使用して行ごとに書き込まれるため、大量のデータには適していません。
マッピングにフラット・ファイルがソースとして含まれている場合、ファイルに組込みのODIドライバを使用する標準のLKM File to SQLではなく、ステージング領域のテクノロジに最も効率的なロード・ユーティリティを利用する戦略を使用できます。ほとんどのRDBMSには、OracleのSQL*Loader、 Microsoft SQL Serverのbcp、TeradataのFastLoad、MultiLoadなど、フラット・ファイルを表にロードするための高速なロード・ユーティリティが装備されています。
LKMでは、ソース・ファイルはステージング領域にロードされ、その後すべての変換がステージング領域で実行されます。
ロード・ユーティリティを使用する一般的なLKMでは、次の手順が行われます。
ステージング領域でロード表を削除し、作成します。
ロード表にファイルをロードするために、ローディング・ユーティリティによって要求されるスクリプトを生成します。
適切なオペレーティング・システム・コマンドを実行してロードを開始し、リターン・コードをチェックします。
ユーティリティによってログ・ファイルが作成された場合は、このファイルをエラー処理のために分析します。
統合フェーズが終了したら、ロード表を削除します。
ソースの結果セットがリモート・データベース・サーバー上にある場合、エージェントを使用してデータを転送するかわりに、データをファイルにアンロードしてからそのファイルをステージング領域にロードする方法があります。
通常、様々なテクノロジに渡る大量のデータを処理する場合には、この方法が最も効率的です。たとえば、Microsoft SQL Serverソースからbcpを使用してデータをアンロードし、そのデータをSQL*Loaderを使用してOracleのステージング領域にロードできます。
この戦略に従うLKMの手順は、次のようになります。
ステージング領域でロード表を削除し、作成します。
ソース・データベース・アンロード・ユーティリティ(Microsoft SQL ServerのbcpやDB2アンロードなど)または組込みのOdiSqlUnloadツールを使用して、ソースから 一時フラット・ファイルへデータをアンロードします。
ロード表に一時ファイルをロードするために、ロード・ユーティリティによって要求されるスクリプトを生成します。
適切なオペレーティング・システム・コマンドを実行してロードを開始し、リターン・コードをチェックします。
ユーティリティによってログ・ファイルが作成された場合は、このファイルをエラー処理のために分析します。
統合KMが終了したらロード表を削除し、一時ファイルを削除します。
アンロード/ロード戦略を使用する場合、データを2度ステージングする必要があります。1度目は一時ファイル、2度目はロード表でのステージングです。そのため、ディスク領域が余分に使用され、能率上の問題が発生する可能性があります。より効率的な代替方法は、アンロードおよびロードのユーティリティ間でパイプラインを使用することです。あいにく、一部のオペレーティング・システムではファイルベースのパイプライン(FIFO)がサポートされていません。
一部のRDBMSには、サーバー間でデータを転送するためのメカニズムが装備されています。たとえば、次のようなメカニズムがあります。
Oracle: データベース・リンク
Microsoft SQL Server: リンク・サーバー
IBM DB2 400: DRDAファイル転送
その他のデータベースには、Oracleの外部表機能など、ファイルを表にロードするための特別なメカニズムが実装されています。
これらのロード戦略は、適切なオブジェクト(ビュー、データベース・リンクなど)を作成し、その機能を使用するための適切なコマンドを実装する特定のKMに実装されています。
この項では、ロード戦略の例を示します。
LKM SQL to SQLは、エージェントを使用したロード・フェーズの一般的な例です。
後述のコマンドはこのKMからの抜粋で、例として示します。このナレッジ・モジュールのコードは、Oracle Data Integrator Studioで編集して確認できます。
このタスクは、ロード表を削除します。このコマンドは常に実行され、「エラーの無視」フラグは有効化されます。ロード表が見つからない場合でもLKMは停止されません。
ターゲットに対するコマンド
drop table <%=snpRef.getTable("L", "COLL_NAME", "A")%>
このタスクは、ロード表を削除します。このコマンドは常に実行されます。
ロード表の名前を返すgetTableメソッドのCOLL_NAMEプロパティを使用することに注意してください。
ターゲットに対するコマンド
create table <%=snpRef.getTable("L", "COLL_NAME", "A")%>( <%=snpRef.getColList("", "[CX_COL_NAME]\t[DEST_WRI_DT] " + snpRef.getInfo("DEST_DDL_NULL"), ",\n\t", "","")%>)
このタスクはソース接続にデータを読み込み、それをロード表にロードします。このコマンドは常に実行されます。
|
注意: ODI一時表には回復不可能なデータは含まれていないため、ロード・フェーズでは常に自動コミットが使用されます。 |
ソースに対するコマンド
getFilter、getJoin、getFromなどのメソッドの使用に注目してください。これらのメソッドは内容に応じた式を返すショートカットです。たとえば、getFilterはソース上で実行されるすべてのフィルタ式を返します。また、getColListのEXPRESSIONプロパティを使用することにも注意してください。これはソース属性とソース上で実行される式を返します。これらの式およびソース属性は、ロード表内の対応する属性名であるCX_COL_NAMEに応じた別名です。
このselect文は、ソース・エンジンにより正しい変換(マッピング、結合、フィルタなど)が行われるようにします。
select <%=snpRef.getPop("DISTINCT_ROWS")%> <%=snpRef.getColList("", "[EXPRESSION]\t[ALIAS_SEP] [CX_COL_NAME]", ",\n\t", "", "")%>from <%=snpRef.getFrom()%>where (1=1)<%=snpRef.getFilter()%><%=snpRef.getJrnFilter()%><%=snpRef.getJoin()%><%=snpRef.getGrpBy()%><%=snpRef.getHaving()%>
ターゲットに対するコマンド
ここでは:[CX_COL_NAME]を使用するバインディングに注目してください。CX_COL_NAMEでバインドされた値は、ソース属性の別名に一致します。
insert into <%=snpRef.getTable("L", "COLL_NAME", "A")%>( <%=snpRef.getColList("", "[CX_COL_NAME]", ",\n\t", "","")%>)values( <%=snpRef.getColList("", ":[CX_COL_NAME]", ",\n\t", "","")%>)
