ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Data Integrator接続およびナレッジ・モジュール・ガイド
11g リリース1(11.1.1)
B62261-05
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

3 ファイル

この章では、Oracle Data Integratorでのファイルの使用方法について説明します。

この章には次の項が含まれます:

3.1 概要

Oracle Data Integratorでは、ASCIIまたはEBCDICのデータを含む固定ファイルまたはデリミタ付きファイルがサポートされます。

3.1.1 概念

ファイル・テクノロジの概念は、Oracle Data Integratorの概念に次のようにマップされます。1つのファイル・サーバーは、Oracle Data Integratorの1つのデータ・サーバーに対応します。このファイル・サーバーで、ファイルが含まれるディレクトリが物理スキーマに対応します。ディレクトリ内のフラット・ファイルのグループがOracle Data Integratorモデルに対応し、この各ファイルがデータストアに対応します。ファイル内のフィールドはデータストアの列に対応します。

Oracle Data Integratorには、ファイル用の組込みドライバが用意されています。また、このドライバを使用し、ファイル・データ・モデルおよびトポロジで宣言されたメタデータを使用してファイルを統合するためのナレッジ・モジュールが用意されています。

ほとんどのテクノロジには、フラット・ファイルと相互作用するための固有の機能(データベース・ローダー、ユーティリティおよび外部表など)も含まれています。テクノロジ固有のナレッジ・モジュールを使用することで、Oracle Data Integratorでもこれらの機能を利用できます。ほとんどの場合において、パフォーマンスの観点から、フラット・ファイルの処理にはデータベース・ユーティリティを使用することをお薦めします。

ファイル・テクノロジは、(固定またはデリミタ付き)フラット・ファイルに関係することに留意してください。XMLファイルの説明は第5章「XMLファイル」に記載されています。

3.1.2 ナレッジ・モジュール

Oracle Data Integratorには、ファイル・ドライバを使用してファイル・データを処理するためのナレッジ・モジュール(KM)が用意されています。この項ではこれらのリストを提供します。

表3-1にリストされているSQL KMは汎用であり、すべてのテクノロジで使用できます。ローダーまたは外部表などの機能を使用するテクノロジ固有のKMは、対応するテクノロジの章にリストされています。

表3-1 ファイルから読み取るためのナレッジ・モジュール

ナレッジ・モジュール 説明

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)」を参照してください。

RKM File (FROM EXCEL)

Microsoft Excelスプレッドシートからファイルのメタデータを取得します。ファイル構造の定義を専用のExcelスプレッドシートで保持する場合は、このKMの使用を検討してください。


3.2 インストールおよび構成

ファイル・テクノロジでの作業を開始する前に、この項の情報を必ず読んでください。

3.2.1 システム要件および動作要件

インストールを実行する前に、システム要件および動作要件のドキュメントを読んで、使用する環境がインストールする製品の最低インストール要件を満たすことを確認する必要があります。

サポートされているプラットフォームおよびバージョンのリストには、次のOracle Technical Network (OTN)からアクセスできます。

http://www.oracle.com/technology/products/oracle-data-integrator/index.html

3.2.2 テクノロジ固有の要件

ファイル・データ用の一部のナレッジ・モジュールでは、データベース固有の機能が使用されます。この項では、これらの機能に関連する要件をリストします。

データベース・ユーティリティ

ほとんどのデータベース・テクノロジには、フラット・ファイルと相互作用するための独自のユーティリティがあります。これらのすべてにおいて、ユーティリティを使用するインタフェースを実行するエージェントからデータベース・クライアント・ソフトウェアにアクセスできる必要があります。次に例を示します。

  • 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が必要です。

3.2.3 接続性要件

この項では、フラット・ファイルに接続するための要件をリストします。

JDBCドライバ

Oracle Data Integratorには、フラット・ファイル用の組込みドライバが含まれています。このドライバはOracle Data Integratorとともにインストールされるもので、追加の構成は不要です。

3.3 トポロジの設定

トポロジの設定には次が含まれます。

  1. ファイル・データ・サーバーの作成

  2. ファイル物理スキーマの作成

3.3.1 ファイル・データ・サーバーの作成

ファイル・データ・サーバーは、ファイル・フォルダのセットです(それぞれのファイル・フォルダは1つの物理スキーマに対応します)。

