6 XMLファイル

Oracle Data IntegratorでのXMLファイルの使用方法について理解することが重要です。

この章の内容は次のとおりです。

6.1 概要

Oracle Data Integratorでは、Oracle Data Integrator Driver for XMLを介したXMLファイル統合がサポートされます。

6.1.1 概念

XMLの概念は、次のようにOracle Data Integratorの概念にマップされます。1つのXMLファイルは、Oracle Data Integratorの1つのデータ・サーバーに対応します。このデータ・サーバー内で、単一のスキーマがXMLファイルの内容にマップされます。Oracle Data Integrator Driver for XML (XMLドライバ)により、XMLファイルの階層構造がリレーショナル・スキーマにロードされます。このリレーショナル・スキーマは、SQLを使用した問合せまたは変更が可能なスキーマ内にある一連の表です。XMLドライバでは、リレーショナル・スキーマをXMLファイルにアンロードして戻すこともできます。リレーショナル・スキーマは、表、列および制約とともに、ODIでデータ・モデルとしてリバース・エンジニアリングされます。このモデルは、ODI内で通常のリレーショナル・データ・モデルと同様に使用されます。リレーショナル・スキーマ内で変更されたデータをXMLファイルに書き込む必要がある場合は、XMLドライバによりリレーショナル・スキーマをファイルに同期化する機能が提供されています。

このドライバの詳細は、Oracle Data Integrator Driver for XMLの参照情報を参照してください。

6.1.2 XMLドライバの事前/事後処理サポート

データをXMLドライバに提供する方法をカスタマイズできるようになりました。中間処理ステージを設定して、Oracle Data Integratorを使用して外部エンドポイントから取得されるデータを処理したり、データを外部エンドポイントに書き出すことができます。

XMLドライバの事前および事後処理ステージの構成および実装の詳細は、XMLおよび複合ファイル・ドライバの事前/事後処理サポートを参照してください。

6.1.3 ナレッジ・モジュール

Oracle Data Integratorには、XMLデータを処理するためのIKM XML Control Appendが用意されています。このナレッジ・モジュールは、固有のXMLナレッジ・モジュールです。これには、リレーショナル・スキーマからファイルへデータを同期化するための固有のオプションが備えられています。

このKM以外に、XMLデータ・サーバーを任意のSQLデータ・サーバーとして使用することもできます。XMLデータ・サーバーでは、SQLデータ・サーバーをソース指定またはターゲット指定するテクノロジ固有のKMと汎用KMの両方がサポートされています。これらのKMの詳細は、「汎用SQL」またはテクノロジの章を参照してください。

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

XMLナレッジ・モジュールの使用を開始する前に、この項の情報を必ず読んでください。

6.2.1 システム要件

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

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

http://www.oracle.com/technetwork/middleware/data-integrator/documentation/index.html

6.2.2 テクノロジ固有の要件

Oracle Data IntegratorでXMLファイルを使用するためのテクノロジ固有の要件はありません。

サポートされるデータ型

