ヘッダーをスキップ

Oracle Database ユーティリティ
10g リリース2(10.2)

B19211-01
目次
目次
索引
索引

戻る 次へ

9 フィールド・リスト・リファレンス

この章では、SQL*Loader制御ファイルのフィールド・リストについて説明します。この章の内容は、次のとおりです。

フィールド・リストの内容

SQL*Loader制御ファイルのフィールド・リストには、位置、データ型、条件、デリミタなど、ロードするフィールドの情報が提供されます。

例9-1に、第8章で説明したサンプル制御ファイルのフィールド・リスト・セクションを示します。

例9-1    サンプル制御ファイルのフィールド・リスト・セクション

.
.
.
1  (hiredate  SYSDATE,
2     deptno  POSITION(1:2)  INTEGER EXTERNAL(2)
              NULLIF deptno=BLANKS,
3       job   POSITION(7:14)  CHAR  TERMINATED BY WHITESPACE
              NULLIF job=BLANKS  "UPPER(:job)",
       mgr    POSITION(28:31) INTEGER EXTERNAL 
              TERMINATED BY WHITESPACE, NULLIF mgr=BLANKS,
       ename  POSITION(34:41) CHAR 
              TERMINATED BY WHITESPACE  "UPPER(:ename)",
       empno  POSITION(45) INTEGER EXTERNAL 
              TERMINATED BY WHITESPACE,
       sal    POSITION(51) CHAR  TERMINATED BY WHITESPACE
              "TO_NUMBER(:sal,'$99,999.99')",
4      comm   INTEGER EXTERNAL  ENCLOSED BY '(' AND '%'
              ":comm * 100"
    )

このサンプル制御ファイルの左側の数字は、実際の制御ファイルでは表示されません。これらの数字は、次の説明の番号に対応しています。

  1. SYSDATEに、列を現在のシステム日付に設定します。詳細は、「列への現在の日付の設定」を参照してください。

  2. POSITIONに、データ・フィールドの位置を指定します。詳細は、「データ・フィールドの位置指定」を参照してください。

    INTEGER EXTERNALは、フィールド用のデータ型です。「データ・フィールドのデータ型の指定」および「数値型EXTERNAL」を参照してください。

    NULLIF句は、フィールド条件の指定に使用する句の1つです。詳細は、「WHEN、NULLIFおよびDEFAULTIF句の使用」を参照してください。

    このサンプルでは、BLANKSを使用して、フィールドを空白と比較しています。詳細は、「フィールドとBLANKSの比較」を参照してください。

  3. TERMINATED BY WHITESPACE句は、フィールドを指定できるデリミタの1つです。詳細は、「TERMINATEDフィールド」を参照してください。

  4. ENCLOSED BY句は、もう1つの使用可能なフィールド・デリミタです。詳細は、「ENCLOSEDフィールド」を参照してください。

データ・フィールドの位置指定

データ・ファイルからデータをロードする場合は、フィールドの位置と長さをSQL*Loaderに対して明示する必要があります。論理レコード中のフィールド位置は、列指定(columnspec)の中でPOSITION句を使用して指定します。このときフィールド位置は、絶対位置で指定することも、前のフィールドからの相対位置で指定することもできます。POSITIONに対する引数は、カッコで囲む必要があります。文字長セマンティクスをデータ・ファイルに使用しても、start、endおよびintegerは、常にバイト単位です。

位置指定(pos_spec)句の構文は次のとおりです。


画像の説明

表9-1では、位置指定句のパラメータについて説明します。

表9-1     位置指定句のパラメータ
パラメータ  説明 

start 

論理レコード中のデータ・フィールドの開始位置です。論理レコードの先頭バイト位置は1となります。 

end 

論理レコード中のデータ・フィールドの終了位置です。start-endと表記することも、start:endと表記することもできます。endを省略した場合、フィールド長は、データ・ファイル中のデータ型から導出されます。CHAR型では、startまたはendを省略し、長さ指定(CHAR(n))をしない場合、データ長が1として扱われます。データ型から長さを導出できない場合は、エラー・メッセージが出力されます。 

対象となるデータ・フィールドが前のフィールドの直後にあることを示します。制御ファイル中の最初のデータ・フィールドに対して*を指定した場合、そのフィールドは論理レコードの先頭であると判断されます。位置指定に*を使用した場合、フィールド長はデータ型から導出されます。 

+integer 

+integerを指定してオフセットを使用すると、前フィールドの終了位置直後の位置から現行のフィールドをオフセットできます。この場合、現行のフィールドの値は、+integerで指定されたバイト数分スキップした後で読み込まれます。 

POSITIONを完全に省略することも可能です。省略した場合のデータ・フィールドの位置指定は、POSITION(*)と指定した場合と同じです。

タブを含むデータでのPOSITIONの使用

フィールド位置の指定で、データ・ファイル中にタブが含まれている場合は注意が必要です。SQL*Loaderの拡張SQL文字列機能を使用して、書式化されたレポートのデータをロードするとします。最初に、レポートの印刷出力を見て、すべての文字位置を正確に調べ、制御ファイルを作成します。このような状況でデータをロードしようとすると、無効な数字および欠落フィールドによる多数のエラーが発生し、ロードが失敗する場合があります。

このようなエラーは、データにタブが含まれているときに発生します。紙に出力した場合、各タブの幅は数列分に拡がります。ただし、データ・ファイルでは、それぞれのタブは1文字のままです。そのため、SQL*Loaderは、データ・ファイルの読取り時に、誤ったPOSITION指定を参照することになります。

この問題を解決するには、データ・ファイル中のタブを探して該当箇所のPOSITION指定を調整するか、フィールドをデリミタで区切ります。

参照:

「デリミタの指定」 

複数表のロードでのPOSITIONの使用

複数表のロードでは、複数のINTO TABLE句を指定します。このとき最初の表の最初の列に対してPOSITION(*)を使用すると、論理レコードの先頭から相対的に位置が計算されます。2番目以降の表の最初の列に対してPOSITION(*)が使用された場合は、その時点で最後にロードされた表の最終列から相対的に位置が計算されます。

したがって、2番目以降のINTO TABLE句の処理開始時に、位置が自動的に論理レコードの先頭に設定されるわけではありません。このため、複数のINTO TABLE句を指定して、同一物理レコード中の異なる箇所を処理できます。例については、「複数の論理レコードの抽出」を参照してください。

論理レコード中のデータには、2つの表の両方ではなく、片方の表のみにロードするデータもあります。その場合は、POSITIONをリセットする必要があります。このとき、位置指定を省略するか、またはINTO TABLE句で先頭フィールドに対するPOSITION(*+n)を指定するかわりに、POSITION(1)またはPOSITION(n)を指定します。

POSITIONを使用した例

siteid  POSITION (*) SMALLINT 
siteloc POSITION (*) INTEGER 

これらが最初の2つの列を指している場合、siteidは1列目から始まり、sitelocがその次の列から始まります。

ename  POSITION (1:20)  CHAR 
empno  POSITION (22-26) INTEGER EXTERNAL 
allow  POSITION (*+2)   INTEGER EXTERNAL TERMINATED BY "/" 

enameは位置1〜20を占める文字データで、その次の列empnoは位置22〜26を占める数値型データです。列allowempnoの終了位置直後の位置(27)から+2の位置、つまり位置29から始まり、スラッシュが検出されるまで継続するデータとなります。

列およびフィールドの指定

表の列はいくつでもロードできます。データベース中に定義されていて制御ファイル中で指定されていない列には、NULL値が割り当てられます。

列指定(columnspec)には、列名とその列に入る値の指定を記述します。これらの列指定はカンマで区切って、全体を小カッコで囲みます。

(columnspec,columnspec, ...)

それぞれの列名は、INTO TABLE句で指定した表中の列名に対応させてください。列名にSQLやSQL*Loaderの予約語または特殊文字が含まれているか、大/小文字の区別がある場合は、列名を引用符で囲みます。

列の値をSQL*Loaderで生成する場合は、列指定の中でRECNUMパラメータ、SEQUENCEパラメータ、またはCONSTANTパラメータを指定します。詳細は、「SQL*Loaderを使用した入力データの生成」を参照してください。

データ・ファイルから列の値を読み込む場合は、列の値に対応するデータ・フィールドを指定します。このとき、列指定(columnspec)には、データベース表中の列を示す列名(column name)およびデータ・レコード中のフィールドを示すフィールド指定(field specification)を指定します。フィールド指定には、フィールドの位置、データ型、NULL値の制限およびデフォルト値を指定します。

列オブジェクトのロード時に、必ずしもすべての属性を指定する必要はありません。指定しなかった属性には、NULLが設定されます。

FILLERフィールドの指定

FILLERで指定されたFILLERフィールドは、データ・ファイルをマップしたフィールドで、データベースの列とは対応しません。FILLERフィールドは、データ・ファイルがマップされているデータ・フィールドから割り当てられた値です。

FILLERフィールドに関しては次のことに注意してください。

FILLERフィールド指定の例を次に示します。

 field_1_count FILLER char,
 field_1 varray count(field_1_count)
 (
    filler_field1  char(2),
    field_1  column object
    (
      attr1 char(2),
      filler_field2  char(2),
      attr2 char(2),
    )
    filler_field3  char(3),
 )
 filler_field4 char(6)

データ・フィールドのデータ型の指定

フィールドのデータ型を指定することによって、SQL*Loaderでフィールドのデータが処理される方法が決まります。たとえば、INTEGERデータ型を指定するとバイナリ・データとして処理され、INTEGER EXTERNALを指定すると数字を表す文字データとして処理されます。CHARを指定したフィールドには、すべての文字データを含むことができます。

各フィールドに対して指定できるデータ型は1つのみです。データ型を指定しない場合は、CHARが想定されます。

SQL*Loaderデータ型からOracleデータ型への変換処理およびSQL*Loaderの各データ型の詳細は、「SQL*Loaderのデータ型」を参照してください。

データ型を指定する前に、フィールドの位置を指定する必要があります。

SQL*Loaderのデータ型

SQL*Loaderデータ型は、移植可能なデータ型と移植不能なデータ型に分類されます。さらに、これら2つのグループは、LENGTH-VALUEデータ型およびVALUEデータ型に分類されます。

移植可能なデータ型および移植不能なデータ型は、データ型のプラットフォーム依存性によって分類されます。プラットフォーム依存性は、異なるプラットフォームのバイト順序スキーマ(ビッグ・エンディアンとリトル・エンディアン)の違い、プラットフォームのビット数(16ビット、32ビット、64ビット)の違い、符号付き数表現のスキーマの違い(2の補数と1の補数)などの様々な理由から存在します。バイト順序スキーマ、プラットフォームのワード長などの場合は、SQL*Loaderで、プラットフォーム依存性を解決するメカニズムが提供されます。これらのメカニズムの詳細は、該当するデータ型の説明を参照してください。

移植可能なデータ型および移植不能なデータ型の両方ともVALUEまたはLENGTH-VALUEをとることができます。VALUEデータ型のデータ・フィールド部分は単一であるとします。LENGTH-VALUEデータ型では、データ・フィールドが2つのサブフィールド(lengthサブフィールドがvalueサブフィールドの長さを指定)で構成される必要があります。

移植不能なデータ型

移植不能なデータ型は、VALUEデータ型およびLENGTH-VALUEデータ型に分類されます。移植不能なVALUEデータ型は次のとおりです。

移植不能なLENGTH-VALUEデータ型は次のとおりです。

移植不能なデータ型の構文の詳細は、「datatype_spec」の構文図を参照してください。

INTEGER(n)

データは、フルワード2進整数(nは、1、2、4または8のオプションで提供された長さ)です。長さが指定されていない場合、その長さはバイト単位で、特定のプラットフォームでのC言語のLONG INTのサイズに基づいて決まります。

INTEGERは、バイト・サイズ、バイト順序および符号付きの値の表現がシステム間で異なるため、移植不能です。ただし、符号付きの値の表現がシステム間で同じ場合は、SQL*Loaderを使用して、正しい結果でINTEGERデータにアクセスできます。長さ指定(n)でINTEGERを指定し、必要に応じて適切な方法でデータのバイト順序を指定すると、SQL*Loaderを使用してシステム間で正しい結果でデータにアクセスできます。長さ指定なしにINTEGERを指定すると、C言語のLONG INTの長さが両方のシステムで同じバイト数である場合のみ、SQL*Loaderを使用して正しい結果でデータにアクセスできます。その場合も、必要に応じて、適切な方法でデータのバイト順序を指定する必要があります。

