6 スキーマ・オブジェクト間の依存性

ビューやプロシージャなどのオブジェクトの定義では、他のオブジェクト（表など）が参照されます。したがって、定義するオブジェクトは、その定義で参照する他のオブジェクトに依存しています。この章では、スキーマ・オブジェクトの相互間の依存性と、Oracleがそのような依存性を自動的に追跡し管理する方法について説明します。

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

依存性の問題の概要

スキーマ・オブジェクトのタイプによっては、定義の一部として他のオブジェクトを参照できるものがあります。たとえば、ビューは表や他のビューを参照する問合せによって定義されます。また、プロシージャ本体には、データベースの他のオブジェクトを参照するSQL文を組み込めます。定義の一部として他のオブジェクトを参照するオブジェクトを依存オブジェクトと呼び、参照されるオブジェクトを参照オブジェクトと呼びます。図6-1に、各種の依存オブジェクトと参照オブジェクトを示します。

図 6-1 様々な依存スキーマ・オブジェクトと参照スキーマ・オブジェクト

画像の説明

参照オブジェクトの定義を変更した場合、その変更の内容によって、依存オブジェクトがエラーなしで機能し続ける場合と、そうでない場合があります。たとえば、表を削除した場合、その表に基づくビューは使用できなくなります。

Oracleではオブジェクト間の依存性が自動的に記録されるため、データベース管理者とユーザーは依存性管理の複雑な作業から解放されます。たとえば、複数のストアド・プロシージャが依存している表を変更すると、依存プロシージャは、次に参照された（再度実行またはコンパイルされた）時点で自動的に再コンパイルされます。

スキーマ・オブジェクト間の依存性を管理するために、データベース内のすべてのスキーマ・オブジェクトはステータスを持ちます。

有効なスキーマ・オブジェクトはコンパイルされており、参照するとただちに使用できます。
無効なスキーマ・オブジェクトを使用するには、その前にコンパイルする必要があります。
- プロシージャ、ファンクションおよびパッケージの場合は、スキーマ・オブジェクトをコンパイルする必要があることを意味します。
- また、ビューの場合は、データ・ディクショナリ内の現行の定義を使用して、ビューを再解析する必要があることを意味します。
無効になる可能性があるのは、依存しているオブジェクトのみです。表、順序およびシノニムは、常に有効です。

ビュー、プロシージャ、ファンクションまたはパッケージが無効である場合、Oracleがそのオブジェクトをコンパイルしようとしても、そのオブジェクトに関連したエラーが発生します。たとえば、ビューのコンパイル時に、実表の1つが存在しなかったり、実表の正当な権限がなかったりする場合があります。パッケージのコンパイル時には、PL/SQLまたはSQLの構文エラーが発生したり、参照されているオブジェクトについての適切な権限が存在しない場合があります。このような問題があるスキーマ・オブジェクトは無効のままです。

Oracleはデータベースの変更を自動的に追跡し、関係するオブジェクトのステータスをデータ・ディクショナリに記録します。

ステータスの記録は再帰的な処理です。参照オブジェクトの状態が変更されると、直接的に依存するオブジェクトのステータスが変更されるだけでなく、間接的に依存するオブジェクトのステータスも変更されます。

たとえば、ビューを直接参照するストアド・プロシージャを考えます。ストアド・プロシージャは、このビューの実表を間接的に参照します。このため、実表を変更するとビューは無効になり、さらにストアド・プロシージャも無効になります。図6-2に、間接的な依存性を示します。

図 6-2 間接的な依存性

画像の説明

スキーマ・オブジェクトの依存性の解決

スキーマ・オブジェクトがSQL文によって直接的に、または依存オブジェクトの参照を介して間接的に参照されるときに、OracleはSQL文に明示的に指定されているオブジェクトと参照オブジェクトのステータスを、必要に応じてチェックします。Oracleの処理は、SQL文で直接および間接的に参照されるオブジェクトのステータスに応じて異なります。

参照オブジェクトがすべて有効であれば、追加処理なしでSQL文がただちに実行されます。

参照先のビューやPL/SQLプログラム・ユニット（プロシージャ、ファンクションまたはパッケージ）が無効な状態になっていると、Oracleはその参照オブジェクトを自動的にコンパイルしようとします。

