11gリリース1（11.1）
E05765-03
 目次 |
 索引 |
| Oracle Database 概要 11gリリース1（11.1） E05765-03 |
|
この章では、Oracle組込みデータ型とその特性、およびOracleデータ型をOracle以外のデータ型にマップする方法について説明します。
この章の内容は、次のとおりです。
SQL文中の列値と定数は、それぞれ特定の記憶域形式、制約および値の有効範囲に対応付けられたデータ型を持っています。表の作成時には、その各列のデータ型を指定する必要があります。
Oracleの組込みデータ型は、次のカテゴリに分かれています。
次の各項では、各組込みデータ型についてさらに詳しく説明します。
文字データ型は、文字コード体系（通常、キャラクタ・セットまたはコード・ページと呼ばれます）に対応するバイト値によって、文字（英数字）データを文字列に格納します。
データベースのキャラクタ・セットは、データベースの作成時に設定されます。キャラクタ・セットには、7ビットASCII（情報交換用米国標準コード）、EBCDIC（拡張2進化10進コード）、コード・ページ500、日本語拡張UNIXコード、Unicode UTF-8などがあります。Oracleはシングルバイトおよびマルチバイト・コード体系をサポートしています。
この項の内容は、次のとおりです。
CHARデータ型は、固定長の文字列を格納します。CHAR列を含む表を作成するときは、CHAR列の文字列の長さを1〜2000までの値で指定する必要があります（単位はバイト数または文字数）。デフォルトは1バイトです。Oracleによって、次のことが保証されます。
Oracle Databaseは、空白埋め比較方法を使用してCHAR値を比較します。
VARCHAR2データ型には、可変長の文字列が格納されます。VARCHAR2列を含む表を作成するときは、VARCHAR2列の文字列の最大長を1〜4000までの値で指定します（単位はバイト数または文字数）。各行の値は、Oracle Databaseにより可変長フィールドとして列に格納されます。値が列の最大長を超えている場合は、Oracle Databaseからエラーが戻されます。VARCHAR2とVARCHARを使用すると、表が使用する空白を節約できます。
たとえば、列VARCHAR2を最大サイズ50文字で宣言するとします。シングルバイト・キャラクタ・セットで、特定の行のVARCHAR2列に10文字を入れると、その行断片の列には50文字ではなく10文字（10バイト）のみが格納されます。
Oracle Databaseは、非空白埋め比較方法を使用してVARCHAR2値を比較します。
VARCHARデータ型は、VARCHAR2データ型と同義です。このため、考えられる動作変更を回避するために、可変長の文字列の格納には常にVARCHAR2データ型を使用してください。
グローバリゼーション・サポートは、文字データ型に様々なキャラクタ・セットを使用できるようにします。グローバリゼーション・サポートを使用すると、シングルバイトおよびマルチバイト・キャラクタ・セットの処理や、それらのキャラクタ・セット間での変換が可能になります。クライアント・セッションでは、データベース・キャラクタ・セットと異なるクライアント・キャラクタ・セットを使用できます。
文字データ型の列の長さを指定する場合は、文字のサイズを考慮してください。この問題は、文字データを含む列を持つ表の領域を見積るときに考慮する必要があります。
文字データ型の長さセマンティクスは、バイト数または文字数で測定できます。
シングルバイト・キャラクタ・セットの場合、キャラクタ・セマンティクスで定義された列は、バイト・セマンティクスで定義された列と基本的に同じです。キャラクタ・セマンティクスは、可変幅のマルチバイト文字列の定義に便利です。つまり、データ記憶域で実際に必要な長さを定義する際の複雑さを軽減します。たとえば、Unicode（UTF8）データベースで、VARCHAR2列を定義する必要がある場合を考えます。この列には、5つまでの漢字と5つの英字を格納できます。バイト・セマンティクスでは、（5×3バイト）+（1×5バイト） = 20バイト必要です。キャラクタ・セマンティクスでは、列に10文字必要です。
VARCHAR2(20 BYTE)とSUBSTRB(<string>, 1, 20)は、バイト・セマンティクスを使用します。VARCHAR2(10 CHAR)とSUBSTR(<string>, 1, 10)は、キャラクタ・セマンティクスを使用します。
NLS_LENGTH_SEMANTICSパラメータによって、文字データ型の新しい列が、バイト・セマンティクスとキャラクタ・セマンティクスのどちらを使用するのかが決まります。デフォルトの長さセマンティクスはバイトです。データベースのすべての文字データ型列がバイト・セマンティクスを使用する（またはすべてキャラクタ・セマンティクスを使用する）場合、ユーザーはどの列がどちらのセマンティクスを使用するのかについて考慮する必要はありません。BYTEとCHARの修飾子は、前述したように可能であれば使用しないでください。これは、これらの修飾子を使用すると、データベースのセマンティクスが混合されるためです。かわりに、サーバー・パラメータ・ファイル（SPFILE）または初期化パラメータ・ファイルで、NLS_LENGTH_SEMANTICS初期化パラメータを適切に設定してください。列はデフォルトのセマンティクスを使用します。
|
関連項目
|
NCHARとNVARCHAR2は、Unicode文字データを格納するUnicodeデータ型です。NCHARとNVARCHAR2データ型のキャラクタ・セットは、AL16UTF16またはUTF8のいずれかのみです。また、データベースの作成時に各国語キャラクタ・セットとして指定されます。AL16UTF16とUTF8は、どちらもUnicodeエンコーディングです。
NCHARまたはNVARCHAR2列で表を作成すると、指定する最大サイズは、必ず文字長セマンティクス内になります。文字長セマンティクスは、デフォルトです。また、NCHARまたはNVARCHAR2の唯一の長さセマンティクスです。
たとえば、各国語キャラクタ・セットがUTF8である場合、次の文は、最大バイト長を90バイトに定義します。
CREATE TABLE tab1 (col1 NCHAR(30));
この文は、最大文字長が30の列を作成します。最大バイト長は、最大文字長と各文字の最大バイト長から決まります。
この項の内容は、次のとおりです。
NCHAR列の最大長は2000バイトです。2000文字まで格納できます。実際のデータは、多くの場合、最大バイト数の2000になります。実行時には、同時に2つのサイズ制約を満たす必要があります。
NVARCHAR2列の最大長は4000バイトです。4000文字まで格納できます。実際のデータは、多くの場合、最大バイト数の4000になります。実行時には、同時に2つのサイズ制約を満たす必要があります。
Unicodeは、ユーザーが使用するあらゆる言語のすべての文字を統一してエンコーディングしようとするものです。また、個人的に定義した文字を表す方法も提供します。Unicodeを格納するデータベースの列は、あらゆる言語のテキストを格納できます。
グローバル化されたアプリケーションをデプロイするOracle Databaseユーザーは、Oracle Databaseに必ずUnicodeデータを格納する必要があります。データベースのキャラクタ・セットに関係なく、必ずUnicodeに変換されるデータ型が必要です。
Oracle Databaseは、NCHAR、NVARCHAR2およびNCLOBによって、信頼できるUnicodeデータ型を実現しています。これらのデータ型は、Unicodeエンコーディングへの変換が保証されているため、必ず文字長セマンティクスを使用します。NCHAR/NVARCHAR2が使用するキャラクタ・セットは、UTF8またはAL16UTF16のいずれかです。これは、データベースの作成時に設定される各国語キャラクタ・セットによって決まります。これらのデータ型では、データベースがデータベース・キャラクタ・セットとしてUnicodeを使用するしないにかかわらず、Unicodeのキャラクタ・セットをそのデータベースに格納できます。
CHAR/VARCHAR2に対するすべての暗黙的な変換に加え、Oracle Databaseは、NCHAR/NVARCHAR2に対する暗黙的な変換もサポートしています。CHAR/VARCHAR2とNCHAR/NVARCHAR2間の暗黙的な変換もサポートされています。
文字データのLOBデータ型はCLOBとNCLOBです。最大8TBの文字データ（CLOB）または各国語キャラクタ・セット・データ（NCLOB）を格納できます。
LONGと定義されている列には、最大2GBまでの情報を含む可変長の文字データを格納できます。LONGデータは、異なるシステム間で移動しても適切に変換されるテキスト・データです。
LONGデータ型の列は、ビュー定義のテキストを格納するために、データ・ディクショナリで使用されます。SELECTリストのLONG列、UPDATE文のSET句、およびINSERT文のVALUES句を使用できます。
|
関連項目
|
数値データ型には、正と負の固定小数点数と浮動小数点数、ゼロ、無限大および操作の未定義の結果である値（非数値つまりNAN）が格納されます。
この項の内容は、次のとおりです。
NUMBERデータ型には、固定小数点数および浮動小数点数が格納されます。事実上どんな大きさの数値でも格納可能です。Oracle Databaseが稼働するシステムであれば、最大38桁の精度で、システム間の移植性が保証されています。
NUMBER列には、次の数値を格納できます。
数値列の場合は、次のように列を指定できます。
column_name NUMBER
また、任意で次のように精度（全体の桁数）とスケール（小数点以下の桁数）を指定することもできます。
column_name NUMBER (precision, scale)
精度を指定しないと、値は与えられたとおりに列に格納されます。スケールを指定しないと、スケールは0（ゼロ）になります。
Oracleでは、38桁以下の精度で数値の移植性が保証されています。次のように、スケールのみを指定して、精度は指定しないこともできます。
column_name NUMBER (*, scale)
この場合、精度は38になり、指定したスケールが保持されます。
数値フィールドを指定する場合には、精度とスケールを指定する方法が優れています。これによって、入力の整合性をさらにチェックできます。
表26-1に、様々なスケール変更係数がデータの格納にどのように影響するかを示します。
負のスケールを指定すると、Oracle Databaseにより小数点の左側の指定した桁数で実際のデータが丸められます。たとえば、（7,-2）という指定は、表26-1に示されているとおり、Oracle Databaseによって100の位で丸めることを意味します。
数値の入力および出力において、標準Oracle Databaseのデフォルト小数点文字はピリオドです。たとえば、1234.56というようになります。小数点文字は、数値の整数部と小数部を分離する文字です。デフォルトの小数点文字は、初期化パラメータNLS_NUMERIC_CHARACTERSを使用して変更できます。また、セッションの存続中の小数点文字は、ALTER SESSION文でも変更できます。現行のデフォルト小数点文字を使用していない数値を入力するには、TO_NUMBER関数を使用します。
Oracle Databaseでは、数値データが可変長形式で格納されます。それぞれの値は科学表記法で格納され、指数を格納するために1バイト、仮数を格納するために最大20バイトが使用されます。結果の数値の精度は38桁に制限されます。Oracle Databaseでは、先行ゼロと後続ゼロは格納されません。たとえば、数値412は4.12 x 102という形式で格納され、指数（2）を格納するために1バイト、仮数の3桁の有効数字（4、1、2）を格納するために2バイトが使用されます。負数の長さには、符号が含まれます。
このことを考慮に入れると、値の精度がpのとき、数値データNUMBER(p)の列データ・サイズ（バイト数）は、次の式を使用して計算できます。
ROUND((length(p)+s)/2))+1
数値が正数であればsは0（ゼロ）となり、数値が負数であればsは1となります。
0（ゼロ）および正と負の無限大（Oracle Databaseバージョン5からのインポートによってのみ生成されます）は、一意の表現形式を使用して格納します。0（ゼロ）と負の無限大は、それぞれ1バイトを必要とします。正の無限大は2バイトを必要とします。
Oracle Databaseには、浮動小数点数専用にBINARY_FLOATおよびBINARY_DOUBLEという2つの数値データ型が用意されています。この2つのデータ型は、NUMBERデータ型の基本機能をすべてサポートしています。ただし、NUMBERは10進精度を使用しますが、BINARY_FLOATおよびBINARY_DOUBLEは2進精度を使用します。これにより、算術計算が高速になり、通常は記憶域必要量が減少します。
BINARY_FLOATとBINARY_DOUBLEは、近似値データ型です。どちらにも、10進値の正確な表現ではなく近似値表現が格納されます。たとえば、BINARY_DOUBLEまたはBINARY_FLOATでは、値0.1を正確に表現できません。この2つは、通常は科学関係の計算に使用されます。両者の動作は、JavaとXMLSchemaのデータ型FLOATおよびDOUBLEに似ています。
この項の内容は、次のとおりです。
BINARY_FLOATは、32ビット単精度の浮動小数点数データ型です。BINARY_FLOAT値には、それぞれ長さを格納する1バイトを含めて5バイト必要です。
BINARY_DOUBLEは、64ビット倍精度の浮動小数点数データ型です。BINARY_DOUBLE値には、それぞれ長さを格納する1バイトを含めて9バイト必要です。
DATEデータ型には、ある時点の値（日付と時刻）が表に格納されます。DATEデータ型には、年（世紀を含む）、月、日、時、分および秒（真夜中から数える）が格納されます。
Oracle Databaseでは、ユリウス暦の西暦前4712年1月1日から西暦9999年12月31日までの日付を格納できます。BCE（書式マスクでは'BC'）が明確に指定されないかぎり、デフォルトとして日付は西暦として扱われます。
Oracle Databaseでは、日付を格納する際、独自の内部書式が使用されます。日付データは、それぞれ世紀、年、月、日、時、分および秒に対応する7バイトの固定長フィールドに格納されます。
日付の入出力に対する標準的なOracleの日付書式は、DD-MON-YYです。次に例を示します。
'13-NOV-92'
このデフォルト日付書式は、インスタンスごとにパラメータNLS_DATE_FORMATを使用して変更できます。ユーザー・セッションの存続中には、ALTER SESSION文でも変更できます。標準Oracle日付書式ではない日付を入力するには、次のように書式マスク付きのTO_DATE関数を使用してください。
TO_DATE ('November 13, 1992', 'MONTH DD, YYYY')
Oracle Databaseでは、時刻はHH:MI:SSの24時間形式で格納されます。デフォルトでは、時刻部分に何も指定しない場合、日付フィールドの時刻部分は00:00:00 A.M.（真夜中）になります。時刻のみを入力した場合、日付部分のデフォルトは現在の月の1日になります。日付の時刻部分を入力するには、次のように時刻部分を表す書式マスクを指定してTO_DATE関数を使用してください。
INSERT INTO birthdays (bname, bday) VALUES ('ANDY',TO_DATE('13-AUG-66 12:56 A.M.','DD-MON-YY HH:MI A.M.'));
この項の内容は、次のとおりです。
ユリウス日付を使用すると、共通の基準からの通算日数を算定できます。（01-01-4712（西暦前）が基準になるため、現在の日付は2,400,000辺りになります。）ユリウス日付は、通常は整数ではなく、小数部が日付部分になります。Oracle Databaseでは簡略化された方法が使用されるため、結果は整数値になります。ユリウス日付は、様々な計算方法と解釈があります。Oracle Databaseで使用する計算方法では、7桁の数値（最も一般的に使用される日付の場合）が生成されます。08-APR-93は2449086になります。
日付データをユリウス日付に変換するために、日付関数（TO_DATEまたはTO_CHAR）に書式マスク'J'を指定できます。たとえば、次の問合せはユリウス日付書式ですべての日付を戻します。
SELECT TO_CHAR (hire_date, 'J') FROM employees;
ユリウス日付を計算で使用する場合は、TO_NUMBER関数を使用する必要があります。ユリウス日付を入力する場合は、TO_DATE関数を使用できます。
INSERT INTO employees (hire_date) VALUES (TO_DATE(2448921, 'J'));
Oracle日付算術では、過去採用されてきた様々な暦の変則を考慮しています。たとえば、ユリウス暦からグレゴリウス暦への切替え（15-10-1582）では、その直前の10日間（05-10-1582から14-10-1582まで）が排除されています。0年は存在しません。
存在しない日付でもデータベースに入力できます。ただし、その日付は、日付算術では無視され、次の実在する日付として処理されます。たとえば、04-10-1582の次の日は15-10-1582で、05-10-1582の次の日も15-10-1582になります。
Oracle Databaseでは、データを世紀情報と一緒に格納します。たとえば、Oracle Databaseには、単に96または01ではなく、1996または2001が格納されます。DATEデータ型は常に4桁の年を内部に格納し、データベース内部に格納される他のすべての日付も4桁の年となります。インポート、エクスポート、リカバリなどのOracle Databaseユーティリティでも、年を4桁で処理しています。
Oracle Databaseは、サーバーのDATETIMEデータ型に対して夏時間をサポートしています。特定の地域のローカル時間に基づいて、DATETIME値を挿入および問合せできます。DATETIMEデータ型のTIMESTAMP WITH TIME ZONEおよびTIMESTAMP WITH LOCAL TIME ZONEでは、タイム・ゾーンも認識されます。
日付/時間データにタイム・ゾーンを含めることが可能です。また、小数秒をサポートしています。3つの新しいデータ型がDATEに追加されています。これらのデータ型には、表26-2に示すような違いがあります。
| データ型 | タイム・ゾーン | 小数秒 |
|---|---|---|
|
|
なし |
なし |
|
|
なし |
あり |
|
|
明示的 |
あり |
|
|
関連 |
あり |
TIMESTAMP WITH LOCAL TIME ZONEは、データベースのタイム・ゾーンで格納されます。ユーザーがデータを選択すると、値はユーザーのセッションのタイム・ゾーンに調整されます。
たとえば、サンフランシスコのデータベースは、システム・タイム・ゾーン = -8:00です。ニューヨークのクライアント（セッション・タイム・ゾーン = -5:00）が、サンフランシスコのデータベースへの挿入またはデータベースからの選択を実行すると、TIMESTAMP WITH LOCAL TIME ZONEデータが次のように調整されます。
TIMESTAMP WITH LOCAL TIME ZONE列にTIMESTAMP'1998-1-23 6:00:00-5:00'を挿入します。この挿入されたデータは、バイナリ値1998-1-23 3:00:00として、サンフランシスコのデータベースに格納されます。
'1998-1-23 6:00:00'です。
'1998-1-23 3:00:00'です。LOBデータ型BLOB、CLOB、NCLOBおよびBFILEを使用すると、非構造化データ（テキスト、グラフィック・イメージ、ビデオ・クリップおよびサウンド・ウェーブなど）の大きなブロックを、バイナリ形式または文字形式で格納し、操作できます。このデータ型を使用すると、個々のデータに対する効率的なランダム・アクセスが可能です。LONGデータ型よりも、LOBデータ型を常に使用することをお薦めします。LOB列に対して（パラレルDMLまたはDDLではない）パラレル問合せを実行できます。
LOBデータ型は、いくつかの点でLONGおよびLONG RAWデータ型と異なります。次に例を示します。
LONG列は1つしか含むことができません。
LONG列を含む表はパーティション化できません。
LONGの最大サイズは2GBです。
LONGは順次アクセスしかサポートしていません。
NCLOBを除く）をユーザー定義オブジェクト型の属性として指定できますが、LONGデータ型には指定できません。
BLOB、CLOBおよびNCLOB）は、一時表領域に作成され、表には依存しません。ただし、LONGデータ型の場合、一時構造は使用できません。
LONG列がある表はできません。
SQL文は、表にLOB列を定義し、ユーザー定義オブジェクト型にLOB属性を定義します。表内にLOBを定義するときは、各LOBについて表領域と記憶特性を明示的に指定できます。
LOBデータ型は、インライン（表の中）、アウトライン（表領域の中で、LOBロケータを使用）または外部ファイル（BFILEデータ型）のいずれかに格納できます。Oracle9i以上への互換性設定によって、LOBと一緒にSQL VARCHAR演算子およびSQL関数を使用できます。
この項の内容は、次のとおりです。
BLOBデータ型は、構造化されていないバイナリ・データをデータベースに格納します。BLOBは最大128TBのバイナリ・データを格納できます。
BLOBは、トランザクションに全面的に参加します。DBMS_LOBパッケージ、PL/SQLまたはOCIによってBLOB値に加えられる変更は、コミットまたはロールバックが可能です。ただし、BLOBロケータは、複数のトランザクションまたはセッションにまたがることはできません。
CLOBおよびNCLOBデータ型は、最大128TBの文字データをデータベースに格納します。CLOBはデータベース・キャラクタ・セットを、またNCLOBはUnicode各国語キャラクタ・セット・データを格納します。固定幅のUnicodeキャラクタ・セットで内部的に可変幅のLOBデータを格納すると、Oracle Databaseでは、CLOBおよびNCLOBへの効率的なキャラクタベースのランダム・アクセスが可能になります。
CLOBとNCLOBは、トランザクションに全面的に参加します。DBMS_LOBパッケージ、PL/SQLまたはOCIによってCLOBまたはNCLOB値に加えられる変更は、コミットまたはロールバックが可能です。ただし、CLOBおよびNCLOBロケータは複数のトランザクションやセッションにまたがることはできません。NCLOB属性を持つオブジェクト型は作成できませんが、オブジェクト型のメソッドでNCLOBパラメータを指定することはできます。
BFILEデータ型は、構造化されていないバイナリ・データを、データベースの外にあるオペレーティング・システムのファイルに格納します。BFILE列または属性は、データが含まれる外部ファイルを参照するファイル・ロケータを格納します。格納可能なBFILEデータの量は、オペレーティング・システムによって制限されます。
BFILEは読取り専用のため、変更はできません。サポートしているのはランダム読取りのみで（順次読取りはサポートしていません）、トランザクションには参加しません。基礎となるオペレーティング・システムは、BFILEについてファイルの整合性、セキュリティおよび継続性を維持する必要があります。データベース管理者は、ファイルが存在することとOracle Databaseプロセスがオペレーティング・システムの読取り権をファイルに持っていることを確認する必要があります。
RAWデータ型とLONG RAWデータ型は、Oracle Databaseが解釈しない（異なるシステム間での移動時には変換されない）データに使用します。これらのデータ型は、バイナリ・データやバイト文字列用に用意されています。たとえば、LONG RAWはグラフィックス、サウンド、文書またはバイナリ・データの配列の格納に使用できます。解釈は用途によって異なります。
RAWは、VARCHAR2文字データ型と同じく可変長のデータ型です。ただし、Oracle Net Services（ユーザー・セッションをインスタンスに接続）およびインポート/エクスポート・ユーティリティでは、RAWデータやLONG RAWデータの送信時に、文字変換は実行されません。それとは対照的に、Oracle Net ServicesとImport/Export Utilityは、データベース・キャラクタ・セットとユーザー・セッションのキャラクタ・セットが異なる場合に、これらのキャラクタ・セット間でCHARデータ、VARCHAR2データおよびLONGデータを自動的に変換します。
Oracle DatabaseがRAWまたはLONG RAWデータとCHARデータとの間の自動変換を実行する場合、バイナリ・データは16進数で表され、これらの16進文字は1文字でRAWデータ4ビット分のデータを表します。たとえば、1バイトのRAWデータのビットが11001011の場合、これは'CB'として表示および入力されます。
LONG RAWデータは索引付けできませんが、RAWデータは索引付けできます。
Oracle Databaseでは、ROWIDデータ型にデータベース内の各行のアドレス（ROWID）が格納されます。
ユニバーサルROWIDまたはUROWIDという単一のデータ型は、論理ROWIDと物理ROWIDのみでなく、ゲートウェイを介してアクセスされるOracle以外の表など、外部表のROWIDもサポートしています。
UROWIDデータ型の列には、あらゆる種類のROWIDを格納できます。UROWID列を使用するには、（ファイル形式の互換性を確保するための）COMPATIBLE初期化パラメータの値を8.1以上に設定する必要があります。
この項の内容は、次のとおりです。
Oracleデータベースのそれぞれの表は、ROWIDという名前の疑似列を内部的に持っています。SQL*PlusでSELECT * FROM...文またはDESCRIBE...文を実行して表の構造のリストを表示しても、この疑似列は表示されません。また、表には疑似列のスペースが取得されません。ただし、それぞれの行のアドレスは、予約語ROWIDを列名として使用すると、SQL問合せで取得できます。次に例を示します。
SELECT ROWID, last_name FROM employees;
ROWID疑似列の値は、INSERTまたはUPDATE文では設定できません。また、ROWIDの値は削除できません。Oracle Databaseは、索引を組み立てるために、疑似列ROWID内のROWIDの値を内部的に使用します。
ROWID疑似列のROWIDは他の表の列と同じように参照できますが（SELECT構文のリストやWHERE句で使用）、そのROWIDはデータベースに格納されているわけではなく、またそのデータベースのデータでもありません。ROWIDデータ型の列を含む表を作成することはできますが、そのような列のROWID値が有効であるかどうかは保証できません。ユーザーは、ROWID列に格納されているデータが、本当に有効なROWIDであることを確認する必要があります。
物理ROWIDは、特定の表の1行への最高速のアクセスを提供します。物理ROWIDには、1行のアドレス（特定のブロックまで）が含まれ、単一のブロック・アクセスでその行を取り出すことができます。
クラスタ化されていない表のすべての行には、行の行断片（行が複数の行断片にわたって連鎖している場合は、最初の行断片）の物理アドレスに対応する、一意のROWIDが割り当てられています。クラスタ化表の場合、同じデータ・ブロックにある異なる表の行のROWIDが同一の場合もあります。
特殊な状況では、ROWIDが行断片に割り当てられた後、ROWIDが変更される場合があります。たとえば、行の移動が可能な場合、ROWIDは、パーティション・キーの更新、フラッシュバック表の操作、表の縮小操作などのために変更される可能性があります。行の移動が無効な場合は、Oracle Databaseユーティリティを使用して行をエクスポートおよびインポートした場合にROWIDが変更される可能性があります。
物理ROWIDのデータ型は、次の2つの書式のどちらかです。
この項の内容は、次のとおりです。
拡張ROWIDは、それぞれの選択された行の物理アドレスをBASE64エンコーディングで表現したものです。エンコーディング文字は、A〜Z、a〜z、0〜9、+および/です。たとえば、次の問合せを考えます。
SELECT ROWID, last_name FROM employees WHERE department_id = 20;
次のような行情報が戻されます。
ROWID LAST_NAME ------------------ ---------- AAAAaoAATAAABrXAAA BORTINS AAAAaoAATAAABrXAAE RUGGLES AAAAaoAATAAABrXAAG CHEN AAAAaoAATAAABrXAAN BLUMBERG
拡張ROWIDの書式は、OOOOOOFFFBBBBBBRRRという4つの部分からなっています。
OOOOOO: データ・オブジェクト番号。データベース・セグメント（例ではAAAAao）を識別します。同じセグメント内のスキーマ・オブジェクト（表のクラスタなど）は、同じデータ・オブジェクト番号を持っています。
FFF: 行を含むデータファイルの表領域関連のデータファイル番号（例ではファイルAAT）。
BBBBBB: その行を含むデータ・ブロック（例ではブロックAAABrX）。ブロック番号は、表領域ではなくデータファイルに対する相対値です。このため、同じブロック番号の行が、同じ表領域の2つの異なるデータファイルに存在することもあります。
RRR: ブロック内の行。
データ・オブジェクト番号は、データ・ディクショナリ・ビューUSER_OBJECTS、DBA_OBJECTSおよびALL_OBJECTSから取得できます。たとえば、次の問合せは、SCOTTスキーマのemployees表のデータ・オブジェクト番号を戻します。
SELECT DATA_OBJECT_ID FROM DBA_OBJECTS WHERE OWNER = 'SCOTT' AND OBJECT_NAME = 'EMPLOYEES';
DBMS_ROWIDパッケージを使用して、拡張ROWIDから情報を抽出したり、ROWIDを拡張形式から制限付き形式に変換（またはその逆も）できます。
制限付きROWIDは、それぞれの選択された行の物理アドレスをバイナリで表現したものです。SQL*Plusを使用して問合せを実行すると、このバイナリ表現がVARCHAR2の16進数表現に変換されます。次のような問合せがあるとします。
SELECT ROWID, last_name FROM employees WHERE department_id = 30;
次のような行情報が戻されます。
ROWID ENAME ------------------ ---------- 00000DD5.0000.0001 KRISHNAN 00000DD5.0001.0001 ARBUCKLE 00000DD5.0002.0001 NGUYEN
前述のように、制限付きROWIDのVARCHAR2の16進数表現は、block.row.fileという3つの部分からなっています。
関数SUBSTRを使用して、ROWIDのデータをコンポーネントに分割できます。たとえば、SUBSTRを使用して拡張ROWIDを4つのコンポーネント（データベース・オブジェクト、ファイル、ブロックおよび行）に分割します。
SELECT ROWID, SUBSTR(ROWID,1,6) "OBJECT", SUBSTR(ROWID,7,3) "FIL", SUBSTR(ROWID,10,6) "BLOCK", SUBSTR(ROWID,16,3) "ROW" FROM products; ROWID OBJECT FIL BLOCK ROW ------------------ ------ --- ------ ---- AAAA8mAALAAAAQkAAA AAAA8m AAL AAAAQk AAA AAAA8mAALAAAAQkAAF AAAA8m AAL AAAAQk AAF AAAA8mAALAAAAQkAAI AAAA8m AAL AAAAQk AAI
または、SUBSTRを使用して制限付きROWIDを3つのコンポーネント（ブロック、行およびファイル）に分割します。
SELECT ROWID, SUBSTR(ROWID,15,4) "FILE", SUBSTR(ROWID,1,8) "BLOCK", SUBSTR(ROWID,10,4) "ROW" FROM products; ROWID FILE BLOCK ROW ------------------ ---- -------- ---- 00000DD5.0000.0001 0001 00000DD5 0000 00000DD5.0001.0001 0001 00000DD5 0001 00000DD5.0002.0001 0001 00000DD5 0002
ROWIDは、表データの物理的な格納に関する情報を明らかにするのに便利です。たとえば、表の行の物理的な位置を確認する場合（表のストライプ化の場合など）、次のように拡張ROWIDを問い合せると、指定の表の行がいくつのデータファイルに含まれているかがわかります。
SELECT COUNT(DISTINCT(SUBSTR(ROWID,7,3))) "FILES" FROM tablename; FILES -------- 2
Oracle Databaseでは、ROWIDを内部的に使用して索引が構築されます。索引のそれぞれのキーは、高速アクセスのために、対応する行のアドレスを指すROWIDに結び付けられています。エンド・ユーザーとアプリケーション開発者は、次のような重要な用途にROWIDを使用することもできます。
DML文の中でROWIDを使用する前に、ROWIDが変更されないことを検証して確認する必要があります。目的の行を、削除されないようにロックしてください。無効なROWIDを使用してデータを要求すると、状況によっては、文が失敗します。
また、ROWIDデータ型を使用して定義した列を持つ表を作成することもできます。たとえば、データ型ROWIDの列を持つ例外表を定義して、整合性制約に違反するデータベース行のROWIDを格納できます。ROWIDデータ型を使用して定義されている列の動作は、表の他の列と類似しています。たとえば、値を更新できます。データ型ROWIDとして定義されている列のそれぞれの値を、適切な列データとして格納するには6バイト必要です。
索引構成表の中の行は、永続的な物理アドレスを持たず、索引リーフに格納されます。挿入の結果として同一ブロック内で、または別のブロックに移動できます。したがって、物理アドレスに基づく行識別子は使用できません。かわりに、Oracleは論理行識別子を持つ索引構成表を提供します。この識別子は、表の主キーに基づいており、論理ROWIDと呼ばれます。Oracle Databaseは、これらの論理ROWIDを使用して、索引構成表の2次索引を構築します。
2次索引に使用される論理ROWIDごとに、物理推測が含まれます。これは、推測時、つまり、2次索引の作成時または再作成時に、索引構成表の中の行のブロック位置を識別するものです。
Oracle Databaseは、推測を使用して、全キー検索を回避し、リーフ・ブロックを直接プローブできます。これにより、不揮発性の索引構成表のROWIDアクセスで、通常の表の物理ROWIDアクセスに匹敵するパフォーマンスを得られることが保証されます。ただし、揮発性の表では、推測が陳腐化するとプローブが失敗することがあります。その場合は、主キー検索を実行する必要があります。
2つの論理ROWIDの値は、同じ主キー値および異なる推測を持つ場合に同一とみなされます。
この項の内容は、次のとおりです。
論理ROWIDと物理ROWIDの類似点は、次のとおりです。
ROWID疑似列を介してアクセスできます。 ROWID疑似列を使用して、索引構成表から論理ROWIDを選択できます。SELECT ROWID文は不透明構造を戻します。この構造は、表の主キーと行の物理推測（存在する場合）、およびなんらかの制御情報で内部的に構成されています。
WHERE ROWID = valueという形式の述語を使用して行にアクセスできます。この場合、valueはSELECT ROWIDから戻される不透明構造です。
UROWIDデータ型の列に格納できます。
物理ROWIDと論理ROWIDの違いの1つは、論理ROWIDを使用しても表の構成方法を表示できないことです。
行の物理位置が変化した場合、論理ROWIDは推測が含まれていても引き続き有効ですが、推測は陳腐化し、その行へのアクセスが低速になることがあります。推測情報を動的に更新することはできません。ただし、索引構成表の2次索引に対し、索引を再作成して最新の推測を取得できます。索引構成表の2次索引を再作成するには、通常の表の索引を再作成する場合とは異なり、実表を読み取る必要があるため注意してください。
Oracle Databaseで推測が不用意に使用されないように、DBMS_STATSパッケージまたはANALYZE文で索引統計を収集し、推測の陳腐化を追跡する必要があります。特に、UROWID列に推測を使用したROWIDを永続的に格納し、そのROWIDを後から取り出して行のフェッチに使用するアプリケーションの場合は、この作業が重要になります。
DBMS_STATSパッケージまたはANALYZE文を使用して索引の統計を収集すると、Oracle Databaseにより既存の推測がまだ有効かどうかがチェックされ、陳腐化した推測と有効な推測の比率がデータ・ディクショナリに記録されます。2次索引を再作成（推測を再コンパイル）した後に、索引統計を収集しなおしてください。
通常、論理ROWIDに推論が付いていない場合に、揮発性の高い表へのアクセスが最も高速になります。表が静的な場合、またはROWIDを取得してから使用するまでの時間が短いため行移動がない場合は、推測付きの論理ROWIDによるアクセスが最も高速です。
Oracle Databaseアプリケーションは、SQL*Connectを使用して、Oracle以外のデータベース・サーバーに対しても実行可能です。ROWIDの形式は、そのOracle以外のシステムの特性に応じて異なります。また、VARCHAR2の16進形式への標準変換も使用できません。プログラムでは、ROWIDデータ型を使用できます。しかし、最大256バイトまでの16進形式への非標準変換を使用する必要があります。
Oracle以外のデータベースのROWIDを、UROWIDデータ型の列に格納できます。
|
関連項目
|
表とクラスタを作成するSQL文では、ANSIデータ型と、IBM製品であるSQL/DSおよびDB2からのデータ型も使用できます。Oracle Databaseでは、Oracleデータ型名とは異なるANSIまたはIBMのデータ型名を認識し、それを列のデータ型名として記録してから、変換に基づいて、その列のデータをOracleデータ型に格納します。
Oracleには、XMLデータを処理するためのXMLTypeデータ型が用意されています。
XMLTypeは、他のユーザー定義型と同様に使用できます。XMLTypeは表やビューの列のデータ型として使用できます。XMLTypeの変数はPL/SQLストアド・プロシージャのパラメータや戻り値として使用できます。また、XMLTypeはPL/SQL、SQLやJavaで使用することも、JDBCやOCIを介して使用することも可能です。
XMLの内容を操作する便利な関数が多数用意されています。これらの関数の多くは、SQL関数およびXMLTypeのメンバー関数として提供されます。たとえば、関数extractはXMLTypeのインスタンスから特定のノードを抽出します。XMLTypeは、システム内の他のユーザー定義型と同様に、SQL問合せに使用できます。
|
関連項目
|
Uniform Resource Identifier（URI）は、一般化されたURLの一種です。URLと同様にどのようなドキュメントでも参照でき、ドキュメントの特定部分を参照できます。URIには、ドキュメントの関連部分を指定する強力なメカニズムがあるため、URLよりも一般的です。URITypeを使用すると、次の操作を実行できます。
オブジェクト型とその他のユーザー定義データ型を使用すると、アプリケーションのデータの構造と動作をモデル化するデータ型を定義できます。オブジェクト・ビューは、仮想的なオブジェクト表です。
Oracle Databaseにより、予期しているのとは異なるデータ型が与えられる場合があります。これは、Oracle Databaseで予期されたデータ型にデータを自動的に変換できる場合には許容されます。
|
 Copyright © 1993, 2008 Oracle Corporation. All Rights Reserved. |
|