2.2.13.1 データ・パラメータおよびインジケータ・パラメータ
データ・パラメータには、SQL文が格納する値、取得する値、またはデータベースの列と比較する値が含まれています。インジケータ・パラメータでは、関連付けられているデータ・パラメータにNULL値が割り当てられているかどうかを指定します。インジケータ・パラメータは、データ・パラメータの後に指定します。データ・パラメータとインジケータ・パラメータを関連付ける表記法は、SQL文が発行される環境によって異なります。
SQL文の構文図では、パラメータ構文要素は、データ・パラメータおよびインジケータ・パラメータのすべての表記法を参照します。 |
Oracle Rdbでは、次のようにホスト言語プログラム内でインジケータ・パラメータをすべて整数型(符号付きロングワード型)として宣言することをお薦めします。
ホスト構造体への参照に使用する場合にのみ、インジケータ・パラメータを配列として宣言します(第2.2.13.2項を参照)。
表2-6は、非ストアド・プロシージャ内でインジケータ・パラメータが必要になるタイミング、およびSQLによるNULL値の処理の概要を示しています。
データベースからの取得 | データベースへの格納 | ||||
---|---|---|---|---|---|
NULL値の許可 | メイン・パラメータ | インジケータ・パラメータ | メイン・パラメータ | インジケータ・パラメータ | |
NULL値を許可: 値がNULLでない場合。 | SQLによってデータベースの値に設定される。 | SQLによって0または正の値に設定される。 | プログラムによって格納される値に設定される必要がある。 | プログラムによって0または正の値に設定される必要がある。 | |
NULL値を許可: 値がNULLの場合。 | 前の値のまま。プログラムによって無視される。 | SQLによって-1に設定される。 | SQLによって無視される。 | プログラムによって負の値に設定される必要がある。 | |
NULL値を許可しない場合。 | SQLによってデータベースの値に設定される。 | 任意。インジケータ・パラメータが存在する場合は、SQLによって0または正の値に設定される。 | プログラムによって格納される値に設定される必要がある。 | 任意。インジケータ・パラメータが存在する場合は、プログラムによって0または正の値に設定される必要がある。 |
ホスト構造体とは、構造体をサポートする言語のグループ構成メンバーやレコードに対応するホスト言語パラメータのことです。ホスト構造体を使用して、単一の名前を持つホスト言語変数のリストを参照します。ホスト構造体を定義すると、ホスト構造体を構成するホスト言語変数をリストするかわりに、埋込みSQL文またはSQLモジュール言語プロシージャ内でホスト構造体を参照できます。
パラメータは、あらゆる階層のグループ・フィールドで修飾できます。グループ構成メンバーのパラメータを参照する修飾形式は、次のとおりです。
また、符号付きロングワード整数型の1次元配列を定義することによって、ホスト構造体のインジケータ・パラメータを宣言できます。この配列は、ホスト構造体のフィールドに対するインジケータ・パラメータの集まりであり、インジケータ配列と呼ばれます。(インジケータ配列は、インジケータ構造体またはインジケータ・ベクターとも呼ばれます。)インジケータ・パラメータをデータ・パラメータに追加するのと同様に、複数のデータ・パラメータで表されるホスト構造体にインジケータ配列名を追加できます。インジケータ配列は、ホスト構造体のインジケータ・パラメータを指定する唯一の方法です。
次のようにSQLでパラメータ・リストを使用できるいずれの場所でも、ホスト構造体を参照できます。
ホスト構造体は、ストアド・ルーチンまたは複数文プロシージャでは使用できません。
次の例は、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文でのホスト構造体およびインジケータ配列の使用については、次の点に注意してください。
: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). |
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文を使用して定義されるストアド・プロシージャとストアド・ファンクションの両方を指します。
複数文プロシージャ内の変数およびストアド・ルーチン・パラメータは、それらが含まれるモジュールに関連付けられているルール(大/小文字の区別など)に従います。つまり、次のようになります。
データ・パラメータとは異なり、変数およびストアド・ルーチン・パラメータでは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は、単一スキーマ・データベース定義、またはマルチスキーマ・ネーミングが無効なマルチスキーマ・データベース定義を参照するときのスキーマを表します。
マルチスキーマ・データベース定義を参照するときにマルチスキーマ・ネーミングが有効な場合は、マルチスキーマ・ネーミング規則に従う必要があります。マルチスキーマ・ネーミングでは、次のネーミング規則に従います。
マルチスキーマ・データベースのオブジェクトを参照するときにスキーマ名を省略すると、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句で記憶域に付けた名前の修飾済または未修飾のいずれかの形式を参照します。 ![]() |
記憶域マップでは、複数ファイルのデータベースの特定の記憶域にどの表のどの部分を格納するかを制御します。記憶域マップには、CREATE STORAGE MAP文を使用して名前を付けます。構文図では、構文要素map-nameを使用して、文中に記憶域マップの名前を指定します。
CREATE STORAGE MAP句およびその他のSQL文では、CREATE文で設定した記憶域マップ名を別名で修飾できます。
構文図では、map-nameの構文要素は、CREATE STORAGE MAP文で記憶域マップに付けた名前の修飾済または未修飾のいずれかの形式を参照します。 ![]() |
データ定義を作成するときにデータ定義に指定する名前はSQL名と呼ばれます。各データ定義には、Oracle Rdbで認識されるストアド名もあります。
マルチスキーマ・データベース内の異なるスキーマにある同じ種類の2つのエンティティに対して、同じSQL名を設定できます。たとえば、EMPLOYEESという表をスキーマDEPT1に、2つ目のEMPLOYEES表をスキーマDEPT2に作成できます。最初のEMPLOYEES表が作成されると、SQLによってSQL名と同じストアド名が割り当てられます。2番目のEMPLOYEES表に対しては、シリアル番号が追加され必要に応じて名前が切り捨てられた、一意のストアド名が生成されます。
表2-7は、マルチスキーマ・データベースに3つの定義がある場合のSQL名およびストアド名を対比しています。
SQL名 | SQLによって割り当てられるストアド名1 |
---|---|
DEPT1.EMPLOYEES | EMPLOYEES |
DEPT2.EMPLOYEES | EMPLOYEES1 |
DEPT3.EMPLOYEES | EMPLOYEES2 |
マルチスキーマ・データベースにおける定義で、ストアド名をSQLで生成するのではなく自分で指定する場合は、CREATE文でSTORED NAME IS句を使用するとストアド名を指定できます。ストアド名は、マルチスキーマ・データベース内の定義に対してのみ指定できます。
SQLでは、特定の種類の定義ごとに、SQL名がスキーマ内で一意であり、ストアド名がデータベース内で一意である必要があります。
ストアド名を使用すると、Oracle Rdb管理ユーティリティであるOracle RMUなどのインタフェースを使用して、マルチスキーマ定義にアクセスできます。このユーティリティでは、1つのデータベース内で複数のスキーマを認識しません。ATTACH文またはDECLARE ALIAS文のMULTISCHEMA IS OFF句を使用してマルチスキーマ・ネーミングを無効にすると、ストアド名によってマルチスキーマ定義にアクセスできます。