ヘッダーをスキップ

Oracle Rdb SQLリファレンス・マニュアル リリース7.2 E06178-01 |
| 目次 | 索引

戻る | 次へ |

### 2.2.13.1 データ・パラメータおよびインジケータ・パラメータ

データ・パラメータには、SQL文が格納する値、取得する値、またはデータベースの列と比較する値が含まれています。インジケータ・パラメータでは、関連付けられているデータ・パラメータにNULL値が割り当てられているかどうかを指定します。インジケータ・パラメータは、データ・パラメータの後に指定します。データ・パラメータとインジケータ・パラメータを関連付ける表記法は、SQL文が発行される環境によって異なります。

- 言語をSQL99に設定するか、パラメータを使用する必要がある別の言語に設定するか、またはパラメータを使用する必要があるPARAMETER COLONSなどの句を使用する場合、パラメータ名はすべてコロンで始める必要があります。このルールは、モジュール言語プロシージャ・パラメータの宣言および参照に適用されます。これらの言語または句をいずれも使用しない場合は、パラメータ名をコロンで始めることはできません。詳細は、「SET DIALECT文」および第3.2節を参照してください。
  現在のデフォルトの動作では、コロンは使用されません。ただし、このデフォルトは廃止予定の構文です。コロンを使用するとANSI/ISO規格モジュールの処理を実行できるようになるため、将来的にはコロンの使用がデフォルトになる予定です。

- 動的に実行されるSQL文では、単一のパラメータ・マーカー（?）を使用してデータ・パラメータおよびインジケータ・パラメータを参照します。SQLでは、EXECUTE文またはOPEN文を使用してパラメータ情報が取得されます。これらの文では、（適切なプリコンパイルされたSQLまたはSQLモジュールの表記法を使用して）データ・パラメータおよびインジケータ・パラメータの明示的なリストを指定することも、データ・パラメータおよびインジケータ・パラメータに関する情報フィールド（それぞれSQLDATA、SQLIND）を持つSQLDAを参照することもできます。

注意 SQL文の構文図では、パラメータ構文要素は、データ・パラメータおよびインジケータ・パラメータのすべての表記法を参照します。

Oracle Rdbでは、次のようにホスト言語プログラム内でインジケータ・パラメータをすべて整数型（符号付きロングワード型）として宣言することをお薦めします。

- COBOL: PIC S9(9) COMP
  ANSI/ISO SQL規格に準拠するために、SQLでは、COBOLのSIGN LEADING SEPARATE標識変数およびBINARY引数もサポートされています。
  BINARYは、COMPのシノニムです。詳細は、COBOL言語のサポート・ドキュメントを参照してください。
  COBOL: PIC S9(9) SIGN LEADING SEPARATE

- FORTRAN: INTEGER*4

- PL/I: BIN FIXED(31)

- C: int num2

- Ada: STANDARD.INTEGER

- BASIC: LONG（モジュール言語のみ）

- Pascal: [LONG] --MAXINT...+MAXINT

ホスト構造体への参照に使用する場合にのみ、インジケータ・パラメータを配列として宣言します（第2.2.13.2項を参照）。

表2-6は、非ストアド・プロシージャ内でインジケータ・パラメータが必要になるタイミング、およびSQLによるNULL値の処理の概要を示しています。

表2-6 インジケータ・パラメータおよびNULL値
| データベースからの取得 | データベースへの格納 |
--- | --- | --- | ---
NULL値の許可 | メイン・パラメータ | インジケータ・パラメータ | メイン・パラメータ | インジケータ・パラメータ |
NULL値を許可: 値がNULLでない場合。 | SQLによってデータベースの値に設定される。 | SQLによって0または正の値に設定される。 | プログラムによって格納される値に設定される必要がある。 | プログラムによって0または正の値に設定される必要がある。 |
NULL値を許可: 値がNULLの場合。 | 前の値のまま。プログラムによって無視される。 | SQLによって-1に設定される。 | SQLによって無視される。 | プログラムによって負の値に設定される必要がある。 |
NULL値を許可しない場合。 | SQLによってデータベースの値に設定される。 | 任意。インジケータ・パラメータが存在する場合は、SQLによって0または正の値に設定される。 | プログラムによって格納される値に設定される必要がある。 | 任意。インジケータ・パラメータが存在する場合は、プログラムによって0または正の値に設定される必要がある。 |

### 2.2.13.2 ホスト構造体およびインジケータ配列