2進整数の長さを明示的に指定すると、ワード長がSQL*Loaderで使用されているものとは異なるプラットフォーム上で入力データを作成する場合に有効です。たとえば、2進整数を含む入力データは、64ビットのプラットフォームで作成され、32ビットのプラットフォーム上のSQL*Loaderを使用しているデータベースにロードされます。この場合、INTEGER(8)を指定して、SQL*Loaderによってその整数を4バイトの量ではなく、8バイトの量として処理します。

デフォルトでは、INTEGERSIGNED量として処理されます。SQL*Loaderで、符号なしの量として処理する場合は、UNSIGNEDを指定します。デフォルトの動作に戻すには、SIGNEDを指定します。

参照:

「異なるプラットフォーム間でのデータのロード」 

SMALLINT

データはハーフワードの2進整数で表現されます。このフィールド長には、使用しているシステムのハーフワード整数の長さが取られます。デフォルトでは、SIGNED量として処理されます。SQL*Loaderで、符号なしの量として処理する場合は、UNSIGNEDを指定します。デフォルトの動作に戻すには、SIGNEDを指定します。

SMALLINTは、SHORT INTの長さが同じバイト数のシステム間のみで、正しい結果でロードできます。バイト順序がシステム間で異なる場合は、適切な方法でデータのバイト順序を指定します。詳細は、「バイト順序」を参照してください。


注意:

このデータ型のフィールド長は、C言語のSHORT INTデータ型と同じです。フィールド長を決定する1つの方法は、データを入れずに小さい制御ファイルを作成し、その結果のログ・ファイルを調べることです。このデータ型のサイズは、制御ファイルを使用しては変更できません。 


FLOAT

データは単精度浮動小数点2進数で表現されます。POSITION句でendを指定するとendは無視されます。このフィールド長には、システムの単精度浮動小数点2進数の長さ(C言語のデータ型FLOATに相当する長さ)が取られます。このデータ型のサイズは、制御ファイルを使用しては変更できません。

FLOATは、FLOATの表現に互換性があり、その長さが同じシステム間のみで、正しい結果の出るロードができます。バイト順序が2つのシステム間で異なる場合は、適切な方法でデータのバイト順序を指定します。詳細は、「バイト順序」を参照してください。

DOUBLE

データは倍精度浮動小数点2進数で表現されます。POSITION句でendを指定するとendは無視されます。このフィールド長には、使用しているシステムの倍精度浮動小数点2進数の長さ(C言語のデータ型DOUBLEまたはLONG FLOATに相当する長さ)が取られます。このデータ型のサイズは、制御ファイルを使用しては変更できません。

DOUBLEは、DOUBLEの表現に互換性があり、その長さが同じシステム間のみで、正しい結果でロードできます。バイト順序が2つのシステム間で異なる場合は、適切な方法でデータのバイト順序を指定します。詳細は、「バイト順序」を参照してください。

BYTEINT

2進数で表されている1バイト分のデータを10進数に直した値がロードされます。たとえば、入力文字x"1C"は28としてロードされます。BYTEINTフィールドの長さは、常に1バイトになります。POSITION(start:end)を指定すると、endは無視されます。(データ型は、C言語のUNSIGNED CHARです。)

このデータ型の構文の例は次のとおりです。

(column1 position(1) BYTEINT, 
column2 BYTEINT, 
... 
) 

ZONED

ZONED型のデータは、ZONED型の10進数形式で表現されます。つまり、10進数の各1桁が1バイト(COBOLのSIGN TRAILINGフィールドに相当)で表され、最終バイトに符号が入ります。このフィールド長には、精度(桁数)として指定された長さが取られます。

ZONEDデータ型の構文は次のとおりです。


画像の説明

ここでのprecisionは数字の桁数です。scale(指定されている場合)は(暗黙の)小数点の右側の桁数です。次の例では、位置32から始まる8桁の整数を表します。

sal  POSITION(32)  ZONED(8), 
 

Oracleデータベースでは、ZONED型のデータがASCIIベースのプラットフォームで生成される場合、VAX/VMS ZONED型10進数形式を使用します。EBCDICベースのプラットフォームで生成されるZONED型10進データのロードも可能です。この場合、Oracleでは「ESA/390操作の原理」で指定されているIBM形式を使用します。使用される形式は、入力データ・ファイルのキャラクタ・セット・エンコーディングによって異なります。詳細は、「CHARACTERSETパラメータ」を参照してください。

DECIMAL

DECIMAL型のデータは、PACKED型の10進数形式で記述されます。つまり、10進数の各2桁が1バイトで表され、最終バイトに1桁と符号が入ります。DECIMALフィールドでは暗黙の小数点位置を指定できるため、分数の値を表すこともできます。

DECIMALデータ型の構文は次のとおりです。


画像の説明

precisionパラメータは、数値の桁数です。DECIMALフィールドのバイト長は、桁数から計算します。(N+1/2)を求め、その小数点以下を切り上げた値がバイト長となります。

scaleパラメータは、小数点の右側にくる桁数のことで、スケール変更係数と呼びます。デフォルト値は0(ゼロ)です(整数となります)。全体の桁数より大きい数は指定できますが、負数は指定できません。

次に例を示します。

sal DECIMAL (7,2) 

この例では、+12345.67の形式の数値がロードされます。このフィールドは、データ・レコード中で4バイトを占有します。(DECIMALフィールドのバイト長は、(N+1)/2の小数点以下を切り上げた値になります。ここで、Nは数値の桁数です。また、1は符号用として追加されています。)

VARGRAPHIC

このデータは、可変長のダブルバイト・キャラクタ・セット(DBCS)です。lengthサブフィールドおよびダブルバイト文字の文字列で構成されます。ダブルバイト・キャラクタ・セットは、Oracleデータベースではサポートされていないため、SQL*Loaderを使用してシングルバイトとして読み込み、RAWデータとしてロードします。RAWデータ型と同様、VARGRAPHICフィールドは変更されずに指定の列に格納されます。


注意:

lengthサブフィールドのサイズには、システム上のSQL*LoaderのSMALLINTデータ型の長さ(C言語のSHORT INT型に相当する長さ)が取られます。詳細は、「SMALLINT」を参照してください。 


VARGRAPHICは、SHORT INTの長さが同じバイト数のシステム間でのみ、正しい結果でロードできます。バイト順序がシステム間で異なる場合は、適切な方法でlengthサブフィールドのバイト順序を指定します。詳細は、「バイト順序」を参照してください。

VARGRAPHICデータ型の構文は次のとおりです。


画像の説明

現行のフィールドの長さは、先頭の2バイトで示されます。VARGRAPHICデータ型に指定する最大長(maximum_length)には、lengthサブフィールドの長さは含まれません。この最大長には、グラフィック(ダブルバイト)文字の文字数を指定します。フィールドのバイト単位の最大長を決定するには、このmaximum_lengthの値を2倍します。

フィールド最大長のデフォルトは、グラフィック文字で2KB、つまり4KB(2×2KB)です。必要なメモリーを最小限にするには、このような可変フィールドに対して、できるだけ最大長を指定します。

VARGRAPHIC文の前に位置指定が指定されている場合、(pos_specを使用して)グラフィック文字の1文字目ではなく、lengthサブフィールドの位置がわかります。pos_specstart:end)を指定すると、endの位置によってそのフィールドの最大長が決まります。ここでのstartendは、そのファイルにおける1バイト単位の文字位置を示します。したがって、(end + 1)からstartの値を引くと、フィールドの実際のバイト長が求められます。最大長を指定した場合は、その最大長の方が、位置指定から計算された最大長より優先されます。

VARGRAPHICフィールドのフィールド長全体が、読み込まれる前に論理レコードの終わりで切り捨てられた場合、警告が出力されます。VARGRAPHIC型のフィールド長は、そのフィールドの各入力データ中に埋め込まれているため、そのフィールド長の方が正確であるとみなされます。

VARGRAPHICデータに対してはデリミタを使用できません。

VARCHAR

VARCHARフィールドは、LENGTH-VALUEデータ型です。バイナリのlengthサブフィールドおよびその長さを持つ文字列で構成されます。データ・ファイルに文字長セマンティクスが使用されないかぎり、長さはバイト単位です。文字長セマンティクスが使用される場合は、文字単位になります。詳細は、「文字長セマンティクス」を参照してください。

VARCHARフィールドは、SHORTデータ・フィールドINTの長さが同じバイト数のシステム間のみで、正しい結果でロードできます。バイト順序がシステム間で異なる場合、またはVARCHARフィールドにUTF-16キャラクタ・セットのデータが含まれている場合は、適切な方法でlengthサブフィールドおよびデータのバイト順序を指定します。データのバイト順序は、UTF-16キャラクタ・セットに対してのみ問題となります。詳細は、「バイト順序」を参照してください。


注意:

lengthサブフィールドのサイズには、システム上のSQL*LoaderのSMALLINTデータ型の長さ(C言語のSHORT INT型に相当する長さ)が取られます。詳細は、「SMALLINT」を参照してください。 


VARCHARデータ型の構文は次のとおりです。


画像の説明

制御ファイルに指定する最大長(maximum_length)には、lengthサブフィールドのサイズを含むことはできません。VARCHARデータ型にオプションで最大長を指定すると、そのサイズ分のバッファがこのフィールドに対してバイト単位で割り当てられます。ただし、文字長セマンティクスがデータ・ファイルに使用される場合、バイト単位のバッファ・サイズは、キャラクタ・セット内の最大限の文字のバイト単位のサイズのmax_length倍となります。詳細は、「文字長セマンティクス」を参照してください。

デフォルトの最大サイズは4KBです。データのロードに必要な最小限の値を最大値として指定することによって、SQL*Loaderで使用されるメモリーを最小限に抑えることができます。特に、VARCHARフィールドを多数使用する場合有効です。

POSITION句を使用する場合、指定する位置は、テキスト文字の先頭ではなく、lengthサブフィールドのバイト単位の位置になります。POSITION(start:end)と指定すると、endの位置によってそのフィールドの最大長が決まります。したがって、(end + 1)からstartの値を引くと、フィールドの実際のバイト長が求められます。最大長を指定した場合は、その最大長の方がPOSITION句から計算された長さよりも優先されます。

VARCHARフィールドのフィールド長全体が読み込まれる前に、論理レコードの終わりで切り捨てられた場合、警告が出力されます。VARGRAPHIC型のフィールド長は、そのフィールドの各入力データ中に埋め込まれているため、そのフィールド長の方が正確であるとみなされます。

VARGRAPHICデータに対してはデリミタを使用できません。

VARRAW

VARRAWは、2バイトのバイナリのlengthサブフィールドおよびその後に続くRAW文字列のVALUEサブフィールドで構成されています。

デフォルトでは、VARRAWは、lengthサブフィールドが2バイトで、最大サイズが4KBのVARRAWになります。VARRAW(65000)は、lengthサブフィールドが2バイトで、最大サイズが65000バイトのVARRAWになります。

VARRAWフィールドは、適切な方法でlengthサブフィールドのバイト順序を指定すると、異なるバイト順序のシステム間でロードできます。詳細は、「バイト順序」を参照してください。

LONG VARRAW

LONG VARRAWは、2バイトのlengthサブフィールドではなく、4バイトのlengthサブフィールドを持つVARRAWです。

デフォルトでは、LONG VARRAWは、lengthサブフィールドが4バイトで、最大サイズが4KBのVARRAWになります。LONG VARRAW(300000)は、lengthサブフィールドが4バイトで、最大サイズが300000バイトのVARRAWになります。

LONG VARRAWフィールドは、適切な方法でlengthサブフィールドのバイト順序を指定すると、異なるバイト順序のシステム間でロードできます。詳細は、「バイト順序」を参照してください。

移植可能なデータ型

移植可能なデータ型は、VALUEデータ型およびLENGTH-VALUEデータ型に分類されます。移植可能なVALUEデータ型は次のとおりです。

移植可能なLENGTH-VALUEデータ型は次のとおりです。

これらのデータ型の構文の詳細は、「datatype_spec」の構文図を参照してください。

文字データ型には、CHAR型、DATE型および数値型EXTERNAL型があります。これらのフィールドにはデリミタを使用できます。また、制御ファイルにフィールド長(または最大長)を指定することができます。

CHAR

このデータ・フィールドには、文字データが入ります。データ長には最大長を指定します(オプション)。データ長については、次のことにも注意してください。

CHARデータ型の構文は次のとおりです。


画像の説明

参照:

「デリミタの指定」 

日時データ型および期間データ型

日時および期間の両方ともフィールドで構成されています。これらのフィールドの値によってデータ型の値が決定されます。

日時データ型には次のものがあります。

日時データ型の値は、Datetimesと呼ばれる場合があります。次に説明する日時データ型(DATEを除く)では、オプションでfractional_second_precisionの値を指定できます。fractional_second_precisionには、SECOND日時フィールドの小数部分に格納する桁数を指定します。このデータ型の列を作成する場合は、値を0〜9に指定できます。デフォルトは6です。

