Oracle Rdb7

2.2.8.1 Oracle Rdbのアタッチ仕様

データベースを最初に作成するときに、データベースに格納されるすべてのデータベース定義（メタデータ）およびユーザー・データを含むファイルに対してファイル仕様を指定します。ファイル仕様名にはASCII英数字を使用する必要があります。

ファイル仕様はCONNECT文およびDECLARE ALIAS文でデータベースを参照するときに使用できますが、Oracle Rdbでは、リポジトリがインストールされている場合は、常にリポジトリ・パス名を使用することをお薦めします。詳細は、「DECLARE ALIAS文」および「CONNECT文」の「使用方法」を参照してください。

完全なファイル仕様には、次の項目が含まれます。

ネットワーク・ノード名
デバイス名
ディレクトリ名またはディレクトリ・リスト
ファイル名
ファイル拡張子
ファイル・バージョン番号

たとえば、OpenVMSの完全なファイル仕様の例は、次のとおりです。

SPEEDY::DISK_DEPT3:[LICENSES]APPLICANTS.RDB;18

可能な場合は、ファイル仕様で省略されたフィールドに対してデフォルト値が適用されます。

CREATE DATABASE文、ALTER DATABASE文、DROP DATABASE文、ATTACH文またはDECLARE ALIAS文を使用する場合は、ファイル仕様にファイル拡張子またはバージョン番号を含めないようにします。このファイル仕様を使用して、別のファイル拡張子を持つファイルが作成されます。たとえば、OpenVMSで単一ファイルのデータベースを作成する場合、Oracle Rdbによって.rdbおよび.snpというファイル拡張子を持つ2つのファイルが作成されます。拡張子またはバージョンを指定すると、これらの2つのファイル間で不整合が発生する場合があります。

また、ATTACH文またはDECLARE ALIAS文では、完全または部分的なファイル仕様のかわりに論理名も使用できます。

リモート・データベース（ネットワーク上の別ノードにあるデータベース）を使用している場合、ファイル仕様にノード名が確実に含まれるようにする必要があります。OpenVMSでは、クラスタ経由、DECnet経由、TCP/IP経由という3種類のリモート・アクセスが提供されています。Oracle Rdbでは、これら3種類の方法がすべてサポートされています。ノード名の形式は、使用する方法によって異なります。リモート・ノードが同一のクラスタ内に存在するか、DECnet経由で接続する場合、ノード名はリモート・システムのOpenVMSのノード名になります。TCP/IP経由の場合、ノード名には、TCP/IPのドメイン修飾子（MYSYS.MYDOM.MYNETなど）またはIPアドレス（10.20.30.40など）を含むTCP/IPのノード名を使用できます。また、DECnetでTCP/IPがトランスポート・レイヤーとして使用されている場合、DECnetのノード名をTCP/IPのノード名として使用できます。様々なリモート接続を使用したノード名の詳細は、『Oracle Rdb7 Guide to SQL Programming』を参照してください。

リモート・データベースにアクセスするには別のコンピュータ・システムを使用する必要があるため、プロセスまたはプログラムによるリモート・システムへのログインおよびユーザー認証が必要になります。リモート・ノード上のデータベースにアクセスするには、データベースにアタッチするSQL文および構成パラメータ内でユーザー名およびパスワード情報を明示的に指定できます。また、パラメータおよび新規コマンドライン修飾子を使用して、SQLモジュール言語またはプリコンパイルされたSQLプログラムにその情報を渡すこともできます。

Oracle Rdb for OpenVMSを使用して同一クラスタ内のデータベースにアタッチする場合、ユーザー名およびパスワードを明示的に指定する必要はありません。ユーザーがデータベースにアタッチするときは毎回Oracle Rdbによって暗黙的にユーザー認証が行われます。

ただし、Oracle Rdb for OpenVMSを使用してリモート・ノード上のデータベースにアタッチする場合は、リモート・ノードがOpenVMSノードであっても、Oracle Rdbによって提供されている方法の1つを使用してデータベースにアクセスする必要があります。

OpenVMSノード上のデータベースにアタッチするには、次の方法のいずれかを使用できます。