Oracle Data Integratorには、デフォルトのFILE_GENERICデータ・サーバーが用意されています。このデータ・サーバーは、ほとんどのニーズに対応します。ほとんどの場合、ファイル・データ・サーバーの作成は不要で、必要なのはFILE_GENERICデータ・サーバーの下に物理スキーマを作成することのみです。

3.3.1.1 データ・サーバーの作成

『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のデータ・サーバーの作成に関する項に記載されている標準の手順で、ファイル・テクノロジ用データ・サーバーを作成します。この項では、ファイル・データ・サーバーの定義に関する必須または固有のフィールドのみについて説明します。

  1. 「定義」タブ:

    • 名前: Oracle Data Integratorに表示されるデータ・サーバーの名前。

    • ユーザー/パスワード: これらのフィールドは、ファイル・データ・サーバーでは使用しません。

  2. 「JDBC」タブで次の値を入力します。

    • JDBCドライバ: com.sunopsis.jdbc.driver.file.FileDriver

    • JDBC URL: jdbc:snps:dbfile?<property=value>&<property=value>&...

      URLでは表3-2にリストされているプロパティを使用できます。

      表3-2 JDBCファイル・ドライバのプロパティ

      プロパティ 説明

      ENCODING

      <encoding_code>

      ファイル・エンコーディング。サポートされているエンコーディングのリストは、http://java.sun.com/j2se/1.4.2/docs/guide/intl/encoding.doc.htmlにあります。デフォルトのエンコーディング値はISO8859_1です。

      TRUNC_FIXED_STRINGS

      TRUE|FALSE

      固定ファイルのフィールド・サイズにあわせて文字列を切り捨てます。デフォルト値はFALSEです。

      TRUNC_DEL_STRINGS

      TRUE|FALSE

      デリミタ付きファイルのフィールド・サイズにあわせて文字列を切り捨てます。デフォルト値はFALSEです。

      OPT

      TRUE|FALSE

      パフォーマンス向上のためにマルチプロセッサ・マシンでファイル・アクセスを最適化します。シングル・プロセッサ・マシンでこのオプションを使用すると、実際のパフォーマンスが低下することがあります。デフォルト値はFALSEです。


      JDBC URLの例:

      jdbc:snps:dbfile?ENCODING=ISO8859_1&TRUNC_FIXED_STRINGS=FALSE&OPT=TRUE

3.3.2 ファイル物理スキーマの作成

『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』の物理スキーマの作成に関する項に記載されている標準の手順で、ファイル物理スキーマを作成します。

物理スキーマでは、次のようにディレクトリのペアを設定する必要があります。

  • ディレクトリ(スキーマ)。Oracle Data Integratorによって、ソースおよびターゲットのファイルの検索、およびソース・ファイルで検出された無効なレコードのエラー・ファイルの作成が行われる場所です。

  • ディレクトリ(作業スキーマ)。Oracle Data Integratorによって、データ・スキーマ内のソースおよびターゲットに関連する一時ファイルが作成される可能性がある場所です。


注意:

  • データ・スキーマおよび作業スキーマは、それぞれ1つのディレクトリに対応します。ファイルにアクセスするコンポーネントから、このディレクトリにアクセスできる必要があります。ディレクトリは、絶対パス(m:/public/data/files)、またはランタイム・エージェントかStudio起動ディレクトリを基準とした相対パス(../demo/files)のいずれかにできます。実行場所に依存しないパスを使用することをお薦めします。

  • UNIXの場合は特に、これらの両ディレクトリでの読取り/書込み権限がエージェントに必要です。

  • ファイルのパスは、WindowsとUNIXで異なることに注意してください。このディレクトリ情報を設定する際には、エージェントで使用するプラットフォームを考慮してください。


『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』の論理スキーマの作成に関する項に記載されている標準の手順で、この物理スキーマ用の論理スキーマを作成し、特定のコンテキストで関連付けます。

3.4 統合プロジェクトの設定

ファイル・データベースを使用してプロジェクトを設定するには、標準の手順に従います。『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』の統合プロジェクトの作成に関する項を参照してください。

最初は、使用するプロジェクトに次のナレッジ・モジュールをインポートすることをお薦めします。

これらのナレッジ・モジュール以外に、使用する製品に関連する他のテクノロジ固有のファイル・ナレッジ・モジュールもインポートできます。

3.5 ファイル・モデルの作成およびリバース・エンジニアリング

