7 Oracleオブジェクトの管理

この章では、Oracleオブジェクトがデータベースの他の部分と関連してどのように機能するか、またDML操作およびDDL操作をどのように実行するかについて説明します。内容は次のとおりです。

オブジェクト型およびそれらのメソッドの権限
依存性および不完全な型
オブジェクト型のシノニム
パフォーマンス・チューニング
オブジェクトをサポートするツール
オブジェクトをサポートするユーティリティ

オブジェクト型およびそれらのメソッドの権限

オブジェクト型に対する権限は、システム・レベルおよびスキーマ・オブジェクト・レベルで存在します。

この項の内容は次のとおりです。

オブジェクト型のシステム権限
スキーマ・オブジェクト権限
新しい型または表での型の使用
例: オブジェクト型の権限
オブジェクト型へのアクセスおよびオブジェクト・アクセスの権限

オブジェクト型のシステム権限

Oracleでは、オブジェクト型に次のシステム権限を定義します。

CREATE TYPE: 自分のスキーマにオブジェクト型を作成できます。
CREATE ANY TYPE: 任意のスキーマにオブジェクト型を作成できます。
ALTER ANY TYPE: 任意のスキーマ内のオブジェクト型を変更できます。
DROP ANY TYPE: 任意のスキーマ内のオブジェクト型を削除できます。
EXECUTE ANY TYPE: 任意のスキーマ内のオブジェクト型を使用および参照できます。
UNDER ANY TYPE: 任意のNOT FINALオブジェクト型の下にサブタイプを作成できます。
UNDER ANY VIEW: 任意のオブジェクト・ビューの下にサブビューを作成できます。

The RESOURCEロールには、CREATE TYPEシステム権限が含まれます。DBAロールには、前述のすべての権限が含まれます。

スキーマ・オブジェクト権限

オブジェクト型には、2つのスキーマ・オブジェクト権限が適用されます。

オブジェクト型にEXECUTE権限があると、その型を次のように使用できます。
- 表の定義
- リレーショナル表の列の定義
- オブジェクト型の変数またはパラメータの宣言
EXECUTEは、コンストラクタなどの型のメソッドを起動します。

メソッド実行および対応する権限は、ストアドPL/SQLプロシージャのものと同じです。
UNDERは、権限が与えられた型またはビューの下にサブタイプまたはサブビューを作成します。

権限付与者が直系のスーパータイプまたはスーパービューについてUNDER権限をWith Grant Option付きで持っている場合のみ、サブタイプまたはサブビューに対するUNDER権限が付与されます。

WITH HIERARCHY OPTION句は、オブジェクトのすべてのサブオブジェクトについて指定されたオブジェクト権限を付与します。このオプションが意味を持つのは、オブジェクト・ビュー階層内のオブジェクト・ビューにSELECTオブジェクト権限が付与されている場合のみです。この場合、権限が付与されているビューのサブビューすべてに、権限が適用されます。

新しい型または表での型の使用

次の場合は、前述の項で説明した権限の他に、特定の権限が必要です。

別のユーザーが作成した型を使用する型または表を作成する場合
新しく作成した型または表の使用権限を別のユーザーに付与する場合

新しい型または表を定義するには、EXECUTE ANY TYPEシステム権限、または使用する型に対するEXECUTEオブジェクト権限が必要です。これらの権限は、ロールを介してではなく、明示的に付与される必要があります。

新しい型または表へのアクセス権限を他のユーザーに付与するには、Grant Optionを含む適切なEXECUTEオブジェクト権限、またはオプションWITH ADMIN OPTIONを含むEXECUTE ANY TYPEシステム権限が必要です。これらの権限は、ロールを介してではなく、明示的に付与される必要があります。

例: オブジェクト型の権限

CREATE SESSIONロールおよびRESOURCEロールを持つUSER1、USER2、USER3という3人のユーザーがいると想定します。

USER1は、USER1スキーマ内で次のDDLを実行します。