Oracleを対象とするデータ型マッピングは、次のデータ型に対して定義されます。XMLテクノロジのサポートされるデータ型は次のとおりです。

  • BIGINT — intデータ型は、SQL Serverの主要な整数データ型です。19桁の10進数の精度を持つ整数データ型。bigintデータ型は、整数値がintデータ型でサポートされている範囲を超える可能性があるときに使用するためのものです。bigintは、データ型の優先順位チャートでsmallmoneyとintの間に位置します。パラメータ式がbigintデータ型の場合にのみ、関数でbigintが返されます。

  • BINARY — データ型BINARYおよびBINARY VARYING (VARBINARY)はまとめてバイナリ文字列型と呼ばれ、バイナリ文字列型の値はバイナリ文字列と呼ばれます。バイナリ文字列は、一連のオクテットまたはバイトです。昇順では、バイナリ値NULLは最後に表示されます(最も大きい)。4,096バイトまでのバイナリ・データの格納を有効にします。お使いのアプリケーションで、文字セマンティックで制約されないビットを格納できるようにします。

  • BIT — 1、0またはNULLの値を指定できる整数のデータ型。TRUEは1に、FALSEは0に変換可能であるため、これをブール値の格納に使用することもできます。ビットに変換すると、すべてのゼロでない値が1になります。表に8ビット以下の列がある場合、列は1バイトとして格納されます。表に9から16ビットまでの列がある場合、列は2バイトとして格納され、以降、同様に続きます。

  • BLOB — BLOB (バイナリ・ラージ・オブジェクト)は、2,147,483,647文字までの長さになる可変長バイナリ文字列です。他のバイナリ型と同様に、BLOB文字列はコード・ページには関連付けられません。また、BLOB文字列では、文字データは保持されません。接尾辞K、MまたはG (それぞれ1024、1024*1024、1024*1024*1024の倍数に関連します)のいずれかが指定された場合を除いて、BLOBの長さはバイト単位で指定されます。BLOBの長さはバイト単位で指定されます。

  • CHAR — CHARデータ型には、固定長フィールドに文字データが格納されます。文字データは、固定長または可変長の文字列として格納できます。固定長文字列は出力で右側が空白で拡張されます。可変長文字列は拡張されません。入力で末尾の空白が削除され、出力でのみリストアされます。デフォルトの長さは1で、最大サイズは4,096バイトです。

  • CLOB — CLOB (キャラクタ・ラージ・オブジェクト)は、任意の文字セットの大きいドキュメントなど、Unicode文字ベースのデータを格納するために使用されます。CLOB値は、2,147,483,647 (2G)文字までの長さに設定できます。接尾辞K、MまたはG (それぞれ1024、1024*1024、1024*1024*1024の倍数に関連します)のいずれかが指定された場合を除いて、両方のCLOBの長さは数値の文字単位で指定されます。CLOBの長さは文字単位(Unicode)で指定されます。

  • DATE - 国際規格ISO-8601:1988の日付表記YYYYMMDDに基づきます(ここでYYYYは一般的なグレゴリオ暦の年、MMは01 (1月)から12 (12月)までの月、DDは01から31までの値による月の日付を表します)。日付は、次のリストのいずれかの基本データ型で表すことができます。いくつかのデータ型では、必要な最小値は4バイトです。リストには、数値、文字列およびEBCDICが含まれます。

  • DECIMAL — DECIMALでは、精度とスケールを任意にサイズ変更できる真数値が指定されます。精度(小数点の右側と左側の両方の合計桁数)とスケール(小数部の桁数)を指定できます。必要な記憶域の量は精度に基づきます。

  • DOUBLE — CREATE TABLE文とALTER TABLE文で使用される倍精度浮動小数点データ型。doubleデータ型は、倍精度64ビットIEEE 754浮動小数点です。Doubleデータ型では、可能な最大の数値と最小の数値が指定されます。Doubleのデフォルト値は0です。10進値では、通常、このデータ型がデフォルトの選択内容です。

    ノート:

    通貨などの正確な値には、このデータ型を使用しないでください。
  • FLOAT — FLOATデータ型は、2進精度bを持つ浮動小数点数です。このデータ型のデフォルト精度は、126桁の2進精度または38桁の10進精度です。精度がpのNUMBERデータ型のサブタイプ。FLOATの値は、内部的にNUMBERと表されます。精度pには1から126の2進数を指定できます。FLOAT値には、1から22バイトが必要です。

  • INTEGER— INTEGERは、整数部のみを持ち、浮動小数点と小数部を持たない数値を参照するANSI SQLデータ型です。3、25、1987など、整数のみが格納されます。INTEGERデータ型は、通常NUMBER(38)と呼ばれます。この精度は1から38までの範囲です。SIMPLE_INTEGERはBINARY_INTEGERのサブタイプです。この範囲は-2147483648から2147483648です。SIMPLE_INTEGERではNULL値は格納できません。

  • LONGVARBINARY — IPアドレスなどの可変長RAWバイト・データ。LONG VARBINARY値は、列の幅全体には拡張されません。32,000,000バイトまでのデータを格納します。LONGデータ型は、65,000バイト(VARBINARYデータ型およびVARCHARデータ型の最大サイズ)より大きいデータを格納する必要がある場合にのみ使用します。そのようなデータには、非構造化データ、オンラインのコメントや投稿、小さいログ・ファイルなどが含まれる場合があります。

  • LONGVARCHAR — 文字、数値および記号の可変長文字列。LONG VARCHAR値は、列の幅全体には拡張されません。32,000,000バイトまでのデータを格納します。LONGデータ型は、65,000バイト(VARBINARYデータ型およびVARCHARデータ型の最大サイズ)より大きいデータを格納する必要がある場合にのみ使用します。そのようなデータには、非構造化データ、オンラインのコメントや投稿、小さいログ・ファイルなどが含まれる場合があります。

  • NCHARおよびNVARCHAR2— NCHARとNVARCHAR2は、Unicode文字データを格納するUnicodeデータ型です。NCHARとNVARCHAR2のデータ型の文字セットはAL16UTF16とUTF8のいずれかのみに設定でき、データベース作成時に各国語文字セットとして指定されます。AL16UTF16とUTF8は、両方ともUnicodeエンコーディングです。NCHARデータ型は、各国語文字セットに対応する固定長の文字列を格納し、NVARCHAR2データ型は、可変長の文字列を格納します。NCHAR列の最大長は2000バイトで、最大で2000文字を保持できます。実際のデータが最大バイト制限の2000の対象となります。NVARCHAR2列の最大長は4000バイトで、最大で4000文字を保持できます。実際のデータが最大バイト制限の4000の対象となります。両方のデータ型に対して、2つのサイズ制限を実行時に同時に満たす必要があります。

  • NCLOB — NCLOB (各国語キャラクタ・ラージ・オブジェクト)は、最大で4 GBの文字データを保持できるデータ型です。CLOBと似ていますが、文字は各国語文字セットからのものです。12cでは、記憶域の制限が、(4*1024*1024*1024-1) * CHUNKサイズ(LOBを定義するLOB STORAGE句で指定されたサイズ、デフォルトではデータベース・ブロック・サイズ)に拡張されます。

  • NUMBER — NUMBERデータ型には、固定小数点数および浮動小数点数が格納されます。事実上どんな大きさの数値でも格納可能であり、Oracleが稼働するシステム間で、最大38桁の精度で移植性が保証されます。NUMBER列には、有効桁数が最大で38の1 x 10-130から9.99...9 x 10125まで範囲の正の数値、有効桁数が最大で38の-1 x 10-130から9.99...99 x 10125までの負の数値、0 (ゼロ)および正と負の無限大(バージョン5以降のOracleデータベースからインポートする方法でのみ生成される)の数値を格納できます。

  • NUMERIC — 数値データ型は、正と負の固定小数点数と浮動小数点数、0 (ゼロ)、無限大、および操作の未定義の結果である値(非数値、つまりNAN)を格納します。これはNumberデータ型と浮動小数点数で構成されます。NUMBERデータ型には、固定小数点数および浮動小数点数が格納されます。事実上どんな大きさの数値でも格納可能であり、Oracle Databaseが稼働するシステム間で、最大38桁の精度で移植性が保証されます。

  • OBJECT — オブジェクト型は、発注書など、アプリケーション・プログラムで処理する実社会のエンティティを抽象化したものです。オブジェクト型は、次の3種類のコンポーネントがあるスキーマ・オブジェクトです。名前。そのスキーマ内でオブジェクト型を一意に識別します。属性。実社会のエンティティの構造と状態をモデル化します。属性は、組込み型か他のユーザー定義型です。メソッド。PL/SQLまたはJavaで記述され、データベースに格納されているか、またはCなどの言語で記述され、外部に格納されているファンクションまたはプロシージャです。メソッドは、アプリケーションが実社会エンティティに対して実行できる操作を実装します。オブジェクト型はテンプレートです。テンプレートにあわせて構造化されたデータ・ユニットをオブジェクトと呼びます。

  • REAL — REALデータ型は63桁の2進精度または18桁の10進精度を持つ浮動小数点数です。REALは仮数小数点精度7の、符号付き概数値です。その絶対値は0 (ゼロ)、または10^-38から10^38までです。例 - 5600E+12。REALデータ型では、IEEE浮動小数点表記法を使用した、数値に対する4バイトの記憶域が指定されます。

  • SMALLINT — 小整数型であるSMALLINTは、精度5およびスケール0の真数値で、通常は2バイト、つまり16ビットです。符号付きの場合は、範囲は-32,768から+32,767まで(SQL_C_SSHORTまたはSQL_C_SHORT)、符号なしの場合は、0から65,535まで(SQL_C_USHORT)です。-32,768 <= n <= 32,767 (ここで、nはSMALLINTの値です)。SMALLINTでは、2バイトの記憶域が指定されます。

  • TEXT — TEXTデータ型には、あらゆる種類のテキスト・データが格納されます。ロケールでサポートされるシングルバイト文字とマルチバイト文字の両方を含めることができます。シンプル・ラージ・オブジェクトという用語は、TEXTまたはBYTEのデータ型のインスタンスを指します。TEXT列の理論上の制限は231バイト(2GB)ですが、実際の制限は、使用できるディスク記憶域によって決定します。同じ表でTEXTデータ型として宣言できるのは、195列までです。同じ制限がBYTEデータ型にも適用されます。TEXT列では、値を格納、取得、更新または削除できます。