無効な参照オブジェクトは、そのすべてを正常にコンパイルできる場合には問題なくコンパイルされ、SQL文は正常に実行されます。

無効なオブジェクトは、正常にコンパイルできなければ無効のままになります。Oracleはエラーを戻し、失敗したSQL文をロールバックします。トランザクションの残りの部分は変更されず、ユーザーがコミットまたはロールバックできます。

注意
Oracleは、無効であると検出された後に置き換えられていないオブジェクトのみを動的に再コンパイルします。これにより、不要な再コンパイルが省略されます。

ビューとPL/SQLプログラム・ユニットのコンパイル

次の条件が満たされている場合は、ビューまたはPL/SQLプログラム・ユニットをコンパイルして、その状態を有効にすることができます。

ビューまたはプログラム・ユニットの定義が正しいこと。すべてのSQL文とPL/SQL文が適切な構成メンバーである必要があります。
参照オブジェクトが存在し、適切な構成であること。たとえば、ビューを定義する問合せに列が含まれる場合、その列が実表に存在している必要があります。
ビューまたはプログラム・ユニットの所有者に、参照オブジェクトに対する必要な権限が付与されていること。たとえば、プロシージャ内のSQL文によって表に行が挿入される場合、プロシージャの所有者にはその参照表に対するINSERT権限が必要です。

ビューと実表

ビューは、そのビューの定義問合せで参照されている実表またはビューに依存しています。たとえば、SELECT * FROM tableのように、ビューの定義問合せで参照される列が明示的に定義されていなければ、定義問合せはデータ・ディクショナリへの格納時に展開され、参照先の実表内の現行の列がすべて含まれるようになります。

ビューの実表またはビューを変更、改名または削除すると、そのビューは無効になりますが、その定義は無効なビューを参照する権限、シノニム、他のオブジェクトおよび他のビューとともに、データ・ディクショナリ内に残ります。

注意
表、索引およびビューを作成した後に表を削除すると、その表に依存するビュー、パッケージ、パッケージ本体、ファンクションおよびプロシージャなどのオブジェクトはすべて無効になります。

無効なビューを使用すると、そのビューは動的に再コンパイルされます。再コンパイルされたビューは、次に示す条件に応じて有効または無効になります。

ビューの定義問合せが参照しているすべての実表が存在している必要があります。ビューの実表を改名または削除すると、そのビューは無効になり、使用できなくなります。無効なビューを参照すると、その参照文は失敗します。ビューをコンパイルできるのは、実表を元の名前に改名した場合、または実表を再作成した場合のみです。
実表を変更したり、同じ列を含む実表を再作成した場合に、その実表の1つ以上の列のデータ型が変更されていても、ほとんどの依存ビューは正常に再コンパイルできます。
ビューの実表が、少なくとも同じ列集合を含むように変更または再作成された場合、そのビューは有効にすることができます。実表が新しい列を含むように再作成され、その結果の表中にもはや存在しない列をビューが参照していると、そのビューは有効になりません。後者のケースは、SELECT * FROM tableの問合せで定義されたビューに特に当てはまります。このような定義問合せはビューの作成時にデータ・ディクショナリ内で展開され、そのまま永続的に格納されるためです。

プログラム・ユニットと参照オブジェクト

参照オブジェクトの定義を変更すると、プログラム・ユニットは自動的に無効になります。たとえば、スタンドアロン・プロシージャに表、ビュー、別のスタンドアロン・プロシージャおよびパブリック・パッケージ・プロシージャを参照する複数の文が含まれているとします。このような場合は、次のような条件が成立します。

参照表を変更すると、依存プロシージャは無効になります。
参照ビューの実表を変更すると、ビューと依存プロシージャが無効になります。
参照スタンドアロン・プロシージャを置き換えると、依存プロシージャが無効になります。
参照パッケージの本体を置き換えても、依存プロシージャには影響しません。ただし、参照パッケージの仕様部を置き換えると、依存プロシージャは無効になります。これが、パッケージを使用することによってプロシージャおよび参照オブジェクトの間の依存性を最小にするメカニズムです。
表、索引およびビューを作成した後に表を削除すると、その表に依存するビュー、パッケージ、パッケージ本体、ファンクションおよびプロシージャなどのオブジェクトはすべて無効になります。

