索引順編成ファイル　その１

１　索引順編成ファイルとはどんなファイルか

最初に注意しておきますが、ＮＥＣのオフコンの索引順編成ファイルは、通常世間一般に索引編成、索引順編成と言われているファイル形式とはかなり異なります。普通の索引順編成ファイルの簡易版といった感じです。

あるキーで検索してそのキーに対応するデータを読み込んだり、書き換えたりできるファイルです。キーは１種類だけでレコード中に連続した領域になければなりません。

１つのファイル中に索引部と呼ばれる部分とデータ部と呼ばれる部分がある構造のファイルになります。実際のデータ（例えば顧客の名前や売り上げ金額とか）はデータ部に入っています。
索引部には、索引キーと実際のデータが入っているレコードへのポインタの組（索引エントリという）がレコード数分入っています。索引エントリはキーの昇順に並んでいます。

全ての索引エントリはポインタを介して対応するレコードにリンクされています。
あるキーで読み込みを行うと、たくさんある索引エントリの中からその索引キーの入ったエントリを探し出し、ポインタでリンクされているレコードの情報を読み込むという動作をします。

＜データ部＞
データ部は、ＥＯＤがあります。他のファイルとの違いとして、順編成や相対編成ファイルはデータを書き込むとアドレスの低位番地から高位番地にＥＯＤが移動するのに対して、索引順編成ファイルは高位番地から低位番地にＥＯＤが移動する点です。

データを削除すると、順編成ファイルや相対編成ファイルと同様に削除レコードが発生します。順編成や相対編成ファイルと異なるのは、ファイル再編成をしなくても削除レコードは自動的に再利用されるということです。（削除レコードチェインで管理してうまく再利用している。）

＜索引部＞
索引エントリは複数集まって索引ブロックを構成しています。索引部は複数の索引ブロックの集合になっています。
索引エントリは昇順に格納されており、レコードの削除、追加があるとその度に昇順になるように再編成が行われます。

２　索引ブロックの仕組み

索引順編成ファイルを作る時に、使用効率というパラメータがあります。
これが何かを説明するためには、索引ブロックの仕組みを説明する必要があります。

基本的に索引部はＢ＋ツリー構造になっています。
索引ブロックは第一レベルの索引ブロック、第二レベル以降の索引ブロック、最下位レベルの索引ブロックに別れています。
最下位レベルの索引ブロックに索引エントリが入っています。それ以外の索引ブロックには１つ下位の索引ブロックへのポインタが入っています。

レコード（データ）をどんどん追加していくと、索引エントリが増えていき、そのうちに索引ブロックに入りきらなくなります。そうなると新しい索引ブロックを１個作り、オーバーフローした索引ブロック中の索引エントリを２つの索引ブロックに分けます。

具体的に例で説明します。

９個の索引エントリの入る索引ブロックがあるとします。最初は全ての索引エントリは未使用状態とします。

今データを入力したため、レコードを登録し、そのキーを索引部に登録することになりました。
索引エントリにキーＡが登録されました。

次々にデータ入力がされ、索引エントリにキーが登録されていきます。

索引ブロックが満杯になってしまいました。この状態でさらにキーを登録しようとすると、キー分割が行われます。

新しく索引ブロックが作られ、索引エントリが２つの索引ブロックに振り分けられます。
この振り分け方を指定するのが、使用効率というパラメータです。
使用効率が５０％のとき、２つの検索ブロックに半分ずつ振り分けられます。

使用効率１００％で指定した場合は、下の図のように元の索引ブロックは１００％使用された状態、新しい索引ブロックに新しく登録したキーが登録された状態となります。

３　キー

索引順編成ファイルで登録できるキーの数は１個だけです。キーは連続した領域になければなりません。

索引順編成ファイルを作る時に、既に登録済みのレコードと同一のキー値を持つレコードをさらに追加できるかどうかを指定できます。同一のキー値を許す場合「二重キーあり」でファイルを作ります。同一のキー値を許さない場合は「二重キーなし」でファイルを作ります。
ファイルを作った後に「あり」を「なし」にしたり、逆に「なし」から「あり」に変更することはできません。

二重キーありにすると二重キーを管理するための「補足レコード」というものが作られ、そのレコードへのポインタ用（チェーンフィールド）にデータレコードの長さが８バイト増えます。

４　索引順編成ファイルの作成

ファイルの作成をする時には、作るファイルの大きさに気をつける必要があります。１つのファイル中に索引部とデータ部が入るので、順編成ファイルのようにデータ分のサイズを用意すればいいのではなく、索引部も含めたサイズでファイルを作らなければなりません。

索引順編成ファイルはファイル作成後にエクステントの拡張や追加はできないので、後からファイルサイズを動的に増やすということはできません。最初にファイルを作る時のファイルサイズが重要になります。ファイルがオーバーフローしたら、別の大きなファイルをもう１個作り、そこに全データをコピーしていくことになります。