ATTACH文のUSER句およびUSING句にユーザー名およびパスワードを明示的に指定します。
リモート・ノード上のmf_personnelデータベースにアタッチするには、次の例に示すようにATTACH文のUSER句およびUSING句を使用します。
SQL> ATTACH 'FILENAME REMNOD::DISK1:[DIR]MF_PERSONNEL cont> USER ''heleng'' USING ''MYpassword'''; SQL>
ユーザー名およびパスワードは一重引用符で囲む必要があります。ただし、この例のリテラルは引用符で囲まれたattach-string内に含まれているため、ユーザー名およびパスワードを一重引用符で2重に囲む必要があります。
構成ファイルRDB$CLIENT_DEFAULTS.DATに、ユーザー名およびパスワードを明示的に指定します。次の例は、構成ファイル内に情報を組み込む方法を示しています。
! User name to be used for authentication SQL_USERNAME HELENG ! Password to be used for authentication SQL_PASSWORD MYPASSWORD
リモートのOpenVMSノード上のデータベースにアタッチするには、次のいずれかの方法も使用できます。
- リモート・システム上のプロキシ・アカウントを使用します。この方法を使用すると、コマンド・ファイル内のATTACH文、またはホスト言語プログラムのDECLARE ALIAS文で、ユーザー名およびパスワードを指定する必要がなくなります。プロキシ・アカウントはローカル・アカウントと同じ権限を持つ必要がないため、リモート・アクセス方法としてお薦めします。Oracle Rdbのインストールで作成されるRDB$REMOTEアカウントにデータベース権限を付与する必要があります。プロキシ・アカウントの詳細は、『Oracle Rdb7 Guide to SQL Programming』を参照してください。プロキシ・アカウントは、TCP/IPではサポート対象外です。
- ファイル仕様にユーザー名およびパスワードを埋め込みます（この方法はTCP/IPではサポートされていません）。次の例は、リモート・システムREMNODにアクセスするATTACH文を示しています。
  SQL> ATTACH 'FILENAME REMNOD"JULIA OPEN_UP"::APPLICANTS.RDB';
  この例では、リモート・ノード名がREMNOD、データベースが定義されているアカウントのユーザー名がJULIA、このアカウントのパスワードがOPEN_UPになっています。データベース・ファイルがJULIAのログイン・ディレクトリにある場合、ディスクおよびディレクトリの指定は不要です。DECnetソフトウェアによって、JULIAという名前のユーザーに対するログイン・プロセスが実行され、JULIAのディスクおよびログイン・ディレクトリが自動的に使用されます。

SQL文でUSER句およびUSING句を指定しない場合、Oracle Rdbにより構成ファイル内の情報が使用されます。構成ファイル内にSQL_USERNAMEパラメータおよびSQL_PASSWORDパラメータが指定されていない場合は、プロキシ・アカウントの有無がチェックされます。

2.2.8.2 リポジトリ・パス名

CREATE DATABASE文でPATHNAME引数を指定しない場合、SQLではデータ定義を格納するためにリポジトリは使用されません。

データベースを最初に作成するときにPATHNAME引数を指定すると、データベースのデータ定義のコピーを含むパス名が作成されます。

SQLではパス名は文字列リテラルと同様に処理されるため、パス名を一重引用符で囲む必要があります。リポジトリ・パス名にはASCII英数字を使用する必要があります。

ATTACH文またはDECLARE ALIAS文を発行するときは、データベースのリポジトリ・パス名（次に物理データベース・ファイルを指し示す）を指定することも、物理データベース・ファイル仕様を直接指定することもできます。

CREATE DATABASE文でPATHNAME引数を使用しない場合は、最初にINTEGRATE文を発行するまで、ATTACH文またはDECLARE ALIAS文でデータベースのパス名を指定できません。Oracle Rdbでは、CREATE DATABASE文、ATTACH文およびDECLARE ALIAS文で常にリポジトリ・パス名を使用し、DICTIONARY IS REQUIRED句を使用して2つのコピーが確実に同じになるようにすることをお薦めします。

リポジトリ・パス名は、次の形式で指定できます。

CDD$TOP.ELLINGSWORTH.SQL.PERSONNELなどの、フルパス名
相対パス名
相対パス名は、現在のデフォルト・リポジトリ・ノードに続くフルパス名の一部で構成されています。たとえば、SET DICTIONARYコマンドを使用して、現在のリポジトリ・ディレクトリをCDD$TOP.ELLINGSWORTH.SQLに設定するとします。この場合、フルパス名CDD$TOP.ELLINGSWORTH.SQL.PERSONNELのかわりに相対パス名PERSONNELを使用できます。デフォルトでは、現在のリポジトリ・ノードは論理名CDD$DEFAULTで定義されるパス名に設定されます。SET DICTIONARY文の詳細は、「SET文」を参照してください。リポジトリ・パス名の詳細は、『Using Oracle CDD/Repository on OpenVMS Systems』も参照してください。
フルパス名または相対パス名を指す論理名