データ・ウェアハウスの考慮事項

一部のデータ・ウェアハウスでは、ロード時間を速めるために夜間に索引を削除します。ただし、索引が削除された表に依存するすべてのビューは無効になります。このことは、その後実行されるパッケージがこれら削除されたビューを参照すると、そのパッケージが無効になることを意味します。

表、索引およびビューを作成した後に索引を削除すると、その表に依存するビュー、パッケージ、パッケージ本体、ファンクションおよびプロシージャなどのオブジェクトはすべて無効になることに注意してください。このことにより、更新可能な結合ビューが保護されます。

ビューを再び有効にするには、次の文を使用します。

SELECT * FROM vtest;

または

ALTER VIEW vtest compile;

セッションの状態と参照パッケージ

パッケージ構成を参照するセッションごとに、各パッケージの独自のインスタンスが存在します。このインスタンスには、パブリック変数とプライベート変数、カーソルおよび定数の永続的な状態が含まれます。その後、セッションのインスタンス化されたパッケージのいずれかが無効にされて再コンパイルされると、セッションのパッケージのすべてのインスタンス化が、状態も含めて失われる可能性があります。

セキュリティ認可

ユーザーやPUBLICに対してDMLオブジェクト権限やシステム権限の付与または取消しが実行された場合、Oracleはその所有者のすべての依存オブジェクトを自動的に無効にします。Oracleは依存オブジェクトを無効にして、その依存オブジェクトの所有者が参照オブジェクトに対する必要な権限を引き続き持っていることを検証します。Oracleは内部的に、そのようなオブジェクトを再コンパイルする必要はないことを確認します。つまり、オブジェクト構造を検証するのではなく、セキュリティ認可のみを検証します。このように最適化すると、不要な再コンパイルが省略され、依存オブジェクトのタイム・スタンプを変更する必要もありません。

関連項目
無効なビューとプログラム・ユニットを強制的に再コンパイルする方法の詳細は、『Oracle Databaseアプリケーション開発者ガイド - 基礎編』を参照してください。

オブジェクト名の解決

SQL文で参照するオブジェクト名は、複数の要素をピリオドで区切って指定できます。Oracleでは、次の方法でオブジェクト名が解決されます。

Oracleは、SQL文で参照されている名前の最初の要素を修飾しようとします。たとえば、hr.employeesでは、hrが最初の要素です。要素が1つしかない場合は、その要素が最初の要素とみなされます。
1. 現行のスキーマ内で、オブジェクト名の最初の要素と一致する名前を持つオブジェクトが検索されます。一致するオブジェクトが見つからない場合は、手順bに進みます。
2. 名前の最初の要素と一致するパブリック・シノニムが検索されます。一致するパブリック・シノニムが見つからない場合は、手順cに進みます。
3. オブジェクト名の最初の要素と一致する名前を持つスキーマが検索されます。一致するスキーマが見つかると、手順bに戻り、今度は名前の2番目要素がオブジェクトとして使用され、修飾されたスキーマ内で検索されます。2番目要素が以前に修飾されたスキーマ内のオブジェクトに対応していない場合、または2番目要素が存在しない場合は、エラーが戻されます。
手順cでスキーマが見つからない場合、オブジェクトは修飾できず、エラーが戻されます。
スキーマ・オブジェクトは修飾されています。名前の残りの要素は、見つかったオブジェクトの有効な部分と一致する必要があります。たとえば、
hr.employees.department_idが名前の場合、hrはスキーマ、employeesは表としてそれぞれ修飾され、department_idは1列に対応する必要があります（employeesが表であるため）。employeesがパッケージとして修飾されている場合、department_idはそのパッケージのパブリック定数、変数、プロシージャまたはファンクションに対応する必要があります。

Oracleによる参照の解決では、オブジェクトは、他のオブジェクトが存在しないという事実に依存する場合があります。このような状況は、依存オブジェクトが使用している参照が、別のオブジェクトが存在する場合に異なって解釈される可能性がある場合に発生します。