この項には次のトピックが含まれます:

3.5.1 ファイル・モデルの作成

ファイル・モデルは、ディレクトリに格納されているファイルに対応するデータストアのセットです。モデルは常に、論理スキーマに基づきます。特定のコンテキストで、論理スキーマは1つの物理スキーマに対応します。この物理スキーマのデータ・スキーマは、モデルで示されるすべてのファイルが(最終的にはサブディレクトリに)含まれているディレクトリです。

『Oracle Fusion Middleware Oracle Data Integrator開発者ガイド』のモデルの作成に関する項に記載されている標準の手順で、ファイル・モデルを作成します。

3.5.2 ファイル・モデルのリバース・エンジニアリング

Oracle Data Integratorでは、特有の方法でファイルをリバース・エンジニアリングできます。ファイル・データベースでサポートされているリバース・エンジニアリングのタイプは次の4つです。


注意:

組込みファイル・ドライバでは、Oracle Data Integratorモデルのメタデータが使用されます(フィールドのデータ型または長さ、ヘッダー行の数など)。ドライバ固有のタグは、Oracle Data Integratorで生成され、通常のSQLコマンドとともにドライバに渡されます。これらのタグで、ドライバによるファイルの読取りまたは書込み方法が制御されます。

同様に、Oracle Data Integratorでデータベース・ローダーおよびユーティリティが使用される場合には、モデル・メタデータを使用して、これらのローダーおよびユーティリティが制御されます。

ファイル定義とファイル・コンテンツの間の矛盾は、実行時の問題の原因となるため、リバース・エンジニアリング・プロセスの後で、ファイル定義に細心の注意を払うことが重要です。


3.5.2.1 デリミタ付きファイルのリバース・エンジニアリング

デリミタ付きファイルのリバース・エンジニアリングを実行するには、次のようにします。

  1. 「モデル」アコーディオンで使用するファイル・モデルを右クリックして、「新規データストア」を選択します。データストア・エディタが開きます。

  2. 「定義」タブで次のフィールドに入力します。

    • 名前: このデータストアの名前。

    • リソース名: サブディレクトリ(必要な場合)およびファイルの名前。「...」ボタンを使用してファイルを参照できます。

  3. 「ファイル」タブに移動してファイルの詳細を指定します。次のようにフィールドを設定します。

    • ファイル形式: 区切り

    • ヘッダー(行数): ヘッダーの行数を入力します。ヘッダーがある場合、ヘッダーの最初の行はOracle Data Integratorによってファイルの列名に使用されます。

    • 「レコード・セパレータ」を選択します。

    • 「フィールド・セパレータ」として使用する文字を選択または入力します。

    • ファイルで使用されている場合は「テキスト・デリミタ」を入力します。

    • ファイルに小数点が含まれる場合は「小数点セパレータ」を入力します。

  4. 「ファイル」メイン・メニューから「保存」を選択します。

  5. データストア・エディタの「列」タブに移動します。

  6. エディタ・ツールバーで「リバースエンジニアリング」をクリックします。

  7. リバース・エンジニアリングされた列のデータ型および長さを検証します。Oracle Data Integratorでは、ファイルの内容からフィールドのデータ型および長さが推測されますが、このプロセスでデフォルト値(たとえば、文字列フィールドの長さが50)や不正なデータ型が設定されることがあります。

  8. 「ファイル」メイン・メニューから「保存」を選択します。

3.5.2.2 ウィザードを使用した固定ファイルのリバース・エンジニアリング

Oracle Data Integratorには、固定ファイルの列をグラフィカルに定義するためのウィザードが用意されています。