ホスト構造体とは、構造体をサポートする言語のグループ構成メンバーやレコードに対応するホスト言語パラメータのことです。ホスト構造体を使用して、単一の名前を持つホスト言語変数のリストを参照します。ホスト構造体を定義すると、ホスト構造体を構成するホスト言語変数をリストするかわりに、埋込みSQL文またはSQLモジュール言語プロシージャ内でホスト構造体を参照できます。

パラメータは、あらゆる階層のグループ・フィールドで修飾できます。グループ構成メンバーのパラメータを参照する修飾形式は、次のとおりです。

また、符号付きロングワード整数型の1次元配列を定義することによって、ホスト構造体のインジケータ・パラメータを宣言できます。この配列は、ホスト構造体のフィールドに対するインジケータ・パラメータの集まりであり、インジケータ配列と呼ばれます。（インジケータ配列は、インジケータ構造体またはインジケータ・ベクターとも呼ばれます。）インジケータ・パラメータをデータ・パラメータに追加するのと同様に、複数のデータ・パラメータで表されるホスト構造体にインジケータ配列名を追加できます。インジケータ配列は、ホスト構造体のインジケータ・パラメータを指定する唯一の方法です。

次のようにSQLでパラメータ・リストを使用できるいずれの場所でも、ホスト構造体を参照できます。

- INSERT文のVALUES句

- 選択リスト

- IN条件

- FETCH文またはシングルトンSELECT文のINTO句

- OPEN文またはEXECUTE文のUSING句

ホスト構造体は、ストアド・ルーチンまたは複数文プロシージャでは使用できません。

次の例は、COBOLプログラムにおける、人事データベースのEMPLOYEES表に対応するホスト構造体およびインジケータ配列の宣言を示しています。また、この例では、ホスト構造体およびインジケータ配列を使用するSQL INSERT文も埋め込まれています。

     .
     .
     .
    WORKING-STORAGE SECTION.
    *
    * Host structure declaration. A parameter to match
    * each column being retrieved or stored is a subordinate
    * field in the structure.
    *
    01 WS-EMP-REC.
            02 WS-EMP-ID            PIC X(5).
            02 WS-L-NAME            PIC X(14).
            02 WS-F-NAME            PIC X(10).
            02 WS-M-INIT            PIC X.
            02 WS-ADDRESS-1         PIC X(25).
            02 WS-CITY              PIC X(20).
            02 WS-STATE             PIC X(2).
            02 WS-POSTAL-CODE       PIC X(5).
            02 WS-SEX               PIC X.
            02 WS-BIRTH-DATE        SQL_DATE.
            02 WS-STATUS            PIC X.
    *
    * Indicator array for host structure WS-EMP-REC.
    * EMP-REC-IND is the indicator when you refer to WS-EMP-REC.
    *
    01 WS-EMP-REC-IND.
            02 EMP-REC-IND OCCURS 11 TIMES PIC S9(9) COMP.
    *
    * Indicator declarations for references to individual parameters
    * in WS-EMP-REC.  You cannot use a subscripted reference to the
    * indicator array in such references, but must declare separate
    * indicator parameters.
    *
    01 EMP-ID-IND                   PIC S9(9) COMP.
    01 L-NAME-IND                   PIC S9(9) COMP.
    01 F-NAME-IND                   PIC S9(9) COMP.
    01 M-INIT-IND                   PIC S9(9) COMP.
    01 ADDRESS-1-IND                PIC S9(9) COMP.
    01 CITY-IND                     PIC S9(9) COMP.
    01 STATE-IND                    PIC S9(9) COMP.
    01 POSTAL-CODE-IND              PIC S9(9) COMP.
    01 SEX-IND                      PIC S9(9) COMP.
    01 BIRTH-DATE-IND               PIC S9(9) COMP.
    01 STATUS-IND                   PIC S9(9) COMP.
     .
     .
     .
    EXEC SQL
    INSERT INTO EMPLOYEES VALUES (:WS-EMP-REC:EMP-REC-IND)
    END-EXEC.
     .
     .
     .

また、ホスト構造体内の単一のパラメータを参照することもできます。FORTRAN、C、PascalおよびAdaでは、パラメータ名をすべての上位グループ・フィールド名で修飾する必要があります。COBOLおよびPL/Iでは、修飾しないと名前があいまいになる場合にのみ、パラメータをグループ・フィールド名で修飾する必要があります。