関連項目
『Oracle Database 管理者ガイド』

共有SQLの依存性管理

スキーマ・オブジェクト相互間の依存性管理に加えて、Oracleは共有プール内の各共有SQL領域の依存性も管理します。表またはビュー、シノニム、順序を生成、変更または削除したり、プロシージャまたはパッケージ仕様部を再コンパイルすると、それらに依存する共有SQL領域もすべて無効になります。共有SQL領域が無効になった後で、その領域に対応するカーソルを実行すると、OracleによってSQL文が再解析され、共有SQL領域が再生成されます。

ローカルおよびリモートの依存性の管理

依存性の追跡や必要な再コンパイルは、Oracleによって自動的に実行されます。ローカル依存性の管理が発生するのは、Oracleが単一データベース内のオブジェクト間の依存性を管理する場合です。たとえば、プロシージャ内の文が、同じデータベース内の表を参照する場合があります。

リモート依存性の管理が発生するのは、Oracleがネットワークを介した分散環境で依存性を管理する場合です。たとえば、Oracle Formsトリガーは、データベース内のスキーマ・オブジェクトに依存する場合があります。また、分散データベースにおいて、ローカル・ビューの定義問合せがリモート表を参照する場合があります。

ローカル依存性の管理

Oracleは、データベース内部の依存性表を使用してローカル依存性を管理します。この表は、スキーマ・オブジェクトごとに依存オブジェクトを追跡し、記録するものです。参照オブジェクトが修正されると、この依存性表を使用して依存オブジェクトが識別され、それらの依存オブジェクトが無効にされます。

たとえば、ストアド・プロシージャUPDATE_SALが表JWARD.employeesを参照している場合を考えます。この表の定義になんらかの変更があると、ストアド・プロシージャUPDATE_SALを含めて、JWARD.employeesを参照するすべてのオブジェクトのステータスがINVALIDに変更されます。そのため、このプロシージャは、再コンパイルされて有効にされるまで実行できません。同様に、ユーザーのDML権限を取り消すと、そのユーザーのスキーマ内の依存オブジェクトはすべて無効になります。ただし、認可が取り消されたために無効になったオブジェクトは、再認可によって有効にできます。その場合は、完全に再コンパイルする必要はありません。

リモート依存性の管理

Oracleは、アプリケーションからデータベースへの依存性と分散データベースの依存性も管理します。たとえば、Oracle Formsアプリケーションには表を参照するトリガーが含まれていたり、ローカルなストアド・プロシージャから分散データベース・システム内のリモート・プロシージャがコールされることがあります。データベース・システムでは、このようなオブジェクト間の依存性を管理する必要があります。関係するオブジェクトの種類によっては、リモート依存性を管理するために別のメカニズムが使用されます。

ローカルおよびリモートのデータベース・プロシージャ間の依存性

ファンクション、パッケージおよびトリガーなど、ストアド・プロシージャの相互間の依存性は、分散データベース・システムにおいてはタイム・スタンプのチェックまたはシグネチャのチェックを使用して管理されます。

動的初期化パラメータREMOTE_DEPENDENCIES_MODEは、タイム・スタンプとシグネチャのどちらでリモート依存性を管理するかを決定します。

関連項目
タイム・スタンプまたはシグネチャによるリモート依存性管理の詳細は、『Oracle Databaseアプリケーション開発者ガイド - 基礎編』を参照してください。

タイム・スタンプのチェック

タイム・スタンプのチェックの依存性モデルでは、プロシージャがコンパイルまたは再コンパイルされるたびに、そのタイム・スタンプ（作成、変更または置換された時刻）がデータ・ディクショナリに記録されます。タイム・スタンプは、プロシージャが作成、変更または置換された時刻の記録です。さらに、コンパイル済プロシージャには、それが参照するリモート・プロシージャごとに、スキーマ、パッケージ名、プロシージャ名、タイム・スタンプなどの情報も含まれています。

依存プロシージャが使用されると、Oracleは、コンパイル時に記録されたリモート・タイム・スタンプと、リモートで参照されたプロシージャのカレント・タイム・スタンプを比較します。比較結果に応じて、次の2つの処理が発生します。