Oracle Rdb機能の中には、リポジトリのすべてのバージョンで完全にはサポートされていないものがあります。パス名でのアタッチによるオブジェクトの作成、変更または削除は、リポジトリによって完全にはサポートされていないため、エラーまたは情報メッセージが表示される場合があります。バージョンの異なるリポジトリに対するOracle Rdb機能の互換性の詳細は、『Oracle Rdbリリース・ノート』を参照してください。

2.2.9 ドメイン名

ドメインは、表列に設定可能な値のセットです。

ドメイン定義では、データ型とドメイン名を関連付けることによって、表列で保持可能な値セットが制限されます。また、ドメイン定義を使用すると、オプションのフォーマット句および照合句を使用できます。CREATE文およびALTER TABLE文では、列定義のドメイン名が参照されます。ドメイン名は、スキーマ内のドメイン名の間で一意である必要があります。

複数の表の列を定義するときに、ドメインを使用できます。ドメインを定義すると、CREATE文またはALTER TABLE文を使用してドメイン定義に基づいた列を定義できます。

ドメイン名は、スキーマ名（ドメインがマルチスキーマのデータベースに属している場合）または別名を使用して修飾できます。

通常、表を作成するときは、ドメインを使用する必要があります。ドメインを使用する場合の利点は、次のとおりです。

複数の表にある類似した列を1つの基準で統一できます。たとえば、ドメインID_DOMを使用して列を定義すると、これらの列すべてのデータ型がCHAR(5)になります。
ドメイン自体を変更することにより、そのドメインを使用して定義したすべての列のデータ型を変更できます。たとえば、POSTAL_CODE_DOMのデータ型をCHAR(5)からCHAR(10)に変更する場合、必要な処理はPOSTAL_CODE_DOMのデータ型の変更のみです。表COLLEGESおよびEMPLOYEESの列POSTAL_CODEのデータ型を変更する必要はありません。

次の場合は、表の作成時にドメインを使用しないことをお薦めします。

中間結果表を作成している場合。データベース内のドメインについて把握し、それらを定義するには時間がかかります。中間結果表はこの作業の妨げになる場合があります。

注意

構文図では、domain-nameの構文要素は、CREATE DOMAIN文でドメインに付けた名前の修飾済または未修飾のいずれかの形式を参照します。

2.2.10 索引名

索引名は、CREATE INDEX文を使用して指定します。CREATE INDEX文およびその他のSQL文では、指定した索引名を認可識別子で修飾できます。

注意

構文図では、index-nameの構文要素は、CREATE INDEX文で索引に付けた名前の修飾済または未修飾のいずれかの形式を参照します。

2.2.11 マルチスキーマ・データベースにおける名前

データベースにマルチスキーマ属性を指定すると、データ定義をそのデータベース内の複数のスキーマに格納できます。マルチスキーマ属性を指定するには、CREATE DATABASE文またはALTER DATABASE文のMULTISCHEMA IS ON句を使用します。SQLの動作をANSI/ISO規格に準拠させる場合、マルチスキーマ属性を指定する必要があります。

複数のスキーマを持つデータベースでは、1つ以上のカタログ内にスキーマを構成する必要があります。マルチスキーマ・データベースのデータ定義を参照するには、スキーマ名、カタログ名、およびオプションで別名を使用して、データ定義名を修飾します。

別名を使用してマルチスキーマ・データベースのカタログ名、スキーマ名、オブジェクト名を修飾する方法は、次のとおりです。

それぞれの名前の後にピリオド（.）を付け、別名から従属名を切り離し、お互いを区切ります。
二重引用符（"）を使用して、左端の名前のペアを区切ります。
左端の名前のペアには大文字のみを使用します。

マルチスキーマ・オブジェクトの修飾名の、左端の名前のペアはデリミタ付き識別子です。オブジェクト名では、修飾名はそれぞれ1つのレベルとみなされます。また、3レベルを超える名前は許可されていません。ただし、デリミタ付き識別子は単一レベルとして解釈されます。

3レベルの名前のどの部分であっても、二重引用符内に別名を埋め込むことができます。ただし、左端のレベルに埋め込むことができるのは別名のみです。たとえば、スキーマ名を指定してカタログ名を指定しない（暗黙的にデフォルトのカタログを示す）場合は、デリミタ付き識別子を使用して別名でスキーマ名を修飾できます。

Oracle RdbのSQL実装のデフォルトでは、二重引用符で囲まれた文字列は文字列リテラルとみなされますが、ANSI/ISO SQL規格では、二重引用符で囲まれた文字列はデリミタ付き識別子と解釈されます。ANSI/ISO SQL規格を利用するには、デリミタ付き識別子を含む文を発行する前にANSI/ISO SQL引用を有効にする必要があります。ANSI/ISO SQL引用を有効にする方法の詳細は、第2.2節を参照してください。