埋込みSQL文でのホスト構造体およびインジケータ配列の使用については、次の点に注意してください。

- 参照する構造体のホスト言語パラメータごとに、インジケータ・パラメータを個別に宣言する必要があります。たとえば、前述のCOBOLの例のWS-EMP-RECおよびWS-EMP-REC-INDの宣言において、F-NAMEフィールドのホスト構造体およびインジケータ・パラメータを参照する正しい方法の1つは、次のとおりです。

      :WS-EMP-REC.WS-F-NAME:F-NAME-IND.

  インジケータ配列の個別要素への添字付き参照を、ホスト構造体の個別のパラメータのインジケータ・パラメータとして使用することはできません。たとえば、前述のCOBOLのWS-EMP-RECおよびWS-EMP-REC-INDの宣言において、SQL文では次のようなF-NAMEフィールドのホスト構造体およびインジケータ・パラメータを参照できません。

      :WS-EMP-REC.WS-F-NAME:EMP-REC-IND(3).

- COBOLとSQLプリコンパイラでは、ホスト構造体への参照の解釈方法が異なります。この相違のために、プリコンパイラからわかりにくいエラー・メッセージが出力される場合があります。
  COBOLでは、ホスト構造体への参照は、構造体の下位のフィールドを連結した長さを持つ、テキスト・データ型の単一のパラメータへの参照として解釈されます。たとえば、COBOLでは、次の宣言内のB-DATEへの参照は、構造体の要素フィールドの値を保持する、単一のパラメータへの参照として解釈されます。

      01 B-DATE.
         02   CENTURY PIC XX.
         02   YEAR    PIC XX.
         02   MONTH   PIC XX.
         02   DAYW    PIC XX.

  一方、SQLでは、ホスト構造体への参照は、その構造体を構成するすべての個別のパラメータへの参照として解釈されます。B-DATEを参照する埋込みSQL文では、B-DATEを4つの個別のホスト言語パラメータとして処理する必要があります。たとえば、前述のB-DATE宣言と同じプログラム内に埋め込まれている次のSQL文では、プリコンパイラ・エラーが生成されます。

      EXEC SQL
      INSERT INTO TEMP_TABLE (BIRTHDAY) VALUES (:B-DATE)
      END-EXEC.
      * This statement will generate this precompiler error:
      *
      * %SQL-F-INVVALLIS,
      * The value list must have as many items as the column list.

  次のように、B-DATEを単一のパラメータとして宣言した後で、COBOLのREDEFINES句を使用してそのパラメータを参照する4つのパラメータを宣言することによって、この問題を回避できます。

      01 B-DATE PIC X(9).
      01 B-DATE-REDEF REDEFINES B-DATE.
         02   CENTURY PIC XX.
         02   YEAR    PIC XX.
         02   MONTH   PIC XX.
         02   DAYW    PIC XX.

  VARCHAR列またはLONG VARCHAR列に関連付けられているCOBOLのホスト構造体の場合、ホスト構造体への参照が、その構造体を構成する要素フィールドへの個別の参照としてSQLで解釈されるというルールは適用されません。このようなホスト構造体の場合、SQLでは、2つの要素フィールドが、可変テキスト値を割り当てるための単一のパラメータとして解釈されます。VARCHAR列またはLONG VARCHAR列に対するCOBOLのホスト構造体宣言の詳細は、第4.4.4項を参照してください。

### 2.2.13.3 複数文プロシージャ変数およびストアド・ルーチン・パラメータ

複数文プロシージャ変数およびストアド・ルーチン・パラメータは、値式で頻繁に使用されます（第2.6節を参照）。変数は、プログラムの実行中に変更される可能性がある値を表す識別子です。複数文プロシージャではSQL変数を使用します。ストアド・ルーチン・パラメータは、ストアド・プロシージャまたはストアド・ファンクションで使用する、ストアド・ルーチンのパラメータに関連付けられている変数です。ストアド・ルーチンは、CREATE MODULE文を使用して定義されるストアド・プロシージャとストアド・ファンクションの両方を指します。

複数文プロシージャ内の変数およびストアド・ルーチン・パラメータは、それらが含まれるモジュールに関連付けられているルール（大/小文字の区別など）に従います。つまり、次のようになります。

- 埋込みSQLでは、変数はプログラムが記述されたホスト言語のルールに従います。

- SQLモジュール言語プログラムでは、変数はSQLインタフェースのルールに従います。

- ストアド・ルーチンでは、変数はSQLインタフェースのルールに従います。