このウィザードを使用して固定ファイルをリバース・エンジニアリングするには、次のようにします。

  1. 「モデル」アコーディオンで使用するファイル・モデルを右クリックして、「新規データストア」を選択します。データストア・エディタが開きます。

  2. 「定義」タブで次のフィールドに入力します。

    • 名前: このデータストアの名前。

    • リソース名: サブディレクトリ(必要な場合)およびファイルの名前。「...」ボタンを使用してファイルを参照できます。

  3. 「ファイル」タブに移動してファイルの詳細を指定します。次のようにフィールドを設定します。

    • ファイル形式: 固定

    • ヘッダー(行数): ヘッダーの行数を入力します。

    • 「レコード・セパレータ」を選択します。

  4. 「ファイル」メイン・メニューから「保存」を選択します。

  5. データストア・エディタの「列」タブに移動します。

  6. エディタ・ツールバーで、「リバース・エンジニアリング」をクリックします。列設定ウィザードが起動します。ファイルの最初のレコードが列設定ウィザードに表示されます。

  7. (ファイルの内容の上にある)ルーラーをクリックして、列を区切るマーカーを作成します。ルーラー内で右クリックすると、マーカーを削除できます。

  8. 事前生成済の名前(C1、C2など)で列が作成されます。(ルーラーの下にある)列のヘッダー行をクリックすると、列名を編集できます。

  9. (右側の)プロパティ・パネルで、選択した列のすべてのパラメータを編集できます。少なくとも、各列の「列名」、「データ型」および「長さ」を設定する必要があります。

  10. 列の定義が完了したら「OK」をクリックします。

  11. 「ファイル」メイン・メニューから「保存」を選択します。

3.5.2.3 COBOLコピーブックのリバース・エンジニアリング

COBOLコピーブックのリバース・エンジニアリングでは、COBOLコピーブック・ファイルに含まれるレガシー・ファイル構造の説明からレガシー・ファイル構造を取得できます。

COBOLコピーブックを使用して固定ファイルをリバース・エンジニアリングするには、次のようにします。

  1. 「モデル」アコーディオンで使用するファイル・モデルを右クリックして、「新規データストア」を選択します。データストア・エディタが開きます。

  2. 「定義」タブで次のフィールドに入力します。

    • 名前: このデータストアの名前。

    • リソース名: サブディレクトリ(必要な場合)およびファイルの名前。「...」ボタンを使用してファイルを参照できます。

  3. 「ファイル」タブに移動してファイルの詳細を指定します。次のようにフィールドを設定します。

    • ファイル形式: 固定

    • ヘッダー(行数): ヘッダーの行数を入力します。

    • 「レコード・セパレータ」を選択します。

  4. 「ファイル」メイン・メニューから「保存」を選択します。

  5. データストア・エディタの「列」タブに移動します。

  6. 固定形式のファイル・データストアを作成するか開きます。

  7. データストア・エディタの「列」タブに移動します。

  8. ツールバー・メニューで「COBOLコピーブックのリバース・エンジニアリング」をクリックします。

  9. 「COBOLコピーブックのリバース・エンジニアリング」ダイアログで次のフィールドに入力します。

    • ファイル: コピーブック・ファイルの場所。

    • キャラクタ・セット: コピーブック・ファイルのキャラクタ・セット。

    • 説明書式: (EBCDIC | ASCII): コピーブック・ファイルの書式。

    • データ形式: (EBCDIC | ASCII): データ・ファイルの形式。

  10. 「OK」をクリックします。

コピーブックで説明されている列がリバース・エンジニアリングされ、列リストに表示されます。


注意:

コピーブックで宣言されているデータ型に対応するデータ型がOracle Data Integratorのファイル・テクノロジにない場合、そのデータ型を持つフィールドの列は、データ型なしで表示されます。


3.5.2.4 カスタマイズされたリバース・エンジニアリング

このリバース・エンジニアリング方法では、ファイルのグループの説明を含むMicrosoft Excelスプレッドシートが使用されます。このファイルには特定の書式が使用されます。サンプル・ファイル(file_repository.xls)は、/demo/excelサブディレクトリ内のOracle Data Integratorデモに含まれています。

次の手順は、使用するフラット・ファイルの構造の説明を使用して、このファイルが変更されていることを前提としています。

カスタマイズされたリバース・エンジニアリングを実行するには、次の手順を行います。

  1. Excelスプレッドシート用のODBCデータソースの作成。ファイルの説明を含むExcelスプレッドシートに対応します。

  2. Microsoft Excelスプレッドシートのデータ・サーバー、物理スキーマおよび論理スキーマの定義

  3. カスタマイズされたリバース・エンジニアリングの実行。RKM File from Excel RKMを使用します。

Excelスプレッドシート用のODBCデータソースの作成

  1. Microsoft ODBCデータソース・アドミニストレータを起動します。

  2. システム・データソースを追加します。

  3. 「Microsoft Excel Driver(*.xls)」ドライバを選択します。

  4. データソースにODI_EXCEL_FILE_REPOという名前を付けて、ファイル/demo/excel/file_repository.xlsを選択します。