CONNECT user1
Enter password: password1
CREATE TYPE type1 AS OBJECT ( attr1 NUMBER );
/
CREATE TYPE type2 AS OBJECT ( attr2 NUMBER );
/
GRANT EXECUTE ON type1 TO user2;
GRANT EXECUTE ON type2 TO user2 WITH GRANT OPTION;

USER2は、USER2スキーマ内で次のDDLを実行します。

CONNECT user2
Enter password: password2
CREATE TABLE tab1 OF user1.type1;
CREATE TYPE type3 AS OBJECT ( attr3 user1.type2 );
/
CREATE TABLE tab2 (col1 user1.type2 );

USER2は、Grant Optionを含む、USER1のTYPE2に対するEXECUTE権限を持っているため、次の文は正常に実行されます。

GRANT EXECUTE ON type3 TO user3;
GRANT SELECT ON tab2 TO user3;

ただし、USER2は、Grant Optionを含む、USER1.TYPE1に対するEXECUTE権限を持っていないため、次の文は正常に実行されません。

GRANT SELECT ON tab1 TO user3 -- incorrect statement;

USER3は、次の処理を正常に実行できます。

CONNECT user3
Enter password: password3
CREATE TYPE type4 AS OBJECT (attr4 user2.type3);
/
CREATE TABLE tab3 OF type4;

オブジェクト型へのアクセスおよびオブジェクト・アクセスの権限

オブジェクト型はEXECUTE権限のみを使用しますが、オブジェクト表はリレーショナル表と同じ次のすべての権限を使用します。

SELECT: 表から1つのオブジェクトおよびその属性にアクセスできます。
UPDATE: 表内のオブジェクトの属性を変更できます。
INSERT: 表に新しいオブジェクトを追加できます。
DELETE: 表からオブジェクトを削除できます。

同様の表権限および列権限が、オブジェクト型の表列の使用を規制します。

オブジェクト表の列を選択するには、オブジェクト表の型に対する権限は必要ありません。ただし、行全体を選択するには必要です。

例7-1に示すスキーマと問合せを考えてみます。

例7-1 型へのアクセスのSELECT権限

CREATE TYPE emp_type as object (
  eno     NUMBER,
  ename   VARCHAR2(36));
/
CREATE TABLE emp OF emp_type;
GRANT SELECT on emp TO user1;
SELECT VALUE(e) FROM emp e;
SELECT eno, ename FROM emp;

どちらの問合せの場合も、Oracleはemp表に対するユーザーのSELECT権限をチェックします。最初の問合せの場合、データを解析するには、ユーザーはemp_type型情報を取得する必要があります。問合せがemp_type型にアクセスすると、ユーザーのEXECUTE権限をチェックします。

2番目の問合せの実行は、指定された型を必要としません。そのため、型権限をチェックしません。

さらに、「例: オブジェクト型の権限」で説明したスキーマを使用して、USER3は次の問合せを実行できます。

SELECT t.col1.attr2 from user2.tab2 t;

SELECT t.attr4.attr3.attr2 FROM tab3 t;

USER3による2つの選択では、USER3は基礎となる型の明示的な権限を持っていませんが、型所有者および表所有者はGrant Optionを含む必要な権限を持っているため、この文は正常に実行されます。

次の要求についての権限をチェックし、ユーザーに各処理に対する権限がない場合はエラーを戻します。

REF値を使用してオブジェクト・キャッシュ内に1つのオブジェクトを確保すると、そのオブジェクトを含むオブジェクト表に対するSELECT権限、およびそのオブジェクト型に対するEXECUTE権限をチェックします。

関連項目

OCIプログラムをオブジェクトとともに効果的に使用するためのヒントおよび技法は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。

既存オブジェクトの変更、またはオブジェクト・キャッシュからのオブジェクトのフラッシュを行うと、接続先オブジェクト表に対するUPDATE権限をチェックします。新しいオブジェクトをフラッシュすると、接続先オブジェクト表に対するINSERT権限をチェックします。
オブジェクトを削除すると、接続先の表に対するDELETE権限をチェックします。
メソッドを起動すると、対応するオブジェクト型に対するEXECUTE権限をチェックします。

