5 ファイル
この章には次の項が含まれます:
概要
Oracle Data Integratorでは、ASCIIまたはEBCDICのデータを含む固定ファイルまたはデリミタ付きファイルがサポートされます。
概念
ファイル・テクノロジの概念は、Oracle Data Integratorの概念に次のようにマップされます。1つのファイル・サーバーは、Oracle Data Integratorの1つのデータ・サーバーに対応します。このファイル・サーバーで、ファイルが含まれるディレクトリが物理スキーマに対応します。ディレクトリ内のフラット・ファイルのグループがOracle Data Integratorモデルに対応し、この各ファイルがデータストアに対応します。ファイル内のフィールドはデータストアの列に対応します。
Oracle Data Integratorには、ファイル用の組込みドライバが用意されています。また、このドライバを使用し、ファイル・データ・モデルおよびトポロジで宣言されたメタデータを使用してファイルを統合するためのナレッジ・モジュールが用意されています。
ほとんどのテクノロジには、フラット・ファイルと相互作用するための固有の機能(データベース・ローダー、ユーティリティおよび外部表など)も含まれています。テクノロジ固有のナレッジ・モジュールを使用することで、Oracle Data Integratorでもこれらの機能を利用できます。ほとんどの場合において、パフォーマンスの観点から、フラット・ファイルの処理にはデータベース・ユーティリティを使用することをお薦めします。
ファイル・テクノロジは、(固定またはデリミタ付き)フラット・ファイルに関係することに留意してください。XMLファイルの説明は「XMLファイル」に記載されています。
ナレッジ・モジュール
Oracle Data Integratorには、ファイル・ドライバを使用してファイル・データを処理するためのナレッジ・モジュール(KM)が用意されています。この項ではこれらのリストを提供します。
表5-1にリストされているSQL KMは汎用であり、あらゆるデータベース・テクノロジで使用できます。ローダーまたは外部表などの機能を使用するテクノロジ固有のKMは、対応するテクノロジの章にリストされています。
表5-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処理を使用してソース・ファイルからターゲット・ファイルにデータを統合します。複数のソース・ファイルを取得し、ログおよび不良ファイルを生成できます。詳細は、IKM File to File (Java)を参照してください。 |
インストールおよび構成
ファイル・テクノロジでの作業を開始する前に、この項の情報を必ず読んでください。
システム要件および動作要件
インストールを実行する前に、システム要件および動作要件のドキュメントを読んで、使用する環境がインストールする製品の最低インストール要件を満たすことを確認する必要があります。
サポートされているプラットフォームおよびバージョンのリストには、次のOracle Technical Network (OTN)からアクセスできます。
http://www.oracle.com/technetwork/middleware/data-integrator/documentation/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が必要です。
サポートされるデータ型
Oracleを対象とするデータ型マッピングは、次のデータ型に対して定義されます。ファイル・テクノロジでサポートされているデータ型は、次のとおりです。
-
ASCII符号付きゾーン10進数 - これは、IBMメインフレームのCOBOLファイルで一般的に使用される数値データ型です。これは、すべての数字が1バイト文字を使用して表され、対応するASCII文字またはEBCDIC文字が各数字に使用されるUSAGE DISPLAY項目です。符号付きゾーン10進数では、正の値と負の値の両方を取ることができます。ZONEDデータ型は、固定幅テキスト・データ・ファイルでのみ有効です。ゾーン10進定数の最大長は、15桁の10進数(15バイト)です。
-
ASCII符号なしゾーン10進数 - 符号なしの10進数はASCII符号付きゾーン10進数によく似ていますが、正の数値のみを表すという点が異なります。ASCIIゾーン10進数形式では、数値の同じ印刷可能な表現が生成されます。1バイトに2つのニブルがあり、それぞれが16進文字で示されます。たとえば、15という値は2バイトで格納されます。最初のバイトには16進値F1が含まれ、2つ目のバイトには16進値C5が含まれます。
注意:
ASCII環境では、符号なしの正の値と符号付きの正の値は、算術的にも物理的にも同等です。 -
バイナリ符号付きビッグ・エンディアン - ビッグ・エンディアンはビッグ・エンド(一連の最上位の値)が最初に(記憶域の最下位のアドレスで)格納される順序です。たとえば、ビッグ・エンディアンのコンピュータでは、16進数4F52に必要な2バイトは、記憶域に4F52として格納されます(たとえば、4Fが記憶域のアドレス1000に格納される場合、52はアドレス1001に格納されます)。符号付きバイナリ・データ型は、正の値と負の値の両方を保持できることを意味します(つまり、8ビットの符号付きバイナリでは、正と負の両方の0から127までの値を保持できます)。
-
バイナリ符号付きリトル・エンディアン - リトル・エンディアンはリトル・エンド(一連の最下位の値)が最初に格納される順序です。たとえば、リトル・エンディアンのコンピュータでは、16進数4F52に必要な2バイトは、524Fとして格納されます(52がアドレス1000、4Fが1001)。符号付きバイナリ・データ型は、正の値と負の値の両方を保持できることを意味します(つまり、8ビットの符号付きバイナリでは、正と負の両方の0から127までの値を保持できます)。
-
バイナリ符号なしビッグ・エンディアン - ビッグ・エンディアンはビッグ・エンド(一連の最上位の値)が最初に(記憶域の最下位のアドレスで)格納される順序です。たとえば、ビッグ・エンディアンのコンピュータでは、16進数4F52に必要な2バイトは、記憶域に4F52として格納されます(たとえば、4Fが記憶域のアドレス1000に格納される場合、52はアドレス1001に格納されます)。符号なしバイナリ・データ型は、バイナリ項目が正の値のみを保持できることを意味します(つまり、8ビットの符号なしバイナリでは、0から255までの値を保持できます)。
-
バイナリ符号なしリトル・エンディアン - リトル・エンディアンはリトル・エンド(一連の最下位の値)が最初に格納される順序です。たとえば、リトル・エンディアンのコンピュータでは、16進数4F52に必要な2バイトは、524Fとして格納されます(52がアドレス1000、4Fが1001)。符号なしバイナリ・データ型は、バイナリ項目が正の値のみを保持できることを意味します(つまり、8ビットの符号なしバイナリでは、0から255までの値を保持できます)。
-
日付 - 国際規格ISO-8601:1988の日付表記YYYYMMDDに基づきます(ここでYYYYは一般的なグレゴリオ暦の年、MMは01 (1月)から12 (12月)までの月、DDは01から31までの値による月の日付を表します)。日付は、次のリストのいずれかの基本データ型で表すことができます。いくつかのデータ型では、必要な最小値は4バイトです。リストには、数値、文字列およびEBCDICが含まれます。
-
EBCDIC - 大規模なIBMコンピュータで使用されるEBCDIC (拡張2進化10進コード)エンコーディングを使用してエンコードされた文字列。EBCDICからASCIIへの再フォーマット中、変換される文字がEBCDIC文字セットではない場合、変換で空白(16進数20)になります。
-
EBCDIC符号付きゾーン10進数 - 符号付きゾーン10進数は、符号を保持するもの(最上位(先行符号)または最下位(後続符号)の数字、通常は最下位の数字)を除く、フィールドのすべての数字については、1バイトで1文字の通常のEBCDIC数字で構成されます。符号を保持する数字では、その数字に数値の符号が結合(オーバーパンチ)されます。これにより、通常であれば符号で使用される1バイトが節約されます。
-
EBCDIC符号なしゾーン10進数 - 符号なしゾーン10進数はEBCDIC符号付きゾーン10進数によく似ていますが、正の数値のみを表すという点が異なります。符号なし(つまり、暗黙的な正数)フィールドでは、各数字は、左端の4ビット(ニブルまたはハーフ・ワード)のゾーン・ビット値と右端の4ビット(ニブルまたはハーフ・ワード)の数字のバイナリ値で表されます。
注意:
EBCDIC環境では、符号なしの正の値と符号付きの正の値は算術的には同等ですが、下位バイトまたは単位の位置(あるいは符号の位置)のため、物理的には異なります。 -
固定EBCDIC - これは、テキスト・データ・ファイルの文字セットに準拠するようにEBCDICとしてエンコードされた、固定長データに空白が埋め込まれた浮動小数点数のテキスト表現です。PACKEDデータ型は、固定幅テキスト・データ・ファイルでのみ有効です。これはパック10進数型です。
-
固定文字列 - 格納されるときに、常に指定した長さまで右に空白が埋め込まれた固定長文字列。Mは文字単位での列の長さを表します。Mの範囲は0から255です。Mが省略された場合の長さは1です。CHAR(0)列には、2つの値(空の文字列またはNULL)を含めることができます。そのような列は、索引の一部にはできません。CONNECTストレージ・エンジンはCHAR(0)をサポートしていません。
注意:
PAD_CHAR_TO_FULL_LENGTH SQLが有効になっていない場合は、CHAR値が取得されるときに末尾の空白が削除されます。 -
数値 - 数値データ型は、正と負の固定小数点数と浮動小数点数、0 (ゼロ)、無限大、および操作の未定義の結果である値(非数値、つまりNAN)を格納します。これはNumberデータ型と浮動小数点数で構成されます。NUMBERデータ型には、固定小数点数および浮動小数点数が格納されます。事実上どんな大きさの数値でも格納可能であり、Oracle Databaseが稼働するシステム間で、最大38桁の精度で移植性が保証されます。
-
符号付きパック10進数 - パック10進定数は、あらゆるタイプの式で使用できます。パック10進定数はP'constantValue'としてコード化されます(ここで、constantValueは1から15桁の10進数の文字列で、オプションでその前にプラス記号(+)かマイナス記号(-)が付けられます)。符号がコード化されない場合、値は正数です。式のコード化を簡素化するために、先頭のPと周囲のアポストロフィを排除してパック10進定数をコード化できます。パック10進定数の最大長は、15桁の10進数(8バイト)です。
-
文字列 - 文字列は、整数や浮動小数点ユニットなど、プログラミングで使用されるデータ型ですが、数値ではなくテキストを表すために使用されます。これは、空白と数値を含めることもできる文字のセットで構成されます。多くの場合、なんらかの文字エンコーディングを使用して、一連の要素(通常は文字)を格納するバイト(単語)の配列として実装されます。文字列は、より一般的な配列またはその他のシーケンス(あるいはリスト)のデータ型および構造を示す場合もあります。文字列はクラス(参照データ型)です。コンパイラには、文字列リテラルから文字列インスタンスへの変換や文字列連結の実行など、文字列に対する特殊なサポートがありますが、文字列はプリミティブ型ではなくクラスです。慣例では、クラス名は大文字で開始します。
-
符号なしパック10進数 - 符号なしパック10進数は、右端の4ビットのニブルに4ビットの符号ではなくパック10進数が含まれることを除いて、パック10進数と同様です。符号なしパック数は、多くの場合、システムから返される特定の日時の値を処理するときに発生します。符号なしパック10進定数は、符号なしパック10進数の値を出力する要件がある場合に、単純な単項式で特に有用です。符号なしパック10進定数は、操作を完了するために常にパック10進数に変換されるため、算術式または関係式で指定しても特にメリットはありません。
トポロジの設定
トポロジの設定には次が含まれます。
ファイル・データ・サーバーの作成
ファイル・データ・サーバーは、ファイル・フォルダのセットです(それぞれのファイル・フォルダは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の管理』の物理スキーマの作成に関する項の説明に従って、標準の手順を使用してファイル物理スキーマを作成します。
物理スキーマでは、次のようにディレクトリのペアを設定する必要があります。
-
ディレクトリ(スキーマ)。Oracle Data Integratorによって、ソースおよびターゲットのファイルの検索、およびソース・ファイルで検出された無効なレコードのエラー・ファイルの作成が行われる場所です。
-
ディレクトリ(作業スキーマ)。Oracle Data Integratorによって、データ・スキーマ内のソースおよびターゲットに関連する一時ファイルが作成される可能性がある場所です。
注意:
-
データ・スキーマおよび作業スキーマは、それぞれ1つのディレクトリに対応します。ファイルにアクセスするコンポーネントから、このディレクトリにアクセスできる必要があります。ディレクトリは、絶対パス(
m:/public/data/files)、またはランタイム・エージェントかStudio起動ディレクトリを基準とした相対パス(../demo/files)のいずれかにできます。実行場所に依存しないパスを使用することをお薦めします。 -
UNIXの場合は特に、これらの両ディレクトリでの読取り/書込み権限がエージェントに必要です。
-
ファイルのパスは、WindowsとUNIXで異なることに注意してください。このディレクトリ情報を設定する際には、エージェントで使用するプラットフォームを考慮してください。
『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には、固定ファイルの列をグラフィカルに定義するためのウィザードが用意されています。
このウィザードを使用して固定ファイルをリバース・エンジニアリングするには、次のようにします。
COBOLコピーブックのリバース・エンジニアリング
COBOLコピーブックのリバース・エンジニアリングでは、COBOLコピーブック・ファイルに含まれるレガシー・ファイル構造の説明からレガシー・ファイル構造を取得できます。
COBOLコピーブックを使用して固定ファイルをリバース・エンジニアリングするには、次のようにします。
コピーブックに記述されている属性が、リバースエンジニアリングされて属性リストに表示されます。
注意:
コピーブックで宣言されているデータ型に対応するデータ型が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を入力します。この論理スキーマは自動的に生成されます。この名称は変更できないことに注意してください。 -
「ファイル」メイン・メニューから「保存」を選択します。
カスタマイズされたリバース・エンジニアリングの実行
注意:
必須Microsoft ExcelスキーマであるEXCEL_FILE_REPOSITORYは、自動的にRKM File (FROM 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では、特定のレコード書式をそれぞれ異なるデータストアとみなすことで対処します。
複数レコード・ファイルをマッピングのソースとして処理するには、次のようにします。
-
ソース・ファイルを含むディレクトリを指す論理スキーマを使用して、ファイル・モデルを作成します。
-
フラット・ファイルの異なるレコード書式および構造を識別します。例5-1では、注文および注文明細行の2つのレコード書式を識別できます。
-
識別した各レコード書式について、次を行います。
-
レコード・タイプごとに、ファイル・モデル内にデータストアを作成します。
例5-1の場合は2つのデータストアを作成します。
-
データストア・エディタの「定義」タブで、「名前」フィールドに一意の名前を入力し、「リソース名」フィールドにフラット・ファイルの名前を入力します。リソース名は、このモデルのすべてのデータストアで同じです。
例5-1の場合は、データストアの名前として
ORDERSおよびORDER_LINESを使用できます。両方のデータストアの「リソース名」フィールドにorders.txtと入力します。 -
「ファイル」タブで、使用するフラット・ファイルの形式に応じて「ファイル形式」リストから「固定」または「区切り」を選択し、レコードおよびフィールドのセパレータを指定します。
-
「属性」タブに、このレコード・タイプの属性定義を入力します。
-
1つ以上の属性を使用してレコード・タイプを識別できます。レコード・コードは、ファイルで検出される要素を区別する際に使用される、フィールド値の内容です。レコード・コードは一意である必要があり、これにより複数のレコード・パターンを持つファイルの処理が可能になります。「レコード・コード」フィールドでは、複数の値をセミコロン(;)文字で区切って指定できます。
属性エディタで、「レコード・コード」フィールドの各レコード・タイプに対してレコード・コードを割り当てます。
例5-1の場合は、ORDERSデータストアのCODE_REC属性の「レコード・コード」フィールドに
ORDと入力し、ORDER_LINESデータストアのCODE_REC属性の「レコード・コード」フィールドにLINと入力します。
-
このように定義することで、ORDERSデータストアからデータを読み取る際に、ファイル・ドライバでは最初の属性に値ORDが含まれているレコードのみがフィルタ処理されます。ORDER_LINESデータストアでも同様です(最初の属性に値LINが含まれているレコードのみが戻されます)。
例5-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で識別されます。
ファイルへのデータの統合
ファイルをマッピングのソースおよびターゲットとして使用できます。ファイルでのデータ統合戦略は、ステージング領域からファイルへのロードに関係します。「統合ナレッジ・モジュール」タブのIKMの選択によって、統合のパフォーマンスおよび可能性が決まります。
Oracle Data Integratorには、ファイル・データを統合するための2つの統合ナレッジ・モジュールが用意されています。
IKM SQL to File Append
IKM SQL to File Appendでは、ファイル・ドライバを使用して、ステージング領域からファイル・ターゲットへ切捨て挿入モードでデータを統合します。
このKMのオプションは次のとおりです。
-
INSERT: マッピングのターゲット・データストアへのデータの挿入を自動的に試行します。
-
CREATE_TARG_TABLE: ターゲット表を作成します。
-
TRUNCATE: ターゲット・ファイルの内容を削除し、ターゲット・ファイルが存在しない場合にはファイルを作成します。
-
GENERATE_HEADER: デリミタ付きファイルのヘッダー行を作成します。
このKM以外に、ステージング領域のテクノロジ固有のIKMも使用できます。それらのKMではテクノロジ固有の最適化がサポートされており、ローダーや外部表などが使用されます。
IKM File to File (Java)
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オプションに設定された値のサマリー、エラー・メッセージ(ある場合)、処理された行に関する統計情報など、ロード・プロセスに関する情報が含まれます。
-
不良ファイル: このファイルには、処理できなかった各行が記録されます。エラーが発生しなかった場合、不良ファイルは空になります。
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は、処理後にソース・ファイル名に追加される接尾辞を示します。
例5-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