Oracle Database SQL言語リファレンス 11g リリース1(11.1) E05750-03 |
|
この章では、Oracle SQLの基本要素に関する参照情報を説明します。これらの要素は、SQL文の最も単純な構成ブロックです。したがって、第10章〜第19章で説明されている文を使用する前に、この章で説明する概念を理解しておく必要があります。
この章では、次の内容を説明します。
Oracle Databaseが処理する値は、それぞれデータ型を持ちます。値のデータ型は、固定されたプロパティの集合をその値に対応付けます。このプロパティに応じて、Oracleは、あるデータ型の値を別のデータ型の値と区別して扱います。たとえば、NUMBER
データ型の値は加算できますが、RAW
データ型の値は加算できません。
表またはクラスタを作成する場合、各列にデータ型を指定する必要があります。プロシージャまたはストアド・ファンクションを作成する場合は、その各引数にデータ型を指定する必要があります。データ型によって、各列が含むことができる値のドメイン、または各引数が持つことができる値のドメインが決まります。たとえば、DATE
列は、2月29日(うるう年を除く)、2または'SHOE'という値を格納できません。列に入る値は、その列のデータ型を受け継ぎます。たとえば、DATE
列に'01-JAN-98'
を挿入すると、Oracleはそれが有効な日付に変換されることを確認してから、文字列'01-JAN-98'
をDATE
値として扱います。
Oracle Databaseには、多くの組込みデータ型、およびデータ型として使用できるいくつかのユーザー定義型のカテゴリがあります。Oracleのデータ型の構文については、次の構文図で示します。この項は、次の4つの項にわかれています。
データ型はスカラーまたは非スカラーです。スカラー型は、アトム値を持ちますが、非スカラー型(コレクションともいう)は一連の値を持ちます。ラージ・オブジェクト(LOB)は、スカラー型の特別な形で、バイナリまたは文字データのラージ・スカラー値を表しています。LOBはサイズが大きいため、他のスカラー型には影響しないいくつかの制限事項があります。これらの制限事項については、関連するSQL構文を参照してください。
Oracleプリコンパイラによって、埋込みSQLプログラムで他のデータ型が区別されます。このようなデータ型は、外部データ型と呼ばれ、ホスト変数に対応付けられています。組込みデータ型およびユーザー定義型を外部データ型と混同しないでください。Oracleによる外部データ型と組込み型またはユーザー定義データ型の間の変換など、外部データ型の詳細は、『Pro*COBOLプログラマーズ・ガイド』および『Pro*C/C++プログラマーズ・ガイド』を参照してください。
Oracle組込みデータ型の詳細は、「Oracleの組込みデータ型」を参照してください。
次に、ANSIがサポートしているデータ型について示します。また、「ANSI、DB2、SQL/DSのデータ型」に、ANSIがサポートしているデータ型をOracle組込みデータ型にマップする方法を示します。
expression_filter_type
の詳細は、「Expression Filter型」を参照してください。次に、Oracleが提供するその他の型を示します。
任意
型の詳細は、「任意型」を参照してください。
XML型の詳細は、「XML型」を参照してください。
空間型の詳細は、「空間型」を参照してください。
メディア型の詳細は、「メディア型」を参照してください。
次の表にOracle組込みデータ型の概要を示します。構文要素については、前の項の構文を参照してください。データ型のコードは、Oracle Databaseが内部的に使用します。DUMP
ファンクションによって、列またはオブジェクト属性のデータ型コードが戻されます。
次の項では、Oracle Databaseに格納されるOracleデータ型について説明します。これらのデータ型をリテラルとして指定する方法については、「リテラル」を参照してください。
文字データ型を使用すると、単語や自由形式のテキストなど、データベース・キャラクタ・セットまたは各国語キャラクタ・セットの文字(英数字)を格納できます。文字データ型は、他のデータ型より制限が少ないため、プロパティも少なくなります。たとえば、文字データ型の列は、すべての英数字の値を格納できますが、NUMBER
型の列が格納できるのは数値のみです。
文字データは、7ビットASCIIやEBCDICなど、データベース作成時に指定されたキャラクタ・セットの1つに対応しているバイト値で文字列に格納されます。Oracle Databaseは、シングルバイトのキャラクタ・セットとマルチバイトのキャラクタ・セットの両方をサポートします。
次のデータ型が、文字データに対して使用されます。
文字データ型をリテラルとして指定する方法については、「テキスト・リテラル」を参照してください。
CHAR
データ型は、固定長の文字列を指定します。Oracleでは、CHAR
列に格納される値がすべてsize
で指定した長さを持つように調整されます。列の長さより短い値を挿入すると、列の長さにあわせるため、その値の後に空白が埋め込まれます。列に対して長すぎる値を挿入しようとすると、Oracleはエラーを戻します。
CHAR
列のデフォルトの長さは1バイトで、この許容最大値は2000バイトです。CHAR(10)
列には、1バイトの文字列を挿入できますが、この文字列は10バイトまで空白埋めされてから格納されます。
CHAR
列を持つ表を作成する場合、デフォルトでは列の長さはバイト単位になります。BYTE
修飾子は、デフォルトと同じです。CHAR
修飾子(たとえば、CHAR
(10
CHAR
))を使用すると、列の長さは文字単位になります。技術的ないい方をすると、文字は、データベース・キャラクタ・セットのコード・ポイントです。サイズは、データベース・キャラクタ・セットによって異なりますが、1バイトから4バイトです。BYTE
およびCHAR
修飾子は、NLS_LENGTH_SEMANTICS
パラメータ(デフォルトはバイト・セマンティクス)で指定したセマンティクスを上書きします。パフォーマンス上の理由から、長さセマンティクスの設定にはNLS_LENGTH_SEMANTICS
パラメータを使用し、このパラメータを上書きする必要があるときにのみBYTE
およびCHAR
修飾子を使用することをお薦めします。
異なるキャラクタ・セットを持つデータベース間で適切にデータを変換するには、CHAR
データが正しい書式の文字列で構成されていることを確認してください。
参照:
キャラクタ・セット・サポートの詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。比較セマンティクスについては、「データ型の比較規則」を参照してください。 |
NCHAR
データ型はUnicodeのみのデータ型です。NCHAR
列を持つ表を作成する場合、列の長さを文字単位で指定します。使用する各国語キャラクタ・セットは、データベースを作成するときに指定します。
列の最大長は、各国語キャラクタ・セットの定義によって決まります。NCHAR
文字データ型の幅指定は、文字数を示します。許容最大列サイズは2000バイトです。
列の長さより短い値を挿入すると、列の長さにあわせるため、その値の後に空白が埋め込まれます。CHAR
値をNCHAR
列に挿入することや、NCHAR
値をCHAR
列に挿入することはできません。
次の例では、表pm.product_descriptions
のtranslated_description
列と各国語キャラクタ・セットの文字列を比較します。
SELECT translated_description FROM product_descriptions WHERE translated_name = N'LCD Monitor 11/PM';
NVARCHAR2
データ型はUnicodeのみのデータ型です。NVARCHAR2
列を持つ表を作成する場合、保持できる最大の文字数を指定します。Oracleでは、列の最大長を超えないかぎり、各値を指定されたとおりに正確に列に格納します。
列の最大長は、各国語キャラクタ・セットの定義によって決まります。NVARCHAR2
文字データ型の幅指定は、文字数を示します。許容最大列サイズは4000バイトです。
VARCHAR2
データ型は、可変長の文字列を指定します。VARCHAR2
列を作成する場合、保持できるデータの最大バイト数または最大文字数を指定します。Oracleでは、列の最大長を超えないかぎり、各値を指定されたとおりに正確に列に格納します。最大長を超える値を挿入しようとすると、Oracleはエラーを戻します。
VARCHAR2
列には最大長を指定する必要があります。保存される文字列の実際の長さは0(ゼロ)にできますが、最大長は1バイト以上にする必要があります。CHAR
修飾子(たとえば、VARCHAR2
(10
CHAR
))を使用すると、バイトではなく、文字で最大長を指定できます。技術的ないい方をすると、文字は、データベース・キャラクタ・セットのコード・ポイントです。BYTE
修飾子(たとえば、VARCHAR2
(10 BYTE
))を使用すると、明示的にバイトで最大長を指定できます。列定義または属性定義に明示的な修飾子が含まれていないときにその列または属性を持つデータベース・オブジェクトを作成した場合、長さセマンティクスは、そのオブジェクトを作成するセッションのNLS_LENGTH_SEMANTICS
パラメータの値によって決定されます。文字での最大長と関係なく、VARCHAR2
データの長さは4000バイト以下になります。Oracleは、非空白埋め比較セマンティクスを使用してVARCHAR2
値を比較します。
異なるキャラクタ・セットを持つデータベース間で適切にデータを変換するには、VARCHAR2
データが正しい書式の文字列で構成されていることを確認してください。キャラクタ・セット・サポートの詳細は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。
VARCHAR
データ型は、使用しないでください。かわりにVARCHAR2
データ型を使用してください。現在、VARCHAR
データ型はVARCHAR2
データ型と同じ意味で使用されていますが、VARCHAR
データ型は、異なる比較セマンティクスで比較される別の可変長文字列のデータ型に変更される予定です。
Oracle Databaseの数値データ型は、正と負の固定小数点数と浮動小数点数、0(ゼロ)、無限大、および操作の未定義の結果である値(非数値、つまりNAN
)を格納します。数値データ型をリテラルとして指定する方法については、「数値リテラル」を参照してください。
NUMBER
データ型は、0(ゼロ)と、絶対値が1.0×10-130以上1.0×10126未満の範囲にある正と負の固定小数点数を格納します。1.0×10126以上の絶対値を持つ算術式を指定した場合、Oracleはエラーを戻します。NUMBER
の各値は1〜22バイトである必要があります。
次の書式で固定小数点数を指定できます。
NUMBER(p,s)
それぞれの意味は、次のとおりです。
p
は精度(precision)、つまり最大有効桁数(10進)です。最上位有効桁は最も左側のゼロ以外の桁で、最下位有効桁は最も右側の桁です。Oracleは、100進数で20桁までの精度で数値の移植性を保証します。これは小数点の位置によって39桁(10進)または40桁(10進)になります。
s
は位取り(scale)、つまり小数点から最下位有効桁までの桁数です。位取りの有効範囲は-84〜127です。
e
表記を使用する場合、位取りは通常、精度よりも大きくなります。位取りが精度より大きい場合、精度は小数点の右側にある最大有効桁数を示します。たとえば、NUMBER(4,5)
として定義された列は、小数点の後の最初の桁が0(ゼロ)である必要があり、小数点以下5桁を超える値はすべて丸められます。
入力に対する特別な整合性チェックとして、固定小数点数列の位取りと精度を指定することをお薦めします。位取りと精度を指定しても、すべての値が固定長に強制されるわけではありません。値が精度の有効範囲を超えると、Oracleはエラーを戻します。値が位取りの有効範囲を超えると、Oracleはその値を丸めます。
次の書式で整数を指定できます。
NUMBER(p)
これは、精度がp
で、位取りが0の固定小数点数です(NUMBER(p,0)
と同じです)。
次の書式で浮動小数点を指定できます。
NUMBER
精度および位取りを指定しない場合、最大の範囲および精度をOracleの数値に指定したことになります。
表2-2に、異なる精度および位取りを使用したOracleのデータの格納方法を示します。
FLOAT
データ型は、NUMBER
のサブタイプです。このデータ型は、精度とともに指定するか、または精度なしで指定でき、その定義はNUMBER
の場合と同じであり、1〜126の範囲で指定します。位取りは指定できませんが、データから解釈されます。FLOAT
の各値は1〜22バイトである必要があります。
2進精度から10進精度に変換するには、n
に0.30103を乗算します。10進精度から2進精度に変換するには、10進精度に3.32193を乗算します。2進精度の126桁は、10進精度の38桁とほぼ等しくなります。
NUMBER
とFLOAT
の違いは、例を使用して説明します。次の例では、同じ値がNUMBER
列とFLOAT
列に挿入されます。
CREATE TABLE test (col1 NUMBER(5,2), col2 FLOAT(5)); INSERT INTO test VALUES (1.23, 1.23); INSERT INTO test VALUES (7.89, 7.89); INSERT INTO test VALUES (12.79, 12.79); INSERT INTO test VALUES (123.45, 123.45); SELECT * FROM test; COL1 COL2 ---------- ---------- 1.23 1.2 7.89 7.9 12.79 13 123.45 120
この例では、戻されるFLOAT
の値は、5桁(2進)を超えることはできません。5桁(2進)で表すことができる10進数の最大値は31です。最後の行には、31を超える10進値が含まれています。このため、FLOAT
の値は、その有効桁数が5桁(2進)を超えないように切り捨てられる必要があります。したがって、123.45は、2桁の有効桁数(10進)のみを持ち、4桁(2進)しか必要のない120に丸められます。
ANSIのFLOAT
データを変換する際、Oracle Databaseは、OracleのFLOAT
データ型を内部的に使用します。OracleのFLOAT
は使用可能ですが、BINARY_FLOAT
およびBINARY_DOUBLE
データ型の方がより堅牢であるため、これらのデータ型を使用することをお薦めします。詳細は、「浮動小数点数」を参照してください。
浮動小数点数は、最初の桁から最後の桁までの任意の位置に小数点を置くことも、小数点を省略することもできます。指数は、数字の後に増加する桁数を表すときに、オプションで使用されます(たとえば、1.777 e-20)。小数点以下の桁数に制限はないため、浮動小数点数に対して位取りは指定できません。
2進浮動小数点数とNUMBER
では、Oracle Databaseによる内部的な値の格納方法が異なります。NUMBER
の場合、値は10進精度を使用して格納されます。NUMBER
でサポートされる範囲内および精度内のすべてのリテラルは、NUMBER
として正確に格納されます。これは、リテラルが10進精度(0〜9)を使用して表されるためです。2進浮動小数点数は、2進精度(0および1)を使用して格納されます。このような格納スキームでは、10進精度を使用したすべての値を正確に表すことができません。値を10進精度から2進精度に変換するときに発生するエラーは、その値を2進精度から10進精度に戻すときには発生しない場合が多くあります。リテラル0.1はその一例です。
Oracle Databaseでは、浮動小数点数専用の2種類の数値データ型を提供しています。
32ビットの単精度浮動小数点数データ型です。このデータ型の各値には、長さを示すバイトを含め、5バイトが必要です。
64ビットの倍精度浮動小数点数データ型です。このデータ型の各値には、長さを示すバイトを含め、9バイトが必要です。
NUMBER
列では、浮動小数点数は10進精度を持ちます。BINARY_FLOAT
列またはBINARY_DOUBLE
列では、浮動小数点数は2進精度を持ちます。2進浮動小数点数では、特殊な値である無限大およびNaN
(非数値)がサポートされます。
表2-3に示す制限内で、浮動小数点数を指定できます。浮動小数点数を指定する書式については、「数値リテラル」を参照してください。
値 | BINARY_FLOAT | BINARY_DOUBLE |
---|---|---|
正の最大有限値 |
3.40282E+38F |
1.79769313486231E+308 |
正の最小有限値 |
1.17549E-38F |
2.22507485850720E-308 |
Oracleの浮動小数点データ型の実装は、2進浮動小数点算術の規格である電気電子学会(IEEE)754-1985(IEEE754)規格に準拠しています。浮動小数点データ型は次の点でIEEE754に準拠しています。
SQRT
は平方根を実装します。「SQRT」を参照してください。
REMAINDER
は余りを実装します。「REMAINDER」を参照してください。
NaN
と比較する場合は除きます。Oracleは、NaN
が他のすべての値より大きいとみなし、NaN
とNaN
は等しいと評価します。「浮動小数点条件」を参照してください。
INF
、-INF
およびNaN
がサポートされています。「浮動小数点条件」を参照してください。
BINARY_FLOAT
およびBINARY_DOUBLE
の値を整数値のBINARY_FLOAT
およびBINARY_DOUBLE
に丸める方法として、SQLファンクションROUND
、TRUNC
、CEIL
およびFLOOR
が提供されています。
BINARY_FLOAT
およびBINARY_DOUBLE
を10進値に、10進値をBINARY_FLOAT
およびBINARY_DOUBLE
に丸める方法として、SQLファンクションTO_CHAR
、TO_NUMBER
、TO_NCHAR
、TO_BINARY_FLOAT
、TO_BINARY_DOUBLE
およびCAST
が提供されています。
浮動小数点データ型は次の点ではIEEE754に準拠していません。
NaN
との比較はサポートされていません。
NaN
値は、BINARY_FLOAT_NAN
またはBINARY_DOUBLE_NAN
のいずれかに強制変換されます。
数値データ型をサポートする操作で、操作の引数が様々なデータ型を持つ場合、Oracleが使用するデータ型は、数値の優先順位によって判断されます。数値の優先順位が最も高いデータ型はBINARY_DOUBLE
であり、その次がBINARY_FLOAT
、最後がNUMBER
となります。したがって、複数の数値に対する操作では、次のようになります。
BINARY_DOUBLE
の場合、Oracleは操作の実行前に、すべてのオペランドを暗黙的にBINARY_DOUBLE
に変換しようとします。
BINARY_DOUBLE
はないが、いずれかがBINARY_FLOAT
の場合、Oracleは操作の実行前に、すべてのオペランドを暗黙的にBINARY_FLOAT
に変換しようとします。
NUMBER
に変換しようとします。
暗黙的な変換が必要な場合に変換に失敗すると、操作は実行されません。暗黙的な変換の詳細は、表2-10「暗黙的な型変換のマトリックス」を参照してください。
他のデータ型のコンテキストでは、数値データ型の優先順位は、日時データ型と期間データ型よりも低く、文字データ型とその他のすべてのデータ型よりも高くなります。
LONG
列を持つ表は作成しないでください。かわりに、LOB列(CLOB
、NCLOB
またはBLOB
)を使用してください。LONG
列は、下位互換性のためにサポートされています。
LONG
列には、2GB(231)から1を引いたバイト数までの可変長の文字列を格納できます。LONG
列には、多くの点でVARCHAR2
列と同じ特長があります。LONG
列を使用すると、長いテキスト文字列を格納できます。LONG
値の長さは、ご使用のコンピュータで利用できるメモリーによって制限される場合もあります。LONG
リテラルは、「テキスト・リテラル」の説明のような形式になります。
既存のLONG
列もLOB列に変換することをお薦めします。LOB列は、LONG
列ほど制限は多くありません。LOB機能はリリースごとに拡張されていますが、LONG
機能は最近のリリースでは変更されていません。LONG
列からLOB列への変換については、「ALTER TABLE」の「modify_col_properties
」および「TO_LOB」を参照してください。
SQL文の中の次の場所でLONG
列を参照できます。
LONG
値を使用する場合には、次の制限があります。
LONG
列を含めることはできません。
LONG
属性を持つオブジェクトは作成できません。
LONG
列は、WHERE
句または整合性制約では指定できません(NULL
およびNOT
NULL
制約は除く)。
LONG
列に索引を付けることはできません。
LONG
データは正規表現では指定できません。
LONG
値を戻すことはできません。
LONG
データ型を使用して、PL/SQLプログラム・ユニットの変数または引数を宣言できます。ただし、そのプログラムは、SQLからコールできません。
LONG
列、更新された表、ロックされた表は、同一データベース上にある必要があります。
LONG
列およびLONG
RAW
列は、分散型のSQL文で使用できません。また、レプリケートできません。
LONG
とLOBの両方の列を持つ表では、1つのSQL文で両方に4000バイトより大きいデータをバインドすることはできません。ただし、いずれか片方にバインドすることは可能です。
また、LONG
列はSQL文の次のような部分では使用できません。
GROUP
BY
句、ORDER
BY
句、CONNECT
BY
句またはSELECT
文にあるDISTINCT
演算子
SELECT
文の一意演算子
CREATE
CLUSTER
文の列リスト
CREATE
MATERIALIZED
VIEW
文のCLUSTER
句
GROUP
BY
句を含む問合せのSELECT
構文のリスト
UNION
、INTERSECT
またはMINUS
集合演算子によって結合されている副問合せまたは問合せのSELECT
構文のリスト
CREATE
TABLE
...AS
SELECT
文のSELECT
構文のリスト
ALTER
TABLE
...MOVE
文
INSERT
文の副問合せのSELECT
構文のリスト
トリガーでは、LONG
データ型は次のように使用されます。
LONG
列に挿入できます。
LONG
列のデータをCHAR
やVARCHAR2
などの制約があるデータ型に変換できる場合は、トリガー内のSQL文でLONG
列を参照できます。
LONG
データ型を使用して宣言できません。
:NEW
と:OLD
はLONG
列で使用できません。
Oracle Call Interfaceを使用して、データベースからLONG
値の一部を検索できます。
日時データ型には、DATE
、TIMESTAMP
、TIMESTAMP
WITH
TIME
ZONE
およびTIMESTAMP
WITH
LOCAL
TIME
ZONE
があります。日時データ型の値は、「日時」とも呼ばれます。期間データ型には、INTERVAL
YEAR
TO
MONTH
およびINTERVAL
DAY
TO
SECOND
があります。期間データ型の値は、「期間」とも呼ばれます。日時値と期間値をリテラルとして表す方法の詳細は、「日時リテラル」および「期間リテラル」を参照してください。
日時および期間はいずれもフィールドで構成されます。これらのフィールドの値は、データ型の値によって決まります。表2-4に、日時フィールド、および日時と期間の有効な値を示します。
日時データのDML操作で正しい結果を得るには、組込みSQLファンクションDBTIMEZONE
およびSESSIONTIMEZONE
で問い合せることによって、データベースおよびセッションのタイムゾーンを確認します。タイムゾーンを手動で設定していない場合、Oracle Databaseは、オペレーティング・システムのタイムゾーンをデフォルトで使用します。オペレーティング・システムのタイムゾーンがOracleで有効でない場合は、Oracleは、協定世界時(UTC)(以前のグリニッジ標準時)をデフォルトの値として使用します。
DATE
データ型は、日付および時刻の情報を格納するために使用します。日付および時刻の情報は、文字データ型および数値データ型で表現できますが、DATE
データ型には特別に対応付けられているプロパティがあります。各DATE
値には、世紀、年、月、日、時、分および秒の情報が格納されます。
DATE
値をリテラルに指定するか、文字値や数値をTO_DATE
ファンクションによって日付値に変換できます。これらの方法でのDATE
値の表し方の例は「日時リテラル」を参照してください。
ユリウス日は、紀元前4712年1月1日から経過した日数です。ユリウス日によって共通の基準で日付を算定できます。日付ファンクションTO_DATE
とTO_CHAR
で日付書式モデル「J」を使用して、OracleのDATE
値とユリウス日の間で変換を行うことができます。
デフォルトの日付値は次のように決まります。
これらのデフォルト値は、次の例(5月に発行)のように、日付が指定されていない場合に日付値を要求する問合せで使用されます。
SELECT TO_DATE('2005', 'YYYY') FROM DUAL; TO_DATE(' --------- 01-MAY-05
次の文では、1997年1月1日をユリウス日で戻します。
SELECT TO_CHAR(TO_DATE('01-01-1997', 'MM-DD-YYYY'),'J') FROM DUAL; TO_CHAR -------- 2450450
TIMESTAMP
データ型は、DATE
データ型の拡張機能です。DATE
データ型の年、月および日に加えて、時、分および秒の値を格納します。このデータ型は、正確な時刻の値の格納に有効です。TIMESTAMP
データ型は、次のように指定します。
TIMESTAMP [(fractional_seconds_precision)]
fractional_seconds_precision
には、オプションで、Oracleが格納する桁数を、SECOND
日時フィールドの小数部まで指定します。このデータ型の列を作成する場合、0〜9の値を指定できます。デフォルト値は6です。
TIMESTAMP
WITH
TIME
ZONE
は、タイムゾーン地域名またはタイムゾーン・オフセットを値に含むTIMESTAMP
の変形です。タイムゾーン・オフセットは、ローカルの時刻とUTC(時および分)との差異です。このデータ型は複数の地域にまたがる日時情報の収集および評価に有効です。
TIMESTAMP
WITH
TIME
ZONE
データ型は、次のように指定します。
TIMESTAMP [(fractional_seconds_precision)] WITH TIME ZONE
fractional_seconds_precision
には、オプションで、Oracleが格納する桁数を、SECOND
日時フィールドの小数部まで指定します。このデータ型の列を作成する場合、0〜9の値を指定できます。デフォルト値は6です。
参照:
|
TIMESTAMP
WITH
LOCAL
TIME
ZONE
は、タイムゾーン・オフセットを値に含むTIMESTAMP
のもう1つの変形です。これは、TIMESTAMP
WITH
TIME
ZONE
とは異なり、データベースに格納されるデータはデータベース・タイムゾーンに対して正規化され、タイムゾーン・オフセットは列データの一部として格納されません。ユーザーがデータを検索すると、Oracleはユーザーのローカル・セッション・タイムゾーンのデータを戻します。タイムゾーン・オフセットは、ローカルの時刻とUTC(時および分)との差異です。このデータ型は、2層アプリケーションでクライアント・システムのタイムゾーンの日時情報を表示する場合に有効です。
TIMESTAMP
WITH
LOCAL
TIME
ZONE
データ型は、次のように指定します。
TIMESTAMP [(fractional_seconds_precision)] WITH LOCAL TIME ZONE
fractional_seconds_precision
には、オプションで、Oracleが格納する桁数を、SECOND
日時フィールドの小数部まで指定します。このデータ型の列を作成する場合、0〜9の値を指定できます。デフォルト値は6です。
参照:
|
INTERVAL
YEAR
TO
MONTH
は、YEAR
およびMONTH
日時フィールドを使用して期間を格納します。このデータ型は、年および月の値のみが重要な場合に、2つの日時の値の正確な違いを表す場合に有効です。
INTERVAL
YEAR
TO
MONTH
は、次のように指定します。
INTERVAL YEAR [(year_precision)] TO MONTH
year_precision
は、YEAR
日時フィールドの桁数です。year_precision
のデフォルト値は2です。
期間値をリテラルとして指定すると、高い柔軟性が得られます。期間値をリテラルとして指定する方法の詳細は、「期間リテラル」を参照してください。期間の使用例は、「日時および期間の例」を参照してください。
INTERVAL
DAY
TO
SECOND
は、日付、時、分および秒で期間を格納します。このデータ型は、2つの日時の値の正確な違いを表す場合に有効です。
このデータ型は、次のように指定します。
INTERVAL DAY [(day_precision)] TO SECOND [(fractional_seconds_precision)]
それぞれの意味は、次のとおりです。
day_precision
は、DAY
日時フィールドの桁数です。有効範囲は0〜9です。デフォルトは2です。
fractional_seconds_precision
は、SECOND
日時フィールドの小数部の桁数です。有効範囲は0〜9です。デフォルトは6です。
期間値をリテラルとして指定すると、高い柔軟性が得られます。期間値をリテラルとして指定する方法の詳細は、「期間リテラル」を参照してください。期間の使用例は、「日時および期間の例」を参照してください。
日付(DATE
)、タイムスタンプ(TIMESTAMP
、TIMESTAMP
WITH
TIME
ZONE
およびTIMESTAMP
WITH
LOCAL
TIME
ZONE
)および期間(INTERVAL
DAY
TO
SECOND
およびINTERVAL
YEAR
TO
MONTH
)データに対して、様々な演算処理を実行できます。Oracleは、次の規則に基づいて結果を計算します。
NUMBER
定数を使用できますが、期間値では使用できません。Oracleは、タイムスタンプ値を内部的に日付値に変換し、日時の演算で使用されるNUMBER
定数と期間式を日数として解析します。たとえば、SYSDATE
+ 1は明日です。SYSDATE
-7は1週間前です。SYSDATE
+ (10/1440)は10分後です。SYSDATE
からemployees
サンプル表のhire_date
列を引くと、各従業員が雇用されてから経過した日数が戻ります。日付値またはタイムスタンプ値の乗算や除算はできません。
BINARY_FLOAT
オペランドおよびBINARY_DOUBLE
オペランドを暗黙的にNUMBER
に変換します。
DATE
値には時刻コンポーネントが含まれるため、多くの場合、日付操作の結果には小数部が含まれます。この小数部は、日を単位として表されています。たとえば、1.5日は36時間です。小数部は、DATE
データの一般的な操作を行うOracle組込みファンクションによっても戻されます。たとえば、MONTHS_BETWEEN
ファンクションは、2つの日付の間の月数を戻します。結果の小数部は、月(1か月は31日)を単位として表されます。
DATE
値または数値であり、タイムゾーンおよび小数部コンポーネントのいずれも含まない場合、次のようになります。
DATE
データ型専用に設計された組込みファンクションにタイムスタンプ値、期間値または数値を渡すと、OracleはDATE
値以外の値を暗黙的にDATE
値に変換します。DATE
への暗黙的な変換を実行するファンクションの詳細は、「日時ファンクション」を参照してください。
SELECT TO_DATE('31-AUG-2004','DD-MON-YYYY') + TO_YMINTERVAL('0-1') FROM DUAL; SELECT TO_DATE('29-FEB-2004','DD-MON-YYYY') + TO_YMINTERVAL('1-0') FROM DUAL;
最初の文は、1か月31日の月に1か月が追加され、9月31日となります。これは有効な日付ではないため、この文は失敗します。2つ目の文は、4年に1度のみ存在する日付に1年を追加する計算は無効であるため、失敗します。ただし、2月29日に4年を追加する計算は有効であるため、次の文は成功します。
SELECT TO_DATE('29-FEB-2004', 'DD-MON-YYYY') + TO_YMINTERVAL('4-0') FROM DUAL; TO_DATE(' --------- 29-FEB-08
TIMESTAMP
WITH
LOCAL
TIME
ZONE
では、Oracleは、日時の値をデータベース・タイムゾーンからUTCに変換し、演算を実行した後にデータベース・タイムゾーンに変換しなおします。TIMESTAMP
WITH
TIME
ZONE
では、日時の値は常にUTCであるため、変換は必要ありません。
表2-5に、日時の演算処理のマトリックスを示します。ダッシュはサポートされていない処理を表します。
期間値の式を開始時間に追加できます。order_date
列を持つサンプル表oe.orders
について考えます。次の文は、order_date
列の値に30日を加算します。
SELECT order_id, order_date + INTERVAL '30' DAY FROM orders ORDER BY order_id, "Due Date";
Oracle Databaseは、指定したタイムゾーン地域に、夏時間が適用されているかを自動的に判断し、それに応じてローカル時刻の値を戻します。日時の値は、境界を除いたすべての指定した地域において、夏時間が適用されているかをOracleが判断するために有効です。夏時間の開始または終了時に、境界が発生します。たとえば、米国の太平洋地域では、夏時間の開始時、時刻は午前2時から午前3時に変更されます。午前2時と午前3時の間の1時間は存在しません。夏時間の終了時、時刻は午前2時から午前1時に変更されます。午前1時と午前2時の間の1時間は繰り返されます。
このような境界を解決するために、OracleはTZR
およびTZD
書式要素を使用します。詳細は、表2-17を参照してください。TZR
は、日時の入力文字列でタイムゾーン地域を表します。たとえば、Australia/North
、UTC
、Singapore
などです。TZD
は、夏時間情報を含むタイムゾーン地域の略称書式です。たとえば、米国/太平洋標準時はPST
、米国/太平洋夏時間はPDT
などです。TZR
およびTZD
書式要素の値を表示するには、V$TIMEZONE_NAMES
動的パフォーマンス・ビューのTZNAME
およびTZABBREV
列に問合せを実行してください。
両方のファイルに含まれるすべてのタイムゾーン地域名のリストは、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。
参照:
|
次の例では、日時および期間データ型の指定方法を示します。
CREATE TABLE time_table ( start_time TIMESTAMP, duration_1 INTERVAL DAY (6) TO SECOND (5), duration_2 INTERVAL YEAR TO MONTH);
start_time
列は、TIMESTAMP
型です。TIMESTAMP
の暗黙的な小数部の精度は6です。
duration_1
列は、INTERVAL
DAY
TO
SECOND
型です。DAY
フィールドの最大桁数は6です。また、小数部の最大桁数は5です(その他のすべての日時フィールドの最大桁数は2です)。
duration_2
列は、INTERVAL
YEAR
TO
MONTH
型です。各フィールド(YEAR
およびMONTH
)の値の最大桁数は2です。
期間データ型には書式モデルはありません。そのため、これらの表示を調整するには、EXTRACT
などの文字ファンクションを結合させて要素を連結させる必要があります。たとえば、次の例では、hr.employees
とoe.orders
表にそれぞれ問合せを行い、期間出力の書式を"yy-mm"から"yy years mm months"に、および"dd-hh"から"dddd days hh hours"に変更します。
SELECT last_name, EXTRACT(YEAR FROM (SYSDATE - hire_date) YEAR TO MONTH ) || ' years ' || EXTRACT(MONTH FROM (SYSDATE - hire_date) YEAR TO MONTH ) || ' months' "Interval" FROM employees ; LAST_NAME Interval ------------------------- -------------------- King 17 years 11 months Kochhar 15 years 8 months De Haan 12 years 4 months Hunold 15 years 4 months Ernst 14 years 0 months Austin 7 years 11 months Pataballa 7 years 3 months Lorentz 6 years 3 months Greenberg 10 years 9 months . . . SELECT order_id, EXTRACT(DAY FROM (SYSDATE - order_date) DAY TO SECOND ) || ' days ' || EXTRACT(HOUR FROM (SYSDATE - order_date) DAY TO SECOND ) || ' hours' "Interval" FROM orders; ORDER_ID Interval ---------- -------------------- 2458 2095 days 18 hours 2397 2000 days 17 hours 2454 2048 days 16 hours 2354 1762 days 16 hours 2358 1950 days 15 hours 2381 1823 days 13 hours 2440 2080 days 12 hours 2357 2680 days 11 hours 2394 1917 days 10 hours 2435 2078 days 10 hours . . .
RAW
データ型とLONG
RAW
データ型には、異なるシステム間でデータを移動する際にOracle Databaseによって明示的に変換されないデータが格納されます。これらのデータ型は、バイナリ・データまたはバイト列に使用されます。たとえば、LONG
RAW
は、図形、音声、文書、またはバイナリ・データの配列の格納に使用できますが、解析方法は用途によって異なります。
LONG
RAW
列をバイナリLOB(BLOB
)へ変換することをお薦めします。LOB列は、LONG
列ほど制限は多くありません。詳細は、「TO_LOB」を参照してください。
RAW
は、VARCHAR2
と同様に可変長データ型ですが、Oracle Net(ユーザー・セッションとインスタンスを接続します)およびOracleのインポート/エクスポート・ユーティリティは、RAW
またはLONG
RAW
データの転送時に文字変換を行いません。これに対し、Oracle NetおよびOracleのインポート/エクスポート・ユーティリティは、CHAR
、VARCHAR2
およびLONG
データをデータベース・キャラクタ・セットからユーザー・セッションのキャラクタ・セットに自動的に変換します。2つのキャラクタ・セットが異なる場合は、ALTER
SESSION
文のNLS_LANGUAGE
パラメータでユーザー・セッションのキャラクタ・セットを設定できます。
RAW
データまたはLONG
RAW
データとCHAR
データ間で、データを自動的に変換するときに、バイナリ・データは16進数で表されます。1つの16進文字で4ビットのRAW
データを表します。たとえば、ビット列が11001011で表示される1バイトのRAW
データは、CB
として表示または入力されます。
組込みLOBデータ型のBLOB
、CLOB
、NCLOB
(内部ファイルに格納)およびBFILE
(外部ファイルに格納)には、構造化されていない大きいデータ(text、image、video、spatial dataなど)を格納できます。BLOB
、CLOB
およびNCLOB
データの最大サイズは、232から1を引いたバイト数にLOB記憶域のCHUNK
パラメータの値を掛けた値です。データベースの表領域が標準のブロック・サイズで、LOB列を作成したときにLOB記憶域のCHUNK
パラメータのデフォルト値を使用した場合には、前述の値は232バイトから1を引いた値にデータベース・ブロック・サイズを掛けた値に等しくなります。BFILE
データの最大サイズは、264バイトから1を引いた値ですが、この最大サイズはオペレーティング・システムによって制限される場合があります。
表を作成するときに、LOB列またはLOBオブジェクト属性に、オプションで表に指定したものとは異なる表領域および記憶特性を指定できます。
LOB列の作成時に行の記憶域を使用可能にしている場合、CLOB
、NCLOB
およびBLOB
の値は、約4000 バイトを上限としてインラインに格納されます。4000バイトを超えるLOBは、常に外部ファイルに格納されます。詳細は、「ENABLE STORAGE IN ROW」を参照してください。
LOB列には、内部のLOB値(データベース内)または外部のLOB値(データベース外)を参照できるLOBロケータが含まれています。表からLOBを選択すると、実際にはLOBのロケータが戻され、LOB値全体は戻されません。LOBに対するDBMS_LOB
パッケージとOracle Call Interface(OCI)の操作は、これらのロケータを介して行われます。
LOBは、LONG
型およびLONG
RAW
型と似ていますが、次の点で異なります。
BLOB
、NCLOB
およびCLOB
の値は、別々の表領域に格納されます。BFILE
データは、サーバー上の外部ファイルに格納されます。
BFILE
データの最大サイズは、264バイトから1を引いた値ですが、この最大サイズはオペレーティング・システムによって制限される場合があります。
NCLOB
の例外を除いて、1つのオブジェクトに1つ以上のLOB属性を定義できます。
NULL
、つまり空に設定したり、LOB全体をデータに置き換えられます。BFILE
は、NULL
に設定したり、別のファイルを指すように設定できます。
INSERT
文またはUPDATE
文を発行するだけで、インラインLOB列(データベースに格納されているLOB列)またはLOB属性(データベースに格納されているオブジェクト型列の属性)の行にアクセスして移入することができます。
LOB列には、多数のルールおよび制限事項があります。詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。
参照:
|
BFILE
データ型を使用すると、Oracle Database外のファイル・システムに格納されているバイナリ・ファイルLOBにアクセスできます。BFILE
列または属性には、サーバーのファイル・システム上のバイナリ・ファイルに対するポインタとして機能する、BFILE
ロケータが格納されます。ロケータには、ディレクトリ名とファイル名が保持されます。
BFILENAME
ファンクションを使用すると、実表のデータに影響を与えずにBFILE
のファイル名およびパスを変更できます。この組込みSQLファンクションの詳細は、「BFILENAME」を参照してください。
バイナリ・ファイルLOBは、トランザクションには関係なく、リカバリができません。ファイルの統合性と耐久性を提供しているのは基本にあるオペレーティング・システムです。BFILE
データの最大サイズは、264バイトから1を引いた値ですが、この最大サイズはオペレーティング・システムによって制限される場合があります。
データベース管理者は、外部ファイルが存在し、Oracleのプロセスがファイルに対するオペレーティング・システムの読取り権限を持っていることを確認する必要があります。
BFILE
データ型を使用すると、サイズが大きいバイナリ・ファイルの読取り専用のサポートが有効になります。この場合、ファイルを修正またはレプリケートすることはできません。Oracleでは、ファイル・データにアクセスするためのAPIが提供されています。ファイル・データにアクセスするために使用する主なインタフェースは、DBMS_LOB
パッケージとOracle Call Interface(OCI)です。
参照:
LOBの詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』および『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。また、「CREATE DIRECTORY」も参照してください。 |
BLOB
データ型は、構造化されていないバイナリ・ラージ・オブジェクトを格納するために使用します。BLOB
オブジェクトは、キャラクタ・セットのセマンティクスを持たないビットストリームとして考えることができます。BLOB
オブジェクトには、4GBから1を引いたバイト数にLOB記憶域のCHUNK
パラメータの値を掛けた値のサイズまでのバイナリ・データを格納できます。データベースの表領域が標準のブロック・サイズで、LOB列を作成したときにLOB記憶域のCHUNK
パラメータのデフォルト値を使用した場合には、前述の値は4GBから1を引いた値にデータベース・ブロック・サイズを掛けた値に等しくなります。
BLOB
オブジェクトでは、トランザクションが完全にサポートされます。SQL、DBMS_LOB
パッケージまたはOracle Call Interface(OCI)を介して行った変更は、すべてトランザクションに反映されます。BLOB
値の操作は、コミットおよびロールバックできます。ただし、1つのトランザクションのPL/SQLまたはOCI変数をBLOB
ロケータに保存し、そのロケータを別のトランザクションまたはセッションで使用することはできません。
CLOB
データ型は、シングルバイトおよびマルチバイト・キャラクタ・データを格納するために使用します。固定幅および可変幅のキャラクタ・セットがサポートされます。両方のキャラクタ・セットでデータベース・キャラクタ・セットを使用します。CLOB
オブジェクトには、4GBから1を引いたバイト数にLOB記憶域のCHUNK
パラメータの値を掛けた値のサイズまでの文字データを格納できます。データベースの表領域が標準のブロック・サイズで、LOB列を作成したときにLOB記憶域のCHUNK
パラメータのデフォルト値を使用した場合には、前述の値は4GBから1を引いた値にデータベース・ブロック・サイズを掛けた値に等しくなります。
CLOB
オブジェクトでは、トランザクションが完全にサポートされます。SQL、DBMS_LOB
パッケージまたはOracle Call Interface(OCI)を介して行った変更は、すべてトランザクションに反映されます。CLOB
値の操作は、コミットおよびロールバックできます。ただし、1つのトランザクションのPL/SQLまたはOCI変数をCLOB
ロケータに保存し、そのロケータを別のトランザクションまたはセッションで使用することはできません。
NCLOB
データ型は、Unicodeデータを格納するために使用します。固定幅および可変幅のキャラクタ・セットがサポートされます。両方のキャラクタ・セットで各国語キャラクタ・セットを使用します。NCLOB
オブジェクトには、4GBから1を引いたバイト数にLOB記憶域のCHUNK
パラメータの値を掛けた値のサイズまでの文字テキスト・データを格納できます。データベースの表領域が標準のブロック・サイズで、LOB列を作成したときにLOB記憶域のCHUNK
パラメータのデフォルト値を使用した場合には、前述の値は4GBから1を引いた値にデータベース・ブロック・サイズを掛けた値に等しくなります。
NCLOB
オブジェクトでは、トランザクションが完全にサポートされます。SQL、DBMS_LOB
パッケージまたはOCIを介して行った変更は、すべてトランザクションに反映されます。NCLOB
値の操作は、コミットおよびロールバックできます。ただし、1つのトランザクションのPL/SQLまたはOCI変数をNCLOB
ロケータに保存し、そのロケータを別のトランザクションまたはセッションで使用することはできません。
データベース内の各行にはアドレスがあります。次の項では、Oracle Databaseにおける行のアドレスの2つの書式について説明します。
Oracle Database固有のヒープ構成表内の行は、ROWIDという行のアドレスを持ちます。疑似列ROWID
を問い合せることによって、ROWIDの行のアドレスを調べることができます。この疑似列の値は、各行のアドレスを表す文字列で、文字列のデータ型はROWID
です。また、ROWID
データ型を持つ実際の列を含む表やクラスタを作成することもできます。Oracle Databaseでは、このような列の値が有効なROWIDであることは保証されません。ROWID
疑似列の詳細は、第3章「疑似列」を参照してください。
ROWIDには、次の情報が含まれています。
USER_OBJECTS
、DBA_OBJECTS
およびALL_OBJECTS
から取り出すことができます。同じセグメントを共有するオブジェクト(たとえば、同じクラスタ内のクラスタ化された表など)には、同じオブジェクト番号が付けられます。
ROWIDは、BASE 64の値で格納され、文字A〜Z、a〜z、0〜9、プラス記号(+)およびスラッシュ(/)を含めることができます。ROWIDは、直接は使用できません。ROWIDの内容を解析するには、提供されているパッケージDBMS_ROWID
を使用します。パッケージ・ファンクションを使用すると、前述の4つのROWIDの要素に関する情報を抽出して利用できます。
物理アドレスまたは永続アドレス以外のアドレス、またはOracle Databaseが生成したものではないアドレスがある行を持つ表もあります。たとえば、索引構成表の行のアドレスは索引リーフに格納され、移動できます。外部キー表のROWID(たとえば、ゲートウェイを介してアクセスされるDB2)は、標準のOracle ROWIDではありません。
Oracleでは、ユニバーサルROWID(UROWID)を使用して索引構成表および外部キー表のアドレスを格納します。索引構成表には、論理UROWIDがあり、外部キー表には外部キーUROWIDがあります。いずれのタイプのUROWIDも、(ヒープ構成表の物理ROWIDのように)ROWID
疑似列に格納されます。
Oracleは、表の主キーに基づいて論理ROWIDを作成します。論理ROWIDは、主キーが変更されないかぎり、変更されません。索引構成表のROWID
疑似列はUROWID
データ型です。この疑似列には、ヒープ構成表のROWID
疑似列と同様に(SELECT
... ROWID
文を使用して)アクセスできます。索引構成表のROWID
を格納する場合、表にUROWID
型の列を定義し、この列にROWID
疑似列の値を取り込みます。
表とクラスタを作成するSQL文では、ANSIデータ型、およびIBM社の製品SQL/DSとDB2のデータ型も使用できます。Oracleでは、Oracle Databaseのデータ型の名前と異なるANSIまたはIBMのデータ型の名前を認識します。データ型をOracleの同等のデータ型に変換して、Oracleのデータ型を列のデータ型の名前として記録し、次の表に示す変換に基づいて、Oracleのデータ型で列データを格納します。
ANSI SQLデータ型 | Oracleデータ型 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
次のSQL/DSとDB2のデータ型には、対応するOracleデータ型がありません。次のデータ型を持つ列は定義しないでください。
データ型がTIME
であるデータは、Oracleの日時データとしても表現できます。
SQL/DSとDB2データ型 | Oracleデータ型 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
ユーザー定義のデータ型は、Oracle組込みデータ型とその他のユーザー定義のデータ型を、アプリケーション内のデータの構造と動作をモデル化するオブジェクト型の構築ブロックとして使用します。次の項で、ユーザー定義型の様々なカテゴリを説明します。
参照:
|
オブジェクト型とは、実社会エンティティ(たとえば、発注書など)を抽象化し、アプリケーション・プログラムで処理できるようにしたものです。1つのオブジェクト型は、次の3種類のコンポーネントを持つスキーマ・オブジェクトです。
オブジェクト識別子(キーワードOID
で表される)を使用することによって、オブジェクトを一意に識別し、他のオブジェクトまたはリレーショナル表からそのオブジェクトを参照できます。REF
と呼ばれるデータ型のカテゴリが、そのような参照を表します。REF
データ型は、オブジェクト識別子のコンテナです。REF
値は、オブジェクトへのポインタとなります。
REF
値が、存在しないオブジェクトを指している場合、そのREF
はDANGLING(参照先がない)状態であるといいます。DANGLING状態のREF
は、NULLであるREF
と異なります。REF
がDANGLING状態であるかどうかを確認するには、条件IS
[NOT
] DANGLING
を使用します。たとえば、列型がcustomer_typ
(属性cust_email
を持つ)を指しているREF
であるcustomer_ref
列があるとします。このcustomer_ref列を含むオブジェクト・ビューoc_orders
(サンプル・スキーマoe
内)は、次のように指定します。
SELECT o.customer_ref.cust_email FROM oc_orders o WHERE o.customer_ref IS NOT DANGLING;
配列とは、順序付けられたデータ要素の集合です。ある特定の配列のすべての要素は、同じデータ型です。各要素には索引があります。索引は、各要素の配列内での位置に対応する番号です。
配列内の要素数は、その配列のサイズを表します。Oracleの配列は可変サイズであるため、VARRAYと呼ばれます。VARRAYを宣言する場合は、最大サイズを指定する必要があります。
VARRAY宣言時に領域は割り当てられません。VARRAYでは、次のような型を定義します。
通常、Oracleは、1つの配列オブジェクトをインライン形式でその行の他のデータと同じ表領域に、またはアウトライン形式でLOBに格納します。この形式は配列オブジェクトのサイズによって決まります。ただし、VARRAYに個別の記憶特性を指定する場合、Oracleはこれをサイズに関係なくアウトライン形式で格納します。VARRAYの格納方法の詳細は、「CREATE TABLE」の「varray_col_properties」を参照してください。
ネストした表は、順序付けられていない要素の集合を表現します。その要素は、組込み型またはユーザー定義型です。ネストした表は、単一列の表として表示できます。ネストした表がオブジェクト型の場合、オブジェクト型のそれぞれの属性を表す複数列の表としても表示できます。
ネストした表の定義では、領域は割り当てられません。ネストした表では、次のものを宣言するための型を定義します。
ネストした表が、リレーショナル表内の列型として使用される場合、またはオブジェクト表の基礎となるオブジェクト型の属性として使用される場合、Oracleは、ネストした表のすべてのデータを単一表に格納し、その単一表を、ネストした表を囲むリレーショナル表またはオブジェクト表に対応付けます。
Oracleは、組込み型またはANSIがサポートする型が不十分な場合に、新しい型を定義するためのSQLに基づくインタフェースを提供します。これらの型の動作は、C/C++、JavaまたはPL/SQLで実装されます。Oracle Databaseは、入出力、異機種間でのクライアント側の新しいデータ型へのアクセス、およびアプリケーションとデータベース間のデータ転送のための最適化で必要な下位レベルのインフラストラクチャ・サービスを自動的に提供します。
これらのインタフェースは、ユーザー定義(またはオブジェクト)型の作成に使用できます。また、Oracleが有効なデータ型を作成するときに使用します。このようなデータ型のいくつかはサーバーで提供され、横方向の幅広いアプリケーション領域(任意型など)および縦方向の固有アプリケーション領域(空間型など)の両方に役立ちます。
Oracleが提供する型については、次の項で説明します。また、それらの型の実装および使用に関するドキュメントの参照先も示します。
任意型は、実際の型が不明なプロシージャ・パラメータおよび表の列の柔軟性が高いモデリングを提供します。これらのデータ型によって、型の記述、データ・インスタンスおよびその他のSQL型の一連のデータ・インスタンスを動的にカプセル化し、アクセスできます。これらの型を構成およびアクセスするには、OCIおよびPL/SQLインタフェースを使用します。
この型には、任意の名前のあるSQL型または名前のない一時型の型の記述を含めることができます。
この型には、指定した型のインスタンスをデータおよび型の記述とともに含めることができます。ANYDATA
は、表の列のデータ型として使用できます。また、このデータ型によって、単一列に異機種間の値を格納できます。ユーザー定義型と同様に、SQL組込み型の値も格納できます。
この型には、指定した型の記述およびその型の一連のデータ・インスタンスを含めることができます。ANYDATASET
は、柔軟性が必要なプロシージャ・パラメータのデータ型として使用できます。ユーザー定義型と同様に、SQL組込み型のデータ・インスタンスの値も格納できます。
eXtensible Markup Language(XML)は、World Wide Web Consortium(W3C)によって開発された、構造化されたデータおよび構造化されていないデータをWebで表示するための標準書式です。Universal Resource Identifiers(URI)は、WebページなどのWeb上のリソースを識別します。Oracleでは、データベース自体に格納されるデータにアクセスするためにDBUriRef
型と呼ばれるURIのクラスと同様に、XMLおよびURIデータを処理するための型が用意されています。また、データベースから外部URIおよび内部URIの両方に格納およびアクセスする型セットを利用できます。
Oracleが提供するこの型は、データベースでのXMLデータの格納および問合せに使用します。XMLType
は、XPath式を使用したXMLデータへのアクセス、抽出および問合せに使用するメンバー・ファンクションを持ちます。XPathは、XML文書をトラバースするためにW3Cによって開発された別の規格です。OracleのXMLType
ファンクションは、W3Cの多数のXPath式をサポートします。また、Oracleは、既存のリレーショナルまたはオブジェクト・リレーショナル・データからXMLType
値を作成するためのSQLファンクションおよびPL/SQLパッケージのセットを提供します。
XMLType
はシステム定義型であるため、ファンクションの引数として、あるいは表またはビューの列のデータ型として使用できます。また、XMLType
の表およびビューも作成できます。表にXMLType
列を作成する際は、XMLデータをCLOB
列に(内部的にはCLOB
として格納されるバイナリXMLとして)格納するか、またはオブジェクトと関連付けて格納するかを選択できます。
また、スキーマを登録し(DBMS_XMLSCHEMA
パッケージを使用)、登録したスキーマに適合する表または列を作成できます。この場合、XMLデータは、デフォルトでは基礎となるオブジェクト・リレーショナル列に格納されますが、スキーマ・ベースのデータであっても、CLOB
列またはバイナリXML列に格納するように指定できます。
XMLType
列の問合せおよびDMLは、格納メカニズムとは関係なく、同様に動作します。
Oracleは、継承階層で関連するURI型のファミリ(URIType
、DBUriType
、XDBUriType
およびHTTPUriType
)を提供します。URIType
はオブジェクト型であり、その他はURIType
のサブタイプです。URIType
はスーパータイプであるため、この型の列を作成し、DBUriType
またはHTTPUriType
型のインスタンスをこの列に格納できます。
HTTPUriType
を使用すると、外部のWebページまたはファイルのURLを格納できます。Oracleは、Hypertext Transfer Protocol(HTTP)を使用して、これらのファイルにアクセスします。
XDBUriType
を使用すると、表の任意のURIType
列に埋込み可能なURIとして、ドキュメントをXMLデータベース階層に展開できます。XDBUriType
は、URLで構成されています。URLは、参照先のXML文書の階層名と、XPath構文を表すオプションのフラグメントで構成されています。フラグメントとURL部分は、シャープ記号(#)で区切ります。次に、XDBUriType
の例を示します。
/home/oe/doc1.xml /home/oe/doc1.xml#/orders/order_item
DBUriType
を使用すると、データベース内のデータを参照するDBUriRef
値を格納できます。この場合、データベースの内部または外部に格納されたデータを参照し、常にデータにアクセスできます。
DBUriRef
値は、データベース内のデータを参照するために、XPathのような表現を使用します。データベースをXMLツリーに想定すると、表、行および列がXML文書の要素です。たとえば、サンプルの人材のユーザーhr
は次のようにXMLツリーで表します。
<HR> <EMPLOYEES> <ROW> <EMPLOYEE_ID>205</EMPLOYEE_ID> <LAST_NAME>Higgins</LAST_NAME> <SALARY>12000</SALARY> .. <!-- other columns --> </ROW> ... <!-- other rows --> </EMPLOYEES> <!-- other tables..--> </HR> <!-- other user schemas on which you have some privilege on..-->
DBUriRef
は、この仮想XML文書のXPath式です。したがって、従業員番号205の従業員のSALARY
値をEMPLOYEES
表で参照するには、DBUriRef
を次のように記述します。
/HR/EMPLOYEES/ROW[EMPLOYEE_ID=205]/SALARY
このモデルを使用すると、CLOB
列またはその他の列に格納されたデータを参照し、それらのデータを外部のURLとして外部の世界へ公開できます。
Oracleは、URIType
の様々なサブタイプのインスタンスを作成し、戻すことができるURIFactory
パッケージも提供します。このパッケージは、URL文字列を分析し、URLの種類(HTTP、DBUri
など)を識別し、サブタイプのインスタンスを作成します。DBUri
インスタンスを作成する場合は、URLの先頭に接頭辞/oradb
を付ける必要があります。たとえば、URIFactory.getURI('/oradb/HR/EMPLOYEES')
によってDBUriType
インスタンスが作成され、URIFactory.getUri('/sys/schema')
によってXDBUriType
インスタンスが作成されます。
Oracle Spatialは、位置情報アプリケーション、地理情報システム(GIS)・アプリケーションおよびジオイメージング・アプリケーションのユーザーが、空間データ管理をより簡単かつ自然に行えるように設計されています。一度空間データをOracle Databaseに格納すると、そのデータの操作や取得を簡単に行うことができ、データベースに格納された他のすべてのデータと関連付けることもできます。次のデータ型は、Oracle Spatialをインストールしている場合にのみ使用できます。
空間オブジェクトのジオメトリの記述は、ユーザー定義の表の単一行およびオブジェクト型SDO_GEOMETRY
の単一列に格納されます。SDO_GEOMETRY
型の列を含むすべての表は、表に対して一意の主キーを定義する別の列を持つ必要があります。このような表は、ジオメトリ表と呼ばれる場合があります。
SDO_GEOMETRY
オブジェクト型の定義は、次のとおりです。
CREATE TYPE SDO_GEOMETRY AS OBJECT ( sgo_gtype NUMBER, sdo_srid NUMBER, sdo_point SDO_POINT_TYPE, sdo_elem_info SDO_ELEM_INFO_ARRAY, sdo_ordinates SDO_ORDINATE_ARRAY) /
この型はトポロジ・ジオメトリを記述します。この記述は、ユーザー定義の表の単一行およびオブジェクト型SDO_GEOMETRY
の単一列に格納されます。
SDO_TOPO_GEOMETRY
オブジェクト型の定義は、次のとおりです。
CREATE TYPE SDO_TOPO_GEOMETRY AS OBJECT ( tg_type NUMBER, tg_id NUMBER, tg_layer_id NUMBER, topology_id NUMBER) /
GeoRasterオブジェクト・リレーショナル・モデルでは、ラスター・グリッドまたはイメージ・オブジェクトは、ユーザー定義の表の単一行およびオブジェクト型SDO_GEORASTER
の単一列に格納されます。このような表は、GeoRaster表と呼ばれます。
SDO_GEORASTER
オブジェクト型の定義は、次のとおりです。
CREATE TYPE SDO_GEORASTER AS OBJECT ( rasterType NUMBER, spatialExtent SDO_GEOMETRY, rasterDataTable VARCHAR2(32), rasterID NUMBER, metadata XMLType) /
Oracle Multimediaは、マルチメディア・データを記述するために、JavaまたはC++クラスに類似したオブジェクト型を使用します。これらのオブジェクト型のインスタンスは、メタデータおよびメディア・データを含む属性とメソッドで構成されます。Multimediaのデータ型は、ORDSYS
スキーマで作成されます。パブリック・シノニムがすべてのデータ型に対して存在するため、スキーマ名を指定せずにアクセスできます。
ORDAudio
オブジェクト型は、オーディオ・データの格納および管理をサポートします。
ORDImage
オブジェクト型は、イメージ・データの格納および管理をサポートします。
ORDVideo
オブジェクト型は、ビデオ・データの格納および管理をサポートします。
ORDDoc
オブジェクト型は、オーディオ、イメージ、ビデオ・データなどすべての種類のメディア・データの格納および管理をサポートします。この型は、すべてのメディアを単一列に格納する場合に使用します。
ORDDicom
オブジェクト型は、医用画像の規格として広く認知されている形式であるDigital Imaging and Communications in Medicine (DICOM)の格納および管理をサポートします。
次のデータ型は、ISO-IEC 13249-5 Still Image規格(一般にSQL/MM StillImageと呼ばれる)に準拠しています。
SI_StillImage
オブジェクト型は、高さ、幅、フォーマットなどの固有のイメージ特性を持つデジタル・イメージを表します。
SI_Color
オブジェクト型は、色の値をカプセル化します。
SI_AverageColor
オブジェクト型は、イメージの平均の色によってそのイメージを特徴付けます。
SI_ColorHistogram
オブジェクト型は、RAWイメージのサンプルによって表示される色の相対頻度によって、イメージを特徴付けます。
イメージをn
×m
個の四角形に分割すると考えた場合、SI_PositionalColor
オブジェクト型は、その四角形の最も重要なn
×m
個の色によってイメージを特徴付けます。
SI_Texture
オブジェクト型は、繰り返し出現している項目のサイズ(粗さ)、輝度の変化(コントラスト)および主な方向(方向性)によってイメージを特徴付けます。
SI_FeatureList
オブジェクト型は、前述したオブジェクト型(SI_AverageColor
、SI_ColorHistogram
、SI_PositionalColor
およびSI_Texture
)が表すイメージの特徴のうち最大4つの特徴を含むリストです。各特徴は、重み付けされます。
ORDImageSignature
は非推奨になったため、コードに使用されることはありません。現存するこのオブジェクト型は、引き続き従来どおり機能します。
Oracle Expression Filterを使用すると、アプリケーション開発者は、ユーザーの目的のデータを表す条件式を管理および評価できます。Expression Filterには、次のデータ型が含まれます。
Expression Filterは、Expression
と呼ばれる仮想データ型を使用して、条件式をデータベース表のデータとして管理および評価します。Expression Filterでは、VARCHAR2
列に属性セットを割り当てることで、この列からExpression
データ型の列を作成します。この割当てによって、列に格納された式の妥当性を確認するデータ制約が有効になります。
Expression
データ型でEVALUATE
演算子を使用して条件を定義すると、列に格納された式をデータに対して評価できます。Enterprise Editionを使用している場合は、Expression
データ型の列にExpression Filter索引を定義して、EVALUATE
演算子によって問合せを処理することもできます。
ここでは、Oracle Databaseが各データ型の値を比較する方法について説明します。
大きい値は小さい値よりも大きいとみなされます。すべての負の数は、0(ゼロ)およびすべての正の数より小さいとみなされます。したがって、-1は100より小さく、-100は-1より小さいとみなされます。
浮動小数点値NaN
(非数値)は、その他の数値よりも大きく、NaNとは等しいとみなされます。
後の日付は前の日付よりも大きいとみなされます。たとえば、29-MAR-2005(2005年3月29日)に相当する日付は05-JAN-2006(2006年1月5日)に相当する日付よりも小さく、05-JAN-2006 1:35pm(2006年1月5日午後1時35分)に相当する日付は05-JAN-2005 10:09am(2005年1月5日午前10時9分)に相当する日付よりも大きいとみなされます。
文字値は、2つのメジャーに基づいて比較されます。
次の項で、2つのメジャーについて説明します。
デフォルトのバイナリ比較では、Oracleは、データベース・キャラクタ・セット内の文字の数値コードを連結した値に従って文字列を比較します。第1の文字の数値が第2の文字の数値よりも大きい場合、第1の文字は第2の文字よりも大きいとみなされます。Oracleは、空白はどの文字よりも小さいとみなします。これは、ほぼすべてのキャラクタ・セットでいえることです。
次に、一般的なキャラクタ・セットを示します。
数値コードのバイナリ順序と、比較する文字の言語順序が一致していない場合は、言語比較が有効です。NLS_SORT
パラメータにBINARY
以外の設定があり、NLS_COMP
パラメータがLINGUISTIC
に設定されている場合は言語比較が使用されます。言語ソートでは、すべてのSQLのソートおよび比較がNLS_SORT
によって指定された言語規則に基づいて行われます。
空白埋め比較セマンティクスでは、2つの値の長さが異なる場合、Oracleはまず短い方の値の最後に空白を追加して、2つの値が同じ長さになるようにします。次に、その2つの値を、最初に異なる文字まで1文字ずつ比較します。最初に異なる文字の位置で、大きい方の文字を持つ値の方が大きいとみなされます。2つの値に異なる文字がない場合、その2つの値は等しいとみなされます。この規則では、2つの値の後続空白数のみが異なる場合、その2つの値は等しいとみなされます。Oracleでは、比較する両方の値が、CHAR
データ型、NCHAR
データ型、テキスト・リテラルのいずれかの式の場合、またはUSER
ファンクションの戻り値の場合のみ空白埋め比較セマンティクスを使用します。
非空白埋め比較セマンティクスでは、Oracleは、2つの値を、最初に異なる文字まで1文字ずつ比較します。最初に異なる文字の位置で、大きい方の文字を持つ値の方が大きいとみなされます。長さが異なる2つの値を短い方の値の最後まで比較して、すべて同じ文字だった場合、長い方の値が大きいとみなされます。同じ長さの2つの値に異なる文字がない場合、その2つの値は等しいとみなされます。Oracleでは、比較する片方または両方の値がVARCHAR2
データ型またはNVARCHAR2
データ型の場合、非空白埋め比較セマンティクスを使用します。
これらの異なる比較セマンティクスを使用して2つの文字値を比較した場合、その結果が異なることもあります。次の表に、それぞれの比較セマンティクスを使用して5組の文字を比較した結果を示します。通常、空白埋め比較と非空白埋め比較の結果は同じです。表に示されている最後の比較では、空白埋め比較と非空白埋め比較の違いが明確になっています。
空白埋め比較 | 非空白埋め比較 |
---|---|
|
|
|
|
|
|
|
|
|
|
ASCIIとEBCDICのキャラクタ・セットの一部を表2-8と表2-9に示します。大文字と小文字は同じではありません。キャラクタ・セットの照合順番は、特定の言語の言語順序と一致しない場合があります。
オブジェクト値は、MAP
とORDER
の2つの比較ファンクションのいずれかを使用して比較されます。どちらのファンクションでもオブジェクト型インスタンスは比較されますが、両者は別のものです。これらのファンクションは、他のオブジェクト型と比較するオブジェクト型の一部として指定される必要があります。
ネストした表の比較の詳細は、「比較条件」を参照してください。
Oracleでは、データ型の優先順位によって、暗黙的にデータ型を変換するかどうかを判断します(次の項を参照)。Oracleデータ型の優先順位は、次のとおりです。
一般に、式には異なるデータ型の値を含めることができません。たとえば、式では10に5を掛けた値に'JAMES'を加えることはできません。ただし、Oracleでは値をあるデータ型から別のデータ型へ変換する場合の、暗黙的な変換と明示的な変換をサポートしています。
次の理由から、暗黙的な変換または自動変換ではなく、明示的な変換を指定することをお薦めします。
VARCHAR2
型へ値を暗黙的に変換すると、NLS_DATE_FORMAT
パラメータに指定されている値によっては、予期しない年が戻される場合があります。
あるデータ型から別のデータ型への変換が意味を持つ場合、Oracle Databaseは値を自動的に変換します。文字データ型への暗黙的な変換はこれらのルールに従います。
表2-10に、Oracleの暗黙的な変換のマトリックスについて示します。この表は、変換の方向または変換されるコンテキストにかかわらず、すべての可能な変換を示します。詳細は、表の後の説明を参照してください。
次に示す規則に従って、Oracle Databaseは、暗黙的なデータ型変換を実行する方向を確立します。
INSERT
およびUPDATE
操作中に、Oracleは変更する列のデータ型に値を変換します。
SELECT
FROM
操作中に、Oracleは列からターゲット変数の型にデータを変換します。
NUMBER
の値と浮動小数点数の値の間では、変換が正確に行われない場合があります。これは、文字型およびNUMBER
では10進精度で数値が示されるのに対し、浮動小数点数では2進精度が使用されているためです。
CLOB
値をVARCHAR2
などの文字データ型に変換する場合、またはBLOB
をRAW
データに変換する場合、変換するデータがターゲットのデータ型より大きいと、データベースはエラーを戻します。
BINARY_FLOAT
からBINARY_DOUBLE
への変換は正確に行われます。
BINARY_DOUBLE
の値がBINARY_FLOAT
でサポートされている精度のビット数よりも多いビット数を使用している場合、BINARY_DOUBLE
からBINARY_FLOAT
への変換は正確に行われません。
DATE
の値と文字の値を比較する場合、Oracleは文字データをDATE
に変換します。
CHAR
またはNCHAR
に変換します。
CHAR
/VARCHAR2
とNCHAR
/NVARCHAR2
の演算処理では、OracleはNUMBER
に変換します。
CHAR
とVARCHAR2
、NCHAR
とNVARCHAR2
の比較では、異なるキャラクタ・セットが必要な場合があります。このような場合のデフォルトの変換の方向は、データベース・キャラクタ・セットから各国語キャラクタ・セットです。表2-11に、異なるキャラクタ・タイプ間での暗黙的な変換の方向を示します。
CLOB
をパラメータとして指定できます。また、OracleはCLOB
と文字型間で暗黙的な変換を実行します。このため、CLOB
を使用できないファンクションは、暗黙的な変換を使用してCLOB
を受け入れます。このような場合、Oracleはファンクションが起動される前にCLOB
をCHAR
またはVARCHAR2
に変換します。CLOB
が4000バイトより大きい場合、Oracleは最初の4000バイトのみをCHAR
に変換します。CHARへ | VARCHAR2へ | NCHARへ | NVARCHAR2へ | |
---|---|---|---|---|
CHARから |
-- |
|
|
|
VARCHAR2から |
|
-- |
|
|
NCHARから |
|
|
-- |
|
NVARCHAR2から |
|
|
|
-- |
コレクションなどのユーザー定義型は暗黙的に変換できないため、CAST
... MULTISET
を使用して明示的に変換する必要があります。
テキスト・リテラル'10'はCHAR
データ型です。次の文のように数式で使用すると暗黙的にNUMBER
データ型に変換されます。
SELECT salary + '10' FROM employees;
条件で文字値とNUMBER
型の値を比較する場合、NUMBER
型の値は文字値に変換されず、文字値が暗黙的にNUMBER
型の値に変換されます。次の文では、'200'が暗黙的に200に変換されます。
SELECT last_name FROM employees WHERE employee_id = '200';
次の文では、Oracleがデフォルトの日付書式'DD-MON-YY
'を使用して、'03-MAR-97
'をDATE
値に暗黙的に変換します。
SELECT last_name FROM employees WHERE hire_date = '03-MAR-97';
SQL変換ファンクションを使用すると、データ型の変換を明示的に指定できます。表2-12に、値をあるデータ型から別のデータ型に明示的に変換するSQLファンクションを示します。
Oracleが暗黙的なデータ型変換を行うことができる場合には、LONG
およびLONG
RAW
の値を指定できません。たとえば、ファンクションや演算子を含む式では、LONG
とLONG
RAW
の値を使用できません。LONG
データ型およびLONG
RAW
データ型の制限については、「LONGデータ型」を参照してください。
暗黙的な変換、または書式モデルを指定しない明示的な変換のいずれかによって日時値がテキストに変換される場合、書式モデルはグローバリゼーション・セッション・パラメータの1つによって定義されます。ソースのデータ型に応じて、パラメータ名はNLS_DATE_FORMAT
、NLS_TIMESTAMP_FORMAT
またはNLS_TIMESTAMP_TZ_FORMAT
です。これらのパラメータの値は、クライアント環境で、またはALTER
SESSION
文で指定できます。
書式モデルがセッション・パラメータに依存している場合、明示的な書式モデルが指定されていない変換が動的SQL文のテキストに連結される日時値に適用されると、データベースのセキュリティに悪影響を及ぼす可能性があります。動的SQL文は、実行のためにデータベースに渡される前にそのテキストがフラグメントから連結される文です。動的SQLは、組込みPL/SQLパッケージDBMS_SQL
またはPL/SQL文EXECUTE
IMMEDIATE
に関連付けられる場合が多いですが、動的に構成されたSQLテキストを引数として渡すことができる場所はこれらのみではありません。次に例を示します。
EXECUTE IMMEDIATE 'SELECT name FROM employee WHERE hiredate > ''' || start_date || '''';
start_date
のデータ型はDATE
です。
前述の例では、start_date
の値はセッション・パラメータNLS_DATE_FORMAT
で指定された書式モデルを使用してテキストに変換されます。結果は、連結されてSQLテキストになります。日時書式モデルは、単純に二重引用符で囲んだリテラル・テキストで構成できます。したがって、セッションのグローバリゼーション・パラメータを明示的に設定できるすべてのユーザーが、前述の変換で生成されるテキストを決定できます。SQL文がPL/SQLプロシージャによって実行される場合、そのプロシージャはセッション・パラメータによるSQLインジェクションに対して脆弱になります。セッション自体より強い権限である定義者の権限でプロシージャが実行されると、ユーザーは機密データに不正にアクセスすることができます。
数値の暗黙的および明示的な変換でも、変換結果がセッション・パラメータNLS_NUMERIC_CHARACTERS
に依存する場合があるため、類似した問題が発生する可能性があります。このパラメータは、小数点区切り文字および桁区切り文字を定義します。小数点区切りを一重引用符または二重引用符と定義すると、SQLインジェクションが発生する可能性があります。
参照:
|
リテラルと定数値という用語の意味は同じで、固定データ値のことです。たとえば、'JACK'、'BLUE ISLAND'および'101'はすべて文字リテラルです。文字リテラルは、一重引用符で囲みます。一重引用符を付けることで、Oracleは文字リテラルとスキーマ・オブジェクト名を区別します。
この項では、次の内容を説明します。
多くのSQL文とファンクションでは、文字リテラルと数値リテラルを指定する必要があります。式と条件の一部として、リテラルを指定できます。文字リテラルは'text
'の表記法を、各国文字リテラルはN'text'
の表記法を、数値リテラルはリテラルのコンテキストに応じてinteger
またはnumber
の表記法を使用して指定できます。これらの表記法の構文については、次の項で説明します。
Datetime(日時)またはInterval(期間)のデータ型をリテラルとして指定する場合は、データ型に含まれているオプションの精度を考慮する必要があります。Datetime(日時)およびInterval(期間)のデータ型をリテラルとして指定する場合の例は、「データ型」の関連する項を参照してください。
このマニュアルの他の箇所で、式、条件、SQLファンクションおよびSQL文の各構文に示されている'string'
に値を指定するときには、必ずこのテキスト・リテラルの表記法を使用してください。このマニュアルでは、テキスト・リテラル、文字リテラルおよび文字列は同じ用語として使用しています。テキスト、文字、文字列リテラルは必ず一重引用符で囲まれています。構文にchar
が使用されている場合、テキスト・リテラルを指定するか、または文字データに変換する他の式(たとえば、hr.employees
表のlast_name
列)を指定します。構文にchar
がある場合、一重引用符で囲む必要はありません。
テキスト・リテラルまたは文字列の構文は次のとおりです。
ここで、N
またはn
は、各国語キャラクタ・セット(NCHAR
またはNVARCHAR2
データ)を使用してリテラルを指定します。デフォルトでは、この表記法を使用して入力したテキストは、サーバーで使用するときにデータベースのキャラクタ・セットによって各国語キャラクタ・セットに変換されます。テキスト・リテラルをデータベースのキャラクタ・セットに変換しているときにデータの消失を避けるためには、環境変数ORA_NCHAR_LITERAL_REPLACE
にTRUE
を設定してください。このように設定することで、n'
を透過的に内部で置き換え、SQLの処理中にテキスト・リテラルを保持します。
構文の上の方のブランチでは、次のようになります。
c
は、データベース・キャラクタ・セットの任意の要素です。リテラル内の一重引用符(')の前には、エスケープ文字を付ける必要があります。リテラル内で一重引用符を表すには、一重引用符を2つ使用します。
構文の下の方のブランチでは、次のようになります。
Q
またはq
は、代替引用メカニズムが使用されることを示します。このメカニズムを使用すると、様々なデリミタをテキスト文字列に使用できます。
'
'
は、開始のquote_delimiter
の前と、終了のquote_delimiter
の後に付ける2つの一重引用符です。
c
は、データベース・キャラクタ・セットの任意の要素です。c
で構成されるテキスト・リテラル内に引用符(")を含めることができます。また、一重引用符が直後に付かないquote_delimiter
も含めることができます。
quote_delimiter
は、空白、タブおよび改行文字を除く、任意のシングルバイト文字またはマルチバイト文字です。quote_delimiter
には一重引用符も使用できます。ただし、quote_delimiter
がテキスト・リテラル自体に使用されている場合は、一重引用符を直後に付けないようにしてください。開始のquote_delimiter
が[
、{
、<
または(
のいずれかである場合、終了のquote_delimiter
も対応する]
、}
、>
または)
である必要があります。それ以外の場合は常に、開始および終了のquote_delimiter
は同じ文字である必要があります。
テキスト・リテラルは、次のようにCHAR
データ型とVARCHAR2
データ型の両方のプロパティを持ちます。
有効なテキスト・リテラルの例を次に示します。
'Hello' 'ORACLE.dbs' 'Jackie''s raincoat' '09-MAR-98' N'nchar literal'
代替引用メカニズムを使用した場合の、有効なテキスト・リテラルの例を次に示します。
q'!name LIKE '%DBMS_%%'!' q'<'So,' she said, 'It's finished.'>' q'{SELECT * FROM employees WHERE last_name = 'Smith';}' nq'Ô ü1234 Ô' q'"name like '['"'
固定小数点数および浮動小数点数を指定するには、数値リテラルの表記法を使用します。
このマニュアルの他の箇所で、式、条件、SQLファンクションおよびSQL文に示されているinteger
(整数)に値を指定するときには、必ずこの表記法を使用してください。
integer
(整数)の構文は次のとおりです。
digit
は、0、1、2、3、4、5、6、7、8、9のいずれかです。
整数は最大38桁の精度を記憶できます。
有効なinteger(整数)の例を次に示します。
7 +255
このマニュアルの他の箇所で、式、条件、SQLファンクションおよびSQL文に示されているnumber
またはn
(数)に値を指定するときには、必ずこれらの表記法を使用してください。
number
(数)の構文は次のとおりです。
それぞれの意味は、次のとおりです。
digit
は、0、1、2、3、4、5、6、7、8、9のいずれかです。
BINARY_FLOAT
型の32ビットの2進浮動小数点数であることを示します。
BINARY_DOUBLE
型の64ビットの2進浮動小数点数であることを示します。f(F)およびd(D)を省略すると、数はNUMBER
型になります。
接尾辞f(F)およびd(D)は、浮動小数点数リテラルでのみサポートされます。文字列ではNUMBER
に変換されるため、サポートされません。たとえば、OracleがNUMBER
を想定している場合に、文字列'9'
を使用すると、文字列は数字の9に変換されます。ただし、文字列'9f'
を使用すると、変換は行われず、エラーが戻されます。
NUMBER
型の数値は、最大38桁の精度を記憶できます。NUMBER
、BINARY_FLOAT
またはBINARY_DOUBLE
で提供される精度以上の精度がリテラルに必要な場合、値は切り捨てられます。リテラルの範囲がNUMBER
、BINARY_FLOAT
またはBINARY_DOUBLE
でサポートされる範囲を超える場合、エラーが発生します。
初期化パラメータNLS_NUMERIC_CHARACTERS
を使用してピリオド(.)以外の小数点文字を設定している場合は、'text'
の表記法で数値リテラルを指定する必要があります。この場合、Oracleは自動的にテキスト・リテラルを数値に変換します。
たとえば、NLS_NUMERIC_CHARACTERS
パラメータでカンマを小数点文字に設定している場合、数値5.123は次のように指定します。
'5,123'
有効なNUMBER
リテラルの例を次に示します。
25 +6.34 0.5 25e-03 -1
有効な浮動小数点数リテラルの例を次に示します。
25f +6.34F 0.5d -1D
値を数値リテラルとして表現できない場合は、次の浮動小数点リテラルを使用することもできます。
Oracle Databaseは、DATE
、TIMESTAMP
、TIMESTAMP WITH TIME ZONE
およびTIMESTAMP WITH LOCAL TIME ZONE
の4つの日時データ型をサポートしています。
DATE
値を文字列リテラルに指定するか、文字値や数値をTO_DATE
ファンクションによって日付値に変換できます。Oracle Databaseが文字列リテラルのかわりにTO_DATE
式を受け入れるのは、DATE
リテラルの場合だけです。
DATE
値をリテラルに指定する場合は、グレゴリオ暦を使用する必要があります。次の例に示すように、ANSIのリテラルを指定できます。
DATE '1998-12-25'
ANSIの日付リテラルには、時刻部分を含めず、書式'YYYY-MM-DD
'で指定する必要があります。また、次のように、Oracleの日付値を指定できます。
TO_DATE('98-DEC-25 17:30','YY-MON-DD HH24:MI')
OracleのDATE
値のデフォルトの日付書式は、初期化パラメータNLS_DATE_FORMAT
で指定します。この例は、日付としての2桁の数、月の名前の省略形、年の下2桁および24時間表記の時刻を含む日付書式です。
デフォルト日付書式の文字値が日付式で使用されると、Oracleは自動的にそれらを日付値に変換します。
日付値を指定する場合に時刻コンポーネントを指定しないと、デフォルト時刻の真夜中(24時間表記では00:00:00、12時間表記では12:00:00)が採用されます。日付値を指定する場合に日付を指定しないと、デフォルト日付である現在の月の最初の日が採用されます。
OracleのDATE
列には、常に、日付フィールドと時刻フィールドが含まれます。したがって、DATE
列を問い合せる場合は、問合せで時刻フィールドを指定するか、またはDATE
列の時刻フィールドが真夜中に設定されていることを確認する必要があります。そうでない場合、Oracleは、正しい結果を戻さない場合があります。時刻フィールドを真夜中に設定するには、TRUNC
日付ファンクションを使用します。また、問合せに、等価性や非等価性の条件のかわりに大/小条件を含めることもできます。
次の例では、数値列row_num
およびDATE
列datecol
を持つ表my_table
があると想定します。
INSERT INTO my_table VALUES (1, SYSDATE); INSERT INTO my_table VALUES (2, TRUNC(SYSDATE)); SELECT * FROM my_table; ROW_NUM DATECOL ---------- --------- 1 03-OCT-02 2 03-OCT-02 SELECT * FROM my_table WHERE datecol = TO_DATE('03-OCT-02','DD-MON-YY'); ROW_NUM DATECOL ---------- --------- 2 03-OCT-02 SELECT * FROM my_table WHERE datecol > TO_DATE('02-OCT-02', 'DD-MON-YY'); ROW_NUM DATECOL ---------- --------- 1 03-OCT-02 2 03-OCT-02
DATE
列の時刻フィールドが真夜中に設定されている場合は、前述の例に示すように、DATE
列に対して問い合せるか、DATE
リテラルを使用して問い合せることができます。
SELECT * FROM my_table WHERE datecol = DATE '2002-10-03';
ただし、DATE
列が真夜中以外の値を含む場合、正しい結果を得るためには、問合せで時刻フィールドを排除する必要があります。次に例を示します。
SELECT * FROM my_table WHERE TRUNC(datecol) = DATE '2002-10-03';
Oracleは、問合せの各行にTRUNC
ファンクションを適用します。これによって、データの時刻フィールドが真夜中である場合、パフォーマンスが向上します。時刻フィールドを真夜中に設定するには、挿入および更新時に次のいずれかの操作を行います。
TO_DATE
ファンクションを使用して、時刻フィールドをマスクします。
INSERT INTO my_table VALUES (3, TO_DATE('3-OCT-2002','DD-MON-YYYY'));
DATE
リテラルを使用します。
INSERT INTO my_table VALUES (4, '03-OCT-02');
TRUNC
ファンクションを使用します。
INSERT INTO my_table VALUES (5, TRUNC(SYSDATE));
日付ファンクションSYSDATE
は、現在のシステムの日付および時刻を戻します。CURRENT_DATE
ファンクションは、現在のセッションの日付を戻します。SYSDATE
、TO_*
日時ファンクションおよびデフォルト日付書式の詳細は、「日時ファンクション」を参照してください。
TIMESTAMP
データ型は、年、月、日、時、分、秒、および秒の小数部の値を格納します。TIMESTAMP
をリテラルに指定する場合、fractional_seconds_precision
値には最大9桁を指定できます。次に例を示します。
TIMESTAMP '1997-01-31 09:26:50.124'
TIMESTAMP WITH TIME ZONE
データ型は、タイムゾーン地域名またはタイムゾーン・オフセットを含むTIMESTAMP
の変形です。TIMESTAMP WITH TIME ZONE
をリテラルに指定する場合、fractional_seconds_precision
値には最大9桁を指定できます。次に例を示します。
TIMESTAMP '1997-01-31 09:26:56.66 +02:00'
2つのTIMESTAMP
WITH
TIME
ZONE
値がUTCで同じ時刻を表す場合は、データに格納されたTIME
ZONE
オフセットにかかわらず、同一であるとみなされます。次に例を示します。
TIMESTAMP '1999-04-15 8:00:00 -8:00'
前述の例文は次の例文と同じです。
TIMESTAMP '1999-04-15 11:00:00 -5:00'
太平洋標準時の午前8時は、東部標準時の午前11時と同じです。
UTCオフセットをTZR
(タイムゾーン地域)書式要素に置換できます。次の例では、前述の例と同じ値を持ちます。
TIMESTAMP '1999-04-15 8:00:00 US/Pacific'
夏時間に切り替えられる境界のあいまいさを排除するには、TZR
および対応するTZD
書式要素の両方を使用します。次の例では、前述の例が確実に夏時間の値を戻します。
TIMESTAMP '1999-10-29 01:30:00 US/Pacific PDT'
タイムゾーン・オフセットは日時式を使用して表記することもできます。
SELECT TIMESTAMP '1999-10-29 01:30:00' AT TIME ZONE 'US/Pacific' FROM DUAL;
ERROR_ON_OVERLAP_TIME
セッション・パラメータをTRUE
に設定しておくと、TZD
書式要素を追加しなかったために日時値があいまいな場合、Oracleはエラーを戻します。パラメータをFALSE
に設定しておくと、Oracleはあいまいな日時を、指定した地域の標準時刻として解析します。
TIMESTAMP WITH LOCAL TIME ZONE
データ型は、TIMESTAMP WITH TIME ZONE
とは異なり、データベースに格納されるデータはデータベースのタイムゾーンに正規化されます。タイムゾーン・オフセットは、列データの一部として格納されません。TIMESTAMP WITH LOCAL TIME ZONE
にはリテラルはありません。他の有効な日時リテラルを使用してこのデータ型の値を示してください。次の表には、TIMESTAMP WITH LOCAL TIME ZONE
列に値を挿入するときに使用できる一部の書式と、問合せによって戻される対応する値を示します。
指定した値に時刻コンポーネントがない場合(明示的または暗黙的に)、デフォルトの午前0時の値が戻されます。
期間リテラルは期間を指定します。年および月、または日付、時間、分および秒の違いを指定できます。Oracle Databaseは、YEAR
TO
MONTH
およびDAY
TO
SECOND
の2種類の期間リテラルをサポートします。各リテラルは先行フィールドを含み、後続フィールドを含むこともあります。先行フィールドは、計測する日付または時刻の基本単位を定義します。後続フィールドは、考慮する基本単位の最小増分値を定義します。たとえば、YEAR
TO
MONTH
期間では、最も近い月に対する年との期間が考慮されます。DAY
TO
MINUTE
期間では、最も近い分に対する日との期間が考慮されます。
数値形式の日付データがある場合、NUMTOYMINTERVAL
またはNUMTODSINTERVAL
変換ファンクションを使用して、数値データを期間値へ変換できます。
期間リテラルは、主に分析ファンクションとともに使用します。
次の構文を使用して、YEAR
TO
MONTH
期間リテラルを指定します。
それぞれの意味は、次のとおりです。
'integer [-integer]'
には、リテラルの先行フィールドおよびオプションの後続フィールドの整数値を指定します。先行フィールドがYEAR
で、後続フィールドがMONTH
の場合、MONTHフィールドの整数値の範囲は0〜11です。
precision
は、先行フィールドの桁数です。先行フィールド精度の有効範囲は0〜9で、デフォルトは2です。
後続フィールドを指定する場合は、その桁数を先行フィールドの桁数より少なく設定する必要があります。たとえば、INTERVAL
'0-1
' MONTH
TO
YEAR
は無効です。
次のINTERVAL
YEAR
TO
MONTH
リテラルは、intervalが123年2か月であることを示しています。
INTERVAL '123-2' YEAR(3) TO MONTH
このリテラルの他の書式の例を次に示します。省略バージョンも含みます。
あるINTERVAL
YEAR
TO
MONTH
リテラルを別のリテラルに加算または減算して、新しいINTERVAL
YEAR
TO
MONTH
リテラルを作成できます。次に例を示します。
INTERVAL '5-3' YEAR TO MONTH + INTERVAL'20' MONTH = INTERVAL '6-11' YEAR TO MONTH
次の構文を使用して、DAY
TO
SECOND
期間リテラルを指定します。
それぞれの意味は、次のとおりです。
integer
は日数を指定します。ここで指定した値の桁数が先行精度で指定した桁数より大きい場合、Oracleはエラーを戻します。
time_expr
には、HH[:MI[:SS[.n]]]
、MI[:SS[.n]]
またはSS[.n]
書式で時間を指定します(ここで、n
は秒の小数部を指定します)。n
の桁数が、fractional_seconds_precision
で指定した数より多い場合、n
はfractional_seconds_precision
値で指定した数に丸められます。先行フィールドがDAY
の場合にのみ、1桁の整数および1つの空白の後にtime_expr
を指定できます。
leading_precision
は、先行フィールドの桁数です。有効範囲は0〜9です。デフォルトは2です。
fractional_seconds_precision
は、SECOND
日時フィールドの小数部の桁数です。有効範囲は1〜9です。デフォルトは6です。
後続フィールドを指定する場合は、その桁数を先行フィールドの桁数より少なく設定する必要があります。たとえば、INTERVAL
MINUTE
TO
DAY
は無効です。このため、SECOND
が先行フィールドの場合、期間リテラルは後続フィールドを持つことができません。
後続フィールドの有効範囲は次のとおりです。
様々なINTERVAL
DAY
TO
SECOND
リテラルの書式の例を次に示します。省略バージョンも含みます。
DAY
TO
SECOND
期間リテラルを別のDAY
TO
SECOND
期間リテラルに加算または減算できます。次に例を示します。
INTERVAL'20' DAY - INTERVAL'240' HOUR = INTERVAL'10-0' DAY TO SECOND
書式モデルは、文字列に格納される日時データや数値データの書式を記述する文字リテラルです。書式モデルによってデータベース内に格納された値の内部表現は変更されません。文字列を日付または数値に変換する場合、書式モデルによって、Oracle Databaseによる文字列の変換方法が決まります。SQL文では、書式モデルをTO_CHAR
ファンクションやTO_DATE
ファンクションの引数として使用して、次の書式を指定できます。
次に例を示します。
17:45:29
'の日時書式モデルは、'HH24:MI:SS
'です。
11-Nov-1999
'の日時書式モデルは、'DD-Mon-YYYY
'です。
$2,304.25
'の数値書式モデルは、'$9,999.99
'です。
日時および数値書式モデルの要素のリストは、表2-13「数値書式要素」および表2-15「日時書式要素」を参照してください。
いくつかの書式の値は、初期化パラメータの値によって決まります。これらの書式要素によって戻される文字は、初期化パラメータNLS_TERRITORY
を使用して暗黙的に指定することもできます。デフォルト日付書式をセッションごとに変更するには、ALTER
SESSION
文を使用します。
参照:
|
この項の後半では、次の書式モデルの使用方法について説明します。
次のファンクションで数値書式モデルを使用できます。
NUMBER
、BINARY_FLOAT
またはBINARY_DOUBLE
データ型の値をVARCHAR2
データ型の値に変換するTO_CHAR
ファンクション
CHAR
データ型またはVARCHAR2
データ型の値をNUMBER
データ型の値に変換するTO_NUMBER
ファンクション
CHAR
およびVARCHAR2
式をBINARY_FLOAT
またはBINARY_DOUBLE
の値に変換するTO_BINARY_FLOAT
ファンクションおよびTO_BINARY_DOUBLE
ファンクション
すべての数値書式モデルでは、数値が指定された有効桁数に丸められます。小数点左の有効桁数が書式で指定された桁数より多い場合、シャープ記号(#)が値のかわりに戻されます。通常、このイベントは、TO_CHAR
ファンクションを制限的な数値書式文字列で使用して、丸め処理が行われた場合に発生します。
NUMBER
の値が非常に大きく、指定の書式で表せない場合、無限大記号(~)が値のかわりに戻されます。同様に、負のNUMBER
の値が非常に小さく、指定の書式で表せない場合、負の無限大記号(-~)が戻されます。
BINARY_FLOAT
またはBINARY_DOUBLE
の値がCHAR
またはNCHAR
に変換される場合、無限大またはNaN
(非数値)のいずれかが入力されると、Oracleは常に値のかわりにシャープ記号を戻します。ただし、書式モデルを省略すると、OracleはInf
またはNan
を文字列として戻します。
数値書式モデルは、1つ以上の数値書式要素で構成されます。次の表に、数値書式モデルの要素とその例を示します。
数値書式モデルに書式要素MI
、S
またはPR
が指定されないかぎり、負の戻り値の先頭には自動的に負の符号が付けられ、正の戻り値の先頭には空白が付けられます。
表2-14に、異なるnumber
と'fmt'
に対して次の問合せを行った場合の結果を示します。
SELECT TO_CHAR(number, 'fmt') FROM DUAL;
次のファンクションで日時書式モデルを使用できます。
TO_*
日時ファンクション(TO
*日時ファンクションは、TO_DATE
、TO_TIMESTAMP
およびTO_TIMESTAMP_TZ
です。)
TO_CHAR
ファンクション
日時書式モデルの合計長は最大22文字です。
デフォルト日時書式は、NLSセッション・パラメータNLS_DATE_FORMAT
、NLS_TIMESTAMP_FORMAT
およびNLS_TIMESTAMP_TZ_FORMAT
で明示的に指定することも、NLSセッション・パラメータNLS_TERRITORY
で暗黙的に指定することもできます。デフォルト日時書式をセッションごとに変更するには、ALTER
SESSION
文を使用します。
日時書式モデルは、表2-15「日時書式要素」に示す、1つ以上の日時書式要素で構成されます。
TO_*
日付ファンクションで使用可能かどうかを示します。TO_CHAR
では、すべての書式要素が使用できます。
FF
、TZD
、TZH
、TZM
およびTZR
は、タイムスタンプおよび期間書式モデルでは使用できますが、元のDATE
書式モデルでは使用できません。
戻される日付値では、その大文字と小文字は対応する書式要素の表記に従います。たとえば、日付書式モデル「DAY」は「MONDAY」、「Day」は「Monday」、「day」は「monday」を生成します。
日付書式モデルでは、次の文字を指定できます。
これらの文字は、戻り値の中で書式モデルに指定された位置と同じ位置に現れます。
Oracle Databaseは、一定の柔軟性によって文字列を日付に変換します。たとえば、TO_DATE
ファンクションの使用時、句読点文字を含む書式モデルと、句読点文字がないか、一部を使用した入力文字列は同じになり、入力文字列の各数値要素に最大許容桁数が含まれます(たとえば、'MM'に2桁の'05'、'YYYY'に4桁の'2007')。次の文は、エラーを戻しません。
SELECT TO_CHAR (TO_DATE('0297','MM/YY'), 'MM/YY') FROM DUAL; TO_CH ----- 02/07
次の書式文字列はエラーを戻しませんが、FX(厳密な書式一致)書式修飾子では、式および書式文字列が完全に一致する必要があります。
SELECT TO_CHAR(TO_DATE('0207', 'fxmm/yy'), 'mm/yy') FROM DUAL; SELECT TO_CHAR(TO_DATE('0207', 'fxmm/yy'), 'mm/yy') FROM DUAL * ERROR at line 1: ORA-01861: literal does not match format string
いくつかの日時書式要素の機能は、Oracle Databaseを使用している国および言語に依存します。たとえば、次の日時書式要素は、フルスペルで値が戻されます。
これらの値を戻す言語は、初期化パラメータNLS_DATE_LANGUAGE
によって明示的に指定することも、初期化パラメータNLS_LANGUAGE
によって暗黙的に指定することもできます。日時書式要素YEAR
とSYEAR
によって戻される値は常に英語です。
日時書式要素D
は、曜日の数(1〜7)を戻します。この数が1である曜日は、初期化パラメータNLS_TERRITORY
によって暗黙的に指定されます。
Oracleは、ISO規格に従った日時書式要素IYYY、IYY、IY、IおよびIWによって戻される値を計算します。これらの値と日時書式要素YYYY、YYY、YY、YおよびWWによって戻される値の相違点については、『Oracle Databaseグローバリゼーション・サポート・ガイド』の「グローバリゼーション・サポート」の章を参照してください。
RR
日時書式要素は、YY
日時書式要素に似ていますが、20世紀以外の日付値を格納する場合の柔軟性が優れています。RR
日時書式要素によって、現在が21世紀でも、年の下2桁を指定するだけで、20世紀の日付を格納できます。
YY
日時書式要素でTO_DATE
ファンクションを使用した場合、日付値は常に現在の年と同じ上2桁で戻されます。そのかわりにRR
日時書式要素を使用した場合、年に指定した2桁の数と現在の年の下2桁の数によって戻り値の世紀が変化します。
したがって、次のようになります。
次に、RR日時書式要素の特長を具体的に説明します。
次の問合せが、1950年〜1999年の間に発行されるとします。
SELECT TO_CHAR(TO_DATE('27-OCT-98', 'DD-MON-RR') ,'YYYY') "Year" FROM DUAL; Year ---- 1998 SELECT TO_CHAR(TO_DATE('27-OCT-17', 'DD-MON-RR') ,'YYYY') "Year" FROM DUAL; Year ---- 2017
次の問合せが、2000年〜2049年の間に発行されるとします。
SELECT TO_CHAR(TO_DATE('27-OCT-98', 'DD-MON-RR') ,'YYYY') "Year" FROM DUAL; Year ---- 1998 SELECT TO_CHAR(TO_DATE('27-OCT-17', 'DD-MON-RR') ,'YYYY') "Year" FROM DUAL; Year ---- 2017
発行される年(2000年の前後)にかかわらず、問合せが同じ値を戻していることに注目してください。RR日時書式要素によって、年の上2桁が異なっても同じ値を戻すSQL文を記述できます。
表2-16に、日時書式要素に付加できる接尾辞を示します。
接尾辞 | 意味 | 要素の例 | 値の例 |
---|---|---|---|
TH |
序数 |
|
|
SP |
フルスペルで表した数 |
|
|
SPTHまたはTHSP |
フルスペルで表した序数 |
|
|
TO_CHAR
ファンクションの書式モデルで修飾子FM
とFX
を使用して、空白の埋め方および書式検査を制御できます。
修飾子は書式モデルに複数指定できます。この場合、後の修飾子は前の修飾子の効果を逆にします。第1の修飾子は、それに後続するモデル部分に対して有効になり、第2の修飾子が指定されると、その後のモデル部分で無効になります。第3の修飾子が指定されると、その後のモデル部分で再び有効になります。以降、同様に続きます。
Fill mode(埋込みモード)です。書式要素が固定幅になるまで後続空白文字と先行0(ゼロ)が埋め込まれます。幅は、関連する書式モデルの最大要素の表示幅と等しくなります。
YYYY
要素は4桁(9999の長さ)まで、HH24
は2桁(23の長さ)まで、DDD
は3桁(366の長さ)まで埋め込まれます。
MONTH
、MON
、DAY
およびDY
には、NLS_DATE_LANGUAGE
パラメータおよびNLS_CALENDAR
パラメータの値によって指定される有効な名前の中で、それぞれ最長のフルスペルの月名、最長の省略形の月名、最長のフルスペルの曜日または最長の省略形の曜日の幅まで、後続空白が埋め込まれます。たとえば、NLS_DATE_LANGUAGE
がAMERICAN
でNLS_CALENDAR
がGREGORIAN
(デフォルト)の場合、MONTH
の最大要素はSEPTEMBER
であるため、MONTH
書式要素のすべての値は表示文字が9文字になるまで埋め込まれます。NLS_DATE_LANGUAGE
パラメータおよびNLS_CALENDAR
パラメータの値は、TO_CHAR
およびTO_*
日時ファンクションの3番目の引数で指定されるか、または現行セッションのNLS環境から取得されます。
SP
、SPTH
およびTHSP
接尾辞)には埋め込まれません。
FM
修飾子を使用すると、TO_CHAR
ファンクションの戻り値で前述の埋込みは行われなくなります。
Format exact(厳密な書式一致)です。この修飾子は、TO_DATE
ファンクションの文字引数と日時書式モデルに対して、厳密な一致を指定します。
FX
を指定していない場合、Oracleは余分な空白を無視します。
FX
を指定していない場合、文字引数における数値によっては先行0(ゼロ)が省略されます。FX
が使用可能になっているとき、FM
修飾子を指定して、この先行0(ゼロ)のチェックを使用禁止にできます。
文字引数の位置がこれらの条件に違反する場合、Oracleはエラー・メッセージを戻します。
次の文は、日付書式モデルを使用して文字式を戻します。
SELECT TO_CHAR(SYSDATE, 'fmDDTH')||' of '||TO_CHAR (SYSDATE, 'fmMonth')||', '||TO_CHAR(SYSDATE, 'YYYY') "Ides" FROM DUAL; Ides ------------------ 3RD of April, 1998
この文はFM
修飾子も使用していることに注目してください。FM
を指定しないと、月は、次のように空白を埋め込んで9文字にして戻されます。
SELECT TO_CHAR(SYSDATE, 'DDTH')||' of '|| TO_CHAR(SYSDATE, 'Month')||', '|| TO_CHAR(SYSDATE, 'YYYY') "Ides" FROM DUAL; Ides ----------------------- 03RD of April , 1998
次の文は、2つの連続した一重引用符を含む日付書式モデルを使用することによって、戻り値に一重引用符を含めます。
SELECT TO_CHAR(SYSDATE, 'fmDay')||'''s Special' "Menu" FROM DUAL; Menu ----------------- Tuesday's Special
書式モデル内の文字リテラルにおいても、同じ目的で一重引用符を2つ連続して使用できます。
表2-17に、char
値と'fmt
'の様々な組合せに対し、次の文がFX
を使用した一致条件を満たしているかどうかを示します(table
という名前の表にはDATE
データ型の列date_column
があります)。
UPDATE table SET date_column = TO_DATE(char, 'fmt');
書式モデルを使用して、データベースから値を戻す場合にOracleが使用する書式を指定できます。
次の文は、部門80の従業員の給与を選択し、TO_CHAR
ファンクションを使用して、その給与を数値書式モデル'$99,990.99
'で指定した書式の文字値に変換します。
SELECT last_name employee, TO_CHAR(salary, '$99,990.99') FROM employees WHERE department_id = 80;
Oracleはこの書式モデルによって、ドル記号を先頭に付け、3桁ごとにカンマで区切り、小数点以下2桁を持つ給与を戻します。
次の文は、部門20の各従業員の入社した日付を選択し、TO_CHAR
ファンクションを使用して、その日付を日付書式モデル'fmMonth
DD,
YYYY
'で指定した書式の文字列に変換します。
SELECT last_name employee, TO_CHAR(hire_date,'fmMonth DD, YYYY') hiredate FROM employees WHERE department_id = 20;
Oracleはこの書式モデルによって、2桁の日、世紀も含めた4桁の年で示された入社日付(fm
で指定)を空白で埋めないで戻します。
列の値を挿入または更新する場合、指定する値のデータ型は列のデータ型と一致している必要があります。書式モデルを使用して、あるデータ型の値を列が必要とする別のデータ型の値に変換する書式を指定できます。
たとえば、DATE
列に挿入する値は、DATE
データ型の値か、またはデフォルト日付書式の文字列値である必要があります(Oracleは、暗黙的にデフォルト日付書式の文字列をDATE
データ型に変換します)。値が別の書式で与えられる場合、TO_DATE
ファンクションを使用して値をDATE
データ型に変換する必要があります。また、文字列の書式を指定する場合にも、書式モデルを使用する必要があります。
次の文は、TO_DATE
ファンクションを使用してHunold
の入社日を更新します。文字列'1998 05 20'をDATE
値に変換するために、書式マスク'YYYY MM DD'を指定します。
UPDATE employees SET hire_date = TO_DATE('1998 05 20','YYYY MM DD') WHERE last_name = 'Hunold';
次の追加の書式化規則は、文字列値を日付値に変換する場合に適用されます(ただし、書式モデルで修飾子FM
とFX
を使用して書式検査を制御した場合は適用できません)。
元の書式要素 | 元の書式要素のかわりに試行する書式要素 |
---|---|
'MM' |
|
|
|
|
|
|
|
|
|
SYS_XMLGEN
ファンクションは、XML文書を含むXMLType
型のインスタンスを戻します。Oracleでは、SYS_XMLGEN
ファンクションの結果をフォーマットするXMLFormat
オブジェクトを提供します。
表2-19に、XMLFormat
オブジェクトの属性を示します。表に示すように、ファンクションはこの型を実装します。
参照:
|
XMLFormat
オブジェクトを実装するファンクションは、次のとおりです。
STATIC FUNCTION createFormat( enclTag IN varchar2 := 'ROWSET', schemaType IN varchar2 := 'NO_SCHEMA', schemaName IN varchar2 := null, targetNameSpace IN varchar2 := null, dburlPrefix IN varchar2 := null, processingIns IN varchar2 := null) RETURN XMLGenFormatType deterministic parallel_enable, MEMBER PROCEDURE genSchema (spec IN varchar2), MEMBER PROCEDURE setSchemaName(schemaName IN varchar2), MEMBER PROCEDURE setTargetNameSpace(targetNameSpace IN varchar2), MEMBER PROCEDURE setEnclosingElementName(enclTag IN varchar2), MEMBER PROCEDURE setDbUrlPrefix(prefix IN varchar2), MEMBER PROCEDURE setProcessingIns(pi IN varchar2), CONSTRUCTOR FUNCTION XMLGenFormatType ( enclTag IN varchar2 := 'ROWSET', schemaType IN varchar2 := 'NO_SCHEMA', schemaName IN varchar2 := null, targetNameSpace IN varchar2 := null, dbUrlPrefix IN varchar2 := null, processingIns IN varchar2 := null) RETURN SELF AS RESULT deterministic parallel_enable, STATIC function createFormat2( enclTag in varchar2 := 'ROWSET', flags in raw) return sys.xmlgenformattype deterministic parallel_enable );
行のある列の値がない場合、その列はNULLである、またはNULLを含むといいます。NOT
NULL
整合性制約またはPRIMARY
KEY
整合性制約によって制限されていない列の場合は、どのデータ型の列でもNULLを含むことができます。実際のデータ値が不定または値に意味がない場合に、NULLを使用してください。
Oracle Databaseは、長さが0(ゼロ)の文字値をNULLとして処理します。ただし、NULLは値0(ゼロ)と同じではないため、0(ゼロ)の数値を表すためにNULL値を使用しないでください。
NULLを含む算術式は、必ずNULLに評価されます。たとえば、NULLに10を加算しても結果はNULLです。実際、オペランドにNULLを指定した場合、(連結演算子を除く)すべての演算子はNULLを戻します。
ほとんどのスカラー・ファンクションでは、引数としてNULLを指定するとNULLが戻されます。NVL
ファンクションを使用した場合、NULLが発生したときに値を戻すことができます。たとえば、式NVL(commission_pct,0)
は、commission_pct
がNULLの場合は0(ゼロ)を戻し、commission_pct
がNULLでなければその値を戻します。
集計ファンクションによるNULLの処理の詳細は、「集計ファンクション」を参照してください。
NULLを検査するには、比較条件IS
NULL
およびIS
NOT
NULL
のみを使用します。NULLを他の条件で使用して、その結果がNULLの値に依存する場合、結果はUNKNOWN
になります。NULLはデータの欠落を表すため、任意の値や別のNULLとの関係で等号や不等号は成り立ちません。ただし、OracleはDECODE
ファンクションを評価するときに2つのNULLを等しい値とみなします。構文および追加情報については、「DECODE」を参照してください。
コンポジット・キーの場合、2つのNULLは等しいと判断されます。NULLを含む2つのコンポジット・キーは、そのキーのNULL以外のコンポーネントのすべてが等しい場合、同一であると判断されます。
UNKNOWN
として評価される条件は、FALSE
と評価される場合とほとんど同じ働きをします。たとえば、UNKNOWN
と評価される条件をWHERE
句に持つSELECT
文からは、行が戻されません。ただし、UNKNOWN
と評価される条件はFALSE
条件とは異なり、UNKNOWN
条件をさらに評価してもUNKNOWN
と評価されます。したがって、NOT
FALSE
はTRUE
と評価されますが、NOT
UNKNOWN
はUNKNOWN
と評価されます。
表2-20は、条件にNULLを含む評価の例です。SELECT
文のWHERE
句でUNKNOWN
と評価される条件が使用された場合、その問合せに対して行は戻されません。
NULLを含む論理条件の結果を示した真理値表は、表7-5、表7-6、および表7-7を参照してください。
次の2種類のコメントを作成できます。
コメントは、アプリケーションを読みやすく、メンテナンスしやすくします。たとえば、文にはアプリケーションでのその文の目的を記述したコメントを含めることができます。SQL文中のコメントは文の実行には影響しませんが、ヒントは例外です。この特殊なコメント形式を使用する場合の詳細は、「ヒントの使用方法」を参照してください。
コメントは、文中のキーワード、パラメータまたは句読点の間に入れることができます。次のいずれかの方法を使用します。
SQLの入力に使用するツール製品には、追加の制限事項があるものもあります。たとえば、SQL*Plusを使用している場合、デフォルトでは複数行のコメント内に空白行を入れることはできません。詳細は、データベースのインタフェースとして使用するツール製品のドキュメントを参照してください。
SQL文の中に両方のスタイルのコメントが複数あってもかまいません。コメントのテキストには、使用しているデータベース・キャラクタ・セットの印字可能文字を含めることができます。
次の文には多くのコメントが含まれています。
SELECT last_name, salary + NVL(commission_pct, 0), job_id, e.department_id /* Select all employees whose compensation is greater than that of Pataballa.*/ FROM employees e, departments d /*The DEPARTMENTS table is used to get the department name.*/ WHERE e.department_id = d.department_id AND salary + NVL(commission_pct,0) > /* Subquery: */ (SELECT salary + NVL(commission_pct,0) /* total compensation is salar + commission_pct */ FROM employees WHERE last_name = 'Pataballa'); SELECT last_name, -- select the name salary + NVL(commission_pct, 0),-- total compensation job_id, -- job e.department_id -- and department FROM employees e, -- of all employees departments d WHERE e.department_id = d.department_id AND salary + NVL(commission_pct, 0) > -- whose compensation -- is greater than (SELECT salary + NVL(commission_pct,0) -- the compensation FROM employees WHERE last_name = 'Pataballa') -- of Pataballa. ;
COMMENT
コマンドを使用して、スキーマ・オブジェクト(表、ビュー、マテリアライズド・ビュー、演算子、索引タイプ、マイニング・モデル)にコメントを付けることができます。表スキーマ・オブジェクトの一部である列にもコメントを作成できます。スキーマ・オブジェクトおよび非スキーマ・オブジェクトに付けたコメントは、データ・ディクショナリに格納されます。このコメントの形式の詳細は、「COMMENT」を参照してください。
Oracle Databaseのオプティマイザに指示(ヒント)を与えるために、SQL文中でコメントを使用できます。オプティマイザは、オプティマイザの動作を阻止する条件が存在しないかぎり、これらのヒントを使用して文の実行計画を選択します。
文ブロックには、ヒントを含むコメントは1つのみ指定できます。このコメントは、SELECT
、UPDATE
、INSERT
、MERGE
またはDELETE
のいずれかのキーワードの後でのみ指定できます。INSERT
文では次の2つのヒントのみを使用します。APPEND
ヒントは常にINSERT
キーワードの後で指定し、PARALLEL
ヒントはINSERT
キーワードの後で指定できます。
次の構文図は、Oracleが文ブロック内でサポートする両方のスタイルのコメントに含まれるヒントの構文です。ヒント構文は、文ブロックを開始するINSERT
、UPDATE
、DELETE
、SELECT
またはMERGE
のいずれかのキーワードの直後でのみ指定できます。
それぞれの意味は、次のとおりです。
hint
は、この項で説明するヒントの1つです。プラス記号とヒントの間の空白は入れても入れなくてもかまいません。コメントに複数のヒントが含まれている場合は、1つ以上の空白で区切る必要があります。
string
は、ヒントに含めることができるその他のコメント・テキストです。
--+
構文では、コメント全体を単一行で指定する必要があります。
Oracle Databaseは、次の状況ではヒントを無視し、エラーを戻しません。
DELETE
、INSERT
、MERGE
、SELECT
またはUPDATE
のいずれかのキーワードの後で指定していない場合。
多くのヒントは、特定の表や索引に適用することも、ビュー内の表や、索引の一部である列によりグローバルに適用することもできます。このようなグローバル・ヒントは、構文要素tablespec
およびindexspec
によって定義します。
アクセスする表は、文で示されるとおり正確に指定する必要があります。文が表の別名を使用している場合は、ヒントでも表名を使用せずに別名を使用します。ただし、文でスキーマ名を指定している場合でも、ヒント内ではスキーマ名を表名に含めないでください。
ヒントの仕様でtablespec
の後にindexspec
を指定する場合、表名と索引名をカンマで区切ることができます。ただし、このカンマは必須ではありません。indexspec
を複数指定する場合もカンマで区切ることができます(必須ではありません)。
多くのヒントでオプションの問合せブロック名を指定して、ヒントが適用される問合せブロックを指定できます。この構文によって、インライン・ビューに適用されるヒントを外部問合せ内で指定できます。
問合せブロックの引数の構文は、@
queryblock
の形式になります。ここでqueryblock
は問合せ内で問合せブロック指定する識別子です。queryblock
識別子は、システムで生成されるかまたはユーザーによって指定されます。ヒントが適用される問合せブロック内でヒントを指定する場合は、@queryblock
構文を指定しません。
EXPLAIN
PLAN
文を使用して取得できます。変換前の問合せブロック名は、NO_QUERY_TRANSFORMATION
ヒントを使用している問合せに対してEXPLAIN
PLAN
を実行することで調べることができます。「NO_QUERY_TRANSFORMATIONヒント」を参照してください。
QB_NAME
ヒントで指定できます。「QB_NAMEヒント」を参照してください。
表2-21に、機能のカテゴリに分類したヒントと、各ヒントの構文とセマンティクスの参照先を示します。表の後には、ヒントをアルファベット順に説明します。
この項では、すべてのヒントの構文とセマンティクスをアルファベット順に説明します。
ALL_ROWS
ヒントは、文ブロックが最高のスループットになるよう(リソースの消費が最小になるよう)、オプティマイザに最適化の指示をします。たとえば、オプティマイザは問合せの最適化アプローチを使用して、この文を最高のスループットに最適化します。
SELECT /*+ ALL_ROWS */ employee_id, last_name, salary, job_id FROM employees WHERE employee_id = 7566;
ALL_ROWS
またはFIRST_ROWS
ヒントのいずれかをSQL文で指定する場合に、この文でアクセスする表の統計情報がデータ・ディクショナリにないと、オプティマイザは該当する表に割り当てられている記憶域など、デフォルトの統計値を使用して欠落している統計値を推定し、実行計画を選択します。このような推定値は、DBMS_STATS
パッケージで収集した値ほど正確でない場合があるため、統計情報の収集にはDBMS_STATS
パッケージを使用する必要があります。
アクセス・パスまたは結合操作のヒントをALL_ROWS
またはFIRST_ROWS
ヒントとともに指定する場合、オプティマイザでは、ヒントで指定されたアクセス・パスまたは結合操作が優先されます。
APPEND
ヒントは、ダイレクト・パス・インサート文を使用するようオプティマイザに指示します。
INSERT
はシリアル・モードでのデフォルトです。シリアル・モードでは、ダイレクト・パスはAPPEND
ヒントを指定する場合にのみ使用できます。
NOAPPEND
ヒントを指定する場合にのみ使用できます。
INSERT
をパラレルにするかどうかの決定は、APPEND
ヒントとは関係ありません。
ダイレクト・パス・インサートの場合、データは現在表に割り当てられている既存の空き領域を使用せず、表の最後に追加されます。その結果、ダイレクト・パス・インサートは、従来型INSERT
よりも高速に処理されます。
(「ヒントでの問合せブロックの指定」、tablespec::=を参照)
CACHE
ヒントは、全表スキャンの実行時に、この表に対して取り出されたブロックを、バッファ・キャッシュ内のLRUリストの最高使用頻度側に入れるようオプティマイザに指定します。このヒントは、小規模な参照表で有効です。
次の例では、CACHE
ヒントが表のデフォルト・キャッシュ仕様を上書きします。
SELECT /*+ FULL (hr_emp) CACHE(hr_emp) */ last_name FROM employees hr_emp;
CACHE
およびNOCACHE
ヒントは、V$SYSSTAT
データ・ディクショナリ・ビューで示すように、システム統計情報table scans (long tables)
およびtable scans (short tables)
に影響を与えます。
(「ヒントでの問合せブロックの指定」、tablespec::=を参照)
CLUSTER
ヒントは、クラスタ・スキャンを使用して、指定した表にアクセスするようオプティマイザに指示します。このヒントは、クラスタ化された表にのみ適用されます。
Oracleでは、置換しても安全な場合には、SQL文内のリテラルをバインド変数に置き換えることができます。この置換処理は、CURSOR_SHARING
初期化パラメータを使用して制御します。CURSOR_SHARING_EXACT
ヒントは、この動作を行わないようオプティマイザに指示します。このヒントを指定すると、Oracleは、リテラルのバインド変数への置換を試行せずにSQL文を実行します。
(「ヒントでの問合せブロックの指定」、tablespec::=を参照)
DRIVING_SITE
ヒントは、データベースによって選択されたサイトとは異なるサイトで問合せを実行するようオプティマイザに指示します。このヒントは、分散化された問合せの最適化を使用している場合に有効です。
次に例を示します。
SELECT /*+ DRIVING_SITE(departments) */ * FROM employees, departments@rsite WHERE employees.department_id = departments.department_id;
この問合せがヒントなしで実行されている場合、departments
からの行がローカル・サイトに送信され、そこで結合が実行されます。このヒントを使用している場合、employees
からの行がリモート・サイトに送信され、そこで問合せが実行されて結果セットがローカル・サイトに戻されます。
(「ヒントでの問合せブロックの指定」、tablespec::=を参照)
DYNAMIC_SAMPLING
ヒントは、動的なサンプリングを制御する方法をオプティマイザに指示し、より正確な述語の選択性と表および索引に対する統計情報を調べることでサーバーのパフォーマンスを改善します。
DYNAMIC_SAMPLING
の値は、0〜10の範囲で設定できます。このレベルが高いほど、コンパイラは多くのリソースを動的なサンプリングに費やし、その適用範囲も広がります。tablespec
を指定しない場合、サンプリングのデフォルトは、カーソルのレベルになります。
integer
の値は0
〜10
となり、サンプリングの度合いを示します。
カーディナリティ統計情報が表にすでに存在する場合、オプティマイザはその情報を使用します。存在しない場合、オプティマイザは動的なサンプリングによってカーディナリティ統計情報を推定します。
tablespec
を指定しており、カーディナリティ統計情報がすでに存在している場合は、次のようになります。
WHERE
句)がない場合、オプティマイザは既存の統計情報を信頼し、このヒントを無視します。たとえば、employees
が分析される場合、次の問合せは動的なサンプリングにはなりません。
SELECT /*+ dynamic_sampling(e 1) */ count(*) FROM employees e;
動的なサンプリングを特定の表に適用するには、次の形式のヒントを使用します。
SELECT /*+ dynamic_sampling(employees 1) */ * FROM employees WHERE ...
(「ヒントでの問合せブロックの指定」、tablespec::=を参照)
FACT
ヒントは、スター型変換のコンテキストで使用されます。このヒントは、tablespec
内で指定されている表をファクト表とみなす必要があることをオプティマイザに指示します。
FIRST_ROWS
ヒントは、最初のn
行を最も効率的に戻す計画を選択し、個々のSQL文を最適化して応答時間を速くするようOracleに指示します。integer
には、戻される行数を指定します。
たとえば、オプティマイザは問合せの最適化アプローチを使用して、次の文を最善の応答時間に最適化します。
SELECT /*+ FIRST_ROWS(10) */ employee_id, last_name, salary, job_id FROM employees WHERE department_id = 20;
この例では、各部門に多数の従業員がいます。ユーザーは、部門20の最初の10人の従業員を迅速に表示する必要があります。
オプティマイザは、DELETE
およびUPDATE
の文ブロック、およびソートまたはグループ化などのブロッキング操作を含むSELECT
文ブロックではこのヒントを無視します。Oracle Databaseでは最初の行を戻す前に、この文でアクセスされるすべての行を取り出す必要があるため、このような文は最善の応答時間に最適化することができません。このヒントをこのような文で指定する場合は、データベースを最善のスループットに最適化します。
(「ヒントでの問合せブロックの指定」、tablespec::=を参照)
FULL
ヒントは、指定した表に対して全表スキャンを実行するようオプティマイザに指示します。次に例を示します。
SELECT /*+ FULL(e) */ employee_id, last_name FROM hr.employees e WHERE last_name LIKE :b1;
Oracle Databaseは、WHERE
句内の条件によって使用可能になるlast_name
列に索引がある場合でも、employees
表に対して全表スキャンを実行し、この文を実行します。
employees
表は、FROM
句の中に別名e
を持つため、ヒントは表名ではなく別名で表を参照する必要があります。スキーマ名がFROM
句の中で指定されている場合でも、ヒントではスキーマ名を指定しないでください。
(「ヒントでの問合せブロックの指定」、tablespec::=を参照)
HASH
ヒントは、ハッシュ・スキャンを使用して、指定した表にアクセスするようオプティマイザに指示します。このヒントは、テーブル・クラスタ内に格納されている表にのみ適用されます。
(「ヒントでの問合せブロックの指定」、tablespec::=、indexspec::=を参照)
INDEX
ヒントは、指定した表について索引スキャンを使用するようオプティマイザに指示します。ファンクション索引、ドメイン索引、Bツリー索引、ビットマップ索引およびビットマップ結合索引について、INDEX
ヒントを使用できます。
ヒントの動作は、indexspec
の仕様によって異なります。
INDEX
ヒントが使用可能な単一の索引を指定すると、データベースはこの索引でスキャンを実行します。オプティマイザは、全表スキャンおよび表上の別の索引のスキャンを考慮しません。
INDEX
ではなくINDEX_COMBINE
ヒントの使用をお薦めします。これは、後者のほうがより多目的なヒントであるためです。INDEX
ヒントが使用可能な索引のリストを指定すると、オプティマイザは、リスト内の各索引でのスキャンのコストを検討し、最低のコストで索引スキャンを実行します。アクセス・パスのコストが最低となる場合、データベースは、このリストから複数の索引をスキャンするように選択し、結果をマージすることもあります。データベースは、全表スキャンおよびヒント内でリスト化されていない索引でのスキャンを検討しません。
INDEX
ヒントが索引を指定しない場合、オプティマイザは、表にある使用可能な各索引でのスキャンのコストを検討し、最低のコストで索引スキャンを実行します。アクセス・パスのコストが最低となる場合、データベースは複数の索引をスキャンするように選択し、結果をマージすることもあります。オプティマイザは全表スキャンを検討しません。
次に例を示します。
SELECT /*+ INDEX (employees emp_department_ix)*/ employee_id, department_id FROM employees WHERE department_id > 50;
(「ヒントでの問合せブロックの指定」、tablespec::=、indexspec::=を参照)
INDEX_ASC
ヒントは、指定した表について索引スキャンを使用するようオプティマイザに指示します。文で索引レンジ・スキャンを使用する場合、Oracle Databaseは索引付きの値の昇順で索引エントリをスキャンします。各パラメータは、「INDEXヒント」と同じ目的で使用されます。
レンジ・スキャンのデフォルトの動作は、索引付きの値の昇順で索引エントリをスキャンします。降順索引の場合は、降順でスキャンします。このヒントは索引のデフォルトの順序を変更しないため、INDEX
ヒントにないものは指定しません。ただし、デフォルトの動作を変更する必要がある場合は、INDEX_ASC
ヒントを使用して昇順レンジ・スキャンを明示的に指定できます。
(「ヒントでの問合せブロックの指定」、tablespec::=、indexspec::=を参照)
INDEX_COMBINE
ヒントは、表へのビットマップ・アクセス・パスを使用するようオプティマイザに指示します。indexspec
がINDEX_COMBINE
ヒントから省略されている場合、オプティマイザは、表のスキャンにかかるコスト効率が最大になる索引のブールの組合せを使用します。indexspec
を指定すると、オプティマイザは、指定した索引のブールのいくつかの組合せの使用を試行します。各パラメータは、「INDEXヒント」と同じ目的で使用されます。次に例を示します。
SELECT /*+ INDEX_COMBINE(e emp_manager_ix emp_department_ix) */ * FROM employees e WHERE manager_id = 108 OR department_id = 110;
(「ヒントでの問合せブロックの指定」、tablespec::=、indexspec::=を参照)
INDEX_DESC
ヒントは、指定した表に降順索引スキャンを使用するようオプティマイザに指示します。文で索引レンジ・スキャンを使用しており、索引が昇順の場合、Oracleは索引付きの値の降順で索引エントリをスキャンします。パーティション索引では、結果は各パーティション内で降順になります。降順索引の場合、このヒントは降順を効果的に取り消すため、索引エントリは昇順でスキャンされます。各パラメータは、「INDEXヒント」と同じ目的で使用されます。次に例を示します。
SELECT /*+ INDEX_DESC(e emp_name_ix) */ * FROM employees e;
(「ヒントでの問合せブロックの指定」、tablespec::=、indexspec::=を参照)
INDEX_FFS
ヒントは、全表スキャンではなく高速全索引スキャンを実行するようオプティマイザに指示します。
各パラメータは、「INDEXヒント」と同じ目的で使用されます。次に例を示します。
SELECT /*+ INDEX_FFS(e emp_name_ix) */ first_name FROM employees e;
(「ヒントでの問合せブロックの指定」、tablespec::=、indexspec::=を参照)
INDEX_JOIN
ヒントは、アクセス・パスとして索引結合を使用するようオプティマイザに指示します。ヒントが正しく機能するためには、問合せの解決に必要なすべての列を含む索引が最小限の数だけ存在している必要があります。
各パラメータは、「INDEXヒント」と同じ目的で使用されます。たとえば、次の問合せは、索引結合を使用してmanager_id
およびdepartment_id
列にアクセスします。これらの列はどちらも、employees
表内で索引付けされています。
SELECT /*+ INDEX_JOIN(e emp_manager_ix emp_department_ix) */ department_id FROM employees e WHERE manager_id < 110 AND department_id < 50;
(「ヒントでの問合せブロックの指定」、tablespec::=、indexspec::=を参照)
INDEX_SS
ヒントは、指定した表について索引スキップ・スキャンを実行するようオプティマイザに指示します。文で索引レンジ・スキャンを使用する場合、Oracleは索引付きの値の昇順で索引エントリをスキャンします。パーティション索引では、結果は各パーティション内で昇順になります。
各パラメータは、「INDEXヒント」と同じ目的で使用されます。次に例を示します。
SELECT /*+ INDEX_SS(e emp_name_ix) */ last_name FROM employees e WHERE first_name = 'Steven';
(「ヒントでの問合せブロックの指定」、tablespec::=、indexspec::=を参照)
INDEX_SS_ASC
ヒントは、指定した表について索引スキップ・スキャンを実行するようオプティマイザに指示します。文で索引レンジ・スキャンを使用する場合、Oracle Databaseは索引付きの値の昇順で索引エントリをスキャンします。パーティション索引では、結果は各パーティション内で昇順になります。各パラメータは、「INDEXヒント」と同じ目的で使用されます。
レンジ・スキャンのデフォルトの動作は、索引付きの値の昇順で索引エントリをスキャンします。降順索引の場合は、降順でスキャンします。このヒントは索引のデフォルトの順序を変更しないため、INDEX_SS
ヒントにないものは指定しません。ただし、デフォルトの動作を変更する必要がある場合は、INDEX_SS_ASC
ヒントを使用して昇順レンジ・スキャンを明示的に指定できます。
(「ヒントでの問合せブロックの指定」、tablespec::=、indexspec::=を参照)
INDEX_SS_DESC
ヒントは、指定した表について索引スキップ・スキャンを実行するようオプティマイザに指示します。文で索引レンジ・スキャンを使用しており、索引が昇順の場合、Oracleは索引付きの値の降順で索引エントリをスキャンします。パーティション索引では、結果は各パーティション内で降順になります。降順索引の場合、このヒントは降順を効果的に取り消すため、索引エントリは昇順でスキャンされます。
各パラメータは、「INDEXヒント」と同じ目的で使用されます。次に例を示します。
SELECT /*+ INDEX_SS_DESC(e emp_name_ix) */ last_name FROM employees e WHERE first_name = 'Steven';
(「ヒントでの問合せブロックの指定」、tablespec::=を参照)
LEADING
ヒントは、実行計画において、指定した一連の表を接頭辞として使用するようオプティマイザに指示します。このヒントは、ORDERED
ヒントより多目的なヒントです。次に例を示します。
SELECT /*+ LEADING(e j) */ * FROM employees e, departments d, job_history j WHERE e.department_id = d.department_id AND e.hire_date = j.start_date;
図形結合の依存性により、指定の表を指定の順序の最初に結合できない場合、LEADING
ヒントは無視されます。2つ以上の競合するLEADING
ヒントを指定すると、指定したすべてのヒントが無視されます。ORDERED
ヒントを指定すると、このヒントがすべてのLEADING
ヒントに優先します。
(「ヒントでの問合せブロックの指定」、tablespec::=を参照)
MERGE
ヒントを使用すると、問合せ内のビューをマージできます。
ビューの問合せブロックにGROUP BY
句、またはSELECT
リスト内のDISTINCT
演算子が含まれている場合、複雑なビューのマージが可能であれば、オプティマイザはビューをアクセス文のみにマージできます。複雑なマージは、副問合せに相関関係がない場合、IN
副問合せをアクセス文にマージする際に使用することもできます。
次に例を示します。
SELECT /*+ MERGE(v) */ e1.last_name, e1.salary, v.avg_salary FROM employees e1, (SELECT department_id, avg(salary) avg_salary FROM employees e2 GROUP BY department_id) v WHERE e1.department_id = v.department_id AND e1.salary > v.avg_salary;
引数なしでMERGE
ヒントを使用する場合、ビューの問合せブロック内に配置する必要があります。ビュー名を引数としてMERGE
ヒントを使用する場合、周囲の問合せに挿入する必要があります。
MODEL_MIN_ANALYSIS
ヒントは、スプレッドシート・ルールのコンパイル時間の最適化(主に、詳細な依存グラフ分析)を省略するようオプティマイザに指示します。スプレッドシートのアクセス構造に選択的に移入するためのフィルタの作成や制限されたルールのプルーニングなど、他のスプレッドシートの最適化は、引き続きオプティマイザによって使用されます。
スプレッドシート・ルールの数が数百を超えると、スプレッドシート分析に長い時間がかかることがあるため、このヒントによってコンパイル時間を減らします。
MONITOR
ヒントは、文の実行時間が長くない場合でも、問合せのリアルタイムのSQL監視を強制します。このヒントは、パラメータCONTROL_MANAGEMENT_PACK_ACCESS
がDIAGNOSTIC+TUNING
に設定されている場合にのみ有効です。
NATIVE_FULL_OUTER_JOIN
ヒントは、ネイティブ完全外部結合を使用するようオプティマイザに指示します。ネイティブ完全外部結合は、ハッシュ結合に基づくネイティブ実行メソッドです。
NOAPPEND
ヒントは、INSERT
文が有効な間、パラレル・モードを無効にして従来型のINSERT
を使用するようにオプティマイザに指示します。従来型のINSERT
はシリアル・モードでのデフォルトです。また、ダイレクト・パス・インサートはパラレル・モードでのデフォルトです。
(「ヒントでの問合せブロックの指定」、tablespec::=を参照)
NOCACHE
ヒントは、全表スキャンの実行時に、この表に対して取り出されたブロックを、バッファ・キャッシュ内のLRUリストの最低使用頻度側に入れるようオプティマイザに指定します。これは、バッファ・キャッシュ内のブロックの通常動作です。次に例を示します。
SELECT /*+ FULL(hr_emp) NOCACHE(hr_emp) */ last_name FROM employees hr_emp;
CACHE
およびNOCACHE
ヒントは、V$SYSSTAT
ビューで示すように、システム統計情報table
scans(long
tables)
およびtable
scans(short
tables)
に影響を与えます。
(「ヒントでの問合せブロックの指定」を参照)
NO_EXPAND
ヒントは、OR
条件を持つ問合せ用のOR
拡張、またはWHERE
句内にあるIN
リストを検討しないようオプティマイザに指示します。通常、オプティマイザは、OR拡張を使用しない場合よりもコストが低減できると判断すると、OR
拡張の使用を検討します。次に例を示します。
SELECT /*+ NO_EXPAND */ * FROM employees e, departments d WHERE e.manager_id = 108 OR d.department_id = 110;
(「ヒントでの問合せブロックの指定」、tablespec::=を参照)
NO_FACT
ヒントは、スター型変換のコンテキストで使用されます。このヒントは、問合せ対象の表をファクト表とみなす必要がないことをオプティマイザに指示します。
(「ヒントでの問合せブロックの指定」、tablespec::=、indexspec::=を参照)
NO_INDEX
ヒントは、指定した表について1つ以上の索引を使用しないようオプティマイザに指示します。次に例を示します。
SELECT /*+ NO_INDEX(employees emp_empid) */ employee_id FROM employees WHERE employee_id > 200;
各パラメータは「INDEXヒント」と同じ目的で使用されますが、次の変更が加えられています。
NO_INDEX
ヒントと同様になります。
NO_INDEX
ヒントは、ファンクション索引、Bツリー索引、ビットマップ索引、クラスタ索引およびドメイン索引に適用されます。NO_INDEX
ヒントと索引ヒント(INDEX
、INDEX_ASC
、INDEX_DESC
、INDEX_COMBINE
またはINDEX_FFS
)の両方が同じ索引を指定する場合、データベースは、NO_INDEX
ヒントと、指定した索引の索引ヒントの両方を無視し、これらの索引を文の実行中に使用することを検討します。
(「ヒントでの問合せブロックの指定」、tablespec::=、indexspec::=を参照)
NO_INDEX_FFS
ヒントは、指定された表の指定された索引の高速全索引スキャンを除外するようオプティマイザに指示します。各パラメータは、「INDEXヒント」と同じ目的で使用されます。次に例を示します。
SELECT /*+ NO_INDEX_FFS(items item_order_ix) */ order_id FROM order_items items;
(「ヒントでの問合せブロックの指定」、tablespec::=、indexspec::=を参照)
NO_INDEX_SS
ヒントは、指定された表の指定された索引のスキップ・スキャンを除外するようオプティマイザに指示します。各パラメータは、「INDEXヒント」と同じ目的で使用されます。
(「ヒントでの問合せブロックの指定」、tablespec::=を参照)
NO_MERGE
ヒントは、外部問合せとインライン・ビュー問合せを結合して単一の問合せにしないようオプティマイザに指示します。
このヒントを使用すると、ビューへのアクセス方法に強い影響を与えることができます。たとえば、次の文は、ビューseattle_dept
がマージされないようにします。
SELECT /*+NO_MERGE(seattle_dept)*/ e1.last_name, seattle_dept.department_name FROM employees e1, (SELECT location_id, department_id, department_name FROM departments WHERE location_id = 1700) seattle_dept WHERE e1.department_id = seattle_dept.department_id;
ビューの問合せブロック内でNO_MERGE
ヒントを使用する場合は、引数なしで指定します。また、周囲の問合せでNO_MERGE
を指定する場合には、ビュー名を引数として指定します。
NO_MONITOR
ヒントは、問合せの実行時間が長い場合でも、問合せのSQLのリアルタイム監視を無効にします。
NO_NATIVE_FULL_OUTER_JOIN
ヒントは、指定された各表を結合する場合にネイティブ実行メソッドを除外するようオプティマイザに指示します。かわりに、完全外部結合は、左側外部結合とアンチ結合の論理和として実行されます。
(「ヒントでの問合せブロックの指定」、tablespec::=を参照)
NO_PARALLEL
ヒントは、表を作成するか変更したDDL内のPARALLEL
パラメータを上書きします。次に例を示します。
SELECT /*+ NO_PARALLEL(hr_emp) */ last_name FROM employees hr_emp;
NOPARALLEL
ヒントは現在非推奨になっています。NO_PARALLEL
ヒントをかわりに使用します。
(「ヒントでの問合せブロックの指定」、tablespec::=、indexspec::=を参照)
NO_PARALLEL_INDEX
ヒントは、索引を作成するか変更したDDL内のPARALLEL
パラメータを上書きし、パラレル索引スキャン操作を防止します。
NOPARALLEL_INDEX
ヒントは現在非推奨になっています。NO_PARALLEL_INDEX
ヒントをかわりに使用します。
(「ヒントでの問合せブロックの指定」、tablespec::=を参照)
NO_PUSH_PRED
ヒントは、結合述語をビューにプッシュしないようオプティマイザに指示します。次に例を示します。
SELECT /*+ NO_MERGE(v) NO_PUSH_PRED(v) */ * FROM employees e, (SELECT manager_id FROM employees ) v WHERE e.manager_id = v.manager_id(+) AND e.employee_id = 100;
(「ヒントでの問合せブロックの指定」を参照)
NO_PUSH_SUBQ
ヒントは、実行計画における最後の手順として、マージされていない副問合せを評価するようオプティマイザに指示します。これにより、副問合せのコストが比較的高い場合や、副問合せによって行数が大幅に減少しない場合に、パフォーマンスが向上する場合があります。
このヒントは、オプティマイザがパラレル結合のビットマップ・フィルタ処理を使用するのを防ぎます。
NO_QUERY_TRANSFORMATION
ヒントは、すべての問合せ変換をスキップするようオプティマイザに指示します。この中には、OR
拡張、ビュー・マージ、副問合せのネスト解除、スター型変換、マテリアライズド・ビュー・リライトなどが含まれますが、これのみに限定されません。次に例を示します。
SELECT /*+ NO_QUERY_TRANSFORMATION */ employee_id, last_name FROM (SELECT * FROM employees e) v WHERE v.last_name = 'Smith';
RESULT_CACHE_MODE
初期化パラメータがFORCE
に設定されていると、オプティマイザは、問合せ結果を結果キャッシュにキャッシュします。この場合、NO_RESULT_CACHE
ヒントにより、このような現行の問合せのキャッシュが無効になります。
問合せがOCIクライアントから実行され、OCIクライアントの結果キャッシュが有効になっている場合、NO_RESULT_CACHE
ヒントにより現行の問合せキャッシュが無効になります。
(「ヒントでの問合せブロックの指定」を参照)
NO_REWRITE
ヒントは、パラメータQUERY_REWRITE_ENABLED
の設定を上書きして、問合せブロック用のクエリー・リライトを無効にするようオプティマイザに指示します。次に例を示します。
SELECT /*+ NO_REWRITE */ sum(s.amount_sold) AS dollars FROM sales s, times t WHERE s.time_id = t.time_id GROUP BY t.calendar_month_desc;
NOREWRITE
ヒントは現在非推奨になっています。NO_REWRITE
ヒントをかわりに使用します。
(「ヒントでの問合せブロックの指定」を参照)
NO_STAR_TRANSFORMATION
ヒントは、問合せのスター型問合せ変換を実行しないようオプティマイザに指示します。
(「ヒントでの問合せブロックの指定」を参照)
NO_UNNEST
ヒントを使用するとネスト解除をオフに切り替えます。
(「ヒントでの問合せブロックの指定」、tablespec::=を参照)
NO_USE_HASH
ヒントは、指定された表を内部表として使用して、指定された各表を別の行のソースに結合する際にハッシュ結合を除外するようオプティマイザに指示します。次に例を示します。
SELECT /*+ NO_USE_HASH(e d) */ * FROM employees e, departments d WHERE e.department_id = d.department_id;
(「ヒントでの問合せブロックの指定」、tablespec::=を参照)
NO_USE_MERGE
ヒントは、指定された表を内部表として使用して、指定された各表を別の行のソースに結合する際にソート/マージ結合を除外するようオプティマイザに指示します。次に例を示します。
SELECT /*+ NO_USE_MERGE(e d) */ * FROM employees e, departments d WHERE e.department_id = d.department_id ORDER BY d.department_id;
(「ヒントでの問合せブロックの指定」、tablespec::=を参照)
NO_USE_NL
ヒントは、指定された表を内部表として使用して、指定された各表を別の行のソースに結合する際に、ネストしたループ結合を除外するようオプティマイザに指示します。次に例を示します。
SELECT /*+ NO_USE_NL(l h) */ * FROM orders h, order_items l WHERE l.order_id = h.order_id AND l.order_id > 3500;
このヒントを指定すると、指定された表についてハッシュ結合とソート/マージ結合のみが検討されます。ただし、ネストしたループのみを使用して表を結合する場合もあります。この場合、オプティマイザは、それらの表に関するヒントを無視します。
NO_XMLINDEX_REWRITE
ヒントは、現行の問合せにXMLIndex索引を使用しないようにオプティマイザに指示します。次に例を示します。
SELECT /*+NO_XMLINDEX_REWRITE*/ count(*) FROM table WHERE existsNode(OBJECT_VALUE, '/*') = 1;
NO_XML_QUERY_REWRITE
ヒントは、SQL文のXPath式のリライトを禁止するようオプティマイザに指示します。このヒントは、XPath式のリライトを禁止することで、現行の問合せでのXMLIndex索引の使用も禁止します。次に例を示します。
SELECT /*+NO_XML_QUERY_REWRITE*/ XMLQUERY('<A/>') FROM dual;
OPT_PARAM
ヒントを使用すると、現行の問合せ中にのみ初期化パラメータを設定できます。このヒントは、パラメータOPTIMIZER_DYNAMIC_SAMPLING
、OPTIMIZER_INDEX_CACHING
、OPTIMIZER_INDEX_COST_ADJ
、OPTIMIZER_SECURE_VIEW_MERGING
およびSTAR_TRANSFORMATION_ENABLED
に対してのみ有効です。たとえば、次のヒントは、ヒントを追加した文のパラメータSTAR_TRANSFORMATION_ENABLED
をTRUE
に設定します。
SELECT /*+ OPT_PARAM('star_transformation_enabled' 'true') */ * FROM ... ;
文字列のパラメータ値は、一重引用符で囲まれます。数値のパラメータ値は、一重引用符で囲まずに指定されます。
ORDERED
ヒントは、FROM
句に現れる順序で表を結合するようOracleに指示します。ORDERED
ヒントより多目的なLEADING
ヒントを使用することをお薦めします。
結合を要求するSQL文からORDERED
ヒントを削除すると、オプティマイザが表の結合順序を選択します。各表から選択した行数をオプティマイザが把握していないと考えられる場合、ORDERED
ヒントを使用して結合順序を指定することがあります。この情報を使用すると、オプティマイザによる選択よりも効率良く内部表と外部表を選択できます。
次の問合せは、ORDERED
ヒントの使用例です。
SELECT /*+ORDERED */ o.order_id, c.customer_id, l.unit_price * l.quantity FROM customers c, order_items l, orders o WHERE c.cust_last_name = :b1 AND o.customer_id = c.customer_id AND o.order_id = l.order_id;
(「ヒントでの問合せブロックの指定」、tablespec::=を参照)
PARALLEL
ヒントは、指定された数の同時サーバーをパラレル操作に使用するようオプティマイザに指示します。このヒントは、文のSELECT
、INSERT
、MERGE
、UPDATE
およびDELETE
部分と表のスキャン部分に適用されます。
パラレル制限に違反すると、ヒントは無視されます。
integer
値は、指定された表の並列度を指定します。DEFAULT
を指定するか、いかなる値も指定しない場合、問合せコーディネータはデフォルトの並列度を決定するために初期化パラメータの設定を検証する必要があります。次の例では、PARALLEL
ヒントが、employees
表定義内で指定された並列度を上書きします。
SELECT /*+ FULL(hr_emp) PARALLEL(hr_emp, 5) */ last_name FROM employees hr_emp;
次の例では、PARALLEL
ヒントが、employees
表定義内で指定された並列度を上書きし、初期化パラメータが決定したデフォルトの並列度を使用するようオプティマイザに指示します。
SELECT /*+ FULL(hr_emp) PARALLEL(hr_emp, DEFAULT) */ last_name FROM employees hr_emp;
Oracleは、一時表に関するパラレル・ヒントを無視します。パラレル実行の詳細は、「CREATE TABLE」および『Oracle Database概要』を参照してください。
(「ヒントでの問合せブロックの指定」、tablespec::=、indexspec::=を参照)
PARALLEL_INDEX
ヒントは、パーティション索引について索引レンジ・スキャン、全体スキャンおよび高速全体スキャンをパラレル化するために、指定された数の同時サーバーを使用するようオプティマイザに指示します。
integer
値は、指定された索引の並列度を示します。DEFAULT
を指定するか、いかなる値も指定しない場合、問合せコーディネータはデフォルトの並列度を決定するために初期化パラメータの設定を検証する必要があります。たとえば、次のヒントは、3つのパラレル実行プロセスが使用されることを示します。
SELECT /*+ PARALLEL_INDEX(table1, index1, 3) */
(「ヒントでの問合せブロックの指定」、tablespec::=を参照)
PQ_DISTRIBUTE
ヒントは、結合表の行を、プロデューサおよびコンシューマ問合せサーバーに分散させる方法をオプティマイザに指示します。この分散処理により、パラレル結合操作のパフォーマンスが向上します。
分散の値は、HASH
、BROADCAST
、PARTITION
およびNONE
です。表2-22で説明するとおり、6つの組合せの表分散のみが有効です。
たとえば、r
とs
という2つの表がハッシュ結合によって結合されている場合、次の問合せには、ハッシュ分散を使用するためのヒントが含まれます。
SELECT /*+ORDERED PQ_DISTRIBUTE(s HASH, HASH) USE_HASH (s)*/ column_list FROM r,s WHERE r.c=s.c;
外部表r
をブロードキャストするための問合せは、次のとおりです。
SELECT /*+ORDERED PQ_DISTRIBUTE(s BROADCAST, NONE) USE_HASH (s) */ column_list FROM r,s WHERE r.c=s.c;
(「ヒントでの問合せブロックの指定」、tablespec::=を参照)
PUSH_PRED
ヒントは、結合述語をビューにプッシュするようオプティマイザに指示します。次に例を示します。
SELECT /*+ NO_MERGE(v) PUSH_PRED(v) */ * FROM employees e, (SELECT manager_id FROM employees ) v WHERE e.manager_id = v.manager_id(+) AND e.employee_id = 100;
(「ヒントでの問合せブロックの指定」を参照)
PUSH_SUBQ
ヒントは、実行計画の初期段階で実行可能な手順で、マージされていない副問合せを評価するようオプティマイザに指示します。通常、マージされていない副問合せは、実行計画の最終手順で実行されます。副問合せのコストが比較的低く、副問合せによって行数が大幅に減少する場合、副問合せの早期評価によってパフォーマンスが向上する可能性があります。
このヒントは、副問合せがリモート表か、マージ結合によって結合されている表に適用される場合には効果がありません。
このヒントは、パラレル結合のビットマップ・フィルタ処理の使用をオプティマイザに強制します。
(「ヒントでの問合せブロックの指定」を参照)
QB_NAME
ヒントを使用すると、問合せブロックの名前を定義できます。この名前は外部問合せ内のヒントまたはインライン・ビュー内のヒントで使用でき、名前が付けられた問合せブロックにある表で実行する問合せに影響をおよぼします。
2つ以上の問合せブロックが同じ名前の場合、または同じ問合せブロックが異なる名前でヒントが2回行われている場合、オプティマイザは、その問合せブロックを参照するすべての名前とヒントを無視します。このヒントを使用して名前が付けられていない問合せブロックには、システムが生成する一意の名前が付けられます。この名前は計画表に表示できます。また、問合せブロック内のヒントや問合せブロック・ヒントでも使用できます。次に例を示します。
SELECT /*+ QB_NAME(qb) FULL(@qb e) */ employee_id, last_name FROM employees e WHERE last_name = 'Smith';
RESULT_CACHE
ヒントは、メモリー内の現行の問合せまたは問合せのフラグメントの結果をキャッシュし、今後の問合せまたは問合せのフラグメントの実行時にキャッシュした結果を使用するようデータベースに指示します。このヒントは、トップレベル問合せ、subquery_factoring_clause
またはFROM
句のインライン・ビューで認識されます。キャッシュ結果は、共有プールの結果のキャッシュ・メモリー部分に保存されます。
作成に使用されたデータベース・オブジェクトが正常に修正されると、キャッシュ結果は自動的に無効化されます。このヒントは、RESULT_CACHE_MODE
初期化パラメータの設定よりも優先されます。
問合せが結果キャッシュに使用できるのは、問合せで必要とされるすべてのファンクション(たとえば、組込みファンクション、ユーザー定義ファンクションまたは仮想列)が決定的である場合にかぎられます。
問合せがOCIクライアントから実行され、OCIクライアントの結果キャッシュが有効になっている場合、RESULT_CACHE
ヒントにより現行の問合せのクライアントのキャッシュが有効になります。
(「ヒントでの問合せブロックの指定」を参照)
REWRITE
ヒントは、可能な場合、コストを考慮することなく、マテリアライズド・ビューに関する問合せをリライトするようオプティマイザに指示します。REWRITE
ヒントは、ビュー・リストとともに、またはビュー・リストなしで使用します。ビュー・リストとともにREWRITE
を使用し、リストに適切なマテリアライズド・ビューが含まれている場合、Oracleはコストを考慮せずにそのビューを使用します。
Oracleでは、リスト外のビューを検討しません。ビュー・リストを指定しない場合、Oracleは適切なマテリアライズド・ビューを検索し、最終計画のコストを考慮することなく常にそのビューを使用します。
(「ヒントでの問合せブロックの指定」を参照)
STAR_TRANSFORMATION
ヒントは、変換を行う際に最適な計画を使用するようオプティマイザに指示します。このヒントを使用しない場合、オプティマイザは、変換された問合せ用の最適な計画のかわりに、変換なしで生成された最適な計画を使用するという、問合せの最適化に関する決定を行う場合があります。次に例を示します。
SELECT /*+ STAR_TRANSFORMATION */ * FROM sales s, times t, products p, channels c WHERE s.time_id = t.time_id AND s.prod_id = p.product_id AND s.channel_id = c.channel_id AND p.product_status = 'obsolete';
ヒントが指定された場合でも、変換が実行される保証はありません。オプティマイザは、妥当と考えられる場合にかぎって副問合せを生成します。副問合せが生成されない場合には、変換された問合せが存在しないため、ヒントに関係なく、未変換の問合せに関する最適な計画が使用されます。
(「ヒントでの問合せブロックの指定」を参照)
UNNEST
ヒントは、副問合せの本体のネストを解除し、その副問合せを含む問合せブロック本体にマージするようオプティマイザに指示します。これによって、アクセス・パスおよび結合の評価時に、オプティマイザが副問合せと問合せブロックを総合して考慮できるようになります。
副問合せのネストを解除する前に、オプティマイザは、文が有効かどうかをまず検討します。文は、経験則に基づくテストと問合せ最適化テストに合格する必要があります。UNNEST
ヒントは、副問合せブロックの有効性のみをチェックするようオプティマイザに指示します。副問合せブロックが有効な場合、経験則またはコストをチェックすることなく副問合せのネストを解除できます。
参照:
|
(「ヒントでの問合せブロックの指定」を参照)
USE_CONCAT
ヒントは、問合せのWHERE
句内で組み合わされたOR
条件を、集合演算子UNION
ALL
を使用して複合問合せに変換するようオプティマイザに指示します。このヒントを使用しない場合、この変換は、連結を使用した問合せのコストが、使用しない場合よりも低い場合にのみ実行されます。USE_CONCAT
ヒントは、コストより優先します。次に例を示します。
SELECT /*+ USE_CONCAT */ * FROM employees e WHERE manager_id = 108 OR department_id = 110;
(「ヒントでの問合せブロックの指定」、tablespec::=を参照)
USE_HASH
ヒントは、指定された各表を、ハッシュ結合を使用して別の行のソースに結合するようオプティマイザに指示します。次に例を示します。
SELECT /*+ USE_HASH(l h) */ * FROM orders h, order_items l WHERE l.order_id = h.order_id AND l.order_id > 3500;
(「ヒントでの問合せブロックの指定」、tablespec::=を参照)
USE_MERGE
ヒントは、指定された各表を、ソート/マージ結合を使用して別の行のソースに結合するようオプティマイザに指示します。次に例を示します。
SELECT /*+ USE_MERGE(employees departments) */ * FROM employees, departments WHERE employees.department_id = departments.department_id;
LEADING
およびORDERED
ヒントとともに、USE_NL
およびUSE_MERGE
ヒントを使用することをお薦めします。オプティマイザは、参照表を結合の内部表にする必要がある場合に、これらのヒントを使用します。参照表が外部表の場合、ヒントは無視されます。
USE_NL
ヒントは、指定された表を内部表として使用し、指定された各表をネストしたループ結合とともに別の行のソースに結合するようオプティマイザに指示します。
(「ヒントでの問合せブロックの指定」、tablespec::=を参照)
USE_NL
ヒントは、指定された表を内部表として使用し、指定された各表をネストしたループ結合とともに別の行のソースに結合するようオプティマイザに指示します。
LEADING
およびORDERED
ヒントとともに、USE_NL
およびUSE_MERGE
ヒントを使用することをお薦めします。オプティマイザは、参照表を結合の内部表にする必要がある場合に、これらのヒントを使用します。参照表が外部表の場合、ヒントは無視されます。
次の例では、ネストしたループがヒントによって強制される場合、全表スキャンを介してorders
がアクセスされ、各行にフィルタ条件l.order_id = h.order_id
が適用されます。フィルタ条件を満たす各行については、索引order_id
を介してorder_items
がアクセスされます。
SELECT /*+ USE_NL(l h) */ h.customer_id, l.unit_price * l.quantity FROM orders h ,order_items l WHERE l.order_id = h.order_id;
INDEX
ヒントを問合せに追加すると、orders
の全表スキャンを回避し、より大規模なシステムで使用される実行計画と同様の実行計画を生成できる場合があります。ただし、ここでは特に効果的ではない場合があります。
(「ヒントでの問合せブロックの指定」、tablespec::=、indexspec::=を参照)
USE_NL_WITH_INDEX
ヒントは、指定された表を内部表として使用し、指定された表をネストしたループ結合とともに別の行のソースに結合するようオプティマイザに指示します。次に例を示します。
SELECT /*+ USE_NL_WITH_INDEX(l item_product_ix) */ * FROM orders h, order_items l WHERE l.order_id = h.order_id AND l.order_id > 3500;
次の条件が適用されます。
次の項で説明するとおり、Oracle Databaseは、特定のスキーマに対応付けられたオブジェクトと、特定のスキーマに対応付けられていないオブジェクトを認識します。
スキーマは、論理的なデータの構造(スキーマ・オブジェクト)の集まりです。スキーマは、データベース・ユーザーによって所有され、そのユーザーと同じ名前を持ちます。各ユーザーは、1つのスキーマを所有します。スキーマ・オブジェクトは、SQLを使用して作成および操作できます。スキーマ・オブジェクトには次のタイプのオブジェクトがあります。
次のタイプのオブジェクトもデータベースに格納され、SQLで作成および操作されますが、スキーマには含まれません。
各タイプのオブジェクトは、このマニュアルの第10章〜第19章のデータベース・オブジェクトを作成する文の項で説明されています。これらの文は、キーワードCREATE
で始まります。たとえば、クラスタの定義については、「CREATE CLUSTER」を参照してください。
ほとんどのデータベース・オブジェクトでは、作成時に名前を指定する必要があります。名前は、この後の項に示す規則に従って付けてください。
スキーマ・オブジェクトの中には、名前を付けることができる、または名前を付ける必要のある部分で構成されるものもあります。たとえば、表やビューの中の列、索引と表のパーティションおよびサブパーティション、表に対する整合性制約、パッケージ内に格納されるオブジェクト(プロシージャおよびストアド・ファンクションを含む)などです。この項では、次の内容について説明します。
すべてのデータベース・オブジェクトには、名前があります。SQL文では、引用識別子または非引用識別子を使用して、オブジェクトの名前を表します。
データベース・オブジェクトを指定する場合、引用識別子または非引用識別子を使用できます。データベース名、グローバル・データベース名およびデータベース・リンク名では大/小文字は区別されませんが、大文字として保存されます。このような名前を引用識別子として指定する場合、引用符は特に警告もなく無視されます。ユーザー名とパスワードのネーミング規則の詳細は、「CREATE USER」を参照してください。
特に指定がないかぎり、次の規則は、引用識別子と非引用識別子の両方に適用されます。
識別子にピリオドで区切られた複数の部分が含まれる場合、各属性の長さは最大30バイトにできます。ピリオドによる各セパレータおよび周囲の二重引用符は1バイトとしてカウントします。たとえば、次のように列を識別するとします。
"schema"."table"."column"
スキーマ名、表名、列名の長さはそれぞれ30バイトです。各引用符やピリオドはシングルバイト文字のため、この例での識別子の総バイト長は、最大98バイトになります。
名前は、データベース・オブジェクトにアクセスするために使用するOracle製品固有のその他の予約語によって、さらに制限されることもあります。
参照:
|
DUAL
およびキーワード(DIMENSION
、SEGMENT
、ALLOCATE
、DISABLE
など、SQL文中の大文字の単語)が含まれます。これらの文字は予約語ではありません。ただし、Oracleは固有の方法でこれらの文字を内部的に使用します。したがって、これらの文字をオブジェクトおよびオブジェクトの部分の名前として使用した場合、使用しているSQL文が読みにくくなり、予期しない結果になることがあります。特に、SYS_
またはORA_
で始まる文字をスキーマ・オブジェクト名として使用しないでください。また、SQL組込みファンクションの名前を、スキーマ・オブジェクトまたはユーザー定義ファンクションの名前として使用しないでください。
引用識別子には、すべての文字、句読点および空白を使用できます。ただし、引用識別子と非引用識別子のいずれにも、二重引用符またはNULL文字(たとえば\0
)は使用できません。
次のスキーマ・オブジェクトは、1つのネームスペースを共有します。
次の各スキーマ・オブジェクトは、固有のネームスペースを持ちます。
表およびビューが同じネームスペースにあるため、同じスキーマの表およびビューが同じ名前を持つことはできません。ただし、表と索引は異なるネームスペースに存在します。このため、同じスキーマ内の表と索引には、同じ名前を付けることができます。
データベース内の各スキーマには、その中のオブジェクトのために固有のネームスペースがあります。たとえば、異なるスキーマ内の2つの表は異なるネームスペースに存在し、同じ名前を付けることができます。
次の各非スキーマ・オブジェクトは、固有のネームスペースを持ちます。
これらのネームスペース内のオブジェクトはスキーマに含まれないため、これらのネームスペースはデータベース全体で使用されます。
名前を二重引用符で囲むことによって、同じネームスペース内の異なるオブジェクトに対して次の名前を指定できます。
employees "employees" "Employees" "EMPLOYEES"
ただし、Oracleは次の名前を同じ名前として解析するため、同じネームスペース内の異なるオブジェクトには、次の名前を使用できません。
employees EMPLOYEES "EMPLOYEES"
NLS_SORT
によって決定される言語固有の規則は考慮されません。この動作は、ファンクションNLS_UPPER
ではなく、SQLファンクションUPPER
を識別子に適用することに対応しています。データベース・キャラクタ・セットの大文字化規則によって、特定の自然言語としては不適切な結果となる場合があります。たとえば、データベース・キャラクタ・セットの大文字化規則に従うと、ドイツ語で使用される小文字のシャープs(ß)に大文字形式はありません。この文字は識別子が大文字に変換されるときに変更されませんが、ドイツ語で予期される大文字形式は2文字連続の大文字S(SS)です。同様に、小文字iの大文字形式は、データベース・キャラクタ・セットの大文字化規則に従うと大文字Iですが、トルコ語およびアゼルバイジャン語で予期される大文字形式は、上に点が付いた大文字Iです。
データベース・キャラクタ・セットの大文字化規則では、識別子はセッションのすべての言語構成で同様に解釈されます。識別子が特定の自然言語で正しく表示されるようにする場合は、引用符で囲んで小文字形式を保持するか、またはその識別子を使用するときは常に言語的に正しい大文字形式を使用することができます。
次に、有効なスキーマ・オブジェクト名の例を示します。
last_name horse hr.hire_date "EVEN THIS & THAT!" a_very_long_and_valid_name
これらのすべての例は、「スキーマ・オブジェクトのネーミング規則」に示す規則に従っています。次の例は、30文字を超えているため、無効となります。
a_very_very_long_and_valid_name
列別名、表別名、ユーザー名およびパスワードは、オブジェクトまたはオブジェクトの部分ではありませんが、特に指定がないかぎり、同様にこれらのネーミング規則に従う必要があります。
オブジェクトとその部分に名前を付ける場合に有効なガイドラインを次に示します。
オブジェクトに名前を付ける場合は、短くて簡単な名前とわかりやすい名前のバランスを考えてください。迷ったときには、わかりやすい名前にしてください。これは、データベース内のオブジェクトは、多くの人々が長期間にわたって使用する可能性があるためです。payment_due_date
のかわりにpmdd
という名前を使用すると、10年後の担当者は表の列の理解に苦労することになります。
一貫したネーミング規則を使用すると、アプリケーション上の各表の働きが理解しやすくなります。そのような規則の例として、FINANCE
アプリケーションに属している表の名前をすべてfin_
で始めるような場合が考えられます。
同一のエンティティや属性に対しては、複数の表にまたがっていても同じ名前を使用してください。たとえば、employees
サンプル表とdepartments
サンプル表の部門番号列には、どちらにもdepartment_id
という名前を付けます。
SQL文のコンテキストでスキーマ・オブジェクトとそれらの部分を参照する方法について説明します。次の項目について説明します。
次に、オブジェクトやそれらの部分を参照するための一般的な構文を示します。
それぞれの意味は、次のとおりです。
object
は、オブジェクトの名前です。
schema
は、オブジェクトを含むスキーマです。この修飾子を指定することによって、自分のスキーマ以外のスキーマ内のオブジェクトを参照できます。その場合には、自分のスキーマ以外のスキーマ内のオブジェクトを参照するための権限が必要です。この修飾子を指定しないと、自分自身のスキーマ内のオブジェクトを参照するものとみなされます。スキーマ・オブジェクトのみがschema
で修飾できます。スキーマ・オブジェクトについては、規則7を参照してください。規則7に示す非スキーマ・オブジェクトはスキーマ・オブジェクトではないため、schema
では修飾できません。ただし、パブリック・シノニムは例外で、「PUBLIC
」で修飾できます。この場合、引用符が必要です。
part
は、オブジェクトの部分です。この識別子によって、スキーマ・オブジェクトの部分(たとえば、表の列またはパーティション)を参照できます。なお、すべてのタイプのオブジェクトが部分を持っているとはかぎりません。
dblink
は、Oracle Databaseの分散オプションを使用している場合にのみ適用されます。オブジェクトを含むデータベースの名前です。この修飾子dblink
を指定することによって、ローカル・データベース以外のデータベース内のオブジェクトを参照できます。このdblink
を指定しないと、自分自身のローカル・データベース内のオブジェクトを参照するものとみなされます。なお、すべてのSQL文でリモート・データベースのオブジェクトにアクセスできるとはかぎりません。
オブジェクトを参照する際のコンポーネントを区切っているピリオドの前後には、空白を入れることができます。ただし、通常は入れません。
SQL文内のオブジェクトが参照される場合、OracleはそのSQL文のコンテキストを検討して、該当するネームスペース内でそのオブジェクトの位置を確認します。そのオブジェクトの位置を確認してから、そのオブジェクトに対して文が指定する操作を実行します。指定した名前のオブジェクトが適切なネームスペース内に存在しない場合、Oracleはエラーを戻します。
次の例で、OracleがSQL文内のオブジェクト参照を変換する方法について説明します。名前departments
で識別される表にデータ行を追加する次の文を考えます。
INSERT INTO departments VALUES ( 280, 'ENTERTAINMENT_CLERK', 206, 1700);
文のコンテキストに基づいて、Oracleは、departments
が次のようなオブジェクトであると判断します。
Oracleは、文を発行したユーザーのスキーマ外のネームスペースを考慮する前に、そのユーザーのスキーマ内のネームスペースからオブジェクト参照を変換しようとします。この例では、Oracleは次の方法で名前departments
を変換しようとします。
departments
に追加しようとします。オブジェクトがその処理にとって正しい型でない場合、Oracleはエラーを戻します。この場合、departments
は、表またはビュー、あるいは表またはビューとなるプライベート・シノニムである必要があります。departments
が順序である場合、Oracleはエラーを戻します。
departments
が順序のパブリック・シノニムである場合、Oracleはエラーを戻します。
パブリック・シノニムに、依存表またはユーザー定義型がある場合は、依存オブジェクトと同じスキーマに、シノニムと同じ名前でオブジェクトを作成することはできません。
シノニムに、依存表またはユーザー定義型がない場合は、依存オブジェクトと同じスキーマに、依存オブジェクトと同じ名前で、オブジェクトを作成できます。すべての依存オブジェクトが無効になり、次のアクセス時に妥当性チェックが再実行されます。
自分が所有するスキーマ以外のスキーマ内のオブジェクトを参照するには、次のように、オブジェクト名の前にスキーマ名を付けます。
schema.object
たとえば、次の文は、サンプル・スキーマhr
内のemployees
表を削除します。
DROP TABLE hr.employees;
ローカル・データベース以外のデータベース内のオブジェクトを参照するには、オブジェクト名の後に、そのデータベースへのデータベース・リンクの名前を続けます。データベース・リンクはスキーマ・オブジェクトであり、これによってOracleがリモート・データベースに接続され、そこにあるオブジェクトにアクセスします。この項では、次の項目について説明します。
「CREATE DATABASE LINK」を使用して、データベース・リンクを作成します。この文では、データベース・リンクに関する次の情報を指定できます。
これらの情報はデータ・ディクショナリに格納されます。
データベース・リンクを作成するとき、データベース・リンク名を指定する必要があります。データベース・リンク名は、他のオブジェクト型の名前とは異なります。データベース・リンク名は128バイト以内の長さで指定し、ピリオド(.)とアットマーク(@)を使用できます。
データベース・リンクに付ける名前は、データベース・リンクが参照するデータベースの名前、およびデータベース名の階層内のそのデータベースの位置に一致している必要があります。次に、データベース・リンク名の書式を示します。
それぞれの意味は、次のとおりです。
database
には、データベース・リンクが接続するリモート・データベースのグローバル名の名前の部分を指定します。このグローバル名は、リモート・データベースのデータ・ディクショナリに格納されます。この名前は、GLOBAL_NAME
データ・ディクショナリ・ビューで確認できます。
domain
には、データベース・リンクが接続するリモート・データベースのグローバル名のドメイン部分を指定します。データベース・リンクの名前にdomain
を指定しないと、Oracleは、現在、データ・ディクショナリに存在しているローカル・データベースのドメインに、データベース・リンク名を付加します。
connect_descriptor
によって、データベース・リンクをさらに修飾できます。接続修飾子を使用する場合、同じデータベースに複数のデータベース・リンクを作成できます。たとえば、接続修飾子を使用して、同じデータベースにアクセスするOracle Real Application Clustersの異なるインスタンスに、複数のデータベース・リンクを作成できます。
database.domain
の組合せは、サービス名と呼ばれることもあります。
リモート・データベースに接続するために、ユーザー名およびパスワードを使用します。データベース・リンクでは、ユーザー名およびパスワードはオプションです。
データベース接続文字列は、Oracle Netがリモート・データベースにアクセスするために使用する仕様です。データベース接続文字列の記述方法については、使用しているネットワーク・プロトコル用のOracle Netのドキュメントを参照してください。データベース・リンク用のデータベース文字列はオプションです。
データベース・リンクは、分散オプションを指定してOracleを使用している場合にのみ利用できます。データベース・リンクを含むSQL文の発行時に、次のいずれかの方法でデータベース・リンク名を指定します。
database
、domain
、およびオプションのconnect_descriptor
コンポーネントを含む完全なデータベース・リンク名を指定します。
database
およびオプションのconnect_descriptor
コンポーネントを含むが、domain
コンポーネントを含まない、部分的なデータベース・リンク名を指定します。
Oracleは、リモート・データベースに接続する前に次のタスクを実行します。
GLOBAL_NAME
データ・ディクショナリ・ビューで見ることができます。
GLOBAL_NAMES
パラメータの値がtrue
の場合は、Oracleは、データベース・リンク名のdatabase.domain
部分がリモート・データベースの完全なグローバル名に一致しているかどうかを確認します。この条件が満たされている場合、Oracleは手順2で選択したユーザー名とパスワードを使用して接続を続行します。それ以外の場合、Oracleはエラーを戻します。
リモート・データベースの完全なグローバル名が、データベース・リンクのdatabase.domain
部分と一致する必要があるという要件を無効にするには、初期化パラメータGLOBAL_NAMES
か、ALTER
SYSTEM
またはALTER
SESSION
文のGLOBAL_NAMES
パラメータにFALSE
を設定します。
表および索引はパーティション化できます。パーティション化されたスキーマ・オブジェクトは、パーティションと呼ばれる多数の部分で構成され、各パーティションのすべての論理属性は同じです。たとえば、表のパーティションはすべて同じ列定義と制約定義を共有し、索引のパーティションはすべて同じ索引列を共有します。
拡張パーティションおよび拡張サブパーティション名を使用した場合、1つのパーティションまたはサブパーティションのみ、パーティション・レベルおよびサブパーティション・レベルの操作(あるパーティションまたはサブパーティションからのすべての行の削除など)ができます。拡張された名前がない場合、そのような操作には述語(WHERE
句)を指定する必要があります。レンジおよびリスト・パーティション表では、パーティション・レベル操作を述語で表そうとすると(特にレンジ・パーティション・キーで複数の列を使用しているときは)、非常に複雑になる可能性があります。ハッシュ・パーティションおよびサブパーティションの場合、述語の使用はより難しくなります。これは、これらのパーティションおよびサブパーティションが、システムが定義するハッシュ・ファンクションに基づいているためです。
拡張パーティション名を使用した場合、パーティションを表のように使用できます。この方法のメリットは、これらのビューに対する権限を他のユーザーやロールに付与する(または取り消す)ことによって、パーティション・レベルのアクセス制御機構を構築できることです。このメリットは、レンジ・パーティション表に最も有効です。パーティションを表として使用するには、単一のパーティションからデータを選択してビューを作成し、そのビューを表として使用します。
構文にpartition_extended_name
要素またはsubpartition_extended_name
要素が指定されているSQL文には、拡張パーティション表名および拡張サブパーティション表名を指定できます。
DML文INSERT
、UPDATE
、DELETE
、およびANALYZE
文では、パーティション名またはサブパーティション名をカッコで囲む必要があります。細かな違いですが、partition_extension_clause
に影響します。
partition_extended_name
、subpartition_extended_name
およびpartition_extension_clause
では、PARTITION
FOR
句およびSUBPARTITION
FOR
句を使用すると、名前がなくてもパーティションを参照できます。これらの句は、すべてのタイプのパーティション化に有効であり、特に時間隔パーティションで役立ちます。データが表に挿入されると、必要に応じて時間隔パーティションが自動的に作成されます。
それぞれのpartition_value
には、パーティション化キー列ごとに1つの値を指定します。複数列のパーティション化キーには、パーティション化キーごとに1つの値を指定します。コンポジット・パーティションには、パーティション化キーごとに1つの値を指定し、続いてサブパーティション化キーごとに1つの値を指定します。すべてのパーティション化キーの値は、カンマで区切られます。時間隔パーティションには、1つのpartition_value
のみを指定できます。この値は、有効なNUMBER
または日時値にする必要があります。SQL文は、指定した値を含むパーティションまたはサブパーティションで動作します。
現在、拡張パーティション表名および拡張サブパーティション表名を使用するときには、次の制限があります。
PARTITION
FOR
句およびSUBPARTITION
FOR
句は、ビューでのDDL操作に対しては無効になります。
次の文のsales
は、パーティションsales_q1_2000
を持つパーティション表です。単一パーティションsales_q1_2000
のビューを作成でき、それを表のように使用できます。この例では、パーティションから行が削除されます。
CREATE VIEW Q1_2000_sales AS SELECT * FROM sales PARTITION (SALES_Q1_2000); DELETE FROM Q1_2000_sales WHERE amount_sold < 0;
SQL文のオブジェクト型の属性とメソッドを参照するには、参照を表の別名で完全に修飾する必要があります。次の例では、cust_address_typ
型、およびcust_address_typ
に基づくcust_address
列を持つ表customers
を含むサンプル・スキーマoe
について考えます。
CREATE TYPE cust_address_typ OID '82A4AF6A4CD1656DE034080020E0EE3D' AS OBJECT ( street_address VARCHAR2(40) , postal_code VARCHAR2(10) , city VARCHAR2(30) , state_province VARCHAR2(10) , country_id CHAR(2) ); / CREATE TABLE customers ( customer_id NUMBER(6) , cust_first_name VARCHAR2(20) CONSTRAINT cust_fname_nn NOT NULL , cust_last_name VARCHAR2(20) CONSTRAINT cust_lname_nn NOT NULL , cust_address cust_address_typ . . .
次に示すとおり、SQL文では、postal_code
属性への参照は表別名を使用して完全に修飾する必要があります。
SELECT c.cust_address.postal_code FROM customers c; UPDATE customers c SET c.cust_address.postal_code = 'GU13 BE5' WHERE c.cust_address.city = 'Fleet';
引数を取らないメンバー・メソッドを参照する場合は、空のカッコを付ける必要があります。たとえば、サンプル・スキーマoe
には、メンバー・ファンクションgetCatalogName
を含むcatalog_typ
に基づくオブジェクト表categories_tab
が含まれます。SQL文でこのメソッドをコールするには、次の例のように、空のカッコを付ける必要があります。
SELECT TREAT(VALUE(c) AS catalog_typ).getCatalogName() "Catalog Type" FROM categories_tab c WHERE category_id = 90; Catalog Type ------------------------------------ online catalog
|
![]() Copyright © 1996, 2008, Oracle Corporation. All Rights Reserved. |
|