オブジェクト表に対する列レベルの権限は提供しません。

依存性および不完全な型

型は、互いに依存するように定義できます。たとえば、employeeの1つの属性を従業員が属する部門にし、departmentの1つの属性を部門を管理する従業員にするように、オブジェクト型employeeおよびdepartmentを定義できます。

このように、直接的または中間の型を介して互いに依存する型を、相互依存といいます。矢印を使用して一連の型の依存関係を示す図の場合、相互依存型同士のつながりがループを形成します。

そのような循環依存を定義するには、サークルの最小限1つのセグメントにREFを使用する必要があります。

たとえば、例7-2に示す型を定義できます。

例7-2 依存オブジェクト型の作成

CREATE TYPE department;
/

CREATE TYPE employee AS OBJECT (
  name    VARCHAR2(30),
  dept    REF department,
  supv    REF employee );
/

CREATE TYPE emp_list AS TABLE OF employee;
/

CREATE TYPE department AS OBJECT (
  name    VARCHAR2(30),
  mgr     REF employee,
  staff   emp_list );
/

これは、適切な相互依存型におけるSQL DDL文の適切な順序です。これをエラーなしでコンパイルします。

例7-2のコードはdepartment型を2回作成することに注意してください。次の文はオプションです。

CREATE TYPE department;

この文は、employeeのREF属性が指すプレースホルダとして機能するdepartmentの不完全な宣言です。AS OBJECT句が省略され、属性またはメソッドがリストされていない点で、この宣言は不完全です。これらは、後述の型を完成させる完全な宣言で指定します。ここでは、departmentを不完全なオブジェクト型として作成しておきます。これにより、employeeがエラーなしでコンパイルできます。

不完全な型を再定義するには、この例の最後に示すとおり、型の属性およびメソッドを指定するCREATE TYPE文を実行します。不完全な型が参照するすべての型を作成した後、不完全な型を再定義してください。

不完全な型をプレースホルダとして作成しない場合、その型を参照する型はコンパイルされますが、コンパイル・エラーが発生します。

たとえば、departmentが存在しない場合、それを不完全な型として作成し、employeeはコンパイル・エラーになります。この場合、次回なんらかの操作がこの型にアクセスしようとした際に、employeeが再コンパイルされます。この型が依存するすべての型が作成され、その依存性が完全な場合、エラーなしでコンパイルされます。

不完全な型を使用することにより、まだ作成されていないサブタイプに対するREF属性を格納する型も作成できます。こうしたスーパータイプを作成するには、参照するサブタイプの不完全な型を最初に作成します。完全なサブタイプは、スーパータイプ作成後に作成します。

サブタイプは、直系のスーパータイプの特殊なバージョンであるため、必然的に直系のスーパータイプとの間に明らかな依存関係を持ちます。スーパータイプを削除した後、サブタイプの削除もれが発生しないようにするために、最初にすべてのサブタイプを削除する必要があります。スーパータイプは、そのすべてのサブタイプが削除されるまで、削除できません。

不完全な型の再定義

不完全な型が参照するすべての型が作成されたら、不完全な型が不完全な状態を維持する必要がなくなるため、不完全な型の宣言を再定義してください。型を再定義すると、型が再コンパイルされ、システムが様々なロックを解放できるようになります。

不完全なオブジェクト型は、オブジェクト型として再定義する必要があります。オブジェクト型をコレクション型（ネストした表型または配列型）として再定義することはできません。その型を削除することはできます。

明示的に作成しなかったためにOracleによって作成される不完全な型も、再定義する必要があります。前述の例は、departmentを明示的に不完全な型として作成しています。departmentを明示的に不完全な型として作成しなかった場合、employee型が（エラー付きで）コンパイルできるように、この型を明示的に不完全な型として作成します。departmentの宣言は、この型を不完全な型として宣言したのがユーザーであるか、Oracleであるかにかかわらず、オブジェクト型として再定義する必要があります。