Microsoft Excelスプレッドシートのデータ・サーバー、物理スキーマおよび論理スキーマの定義

  1. トポロジ・ナビゲータで、次のパラメータを使用してMicrosoft Excelデータ・サーバーを追加します。

    • 名前: EXCEL_FILE_REPOSITORY

    • JDBCドライバ: sun.jdbc.odbc.JdbcOdbcDriver

    • JDBC URL: jdbc:odbc:ODI_EXCEL_FILE_REPO

  2. 「ファイル」メイン・メニューから「保存」を選択します。

  3. このデータ・サーバーに物理スキーマを追加します。「定義」タブではデフォルト値をそのまま使用します。

  1. 物理スキーマの「コンテキスト」タブで「追加」をクリックします。

  2. 新規行でリバース・エンジニアリングに使用するコンテキストを選択し、論理スキーマ列にEXCEL_FILE_REPOSITORYを入力します。この名前は必須です。

  3. 「ファイル」メイン・メニューから「保存」を選択します。

カスタマイズされたリバース・エンジニアリングの実行

  1. デザイナ・ナビゲータで、使用するプロジェクトにRKM File From Excelナレッジ・モジュールをインポートします。

  2. 「モデル」アコーディオンでファイル・モデルをダブルクリックします。モデル・エディタが開きます。

  3. 「リバース・エンジニアリング」タブで次のパラメータを設定します。

    • 「カスタマイズ済」を選択します。

    • コンテキスト: リバース・コンテキスト

    • ナレッジ・モジュール: RKM File from Excel

  4. ツールバー・メニューで「リバースエンジニアリング」をクリックします。

  5. 実行ログでリバースエンジニアリング・プロセスを確認できます。


注意:

  • Microsoft Excelの論理スキーマを定義する必要があります。EXCEL_FILE_REPOSITORYという名前を付け、ファイルfile_repository.xlsまたは構造が類似する別のファイルを指すように設定する必要があります。

  • Microsoft Excelファイルfile_repository.xlsは、リバース・エンジニアリングを実行する前に閉じておく必要があります。


3.6 インタフェースの設計

ファイルは、統合インタフェースのソースまたはターゲットとして使用できますが、ステージング領域としては使用できません

インタフェースまたはチェック用に選択したKMによって、このインタフェースまたはチェックの機能およびパフォーマンスが決まります。この項に示す推奨事項は、ファイル・データ・サーバーに関連する様々な状況でのKMの選択に役立ちます。

3.6.1 ファイルからのデータのロード

ファイルはインタフェースのソースとして使用できます。インタフェース・フロー・タブでのステージング領域にファイルをロードするためのLKMの選択は、インタフェースのパフォーマンスに関してきわめて重要です。

LKM File to SQLでは、組込みファイル・ドライバを使用して、ファイル・データベースからステージング領域へデータがロードされます。このKM以外に、ステージング領域またはターゲットのテクノロジ固有のKMも使用できます。それらのKMではテクノロジ固有の最適化がサポートされており、ローダーや外部表などが使用されます。

このナレッジ・モジュールでは、組込みドライバに依存する他のKMと同様に、ドライバに添付されている次の2つの機能がサポートされています。

誤ったレコードの処理

Oracle Data Integratorの組込みドライバでは、ファイル・テクノロジに対する列レベルでのエラー処理機能が提供されます。Oracle Data Integratorでは、ファイルのロード時に複数の制御が実行されます。その中の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で識別されます。

