2003年 3月16日 indexing (VSAM 式 対 inverted 式) >> 目次 (作成日順)


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

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

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

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

 (1) 顧客 テーブル
 (2) 受注 テーブル
 (3) 請求 テーブル

[ 前提 ]


「顧客」 テーブル
顧客番号 従業員名称 データ・アドレス
01 佐藤正美 111
02 稲森いずみ 112
03 佐藤恵美子 113


「受注」 テーブル
受注番号 顧客番号 データ・アドレス
001 01 211
002 01 211
003 03 213


「請求」 テーブル
請求番号 顧客番号 データ・アドレス
0001 01 311
0002 01 312
0003 03 313


 さて、それぞれの テーブル に対して、「顧客番号」 を使って (マスター・キー でも ネイティブ・キー でもない) 一般 キー を定義して インデックス を生成したとする (duplicate-master-key = yes, change-master-key = yes)。

 
1. ISAM 式・VSAM 式

 ISAM 式および VSAM 式は、それぞれの テーブル に対して、それぞれの インデックス・ファイル を生成する。
 つまり、1つの物理 データセット に対して 1つの インデックス・ファイル を生成する やりかた である。
 したがって、インデックス・ファイル は、前述の例では 3つになって、以下のような中味となる。



「顧客」 の インデックス・ファイル
顧客番号 データ・アドレス
01 111
02 112
03 113


「受注」 の インデックス・ファイル
顧客番号 データ・アドレス
01 211
01 212
03 213


「請求」 の インデックス・ファイル
顧客番号 データ・アドレス
01 311
01 312
03 313


 さて、以上の構造であれば、顧客を単位として、顧客情報ならびに受注情報および請求情報を一覧表示するとなれば、それぞれの インデックス・ファイル に対して アクセス しなければならない。
 したがって、正規化すればするほど、I/O が多くなってしまうという弊害がある。

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

 
2. inverted 式

 inverted 式は、複数の物理 データセット に対して 1つの インデックス・ファイル を生成する やりかた である。
 上述の例で言えば、「顧客」 と 「受注」 と 「請求」 の 3つの テーブル に対して、1つの インデックス・ファイル が生成される。つまり、以下のように、1つの キー の値に対して、複数の データ・アドレス を対応する。



inverted 式
顧客番号 データ・アドレス
01 111 211 212 311 312


 つまり、インデックス を使って、テーブル を join しているのと同じ効果がある。
 正規化されて数の多くなった テーブル に対して、インデックス が 1回の I/O を使って join している (統合している) のと同じである。

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

 
3. まとめ

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

(2) inverted 式
 複数の テーブル に対して 1つの インデックス・ファイル を生成して、「leaf」 の構造は、1つの キー 値に対して複数の データ・アドレス を対応するので、インデックス を使って テーブル を join しているのと同じ効果があるが、キー の削除・追加に対しては、「I/O を削減するために」 パイプライン 機能を搭載した データベース を使ったほうがよい



  << もどる HOME すすむ >>
  ベーシックス