手動による型の再コンパイル

型の作成でコンパイル・エラーが発生し、その型に対してなんらかの操作（表の作成、行の挿入など）を実行しようとした場合、エラーが発生することがあります。この操作を行う前に、タイプtypenameを再コンパイルする必要があります。手動で型を再コンパイルする場合は、ALTER TYPE typename COMPILE文を実行します。型のコンパイルが正常に実行された後、操作を再試行してください。

代入可能な表および列の型依存性

代入可能な表または型Tの列は、Tに依存するのみでなく、Tのサブタイプにも依存します。それは、Tのサブタイプで追加されたそれぞれの属性について、非表示列が表に追加されることからもわかります。代入可能な表または列に、このサブタイプのデータが何も入っていない場合も、非表示列は追加されます。

したがって、たとえば型person_typの個人表はperson_typのみでなく、person_typのサブタイプであるstudent_typおよびpart_time_student_typにも依存します。

依存型、表または列を持つサブタイプを削除しようとすると、DROP TYPE文はエラーを戻し、異常終了します。たとえば、part_time_student_typは、persons表に依存しているので、削除しようとすると、エラーとなります。

依存表または依存列が存在しても、削除する型のデータが何も入っていない場合は、VALIDATEキーワードを使用して、型を削除できます。VALIDATEキーワードが使用されていると、指定された型のインスタンスが実際に格納されているかどうかを調べ、何も見つからなければ、型を削除します。非表示列で、型に固有の属性と関連付けられたものも削除されます。

次に示す最初のDROP TYPE文は正常に実行されません。part_time_student_typが依存表（persons）になっているためです。ただし、personsにpart_time_student_typのインスタンスが何も入っていなければ（および他の依存表または依存列のいずれも入っていなければ）、VALIDATEキーワードにより2番目のDROP TYPE文は正常に実行されます。

-- Following generates an error due to presence of Persons table
DROP TYPE part_time_student_typ -- incorrect statement;
-- Following succeeds if there are no stored instances of part_time_student_typ
DROP TYPE part_time_student_typ VALIDATE;

注意:

サブタイプの削除中に、VALIDATEオプションを使用することをお薦めします。

DROP TYPE FORCEオプション

DROP TYPE文には、FORCEオプションもあります。このオプションは、型に依存型または依存表がある場合でも、型を削除します。存在するすべての依存型または依存表に無効のマークが付けられ、型が削除されたときにアクセス不能になるので、FORCEオプションは慎重に使用する必要があります。依存する型が削除されたために無効になった表のデータに、再びアクセスすることはできません。こうした表に対して実行できる操作は、削除のみです。

型の変更方法の詳細は、「型進化」を参照してください。

オブジェクト型のシノニム

表、ビューおよびその他の様々なスキーマ・オブジェクトについてシノニムが作成できるように、オブジェクト型についてもシノニムを定義できます。

型のシノニムは、基礎となるスキーマ・オブジェクトを場所に依存せずに参照する手段となるため、他の種類のスキーマ・オブジェクトのシノニムと同じ利点があります。パブリック・タイプのシノニムを使用するアプリケーションは、データベースのスキーマを変更せずにデプロイできます。型が定義されているスキーマの名前で型の名前を修飾する必要はありません。

関連項目

シノニムの詳細は、『Oracle Database管理者ガイド』を参照してください。

この項の内容は次のとおりです。

型のシノニムの作成
型のシノニムの使用

型のシノニムの作成

型のシノニムは、CREATE SYNONYM文で作成します。たとえば、これらの文はtyp1型を作成し、次にこの型のシノニムを作成します。

-- For the synonym examples, CREATE SYNONYM and CREATE PUBLIC SYNONYM
-- are granted to USER1
CREATE TYPE typ1 AS OBJECT (x number);
/
CREATE SYNONYM syn1 FOR typ1;

シノニムは、コレクション型についても作成できます。次の例は、ネストした表型のシノニムを作成します。

