11g リリース1（11.1）
E05750-03
 目次 |
 索引 |
| Oracle Database SQL言語リファレンス 11g リリース1（11.1） E05750-03 |
|
この章では、次のSQL文について説明します。
オブジェクト型はPL/SQLを使用して定義されます。このため、この項では一般的な情報について説明します。構文およびセマンティクスの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。
CREATE TYPE文を使用すると、オブジェクト型、SQLJオブジェクト型、名前付きの可変配列（VARRAY）、ネストした表型または不完全なオブジェクト型の仕様部を作成できます。CREATE TYPE文およびCREATE TYPE BODY文を使用してオブジェクト型を作成します。CREATE TYPE文では、オブジェクト型の名前、オブジェクトの属性、メソッドおよびその他のプロパティを指定します。CREATE TYPE BODY文には、その型を実装するメソッドに対するコードが含まれます。
不完全型とは、フォワード型定義によって作成される型です。このオブジェクト型には名前はありますが、属性およびメソッドがないため、不完全といわれます。他の型からの参照が可能なため、互いに参照する型の定義に使用できます。ただし、不完全オブジェクト型を使用して表やオブジェクト列またはネストした表型の列を作成する場合は、型を完全に指定しておく必要があります。
|
参照:
|
自分のスキーマ内に型を作成する場合は、CREATE TYPEシステム権限が必要です。他のユーザーのスキーマ内に型を作成する場合は、CREATE ANY TYPEシステム権限が必要です。これらの権限は、明示的に取得することもロールを介して取得することもできます。
サブタイプを作成する場合は、UNDER ANY TYPEシステム権限またはスーパータイプに対するUNDERオブジェクト権限が必要です。
型の所有者には、型定義内で参照する他のすべての型にアクセスするためのEXECUTEオブジェクト権限が必要です。または、EXECUTE ANY TYPEシステム権限が必要です。所有者は、これらの権限をロールを介して取得することはできません。
型の所有者が、型にアクセスする権限を他のユーザーに付与する場合、所有者には、参照型に対するGrant Option付きのEXECUTEオブジェクト権限、またはAdmin Option付きのEXECUTE ANY TYPEシステム権限が必要です。これらの権限がないと、型の所有者は、型にアクセスする権限を他のユーザーに付与できません。
型はPL/SQLを使用して定義されます。このため、このマニュアルの構文図ではSQLキーワードのみを示します。PL/SQLの構文、セマンティクスおよび例については、『Oracle Database PL/SQL言語リファレンス』を参照してください。
（plsql_sourceについては、『Oracle Database PL/SQL言語リファレンス』を参照してください。）
OR REPLACEを指定すると、既存の型を再作成できます。この句を指定した場合、既存の型の定義をはじめに削除しなくても、その定義を変更できます。
再作成するオブジェクト型に対する権限があらかじめ付与されている場合は、再作成後にあらためて権限を付与されなくてもそのオブジェクト型を使用および参照できます。
ファンクション索引が型に依存している場合、索引にDISABLEDのマークが付きます。
plsql_sourceの構文およびセマンティクスについては、『Oracle Database PL/SQL言語リファレンス』を参照してください。
型本体はPL/SQLを使用して定義されます。このため、この項では一般的な情報について説明します。構文およびセマンティクスの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。
CREATE TYPE BODYを使用すると、オブジェクト型仕様部で定義されたメンバー・メソッドを定義または実装することができます。CREATE TYPE文およびCREATE TYPE BODY文を使用してオブジェクト型を作成します。CREATE TYPE文では、オブジェクト型の名前、オブジェクトの属性、メソッドおよびその他のプロパティを指定します。CREATE TYPE BODY文には、その型を実装するメソッドに対するコードが含まれます。
call_specを定義していないオブジェクト型仕様部に指定された各メソッドには、オブジェクト型本体の対応するメソッド本体を指定する必要があります。
オブジェクト型用のCREATE TYPE仕様部で行われるすべてのメンバー宣言には、それに対応する構造がCREATE TYPE文またはCREATE TYPE BODY文内に存在する必要があります。
自分のスキーマ内で型本体を作成または再作成する場合は、CREATE TYPEシステム権限またはCREATE ANY TYPEシステム権限が必要です。他のユーザーのスキーマ内でオブジェクト型を作成する場合は、CREATE ANY TYPEシステム権限が必要です。他のユーザーのスキーマ内でオブジェクト型を置換する場合は、DROP ANY TYPEシステム権限が必要です。
型本体はPL/SQLを使用して定義されます。このため、このマニュアルの構文図ではSQLキーワードのみを示します。PL/SQLの構文、セマンティクスおよび例については、『Oracle Database PL/SQL言語リファレンス』を参照してください。
（plsql_sourceについては、『Oracle Database PL/SQL言語リファレンス』を参照してください。）
OR REPLACEを指定すると、既存の型本体を再作成できます。この句を指定した場合、既存の型本体の定義をはじめに削除しなくても、その定義を変更できます。
再作成されたオブジェクト型本体に対する権限を付与されているユーザーは、権限を再付与されなくても、そのオブジェクト型本体を使用および参照できます。
この句を使用した場合、ALTER TYPE ... REPLACE文によって追加された仕様部に、新規メンバー・サブプログラム定義を追加できます。
plsql_sourceの構文およびセマンティクスについては、『Oracle Database PL/SQL言語リファレンス』を参照してください。
CREATE USER文を使用すると、データベース・ユーザー（データベースにログイン可能なアカウント）を作成および構成でき、Oracle Databaseがそのユーザーによるアクセスを許可する方法が確立されます。
この文を自動ストレージ管理クラスタで発行すると、現行のノードのASMインスタンスに対してローカルなパスワード・ファイルに、ユーザーおよびパスワードの組合せを追加できます。各ノードのASMインスタンスでは、この文を使用して個々のパスワード・ファイルを更新できます。このパスワード・ファイル自体は、ORAPWDユーティリティで作成されている必要があります。
プロキシ・アプリケーションまたはアプリケーション・サーバーによって、データベースとユーザーを接続できます。構文および説明は、「ALTER USER」を参照してください。
CREATE USERシステム権限が必要です。CREATE USER文を使用して作成したユーザーの権限ドメインは空（権限を付与されていない状態）になります。Oracle Databaseにログオンするユーザーには、CREATE SESSIONシステム権限が必要です。そのため、ユーザーを作成した場合、必ずCREATE SESSIONシステム権限をそのユーザーに付与してください。詳細は、「GRANT」を参照してください。
AS SYSASMとして認証されたユーザーのみが、このコマンドを発行して、自動ストレージ管理インスタンスのパスワード・ファイルを変更できます。
（size_clause::=を参照）
作成するユーザー名を指定します。この名前には、使用しているデータベース・キャラクタ・セットの文字のみを指定できます。また、「スキーマ・オブジェクトのネーミング規則」で説明した規則に従う必要があります。データベース・キャラクタ・セットがマルチバイト文字を含んでいても、ユーザー名にはシングルバイト文字を1つ以上使用することをお薦めします。
IDENTIFIED句を使用すると、Oracle Databaseによるユーザーの認証方法を指定できます。
BY password句を使用すると、ローカル・ユーザーを作成し、データベースへのログイン時に、パスワードの指定が必要であることを指定できます。パスワードは、大/小文字が区別されます。この後に、ユーザーをデータベースに接続するために使用されるCONNECT文字列では、このCREATE USER文または後述のALTER USER文で使用されているものと同じ文字（大文字、小文字または混在）を使用してパスワードを指定する必要があります。パスワードには、データベース・キャラクタ・セットのシングルバイト文字、マルチバイト文字、特殊文字またはこれらの組合せを含めることができます。
Oracle Databaseの複雑なパスワード検証ルーチンを使用していない場合、パスワードは、「スキーマ・オブジェクトのネーミング規則」にある規則に従う必要があります。そのルーチンでは、通常のネーミング規則より複雑な文字の組合せが必要です。このルーチンは、UTLPWDMG.SQLスクリプトを使用して実装します。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
EXTERNALLYを指定すると、外部ユーザーを作成できます。このユーザーは、外部サービス（オペレーティング・システムやサード・パーティのサービスなど）で認証する必要があります。その場合、オペレーティング・システムまたはサード・パーティ・サービスによる認証を使用して、特定の外部ユーザーが特定のデータベース・ユーザーへのアクセス権を所有することが可能になります。
この句はSSL認証の外部ユーザーに必須で、そのユーザーに対してのみ使用されます。certificate_DNは、ユーザーのウォレット内のユーザーのPKI証明書にある識別名です。
GLOBALLY句を使用すると、グローバル・ユーザーを作成することができます。このユーザーは、エンタープライズ・ディレクトリ・サービス（Oracle Internet Directory）によって認可される必要があります。
directory_DN文字列は、次のいずれかの形式になります。
CN=username,other_attributesという形式である必要があります。other_attributesは、ディレクトリ内のユーザーの識別名（DN）以外の部分です。この形式では、プライベート・グローバル・スキーマが作成されます。
GLOBALLYキーワードのみを指定するのと同じで、共有グローバル・スキーマが作成されます。
特定のユーザーとして接続し、ALTER USER文を使用してユーザーのロールをアクティブにするために、アプリケーション・サーバーの機能を制御できます。
ユーザーが作成するオブジェクトを格納するデフォルトの表領域を指定します。この句を省略した場合、ユーザーのオブジェクトはデータベースのデフォルトの表領域に格納されます。データベースのデフォルトの表領域が指定されていない場合、ユーザーのオブジェクトはSYSTEM表領域に格納されます。
ローカル管理の一時表領域（UNDO表領域を含む）またはディクショナリ管理の一時表領域は、ユーザーのデフォルトの表領域として指定できません。
|
参照:
|
ユーザーの一時セグメントが確保される表領域または表領域グループを指定します。この句を省略した場合、ユーザーの一時セグメントはデータベースのデフォルトの一時表領域に格納されます。データベースのデフォルトの一時表領域が指定されていない場合は、SYSTEM表領域に格納されます。
この句には、次の制限事項があります。
参照:
QUOTA句を使用すると、ユーザーが表領域内に割り当てることができる最大サイズを指定できます。
CREATE USER文では、複数の表領域に対して複数のQUOTA句を指定できます。
UNLIMITEDを使用すると、ユーザーは、表領域の領域を無制限に割り当てることができます。
この句は、一時表領域には指定できません。
ユーザーに割り当てるプロファイルを指定します。このプロファイルによって、ユーザーが使用できるデータベース・リソース容量が制限されます。この句を省略した場合、DEFAULTプロファイルがユーザーに割り当てられます。
PASSWORD EXPIREを指定すると、ユーザーのパスワードを期限切れにできます。この設定によって、ユーザーがデータベースにログインする前に、ユーザーまたはDBAはパスワードの変更が必要となります。
ACCOUNT LOCKを指定すると、ユーザー・アカウントをロックし、アクセスを禁止できます。ACCOUNT UNLOCKを指定すると、ユーザー・アカウントのロックを解除し、アカウントへのアクセスを許可できます。
次のすべての例では、example表領域を使用します。この表領域はシード・データベースに存在し、サンプル・スキーマにアクセス可能です。
PASSWORD EXPIREを指定して新規ユーザーを作成する場合、データベースにログインする前に、そのユーザーのパスワードを変更する必要があります。次の文は、sidneyユーザーを作成します。
CREATE USER sidney IDENTIFIED BY out_standing1 DEFAULT TABLESPACE example QUOTA 10M ON example TEMPORARY TABLESPACE temp QUOTA 5M ON system PROFILE app_user PASSWORD EXPIRE;
前述のユーザーsidneyには次の特性があります。
out_standing1
example
temp
SYSTEMへのアクセス
app_user（「プロファイルの作成例:」で作成）によって定義されているデータベース・リソースの制限
sidneyがデータベースにログインする前に変更する必要がある期限切れのパスワード
次の例は、データベースにアクセスする前に外部ソースによって識別される必要のある、外部ユーザーを作成します。
CREATE USER app_user1 IDENTIFIED EXTERNALLY DEFAULT TABLESPACE example QUOTA 5M ON example PROFILE app_user;
ユーザーapp_user1には次の追加の特性があります。
example
example
exampleに5MBの領域、およびデータベースの一時表領域に無制限の割当て
app_userによって定義されているデータベース・リソースの制限
オペレーティング・システム・アカウントによってのみアクセス可能な別のユーザーを作成する場合、ユーザー名に初期化パラメータOS_AUTHENT_PREFIX値の接頭辞を付けます。たとえば、この値が「ops$」の場合、次の文を使用して、外部で識別されるユーザーexternal_userを作成できます。
CREATE USER ops$external_user IDENTIFIED EXTERNALLY DEFAULT TABLESPACE example QUOTA 5M ON example PROFILE app_user;
次の例は、グローバル・ユーザーを作成します。グローバル・ユーザーを作成する場合、エンタープライズ・ディレクトリ・サーバーでユーザーを識別するX.509の名前を指定することができます。
CREATE USER global_user IDENTIFIED GLOBALLY AS 'CN=analyst, OU=division1, O=oracle, C=US' DEFAULT TABLESPACE example QUOTA 5M ON example;
CREATE VIEW文を使用すると、ビューを定義できます。ビューは論理表で、1つ以上の表またはビューがベースとなります。ビューにデータそのものが格納されているわけではありません。ビューの基礎になる表を実表といいます。
LOB、オブジェクト型、REFデータ型、ネストした表またはVARRAY型をサポートするオブジェクト・ビューまたはリレーショナル・ビューを、既存のビュー・メカニズムで作成することもできます。オブジェクト・ビューとは、ユーザー定義型のビューのことで、ビューの各行に、それぞれが一意のオブジェクト識別子を持つオブジェクトが含まれます。
XMLTypeビューも作成できます。このビューは、オブジェクト・ビューと似ていますが、XMLTypeのXML Schemaベースの表のデータを表示します。
|
参照:
|
自分のスキーマ内にビューを作成する場合は、CREATE VIEWシステム権限が必要です。他のユーザーのスキーマ内にビューを作成する場合は、CREATE ANY VIEWシステム権限が必要です。
サブビューを作成する場合は、UNDER ANY VIEWシステム権限またはスーパービューに対するUNDERオブジェクト権限が必要です。
ビューが含まれているスキーマの所有者は、そのビューの基礎となっているすべての表またはビューに対する行の選択、挿入、更新または削除の権限が必要です。また、所有者には、これらの権限がロールを介してではなく、直接付与されている必要があります。
オブジェクト・ビューの作成時にオブジェクト型の基本コンストラクタ・メソッドを使用する場合、次のいずれかの条件を満たしている必要があります。
（inline_constraint::=、out_of_line_constraint::=、object_view_clause::=、XMLType_view_clause::=、subquery::=（SELECT構文の一部）、subquery_restriction_clause::=を参照）
（inline_constraint::=およびout_of_line_constraint::=を参照）
OR REPLACEを指定すると、既存のビューを再作成できます。この句を使用した場合、以前に付与されたオブジェクト権限を削除、再作成、再付与しなくても、既存のビュー定義を変更できます。
ビューを再作成した場合、ビュー内で定義されたINSTEAD OFトリガーが削除されます。
すべてのマテリアライズド・ビューがviewに依存している場合、そのマテリアライズド・ビューにはUNUSABLEというマークが付けられ、それらが再利用可能になるようにリストアする場合は、完全なリフレッシュが必要になります。無効なマテリアライズド・ビューはクエリー・リライトで使用されることはなく、また、再コンパイルされるまでリフレッシュされません。
|
参照:
|
FORCEを指定すると、ビューの実表または参照するオブジェクト型が存在しているか、またはそのビューを含むスキーマの所有者が、それらの表やオブジェクト型に対する権限を持っているかにかかわらず、ビューを作成できます。SELECT、INSERT、UPDATEまたはDELETE文をビューに対して発行する場合、これらの条件を満たしている必要があります。
ビュー定義が制約を含む場合、実表または参照するオブジェクト型が存在しないと、CREATE VIEW ... FORCEは正常に実行されません。また、ビュー定義で存在しない制約が指定される場合も、CREATE VIEW ... FORCEは正常に実行されません。
NOFORCEを指定すると、実表が存在し、ビューを含むスキーマの所有者がその実表に対する権限を持っている場合のみ、ビューを作成できます。これはデフォルトです。
ビューを含めるスキーマを指定します。schemaを指定しない場合、自分のスキーマにそのビューが作成されます。
ビューまたはオブジェクト・ビューの名前を指定します。
あるビューにINSTEAD OFトリガーが含まれている場合、そのビューで作成されるビューが更新可能であっても、そのビューにはINSTEAD OFトリガーが必要です。
ビューを定義する問合せによって選択された式の名前を指定します。別名の数は、ビューによって選択された式の数と一致している必要があります。別名は、Oracle Databaseのスキーマ・オブジェクトのネーミング規則に従う必要があります。別名は、ビュー内で一意である必要があります。
別名を省略した場合、別名は問合せの列または列の別名から導出されます。このため、問合せに列の名前のみでなく式が含まれている場合は、別名を使用する必要があります。また、ビュー定義に制約が含まれている場合も、別名を指定する必要があります。
オブジェクト・ビューの作成時に別名は指定できません。
ビューおよびオブジェクト・ビューには制約を指定できます。out_of_line_constraint句を使用すると、ビュー・レベルで制約を定義できます。適切な別名の後でinline_constraint句を使用すると、列定義または属性定義の一部として制約を定義できます。
Oracle Databaseでは、ビュー制約を適用していません。制限事項を含むビュー制約の詳細は、「ビュー制約」を参照してください。
object_view_clauseを使用すると、オブジェクト型にビューを定義できます。
この句を使用すると、type_name型のオブジェクト・ビューを明示的に作成できます。オブジェクト・ビューの列は、type_name型の最上位属性に対応しています。各行にはオブジェクト・インスタンスが含まれ、また、各インスタンスはWITH OBJECT IDENTIFIER句で指定したオブジェクト識別子に関連付けられます。schemaを指定しない場合、自分のスキーマ内にオブジェクト・ビューが作成されます。
オブジェクト表、XMLType表、オブジェクト・ビューおよびXMLTypeビューには、列名は付けられません。そのため、システム生成疑似列OBJECT_IDが定義されます。問合せでこの列名を使用し、WITH OBJECT IDENTIFIER句を指定して、オブジェクト・ビューを作成できます。
WITH OBJECT IDENTIFIER句を使用すると、最上位（ルート）のオブジェクト・ビューを指定できます。オブジェクト・ビュー内の各行を識別するためのキーとして使用されるオブジェクト型の属性を指定します。ほとんどの場合、各属性は実表の主キー列と対応します。属性リストが一意で、ビューの1行ずつを識別することを確認する必要があります。
オブジェクト・ビューには、次の制限事項があります。
REFを参照解除または確保しようとした場合、データベースはエラーを戻します。
オブジェクト・ビューがオブジェクト表またはオブジェクト・ビュー上で定義されている場合は、この句を省略するか、またはDEFAULTを指定します。
DEFAULTを指定すると、基礎となるオブジェクト表またはオブジェクト・ビュー固有のオブジェクト識別子を使用して、各行を一意に識別できます。
オブジェクト・ビューに対して作成されるオブジェクト識別子の基になるオブジェクト型の属性を指定します。
UNDER句を使用すると、オブジェクト・スーパービューに基づくサブビューを指定できます。
サブビューには、次の制限事項があります。
type_nameは、superview直属のサブタイプである必要があります。
ビューの基になっている表（実表）の列と行を識別する副問合せを指定します。副問合せのSELECT構文のリストには1000以下の式を指定できます。
リモート表およびリモート・ビューを参照するビューを作成する場合、CREATE DATABASE LINK文のCONNECT TO句を使用して、指定するデータベース・リンクを作成しておく必要があります。また、ビュー副問合せのスキーマ名で修飾する必要があります。
ビューを定義する問合せでflashback_query_clauseを使用してビューを作成した場合、AS OF式は作成時には解析されず、ユーザーがビューを問い合せるたびに解析されます。
ビュー問合せには、次の制限事項があります。
CURRVALおよびNEXTVAL疑似列を選択できません。
ROWID、ROWNUMまたはLEVELの各疑似列を選択する場合、そのビュー副問合せには列の別名が必要です。
CREATE OR REPLACE VIEW文を発行してビューを再作成するまで、追加した列はそのビューに含まれません。
SAMPLE句は指定できません。
subquery_restriction_clauseも指定する場合は、副問合せでORDER BY句を指定できません。
これらの制限は、マテリアライズド・ビューにも適用されます。
更新可能なビューには、次の注意事項があります。
更新可能なビューとは、実表の行を挿入、更新または削除できるビューです。更新可能なビューを作成するか、またはビューにINSTEAD OFトリガーを作成して更新可能にすることができます。
更新可能なビューの列を更新する方法を確認するには、USER_UPDATABLE_COLUMNSデータ・ディクショナリ・ビューを問い合せます。このビューで表示される情報は、更新可能なビューのみに意味があります。ビューを更新可能にするには、次の条件が満たされている必要があります。
TABLE句の出力にマップする場合（コレクション・ネスト解除）、ビューは更新可能ではありません。
DISTINCT演算子
GROUP BY、ORDER BY、MODEL、CONNECT BYまたはSTART WITH句
SELECT構文のリストにあるコレクション式
SELECT構文のリストにある副問合せ
WITH READ ONLYが指定された副問合せ
UPDATE文を使用して、実表の行を更新できません。
DELETE文の場合、結合によって複数のキー保存表が作成されると、ビューがWITH CHECK OPTIONを指定して作成されたかどうかにかかわらず、FROM句に指定された最初の表から削除されます。
参照:
INSTEAD OFトリガーの例については、『Oracle Database PL/SQL言語リファレンス』のを参照してください。
この句を使用すると、XMLTypeビューを作成できます。このビューには、XMLTypeのXML Schemaベースの表のデータが表示されます。XMLSchema_specは、XMLデータを対応するオブジェクト・リレーショナル・データにマップするために使用するXML Schemaを示します。XML Schemaは、XMLTypeビューを作成する前に作成しておく必要があります。
オブジェクト表、XMLType表、オブジェクト・ビューおよびXMLTypeビューには、列名は付けられません。そのため、システム生成疑似列OBJECT_IDが定義されます。問合せでこの列名を使用し、WITH OBJECT IDENTIFIER句を指定して、オブジェクト・ビューを作成できます。
|
参照:
|
subquery_restriction_clauseを使用すると、次のいずれかの方法で、ビューを定義する問合せを制限できます。
WITH READ ONLYを指定すると、表またはビューを更新禁止にできます。
WITH CHECK OPTIONを指定すると、副問合せに含まれない行を生成する表またはビューの変更を禁止できます。この句をDML文の副問合せ内で使用する場合、FROM句内の副問合せには指定できますが、WHERE句内の副問合せには指定できません。
CHECK OPTION制約の名前を指定します。この識別子を省略した場合、その制約にSYS_Cnという形式の名前が自動的に割り当てられます。この場合のnは、その制約名をデータベース内で一意の名前にする整数です。
ORDER BY句を指定した場合、この句は指定できません。
次の文は、サンプル表employeesのemp_viewという名前のビューを作成します。このビューには、部門20の従業員とその年間給与が表示されます。
CREATE VIEW emp_view AS SELECT last_name, salary*12 annual_salary FROM employees WHERE department_id = 20;
この場合、副問合せで式salary*12に列の別名（annual_salary）を使用しているため、この式に基づく列の名前をビュー宣言で定義する必要はありません。
次の文は、サンプル表hr.employeesの制限付きのビューを作成し、ビューの列emailに一意制約を定義し、ビューの列emp_idにビューに対する主キー制約を定義します。
CREATE VIEW emp_sal (emp_id, last_name, email UNIQUE RELY DISABLE NOVALIDATE, CONSTRAINT id_pk PRIMARY KEY (emp_id) RELY DISABLE NOVALIDATE) AS SELECT employee_id, last_name, email FROM employees;
次の文は、employees表内の事務員全員の更新可能なビューclerkを作成します。従業員のID、姓、部門番号および職種はビューで参照でき、事務員の行のこれらの列のみを更新できます。
CREATE VIEW clerk AS SELECT employee_id, last_name, department_id, job_id FROM employees WHERE job_id = 'PU_CLERK' or job_id = 'SH_CLERK' or job_id = 'ST_CLERK';
このビューでは、購買係のjob_idを購買マネージャ（PU_MAN）に変更できます。
UPDATE clerk SET job_id = 'PU_MAN' WHERE employee_id = 118;
次の例は、同じビューをWITH CHECK OPTION付きで作成します。新しい従業員が事務員ではない場合は、clerkに新しい行を挿入できません。従業員のjob_idを他の事務タイプに更新できますが、事務員以外のjob_idの場合はビューがemployeesにアクセスできないため、正常に更新できません。
CREATE VIEW clerk AS SELECT employee_id, last_name, department_id, job_id FROM employees WHERE job_id = 'PU_CLERK' or job_id = 'SH_CLERK' or job_id = 'ST_CLERK' WITH CHECK OPTION;
結合ビューは、結合を含むビューの副問合せを持つビューです。副問合せの結合において、一意索引を持つ列が1列以上ある場合、結合ビューで1つの実表を変更できます。結合ビューの中の列が更新可能であるかどうかは、USER_UPDATABLE_COLUMNSを問い合せることでわかります。たとえば、次のようになります。
CREATE VIEW locations_view AS SELECT d.department_id, d.department_name, l.location_id, l.city FROM departments d, locations l WHERE d.location_id = l.location_id; SELECT column_name, updatable FROM user_updatable_columns WHERE table_name = 'LOCATIONS_VIEW' ORDER BY column_name, updatable; COLUMN_NAME UPD ------------------------------ --- DEPARTMENT_ID YES DEPARTMENT_NAME YES LOCATION_ID NO CITY NO
前述の例では、locations表のlocation_id列に対する主キー索引は、locations_viewビュー内で一意ではありません。そのため、locationsはキー保存表ではなく、その実表の列は更新できません。
INSERT INTO locations_view VALUES (999, 'Entertainment', 87, 'Roma'); INSERT INTO locations_view VALUES * ERROR at line 1: ORA-01776: cannot modify more than one base table through a join view
departments表にマップするビュー内のすべての列に更新可能のマークが付けられていて、departmentsの主キーがビューに保持されているため、departments実表に対して、行の挿入、更新または削除を実行できます。
INSERT INTO locations_view (department_id, department_name) VALUES (999, 'Entertainment'); 1 row created.
次の文は、oe.customers表のcustomer_roという名前の読取り専用ビューを作成します。顧客の姓、言語、掛貸限度額のみがこのビューで参照できます。
CREATE VIEW customer_ro (name, language, credit) AS SELECT cust_last_name, nls_language, credit_limit FROM customers WITH READ ONLY;
次の例では、ocスキーマ内でのinventory_typ型の作成方法、およびその型を基にしたoc_inventoriesビューの作成方法を示します。
CREATE TYPE inventory_typ OID '82A4AF6A4CD4656DE034080020E0EE3D' AS OBJECT ( product_id NUMBER(6) , warehouse warehouse_typ , quantity_on_hand NUMBER(8) ) ; / CREATE OR REPLACE VIEW oc_inventories OF inventory_typ WITH OBJECT OID (product_id) AS SELECT i.product_id, warehouse_typ(w.warehouse_id, w.warehouse_name, w.location_id), i.quantity_on_hand FROM inventories i, warehouses w WHERE i.warehouse_id=w.warehouse_id;
次の例は、XMLType表xwarehouses（「例」で作成）の通常のビューを作成します。
CREATE VIEW warehouse_view AS SELECT VALUE(p) AS warehouse_xml FROM xwarehouses p;
このビューからは、次のように選択します。
SELECT e.warehouse_xml.getclobval() FROM warehouse_view e WHERE EXISTSNODE(warehouse_xml, '//Docks') =1;
オブジェクト・リレーショナル表に、XMLTypeビューを作成する場合もあります。次の例は、サンプル表oe.warehouses内のXMLType列warehouse_specと同様のオブジェクト・リレーショナル表を作成し、その表のXMLTypeビューを作成します。
CREATE TABLE warehouse_table ( WarehouseID NUMBER, Area NUMBER, Docks NUMBER, DockType VARCHAR2(100), WaterAccess VARCHAR2(10), RailAccess VARCHAR2(10), Parking VARCHAR2(20), VClearance NUMBER ); INSERT INTO warehouse_table VALUES(5, 103000,3,'Side Load','false','true','Lot',15); CREATE VIEW warehouse_view OF XMLTYPE XMLSCHEMA "http://www.example.com/xwarehouses.xsd" ELEMENT "Warehouse" WITH OBJECT ID (extract(OBJECT_VALUE, '/Warehouse/Area/text()').getnumberval()) AS SELECT XMLELEMENT("Warehouse", XMLFOREST(WarehouseID as "Building", area as "Area", docks as "Docks", docktype as "DockType", wateraccess as "WaterAccess", railaccess as "RailAccess", parking as "Parking", VClearance as "VClearance")) FROM warehouse_table;
このビューは、次のように問い合せます。
SELECT VALUE(e) FROM warehouse_view e;
DELETE文を使用すると、次の表から行を削除できます。
表から行を削除する場合、その表が自分のスキーマ内にある必要があります。自分のスキーマ内にない場合は、その表に対するDELETEオブジェクト権限が必要です。
更新可能なマテリアライズド・ビューから行を削除する場合、そのマテリアライズド・ビューが自分のスキーマ内にある必要があります。自分のスキーマ内にない場合は、そのマテリアライズド・ビューに対するDELETEオブジェクト権限が必要です。
ビューの実表から行を削除する場合、そのビューが含まれるスキーマの所有者には、その実表に対するDELETEオブジェクト権限が必要です。また、他のスキーマ内にビューが存在している場合は、そのビューに対するDELETEオブジェクト権限が必要です。
DELETE ANY TABLEシステム権限を持っている場合、任意の表、表パーティションまたは任意のビューの実表から行を削除できます。
次の場合は、削除するオブジェクトに対するSELECTオブジェクト権限も必要です。
表のファンクション索引が無効な状態にあるとき、表から行を削除できません。まず、ファクション索引を検証する必要があります。
（DML_table_expression_clause::=、where_clause::=、returning_clause::=、error_logging_clause::=を参照）
（partition_extension_clause::=、subquery::=、subquery_restriction_clause::=、table_collection_expression::=を参照）
文の実行計画を選択する場合に、オプティマイザに指示を与えるためのコメントを指定します。
FROM句を使用すると、行を削除するデータベース・オブジェクトを指定できます。
ONLY構文は、ビューのみに関連します。FROM句のビューがビューの階層に属し、そのいずれのサブビューからも行を削除しない場合は、ONLY句を使用します。
この句を使用すると、データを削除するオブジェクトを指定できます。
表またはビューが含まれているスキーマを指定します。schemaを指定しない場合、表またはビューは自分のスキーマにあるとみなされます。
行を削除する表、ビュー、マテリアライズド・ビュー、列または副問合せの結果の列の名前を指定します。
更新可能なビューから行を削除すると、実表から行が削除されます。
読取り専用マテリアライズド・ビューからは行を削除できません。書込み可能なマテリアライズド・ビューから行を削除する場合、基礎となるコンテナ表から行が削除されます。ただし、その削除は次のリフレッシュ操作で上書きされます。マテリアライズド・ビュー・グループ内の更新可能なマテリアライズド・ビューから行を削除する場合、マスター表の対応する行も削除されます。
table、viewの実表またはmaterialized_viewのマスター表に、1列以上のドメイン索引列が含まれる場合は、この文によって適切な索引タイプの削除ルーチンが実行されます。
表に対してDELETE文を実行すると、その表に定義されているDELETEトリガーが起動されます。
行の削除によって解放される表や索引のすべての領域は、表および索引によって引き続き保持されます。
オブジェクト内にある削除対象のパーティションまたはサブパーティションの名前またはパーティション・キー値を指定します。
パーティション・オブジェクトから値を削除する場合、そのパーティション名を指定する必要はありません。ただし、パーティション名を指定した方が、複雑なwhere_clauseより効率が上がることがあります。
オブジェクトが格納されているリモート・データベースへのデータベース・リンクの完全名または部分名を指定します。Oracle Databaseの分散機能を使用している場合にのみ、リモート・オブジェクトから行を削除できます。
dblinkを省略した場合、オブジェクトがローカル・データベース上にあるとみなされます。
subquery_restriction_clauseを使用すると、次のいずれかの方法で副問合せを制限できます。
WITH READ ONLYを指定すると、表またはビューを更新禁止にできます。
WITH CHECK OPTIONを指定すると、副問合せに含まれない行を生成する表またはビューの変更を禁止できます。この句をDML文の副問合せ内で使用する場合、FROM句内の副問合せには指定できますが、WHERE句内の副問合せには指定できません。
CHECK OPTION制約の名前を指定します。この識別子を省略した場合、その制約にSYS_Cnという形式の名前が自動的に割り当てられます。この場合のnは、その制約名をデータベース内で一意の名前にする整数です。
table_collection_expressionを使用すると、問合せおよびDML操作で、collection_expression値を表として扱うことができます。collection_expressionには、副問合せ、列、ファンクションまたはコレクション・コンストラクタのいずれかを指定できます。その形式にかかわらず、集合値（ネストした表型またはVARRAY型の値）を戻す必要があります。このようなコレクションの要素抽出プロセスをコレクション・ネスト解除といいます。
TABLE式を親表と結合する場合は、オプションのプラス（+）には大きな意味があります。+を指定すると、その2つの外部結合が作成され、コレクション式がNULLの場合でも、外部表の行が問合せで戻されるようになります。
相関副問合せでtable_collection_expressionを使用すると、他の表に存在する値で行を削除できます。
削除するオブジェクトからネストした表の列を選択する副問合せを指定します。
この句には、次の制限事項があります。
viewまたはmaterialized_viewのtable（実表またはマスター表）にIN_PROGRESSまたはFAILEDのマークが付いたドメイン索引がある場合、この文は実行できません。
UNUSABLEとマークされている場合は、パーティションに挿入できません。
DML_table_expression_clauseの副問合せでは、ORDER BY句を指定できません。
INSTEAD OFトリガーを使用する場合を除いて、ビューから行を削除できません。
DISTINCT演算子
GROUP BY、ORDER BY、MODEL、CONNECT BYまたはSTART WITH句
SELECT構文のリストにあるコレクション式
SELECT構文のリストにある副問合せ
WITH READ ONLYが指定された副問合せ
UNUSABLEのマークが付いている索引、索引パーティションまたは索引サブパーティションを指定する場合、SKIP_UNUSABLE_INDEXES初期化パラメータがtrueに設定されていないかぎり、DELETE文は正常に実行されません。
where_clauseを使用すると、条件を満たす行のみを削除できます。この条件は、行を削除するオブジェクトを参照したり、副問合せを含むことができます。Oracle Databaseの分散機能を使用している場合にのみ、リモート・オブジェクトから行を削除できます。conditionの構文は、第7章「条件」を参照してください。
この句がリモート・オブジェクトを参照するsubqueryを含む場合、参照がローカル・データベース上でオブジェクトにループバックしないかぎり、DELETEはパラレルで実行されます。ただし、DML_table_expression_clauseのsubqueryがリモート・オブジェクトを参照する場合は、DELETE操作はシリアルで実行されます。詳細は、「CREATE TABLE」の「parallel_clause」を参照してください。
dblinkを省略した場合、表またはビューがローカル・データベース上にあるとみなされます。
where_clauseを省略した場合、オブジェクトのすべての行が削除されます。
文中で参照する表、ビュー、マテリアライズド・ビュー、副問合せまたはコレクション値の相関名を指定します。DML_table_expression_clauseがいずれかのオブジェクト型属性またはオブジェクト型メソッドを参照する場合、この別名が必要です。通常、別名は相関問合せを持つDELETE文で使用されます。
この句を使用すると、削除された列から値を戻すことができるため、DELETE文の後でSELECTを実行する必要がなくなります。
この句を使用すると、DML文に影響される行を取り出すことができます。この句は、表、マテリアライズド・ビュー、および単一の実表を持つビューに指定できます。
returning_clauseを指定したDML文を単一行に実行すると、影響された行、ROWID、および処理された行へのREFを使用している列式が取り出され、ホスト変数またはPL/SQL変数に格納されます。
returning_clauseを指定したDML文を複数行に実行すると、式の値、ROWIDおよび処理された行に関連するREFがバインド配列に格納されます。
exprリストの各項目は、適切な構文で表す必要があります。
INTO句を指定すると、変更された行の値を、data_itemリストに指定する変数に格納できます。
取り出されたexpr値を格納するホスト変数またはPL/SQL変数を指定します。
RETURNINGリストの各式については、INTOリストに、対応する型に互換性があるPL/SQL変数またはホスト変数を指定する必要があります。
RETURNING句には、次の制限事項があります。
exprに次の制限事項があります。
exprリストに主キー列またはその他のNOT NULL列が含まれている場合、表にBEFORE UPDATEトリガーが定義されていると、UPDATE文は正常に実行されません。
returning_clauseを指定できません。
LONG型を取り出すことはできません。
INSTEAD OFトリガーが定義されたビューに対して指定することはできません。
参照:
COLLECT句を使用してコレクション変数に複数の値を戻す場合は、『Oracle Database PL/SQL言語リファレンス』を参照してください。
error_logging_clauseのDELETE文での動作は、INSERT文の場合と同じです。詳細は、「INSERT」文の「error_logging_clause」を参照してください。
次の文は、language_id列の値がARの、サンプル表oe.product_descriptionsからすべての行を削除します。
DELETE FROM product_descriptions WHERE language_id = 'AR';
次の文は、サンプル表hr.employeesから歩合率が10%未満の購買係を削除します。
DELETE FROM employees WHERE job_id = 'SA_REP' AND commission_pct < .2;
次の文は前述の例と同じ結果を表しますが、副問合せを使用します。
DELETE FROM (SELECT * FROM employees) WHERE job_id = 'SA_REP' AND commission_pct < .2;
次の文は、データベース・リンクremoteによってアクセス可能なデータベースの、ユーザーhrが所有するlocations表から指定した行を削除します。
DELETE FROM hr.locations@remote WHERE location_id > 3000;
ネストした表の行の削除例は、「表のコレクション例:」を参照してください。
次の例は、sh.sales表のパーティションsales_q1_1998から行を削除します。
DELETE FROM sales PARTITION (sales_q1_1998) WHERE amount_sold > 1000;
次の例は、削除された行からsalary列を戻し、その結果をバインド配列:bnd1に格納します。バインド配列は事前に宣言しておく必要があります。
DELETE FROM employees WHERE job_id = 'SA_REP' AND hire_date + TO_YMINTERVAL('01-00') < SYSDATE RETURNING salary INTO :bnd1;
DISASSOCIATE STATISTICS文を使用すると、デフォルトの統計情報または統計タイプと、列、スタンドアロン・ファンクション、パッケージ、型、ドメイン索引または索引タイプとの関連付けを解除できます。
この文を発行する場合は、基礎となる表、ファンクション、パッケージ、型、ドメイン索引または索引タイプを変更する適切な権限が必要です。
統計との関連付けを解除する1つ以上の列、スタンドアロン・ファンクション、パッケージ、型、ドメイン索引または索引タイプを指定します。
schemaを指定しない場合、オブジェクトは自分のスキーマ内にあるとみなされます。
オブジェクトのユーザー定義の統計情報を収集する場合、FORCEを指定しないかぎり文は実行されません。
FORCEを指定すると、統計タイプを使用するオブジェクトの統計情報の有無にかかわらず、関連付けが解除されます。統計情報が存在する場合、関連付けが解除される前にその統計情報は削除されます。
次の文は、emp_mgmtパッケージと統計情報の関連付けを解除します。hrスキーマにこのパッケージを作成する例については、『Oracle Database PL/SQL言語リファレンス』を参照してください。
DISASSOCIATE STATISTICS FROM PACKAGES hr.emp_mgmt;
DROP CLUSTER文を使用すると、データベースからクラスタを削除できます。
個々の表は非クラスタ化できません。そのかわり、次の手順を実行します。
CLUSTER句なしで作成します。
RENAME文を使用して、新しい表に既存の表の名前を指定します。
削除するクラスタが自分のスキーマ内にある必要があります。自分のスキーマ内にない場合は、DROP ANY CLUSTERシステム権限が必要です。
クラスタが含まれているスキーマを指定します。schemaを指定しない場合、クラスタは自分のスキーマ内にあるとみなされます。
削除するクラスタの名前を指定します。クラスタを削除するとクラスタの索引も削除され、その索引のデータ・ブロックを含むクラスタ領域が表領域に戻されます。
INCLUDING TABLESを指定すると、クラスタに属するすべての表を削除できます。
CASCADE CONSTRAINTSを指定すると、クラスタに含まれる表の主キーまたは一意キーを参照するクラスタ外の表から、すべての参照整合性制約を削除できます。このような参照整合性制約があるときにこの句の指定を省略した場合、エラーが戻され、クラスタは削除されません。
次の文は、クラスタ（「CREATE CLUSTER」の「例」で作成）を削除します。
次の文は、languageクラスタを削除します。
DROP CLUSTER language;
次の文は、dept_10、dept_20およびこれらの表の主キーまたは一意キーを参照する参照整合性制約とともにpersonnelクラスタを削除します。
DROP CLUSTER personnel INCLUDING TABLES CASCADE CONSTRAINTS;
DROP CONTEXT文を使用すると、データベースからコンテキスト・ネームスペースを削除できます。
コンテキスト・ネームスペースを削除した場合でも、ユーザー・セッションに設定されたネームスペースのコンテキストは無効になりません。ただし、ユーザーがそのコンテキストを設定しようとした場合、そのコンテキストは無効になります。
DROP ANY CONTEXTシステム権限が必要です。
削除するコンテキスト・ネームスペースの名前を指定します。組込みネームスペースUSERENVは削除できません。
次の文は、コンテキスト（「CREATE CONTEXT」で作成）を削除します。
DROP CONTEXT hr_context;
DROP DATABASE文を使用すると、データベースを削除できます。この文は、テスト・データベースを削除したり、新しいホストへの移行が完了した後に古いデータベースを削除する場合に便利です。
この文を発行するには、SYSDBAシステム権限が必要です。データベースは、排他モードおよび制限モードでマウントされている必要があります。また、データベースはクローズ状態である必要があります。
この文を発行すると、データベースを削除し、すべての制御ファイル、およびその制御ファイルに記述されているデータ・ファイルを削除できます。サーバー・パラメータ・ファイル（SPFILE）を使用している場合は、それも削除されます。
アーカイブ・ログおよびバックアップは削除されません。これらを削除するには、Recovery Managerを使用します。データベースがRAWディスク上に存在する場合、この文では実際のRAWディスクの特殊ファイルは削除されません。
DROP DATABASE LINK文を使用すると、データベースからデータベース・リンクを削除できます。
プライベート・データベース・リンクは自分のスキーマにある必要があります。パブリック・データベース・リンクを削除する場合は、DROP PUBLIC DATABASE LINKシステム権限が必要です。
PUBLICを指定すると、パブリック・データベース・リンクを削除できます。
削除するデータベース・リンクの名前を指定します。
他のユーザーのスキーマ内のデータベース・リンクは削除できません。また、データベース・リンク名ではピリオドが許可されるため、スキーマ名でdblinkを修飾することはできません。そのため、ralph.linktosalesのような名前を付けた場合、スキーマralphの中のlinktosalesという名前のデータベース・リンクであるとはみなされず、名前全体が自分のスキーマにあるデータベース・リンク名であると解析されます。
次の文は、パブリック・データベース・リンクremote（「パブリック・データベース・リンクの定義例:」で作成）を削除します。
DROP PUBLIC DATABASE LINK remote;
DROP DIMENSIONを使用すると、指定したディメンションを削除できます。
この文によって、ディメンションに指定された関連を使用するマテリアライズド・ビューが無効になるわけではありません。ただし、クエリー・リライトによってリライトされた要求が無効になり、そのようなビューに対する後続の操作の処理速度が遅くなることがあります。
|
参照:
|
この文を使用する場合、ディメンションが自分のスキーマ内にある必要があります。自分のスキーマ内にない場合は、DROP ANY DIMENSIONシステム権限が必要です。
ディメンションが格納されているスキーマの名前を指定します。schemaを指定しない場合、ディメンションは自分のスキーマ内にあるとみなされます。
削除するディメンションの名前を指定します。そのディメンションはすでに存在している必要があります。
この例は、sh.customers_dimを削除します。
DROP DIMENSION customers_dim;
DROP DIRECTORY文を使用すると、データベースからディレクトリ・オブジェクトを削除できます。
ディレクトリを削除する場合は、DROP ANY DIRECTORYシステム権限が必要です。
削除するディレクトリ・データベース・オブジェクトの名前を指定します。
Oracle Databaseはディレクトリ・オブジェクトを削除しますが、サーバーのファイル・システム上の関連するオペレーティング・システム・ディレクトリは削除しません。
次の文は、ディレクトリ・オブジェクトbfile_dirを削除します。
DROP DIRECTORY bfile_dir;
DROP DISKGROUP文を使用すると、自動ストレージ管理ディスク・グループおよびそのディスク・グループのすべてのファイルを削除できます。自動ストレージ管理では、最初にディスク・グループのファイルが開かれていないことが確認されます。次に、ディスク・グループおよびそのメンバー・ディスクが削除され、ディスク・ヘッダーが消去されます。
|
参照:
|
SYSDBAシステム権限が必要です。また、この文を発行する自動ストレージ管理インスタンスが起動されている必要があります。削除するディスク・グループはマウントされている必要があります。
削除するディスク・グループの名前を指定します。
INCLUDING CONTENTSを指定すると、自動ストレージ管理によってディスク・グループのすべてのファイルが削除されます。ディスク・グループにファイルが含まれている場合、この句を指定する必要があります。
EXCLUDING CONTENTSを指定すると、自動ストレージ管理によって空のディスク・グループのみが削除されます。これはデフォルトです。ディスク・グループが空ではない場合、エラーが戻されます。
この句では、ASMインスタンスではマウントできないディスク・グループに属するディスク上のヘッダーがクリアされます。ディスク・グループは、データベースのインスタンスからはマウントできません。
自動ストレージ管理インスタンスは、ディスク・グループが、同じストレージ・サブシステムを使用する他のASMで使用されているかどうかをまず確認します。ディスク・グループが使用されており、このディスク・グループが同じクラスタまたは同じノードにあるときは、文の実行に失敗します。ディスク・グループが異なるクラスタにある場合は、さらに、そのディスク・グループが別のクラスタ内のインスタンスによってマウントされているかどうかがチェックされます。ディスク・グループがマウントされている場合、この文の実行は失敗します。ただし、後者のチェックは、同じクラスタのディスク・グループのチェックほど確実なものではありません。そのため、この句の使用には注意が必要です。
次の文は、自動ストレージ管理ディスク・グループdgroup_01（「ディスク・グループの作成例:」で作成）およびそのディスク・グループ内のすべてのファイルを削除します。
DROP DISKGROUP dgroup_01 INCLUDING CONTENTS;
DROP FLASHBACK ARCHIVE句を使用すると、システムからフラッシュバック・データ・アーカイブを削除できます。この文では、フラッシュバック・データ・アーカイブとこの中にあるすべての履歴データが削除されますが、フラッシュバック・データ・アーカイブによって使用されている表領域は削除されません。
フラッシュバック・データ・アーカイブを削除するには、FLASHBACK ARCHIVE ADMINISTERシステム権限が必要です。
削除するフラッシュバック・データ・アーカイブの名前を指定します。
このフラッシュバック・データ・アーカイブによって履歴追跡が可能なすべての表について、フラッシュバック・データ・アーカイブが無効化されている場合を除き、デフォルトのフラッシュバック・データ・アーカイブを削除することはできません。
ファンクションはPL/SQLを使用して定義されます。ファンクションの作成、変更および削除の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。
DROP FUNCTION文を使用すると、データベースからスタンドアロン・ストアド・ファンクションを削除できます。
削除するファンクションが自分のスキーマ内にある必要があります。自分のスキーマ内にない場合は、DROP ANY PROCEDUREシステム権限が必要です。
ファンクションが含まれているスキーマを指定します。schemaを指定しない場合、ファンクションは自分のスキーマ内にあるとみなされます。
削除するファンクションの名前を指定します。
Oracle Databaseは、削除したファンクションに依存するローカル・オブジェクト、または削除したファンクションをコールするローカル・オブジェクトを無効にします。後でこれらのオブジェクトを参照した場合、データベースは、そのオブジェクトを再コンパイルしようとします。削除したファンクションを再作成しないかぎり、エラーが戻されます。
任意の統計タイプがファンクションに関連付けられている場合、FORCE句によって統計タイプの関連付けが解除され、統計タイプを使用して収集したユーザー定義のすべての統計情報が削除されます。
|
参照:
|
次の文は、サンプル・スキーマoe内のファンクションSecondMaxを削除します。この場合、SecondMaxに依存するすべてのオブジェクトは無効になります。
DROP FUNCTION oe.SecondMax;
DROP INDEX文を使用すると、データベースから索引またはドメイン索引を削除できます。
索引を削除すると、ビュー、パッケージ、パッケージ本体、ファンクション、プロシージャなど、基礎となる表に依存するすべてのオブジェクトが無効になります。
グローバル・パーティション索引、レンジ・パーティション索引またはハッシュ・パーティション索引を削除すると、すべての索引パーティションも削除されます。コンポジット・パーティション索引を削除した場合、すべての索引パーティションおよびサブパーティションも削除されます。
また、ドメイン索引を削除すると、次のようになります。
FORCE句によって統計タイプの関連付けが解除され、その統計タイプを使用して収集したユーザー定義の統計情報が削除されます。
参照:
domain_index_clause」を参照してください。
削除する索引が自分のスキーマ内にある必要があります。自分のスキーマ内にない場合は、DROP ANY INDEXシステム権限が必要です。
索引が含まれているスキーマを指定します。schemaを指定しない場合、索引は自分のスキーマ内にあるとみなされます。
削除する索引の名前を指定します。索引を削除すると、その索引に割り当てられていたすべてのデータ・ブロックが、その索引が含まれていた表領域に戻されます。
索引またはいずれかの索引パーティションにIN_PROGRESSのマークが付けられている場合は、ドメイン索引を削除できません。
FORCEは、ドメイン索引のみに適用されます。この句を指定すると、索引タイプ・ルーチンの起動がエラーを戻した場合、または索引にIN PROGRESSのマークが付けられている場合でも、ドメイン索引を削除できます。FORCEがないと、その索引タイプ・ルーチンの起動がエラーを戻す場合、または索引にIN PROGRESSマークが付けられている場合にドメイン索引を削除できません。
この文は、索引ord_customer_ix_demo（「索引の圧縮例:」で作成）を削除します。
DROP INDEX ord_customer_ix_demo;
DROP INDEXTYPE文を使用すると、索引タイプを削除できます。同時に、統計タイプとの関連付けも解除されます。
削除する索引タイプが自分のスキーマ内にある必要があります。自分のスキーマ内にない場合は、DROP ANY INDEXTYPEシステム権限が必要です。
索引タイプが含まれているスキーマを指定します。schemaを指定しない場合、この索引タイプは自分のスキーマ内にあるとみなされます。
削除する索引タイプの名前を指定します。
任意の統計タイプが索引タイプに関連付けられている場合、統計タイプと索引タイプの関連付けが解除され、統計タイプを使用して収集したすべての統計情報が削除されます。
FORCEを指定すると、1つ以上のドメイン索引から現在参照されている状態でも、その索引タイプを削除できます。これらのドメイン索引には、INVALIDマークが付けられます。FORCEを指定しない場合、任意のドメイン索引で参照されている索引タイプを削除できません。
次の文は、索引タイプposition_indextype（「拡張索引作成機能の使用方法」で作成）を削除し、この索引タイプで定義されているすべてのドメイン索引にINVALIDのマークを付けます。
DROP INDEXTYPE position_indextype FORCE;
DROP JAVA文を使用すると、Javaソース、クラスまたはリソース・スキーマ・オブジェクトを削除できます。
|
参照:
|
削除するJavaソース、クラスまたはリソースが自分のスキーマ内にある必要があります。自分のスキーマ内にない場合は、DROP ANY PROCEDUREシステム権限が必要です。また、このコマンドを使用する場合は、Javaクラスに対するEXECUTEオブジェクト権限も必要です。
SOURCEを指定すると、Javaソース・スキーマ・オブジェクトおよびそのオブジェクトから導出されたすべてのJavaクラス・スキーマ・オブジェクトを削除できます。
CLASSを指定すると、Javaクラス・スキーマ・オブジェクトを削除できます。
RESOURCEを指定すると、Javaリソース・スキーマ・オブジェクトを削除できます。
既存のJavaクラス、ソースまたはリソース・スキーマ・オブジェクトの名前を指定します。object_nameを二重引用符で囲むと、小文字の名前、または大文字と小文字を組み合せた名前を指定できます。
次の文は、JavaクラスAgent（「Javaクラス・オブジェクトの作成例:」で作成）を削除します。
DROP JAVA CLASS "Agent";
DROP LIBRARY文を使用すると、データベースから外部プロシージャ・ライブラリを削除できます。
DROP ANY LIBRARYシステム権限が必要です。
削除する外部プロシージャ・ライブラリの名前を指定します。
次の文は、ext_libライブラリ（「ライブラリの作成例:」で作成）を削除します。
DROP LIBRARY ext_lib;
DROP MATERIALIZED VIEW文を使用すると、データベースから既存のマテリアライズド・ビューを削除できます。
削除したマテリアライズド・ビューは、ごみ箱内には移動しません。このため、削除したマテリアライズド・ビューを消去またはリカバリすることはできません。
|
参照:
|
削除するマテリアライズド・ビューが自分のスキーマ内にある必要があります。自分のスキーマ内にない場合は、DROP ANY MATERIALIZED VIEWシステム権限が必要です。また、データベースがマテリアライズド・ビューのデータを管理するために使用する内部表、ビュー、索引を削除する権限も必要です。
マテリアライズド・ビューが含まれているスキーマを指定します。schemaを指定しない場合、このマテリアライズド・ビューは自分のスキーマ内にあるとみなされます。
削除する既存のマテリアライズド・ビューの名前を指定します。
この句を使用すると、マテリアライズド・ビュー・オブジェクトを削除した後も、そのマテリアライズド・ビューのコンテナ表およびその内容を保持できます。結果の表の名前は、削除したマテリアライズド・ビューと同じになります。
マテリアライズド・ビューに関連付けられているすべてのメタデータは削除されます。ただし、そのマテリアライズド・ビューの作成時にコンテナ表で自動的に作成されたすべての索引は、保存されます。また、そのマテリアライズド・ビューにネストした表の列が含まれる場合、その列の記憶表がそのメタデータとともに保存されます。
この句は、（マテリアライズド・ビューが「スナップショット」と呼ばれていた）Oracle9i より前のリリースからインポートしたマテリアライズド・ビューには無効です。
次の文は、サンプル・スキーマhrのマテリアライズド・ビューemp_dataを削除します。
DROP MATERIALIZED VIEW emp_data;
次の文は、sales_by_month_by_stateマテリアライズド・ビューおよびそのマテリアライズド・ビューの基礎となる表を削除します（基礎となる表がON PREBUILT TABLE句が指定されたCREATE MATERIALIZED VIEW文に登録されていない場合）。
DROP MATERIALIZED VIEW sales_by_month_by_state;
DROP MATERIALIZED VIEW LOG文を使用すると、データベースからマテリアライズド・ビュー・ログを削除できます。
|
参照:
|
マテリアライズド・ビュー・ログを削除する場合は、表を削除する権限が必要です。
マテリアライズド・ビュー・ログおよびそのマスター表が含まれているスキーマを指定します。schemaを指定しない場合、マテリアライズド・ビュー・ログおよびマスター表は自分のスキーマ内にあるとみなされます。
削除するマテリアライズド・ビュー・ログに関連付けられたマスター表の名前を指定します。
マテリアライズド・ビュー・ログを削除した場合、マテリアライズド・ビュー・ログのマスター表に基づく一部のマテリアライズド・ビューが高速リフレッシュできなくなります。高速リフレッシュできなくなるマテリアライズド・ビューには、ROWIDマテリアライズド・ビュー、主キー・マテリアライズド・ビューおよび副問合せマテリアライズド・ビューが含まれます。
次の文は、oe.customersマスター表のマテリアライズド・ビュー・ログを削除します。
DROP MATERIALIZED VIEW LOG ON customers;
DROP OPERATOR文を使用すると、ユーザー定義演算子を削除できます。
|
参照:
|
削除する演算子が自分のスキーマ内にある必要があります。自分のスキーマ内にない場合は、DROP ANY OPERATORシステム権限が必要です。
演算子が含まれているスキーマを指定します。schemaを指定しない場合、その演算子は自分のスキーマ内にあるとみなされます。
削除する演算子の名前を指定します。
FORCEを指定すると、演算子が現在1つ以上のスキーマ・オブジェクト（索引タイプ、パッケージ、ファンクション、プロシージャなど）によって参照されている場合でも、その演算子を削除できます。演算子に依存するこのようなオブジェクトには、INVALIDのマークが付けられます。FORCEを使用しないと、任意のスキーマ・オブジェクトに参照されている演算子を削除できません。
次の文は、演算子eq_opを削除します。
DROP OPERATOR eq_op;
FORCE句が指定されていないため、この演算子のバインディングのいずれかが索引タイプによって参照されている場合、この操作は実行されません。
DROP OUTLINE文を使用すると、ストアド・アウトラインを削除できます。
|
参照:
|
アウトラインを削除する場合は、DROP ANY OUTLINEシステム権限が必要です。
削除するアウトラインの名前を指定します。
そのアウトラインが削除された後、ストアド・アウトラインが作成されたSQL文がコンパイルされると、オプティマイザはアウトラインの影響なしに新しい実行計画を生成します。
次の文は、ストアド・アウトラインsalariesを削除します。
DROP OUTLINE salaries;
パッケージはPL/SQLを使用して定義されます。パッケージの作成、変更および削除の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。
DROP PACKAGE文を使用すると、データベースからストアド・パッケージを削除できます。この文は、パッケージの本体および仕様部を削除します。
削除するパッケージが自分のスキーマ内にある必要があります。自分のスキーマ内にない場合は、DROP ANY PROCEDUREシステム権限が必要です。
BODYを指定すると、パッケージ本体のみを削除できます。この句を省略した場合、パッケージ本体と仕様部の両方が削除されます。
パッケージ本体のみを削除して仕様部は削除しない場合、依存するオブジェクトは無効になりません。ただし、パッケージ本体を再作成しないかぎり、パッケージ仕様部で宣言したプロシージャやストアド・ファンクションはコールできません。
パッケージが含まれているスキーマを指定します。schemaを指定しない場合、パッケージは自分のスキーマ内にあるとみなされます。
削除するパッケージの名前を指定します。
そのパッケージ仕様部に依存するすべてのローカル・オブジェクトが無効になります。後でこれらのオブジェクトを参照した場合、データベースは、そのオブジェクトを再コンパイルしようとします。削除したパッケージを再作成しないかぎり、エラーが戻されます。
任意の統計タイプがパッケージに関連付けられている場合、FORCE句によって統計タイプの関連付けが解除され、統計タイプを使用して収集されたユーザー定義のすべての統計情報が削除されます。
次の文は、emp_mgmtパッケージの仕様部および本体を削除し、その仕様部に依存するすべてのオブジェクトを無効にします。このパッケージを作成する例については、『Oracle Database PL/SQL言語リファレンス』を参照してください。
DROP PACKAGE emp_mgmt;
プロシージャはPL/SQLを使用して定義されます。プロシージャの作成、変更および削除の詳細は、『Oracle Database PL/SQL言語リファレンス』を参照してください。
DROP PROCEDURE文を使用すると、データベースからスタンドアロンのストアド・プロシージャを削除できます。この文を使用してパッケージの一部であるプロシージャを削除しないでください。かわりに、DROP PACKAGE文を使用してパッケージ全体を削除するか、OR REPLACE句を指定したCREATE PACKAGE文を使用して、そのプロシージャを含めずにパッケージを再定義してください。
削除するプロシージャが自分のスキーマ内にある必要があります。自分のスキーマ内にない場合は、DROP ANY PROCEDUREシステム権限が必要です。
プロシージャが含まれているスキーマを指定します。schemaを指定しない場合、プロシージャは自分のスキーマ内にあるとみなされます。
削除するプロシージャの名前を指定します。
プロシージャを削除すると、そのプロシージャに依存するすべてのローカル・オブジェクトは無効になります。後でこれらのオブジェクトを参照した場合、データベースは、そのオブジェクトを再コンパイルしようとします。削除したプロシージャを再作成しないかぎり、エラー・メッセージが戻されます。
次の文は、ユーザーhrが所有するプロシージャremove_empを削除し、remove_empに依存するすべてのオブジェクトを無効にします。
DROP PROCEDURE hr.remove_emp;
DROP PROFILE文を使用すると、データベースからプロファイルを削除できます。DEFAULTプロファイル以外のプロファイルを削除できます。
DROP PROFILEシステム権限が必要です。
削除するプロファイルの名前を指定します。
CASCADEを指定すると、プロファイルの割当て先のユーザーからプロファイルの割当てを解除できます。このようなユーザーには、自動的にDEFAULTプロファイルが割り当てられます。現在、複数のユーザーに割り当てられているプロファイルを削除する場合は、必ずこの句を指定します。
次の文は、プロファイルapp_user（「プロファイルの作成例:」で作成）を削除します。プロファイルapp_userは削除され、現在app_userプロファイルが割り当てられているユーザーにはDEFAULTプロファイルが割り当てられます。
DROP PROFILE app_user CASCADE;
DROP RESTORE POINT文を使用すると、通常のリストア・ポイントまたは保証付きリストア・ポイントをデータベースから削除できます。
リストア・ポイントの作成方法および使用方法については、「CREATE RESTORE POINT」、「FLASHBACK DATABASE」および「FLASHBACK TABLE」を参照してください。
参照:
通常のリストア・ポイントを削除するには、SELECT ANY DICTIONARYまたはFLASHBACK ANY TABLEのいずれかのシステム権限が必要です。保証付きリストア・ポイントを削除するには、SYSDBAシステム権限が必要です。
削除するリストア・ポイントの名前を指定します。
次の例は、good_dataリストア・ポイント（「リストア・ポイントを作成して使用する例:」で作成）を削除します。
DROP RESTORE POINT good_data;
DROP ROLE文を使用すると、データベースからロールを削除できます。ロールを削除した場合、そのロールが付与されていたすべてのユーザーおよびロールからそのロールが取り消され、データベースからも削除されます。すでに使用可能なロールのユーザー・セッションには影響しません。ただし、削除後は新しいユーザー・セッションでロールを使用可能にできません。
|
参照:
|
Admin Option付きのロールが付与されているか、またはDROP ANY ROLEシステム権限を持っている必要があります。
削除するロールの名前を指定します。
次の文は、ロールdw_manager（「ロールの作成例:」で作成）を削除します。
DROP ROLE dw_manager;
DROP ROLLBACK SEGMENT文を使用すると、データベースからロールバック・セグメントを削除できます。ロールバック・セグメントを削除した場合、ロールバック・セグメントに割り当てられていたすべての領域が表領域に戻されます。
DROP ROLLBACK SEGMENTシステム権限が必要です。また、ロールバック・セグメントをオフラインにしておく必要があります。
削除するロールバック・セグメントの名前を指定します。
この文には、次の制限事項があります。
DBA_ROLLBACK_SEGSデータ・ディクショナリ・ビューを問い合せます。オフラインのロールバック・セグメントは、STATUS列の値がAVAILABLEになっています。また、ALTER ROLLBACK SEGMENT文にOFFLINE句を指定して、ロールバック・セグメントをオフラインにすることもできます。
SYSTEMロールバック・セグメントは削除できません。
次の構文は、ロールバック・セグメント（「ロールバック・セグメントの作成例:」で作成）を削除します。
DROP ROLLBACK SEGMENT rbs_one;
|
 Copyright © 1996, 2008, Oracle Corporation. All Rights Reserved. |
|