| Oracle® Fusion Middleware Oracle Data Integrator接続およびナレッジ・モジュール・ガイド 12c (12.2.1.1) E77236-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Data Integrator接続およびナレッジ・モジュール・ガイド 12c (12.2.1.1) E77236-01 |
|
前 |
次 |
この章では、Oracle Data Integratorでのファイルの使用方法について説明します。
この章には次の項が含まれます:
Oracle Data Integratorでは、ASCIIまたはEBCDICのデータを含む固定ファイルまたはデリミタ付きファイルがサポートされます。
ファイル・テクノロジの概念は、Oracle Data Integratorの概念に次のようにマップされます。1つのファイル・サーバーは、Oracle Data Integratorの1つのデータ・サーバーに対応します。このファイル・サーバーで、ファイルが含まれるディレクトリが物理スキーマに対応します。ディレクトリ内のフラット・ファイルのグループがOracle Data Integratorモデルに対応し、この各ファイルがデータストアに対応します。ファイル内のフィールドはデータストアの列に対応します。
Oracle Data Integratorには、ファイル用の組込みドライバが用意されています。また、このドライバを使用し、ファイル・データ・モデルおよびトポロジで宣言されたメタデータを使用してファイルを統合するためのナレッジ・モジュールが用意されています。
ほとんどのテクノロジには、フラット・ファイルと相互作用するための固有の機能(データベース・ローダー、ユーティリティおよび外部表など)も含まれています。テクノロジ固有のナレッジ・モジュールを使用することで、Oracle Data Integratorでもこれらの機能を利用できます。ほとんどの場合において、パフォーマンスの観点から、フラット・ファイルの処理にはデータベース・ユーティリティを使用することをお薦めします。
ファイル・テクノロジは、(固定またはデリミタ付き)フラット・ファイルに関係することに留意してください。XMLファイルの説明は第5章「XMLファイル」に記載されています。
Oracle Data Integratorには、ファイル・ドライバを使用してファイル・データを処理するためのナレッジ・モジュール(KM)が用意されています。この項ではこれらのリストを提供します。
表3-1にリストされているSQL KMは汎用であり、あらゆるデータベース・テクノロジで使用できます。ローダーまたは外部表などの機能を使用するテクノロジ固有のKMは、対応するテクノロジの章にリストされています。
表3-1 SQL KM
| ナレッジ・モジュール | 説明 |
|---|---|
|
LKM File to SQL |
ASCIIファイルまたはEBCDICファイルから、ステージング領域として使用される任意のANSI SQL-92準拠データベースへ、データをロードします。 |
|
IKM SQL to File Append |
任意のANSI SQL-92準拠ステージング領域からターゲット・ファイルに、置換モードでデータを統合します。 |
|
IKM File to File (Java) |
Java処理を使用してソース・ファイルからターゲット・ファイルにデータを統合します。複数のソース・ファイルを取得し、ログおよび不良ファイルを生成できます。詳細は、3.6.2.2項「IKM File to File (Java)」を参照してください。 |
ファイル・テクノロジでの作業を開始する前に、この項の情報を必ず読んでください。
インストールを実行する前に、システム要件および動作要件のドキュメントを読んで、使用する環境がインストールする製品の最低インストール要件を満たすことを確認する必要があります。
サポートされているプラットフォームおよびバージョンのリストには、次のOracle Technical Network (OTN)からアクセスできます。
http://www.oracle.com/technology/products/oracle-data-integrator/index.html
ファイル・データ用の一部のナレッジ・モジュールでは、データベース固有の機能が使用されます。この項では、これらの機能に関連する要件をリストします。
データベース・ユーティリティ
ほとんどのデータベース・テクノロジには、フラット・ファイルと相互作用するための独自のユーティリティがあります。これらのすべてにおいて、ユーティリティを使用するマッピングを実行するエージェントからデータベース・クライアント・ソフトウェアにアクセスできる必要があります。次に例を示します。
Oracle: SQL*Loader
Microsoft SQL Server: bcp
Teradata: FastLoad、MultiLoad、TPump、FastExport
テクノロジ固有のナレッジ・モジュールを使用することで、Oracle Data Integratorでこれらのユーティリティを利用できます。ナレッジ・モジュールの詳細およびデータベース・ユーティリティを使用するための要件は、このガイドのテクノロジ固有の章を参照してください。
IKM File to File (Java)の要件
IKM File to File (Java)では、ソース・ファイルを処理するためのJavaプログラムが生成、コンパイルおよび実行されます。このKMを使用するには、JDKが必要です。
トポロジの設定には次が含まれます。
ファイル・データ・サーバーは、ファイル・フォルダのセットです(それぞれのファイル・フォルダは1つの物理スキーマに対応します)。
Oracle Data Integratorには、デフォルトのFILE_GENERICデータ・サーバーが用意されています。このデータ・サーバーは、ほとんどのニーズに対応します。ほとんどの場合、ファイル・データ・サーバーの作成は不要で、必要なのはFILE_GENERICデータ・サーバーの下に物理スキーマを作成することのみです。
|
注意: JDK 8からは、JDKにJDBC-ODBCブリッジが含まれなくなりました。JDBC-ODBCブリッジは常に過渡的な製品であるとみなされてきました。一部のJDKバンドルのみに提供されていた、JREに含まれないサポート対象外の製品です。JDBC-ODBCブリッジの代わりに、データベースのベンダーが提供するJDBCドライバまたは市販のJDBCドライバを使用してください。 |
『Oracle Data Integratorでの統合プロジェクトの開発』のデータ・サーバーの作成に関する項の説明に従って、標準の手順を使用してファイル・テクノロジ用のデータ・サーバーを作成します。この項では、ファイル・データ・サーバーの定義に関する必須または固有のフィールドのみについて説明します。
「定義」タブ:
名前: Oracle Data Integratorに表示されるデータ・サーバーの名前。
ユーザー/パスワード: これらのフィールドは、ファイル・データ・サーバーでは使用しません。
「JDBC」タブで次の値を入力します。
JDBCドライバ: com.sunopsis.jdbc.driver.file.FileDriver
JDBC URL: jdbc:snps:dbfile?<property=value>&<property=value>&...
URLでは表3-2にリストされているプロパティを使用できます。
表3-2 JDBCファイル・ドライバのプロパティ
| プロパティ | 値 | 説明 |
|---|---|---|
|
DATA_CONTAINS_LINE_SEPARATOR |
|
trueに設定すると、データの読取り時に、レコードに行セパレータとして設定されている文字(または連続する文字)が含まれている場合、それは改行とはみなされず、読み取られる'行サイズ'の文字数に達するまでデータが読み取られます。 |
|
ENCODING |
|
ファイル・エンコーディング。サポートされているエンコーディングのリストは、 |
|
ERR_FILE_PATH |
|
ファイルの場所のパス。このパスはファイル・ドライバによって使用され、データの解析時にドライバによって検出されたエラーは<property value> + .errorに挿入されます。問題の原因となっている行は、<property value> + .badに挿入されます。したがって、問題が発生した場合、実際には2つのファイルが作成されます。 |
|
MULTIBYTES_MODE |
|
|
|
NO_PAD_DEL_NUMERIC |
|
物理的な列の長さを一致させるための、空白による数値(integer、float)の左パディングを制限します。デフォルト値は |
|
TRUNC_FIXED_STRINGS |
|
固定ファイルのフィールド・サイズにあわせて文字列を切り捨てます。デフォルト値は |
|
TRUNC_DEL_STRINGS |
|
デリミタ付きファイルのフィールド・サイズにあわせて文字列を切り捨てます。デフォルト値は |
|
注意: TRUNC_FIXED_STRINGSおよびTRUNC_DEL_STRINGSプロパティは、INSERT文を介してファイル・ドライバにフィードされるデータの処理に影響を及ぼしますが、ファイル・ドライバがバッキング・ファイルから読み取るデータには影響を及ぼしません。 |
JDBC URLの例:
jdbc:snps:dbfile?ENCODING=ISO8859_1&TRUNC_FIXED_STRINGS=FALSE
『Oracle Data Integratorの管理』の物理スキーマの作成に関する項の説明に従って、標準の手順を使用してファイル物理スキーマを作成します。
物理スキーマでは、次のようにディレクトリのペアを設定する必要があります。
ディレクトリ(スキーマ)。Oracle Data Integratorによって、ソースおよびターゲットのファイルの検索、およびソース・ファイルで検出された無効なレコードのエラー・ファイルの作成が行われる場所です。
ディレクトリ(作業スキーマ)。Oracle Data Integratorによって、データ・スキーマ内のソースおよびターゲットに関連する一時ファイルが作成される可能性がある場所です。
|
注意:
|
『Oracle Data Integratorの管理』の論理スキーマの作成に関する項の説明に従って、標準の手順を使用してこの物理スキーマ用の論理スキーマを作成し、特定のコンテキストで関連付けます。
ファイル・データベースを使用してプロジェクトを設定するには、標準の手順に従います。『Oracle Data Integratorでの統合プロジェクトの開発』の統合プロジェクトの作成に関する項を参照してください。
最初は、使用するプロジェクトに次のナレッジ・モジュールをインポートすることをお薦めします。
LKM File to SQL
IKM SQL to File Append
IKM File to File (Java)
これらのナレッジ・モジュール以外に、使用する製品に関連する他のテクノロジ固有のファイル・ナレッジ・モジュールもインポートできます。
この項には次のトピックが含まれます:
ファイル・モデルは、ディレクトリに格納されているファイルに対応するデータストアのセットです。モデルは常に、論理スキーマに基づきます。特定のコンテキストで、論理スキーマは1つの物理スキーマに対応します。この物理スキーマのデータ・スキーマは、モデルで示されるすべてのファイルが(最終的にはサブディレクトリに)含まれているディレクトリです。
『Oracle Data Integratorでの統合プロジェクトの開発』のモデルの作成に関する項の説明に従って、標準の手順を使用してファイル・モデルを作成します。
Oracle Data Integratorでは、特有の方法でファイルをリバース・エンジニアリングできます。ファイル・データベースでサポートされているリバース・エンジニアリングのタイプは次の4つです。
デリミタ付きファイルのリバース・エンジニアリングは、ファイル・データストアごとに実行されます。
ウィザードを使用した固定ファイルのリバース・エンジニアリングは、ファイル・データストアごとに実行されます。
COBOLコピーブックのリバース・エンジニアリングは、そのファイルを記述するコピーブックが提供されている場合に、固定ファイルに使用できます。これはファイル・データストアごとに実行されます。
カスタマイズされたリバース・エンジニアリングは、RKM (リバース・ナレッジ・モデル)を使用して、Microsoft Excelスプレッドシートからあるモデル内の各ファイル・データストアの列定義を取得し、手動入力することなくバッチでファイル・データストアを自動生成します。
|
注意: 組込みファイル・ドライバでは、Oracle Data Integratorモデルのメタデータが使用されます(フィールドのデータ型または長さ、ヘッダー行の数など)。ドライバ固有のタグは、Oracle Data Integratorで生成され、通常のSQLコマンドとともにドライバに渡されます。これらのタグで、ドライバによるファイルの読取りまたは書込み方法が制御されます。同様に、Oracle Data Integratorでデータベース・ローダーおよびユーティリティが使用される場合には、モデル・メタデータを使用して、これらのローダーおよびユーティリティが制御されます。 ファイル定義とファイル・コンテンツの間の矛盾は、実行時の問題の原因となるため、リバース・エンジニアリング・プロセスの後で、ファイル定義に細心の注意を払うことが重要です。 |
デリミタ付きファイルのリバース・エンジニアリングを実行するには、次のようにします。
「モデル」アコーディオンで使用するファイル・モデルを右クリックして、「新規データストア」を選択します。データストア・エディタが開きます。
「定義」タブで次のフィールドに入力します。
名前: このデータストアの名前。
リソース名: サブディレクトリ(必要な場合)およびファイルの名前。フィールドの横の「参照」アイコンを使用してファイルを参照できます。
「ファイル」タブに移動してファイルの詳細を指定します。次のようにフィールドを設定します。
ファイル形式: 区切り
ヘッダー(行数): ヘッダーの行数を入力します。ヘッダーがある場合、ヘッダーの最初の行はOracle Data Integratorによってファイルの列名に使用されます。
「レコード・セパレータ」を選択します。
「フィールド・セパレータ」として使用する文字を選択または入力します。
ファイルで使用されている場合は「テキスト・デリミタ」を入力します。
ファイルに小数点が含まれる場合は「小数点セパレータ」を入力します。
「ファイル」メイン・メニューから「保存」を選択します。
データストア・エディタの「属性」タブに移動します。
エディタ・ツールバーで「リバース・エンジニアリング」をクリックします。
リバース・エンジニアリングされた属性のデータ型および長さを検証します。Oracle Data Integratorでは、ファイルの内容からフィールドのデータ型および長さが推測されますが、このプロセスでデフォルト値(たとえば、文字列フィールドの長さが50)や不正なデータ型が設定されることがあります。
「ファイル」メイン・メニューから「保存」を選択します。
Oracle Data Integratorには、固定ファイルの列をグラフィカルに定義するためのウィザードが用意されています。
このウィザードを使用して固定ファイルをリバース・エンジニアリングするには、次のようにします。
「モデル」アコーディオンで使用するファイル・モデルを右クリックして、「新規データストア」を選択します。データストア・エディタが開きます。
「定義」タブで次のフィールドに入力します。
名前: このデータストアの名前。
リソース名: サブディレクトリ(必要な場合)およびファイルの名前。フィールドの横の「参照」アイコンを使用してファイルを参照できます。
「ファイル」タブに移動してファイルの詳細を指定します。次のようにフィールドを設定します。
ファイル形式: 固定
ヘッダー(行数): ヘッダーの行数を入力します。
「レコード・セパレータ」を選択します。
「ファイル」メイン・メニューから「保存」を選択します。
データストア・エディタの「属性」タブに移動します。
エディタ・ツールバーで、「リバース・エンジニアリング」をクリックします。属性設定ウィザードが起動します。ファイルの最初のレコードが属性設定ウィザードに表示されます。
ルーラー(ファイルの内容の上部)をクリックし、属性を区切るマーカーを作成します。ルーラー内で右クリックすると、マーカーを削除できます。
事前に生成された名前(C1、C2など)を使用して属性が作成されます。属性名を編集するには、属性ヘッダー行(ルーラーの下)をクリックします。
(右側の)プロパティ・パネルで、選択した属性のすべてのパラメータを編集できます。少なくとも、各属性の「属性名」、「データ型」および「長さ」を設定してください。
属性の定義が完了したら「OK」をクリックします。
「ファイル」メイン・メニューから「保存」を選択します。
COBOLコピーブックのリバース・エンジニアリングでは、COBOLコピーブック・ファイルに含まれるレガシー・ファイル構造の説明からレガシー・ファイル構造を取得できます。
COBOLコピーブックを使用して固定ファイルをリバース・エンジニアリングするには、次のようにします。
「モデル」アコーディオンで使用するファイル・モデルを右クリックして、「新規データストア」を選択します。データストア・エディタが開きます。
「定義」タブで次のフィールドに入力します。
名前: このデータストアの名前。
リソース名: サブディレクトリ(必要な場合)およびファイルの名前。フィールドの横の「参照」アイコンを使用してファイルを参照できます。
「ファイル」タブに移動してファイルの詳細を指定します。次のようにフィールドを設定します。
ファイル形式: 固定
ヘッダー(行数): ヘッダーの行数を入力します。
「レコード・セパレータ」を選択します。
「ファイル」メイン・メニューから「保存」を選択します。
データストア・エディタの「属性」タブに移動します。
固定形式のファイル・データストアを作成するか開きます。
データストア・エディタの「属性」タブに移動します。
ツールバー・メニューで「COBOLコピーブックのリバース・エンジニアリング」をクリックします。
「COBOLコピーブックのリバース・エンジニアリング」ダイアログで次のフィールドに入力します。
ファイル: コピーブック・ファイルの場所。
文字セット: コピーブック・ファイルの文字セット。
説明書式: (EBCDIC | ASCII): コピーブック・ファイルの書式。
データ形式: (EBCDIC | ASCII): データ・ファイルの形式。
「OK」をクリックします。
コピーブックに記述されている属性が、リバースエンジニアリングされて属性リストに表示されます。
|
注意: コピーブックで宣言されているデータ型に対応するデータ型がOracle Data Integratorのファイル・テクノロジにない場合、そのデータ型を持つフィールドの属性は、データ型なしで表示されます。 |
このリバース・エンジニアリング手法では、Oracle Data Integratorは、あるモデル内の各ファイル・データストアの列定義が含まれているMicrosoft Excelスプレッドシートを読み込み、バッチでファイル・データストアを生成します。
file_repository.xlsというサンプル・ファイルがODIから提供されており、通常は/demo/excelサブディレクトリにあります。サンプル・ファイルの専用フォーマットに従って、使用するデータストアの情報を入力します。
次の手順は、使用するフラット・ファイルの構造の説明を使用して、このファイルが変更されていることを前提としています。
このファイルは、リバース・エンジニアリングを開始する前にクローズすることをお薦めします。
カスタマイズされたリバース・エンジニアリングを実行するには、次の手順を行います。
Excelスプレッドシート用のODBCデータソースの作成。ファイルの説明を含むExcelスプレッドシートに対応します。
カスタマイズされたリバース・エンジニアリングの実行。RKM File from Excel RKMを使用します。
Excelスプレッドシート用のODBCデータソースの作成
Microsoft ODBCデータソース・アドミニストレータを起動します。
64ビットJRE上で動作しているODIは、64ビットODBCのみと動作することに注意してください。
システムDSN(データ・ソース名)を追加します。
データ・ソース・ドライバとしてMicrosoft Excel Driver (*.xlsや*.xlsxなど)を選択します。
データ・ソースにODI_EXCEL_FILE_REPOという名前を付けて、/demo/excel/file_repository.xlsをデフォルトのワークブックとして選択します。それに応じたドライバのバージョンを間違いなく選択してください。たとえば、.xlsxファイルにはExcel 12.0を選択します。
Microsoft Excelスプレッドシートのデータ・サーバー、物理スキーマおよび論理スキーマの定義
トポロジ・ナビゲータで、次のパラメータを使用してMicrosoft Excelデータ・サーバーを追加します。
名前: EXCEL_FILE_REPOSITORY
JDBCドライバ: Excel用の適切なJDBCドライバを選択します。
JDBC URL: 選択されたJDBCドライバに必要なURLを入力します。
配列フェッチ・サイズ: 0
残りのパラメータにはデフォルト値を使用します。「ファイル」メイン・メニューから「保存」を選択します。
「テスト接続」をクリックして、データ・サーバーが実際のExcelファイルに接続するか確認します。
このデータ・サーバーに物理スキーマを追加します。「定義」タブではデフォルト値をそのまま使用します。
物理スキーマの「コンテキスト」タブで「追加」をクリックします。
新規行でリバース・エンジニアリングに使用するコンテキストを選択し、論理スキーマ列にEXCEL_FILE_REPOSITORYを入力します。この論理スキーマは自動的に生成されます。この名称は変更できないことに注意してください。
「ファイル」メイン・メニューから「保存」を選択します。
カスタマイズされたリバース・エンジニアリングの実行
デザイナ・ナビゲータで、使用するプロジェクトにRKM File (FROM EXCEL)ナレッジ・モジュールをインポートします。
|
注意: インポート時までにEXCEL_FILE_REPOSITORY論理スキーマが生成されない場合には、インポートされたRKMのカスタマイズ状態は「ユーザーが変更済」となります。EXCEL_FILE_REPOSITORYが生成されると、対応するRKMタスクの下にソース・コマンド・スキーマとして表示されます。 |
既存のファイル・モデルを開きます(またはファイル・モデルを新しく生成します)。ファイル・モデルに通常定義するようにパラメータを定義します。テクノロジはMicrosoft Excelではなく、ファイルであることに注意してください。
「リバース・エンジニアリング」タブで次のパラメータを設定します。
「カスタマイズ済」を選択します。
コンテキスト: リバース・コンテキスト
ナレッジ・モジュール: RKM File (FROM EXCEL)
ツールバー・メニューで「リバース・エンジニアリング」をクリックします。
実行ログでリバースエンジニアリング・プロセスを確認できます。
|
注意:
|
ファイルをマッピングのソースまたはターゲットとして使用できますが、ステージング領域としては使用できません。
マッピングまたはチェック用に選択したKMによって、このマッピングまたはチェックの機能およびパフォーマンスが決まります。この項に示す推奨事項は、ファイル・データ・サーバーに関連する様々な状況でのKMの選択に役立ちます。
ファイルをマッピングのソースとして使用できます。「ロード・ナレッジ・モジュール」タブでのステージング領域にファイルをロードするためのLKMの選択は、マッピングのパフォーマンスに関してきわめて重要です。
LKM File to SQLでは、組込みファイル・ドライバを使用して、ファイル・データベースからステージング領域へデータがロードされます。このKM以外に、ステージング領域またはターゲットのテクノロジ固有のKMも使用できます。それらのKMではテクノロジ固有の最適化がサポートされており、ローダーや外部表などが使用されます。
このナレッジ・モジュールでは、組込みドライバに依存する他のKMと同様に、ドライバに添付されている次の2つの機能がサポートされています。
誤ったレコードの処理
Oracle Data Integratorの組込みドライバでは、ファイル・テクノロジに対する列レベルでのエラー処理機能が提供されます。Oracle Data Integratorでは、ファイルのロード時に複数の制御が実行されます。その中の1つでは、ファイルのデータがデータストア定義と一致するかどうかが検証されます。行の1つの値が列の説明と一致しない場合、属性エディタの「制御」タブにある「エラー発生時」オプションでは実行するアクションが定義され、残りの行の検証が続行されます。「エラー発生時」オプションに指定できる値は次のとおりです。
エラーの拒否: エラーを含む行が.BADファイルに移動し、エラーの理由が.ERRORファイルに書き込まれます。
.BADおよび.ERRORファイルは、読み取られるファイルの名前に拡張子.BADおよび.ERRORを使用して、このファイルと同じ場所に保存されます。
エラーの場合はNull(非アクティブ・トレース): エラーを含む行はフロー内に保持され、誤った値がNullに置き換えられます。
エラーの場合はNull(アクティブ・トレース): エラーを含む行はフロー内に維持され、誤った値がNullに置き換えられます。さらに、エラーの理由が.ERRORファイルに書き込まれます。
複数レコード・ファイルのサポート
Oracle Data Integratorでは、複数のレコード書式を含むファイルを処理できます。ファイルには、たとえば注文を表す(5つの列で構成される)レコードおよび注文明細行を表す(データ型の異なる8つの列で構成される)他のレコードが含まれる場合があります。
Oracle Data Integratorでは、特定のレコード書式をそれぞれ異なるデータストアとみなすことで対処します。
例3-1 複数レコード・ファイル
この例では複数レコード・ファイルorders.txtを使用します。これには、注文および注文明細行の2つの異なるレコード・タイプが含まれます。
注文レコードの書式は次のとおりです。
REC_CODE,ORDER_ID,CUSTOMER_ID,ORDER_DATE
注文明細行レコードの書式は次のとおりです。
REC_CODE,ORDER_ID,LINE_ID,PRODUCT_ID,QTY
注文レコードはREC_CODE=ORDで識別されます。
注文明細行レコードはREC_CODE=LINで識別されます。
複数レコード・ファイルをマッピングのソースとして処理するには、次のようにします。
ソース・ファイルを含むディレクトリを指す論理スキーマを使用して、ファイル・モデルを作成します。
フラット・ファイルの異なるレコード書式および構造を識別します。例3-1では、注文および注文明細行の2つのレコード書式を識別できます。
識別した各レコード書式について、次を行います。
レコード・タイプごとに、ファイル・モデル内にデータストアを作成します。
例3-1の場合は2つのデータストアを作成します。
データストア・エディタの「定義」タブで、「名前」フィールドに一意の名前を入力し、「リソース名」フィールドにフラット・ファイルの名前を入力します。リソース名は、このモデルのすべてのデータストアで同じです。
例3-1の場合は、データストアの名前としてORDERSおよびORDER_LINESを使用できます。両方のデータストアの「リソース名」フィールドにorders.txtと入力します。
「ファイル」タブで、使用するフラット・ファイルの形式に応じて「ファイル形式」リストから「固定」または「区切り」を選択し、レコードおよびフィールドのセパレータを指定します。
「属性」タブに、このレコード・タイプの属性定義を入力します。
1つ以上の属性を使用してレコード・タイプを識別できます。レコード・コードは、ファイルで検出される要素を区別する際に使用される、フィールド値の内容です。レコード・コードは一意である必要があり、これにより複数のレコード・パターンを持つファイルの処理が可能になります。「レコード・コード」フィールドでは、複数の値をセミコロン(;)文字で区切って指定できます。
属性エディタで、「レコード・コード」フィールドの各レコード・タイプに対してレコード・コードを割り当てます。
例3-1の場合は、ORDERSデータストアのCODE_REC属性の「レコード・コード」フィールドにORDと入力し、ORDER_LINESデータストアのCODE_REC属性の「レコード・コード」フィールドにLINと入力します。
このように定義することで、ORDERSデータストアからデータを読み取る際に、ファイル・ドライバでは最初の属性に値ORDが含まれているレコードのみがフィルタ処理されます。ORDER_LINESデータストアでも同様です(最初の属性に値LINが含まれているレコードのみが戻されます)。
ファイルをマッピングのソースおよびターゲットとして使用できます。ファイルでのデータ統合戦略は、ステージング領域からファイルへのロードに関係します。「統合ナレッジ・モジュール」タブのIKMの選択によって、統合のパフォーマンスおよび可能性が決まります。
Oracle Data Integratorには、ファイル・データを統合するための2つの統合ナレッジ・モジュールが用意されています。
IKM SQL to File Appendでは、ファイル・ドライバを使用して、ステージング領域からファイル・ターゲットへ切捨て挿入モードでデータを統合します。
このKMのオプションは次のとおりです。
INSERT: マッピングのターゲット・データストアへのデータの挿入を自動的に試行します。
CREATE_TARG_TABLE: ターゲット表を作成します。
TRUNCATE: ターゲット・ファイルの内容を削除し、ターゲット・ファイルが存在しない場合にはファイルを作成します。
GENERATE_HEADER: デリミタ付きファイルのヘッダー行を作成します。
このKM以外に、ステージング領域のテクノロジ固有のIKMも使用できます。それらのKMではテクノロジ固有の最適化がサポートされており、ローダーや外部表などが使用されます。
IKM File to File (Java)は、File-to-Fileユースケースを処理するためのソリューションです。このIKMでは、ファイルを処理するためのJavaプログラムを生成することで統合のパフォーマンスが最適化されます。データストアのリソース名にワイルドカードが含まれる場合、複数のソース・ファイルを処理できます。このプログラムでは、複数のスレッドを使用して変換を実行できます。
IKM File to File (Java)には、ロギングおよびエラー処理のためのKMオプション(BAD_FILE)が用意されています。
このIKMでは、必要に応じてフィールドをテキスト・デリミタで囲むことができる、フラットなデリミタ付きファイルおよび固定ファイルがサポートされています。EBCDICおよびXML形式はサポートされていません。
IKM File to File (Java)の使用
IKM File to File (Java)を使用するには、ステージング領域がファイル・データ・サーバー上に存在する必要があります。これは、新しいマッピングを作成する際のデフォルト構成です。ステージング領域は、ファイル・テクノロジであるターゲット上に配置されます。
IKM File to File (Java)では、マッピングおよびフィルタがサポートされています。マッピングおよびフィルタは常にソースまたはステージング領域上で実行され、ターゲット上で実行されることはありません。マッピング式とフィルタを定義するときに、Java構文を使用します。マッピング式およびフィルタ条件は、改行を含めずに1行で記述する必要があることに注意してください。IKMでは、標準のJavaデータ型(文字列、数値および日付)がサポートされており、これらのデータ型に対してJava変換を使用できます。
次に、マッピング式の例を2つ示します。
FIC.COL1.toLower()
FIC.COL1+FIC.COL2
2番目の例では、COL1およびCOL2が数値の場合、IKMによって両方の数の合計が計算されます。それ以外の場合は、2つの文字列が連結されます。
次に、フィルタ条件の例を2つ示します。
FIC.COL1.equals("ORDER")
(FIC.COL1==FIC.COL2)&&(FIC.COL3 !=None)
次のオブジェクトおよび機能はサポートされていません。
結合
データセット
チェンジ・データ・キャプチャ(CDC)
フロー制御
ルックアップ
複数のファイルの処理
IKM File to File (Java)では、複数のソース・ファイルを処理できます。複数のソース・ファイルを指定するには、データストアのリソース名にワイルドカードを使用します。PROCESSED_FILE_PREFIXおよびPROCESSED_FILE_SUFFIX KMオプションを使用すると、処理後にファイル名を変更することでソース・ファイルを管理できます。
ロギング機能の使用
マッピングの完了後、Oracle Data IntegratorではKMオプションに従って次の出力ファイルが生成されます。
ログ・ファイル: このファイルには、ソース・ファイル、ターゲット・ファイルおよび不良ファイルの名前、主要なKMオプションに設定された値のサマリー、エラー・メッセージ(ある場合)、処理された行に関する統計情報など、ロード・プロセスに関する情報が含まれます。
例3-2 ログ・ファイル
Source File: /xxx/abc.dat Target File: /yyy/data/target_file.dat Bad File: /yyy/log/target_file.bad Header Number to skip: 1 Errors allowed: 3 Insert option: APPEND (could be REPLACE) Thread: 1 ERROR LINE 100: FIELD COL1 IS NOT A DATE ERROR LINE 120: UNEXPECTED ERROR 32056 Rows susccessfully read 2000 Rows not loaded due to data filter 2 Rows not loaded due to data errors 30054 Rows successfully loaded
不良ファイル: このファイルには、処理できなかった各行が記録されます。エラーが発生しなかった場合、不良ファイルは空になります。
KMオプション
このKMのオプションは次のとおりです。
JAVA_HOMEは、JDKのbinディレクトリへのフル・パスを示します。このオプションが設定されていない場合は、ODI Javaホームが使用されます。
APPENDは、Yesに設定されている場合、変換済のデータをターゲット・ファイルに追加します。Noに設定されている場合、ファイルは上書きされます。
DISCARDMAXは、不良ファイルに破棄されるレコードの最大数を示します。破棄されたレコードの数が、このオプションで指定された数を上回る場合、マッピングは失敗します。
|
注意: ロールバックはサポートされていません。挿入されたレコードはそのまま残ります。 |
MAX_NB_THREADSは、データの処理に使用されるパラレル・スレッドの数を示します。
BAD_FILEは不良ファイル名を示します。このオプションが設定されていない場合、不良ファイル名は自動的に生成され、不良ファイルはターゲットの作業スキーマに書き込まれます。
SOURCE_ENCODINGは、ソース・ファイルの文字セット・エンコーディングを示します。デフォルトはマシンのデフォルトのエンコーディングです。
TARGET_ENCODINGは、ターゲット・ファイルの文字セット・エンコーディングを示します。デフォルトはマシンのデフォルトのエンコーディングです。
REMOVE_TEMPORARY_OBJECTSは、Yesに設定されている場合、ログ・ファイルおよび不良ファイルを削除します。
PROCESSED_FILE_PREFIXは、処理後にソース・ファイル名に追加される接頭辞を示します。
PROCESSED_FILE_SUFFIXは、処理後にソース・ファイル名に追加される接尾辞を示します。