6.2.3 接続性要件

この項では、XMLデータベースに接続するための要件をリストします。

Oracle Data Integrator Driver for XML

XMLファイルへのアクセスは、Oracle Data Integrator Driver for XMLを介して行われます。このJDBCドライバはOracle Data Integratorとともにインストールされるもので、その他のコンポーネントのインストールや構成は不要です。

システム管理者から次の接続情報を入手する必要があります。

  • 使用するXMLファイルに関連付けられているDTDまたはXSDファイルの場所

  • 使用するXMLファイルの場所

6.3 トポロジの設定

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

  1. XMLデータ・サーバーの作成

  2. XML用物理スキーマの作成

6.3.1 XMLデータ・サーバーの作成

各XMLデータ・サーバーは、Oracle Data Integratorにアクセス可能な1つのXMLファイルに対応します。

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

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

  1. 「定義」タブ:
    • 名前: Oracle Data Integratorに表示されるデータ・サーバーの名前。

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

  2. 使用するドライバに応じて、「JDBC」タブに次の値を入力します。
    • JDBCドライバ: com.sunopsis.jdbc.driver.xml.SnpsXmlDriver

    • JDBC URL: jdbc:snps:xml?[property=value&property=value...]

    表6-1に、Oracle Data Integrator Driver for XMLの主なプロパティをリストします。これらのプロパティは、JDBC URL内で指定できます。

    これらのプロパティの詳細、およびすべてのプロパティの包括的なリストは、「Oracle Data Integrator Driver for XMLの参照情報」を参照してください。

    表6-1 JDBCドライバのプロパティ

    プロパティ ノート

    f

    <XMLファイルの場所>

    XMLファイル名。パス名には、バックスラッシュ"\"ではなくスラッシュ"/"を使用します。HTTP、FTPまたはファイルのURLを使用してファイルの場所を示すことができます。URLによって示されたファイルは読取り専用です。

    d

    <DTD/XSDファイルの場所>

    記述ファイル。このファイルはDTDまたはXSDファイルです。HTTP、FTPまたはファイルのURLを使用してファイルの場所を示すことができます。URLによって示されたファイルは読取り専用です。

    DTDまたはXSDファイルが存在しない場合、リレーショナル・スキーマはXMLファイルの内容のみを使用して作成されることに注意してください。DTDまたはXSDに記述されている使用可能な要素が1つのXMLファイル・インスタンスにすべて含まれていないことで、データ・モデルが不完全になる可能性があるため、このような構造からデータ・モデルをリバース・エンジニアリングすることはお薦めしません。

    re

    <ルート要素>

    スキーマのルート表として選択する要素の名前。この値では大/小文字が区別されます。このプロパティは、WSDLファイルから特定のメッセージ定義をリバース・エンジニアリングする場合や、使用可能なルート要素がXSDファイル内に複数存在する場合などに使用できます。

    ro

    true | false

    trueの場合は、XMLファイルが読取り専用モードで開きます。

    s

    <schema name>

    XMLファイルのロード先となるリレーショナル・スキーマの名前。このプロパティが欠落している場合、XMLファイル名の最初の5文字を名前とするスキーマが自動的に作成されます。

    cs

    true | false

    大/小文字を区別するモードまたは区別しないモードで、XMLファイルがロードされます。区別しないモードの場合は、DTDファイル内のすべての要素名を区別できることが必要です(たとえば、同じファイル内にAbcとabcが存在する場合は、名前の競合が発生します)。

    これらのプロパティを次の例に示します。

    products.xsdによって説明される、PRODUCTSスキーマ内のPROD20100125_001.xmlに接続する場合の例は次のとおりです。

    jdbc:snps:xml?f=/xml/PROD20100125_001.xml&d=/xml/products.xsd&s=PRODUCTS
    

    staff_internal.dtdによって説明されるstaff_internal.xmlファイルに読取り専用モードで接続する場合の例は次のとおりです。スキーマ名はstaffになります。

    jdbc:snps:xml?f=/demo/xml/staff_internal.xml&d=/demo/xml/staff_internal.dtd&ro=true&s=staff
    

