サブルーチンは、特定の問題を解決したり、関連する一連のタスクを実行したりするために、多数の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）の使用
アプリケーション内で直接サブルーチンを呼び出す
サブルーチンまたはトリガー内で呼び出す
依存関係管理
サブプログラムのパッケージ本体で参照されているオブジェクトは、そのサブプログラムの依存オブジェクトを構成します。データベースはこれらの依存関係を自動的に追跡および管理します。
例えば、ユーザーがサブプログラムが依存するテーブル定義を変更した場合、サブプログラムが依然として有効かどうかを確認するため、サブプログラムは再コンパイルされなければなりません。通常、このような依存関係の変更後のサブプログラムの再コンパイルは、データベースの依存管理ユニットによって自動的に実行されます。