CREATE TYPE typ2 AS TABLE OF NUMBER;
/
CREATE SYNONYM syn2 FOR typ2;

パブリック・シノニムは、PUBLICキーワードを使用して作成します。

CREATE TYPE shape AS OBJECT ( name VARCHAR2(10) );
/
CREATE PUBLIC SYNONYM pub_shape FOR shape;

REPLACEオプションを使用すると、シノニムが指す基礎となる型を別の型に変更できます。たとえば、次の文は、syn1が指す型をtyp2型に変更します。

CREATE OR REPLACE SYNONYM syn1 FOR typ2;

型のシノニムの使用

型のシノニムは、型を参照できるすべての場所で使用できます。たとえば、DDL文の中で型のシノニムを使用して、表列の型または型属性を指定できます。例7-3では、シノニムsyn1を使用して、属性の型をtyp3型に指定します。

例7-3 CREATE文での型のシノニムの使用

CREATE TYPE typ1 AS OBJECT (x number);
/
CREATE SYNONYM syn1 FOR typ1;

CREATE TYPE typ3 AS OBJECT ( a syn1 );
/

次の例は、syn1をシノニムとするオブジェクト型typ1のコンストラクタをコールするために使用する型のシノニムsyn1です。この文は、typ1のオブジェクト・インスタンスを戻します。

SELECT syn1(0) FROM dual;

次の例は、syn2がネストした表型のシノニムです。この例は、実際の型の名前のかわりにCAST式で使用されるシノニムを示しています。

SELECT CAST(MULTISET(SELECT eno FROM USER3.EMP) AS syn2) FROM dual;

型のシノニムは、次のような文で使用できます。

DML文: SELECT、INSERT、UPDATE、DELETE、FLASHBACK TABLE、EXPLAIN PLANおよびLOCK TABLE
DDL文: AUDIT、NOAUDIT、GRANT、REVOKEおよびCOMMENT

シノニムを使用するスキーマ・オブジェクトの記述

型のシノニムを使用して型または表が作成されると、DESCRIBEコマンドにより、これらのシノニムが表す型のかわりにシノニムが表示されます。同様に、型の名前を示すカタログ・ビュー（USER_TYPE_ATTRSなど）には、対応付けられた型のシノニムの名前が表示されます。

カタログ・ビューUSER_SYNONYMSを問い合せると、型のシノニムの基礎となる型を確認できます。

型のシノニムへの依存

型の宣言でシノニムを直接的または間接的に参照する型は、そのシノニムに依存します。したがって、次に示す型typ3は、シノニムsyn1に依存する型です。

CREATE TYPE typ3 AS OBJECT ( a syn1 );
/

DDL文でシノニムを参照する他の種類のスキーマ・オブジェクトも、これらのシノニムに依存します。型のシノニムに依存するオブジェクトは、シノニムとシノニムの基礎になる型のどちらにも依存します。

シノニムの依存関係によって、シノニムが削除できるかどうか、または名前が変更できるかどうかが決まります。また、依存スキーマ・オブジェクトも、シノニムに対する操作の影響を受けます。次の項では、これらの様々な影響について説明します。

型のシノニムを置換する際の制限事項

シノニムに依存表または有効なユーザー定義型が存在しない場合にのみ、シノニムは置換できます。シノニムを置換することは、シノニムを削除してから、同じ名前で新しいシノニムを再作成することと同等です。

型のシノニムの削除

例7-4のように、シノニムはDROP SYNONYM文で削除します。

例7-4 型のシノニムの削除

CREATE SYNONYM syn4 FOR typ1;

DROP SYNONYM syn4;

型のシノニムに依存表または有効なオブジェクト型がある場合、型のシノニムを削除するには、FORCEオプションが必要です。FORCEオプションは、列の実際の型が削除された場合と同様に、直接的または間接的にシノニムに依存する列を、未使用とマークします。（たとえば、シノニムを使用して、列の宣言された型の属性の型を指定すると、列は間接的にそのシノニムに依存します。）

