サブプログラムは、特定の問題を解決したり、関連する一連のタスクを実行したりするために、多数のSQL文やPL文を含むPLユニットです。
サブプログラムにはパラメータを含めることができ、具体的な値は呼び出し元から渡されます。サブプログラムはストアドプロシージャまたは関数のいずれかになります。典型的な使い方としては、ストアドプロシージャを用いて操作を行い、関数を用いて計算を行って値を返すことが挙げられます。
ストアドサブプログラムはデータベース内部に格納されるサブプログラムであり、多様なデータベースアプリケーションにおいて複雑な論理演算を実装します。ストアドサブプログラムには以下の3種類があります：
独立サブプログラム：スキーマ内に作成されるサブプログラムです。
パッケージ内部のサブプログラム：パッケージ本体内部に作成されるサブプログラムです。
ネストされたサブプログラム：PLブロック内に作成されるサブプログラムです。
独立サブプログラムはプログラムロジックのテストに便利ですが、大量のサブプログラムは管理が面倒です。そのため、プログラムロジックが確定した後は、独立サブプログラムを業務モジュールごとに異なるパッケージに配置することを推奨します。
サブプログラムは、プログラムパッケージやトリガーなど、他の保守性機能の重要な構成要素です。
サブプログラムの構造
サブプログラムは、サブプログラムのヘッダーで始まり、そのヘッダーには名前とパラメータリスト（オプション）が指定されます。
サブプログラムの構造はPLブロックの構造と一致しており、以下を含みます：
宣言部（オプション）
宣言部には型、定数、変数、例外、明示カーソル、ネストされたサブプログラムの宣言が含まれます。これらの項目はサブプログラムにとってローカルなものであり、サブプログラムの実行終了とともに存在しなくなります。
実行部（必須）
実行部には代入文、制御文、データ操作文が含まれます。
例外処理部（オプション）
例外処理部には、例外（ランタイムエラー）を処理するコードが含まれます。
サブプログラムにコメントを追加すると、プログラムの可読性が向上します。コメントはサブプログラム内の任意の場所に記述でき、コンパイラはコメントを無視します。1行コメントは二重バッテン記号（--）で始まり、行末で終わります。複数行コメントはスラッシュとアスタリスク（/*）で始まり、アスタリスクとスラッシュ（*/）で終わります。
ストアドプロシージャの構造は以下のとおりです：
PROCEDURE name [ ( parameter_list ) ]
{ IS | AS }
[ declarative_part ]
BEGIN -- 実行部の開始
statement; [ statement; ]...
[ EXCEPTION ]
exception_handler; [ exception_handler; ]... ]
END;
関数の構造は以下のとおりで、ストアドプロシージャと比較して、1つ以上の RETURN 句が追加されています：
FUNCTION name [ ( parameter_list ) ] RETURN data_type [ clauses ]
{ IS | AS }
[ declarative_part ]
BEGIN
statement; [ statement; ]...
[ EXCEPTION ]
exception_handler; [ exception_handler; ]... ]
END;
ストアドプロシージャと関数では、IS | AS の間のコードがサブプログラムの宣言であり、宣言部、実行部、例外処理部がサブプログラムの内容本体です。
サブプログラムの利点
クライアントプログラムと比較して、サブプログラムには以下の利点があります：
パフォーマンスの向上
ネットワーク転送によるコストを削減できます。事前にコンパイルしてキャッシュメカニズムでキャッシュすることも可能で、実行時のパフォーマンス消費を削減できます。
メモリ消費の削減
データベースの共有メモリ機構により、複数のユーザーが同じストアドプロシージャを実行する際のメモリ消費が削減されます。
生産性の向上
ストアドプロシージャはユーザーのコードロジックを簡略化し、生産性を向上させることができます。
セキュリティの向上
ストアドプロシージャの権限情報を指定することで、セキュリティを向上させることができます。
継承性のあること
ユーザーは権限を取得することで、他のユーザーが定義したストアドプロシージャにアクセスできます。
サブプログラムの実行
サブプログラムは以下の3つの方法で実行できます：
クライアントツール（OBClient）を使用する
アプリケーション内で直接サブプログラムを呼び出す
サブプログラムまたはトリガー内で呼び出す
依存関係管理
サブプログラムのパッケージ本体で参照されているオブジェクトが、そのサブプログラムの依存オブジェクトを構成します。データベースはこれらの依存関係を自動的に追跡および管理します。
例えば、ユーザーがサブプログラムが依存するテーブル定義を変更した場合、サブプログラムは再コンパイルされ、サブプログラムが依然として有効かどうかを判断する必要があります。通常、このような依存関係の変更後のサブプログラムの再コンパイルは、データベースの依存関係管理ユニットによって自動的に完了します。