二重引用符で囲まれている、マルチスキーマ・オブジェクト名の左端のペアは大文字で指定する必要があります。

次の例は、3レベルの名前を示しています。MARKETINGカタログ、JONESスキーマ、LAST_NAMEドメインを持つデータベースの別名が、CORPORATEです。

SQL> SET QUOTING RULES 'SQL99';
SQL> SHOW DOMAIN "CORPORATE.MARKETING".JONES.LAST_NAME;

デフォルトのカタログがMARKETINGに設定されている場合、ユーザーJONESは、別名で修飾されたオブジェクト名を使用してこの例のドメインを参照できます。

SQL> SET QUOTING RULES 'SQL99';
SQL> SHOW DOMAIN "CORPORATE.LAST_NAME";

単一スキーマ・データベースおよびマルチスキーマ・データベースのデータ定義は、異なるネーミング規則に従っています。マルチスキーマ・ネーミングを無効にするには、ATTACH文またはDECLARE ALIAS文のMULTISCHEMA IS OFF句を使用できます。単一スキーマおよびマルチスキーマのネーミング規則の相違の詳細は、第2.2.18項を参照してください。RDB$SCHEMAまたは別のスキーマ名を指定するには、マルチスキーマ・ネーミングが有効なマルチスキーマ・データベースにアタッチする必要があります。マルチスキーマ・ネーミングが無効な場合は、データベース名に関連付けられた別名を使用して、データベース全体の参照のみを実行できます。

MULTISCHEMA IS句を指定しない場合、マルチスキーマ・ネーミングは、マルチスキーマ属性を使用してデータベースが作成されている場合は有効に設定され、そうでない場合は無効に設定されます。

次の例は、マルチスキーマ属性を使用せずにデータベースにスキーマを作成しようとした場合に、SQLによって生成されるエラーを示しています。

SQL> ATTACH 'FILENAME personnel';
SQL> CREATE SCHEMA PACIFIC_NORTHWEST;
%SQL-F-SCHCATMULTI, Schemas and catalogs may only be referenced
with multischema enabled

2.2.12 非ストアド・モジュール、プロシージャおよびパラメータ名（モジュール言語のみ）

SQLモジュール言語では、SQLモジュール・ファイルと呼ばれる別個のファイルに格納されたSQL文を実行する、ホスト言語プログラムのためのコール・メカニズムが提供されています。このモジュールには、SQLプリコンパイラでサポートされていないものを含め、あらゆるホスト言語からコール可能なSQL文が含まれています。このファイルには、次のようなユーザー指定の名前を含む、モジュール言語要素が格納されています。

モジュール名
SQLモジュールの最初のMODULEキーワードの後に、モジュール名を指定します。モジュール名を指定しない場合、SQL_MODULEというモジュール名が使用されます。
モジュール名は一意である必要があります。非ストアド・モジュールが起動されたときに同一の名前のストアド・モジュールがアクティブな場合、次のエラーが返されます。
%RDB-E-EXT_ERR, Rdb extension error -RDMS-E-MODEXTS, there is another module named SALARY_ROUTINES in this database
プロシージャ名
 どのSQLモジュールにも、プロシージャ名、1つ以上の実パラメータ宣言、および単一の実行SQL文で構成される1つ以上のプロシージャが格納されています。PROCEDUREキーワードの後に、各プロシージャの名前を指定する必要があります。
パラメータ名
SQLモジュールのプロシージャ内の実パラメータを使用して、プロシージャのSQL文によって使用されるパラメータの名前を指定します。特殊な目的のプロシージャ・パラメータとしてSQLキーワード（SQLCODE、SQLCA、SQLDA、SQLSTATE）がありますが、SQLモジュールではそれ以外のすべてのパラメータに名前を付ける必要があります。

SQLモジュール言語の詳細は、第3章を参照してください。

ストアド・モジュール、ストアド・ルーチンおよびストアド・ルーチン・パラメータ名の詳細は、「CREATE MODULE文」または『Oracle Rdb7 Guide to SQL Programming』を参照してください。

2.2.13 パラメータ、ルーチン・パラメータおよびSQL変数

パラメータ、ルーチン・パラメータおよびSQL変数は値式で頻繁に使用されます（値式の詳細は、第2.6節を参照）。

変数は、プログラムの実行中に変更される可能性がある値を表す識別子です。複数文プロシージャではSQL変数を使用できます。