6.3.2 XML用物理スキーマの作成

『Oracle Data Integratorの管理』物理スキーマの作成に関する項の説明に従って、標準の手順を使用してXML物理スキーマを作成します。

URLで設定したスキーマ名が表示されます。「データ・スキーマ」および「作業スキーマ」の両方について、このスキーマを選択します。

『Oracle Data Integratorの管理』論理スキーマの作成に関する項の説明に従って、標準の手順を使用してこの物理スキーマ用の論理スキーマを作成し、特定のコンテキストで関連付けます。

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

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

XMLでの作業を開始するにあたり、使用するプロジェクトに次のナレッジ・モジュールをインポートすることをお薦めします。

  • LKM SQL to SQL

  • LKM File to SQL

  • IKM XML Control Append

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

この項では、次の項目について説明します。

6.5.1 XMLモデルの作成

XMLファイル・モデルによって、一連のデータストアがグループ化されます。通常、各データストアはXMLファイル内の1つの要素を表します。

『Oracle Data Integratorでの統合プロジェクトの開発』モデルの作成に関する項の説明に従って、標準の手順を使用してXMLモデルを作成します。XMLテクノロジおよびトポロジの構成時に作成されたXML論理スキーマを選択します。

6.5.2 XMLモデルのリバース・エンジニアリング