期間データ型には次のものがあります。

期間データ型の値は、Intervalsと呼ばれる場合があります。INTERVAL YEAR TO MONTHデータ型では、オプションでyear_precisionの値を指定できます。year_precisionには、YEAR日時フィールドの桁数を指定します。デフォルトは2です。

INTERVAL DAY TO SECONDデータ型では、オプションでday_precisionおよびfractional_second_precisionの値を指定できます。day_precisionには、DAY日時フィールドの桁数を指定します。指定できる値は0〜9で、デフォルトは2です。fractional_second_precisionには、SECOND日時フィールドの小数部分に格納する桁数を指定します。このデータ型の列を作成する場合は、値を0〜9に指定できます。デフォルトは6です。

参照:

fractional_second_precisionyear_precisionおよびday_precisionを使用する、日時データ型と期間データ型の指定の詳細は、『Oracle Database SQLリファレンス』を参照してください。 

DATE

DATEフィールドには文字データが入り、その文字データは、指定された日付マスクを使用してOracleの日付に変換されます。DATEフィールドの構文は次のとおりです。


画像の説明

次に例を示します。

LOAD DATA 
INTO TABLE dates (col_a POSITION (1:15) DATE "DD-Mon-YYYY") 
BEGINDATA 
1-Jan-2002 
1-Apr-2002 28-Feb-2002 

デリミタがない場合、空白は無視され、日付は左から右に構文解析されます(DATEフィールドのデータがすべて空白の場合、NULLフィールドとしてロードされます)。

可変長の日付マスクを指定していない場合、データ長の指定はオプションになります。データ・ファイルに文字長セマンティクスが使用されないかぎり、長さはバイト単位です。文字長セマンティクスが使用される場合は、文字単位になります。詳細は、「文字長セマンティクス」を参照してください。

前述の例では、日付マスク"DD-Mon-YYYY"は、バイト長セマンティクスで11バイトあります。そのため、SQL*Loaderによってこのフィールドの最大文字数が11文字とみなされ、前述の指定は正しく処理されます。ただし、次のように指定される場合は注意が必要です。

DATE "Month dd, YYYY" 

この場合、日付マスクは14バイトです。"September 30, 1991"などのように14バイトを超える長さの値が指定されている場合は、長さを指定する必要があります。

同様に、ユリウス日(日付マスク「J」)の場合も長さを指定する必要があります。日付文字列の長さがマスクの長さ(マスク内のバイト数)を超える可能性がある場合は、必ずフィールド長を指定してください。

長さを明示的に指定していない場合は、POSITION句から長さが求められます。マスクを使用するときは、データ長がマスクの長さ以下であることが確実でないかぎり、常に長さを指定してください。

長さを明示的に指定した場合、この長さは、POSITION句で指定された長さよりも優先されます。これらはいずれも、マスクから求められる長さより優先されます。マスクについては、Oracle日付マスクとして有効なものを指定します。マスクの指定を省略すると、デフォルトのOracle日付マスク「dd-mon-yy」が使用されます。

データ長は小カッコで囲み、マスクは引用符で囲む必要があります。

DATE型のフィールドでは、デリミタも使用できます。詳細は、「デリミタの指定」を参照してください。

TIME

TIMEデータ型には、時、分、秒の値が格納されます。次のように指定します。

TIME [(fractional_second_precision)]

TIME WITH TIME ZONE

TIME WITH TIME ZONEデータ型は、タイムゾーンの置換えを含むTIMEデータ型の変形です。タイムゾーンの置換えは、ローカル時刻とUTCの差(時および分)です。次のように指定します。

TIME [(fractional_second_precision)] WITH [LOCAL] TIME ZONE

LOCALオプションが指定されている場合、データベースに格納されているデータはデータベース・タイムゾーンに指定されます。データが取得されると、ユーザーのローカル・セッション・タイムゾーンに返されます。

TIMESTAMP

TIMESTAMPデータ型は、DATEデータ型の拡張です。DATEデータ型の年、月、日に加えて、TIMEデータ型の時、分、秒の値を格納します。次のように指定します。

TIMESTAMP [(fractional_second_precision)]

日付値を指定する場合、時間構成要素を指定しないと、デフォルト時間の12:00:00 AM(真夜中)が採用されます。

TIMESTAMP WITH TIME ZONE

TIMESTAMP WITH TIME ZONEデータ型は、タイムゾーンの置換えを含むTIMESTAMPデータ型の変形です。タイムゾーンの置換えは、ローカル時刻とUTCの差(時および分)です。次のように指定します。

TIMESTAMP [(fractional_second_precision)] WITH TIME ZONE
TIMESTAMP WITH LOCAL TIME ZONE

TIMESTAMP WITH LOCAL TIME ZONEデータ型は、タイムゾーンの置換えを含むTIMESTAMPデータ型の変形です。データベースに格納されているデータは、データベース・タイムゾーンに指定されます。データが取得されると、ユーザーのローカル・セッション・タイムゾーンに返されます。次のように指定します。

TIMESTAMP [(fractional_second_precision)] WITH LOCAL TIME ZONE
INTERVAL YEAR TO MONTH

INTERVAL YEAR TO MONTHデータ型は、YEARおよびMONTH日時フィールドを使用して一定期間を格納します。次のように指定します。

INTERVAL YEAR [(year_precision)] TO MONTH
INTERVAL DAY TO SECOND

INTERVAL DAY TO SECONDデータ型は、DAYおよびSECOND日時フィールドを使用して一定期間を格納します。次のように指定します。

INTERVAL DAY [(day_precision)] TO SECOND [(fractional_second_precision)]

GRAPHIC

このデータは、ダブルバイト・キャラクタ・セット(DBCS)形式の文字列データです。ダブルバイト・キャラクタ・セットはOracleデータベースではサポートされていないため、SQL*Loaderを使用してシングルバイトとして読み込みます。RAWデータ型と同様、GRAPHICフィールドは変更されずに指定の列に格納されます。

GRAPHICデータ型の構文は次のとおりです。


画像の説明

GRAPHIC型およびGRAPHIC EXTERNAL型では、POSITION(start:end)を指定すると、論理レコードにおけるフィールドの正確な位置が決まります。

ただし、GRAPHIC (EXTERNAL)データ型にデータ長を指定する場合は、ダブルバイト・グラフィック文字の文字数を指定します。この値を2倍してフィールドのバイト長が求められます。グラフィック文字の長さを指定した場合は、POSITION句から求められたデータ長は無視されます。GRAPHICデータ型の指定では、データ・フィールドの区切りの指定はできません。

GRAPHIC EXTERNAL

DBCSフィールドがシフトイン/シフトアウト文字で囲まれている場合は、GRAPHIC EXTERNAL型を使用します。このデータ型は、データの先頭と最後の文字(シフトイン/シフトアウト文字)がロードされないことを除き、GRAPHIC型とほぼ同じです。

GRAPHIC EXTERNALデータ型の構文は次のとおりです。


画像の説明

GRAPHICは、ダブルバイト文字のデータであることを示します。EXTERNALは、先頭と最後の文字が無視されることを示します。graphic_char_lengthの値は、DBCSのデータ長を指定します(「GRAPHIC」を参照)。

たとえば、[ ]をシフトイン/シフトアウト文字とし、#を任意のダブルバイト文字とします。

