インデックスの 「leaf」 構造として以下の 2つのやりかたがあることを、前回、述べた。

　（1） 1つの キー の値に対して 1つの データ・アドレス を対応する。（I-SAM 式あるいは VSAM 式）
　（2） 1つの キー の値に対して複数の データ・アドレス を対応する。（inverted 式）

　いずれのやりかたであれ、「ダイナミック・アロケーション」 を前提にしているので、アドレス は 「相対 アドレス」 （開始点から＋α） を使っている。

　以下の 3つの テーブル を使って、2つのやりかたの違いを例示する。

　（1） 顧客 テーブル
　（2） 受注 テーブル
　（3） 請求 テーブル

　
1. ISAM 式・VSAM 式

　ただ、DB2 も ORACLE も、この構造なので、正規化された データ 構造を実装するためには、「しかるべき」 対応をしなければならない。「しかるべき」 対応というのは 「非正規化する」 などという暴言を吐いているのではなくて、「正当な I/O 削減手段」 を使うことを言っている。この点に関しては、後日、記述する。

　
2. inverted 式

　ただし、キー に対して削除・追加が多ければ、こういう構造は 「揺れる」 ことになるので、パフォーマンス が低下する。キー の削除・追加が多いなら、「物理的な I/O を削減するために」 パイプライン 機能を搭載していなければならない。そうでなければ、こういう構造を使ってはいけない。
　なお、パイプライン 機能については、後日、述べる。

　
3. まとめ

（1） VSAM 式
　1つの テーブル （物理 データセット） に対して 1つの インデックス・ファイル を生成して、「leaf」 の構造は、1つの キー の値に対して 1つの データ・アドレス を対応する やりかた なので、データ の正規形を実装するためには、「I/O を削減する」 手段を考慮しなければならない。