XMLでは、XMLドライバの機能のみを使用する標準のリバース・エンジニアリングがサポートされています。

URLのdtdまたはdパラメータでDTDまたはXSDファイルを参照して、XMLファイル構造の包括的な説明から構造をリバース・エンジニアリングすることをお薦めします。XSDまたはDTDのいずれも使用できない場合は、XMLインスタンス・ファイルを使用してリバース・エンジニアリングできます。この場合、リレーショナル・スキーマの構造は、XMLファイルに含まれるデータから推測されます。

標準のリバース・エンジニアリング

XMLで標準のリバース・エンジニアリングを実行するには、『Oracle Data Integratorでの統合プロジェクトの開発』モデルのリバース・エンジニアリングに関する項の説明に従って、通常の手順を使用します。

標準のリバース・エンジニアリング・プロセスでは、XMLドライバによって生成されたリレーショナル・スキーマから表が自動的にリバース・エンジニアリングされます。これらの表には、自動的に次のものが含められます。

  • 主キー(PK列): 要素の親子関係を保持します。

  • 外部キー(FK列): 要素の親子関係を保持します。

  • 順序識別子(ORDER列): XMLファイル内の要素の順序を保持します。

これらの追加の列により、階層XML構造のリレーショナル・スキーマへのマッピングが可能になります。詳細は、「Oracle Data Integrator Driver for XMLの参照情報」「XMLからSQLへのマッピング」を参照してください。

6.6 マッピングの設計

XMLをマッピングのソースまたはターゲットとして使用できます。

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

6.6.1 XMLマッピングに関するノート

マッピングでXMLを使用する前に、次のノートをよく読んでください。