[####]を表現する場合は、POSITION(1:4) GRAPHICまたはPOSITION(1) GRAPHIC(2)と指定します。

[####]を表現する場合は、POSITION(1:6) GRAPHIC EXTERNALまたはPOSITION(1) GRAPHIC EXTERNAL(2)と指定します。

数値型EXTERNAL

数値型EXTERNALデータ型は、数値データ型(INTEGER、FLOATDECIMALおよびZONED)にEXTERNAL、オプションのデータ長およびデリミタ指定を指定したものです。データ・ファイルに文字長セマンティクスが使用されないかぎり、長さはバイト単位です。文字長セマンティクスが使用される場合は、文字単位になります。詳細は、「文字長セマンティクス」を参照してください。

このデータ型は、判読可能な文字形式の数値データです。長さ、位置およびデリミタについては、CHARデータと同じ規則が数値型EXTERNALにも適用されます。これらの規則の詳細は、「CHAR」を参照してください。

数値型EXTERNALデータ型の構文は、「datatype_spec」を参照してください。


注意:

このデータは、バイナリ表現ではなく、文字形式の数字になります。したがって、これらのデータ型の処理方法は、DEFAULTIFを使用する場合を除き、CHARと同じです。デフォルトをNULLにする場合はCHARを使用します。デフォルトを0(ゼロ)にする場合はEXTERNALを使用します。詳細は、「WHEN、NULLIFおよびDEFAULTIF句の使用」を参照してください。 


FLOAT EXTERNALデータは科学表記法または通常表記法のどちらででも指定できます。「5.33」と「533E-2」は両方とも同じ値の正しい表現です。

RAW

RAW型のバイナリ・データが無条件でRAW型のデータベース列にロードされた場合、Oracleデータベースによるデータ変換は行われません。CHAR列にロードした場合は、Oracleデータベースによって、16進数にデータ変換されます。DATE型や数値型の列にはロードできません。

RAWデータ型の構文は次のとおりです。


画像の説明

ここで、lengthには制御ファイルに指定されたバイト数を指定します。この長さは、データベース中のターゲット列の長さとメモリー・リソースの許容範囲内であれば自由に指定できます。データ・ファイルに文字長セマンティクスが使用される場合でも、長さは常にバイト単位です。RAWデータ・フィールドに対してはデリミタは使用できません。

VARCHARC

VARCHARCデータ型は、文字のlengthサブフィールドおよびその後に続く文字列VALUEサブフィールドで構成されます。

VARCHARCに対する宣言には、lengthサブフィールドの長さが含まれます。また、オプションで文字列の最大サイズがその後に続く場合もあります。データ・ファイルにバイト長セマンティクスが使用される場合、長さおよび最大サイズはともにバイト単位です。データ・ファイルに文字長セマンティクスが使用される場合、長さおよび最大サイズはともに文字単位です。最大サイズが指定されていない場合、バイト長セマンティクスまたは文字長セマンティクスのいずれが使用されていても、デフォルトは4KBです。

次に例を示します。

詳細は、「文字長セマンティクス」を参照してください。

VARRAWC

VARRAWCデータ型は、RAW文字列のVALUEサブフィールドで構成されています。

次に例を示します。

システム固有のデータ型フィールド長の競合

フィールド長を指定する方法は数通りあります。それぞれの指定方法で異なる値を指定して、値が競合する場合は、そのうちの1つの値が優先されます。競合が発生した時点で警告が出されます。どのフィールド長を採用するかは、次の規則に基づいて決定されます。

  1. POSITION句で指定されたバイト数に関係なく、SMALLINTFLOATおよびDOUBLEのデータ・サイズは固定長です。

  2. DECIMALINTEGERZONEDGRAPHICGRAPHIC EXTERNALまたはRAWで指定されたフィールド長(または精度)が、POSITION(start:end)から計算されたサイズと異なる場合は、指定されたフィールド長(または精度)を採用します。

  3. 文字フィールドまたはVARGRAPHICフィールドにおいて指定された最大長が、POSITION(start:end)から計算されたフィールド長と異なる場合は、指定された最大長を採用します。

たとえば、システム固有のデータ型INTEGERが4バイトであるときに、次のようなフィールドが指定されたとします。

column1 POSITION(1:6) INTEGER 

この場合、警告が出力され、正しいフィールド長である4バイトが採用されます。実際に使用されたフィールド長は、ログ・ファイル内の列表の「Len」という見出しの箇所に記録されます。

Column Name             Position   Len  Term Encl Datatype 
----------------------- --------- ----- ---- ---- --------- 
COLUMN1                       1:6     4             INTEGER 

LENGTH-VALUEデータ型のフィールド長

制御ファイルで、LENGTH-VALUEデータ型の最大長(VARCHARVARCHARCVARGRAPHICVARRAWおよびVARRAWC)を指定できます。指定される最大長は、フィールドにバイト長セマンティクスが使用される場合はバイト単位で、文字長セマンティクスが使用される場合は文字単位です。最大長が指定されていない場合は、デフォルトで4096バイトとなります。フィールド長が最大長を超える場合、レコードは拒否され、次のエラーが表示されます。

Variable length field exceed maximum length

データ型の変換

制御ファイルに指定したデータ型で、データ・ファイル中のデータをどのように解釈するかを、SQL*Loaderに対して指定します。一方、サーバーでは、これとは別にデータベース中の列に対してデータ型を定義します。これらの2つのデータ型を対応付ける手がかりとなるのが、制御ファイル中に指定している列名です。

SQL*Loaderでは、入力ファイル中のフィールドからデータが抽出されます。抽出処理は、制御ファイルに指定したデータ型に基づいて行われます。次にSQL*Loaderでは、そのフィールドがサーバーに送信されます。送信されたフィールドは、該当する列に(行挿入配列の一部として)格納されます。

SQL*Loaderまたはサーバーでは、変換の必要なデータに対してデータ変換が行われ、適切な内部形式でデータが格納されます。これには、データ・ファイルのキャラクタ・セットとデータベースのキャラクタ・セットが異なる場合に、データ・ファイルのデータをデータベース用に変換する機能も含まれます。


注意:

SQL*Loaderの従来型パスを使用して、データ・ファイルの文字データをLONG RAW列にロードする場合、その文字データはHEX文字列として解釈されます。SQLは、HEX文字列をバイナリ表現に変換します。ここで、4000バイトより長い文字列は、SQL HEXTORAW変換演算子のバイト制限を超えていることに注意してください。したがって、SQLからOracleエラーORA-01461が返され、SQL*Loaderはその行を拒否してロードを続行します。 


入力ファイル中のデータ型は、Oracle表における列のデータ型に一致している必要はありません。データ型が一致していない場合、Oracleデータベース・サーバーで自動的に変換が行われます。ただし、変換が正常に実行されたか、エラーは発生していないかについては実行後に確認する必要があります。たとえば、CHARデータ型のデータ・ファイル・フィールドをNUMBER型のデータベース列にロードしたとします。この場合、その文字フィールドの値が有効な数値となっているかどうかを必ず確認してください。


注意:

SQL*Loaderには、NUMBERまたはVARCHAR2などのOracle内部データ型に関するデータ型指定は定義されていません。SQL*Loaderのデータ型として扱えるのは、テキスト・エディタで作成できるデータ(文字データ型)、および標準プログラミング言語で作成できるデータ(システム固有のデータ型)のみです。ただし、NUMBERおよびVARCHAR2のようなデータ型は、SQL*Loaderでは認識されませんが、これらのデータ型またはその他のデータ型のデータベース列に、Oracleデータベースで変換可能なデータをロードすることはできます。 


日時データ型および期間データ型のデータ型変換

表9-2に、Oracleデータベース・データ型とSQL*Loader制御ファイルの日時データ型および期間データ型の間でサポートされている変換およびサポートされていない変換を示します。

この表で使用されているOracleデータベース・データ型の略称は次のとおりです。

N: NUMBER

C: CHARまたはVARCHAR2

D: DATE

T: TIMEおよびTIME WITH TIME ZONE

TS: TIMESTAMPおよびTIMESTAMP WITH TIME ZONE

YM: INTERVAL YEAR TO MONTH

DS: INTERVAL DAY TO SECOND

SQL*Loaderデータ型でも、D、T、TS、YMおよびDSに関しては、表の略称の定義は同じです。ただし、前述のとおり、SQL*Loaderには、NUMBER、CHARVARCHAR2などのOracle内部データ型に関するデータ型指定は定義されていません。ただし、Oracleデータベースで変換可能なデータは、これらのデータ型やその他のデータ型のデータベース列にロードできます。

この表の読み方の例を、SQL*Loaderデータ型DATE(略称D)の行で示します。行全体を見ると、Oracleデータベース・データ型のCHARVARCHAR2DATETIMESTAMPおよびTIMESTAMP WITH TIMEZONEデータ型に対してデータ型変換がサポートされていることを確認できます。ただし、Oracleデータベース・データ型のNUMBERTIMETIME WITH TIME ZONEINTERVAL YEAR TO MONTHまたはINTERVAL DAY TO SECONDデータ型に対しては変換がサポートされていません。

表9-2    日時データ型および期間データ型のデータ型変換 
SQL*Loaderのデータ型  Oracleデータベース・データ型(変換のサポート) 

N 

N(可)、C(可)、D (不可)、T(不可)、TS(不可)、YM(不可)、DS(不可) 

C 

N(可)、C(可)、D(可)、T(可)、TS(可)、YM(可)、DS(可) 

D 

N(不可)、C(可)、D(可)、T(不可)、TS(可)、YM(不可)、DS(不可) 

T 

N(不可)、C(可)、D(不可)、T(可)、TS(可)、YM(不可)、DS(不可) 

TS 

N(不可)、C(可)、D(可)、T(可)、TS(可)、YM(不可)、DS(不可) 

YM 

N(不可)、C(可)、D(不可)、T(不可)、TS(不可)、YM(可)、DS(不可) 

DS 

N(不可)、C(可)、D(不可)、T(不可)、TS(不可)、YM(不可)、DS(可) 

デリミタの指定

CHAR、日時、期間または数値型EXTERNAL型のフィールドの境界は、特定のデリミタ文字を使用して、入力データ・レコード中に指定することもできます。RAWデータ型でもデリミタを使用できます。ただし、RAWデータ型が入力LOBFILEにある場合、およびデリミタがTERMINATED BY EOF(ファイルの終わり)の場合のみです。データ型指定の後にデリミタを指定して、フィールドをどのように区切るかを指定します。

次の構文に示すとおり、デリミタ付きデータは、終了デリミタまたは囲みデリミタで区切られます。


画像の説明

デリミタの指定には、TERMINATED BY句またはENCLOSED BY句(あるいはその両方)も使用できます。両方とも指定する場合はTERMINATED BY句を先に指定してください。enclosure_specおよびtermination_specの構文については、「終了および囲みの指定に関する構文」を参照してください。

TERMINATEDフィールド

TERMINATEDフィールドには、フィールドの開始位置から最初のデリミタ文字までのデータが読み込まれます(デリミタ文字自体は読み込まれません)。終了デリミタが最初の列位置にあれば、そのフィールドはNULLとなります。

TERMINATED BY WHITESPACEを指定すると、最初に空白文字(スペース、タブ、空白、LF、改ページまたは改行)が現れるまでデータが読み込まれます。空白文字が現れると、次に空白以外の文字が現れるまで連続する空白文字は読み込まれません。したがって、フィールド値の間に入る空白は、いくつあってもかまいません。

ENCLOSEDフィールド

ENCLOSEDフィールドの読取りでは、空白以外の文字が検出されるまで、空白文字はスキップされます。このとき、現れた空白以外の文字がデリミタの場合は、次のデリミタまでのデータが読み込まれます。現れた空白以外の文字がデリミタでない場合は、エラーとなります。

デリミタ文字が2つ続けて現れた場合は、1つのデリミタ文字のみがデータ値の一部として扱われます。たとえば'DON''T'は、DON'Tとして格納されます。ただし、フィールドに2つのデリミタのみ含まれている場合はNULL値となります。

終了および囲みの指定に関する構文

次の図に、termination_specおよびenclosure_specの構文を示します。


画像の説明


画像の説明

表9-3では、デリミタの指定に使用する、終了および囲みの指定に関する構文について説明します。

表9-3    デリミタの指定に使用するパラメータ 
パラメータ  説明 

TERMINATED 

データは、最初にデリミタが現れるまで読み込まれます。 

BY 

可読性を向上させるために使用されるオプションのワードです。 

WHITESPACE 

デリミタには、スペース、タブ、空白、LF、改ページ、改行などの任意の空白文字を使用できます。(TERMINATEDの場合のみ使用できます。ENCLOSEDでは使用できません。) 

OPTIONALLY 

指定する文字でデータを囲むこともできます。SQL*Loaderでは、この指定文字が最初に現れたところから、次に同じ文字が現れたところまでのデータ値が読み込まれます。データが囲まれていない場合は、終了デリミタ付きのフィールドとして読み込まれます。オプションで囲みデリミタを指定する場合は、必ずTERMINATED BY句を指定してください。その場合、フィールド定義の一部としてローカルに指定しても、FIELDS句の中でグローバルに指定してもかまいません。 

ENCLOSED 

データは2つのデリミタで囲まれます。 

string 

デリミタは文字列です。 

X'hexstr

デリミタには1文字を指定しますが、ここでは文字コード体系におけるX'hexstr'によって指定される値で、文字を指定します。たとえば、X'1F'(10進数の31)などのように指定します。「X」は大文字でも小文字でも使用できます。 

AND 

後続の囲みデリミタを指定する場合に使用します。後続の囲みデリミタには、先頭の囲みデリミタとは異なる文字を指定できます。AND句を指定しないと、先頭の囲みデリミタと後続の囲みデリミタは同じ文字とみなされます。 

EOF 

ファイル全体がLOBにロードされたことを示します。これは、LOBファイルからデータがロードされる場合のみ有効です。EOFによって終了するフィールドは囲むことができません。 

各指定方法によるデリミタの指定例およびそれぞれの場合の実際のデータの例を示します。

TERMINATED BY ','                      a data string, 
ENCLOSED BY '"'                        "a data string" 
TERMINATED BY ',' ENCLOSED BY '"'      "a data string", 
ENCLOSED BY '(' AND ')'                (a data string) 

データ中のデリミタ記号

デリミタとして定義した句読点を、データの中でも使用する必要があります。このような場合、デリミタ文字を2つ続けて記述すると、この文字は1文字のみ指定されたものと解釈され、データの一部として組み込まれます。たとえば、データベースに次の文字列を格納するとします。

(The delimiters are left parentheses, (, and right parentheses, )).) 

フィールド指定は次のようにします。

ENCLOSED BY "(" AND ")" 

この場合、データベースには次の文字列が格納されます。

The delimiters are left parentheses, (, and right parentheses, ). 

このため、隣接するフィールドが同じデリミタを使用すると、問題が発生します。たとえば、次のように指定されている場合、

field1 TERMINATED BY "/" 
field2 ENCLOSED by "/" 

次のデータは正しく解釈されます。

This is the first string/      /This is the second string/ 

ただし、field1およびfield2が次のように隣接している場合、誤った処理が行われます。

This is the first string//This is the second string/ 

この場合、このデータ全体が、中央に1つの「/」のみを持つ単一の文字列とみなされ、field1に属するものと解釈されてしまいます。

デリミタ付きデータの最大長

デリミタ付きデータの最大長のデフォルトは、255バイトです。したがって、デリミタ付きフィールドでは、バインド配列に対して記憶域が大量に使用される場合があります。フィールドが255バイトより短い場合、最大長にはできるだけ小さい値を指定してください。フィールドが255バイトより長い場合は、フィールド長指定子またはPOSITION句を使用して、フィールドに最大長を指定する必要があります。

たとえば、文字列リテラルが255バイトより長い場合は、SUBSTR()およびCHAR()を使用して、フィールドのすべてのレコードの中で最も長い文字列を指定します。たとえば、field1のすべてのレコードの中で最も長い文字列が600バイトの場合は、次のようになります。

field1 CHAR(600) SUBSTR(:field, 1, 240)

デリミタを使用した後続の空白のロード

後続の空白は、PRESERVE BLANKSを指定しないかぎり、デリミタなしのデータ型ではロードされません。たとえば、データ・フィールド長が9文字で、DANIELbbbという値のデータがあるとします。ここでのbbbは3つの空白を示します。このとき、CHAR(9)と宣言されていると、Oracleデータベースには「DANIEL」がロードされます。

この例で後続の空白も必要な場合は、CHAR(9) TERMINATED BY ':'と宣言し、さらにデータ・ファイルにコロンを追加してフィールドをDANIELbbb:とします。このフィールドは、後続の空白とともに、"DANIEL "としてロードされます。TERMINATED BY句を使用しないでPRESERVE BLANKSを指定し、同じ結果を得ることもできます。

参照:

 

文字データ型フィールド長の競合

CHAR型、DATE型、数値型EXTERNAL型の文字データ型の場合は、そのフィールド長を制御ファイルに複数指定できます。複数指定したときの長さが異なり、値が競合する場合は、そのうちの1つが優先されます。競合が発生すると、警告が出力されます。この項では、指定された長さのうちのどれが優先されるかについて説明します。

事前にサイズが決まっているフィールド

前述のデータ型のフィールドに対して開始位置と終了位置を指定すると、そのフィールド長は指定された開始/終了位置から求められます。データ型指定の中で長さを指定し、終了位置は指定しない場合、データ型指定の中で指定された長さがそのフィールド長になります。開始位置、終了位置および長さがすべて指定されていて、その長さが異なる場合は、次のように、データ型指定の中で指定されている長さがフィールド長として使用されます。

POSITION(1:10) CHAR(15) 

この場合、このフィールド長は15になります。

デリミタ付きフィールド

デリミタ付きフィールドに長さを指定した場合、または開始位置と終了位置から長さを計算できる場合は、その長さがフィールドの最大長となります。指定される最大長は、フィールドにバイト長セマンティクスが使用される場合はバイト単位で、文字長セマンティクスが使用される場合は文字単位です。長さが指定されていない場合、または開始位置と終了位置から長さが計算できない場合は、最大長のデフォルトは255バイトです。実際の長さはデリミタの位置によって変わりますが、長さの上限はこの最大長の値となります。

フィールドにデリミタのみでなく、開始位置および終了位置が指定されている場合は、位置指定のみが影響します。囲みデリミタまたは終了デリミタは無視されます。

デリミタが見つからない場合は、レコードの終わりがフィールドの終端となります。TRAILING NULLCOLSが指定されている場合は、残りのフィールドにはNULL値が設定されます。デリミタまたはレコードの終端で区切った結果、フィールド長が最大長よりも大きくなる場合は、SQL*Loaderによってレコードが拒否され、エラーが返されます。

日付フィールド・マスク

マスクを指定した場合、日付フィールド長は、使用するマスクによって異なります。指定されたマスクによって形式が決定され、SQL*Loaderではその形式に基づいてレコード中のデータが解釈されます。たとえば、次のようなマスクを指定したとします。

"Month dd, yyyy" 

この場合、「May 3, 1991」はレコード(バイト長セマンティクスを含む)中で11バイトを占有し、「January 31, 1992」は16バイトを占有することになります。

ただし、開始位置および終了位置を指定すると、この位置指定から計算されるフィールド長は、マスクから求められるフィールド長よりも優先されます。DATE(12)のようにフィールド長が指定された場合は、このフィールド長が最優先となります。日付フィールドが、終了デリミタまたは囲みデリミタでも区切られている場合は、制御ファイル中で指定された長さがそのフィールドの最大長と解釈されます。

参照:

DATEフィールドの詳細は、「日時データ型および期間データ型」を参照してください。 

フィールド条件の指定

フィールド条件とは、論理レコード中のフィールドに関して、それが真か偽かを評価する条件を記述したものです。フィールド条件は、WHEN句、NULLIF句およびDEFAULTIF句で使用します。


注意:

句の評価に使用するフィールドにNULL値が含まれている場合、常に、その句はFALSEと評価されます。この機能を例9-5に示します。 


フィールド条件は、CONTINUEIF句の中で指定する条件と同様ですが、次の2つの点で異なります。第1に、フィールド条件で指定する位置は、物理レコードではなく論理レコードの位置を示します。第2に、論理レコード内の位置またはデータ・ファイル内のフィールド名(FILLERフィールドを含む)のいずれかを指定できます。


注意:

フィールド条件は、SDFのフィールドに基づくことができません。 


field_condition句の構文は次のとおりです。


画像の説明

pos_spec句の構文は次のとおりです。


画像の説明

表9-4では、フィールド条件句のパラメータについて説明します。位置指定パラメータの詳細は、表9-1を参照してください。

表9-4    フィールド条件句のパラメータ 
パラメータ  説明 

pos_spec 

論理レコード中の比較対象フィールドの開始および終了位置です。それらの位置は小カッコで囲んでください。start-endと表記することも、start:endと表記することもできます。

開始位置の指定は、列番号、*(次の列)または*+n(次の列にオフセット分を加算)の形式で指定できます。

終了位置を省略した場合、フィールド長は、比較文字列の長さから判断されます。対象フィールドと比較文字列の長さが異なるときは、短い方を埋めるために文字列が追加されます。文字列の場合は空白が追加され、16進数のバイト列の場合は0(ゼロ)が追加されます。 

start 

論理レコード中の比較対象フィールドの開始位置です。 

end 

論理レコード中の比較対象フィールドの終了位置です。 

full_fieldname 

full_fieldnameには、ドット表記法を使用してフィールドのフルネームを指定します。フィールドcol2が列オブジェクトcol1の属性の場合、指示句の中でcol2 を参照するときは、col1.col2と表記してください。同じエンティティを参照および命名している列名およびフィールド名があっても、列名には、エンティティのフルネームを指定できない(ドット表記法がない)ため、別のものとして認識されます。 

operator 

比較演算子として、等価または不等価を示す記号を指定します。 

char_string 

比較フィールドとの比較に使用する文字列で、一重引用符または二重引用符で囲んで指定します。比較の結果が真の場合は、現在のレコードが表に挿入されます。 

X'hex_string

16進数の文字列で、16進数2桁がフィールドの1バイトに相当します。一重引用符または二重引用符で囲まれます。比較の結果が真の場合は、現在のレコードが表に挿入されます。 

BLANKS 

フィールドが完全に空白かどうかをテストできます。BLANKSの指定は、デリミタ付きデータのロード時にフィールド長が予測できない場合、または空白が複数あるマルチバイト・キャラクタ・セットを使用する場合に必要となります。 

フィールドとBLANKSの比較

BLANKSパラメータを使用すると、長さが不明なフィールドのデータが空白かどうかを知ることができます。

次の指定を実行すると、空白のフィールドにNULL値を設定できます。

full_fieldname ... NULLIF column_name=BLANKS 

BLANKSパラメータが認識できるのは空白のみです。タブは認識できません。BLANKSは、どのようなフィールド比較の場合でも、比較文字列のかわりに指定できます。列の値がすべて空白のときにのみ条件が真となります。

BLANKSは、固定長フィールドに対しても指定できます。その場合は、対象フィールドに合った長さの空白文字列を指定したのと同じことになります。たとえば、次の2つの指定はどちらも同じことを意味します。

fixed_field CHAR(2) NULLIF fixed_field=BLANKS 
fixed_field CHAR(2) NULLIF fixed_field="  " 

マルチバイト・キャラクタ・セットには複数の空白が存在することもあります。このようなキャラクタ・セットには、空白文字列を指定するかわりにBLANKSを使用します。

文字列は特定の空白文字の組合せのみに一致しますが、BLANKSパラメータは様々な空白文字の組合せに一致します。マルチバイト・キャラクタ・セットの詳細は、「マルチバイト(アジア系言語)・キャラクタ・セット」を参照してください。

フィールドと文字列の比較

データ・フィールドが、それより短い比較文字列と比較された場合は、その文字列が埋め込まれます。文字データ型の文字列には、次のように空白が埋め込まれます。

NULLIF (1:4)=" " 

この例では、位置1:4にあるデータが4つの空白と比較されます。位置1:4のデータが空白4つであれば、この句は真となります。

次の句のように、16進文字列には16進数のゼロが埋め込まれます。

NULLIF (1:4)=X'FF' 

この句で、データ位置1:4を16進数のバイト列'FF000000'と比較します。

WHEN、NULLIFおよびDEFAULTIF句の使用

次の説明は、スカラー・フィールドに適用されます。非スカラー・フィールド(列オブジェクト、LOBおよびコレクション)はより複雑なため、WHENNULLIFおよびDEFAULTIF句は異なる方法で処理されます。

WHENNULLIFまたはDEFAULTIF句は、フィールド名を指定するか、フィールド位置を指定するかによって、結果が異なります。

フィールドに切り捨てられた空白がある場合、あるいはWHENNULLIFまたはDEFAULTIF句に空白およびタブが含まれているか、BLANKSパラメータが使用されている場合は、異なる結果が得られます。名前で指定されているフィールドおよび位置で指定されているフィールドに対して同じ結果が必要な場合は、PRESERVE BLANKSオプションを使用します。PRESERVE BLANKSオプションによって、フィールド値の評価時にSQL*Loaderによって空白文字が切り捨てられないようにします。

WHENNULLIFまたはDEFAULTIF句は、SQL*Loaderの処理手順によっても結果に影響します。SQL*Loaderは次の手順を順番に実行します。ただし、すべての手順を実行するわけではありません。フィールドが設定されると、設定作業の残りの手順は無視されます。たとえば、手順5でフィールドが設定された場合、SQL*Loaderは手順6には進みません。

  1. SQL*Loaderで、入力レコードの各フィールドの値が評価され、空白およびタブの切り捨てに関する既存のガイドラインに従って、切り捨てる必要のある空白が切り捨てられます。

  2. 各レコードに対して、SQL*Loaderで表のWHEN句が評価されます。

  3. レコードが表のWHEN句を満たす場合、またはWHENが指定されていない場合は、SQL*Loaderで、NULLIF句の各フィールドが確認されます。

  4. NULLIF句が存在する場合は、SQL*Loaderで評価されます。

  5. NULLIF句が満たされている場合は、SQL*LoaderはフィールドがNULLに設定されます。

  6. NULLIF句が満たされていない場合、またはNULLIF句がない場合は、SQL*Loaderのフィールド評価によってフィールド長が確認されます。フィールドがフィールド評価の結果、0の長さを持っている場合(たとえば、NULLフィールドまたは結果としてNULLフィールドとなる空白の切捨て)は、SQL*LoaderでフィールドがNULLに設定されます。この場合、フィールドに指定されたDEFAULTIF句は評価されません。

  7. 指定されたNULLIF句が偽の場合、またはNULLIF句がない場合、およびフィールドがフィールド評価の結果、0の長さを持たない場合は、SQL*Loaderで、DEFAULTIF句に対するフィールドが確認されます。

  8. DEFAULTIF句が存在する場合は、SQL*Loaderで評価されます。

  9. DEFAULTIF句が満たされていて、データ・ファイルのフィールドが数値フィールドの場合、フィールドは0に設定されます。フィールドが数値フィールドではない場合、NULLに設定されます。次のフィールドは数値フィールドで、DEFAULTIF句を満たす場合は、0に設定されます。

    • BYTEINT

    • SMALLINT

    • INTEGER

    • FLOAT

    • DOUBLE

    • ZONED

    • (PACKED)DECIMAL

    • 数値型 EXTERNALINTEGERFLOATDECIMALおよびZONED

  10. DEFAULTIF句が満たされていない場合、またはDEFAULTIF句がない場合は、SQL*Loaderによって、手順1の評価値でフィールドが設定されます。

SQL*Loaderの操作順序が原因で、予期しない結果となる場合があります。たとえば、DEFAULTIF句は、数値フィールドを0ではなくNULLに設定しているように見える場合があります。


注意:

これらの手順に示したとおり、NULLIFおよびDEFAULTIF句を使用した場合は、SQL*Loaderによる処理が増えます。そのためパフォーマンスに影響する可能性があります。手順1では、0と評価されたフィールドは、SQL*LoaderによってNULL値に設定されます。パフォーマンスを向上させるには、この機能を利用するためにデータを変更できるかどうかを検討してください。手順1でのNULL値の検出は、NULLIF句またはDEFAULTIF句の処理よりはるかに迅速に行われます。

たとえば、CHAR(5)は、論理レコードの終わりまでに格納されない場合、またはすべての空白が含まれ、空白の切捨てが有効になっている場合は、データ長が0になります。デリミタで区切られたフィールドは、フィールドの開始と終了記号の間に文字がない場合、データ長が0になります。

また、文字フィールドの場合は、通常、NULLIFの方がDEFAULTIFより迅速に処理されます(文字フィールドのデフォルト値はNULLです)。 


WHEN、NULLIFおよびDEFAULTIF句の使用

例9-2から例9-5に、異なる条件でWHEN句、NULLIF句およびDEFAULTIF句を使用した場合の結果を示します。これらの例では、空白またはスペースはピリオド(.)で示されています。col1およびcol2は、データベースのVARCHAR2(5)列です。

例9-2    DEFAULTIF句の無評価

制御ファイルが次のように指定されています。

(col1 POSITION (1:5),
 col2 POSITION (6:8) CHAR INTEGER EXTERNAL DEFAULTIF col1 = 'aname')

データ・ファイルには、次のものが含まれます。

aname...

例9-2では、行のcol1anameと評価され、col2が長さが0(「...」ですが、後続の空白は位置フィールでは切り捨てられます)であるNULLと評価されます。

SQL*Loaderでcol2にロードされた最終値が確認される場合、WHEN句およびNULLIF句は評価されません。フィールド長(フィールド評価の結果、0と評価された長さ)が確認されます。したがって、SQL*Loaderでは、col2の最終値にNULLが設定されます。DEFAULTIF句は評価されず、行はcol1の場合はanamecol2の場合はNULLとしてロードされます。

例9-3    DEFAULTIF句の評価

制御ファイルが次のように指定されています。

.
.
.
PRESERVE BLANKS
.
.
.
(col1 POSITION (1:5),
 col2 POSITION (6:8) INTEGER EXTERNAL DEFAULTIF col1 = 'aname'

データ・ファイルには、次のものが含まれます。

aname...

例9-3では、行のcol1は再びanameと評価されます。col2は、PRESERVE BLANKSが指定された場合、後続の空白が切り捨てられないため、「...」と評価されます。

SQL*Loaderでcol2にロードされた最終値が確認される場合、WHEN句およびNULLIF句は評価されません。0でなく3と評価されたフィールド評価からフィールド長が確認されます。

次に、SQL*LoaderではDEFAULTIF句が評価されます。col1anameanameと同じであるため、真と評価されます。

col2は数値フィールドであるため、SQL*Loaderではcol2の最終値に0が設定されます。行は、col1の場合は「aname」、col2の場合は0としてロードされます。

例9-4    DEFAULTIF句を使用した位置の指定

制御ファイルが次のように指定されています。

(col1 POSITION (1:5), 
 col2 POSITION (6:8) INTEGER EXTERNAL DEFAULTIF (1:5) = BLANKS)

データ・ファイルには、次のものが含まれます。

.....123

例9-4では、行のcol1が、長さが0(.....ですが、後続の空白は切り捨てられます)のNULLと評価されます。col2は、123と評価されます。

SQL*Loaderでcol2にロードされる最終値が設定される場合、WHEN句およびNULLIF句は評価されません。0でなく3と評価されたフィールド評価からフィールド長が確認されます。

次に、SQL*LoaderではDEFAULTIF句が評価されます。.....である(1:5)を、真と評価されているBLANKSと比較されます。したがって、col2が数値フィールド(integer EXTERNALは数値)のため、SQL*Loaderではcol2の最終値に「0」が設定されます。行は、col1の場合はNULLcol2の場合は0としてロードされます。

例9-5    DEFAULTIF句を使用したフィールド名の指定

制御ファイルが次のように指定されています。

(col1 POSITION (1:5), 
 col2 POSITION(6:8) INTEGER EXTERNAL DEFAULTIF col1 = BLANKS)

データ・ファイルには、次のものが含まれます。

.....123

例9-5では、行のcol1が、長さが0.....ですが、後続の空白は切り捨てられます)のNULLと評価されます。col2は、123と評価されます。

SQL*Loaderでcol2の最終値が確認される場合、WHEN句およびNULLIF句は評価されません。0でなく3と評価されたフィールド評価からフィールド長が確認されます。

次に、SQL*LoaderではDEFAULTIF句が評価されます。評価の一部として、SQL*Loaderでは、col1のフィールド評価がNULLであることが確認されます。NULLのため、DEFAULTIF句は偽と評価されます。したがって、SQL*Loaderではcol2の最終値に、フィールド評価の元の値である123が設定されます。行は、col1の場合はNULLcol2の場合は123としてロードされます。

異なるプラットフォーム間でのデータのロード

データ・ファイルを作成するプラットフォームと、そのデータ・ファイルのロード先となるプラットフォームが異なる場合は、ターゲット・システムが読取り可能な形式でデータを作成する必要があります。たとえば、ソース・システムでは浮動小数点の内部表現に16バイトを使用し、ターゲット・システムでは浮動小数点を12バイトで表現しているとします。この場合、ソース・システムで生成されたデータを、ターゲット・システムに直接読み込ませることはできません。

この問題を解決する方法として、Oracle Netデータベース・リンクを使用してデータをロードし、データ型の自動変換機能を利用する方法があります。前述のような問題が発生した場合は、できるだけこの方法を使用してください。この場合、SQL*Loaderはソース・システムで実行する必要があります。

プラットフォーム間のロードに関する問題は、通常、システム固有のデータ型に関連して発生します。フィールドに0(ゼロ)を追加してフィールド長を長くするか、またはフィールドの一部分のみを読み込んでフィールド長を短くする(4バイト整数を使用しているシステム上に8バイト整数を読み込む場合、またはその逆のパターンがこれに相当)ことによって、問題を回避できる場合もあります。ただし、データ型の実装に互換性がない場合は、この方法で問題の解決はできません。

Oracle Netデータベース・リンクが使用できず、ターゲット・システム上で実行しているSQL*Loaderを使用してデータ・ファイルにアクセスする必要がある場合は、移植可能なSQL*Loaderデータ型(たとえば、CHARDATEVARCHARC、数値型EXTERNAL)のみを使用してください。このようにして作成したデータ・ファイルは、システム固有のデータ型を使用して作成したデータ・ファイルよりサイズが大きくなる場合があります。そのため、ロードに時間がかかりますが、異なるプラットフォームに直接転送することができます。

バイト順序スキームまたはシステム固有の整数の長さが、入力データが作成されるプラットフォームとSQL*loaderを実行するプラットフォームの間で異なることが事前にわかっている場合は、適切な方法で、データのバイト順序またはシステム固有の整数の長さを指定します。バイト順序を指定する方法には、BYTEORDERパラメータを使用する方法、またはファイルにバイト順序マーク(BOM)を設定する方法があります。この2つの方法の詳細は、「バイト順序」を参照してください。これらの方法を実行すると、非互換性を排除し、プラットフォーム間での正常なデータ・ロードを実現できます。バイト順序がSQL*Loaderのデフォルトと異なる場合は、バイト順序を指定する必要があります。

バイト順序


注意:

この項の説明は、SQL*Loaderを実行するシステムとは異なるバイト順序スキームを持つシステム上で入力データを作成する場合のみに適用されます。それ以外の場合は、次の項に進んでください。 


SQL*Loaderを使用して、SQL*Loaderが実行されているシステムとはバイト順序が異なるシステム上で作成されたデータ・ファイルからデータをロードできます。

デフォルトでは、すべてのデータ・ファイルに対するバイト順序として実行されているシステムのバイト順序が、SQL*Loaderで使用されます。たとえば、Sun SPARC Solarisシステム上では、SQL*Loaderでビッグ・エンディアン・バイト順序が使用されます。IntelまたはIntelと互換性のあるPC上では、SQL*Loaderでリトル・エンディアン・バイト順序が使用されます。

バイト順序は、データが一度に偶数バイト(通常、2バイト、4バイトまたは8バイト)書き込まれる場合、および読み込まれる場合の結果に影響します。次に例をいくつか示します。

バイト順序は、UTF16キャラクタ・セットの文字データが2バイトのエントリとして書き込まれる場合、および読み込まれる場合の結果にも影響します。たとえば、文字「a」(ASCIIでは0x61)は、ビッグ・エンディアン・システムでは0x0061、リトル・エンディアン・システムでは0x6100として書き込まれます。

Oracleでサポートされるすべてのキャラクタ・セットでは、UTF16を除いて、一度に1バイト書き込まれます。そのため、UTF8などのマルチバイト・キャラクタ・セットの場合も、文字の書込み、読取りには、システムのバイト順序に関係なく、すべてのシステムで同じ方法が使用されます。したがって、UTF16キャラクタ・セットのデータは、バイト順序依存のため移植不能です。Oracleでサポートされる他のすべてのキャラクタ・セットのデータは移植可能です。

データ・ファイルのバイト順序が問題となるのは、バイト順序依存データを含むデータ・ファイルが、SQL*Loaderが実行されているシステムとは異なるバイト順序のシステムで作成される場合のみです。SQL*Loaderでデータのバイト順序を認識できる場合、必要に応じてバイトを入れ替えて、データが正常にターゲット・データベースにロードされることを確認します。バイト・スワップとは、ビッグ・エンディアン形式のデータをリトル・エンディアン形式に変換すること、またはその逆の変換を意味します。

SQL*Loaderにデータのバイト順序を指定するには、BYTEORDERパラメータを使用するか、またはそのファイルにバイト順序マーク(BOM)を設定します。この2つの方法のいずれも使用しない場合、SQL*Loaderではデータを正常にデータ・ファイルにロードできません。

参照:

SQL*Loaderでのバイト・スワップの処理例については、「事例11: Unicodeキャラクタ・セットのデータのロード」を参照してください。(事例へのアクセス方法については、「SQL*Loaderの事例」を参照してください。) 

バイト順序の指定

入力データ・ファイルのデータのバイト順序を指定するには、SQL*Loader制御ファイルの次の構文を使用します。


画像の説明

BYTEORDERパラメータには、次の特長があります。

バイト順序マーク(BOM)の使用

Unicodeエンコーディング(UTF-16またはUTF-8)が使用されているデータ・ファイルには、ファイルの最初の数バイトにバイト順序マーク(BOM)が含まれている場合があります。キャラクタ・セットUTF-16が使用されているデータ・ファイルでは、ファイルの最初の2バイトの値0xFEFFは、ファイルがビッグ・エンディアンのデータを含んでいることを示すBOMです。0xFFFEという値は、ファイルにリトル・エンディアンのデータが含まれていることを示すBOMです。

第1プライマリ・データ・ファイルでUTF16キャラクタ・セットが使用され、BOMも使用されている場合は、SQL*Loaderでそのマークを読み込んで解釈し、すべてのプライマリ・データ・ファイルのバイト順序を決定します。SQL*Loaderで、BOMを読み込んで解釈し、スキップして、BOMの直後のバイトからデータを処理し始めます。BOM設定は、第1プライマリ・データ・ファイルに対するBYTEORDER指定より優先されます。第1プライマリ・データ・ファイル以外のデータ・ファイルのBOMは、バイト順序競合の確認のみに使用されます。データ・ファイルの処理中にSQL*Loaderで使用されるバイト順序の設定は変更されません。

つまり、第1プライマリ・データ・ファイルに対するバイト順序インジケータの優先順位は次のようになります。

UTF8キャラクタ・セットが使用されているデータ・ファイルでは、最初の3バイトの0xEFBBBFというBOMによって、ファイルにUTF8データが含まれていることが示されます。UTF8のデータはバイト順序依存ではないため、BOMではデータのバイト順序を指定しません。UTF8のBOMが検出された場合は、SQL*LoaderでBOMをスキップしますが、データ・ファイルの処理のためのバイト順序の設定変更は実行しません。

SQL*Loaderによって、まず、定義済の優先順位を使用して第1プライマリ・データ・ファイルのバイト順序設定を確立します。このバイト順位設定は、すべてのプライマリ・データ・ファイルに使用されます。別のプライマリ・データ・ファイルでキャラクタ・セットUTF16が使用され、BOMも含まれている場合、そのBOMの値は、第1プライマリ・データ・ファイルで確立されたバイト順序設定と比較されます。BOMの値が第1プライマリ・データ・ファイルのバイト順序設定と一致する場合は、SQL*LoaderでそのBOMをスキップし、そのバイト順序設定を使用して、BOMの直後のバイトからデータを処理し始めます。BOMの値が、第1プライマリ・データ・ファイルで確立されたバイト順序設定と一致しない場合は、SQL*Loaderでエラー・メッセージを発行し、処理を停止します。

LOBFILEまたはSDFが制御ファイルで指定される場合、ファイルを処理する準備が整うと、SQL*Loaderで各LOBFILEおよびSDFのバイト順序設定を確立します。LOBFILEおよびSDFのデフォルトのバイト順序設定は、第1プライマリ・データ・ファイルで確立されたバイト順序設定です。これは、BYTEORDERパラメータがLOBFILEまたはSDFで指定される場合は、上書きされます。いずれの場合も、LOBFILEまたはSDFでUTF16キャラクタ・セットが使用され、BOMが含まれている場合、BOMの値はファイルのバイト順序と比較されます。BOMの値がファイルのバイト順序設定と一致する場合は、SQL*LoaderでそのBOMをスキップし、そのバイト順序設定を使用して、BOMの直後のバイトからデータを処理し始めます。BOMの値が一致しない場合、SQL*Loaderからエラーが発行され、処理が停止します。

つまり、LOBFILEおよびSDFに対するバイト順序インジケータの優先順位は次のようになります。

BOMの確認の抑止

Unicodeキャラクタ・セットのデータ・ファイルには、ファイルの最初のバイトにBOMと一致するバイナリ・データが含まれています。たとえば、integer(2)型の値0xFEFF = 65279小数点は、UTF16のビッグ・エンディアンBOMと一致します。この場合、SQL*Loaderを使用してデータ・ファイルの最初のバイトをデータとして読み込むことができます。また、値NOCHECKBYTEORDERMARKパラメータを指定して、SQL*LoaderによってBOMの確認もできます。BYTEORDERMARKパラメータの構文は次のとおりです。


画像の説明

BYTEORDERMARK NOCHECKを指定すると、SQL*LoaderではBOMが確認されず、データ・ファイルのすべてのデータがデータとして読み込まれます。

BYTEORDERMARK CHECKを指定すると、SQL*LoaderでBOMが確認されます。これは、Unicodeキャラクタ・セットのデータ・ファイルのデフォルトの動作です。ただし、この仕様は説明のために制御ファイルで使用される場合があります。Unicode以外のキャラクタ・セットが使用されているデータ・ファイルにBYTEORDERMARK CHECKを指定すると、エラーが発生します。

BYTEORDERMARKパラメータには、次の特長があります。

すべてが空白のフィールドのロード

フィールドが完全に空白のレコードは拒否されます。これらのフィールドのいずれかをNULLとしてロードするには、BLANKSパラメータを持つNULLIF句を使用します。

空白のフィールドがCHAR型で、囲みデリミタによって囲まれている場合は、囲みデリミタで囲まれている空白部分がロードされます。囲みデリミタで囲まれていない場合は、そのフィールドはNULLとしてロードされます。

DATEフィールドまたは数値フィールドのデータがすべて空白の場合は、NULLフィールドとしてロードされます。

参照:

 

空白の切捨て

空白、タブおよびその他の印字されない文字(改行、LFなど)が空白を構成します。先頭の空白は、フィールドの開始位置にあります。後続の空白は、フィールドの終了位置にあります。フィールドの指定方法にもよりますが、空白は、フィールドのデータベースへの挿入時に、データの一部として含めることも切り捨てることもできます。これについて、図9-1に示します。この図では、2つのCHARフィールドがデータ・レコードに定義されています。

フィールド指定は制御ファイルに含まれています。制御ファイルのCHAR指定は、データベースのCHAR指定と同じではありません。制御ファイル内でCHARとして定義されたデータ・フィールドは、SQL*Loaderに行挿入の作成方法を指定するのみです。Oracleデータベースで必要な変換が行なわれ、データベースのCHARVARCHAR2NCHARNVARCHARNUMBERまたはDATE列にデータを挿入できるようになります。

デフォルトでは、SQL*Loaderを使用してCHARデータから後続の空白を削除した後、このデータをデータベースに渡します。その後、図9-1に示すとおり、フィールド1とフィールド2は3バイトのフィールドとしてデータベースに渡されます。ただし、データを表に挿入する場合は処理が異なります。

図9-1    フィールド変換の例


画像の説明

列1は、データベース内で長さ5の固定長CHAR列として定義されます。そのため、データ(aaa)は5バイトの幅を保持したまま、その列で左揃えにされます。余った右側の部分は空白で埋められます。一方、列2は、最大長5バイトの可変長フィールドとして定義されています。その列(bbb)のデータも左揃えにされますが、長さは3バイトのままです。

表9-5に、PRESERVE BLANKSが指定されていない場合に空白が入力データ・フィールドから切り捨てられるケースおよびその処理方法を示します。空白の切捨てを回避する方法については、「空白の切捨てに対するPRESERVE BLANKSオプションの影響」を参照してください。

表9-5    空白の切捨てに関する動作のサマリー 
指定  データ  結果  先頭の空白1  後続の空白1 

サイズ指定あり 

__aa__ 

__aa 

あり 

なし 

終了デリミタ 

__aa__, 

__aa__ 

あり 

あり2 

囲みデリミタ 

"__aa__" 

__aa__ 

あり 

あり 

終了と囲み 

"__aa__", 

__aa__ 

あり 

あり 

オプションの囲み(あり) 

"__aa__", 

__aa__ 

あり 

あり 

オプションの囲み(なし) 

__aa__, 

aa__ 

なし 

あり 

前のフィールドが空白で区切られている場合 

__aa__ 

aa3 

なし 

3 

1 空白のみのフィールドが切り捨てられた場合、値はNULL になります。

2 空白で終了するフィールドを除きます。

3 後続の空白があるかどうかは、表中の他の項目に示すとおり、現行のフィールドの指定によって異なります。

この項の残りの部分では、空白の切捨てに関する次の項目について説明します。

空白の切捨てが可能なデータ型

次の説明は、データ型が文字データ型であるフィールドにのみ適用できます。

空白の切捨てが可能なデータ型に対するフィールド長指定

フィールド長の指定には2通りの方法があります。制御ファイルで位置指定またはデータ型および長さについてフィールド長の定数を定義した場合、そのフィールドは、事前にサイズが決まっていることになります。一方、フィールド長を事前に指定しないでレコード中のインジケータでフィールド長を決める場合は、そのフィールドを囲みデリミタまたは終了デリミタのいずれかを使用して区切ります。

開始値および終了値を持つ位置指定は、囲みデリミタまたは終了デリミタが定義されるフィールドに対して定義されます。囲みデリミタまたは終了デリミタは無視されます。

事前にサイズが決まっているフィールド

フィールドのサイズを事前に決定するには、フィールドの開始位置と終了位置を指定するか、フィールド長を指定します。それぞれの指定例を示します。

loc POSITION(19:31) 
loc CHAR(14) 

2番目の例では、フィールド位置は指定されていませんが、フィールド長は事前に指定されています。

デリミタ付きフィールド

デリミタとは、フィールドの境界を指定する文字のことです。

囲みデリミタは、次の例("__"が空白またはタブを表す)中の引用符のように、フィールドを囲みます。

"__aa__"

一方、終了デリミタは、フィールドの終わりを示します。次の例中のカンマがこれに相当します。

__aa__, 

デリミタに使用する文字は、制御句TERMINATED BYおよびENCLOSED BYを使用して指定します。次に指定例を示します。

loc TERMINATED BY "." OPTIONALLY ENCLOSED BY '|' 

フィールドの相対的な位置指定

この項では、次の条件でSQL*Loaderを使用してフィールドの開始位置を決定する方法について説明します。

フィールドの開始位置が指定されていない場合

フィールドの開始位置が指定されていない場合は、前のフィールドの終了位置の直後の位置が、そのフィールドの開始位置となります。図9-2に、前のフィールド(フィールド1)のサイズが事前に決定されている場合の例を示します。

図9-2    固定長フィールドの後の相対的な位置指定


画像の説明

前のフィールドの終端がデリミタで指定されている場合

前のフィールド(フィールド1)の終端がデリミタで指定されている場合、次のフィールドはそのデリミタの直後から開始します。この例を図9-3に示します。

図9-3    デリミタ付きフィールドの後の相対的な位置指定


画像の説明

前のフィールドに囲みデリミタおよび終了デリミタの両方が含まれる場合

フィールドが囲みデリミタと終了デリミタの両方で指定された場合、その次のフィールドは終了デリミタの直後の位置から開始します。この例を図9-4に示します。囲みデリミタから終了デリミタまでの間に空白以外の文字がある場合は、エラーが出力されます。

図9-4    囲みデリミタの後の相対的な位置指定


画像の説明

先頭の空白

図9-4の例では、2つのフィールドはともに先頭の空白が付いた状態で格納されます。ただし、次のような場合、先頭の空白はフィールドのデータに含まれません。

これらの事例については、次の項で例示します。

前のフィールドが空白で区切られている場合 

前のフィールドがTERMINATED BY WHITESPACEで区切られていると、そのフィールドの後に続く空白はすべてデリミタとみなされます。この場合、次のフィールドは、次に空白以外の文字が現れた位置から開始します。この例を図9-5に示します。

図9-5    空白で区切られたフィールド


画像の説明

このようなケースは、前述の例のとおり前のフィールドがTERMINATED BY WHITESPACE句で明示的に指定された場合に発生します。グローバルにFIELDS TERMINATED BY WHITESPACE句が指定された場合も、このケースに相当します。

オプションの囲みデリミタ

オプションの囲みデリミタが指定されているにもかかわらず、それが使用されていない場合も、先頭の空白は切り捨てられます。

オプションの囲みデリミタが指定されると、SQL*Loaderによって前方スキャンが実行され、最初の囲みデリミタが検索されます。囲みデリミタがない場合は、空白がスキップされ、フィールドから削除されます。最初に見つかった空白以外の文字がフィールドの開始と判断されます。この例を図9-6のフィールド2に示します(フィールド1では、SQL*Loaderによってフィールドの囲みデリミタが検出されたため空白が含まれます)。

図9-6    オプションの囲みデリミタ付きフィールド


画像の説明

前のフィールドがTERMINATED BY WHITESPACEで区切られた場合と異なり、前述のように指定された場合は、現行のフィールドの開始位置が指定されていても先頭の空白は切り捨てられます。


注意:

囲みデリミタが存在する場合は、最初の囲みデリミタの後の先頭の空白はそのままデータとして保持されますが、この囲みデリミタの前にある空白は切り捨てられます。図9-6のフィールド1の最初の引用符がこのケースに相当します。 


後続の空白の切捨て

後続の空白は、フィールドが文字データ型で事前にフィールド・サイズが決まっている場合、常に切り捨てられます。後続の空白が常に切り捨てられるのは、これらのフィールドのみです。

囲まれたフィールドの切捨て

フィールドが囲みデリミタで囲まれている場合、または、図9-6の最初のフィールドのように終了デリミタと囲みデリミタの両方で区切られている場合、囲みデリミタの外側にある空白は、フィールドの一部とはみなされません。囲みデリミタの内側に空白があれば、それが先頭の空白または後続の空白のいずれであっても、フィールドの一部とみなされます。

空白の切捨てに対するPRESERVE BLANKSオプションの影響

すべてのCHARフィールド、DATEフィールド、および数値型EXTERNALフィールドで空白が切り捨てられないようにするには、制御ファイル内のLOAD文でPRESERVE BLANKSを指定します。ただし、CHARDATEまたは数値型EXTERNALフィールドのいずれかに空白を残す必要がない場合があります。その場合は、SQL*Loaderを使用して、PRESERVE BLANKSを、LOAD文でグローバルに指定するのではなく、個々のフィールドのデータ型指定で指定することもできます。

次の例では、PRESERVE BLANKSLOAD文で指定されていない場合に、空白を含むc1フィールドをデフォルトでゼロにします。これは、個々のフィールドに対してPRESERVE BLANKSを指定することで実現できます。指定したフィールドのみで空白が切り捨てられ、その他のフィールドでは空白はそのまま残されます。

c1 INTEGER EXTERNAL(10) PRESERVE BLANKS DEFAULTIF c1=BLANKS

この例では、PRESERVE BLANKSがフィールドに対して指定されていない場合、そのフィールドがNULL(0ではなく)として誤ってロードされます。

LOAD文に対するオプションとしてPRESERVE BLANKSを指定して、ほとんどのCHARDATEおよび数値型EXTERNALフィールドに適用する必要がある場合があります。このオプションの指定は、個々のフィールドのデータ型指定でNO PRESERVE BLANKSを指定して上書きできます。次に例を示します。

c1 INTEGER EXTERNAL(10) NO PRESERVE BLANKS

[NO] PRESERVE BLANKSとデリミタ句の併用

デリミタ句が指定されていると、PRESERVE BLANKSオプションに次のような影響があります。

たとえば、次のフィールドについて考えてみます。ここでは、アンダースコアは空白を表します。

__aa__, 

このフィールドが次のデリミタ句でロードされるとします。

TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' 

この場合、PRESERVE BLANKSを指定すると、先頭の空白および後続の空白がともに保存されます。PRESERVE BLANKSを指定しない場合は、先行する空白は切り捨てられます。

次に、このフィールドが次の句でロードされるとします。

TERMINATED BY WHITESPACE

この場合、PRESERVE BLANKSを指定すると、次のフィールドの先頭の空白は、このフィールドが空白を含むPOSITION句で指定されていないかぎり保存されません。このようなPOSITION句の指定がない場合は、SQL*Loaderによって前のフィールドの終わりにあるすべての空白を読み込まずにスキャンが実行され、次に空白以外の文字またはタブ以外の文字が現れた位置が次のフィールドの開始位置と認識されます。

参照:

「空白の切捨て」 

フィールドへのSQL演算子の適用

SQL文字列を使用することによって、様々なSQL演算子をフィールド・データに適用できます。SQL文字列には、任意に組み合せたSQL式を組み込むことができます。ただし、このSQL式は、OracleデータベースによってINSERT文中のVALUES句に対して有効であると認識されたものにかぎります。通常、ターゲット列のデータ型と互換性のある単一の値を返すSQL関数を使用できます。SQL文字列は、列オブジェクトおよびコレクションなどのユーザー定義の複合型に加えて、単純なスカラー列型にも適用できます。式の詳細は、『Oracle Database SQLリファレンス』を参照してください。

列名とSQL文字列のバインド変数における列名は、SQL識別子のルールによる解釈の結果、同じ列に対応している必要があります。ただし、次の制御ファイルの指定例に示すとおり、2つの名前を完全に同じ記述にする必要はありません。

LOAD DATA 
INFILE * 
APPEND INTO TABLE XXX 
( "Last"   position(1:7)     char   "UPPER(:\"Last\")" 
   first   position(8:15)    char   "UPPER(:first || :FIRST || :\"FIRST\")" 
) 
BEGINDATA 
Phil Grant 
Jason Taylor 

前述の例では、次のことに注意してください。

次の要件および制限はSQL文字列を使用している場合に適用されます。

フィールドの参照

レコード中のフィールドを参照する場合は、フィールド名の前にコロン(:)を付けます。このように指定すると、現在のレコードのフィールド値が代入されます。SQL文字列で、前にコロン(:)が付いたフイールド名もバインド変数として参照されます。次の例では、制御ファイルの現行のフィールドおよび他のフィールドの参照方法を示します。

LOAD DATA
INFILE *
APPEND INTO TABLE YYY
(
 field1  POSITION(1:6) CHAR "LOWER(:field1)"
 field2  CHAR TERMINATED BY ','
         NULLIF ((1) = 'a') DEFAULTIF ((1)= 'b')
         "RTRIM(:field2)"
 field3  CHAR(7) "TRANSLATE(:field3, ':field1', ':1')",
 field4  COLUMN OBJECT
 (
  attr1  CHAR(3)  "UPPER(:field4.attr3)",
  attr2  CHAR(2),
  attr3  CHAR(3)  ":field4.attr1 + 1"
 ),
 field5  EXPRESSION "MYFUNC(:FIELD4, SYSDATE)"
)
BEGINDATA
ABCDEF1234511  ,:field1500YYabc
abcDEF67890    ,:field2600ZZghl

前述の例では、次のことに注意してください。

フィールド指定でのSQL演算子の共通使用

次のタスクでは、共通してSQL演算子が使用されています。

SQL演算子の組合せ

複数の演算子を次の例のように組み合せることができます。

field1 POSITION(*+3) INTEGER EXTERNAL
       "TRUNC(RPAD(:field1,6,'0'), -2)"
field1 POSITION(1:8) INTEGER EXTERNAL
       "TRANSLATE(RTRIM(:field1),'N/A', '0')"
field1 CHAR(10)
       "NVL( LTRIM(RTRIM(:field1)), 'unknown' )"

日付マスク付きのSQL文字列の使用

日付マスクと併用する場合、日付マスクはSQL文字列の後で評価されます。次のように指定されるフィールドがあるとします。

field1 DATE "dd-mon-yy" "RTRIM(:field1)"

SQL*Loaderの内部で次の文が生成され、挿入されます。

TO_DATE(RTRIM(<field1_value>), 'dd-mon-yyyy')

DATEフィールド・データ型を使用する場合、日付マスクなしのSQL文字列は使用できないことに注意してください。これは、SQL*Loaderで、DATEパラメータの後の最初の引用符付き文字列が日付マスクであるとみなされるためです。たとえば、次のフィールド指定では、エラー(ORA-01821: 日付書式コードが無効です)が発生します。

field1 DATE "RTRIM(TO_DATE(:field1, 'dd-mon-yyyy'))"

この場合、単純な解決策としては、CHARデータ型を使用します。

書式化されたフィールドの解析

TO_CHAR演算子を使用して、書式化された日付および数値を格納できます。次に例を示します。

field1 ... "TO_CHAR(:field1, '$09999.99')"

この例では、数値型の入力データを、書式化された形式で格納することができます。この場合、field1はデータベース中ではキャラクタ列です。この指定にある書式化文字(ドル記号やピリオドなど)は、データとともにそのままフィールドに格納されます。

ただし、このような値を数量や日付として格納すると、より柔軟な処理を行うことができます。この場合、データベース内の値に算術関数を指定しても、書式化された値を選択してレポートを作成することができます。

SQL文字列を使用して、書式化されたレポートからデータをロードする例は、「事例7: 書式化されたレポートからのデータの抽出」にあります。(事例へのアクセス方法については、「SQL*Loaderの事例」を参照してください。)

SQL文字列を使用したANYDATAデータベース型へのロード

ANYDATAデータベース型には、異なる型のデータを格納できます。SQL*loaderを使用してANYDATA型をロードするには、ファンクション・コールによって明示的に構築する必要があります。ファンクションは、この項で説明したとおり、SQL文字列のサポートを使用して起動します。

たとえば、ANYDATA型のmiscellaneousという名前の列を含む表があるとします。この列は、次のようにしてロードできます。この場合、番号を含むANYDATA型が作成されます。

LOAD DATA
INFILE *
APPEND INTO TABLE  ORDERS
(
miscellaneous CHAR "SYS.ANYDATA.CONVERTNUMBER(:miscellaneous)"
)
BEGINDATA
4

レコード内の値によっては、さらに複雑な条件で、異なる型を含むANYDATA型を作成する場合もあります。そのためには、レコード内の値に基づいて、ANYDATA型にする型を決定する独自のファンクションを記述し、適切なANYDATA.Convert*()ファンクションをコールしてその型を作成する必要があります。

参照:

  • ANYDATA データベース型の詳細は、『Oracle Database SQLリファレンス』を参照してください。

  • PL/SQLでのANYDATAデータベース型の使用方法の詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

 

SQL*Loaderを使用した入力データの生成

この項では、データ・ファイルからデータを読み込むのではなく、SQL*Loaderでデータを生成してデータベース・レコードに格納するパラメータについて説明します。ここで説明するパラメータは次のとおりです。

ファイルを使用しないデータのロード

フィールドの指定として順序、レコード番号、システム日付、定数およびSQL文字列式のみを指定してSQL*Loaderでデータを生成できます。

SQL*Loaderを使用して、LOAD文で指定された数のレコードを挿入します。この場合、SKIPパラメータは指定できません。

SQL*Loaderは、このような場合用に最適化されています。生成された指定のみが使用されていることを検出すると、SQL*Loaderでは、常に、指定されたすべてのデータ・ファイルが無視されます。I/Oの読取りは実行されません。

バインド配列用のメモリーも不要です。制御ファイル中にWHEN句が指定されている場合は、SQL*Loaderでデータの評価が必要であると判断され、入力レコードが読み込まれます。

列への定数値の設定

これは、生成するデータとしては最も単純な形式です。ロード中であっても、何回ロードしても、このデータは変わりません。

CONSTANTパラメータ

列に定数値を設定するには、CONSTANTを指定して、その後に値を指定します。

CONSTANT  value 

CONSTANTデータは、SQL*Loaderでは、文字入力として認識されます。このデータは、必要に応じてデータベース列のデータ型に変換されます。

値を引用符で囲むこともできます。特に、指定する値に空白や予約語が含まれている場合は、必ず引用符で囲んでください。また、ターゲット列に対して必ず有効な値を指定してください。指定した値が無効な場合は、すべてのレコードが拒否されてしまいます。

2の32乗-1(4,294,967,295)より大きい数値は引用符で囲んでください。


注意:

CONSTANTパラメータを使用して列にNULLを設定することはできません。列をNULLに設定する場合は、その列については何も指定しないでください。これによって、Oracleでレコードをロードするときに、その列に自動的にNULLが設定されます。CONSTANTおよび値の組合せを指定すると、列指定は完結します。 


列への式の値の設定

列名の後にEXPRESSIONパラメータを使用して、SQL演算子または特別に書き込まれたPL/SQL関数によって返された値に、その列を設定します。EXPRESSIONパラメータの後に続くSQL文字列に、演算子または関数が指定されます。演算子または関数に必要なパラメータが適切に指定され、その演算子または関数によって返された結果が、ロード中の列のデータ型と互換性がある場合、任意の式を使用できます。

EXPRESSIONパラメータ

列名、EXPRESSIONパラメータおよびSQL文字列の組合せは、完全なフィールド指定です。

column_name EXPRESSION "SQL string"

列へのデータ・ファイルのレコード番号の設定

RECNUMパラメータを列名の後に指定すると、レコードのロード元である論理レコードの番号が、その列に設定されます。レコードの番号は、最初のデータ・ファイルの先頭をレコード1として、順番にカウントされます。RECNUMは、各論理レコードが構成されるたびに増えていきます。廃棄、スキップ、拒否またはロードされたレコードもカウントされます。SKIP=10と指定した場合、最初にロードされるレコードのRECNUMの値は11になります。

RECNUMパラメータ

列名およびRECNUMの組合せを指定すると、列指定は完結します。

column_name  RECNUM  

列への現在の日付の設定

SYSDATEを使用して列を指定すると、SQL言語のSYSDATEパラメータで定義されているものと同じ、現在のシステム日付が列に設定されます。詳細は、『Oracle Database SQLリファレンス』の「DATEデータ型」を参照してください。

SYSDATEパラメータ

列名とSYSDATEパラメータの組合せを指定すると、列指定は完結します。

column_name  SYSDATE

データベースの列のデータ型は、CHARまたはDATE型にしてください。列がCHAR型の場合、日付は'dd-mon-yy'の書式でロードされます。ロード後は、この書式でのみ日付のロードができます。システム日付をDATE列にロードすると、そのシステム日付は、時間と日付を含む様々な書式でロードできます。

新しいシステム日付/時間は、従来型パス・ロードで挿入されたレコードの各配列や、ダイレクト・パス・ロード中にロードされた各レコード・ブロックで使用されます。

列への一意の順序番号の設定

SEQUENCEパラメータは、特定の列に対して一意の値を設定します。SEQUENCEの値は、ロードされたレコードまたは拒否されたレコードが発生するたびに増加します。廃棄またはスキップされたレコードに対しては、値は増加しません。

SEQUENCEパラメータ

列名とSEQUENCEパラメータの組合せを指定すると、列指定は完結します。


画像の説明

表9-6では、列指定に使用されるパラメータについて説明します。

表9-6    列指定に使用されるパラメータ 
パラメータ  説明 

column_name 

データベース内の、順序を割り当てる列の名前。 

SEQUENCE 

列の値を指定するには、このSEQUENCEを使用します。 

COUNT 

順序番号は表中にすでにあるレコード数で始まり、以降は増分値を加えた値が設定されます。 

MAX 

順序番号は列の現在の最大値で始まり、以降は増分値を加えた値が設定されます。 

integer 

先頭となる特定の順序番号を指定します。 

incr 

レコードがロードまたは拒否された後の順序番号の増分値。これはオプションです。デフォルトは1です。 

レコードが拒否された場合(書式エラーがあるか、またはOracleエラーが発生した場合)でも、その欠落を埋めるために生成された順序番号が変更されることはありません。たとえば、ある列に関して、4つの行に順序番号10、12、14および16が割り当てられ、番号12の行が拒否されたとします。この場合、挿入された3つの行の番号は10、14および16であって、10、12および14ではありません。このような処理が行われることによって、データ・エラーが発生しても、挿入時の順番を保持できます。拒否されたデータを修正して再度挿入する場合は、列の順序番号に一致するようにデータを手動で設定できます。

「事例3: 自由区分形式ファイルのロード」に、SEQUENCEパラメータの使用例があります。(事例へのアクセス方法については、「SQL*Loaderの事例」を参照してください。)

複数の表に対する順序番号の生成

一意の順序番号は、各表への挿入時に生成されるのではなく、各論理入力レコードに対して生成されます。したがって、データを複数の表に挿入する場合、同じ順序番号を使用することができます。この仕様は、多くの場合に有効です。

ただし、INTO TABLE句ごとに別の順序番号を生成する場合もあります。たとえば、各入力レコード中に3つの論理レコードが定義された形式のデータについて考えます。この場合、INTO TABLE句を3つ使用して、レコードの3つの異なる部分を同じ表に挿入するように指定できます。SEQUENCE(MAX)を使用すると、各表の最大値が採用されるため、順序番号に一貫性がなくなります。

このレコードの順序番号を生成する場合は、挿入する3つの論理レコードそれぞれに対して、重複しない番号を生成する必要があります。1レコード当たりの表挿入の回数を順序番号の増分値として使用し、各挿入の順序番号をその続き番号で始めるようにします。

例: 挿入ごとの順序番号の生成

次に示す部門名をdept表にロードするとします。各入力レコードには部門名が3つ入っています。この部門番号を自動生成する方法について考えます。

Accounting     Personnel      Manufacturing
Shipping       Purchasing     Maintenance 
... 

部門番号を重複しないように生成するには、次のような制御ファイル・エントリを作成します。

INTO TABLE dept 
(deptno  SEQUENCE(1, 3), 
 dname   POSITION(1:14) CHAR) 
INTO TABLE dept 
(deptno  SEQUENCE(2, 3), 
 dname   POSITION(16:29) CHAR) 
INTO TABLE dept 
(deptno  SEQUENCE(3, 3), 
 dname   POSITION(31:44) CHAR) 

最初のINTO TABLE句で生成される部門番号は1で、2番目では2が、3番目では3が生成されます。すべてのINTO TABLE句で増分値は3が使用されます(増分値は各レコードに含まれる部門名の数と一致します)。この制御ファイルでロードを実行すると、Accounting部門は部門番号1、Personnel部門は部門番号2、Manufacturing部門は部門番号3でロードされます。

また、次のレコードになると、順序番号は増分値分のみ増加するので、Shipping部門は部門番号4、Purchasing部門は部門番号5でロードされ、以降も同様にロードされます。


戻る 次へ
Oracle
Copyright © 2005 Oracle Corporation.

All Rights Reserved.
目次
目次
索引
索引