削除されたシノニムに依存するすべてのスキーマ・オブジェクトは無効になります。これらのスキーマ・オブジェクトは、削除されたシノニムと同じ名前のローカル・オブジェクトを作成するか、または同じ名前で新しいパブリック・シノニムを作成することで、再検証できます。

型のシノニムの基礎となるベース型の削除は、シノニムの削除と同じ結果を依存オブジェクトにもたらします。

型のシノニムの名前変更

型のシノニムの名前は、RENAME文で変更します。シノニムの名前を変更することは、シノニムを削除してから、新しい名前でシノニムを再作成することと同等です。型のシノニムに依存表または有効なオブジェクト型が存在する場合、型のシノニムの名前は変更できません。syn1には依存するオブジェクト型が存在するため、次の例は失敗します。

RENAME syn1 TO syn3 -- invalid statement;

型のパブリック・シノニムおよびローカル・スキーマ・オブジェクト

パブリック・シノニムが、新しいスキーマ・オブジェクトを作成するローカル・スキーマに依存表または有効なオブジェクト型を持っている場合、そのパブリック・シノニムと同じ名前のローカル・スキーマ・オブジェクトは作成できません。また、同じスキーマ内のプライベート・スキーマと同じ名前のローカル・スキーマ・オブジェクトも作成できません。

たとえば、次の例では、表shape_tabはパブリック・シノニムpub_shapeの依存表です。この表には、型の定義でこのシノニムを使用する列があるためです。したがって、依存表と同じスキーマにパブリック・シノニムpub_shapeと同じ名前の表を作成しようとすると、正常に実行されません。

-- Following uses public synonym pub_shape
CREATE TABLE shape_tab ( c1 pub_shape );
-- Following is not allowed
CREATE TABLE pub_shape ( c1 NUMBER ) -- invalid statement;

パフォーマンス・チューニング

オブジェクトのチューニング時には、次の点に対処する必要があります。

オブジェクトおよびオブジェクト・ビューによる実行時のCPUおよびメモリー・リソースの消費状況
実行時のメモリーおよびCPUリソースの監視方法
多数のオブジェクトの管理方法

重要なパフォーマンス要因には、次のようなものがあります。

統計を収集するDBMS_STATSパッケージ
SQLコマンドの実行をプロファイルするtkprof

問合せ計画を生成するEXPLAIN PLAN

関連項目

アプリケーションのパフォーマンスの測定およびチューニングの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

オブジェクトをサポートするツール

この項では、Oracleオブジェクトのサポート機能を持ついくつかのOracleのツール製品について説明します。

この項の内容は次のとおりです。

JDeveloper
JPublisher

JDeveloper

JDeveloperは、複数層のJavaアプリケーションの作成を目的としたフル機能の統合開発環境です。このツールにより、Javaクライアント・アプリケーション、動的HTMLアプリケーション、Webおよびアプリケーション・サーバー・コンポーネントおよび業界標準モデルに基づいたデータベース・ストアド・プロシージャの開発、デバッグおよびデプロイができます。

JDeveloperの強力な機能が提供されるのは、次の分野です。

Oracle Business Components for Java
Webアプリケーションの開発
クライアント向けJavaアプリケーションの開発
データベースにおけるJava
JavaBeansによるコンポーネント・ベースの開発
シンプリファイド・データベース・アクセス
ビジュアル統合開発環境
Java言語サポート

JDeveloperはクロスプラットフォームの総合開発環境（IDE）です。Oracle Application ServerおよびOracle Databaseと緊密に統合された標準のGUIベースのJava開発環境となります。

Business Components for Java（BC4J）

標準EJBおよびCORBAデプロイメント・アーキテクチャであるOracle Business Components for Javaがサポートされるため、エンタープライズ向けのJavaビジネス・アプリケーションの開発、配布、カスタマイズが簡素化されます。Oracle Business Components for Javaは、アプリケーション・コンポーネントのフレームワークで、次に示す作業に必要な共通ファシリティすべてを管理する再利用可能なソフトウェア・ビルディング・ブロックを提供します。