6.6.1.1 XML構造のターゲット指定

XMLモデルのデータストアをマッピングのターゲットとして使用する場合は、XML階層の親子関係および順序を保持するためにドライバで生成される列が確実にロードされるようにしてください。たとえば、リレーショナル・スキーマのREGION表に対応するregion要素のレコードを例6-1のようなXML構造に入力する場合は、REGION表の列REGION_IDおよびREGION_NAMEをロードする必要があります。これらの2つの列は、XML属性に対応します。

<country COUNTRY_ID="6" COUNTRY_NAME="Australia">
    <region REGION_ID="72" REGION_NAME="Queensland">
</country>

例6-1では、XMLドライバによってREGION表に自動的に作成された追加の列もロードする必要があります。それらの列は次のとおりです。

  • REGIONPK: この列により、各<region>要素を識別できます。

  • REGIONORDER: この列により、XMLファイル内で<region>要素を順序付けできます(レコードは、リレーショナル・スキーマでは順序付けされませんが、XML要素では順序付けされます)。

  • COUNTRYFK: この列により、<region>要素を<country>親要素との関係で配置できます。この値は、COUNTRY表のAustraliaレコードのCOUNTRY.COUNTRYPK値と同じです。

例6-1 XML構造

6.6.1.2 XMLファイルとスキーマの同期化

XMLファイルのデータとXMLスキーマのデータを完全に同期化するには、次のコマンドをコールする必要があります。

  • データの読取りまたは更新のためにXMLモデルの表を使用する前に、XML論理スキーマでSYNCHRONIZE FROM FILEコマンドを使用することをお薦めします。この操作によって、XML階層のデータがXMLリレーショナル・スキーマに再ロードされます。このスキーマは、最初のアクセス時に組込みまたは外部のデータベース記憶域にロードされます。その後に行ったファイルへの変更は、このコマンドを発行しないかぎり、自動的にはスキーマへ同期されません。

  • リレーショナル・スキーマへの変更を行った後、XML論理スキーマでSYNCHRONIZE ALLまたはSYNCHRONIZE FROM DATABASEコマンドをコールして、このスキーマをXML階層データにアンロードする必要があります。IKM XML Control Appendにはこの同期化コマンドが実装されています。

XMLスキーマを操作するマッピングおよびプロシージャの前(および後)に、パッケージ内のプロシージャでこれらのコマンドを実行する必要があります。

これらのコマンドの詳細は、「Oracle Data Integrator Driver for XMLの参照情報」を参照してください。

6.6.1.3 サイズが大きいXMLファイルの処理

Oracle Data Integratorでは、サイズが大きいXMLファイルを高いパフォーマンスで処理できます。

デフォルトのドライバ構成では、リレーショナル・スキーマがメモリーの組込みエンジンに格納されます。サイズの大きいXMLファイルを処理する場合は、外部データベース記憶域の使用を検討することをお薦めします。

これらのコマンドの詳細は、「スキーマの格納」を参照してください。

6.6.2 XMLとの間でのデータのロード

XMLファイルは、マッピングのソースまたはターゲットとして使用できます。「ロード・ナレッジ・モジュール」タブでの、XMLファイルと別のタイプのデータ・サーバー間でデータをロードするためのLKMの選択は、マッピングのパフォーマンスに関してきわめて重要です。

6.6.2.1 XMLスキーマからのデータのロード

汎用SQL KMまたは関係するもう一方のテクノロジ固有のKMを使用して、XMLデータベースからターゲットまたはステージング領域のデータベースへデータをロードします。

XMLソースからステージング領域へのロードに使用できるKMの例を表6-2に示します。

表6-2 XMLからステージング領域へロードするためのKM

ステージング領域 KM ノート

Microsoft SQL Server

LKM SQL to MSSQL (BULK)

SQL Serverのバルク・ローダーを使用します。

Oracle

LKM SQL to Oracle

汎用LKMより高速です(統計を使用)。

All

LKM SQL to SQL

ANSI SQL-92のソースとANSI SQL-92のステージング領域の間でデータをロードするための汎用KMです。