タイム・スタンプが一致すると、ローカル・プロシージャとリモート・プロシージャはコンパイルされずに実行されます。
リモートで参照されたプロシージャのいずれかのタイム・スタンプの比較結果が一致しない場合、ローカル・プロシージャは無効となり、コール元の環境にエラーが戻されます。さらに、新しいタイム・スタンプを持つそのリモート・プロシージャに依存する他のすべてのローカル・プロシージャも無効になります。たとえば、いくつかのローカル・プロシージャがリモート・プロシージャをコールしており、そのリモート・プロシージャが再コンパイルされたとします。ローカル・プロシージャの1つが実行され、リモート・プロシージャのタイム・スタンプと一致しないことがわかると、そのリモート・プロシージャに依存するローカル・プロシージャはすべて無効になります。

ローカル・プロシージャ本体の文によりリモート・プロシージャが実行されると、実際のタイム・スタンプが比較されます。分散データベースの通信リンクを使用してタイム・スタンプが比較されるのは、このときのみです。したがって、ローカル・プロシージャの文のうち無効なプロシージャ・コールより前にあるすべての文は、正常に実行される可能性があります。無効なプロシージャ・コールより後の文はまったく実行されません。コンパイルが必要です。

無効なプロシージャ・コールの実行方法によっては、その前に実行されたDML文がロールバックされます。たとえば、次の例では、PL/SQLブロックの変更全体がロールバックされるため、UPDATEの結果はロールバックされます。

BEGIN
UPDATE table set ...
invalid_proc;
COMMIT;
END;

ただし、次の例では、UPDATEの結果は確定されます。この場合、ロールバックされるのはPROCコールのみです。

UPDATE table set ...
EXECUTE invalid_proc;
COMMIT;

シグネチャのチェック

Oracleには、シグネチャを使用するリモート依存性の機能もあります。このシグネチャ機能の影響を受けるのは、リモート依存性のみです。ローカル依存性は、その環境でいつでも再コンパイルできるため影響を受けません。

プロシージャのシグネチャには、次の項目に関する情報が含まれます。

パッケージ、プロシージャまたはファンクションの名前
パラメータのベース型
パラメータのモード（IN、OUTおよびIN OUT）

注意
重要なのはパラメータの型とモードのみです。パラメータの名前はシグネチャには影響しません。

シグネチャ依存性モデルが有効である場合に、依存単位に親単位のプロシージャへのコールが含まれており、かつ、そのプロシージャのシグネチャが互換性のない方法で変更されていると、リモート・プログラム・ユニットへの依存性により、その依存単位が無効になります。プログラム・ユニットは、パッケージ、ストアド・プロシージャ、ストアド・ファンクションまたはトリガーのいずれかです。

その他のリモート・スキーマ・オブジェクトの間の依存性

Oracleでは、ローカル・プロシージャとリモート・プロシージャの間の依存性を除いては、リモート・スキーマ・オブジェクト間の依存性は管理されません。

たとえば、リモート表を参照する問合せによって、ローカル・ビューを作成して定義するとします。また、ローカル・プロシージャに、同じリモート表を参照するSQL文が含まれているとします。その後、表の定義が変更されたとします。

表の変更後にビューとプロシージャが使用され、そのビューとプロシージャがエラーとなった場合でも、ローカル・ビューとプロシージャは無効になりません。この場合、ビューとプロシージャを、エラーが戻されないように手動で変更する必要があります。このような場合は、依存オブジェクトを不必要に再コンパイルするより、依存性を管理しないことをお薦めします。

アプリケーションの依存性

データベース・アプリケーションのコードでは、接続されているデータベース内のオブジェクトを参照できます。たとえば、OCIおよびプリコンパイラ・アプリケーションは、無名PL/SQLブロックを発行できます。Oracle Formsアプリケーション内のトリガーは、スキーマ・オブジェクトを参照できます。

このようなアプリケーションは、参照するスキーマ・オブジェクトに依存しています。依存性管理の方法は、開発環境によって異なります。

関連項目
データベース・アプリケーション内でリモート依存性を管理する方法の詳細は、アプリケーション開発ツール固有およびオペレーティング・システム固有のマニュアルを参照してください。