複数レコード・ファイルを統合インタフェースのソース・インタフェースとして処理するには、次のようにします。

  1. ソース・ファイルを含むディレクトリを指す論理スキーマを使用して、ファイル・モデルを作成します。

  2. フラット・ファイルの異なるレコード書式および構造を識別します。例3-1では、注文および注文明細行の2つのレコード書式を識別できます。

  3. 識別した各レコード書式について、次を行います。

    1. レコード・タイプごとに、ファイル・モデル内にデータストアを作成します。

      例3-1の場合は2つのデータストアを作成します。

    2. データストア・エディタの「定義」タブで、「名前」フィールドに一意の名前を入力し、「リソース名」フィールドにフラット・ファイルの名前を入力します。リソース名は、このモデルのすべてのデータストアで同じです。

      例3-1の場合は、データストアの名前としてORDERSおよびORDER_LINESを使用できます。両方のデータストアの「リソース名」フィールドにorders.txtと入力します。

    3. 「ファイル」タブで、使用するフラット・ファイルの形式に応じて「ファイル形式」リストから「固定」または「区切り」を選択し、レコードおよびフィールドのセパレータを指定します。

    4. 「列」タブで、このレコード・タイプの列定義を入力します。

    5. 1つ以上の列を使用してレコード・タイプを識別できます。レコード・コードは、ファイルで検出される要素を区別する際に使用される、フィールド値の内容です。レコード・コードは一意である必要があり、これにより複数のレコード・パターンを持つファイルの処理が可能になります。「レコード・コード」フィールドでは、複数の値をセミコロン(;)文字で区切って指定できます。

      列エディタで、「レコード・コード」フィールドの各レコード・タイプに対してレコード・コードを割り当てます。

      例3-1の場合は、ORDERSデータストアのCODE_REC列の「レコード・コード」フィールドにORDと入力し、ORDER_LINESデータストアのCODE_REC列の「レコード・コード」フィールドにLINと入力します。

このように定義することで、ORDERSデータストアからデータを読み取る際に、ファイル・ドライバでは最初の列に値ORDが含まれているレコードのみがフィルタ処理されます。ORDER_LINESデータストアでも同様です(最初の列に値LINが含まれているレコードのみが戻されます)。

3.6.2 ファイルへのデータの統合

ファイルをインタフェースのソースおよびターゲットとして使用できます。ファイルでのデータ統合戦略は、ステージング領域からファイルへのロードに関係します。インタフェース・フロー・タブのIKMの選択によって、統合のパフォーマンスおよび可能性が決まります。

Oracle Data Integratorには、ファイル・データを統合するための2つの統合ナレッジ・モジュールが用意されています。

3.6.2.1 IKM SQL to File Append

IKM SQL to File Appendでは、ファイル・ドライバを使用して、ステージング領域からファイル・ターゲットへ切捨て挿入モードでデータを統合します。

このKMのオプションは次のとおりです。

  • INSERT: インタフェースのターゲット・データストアへのデータの挿入を自動的に試行します。

  • CREATE_TARG_TABLE: ターゲット表を作成します。

  • TRUNCATE: ターゲット・ファイルの内容を削除し、ターゲット・ファイルが存在しない場合にはファイルを作成します。

  • GENERATE_HEADER: デリミタ付きファイルのヘッダー行を作成します。

このKM以外に、ステージング領域のテクノロジ固有のIKMも使用できます。それらのKMではテクノロジ固有の最適化がサポートされており、ローダーや外部表などが使用されます。

3.6.2.2 IKM File to File (Java)

IKM File to File (Java)は、File-to-Fileユースケースを処理するためのソリューションです。このIKMでは、ファイルを処理するためのJavaプログラムを生成することで統合のパフォーマンスが最適化されます。データストアのリソース名にワイルドカードが含まれる場合、複数のソース・ファイルを処理できます。このプログラムでは、複数のスレッドを使用して変換を実行できます。

IKM File to File (Java)には、ロギングおよびエラー処理のための2つのKMオプション(LOG_FILEと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は、データの処理に使用されるパラレル・スレッドの数を示します。

  • LOG_FILEはログ・ファイル名を示します。このオプションが設定されていない場合、ログ・ファイル名は自動的に生成され、ログ・ファイルはターゲットの作業スキーマに書き込まれます。

  • BAD_FILEは不良ファイル名を示します。このオプションが設定されていない場合、不良ファイル名は自動的に生成され、不良ファイルはターゲットの作業スキーマに書き込まれます。

  • SOURCE_ENCODINGは、ソース・ファイルのキャラクタ・セット・エンコーディングを示します。デフォルトはマシンのデフォルトのエンコーディングです。

  • TARGET_ENCODINGは、ターゲット・ファイルのキャラクタ・セット・エンコーディングを示します。デフォルトはマシンのデフォルトのエンコーディングです。

  • REMOVE_TEMPORARY_OBJECTSは、Yesに設定されている場合、ログ・ファイルおよび不良ファイルを削除します。

  • PROCESSED_FILE_PREFIXは、処理後にソース・ファイル名に追加される接頭辞を示します。

  • PROCESSED_FILE_SUFFIXは、処理後にソース・ファイル名に追加される接尾辞を示します。