リレーショナル・データベースと統合するコンポーネントのビジネス・ロジックの作成およびテスト
データの複数のSQLベース・ビューを介したビジネス・ロジックの再利用
サーブレット、JavaServer Pages（JSP）およびThin-Java Swingクライアントから行うビューへのアクセスおよび更新
配布したアプリケーションの修正を必要としないレイヤー単位のアプリケーション機能のカスタマイズ

JPublisher

JPublisherはユーティリティで、次のユーザー定義データベース・エンティティをユーザーのJavaプログラムで表すJavaクラスを生成します。

データベース・オブジェクト・タイプ
データベース参照（REF）型
データベース・コレクション型（VARRAYまたはネストした表）
PL/SQLパッケージ

JPublisherにより、強力な型指定パラダイムで、データベース・オブジェクト型、参照型およびコレクション型（VARRAYまたはネストした表）をJavaクラスに対してマップする操作を指定し、カスタマイズできます。

関連項目

『Oracle Database JPublisherユーザーズ・ガイド』

オブジェクトをサポートするユーティリティ

この項では、Oracleオブジェクトのサポート機能を持ついくつかのOracleのユーティリティについて説明します。

この項の内容は次のとおりです。

オブジェクト型のインポート/エクスポート
SQL*Loader

オブジェクト型のインポート/エクスポート

エクスポート・ユーティリティおよびインポート・ユーティリティは、Oracleデータベースへ、またはOracleデータベースから、データを移動します。また、データのバックアップまたはアーカイブ、およびOracle RDBMSの異なるリリースへの移行に役立ちます。

エクスポートおよびインポートは、オブジェクト型をサポートします。エクスポートは、オブジェクト型定義および関連するすべてのデータをダンプ・ファイルに書き込みます。インポートは、ダンプ・ファイルからこれらの項目を再作成します。

タイプ

導出型の定義文はエクスポートされます。インポート時、スーパータイプ定義のインポートが完了する前に、サブタイプを作成できます。この場合、サブタイプを作成するとコンパイル・エラーが発生しますが、無視してください。型のスーパータイプが作成された後、型の再検証が行われます。

オブジェクト・ビューの階層

ビュー階層に属するすべてのビューのビュー定義はエクスポートされます。

SQL*Loader

SQL*Loaderユーティリティは、外部ファイルのデータを、Oracleデータベース内の表に移動します。これらのファイルには、INTEGER、CHAR、DATEなど基本的なスカラー・データ型で構成されるデータや、行オブジェクトや列オブジェクト（オブジェクト、コレクションまたはREF属性）、コレクション、LOBなど複雑なユーザー定義データ型などが含まれる可能性があります。現在、SQL*Loaderはシングルレベル・コレクションのみをサポートしています。マルチレベル・コレクション（他のコレクションが要素になっているか、他のコレクションが入っているコレクション）のロードに、SQL*Loaderは使用できません。

SQL*Loaderは、SQL*Loader DDL文が入っている制御ファイルを使用して、データ・ファイルのフォーマット、内容および位置を記述します。

SQL*Loaderがデータをロードする方法は、2通りあります。

従来型パス・ロード: SQL INSERT文およびバインド配列バッファを使用して、データをデータベース表にロードします。
ダイレクト・パス・ロード: ダイレクト・パス・ロードAPIを使用して、SQL*Loaderクライアントのかわりに、データ・ブロックを直接データベースに書き込みます。

ダイレクト・パス・ロードはSQLインタフェースを使用しないので、関連するSQL文の処理時にオーバーヘッドが発生しません。したがって、ダイレクト・パス・ロードからは従来型パス・ロードよりも優れたパフォーマンスが得られます。

どちらの方法も、サポート対象となっているオブジェクトおよびコレクション・データ型のデータのロードに使用できます。

関連項目

SQL*Loaderの使用方法は、『Oracle Databaseユーティリティ』を参照してください。