ルーチン・パラメータは、ストアド・ルーチンまたは外部ルーチンで使用される、ルーチンのパラメータに関連付けられている変数です。ストアド・ルーチンは、CREATE MODULE文を使用して定義されるストアド・プロシージャとストアド・ファンクションの両方を指します。外部ルーチンは、CREATE PROCEDURE文およびCREATE FUNCTION文を使用して定義される外部プロシージャと外部ファンクションの両方を指します。

SQL変数を複数文プロシージャで使用するか、ルーチン・パラメータを使用する場合は、標識変数を使用しないでください。複数文プロシージャにおけるSQL変数、およびストアド・ルーチン・パラメータの詳細は、第2.2.13.3項を参照してください。外部ルーチン・パラメータの詳細は、第2.2.13.4項を参照してください。

パラメータは、SQL文に関連付けられているホスト言語プログラムで宣言される識別子です。パラメータは、プログラムの実行中に変更される可能性のある値を表します。通常の値式を受け入れないSQLデータ操作句の多くで、パラメータを使用する必要があります。ただし、データ定義言語文ではパラメータを使用できません。

次の場所でパラメータを使用できます。

対話型SQL
対話型SQLでは、DECLARE変数文を使用してパラメータを宣言します。パラメータおよび変数の宣言の詳細は、「DECLARE変数文」を参照してください。
SQLモジュール言語
 SQL文を含むSQLモジュール・プロシージャをコールするプログラムでは、SQL文によってホスト言語変数が間接的に参照されます。プログラム内で宣言されている変数を、SQLモジュール内のプロシージャに対するホスト言語コール文のパラメータとして指定します。このようなコール文のパラメータは、実パラメータと呼ばれます。
非ストアド・プロシージャでは、コール側プログラムの実パラメータに対応するパラメータ宣言がSQLモジュール・プロシージャに含まれています。このような宣言におけるモジュール・パラメータは、仮パラメータと呼ばれます。モジュール・プロシージャのSQL文では、仮パラメータ名を使用して、モジュール・プロシージャに対するホスト言語コールで指定されている実パラメータが間接的に参照されます。
プリコンパイルされたSQL
プリコンパイルされたプログラムでは、プログラム内に埋め込まれたSQL文によって、ホスト言語変数が直接参照および使用されます。SQLプリコンパイラでは、ホスト言語の宣言構文のサブセットのみがサポートされています。詳細は、第4.4節を参照してください。使用できるのは、ホスト言語のルールに準拠しているパラメータ名のみです。
動的SQL
動的SQLでは、PREPARE文の文字列で疑問符（?）によって表されるパラメータ・マーカーを持つパラメータが、動的に実行されるSQL文によって参照されます。

SQL文では、次の目的でパラメータを使用します。

SQLでは、データベースからデータを取得し、プログラムで使用できるよう、取得したデータをパラメータにセットします。
パラメータには、データベースを更新するためにSQLで使用される、プログラムによって生成されるデータが格納されます。
データ操作文では、値式にパラメータを指定できます。
インジケータ・パラメータと呼ばれる特殊な目的を持つパラメータは、対応するメイン・パラメータに格納されている値がNULLかどうかを示します。（インジケータ・パラメータはストアド・ルーチンでは使用しません。）
SQLでは、SQL文の成功または失敗に関する情報が、SQLCODEと呼ばれるパラメータ、またはステータス・パラメータSQLSTATE（ANSI/ISO SQL規格）に設定されます。パラメータSQLCODEは、明示的に宣言することも、SQL通信領域（SQLCA）の一部として宣言することもできます。
SQLCODEおよびSQLSTATEの詳細は、付録Cを参照してください。
SQLおよびプログラムでは、SQL記述子領域（SQLDAおよびSQLDA2）と呼ばれるパラメータのコレクションを使用して、動的SQL文に関する情報がやりとりされます。詳細は、付録Dを参照してください。

SQL文では、列、表またはビューを参照するパラメータは使用できません。たとえば、BADVARがデータベース内の表の名前を持つホスト言語変数の場合、次の文は無効になります。

EXEC SQL SELECT FIRST_NAME INTO :GOODVAR FROM :BADVAR END-EXEC

プリコンパイラ、モジュール言語または動的SQLを使用する場合、データベースとデータをやりとりするときに、表示操作でCHAR型のホスト変数とともにCASTまたはEXTRACTを使用して、日時データをバイナリ形式から変換する必要があります。次に例を示します。

EXEC SQL SELECT CAST(TBL_INT_H3 AS CHAR(4))
         INTO :string_var3
         FROM ALL_DATE_TABLE;

CASTファンクションおよびEXTRACTファンクションの詳細は、それぞれ第2.6.2.2項および第2.6.2.11項を参照してください。

パラメータの詳細は、第2.2.13.1項を参照してください。