データ・パラメータとは異なり、変数およびストアド・ルーチン・パラメータではNULL値を使用できます。このため、変数およびストアド・ルーチン・パラメータにはインジケータ・パラメータを使用できません。

ストアド・ルーチン・パラメータの詳細は、「CREATE MODULE文」を参照してください。

### 2.2.13.4 外部ルーチン・パラメータ

外部ルーチン・パラメータは、コール側プログラムの実パラメータに対応する3GLの宣言です。これらの宣言は、仮パラメータと呼ばれます。外部ルーチンの3GL文またはSQL文では、仮パラメータ名を使用してコール側プログラムの実パラメータを間接的に参照します。

外部ルーチン・パラメータでは、NULL値を使用できません。

## 2.2.14 文名（動的SQLのみ）

動的SQLでは、コンパイルの前にプログラムに埋め込む必要があるプリコンパイルされたSQL文とは対照的に、プログラムは実行時にSQL文を受け入れたり生成できます。埋込みSQL文とは異なり、動的に実行されるこのようなSQL文は、ソース・コードの一部ではなく、プログラムの実行時に生成されます。動的SQLは、プログラムで処理する必要があるSQL文のタイプを予測できない場合に便利です。

動的に実行されるSQL文を制御するには、プログラムで埋込みPREPARE文を使用して、実行時に作成されるSQL文の名前を割り当て、実行の準備をします。EXECUTE文、動的なDECLARE CURSOR文およびDESCRIBE文では、割り当てられた名前が参照されます。準備された文の名前は修飾できません。

埋込みPREPARE文で準備されるため、動的文名を参照できるのはプログラムのみです。対話型SQLからは参照できません。

## 2.2.15 スキーマ名

スキーマは、表、ビュー、ドメイン、制約、照合順番、索引、記憶域マップ、トリガー、およびこれらのそれぞれに対する権限などのメタデータ定義で構成されています。

スキーマには、CREATE SCHEMA文またはCREATE DATABASE文を使用して名前を付けます。また、スキーマ名を使用すると、表、ビューおよび列などの他のデータベース要素の名前を修飾することもできます。

注意 構文図では、schema-nameの構文要素は、CREATE文でスキーマに付けた名前の修飾済または未修飾のいずれかの形式を参照します。つまり、構文図ではschema-nameは常に次のように定義されます。

デフォルトでは、作成するデータベースごとにスキーマが1つのみ割り当てられます。マルチスキーマ・データベースの作成方法の詳細は、「CREATE DATABASE文」を参照してください。別名RDB$DBHANDLEは、単一スキーマ・データベース定義、またはマルチスキーマ・ネーミングが無効なマルチスキーマ・データベース定義を参照するときのスキーマを表します。

マルチスキーマ・データベース定義を参照するときにマルチスキーマ・ネーミングが有効な場合は、マルチスキーマ・ネーミング規則に従う必要があります。マルチスキーマ・ネーミングでは、次のネーミング規則に従います。

- 定義名が含まれているスキーマ名を使用して、定義名を修飾する必要があります。異なるスキーマに属していないかぎり、同じ名前を持つ表とビュー、または同じ種類の2つのオブジェクト（2つの表など）を参照することはできません。

- マルチスキーマ・データベースのオブジェクト名は、別名およびカタログ名で修飾することもできます。
  カタログ名でオブジェクト名を修飾するときにデフォルト・スキーマを使用しない場合は、スキーマ名も指定する必要があります。カタログ名と別名の組合せ、またはスキーマ名と別名の組合せは、二重引用符で囲む必要があります。

- オブジェクトを格納するカタログおよびスキーマがデフォルトに設定されている場合、必要に応じて、マルチスキーマ・データベースのオブジェクト名を別名で修飾できます。別名およびオブジェクト名の組合せを二重引用符で囲み、この2つをピリオドで区切ります。

マルチスキーマ・データベースのオブジェクトを参照するときにスキーマ名を省略すると、SQLでは、実行者のユーザー識別子と同じ名前のスキーマがデフォルト・スキーマとして使用されます。デフォルト・スキーマは、SET SCHEMA文を使用して変更できます。