6.6.2.2 XMLスキーマへのデータのロード

XMLスキーマをステージング領域として使用することはお薦めしません。ただし、XMLがマッピングのターゲットで、そのターゲットをステージング領域として使用する場合は例外です。この場合は、XMLスキーマにデータをロードする必要があることがあります。

汎用SQL KMまたは関係するもう一方のテクノロジ固有のKMを使用してソースまたはステージング領域からXMLスキーマへデータをロードします。

ソースからXMLステージング領域へのロードに使用できるKMの例を表6-3に示します。

表6-3 XMLスキーマにロードするためのKM

ソース KM ノート

ファイル

LKM File to SQL

ANSI SQL-92のステージング領域にあるファイルにロードするための汎用KMです。

All

LKM SQL to SQL

ANSI SQL-92のソースとANSI SQL-92のステージング領域の間でデータをロードするための汎用KMです。

6.6.3 XMLへのデータの統合

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

IKM XML Control Appendでは、データがXMLスキーマに統合されるほか、データをファイルに同期するオプションを使用できます。このKM以外に、汎用SQL KMまたは関係するもう一方のテクノロジ固有のKMも使用できます。汎用KMまたはテクノロジ固有のKMを使用する場合は、スキーマで行われた変更をXMLファイルに書き込むための同期化操作を手動で実行する必要があります。

次のデータ統合に使用できるKMの例を表6-4に示します。

  • ステージング領域からXMLターゲットへの統合

  • XMLステージング領域からXMLターゲットへの統合。この場合、ステージング領域はXMLターゲット上にあります。

表6-4 XMLファイルにデータを統合するためのKM

モード ステージング領域 KM ノート

更新

XML

IKM SQL Incremental Update

汎用KM

追加

XML

IKM SQL Control Append

汎用KM

追加

すべてのRDBMS

IKM SQL to SQL Append

汎用KM

6.7 トラブルシューティング

この項では、Oracle Data IntegratorでのXMLの使用時に発生する可能性がある問題のトラブルシューティングに関する情報を提供します。次の項目が含まれます。

6.7.1 XMLで発生したエラーの検出

通常、Oracle Data Integratorではエラーは次のように表示されます。

java.sql.SQLException: No suitable driver
at ... 
at ... 
...

このjava.sql.SQLExceptioncodeは、JDBCドライバを介して問合せが行われ、エラーが戻されたことを単純に示しています。このエラーはデータベースまたはドライバのエラーであることが多く、次のように解明する必要があります。

まず、太字のテキスト部分のみに注目してください。これは、XMLドライバのドキュメントで検索する必要があります。ここで示されているように、固有のエラー・コードが含まれている場合は、エラーをすばやく識別できます。

このようなエラーが実行ログで検出された場合は、データベースに送信されたSQLコードを分析して、エラーの原因を特定する必要があります。このコードは、エラーのあるタスクの「説明」タブに表示されます。

6.7.2 一般的なエラー

この項では、XMLの最も一般的なエラーおよび主な原因について説明します。次の項目が含まれます。

  • No suitable driver

    JDBC URLが不正です。URL構文が有効であることを確認してください。

  • File <XML file> is already locked by another instance of the XML driver.

    XMLファイルが別のユーザーまたはアプリケーションによってロックされています。XMLファイルを使用している可能性があるすべてのアプリケーションを閉じてください。該当するアプリケーションがクラッシュした場合は、XMLファイルのディレクトリに残っている.lckファイルを削除してください。

  • The DTD file "xxxxxxx.dtd" doesn't exist

    この例外は、コマンドLOAD FILEを使用してXMLファイルをロードしようとしたときに発生する可能性があります。このエラー・メッセージの原因として、次の2つが考えられます:

    • DTDファイルのパスが間違っています。

    • 対応するXMLファイルが(接続時などに)別のスキーマによってすでに開かれています。

  • Table not found: S0002 Table not found: <table name> in statement [<SQL statement>]

    アクセスしようとしている表がスキーマに存在しません。

  • Column not found: S0022 Column not found: <column name> in statement [<SQL statement>]

    アクセスしようとしている列が、文の中で指定された表に存在しません。