このドキュメントでは、次のトピックについて説明します。
ディスクリプタは、ユーザー指定の検索条件に依存してファイルからレコードを選択したり、論理順次読み込みを制御するために使用します。 したがって、ディスクリプタの使用はファイルに対するアクセス方法に密接に関係します。 各ディスクリプタについて、ディスクスペースも、処理オーバーヘッドも余計にかかります。更新が頻繁なときは特にそうです。 ファイルに対して、どのタイプのディスクリプタをいくつ定義するかについては、次の点を考慮します。
あるフィールドの処理を継続する前にデータを再び並び替える必要がある場合、照合ディスクリプタを定義することができます。
ファイル内のレコード総数に対して少ない比率のレコードを選択するのに使用できるようなディスクリプタフィールドの値の配分にします。
既存のディスクリプタを使用して非常に少ない数のレコードを選択できる場合、検索条件をすっきりするためにディスクリプタを追加定義しないでください。
2 つか 3 つのディスクリプタが頻繁に組み合わせて使用される（例えば地域、部、課）ときは、別々のディスクリプタで定義せず、スーパーディスクリプタとして定義することができます。
あるディスクリプタについての選択条件がいつも値の範囲を含むときは、サブディスクリプタを使用することができます。
あるディスクリプタについての選択条件が空値指定を含まず、このディスクリプタについて空値が多いときは、空値省略（NU）オプションを定義する必要があります。
更新の頻繁なフィールドは、ディスクリプタとして定義しないでください。
更新量が多い（大量の追加や削除）ファイルは、ディスクリプタ数を多くしないでください。
照合ディスクリプタは、ディスクリプタフィールド値を、ユーザーが提供したアルゴリズムに基づいた特別なシーケンスでソート（照合）するために使用されます。 英数字フィールドまたはワイド文字フィールドを照合ディスクリプタの親フィールドとして定義することができます。
特別な照合ディスクリプタユーザー出口は、ADARUN パラメータ CDXnn（CDX01～CDX08）で指定されます。 ユーザー出口は、照合ディスクリプタ値をエンコードするために、または本来のフィールド値にデコードするために使用されます。 各照合ディスクリプタはユーザー出口に割り当てられなければならず、単一のユーザー出口は複数の照合ディスクリプタを処理します。
スーパーディスクリプタは 20 個までのフィールド（またはフィールドの一部）の組み合わせによるディスクリプタです。 スーパーディスクリプタを構成するフィールドは、ディスクリプタであってもなくてもかまいません。 検索条件が値の組み合わせを含むとき、通常のディスクリプタを組み合わせるよりもスーパーディスクリプタを使用した方が効率が良くなります。 これは、Adabas がインバーテッドリストを複数ではなく 1 つだけアクセスするだけで済み、また複数の ISN リストを AND で結合して最終的な該当レコードのリストを生成する必要がないからです。 スーパーディスクリプタは、ファイルの論理順次読み込みの順を制御するのに通常のディスクリプタと同じように使用できます。
スーパーディスクリプタを含む検索条件に対する値は、スーパーディスクリプタのフォーマットと同じでなければなりません（構成フィールドがすべて数値のときバイナリ、そうでないときは英数字）。 スーパーディスクリプタのフォーマットがバイナリのとき、Natural のような問い合わせまたはレポート機能を使用して選択条件値を入力するのは難しくなります。
スーパーディスクリプタの定義については、ADACMP ドキュメントの「SUPDE：スーパーディスクリプタの定義」を参照してください。
フィールドの一部から作られるディスクリプタをサブディスクリプタといいます。 サブディスクリプタの元のフィールドはディスクリプタであってもなくてもかまいません。 検索条件が、英数字フィールドの先頭 n バイトまたは数値フィールドの最後の n バイトを対象とするとき、そのフィールドの関連バイトだけからサブディスクリプタを定義できます。 こうすると、検索条件では値の範囲の代わりに 1 つの値だけを指定すればよく、 Adabas は中間の ISN リストを作りマージする必要がないので効率を上げることができます。
例えば、AREA が 8 バイトの英数字フィールドであり、先頭 3 バイトで地域、後 5 バイトで部門を表わすとします。 地域が 111 のレコードだけが必要であるとき、サブディスクリプタを使用しない場合は AREA = 11100000 THRU 11199999 という検索条件が必要になります。 AREA の先頭 3 バイトをサブディスクリプタと定義すれば、REGION = 111 という検索条件を指定することができます。
フォネティックディスクリプタはフォネティック検索を行うために定義します。 FIND コマンドでフォネティックディスクリプタを利用すると、同じフォネティック値を含む全レコードが返ります。 ディスクリプタのフォネティック値はフィールド値の先頭 20 バイトに基づくもので、英字の値のみが考慮されます（数値、特殊文字および空白は無視されます）。
ハイパーディスクリプタオプションを使用するとユーザーが提供するアルゴリズムに基づいてディスクリプタ値を生成できます。 単一の物理 Adabas データベースごとに 31 個までの異なるハイパーディスクリプタを定義できます。 使用するジョブの ADARUN ステートメントパラメータで適切な HEXnn を指定して各ハイパーディスクリプタに命名しなければなりません。
ハイパーディスクリプタは n 個から構成されるスーパーディスクリプタ、派生キー、またはその他のキー構造を実装するために使用できます。 ハイパーディスクリプタの詳細は、ユーザーおよびハイパー出口に関するドキュメント、および『Adabas ユーティリティマニュアル』の「ADACMP ユーティリティ」の記述を参照してください。
ファイルカップリングにより、1 つの FIND コマンドで指定の値を含むある別ファイルのレコードに関係する（カップリングされた）あるファイルのレコードを選択できます。 例えば、CUSTOMER ファイルと ORDERS ファイルがあり、それぞれ顧客情報と注文情報が含まれているとします。 各ファイルは共通のディスクリプタ顧客番号（CUSTOMER_NUMBER）を持ち、これによりカップリングされています。
この 2 ファイルは ADAINV ユーティリティによりカップリングされており、CUSTOMER ファイルのレコードと ORDERS ファイルのレコードとを互いに関連付ける（同一顧客番号を持つ）カップリングインデックスが、1 組のインバーテッドリスト内に存在します。 ファイルがカップリングされると、どちらのファイルのディスクリプタを使用しても 1 つの FIND コマンドで検索できます。例えば次のように指定します。
FIND CUSTOMER WITH NAME = JOHNSON
AND COUPLED TO ORDERS
WITH ORDER-MONTH = JANUARY 物理カップリングは、ファイルの更新が少ないか、カップリングリストのオーバーヘッドがかかっても、問い合わせの簡単さと比較して問題にならなければ有効です。 また問い合わせの元になるファイルで、小さいファイルについても有効です。
ファイルの更新頻度が高いと、物理カップリングに対するオーバーヘッドがかなりの量になります。 いずれかのファイルのレコードが追加／削除されたり、カップリングの元になるディスクリプタの更新が起きると、カップリングリストも更新しなければなりません。
物理カップリングは、カップリングインデックス用のディスクスペースも必要です。 必要な容量はカップリングされるレコード数に依存します。 カップリングディスクリプタが一方のファイルのユニークキーになっていると最良です。 つまり、別ファイルのある 1 レコードにカップリングされるあるファイルのレコードが少ないことを示します。 最悪のケースはファイル間に多対多の関係が存在する場合です。 このとき、両ファイルとも、レコードにカップリングされるレコード数が大きくなってしまいます。
カップリングの基本として使用するディスクリプタは、通常、空値省略オプションとして定義する必要があります。こうすればこのディスクリプタが空値のレコードはカップリングインデックスに含まれません。
その他カップリング使用については、『Adabas ユーティリティマニュアル』「ADAINV ユーティリティ」の説明を参照してください。
複数ファイルの問い合わせは、ファイル間の結合に使用するフィールドを検索条件に指定することもできます。 この特徴は論理カップリングと呼ばれ、ファイルは物理的にカップリングされている必要はありません。
この手法には読み込みコマンドが必要ですが、物理カップリングリストが不要なため、カップリングディスクリプタに変更の多い場合には効果があります。 ユーザープログラムには、ソフトカップリング結合に使用するフィールドと、検索条件だけを指定すればよいというのも重要です。 Adabas がすべての必要な検索、読み込み、内部リストのマッチング操作を行います。
ファイル内の各レコードの ISN は、通常、Adabas が自動的に割り当てますが、オプションとしてユーザーが割り当てることもできます。 このことにより、インバーテッドリストを使用せず直接 ISN を使用して検索することが可能となります。 ただし、ユーザー自身が ISN 割り当てのアルゴリズムを開発しなければなりません。 結果 ISN は、ファイルのロード時に ADALOD ユーティリティで指定された MINISN および MAXISN パラメータ値の範囲内にする必要があります。
インバーテッドリストを使用せずに、直接関係レコードを読むために、レコード内に関係レコードの ISN を格納してもかまいません。
例えば、注文レコードを 1 つ読み、この注文に対する全顧客レコードを選択して読み込むアプリケーションを考えます。 顧客レコードの ISN（1 注文レコードに複数の顧客があるとき、マルチプルバリューフィールドを使用できます）を注文レコードに格納すると、注文レコード内の ISN を使用して関連顧客レコードを直接読むことができます。
こうすればその注文に関する顧客レコードを探すのに顧客ファイルに FIND コマンドを発行する必要がなくなります。 この手法では顧客レコードの ISN を含むフィールドを注文レコード内に保持する必要があり、顧客ファイルの ISN はファイルのアンロード／リロードで変えられることはないと仮定しています。
Adabas ダイレクトアクセスメソッド（ADAM）を使用すると、インバーテッドリストをアクセスせずにデータストレージから直接レコードを検索できます。 レコードが格納されているデータストレージブロック番号は、レコードの ADAM キーに基づきランダマイジングアルゴリズムを使用して計算されます。 ADAM は、アプリケーションプログラム、クエリおよびレポートライタの機能に対して完全に透過的に使用されます。
ADAM キーの値はユニークでなければなりません。 レコードの ISN を ADAM キーとして使用してもかまいません。
ADAM ファイルのアクセス処理はかなり速いのですが、ADAM ファイルのロードや ADAM ファイルへの新レコードの追加は、一般に一連の新レコードが同一ブロックに格納されることはないので、標準ファイルよりも時間がかかります。
ADAM ファイルはランダムにも論理順にも処理されるなら、ADALOD ユーティリティのビット切り捨て機能を使用して論理順次処理を最適化できます。 この機能を使用すると各 ADAM キーの右側を指定ビット数だけ切り捨てて、ランダマイジングアルゴリズムへの入力にすることができます。 したがって、キーの値の左側が似ているレコードは、同じデータストレージブロックに格納されます。
切り捨てるビットが多過ぎるとオーバーフローレコード数が増し、ランダムアクセスのパフォーマンスが低下するので注意する必要があります。 この原因は、ADAM キーを使用して配置されたブロックに格納できないオーバーフローレコードが、標準インバーテッドリスト処理で他のブロックに格納されるからです。オーバーフローレコードもインバーテッドリストを使用して配置しなければなりません。 他にオーバーフローを最小にする方法はファイルとパディングファクタサイズを相対的に大きく指定することです。
インバーテッドリストを使用した検索では 3～4 回の I/O が必要ですが、ADAM では一般的に平均 1.2～1.5 回の I/O で済みます。この平均には、アソシエータの制御下でファイルの他のブロックに格納されたオーバーフローレコードの平均も含まれています。 オーバーフローレコードについては、通常のインバーテッドリスト経由の検索を行います。
したがって、ADAM ファイルのパフォーマンスは使用可能ディスクスペース（スペースが多いほど、インバーテッドリスト付きで配置する必要のあるオーバーフローレコードは少なくなります）と ADAM キーから切り捨てるビット数、レコードの追加／更新処理の量により決まります。 ディスクスペースと切り捨てビット数との各種組み合わせに対する平均入出力回数は、ADAMER ユーティリティを使用して調べることができます。 詳細は、『Adabas ユーティリティマニュアル』を参照してください。