次の例では、別名CORPを持つマルチスキーマ・データベースのカタログRDB$CATALOGのスキーマRDB$SCHEMAに、表QUARTERLY_TOTALを作成しています。

    SQL> ATTACH 'ALIAS CORP FILENAME corporate_data';
    SQL> SET QUOTING RULES 'SQL99';
    SQL> SET CATALOG 'RDB$CATALOG';
    SQL> SET SCHEMA 'RDB$SCHEMA';
    SQL> CREATE TABLE "CORP.QUARTERLY_TOTAL" (SALARY_AMOUNT_DOM CHAR);
    SQL> SHOW TABLES;
    User tables in database with alias CORP
         "CORP.ADMINISTRATION".ACCOUNTING.BUDGET
         "CORP.ADMINISTRATION".ACCOUNTING.DEPARTMENTS
         .
         .
         .
         "CORP.ADMINISTRATION".RECRUITING.RESUMES
         "CORP.RDB$CATALOG".RDB$SCHEMA.QUARTERLY_TOTAL

カタログの詳細は、第2.2.3項を参照してください。

## 2.2.16 記憶域名

記憶域は、複数ファイルのデータベースの1つ以上の表に関連付けられるデータ・ファイルおよびスナップショット・ファイルのことです。記憶域は、CREATE DATABASE文またはIMPORT文のCREATE STORAGE AREA句で名前を付けます。CREATE STORAGE MAP文では、特定の記憶域にどの表のどの部分を格納するかを制御します。構文図では、構文要素area-nameを使用して、文中に記憶域名を指定します。CREATE STORAGE AREA句およびその他のSQL文では、CREATE文で設定した記憶域名を別名で修飾できます。

記憶域名にはASCII英数字を使用する必要があります。

注意 構文図では、area-nameの構文要素は、CREATE STORAGE AREA句で記憶域に付けた名前の修飾済または未修飾のいずれかの形式を参照します。

## 2.2.17 記憶域マップ名

記憶域マップでは、複数ファイルのデータベースの特定の記憶域にどの表のどの部分を格納するかを制御します。記憶域マップには、CREATE STORAGE MAP文を使用して名前を付けます。構文図では、構文要素map-nameを使用して、文中に記憶域マップの名前を指定します。

CREATE STORAGE MAP句およびその他のSQL文では、CREATE文で設定した記憶域マップ名を別名で修飾できます。

注意 構文図では、map-nameの構文要素は、CREATE STORAGE MAP文で記憶域マップに付けた名前の修飾済または未修飾のいずれかの形式を参照します。

## 2.2.18 ストアド名

データ定義を作成するときにデータ定義に指定する名前はSQL名と呼ばれます。各データ定義には、Oracle Rdbで認識されるストアド名もあります。

マルチスキーマ・データベース内の異なるスキーマにある同じ種類の2つのエンティティに対して、同じSQL名を設定できます。たとえば、EMPLOYEESという表をスキーマDEPT1に、2つ目のEMPLOYEES表をスキーマDEPT2に作成できます。最初のEMPLOYEES表が作成されると、SQLによってSQL名と同じストアド名が割り当てられます。2番目のEMPLOYEES表に対しては、シリアル番号が追加され必要に応じて名前が切り捨てられた、一意のストアド名が生成されます。

表2-7は、マルチスキーマ・データベースに3つの定義がある場合のSQL名およびストアド名を対比しています。

表2-7 ストアド名およびSQL名
SQL名 | SQLによって割り当てられるストアド名1
--- | ---
DEPT1.EMPLOYEES | EMPLOYEES
DEPT2.EMPLOYEES | EMPLOYEES1
DEPT3.EMPLOYEES | EMPLOYEES2

1この表では、DEPT1、DEPT2およびDEPT3のEMPLOYEESが順番に作成されることを想定しています。

マルチスキーマ・データベースにおける定義で、ストアド名をSQLで生成するのではなく自分で指定する場合は、CREATE文でSTORED NAME IS句を使用するとストアド名を指定できます。ストアド名は、マルチスキーマ・データベース内の定義に対してのみ指定できます。

SQLでは、特定の種類の定義ごとに、SQL名がスキーマ内で一意であり、ストアド名がデータベース内で一意である必要があります。

ストアド名を使用すると、Oracle Rdb管理ユーティリティであるOracle RMUなどのインタフェースを使用して、マルチスキーマ定義にアクセスできます。このユーティリティでは、1つのデータベース内で複数のスキーマを認識しません。ATTACH文またはDECLARE ALIAS文のMULTISCHEMA IS OFF句を使用してマルチスキーマ・ネーミングを無効にすると、ストアド名によってマルチスキーマ定義にアクセスできます。