索引順編成ファイルはマルチエクステント構成を取ることができないので、作ることのできる最大のファイルサイズは１エクステント分即ち1,048,575セクタまでとあまり大きなファイルはつくれません。

５　処理モード

３種類の処理モードが使えます。

＜入力処理モード＞
レコードを読み込むモード。ファイルに対する書き込みは一切できない。

＜出力処理モード＞
入力処理モードとは逆に、ファイル先頭からレコードを順番に書き込むモード。前に書いたレコード（データ）は上書きされて残らない。ファイルからの読み込みは一切できない。

＜更新処理モード＞
レコードの書き込みや読み込み、レコードの内容を置換したり、レコードの追加や削除をすることができる。

６　アクセスモード

索引順編成ファイルは順アクセスモード、乱アクセスモード、動的アクセスモードという３種類のアクセスモードを持ちます。

アクセスモード	概　要
順アクセス	索引エントリの順番にアクセスする。順編成ファイルや相対編成ファイルが物理順にアクセスするのに対して、索引順ファイルは索引部を参照して論理順にアクセスすることが異なる。二重キーが「あり」で同一キーのレコードがある場合は、チェーンフィールドを参照して同一キーレコードを論理順にアクセスする。
乱アクセス	索引部を指定してレコードを直接読み込むことができる。同一キーレコードがある場合は、同一キーを持つレコードのうち、最初に記録されているレコードを読み込む。（２番目以降は読み込めないので、２番目以降の同一キーレコードが必要な場合は動的アクセスモードを使用する。）
動的アクセス	特定のレコードを乱アクセスで読み込み、その後連続するレコードを順次的に読み込む。乱アクセスモードと順アクセスモードの組み合わせ。

７　レコードの位置づけ

乱アクセスと動的アクセスでは位置付づけ命令で特定のレコードに位置付けて、そこから順番にレコードを読み取ることができます。

• 指定したキーをもつレコードに位置付ける。指定したキーを持つレコードがない場合は、レコード未発見のエラーになる。
• 指定したキーを持つレコードまたは指定したキーより大きなキーをもつレコードに位置付ける。条件を満足するレコードがなかった場合は、レコード未発見のエラーになる。
• 指定したキーより大きなキーをもつレコードに位置付ける。条件を満足するレコードがなかった場合は、レコード未発見のエラーになる。

位置付け命令に続いて順次的な読み取り命令を出すことによって、位置づけたレコードを読み取ることができます。

８　オーバーフロー

索引順編成ファイルはエクステントの拡張／追加もできず、削除レコードも自動的に再使用される仕組みであるので、順編成ファイルや相対編成ファイルのようなオーバーフロー回避手段は取ることができないため、オーバーフローになった場合は、さらに大きなファイルに作り直すしか手がありません。

これはかなり運が悪い時にだけに起きるらしいのですが、索引順編成ファイルの特性上、まれに一旦ファイルオーバーフロー状態になるといくらレコードを削除してもなかなかオーバーフロー状態を解除できなくなってしまうことがあるそうです。大量のレコードを削除する（削除キーブロックができるとオーバーフロー状態を解除できる）か、オーバーフローになったファイルは捨ててもっと大きなファイルを作り直すことでオーバーフローを解除します。これは仕様らしいので、このようになったら諦めてがんばって復旧するしか方法はないようです。（オーバーフローになる直前のレコード追加でキー分割が発生し、中途半端に未使用セクタが残ると起きるらしい。これはダメじゃないのかという気がしますが・・・。）

９　ファイル／ブロック形式

レコードの桁数は、５〜４０９６（フロッピーディスクの場合５〜５１２）

ブロック化係数は、１〜２５６
ブロックの桁数は、５〜４０９６（フロッピーディスクの場合５〜５１２）

索引キー長の桁数は、１〜２４３（フロッピーディスクの場合１〜３２）
索引キーはレコード内の連続した領域に必ず１つ存在しなければなりません。

有効な値は、先頭が１６進数ＦＦ以外の文字列

１０　索引順編成ファイルを使用する場合

索引順編成ファイルは、削除レコードが自動的に再利用されるという利点はありますが、あまり大きなファイルが作れない、エクステントの拡張／追加ができない、未クローズ発生時の復旧が面倒、強制読み出し機能が使えない、削除レコードが読み出せない、と欠点がたくさんあります。複数索引順編成ファイルがあるので、索引順編成ファイルはなるべく使用しないのがよろしいかと思います。

索引順編成ファイルは、複数索引順ファイルを利用するまでもないような比較的小サイズのデータで乱アクセスは行うが、使用中のデータの追加や削除が少ない、といった用途に使用するとよいでしょう。