2003年 4月16日 | クラスタ・キー | >> 目次 (作成日順) |
(1) 分離格納式 (複数 テーブル を 1つの物理 データセット のなかに co-locate するやりかた) 分離格納式は、複数の論理 ファイル を 1つの物理 データセット 内に分離格納する やりかた であり、JOIN 式は、複数の論理 ファイル を join して 1つの物理 データセット を生成する やりかた である。 分離格納式は、大型汎用機系の データベース に搭載され (たとえば、DB2/MVS や DATACOM/DB など)、JOIN 式は、オープン 系の データベース に搭載されている (たとえば、ORACLE)。 [ 前提 ]
(1) 従業員番号 (EMP-NO、5桁) は部門 コード (2桁) と連番 (3桁) 構成されている。
(2) 1つの物理 データセット のなかに 2つの テーブル が格納されている。 (3) 従業員番号が ネイティブ・キー および マスター・キー として定義されている。
(4) 1つの データ・ブロック には 3つの レコード を格納することができる。 さて、以上の前提にして、社長室に新たな データ (従業員番号 「01005」) を追加する (以下の図を参照されたい)。 分離格納式は、最初に、追加される データ の キー 値 (ネイティブ・キー および マスター・キー) がすでに存在していないかどうかを検証して、同一の キー が存在していないなら、次に、既存の データ を納めている ブロック のなかに 「空き エリア」 があるかどうかを検証する。 「空き エリア」 があれば当該 ブロック のなかに新規の データ を追加するし、「空き エリア」 がなければ、他の ブロック のなかに格納する。
分離格納式を使う理由は、それぞれの テーブル のなかに納められている データ の シーケンス (native-sequence) を保証しながら、かつ、複数の テーブル 間の データ の シーケンス を実現するためにある。 ただし、「複数 FILE = 1 AREA」 式は、「ディスク・スキップ の負荷」 および 「障害修復の迅速性」 という難点がある。 |
テーブル 名称 | EMP-NO | EMP-NM | cluster-key |
HNB | 01 001 | 佐藤正美 | 001 |
01 002 | 佐藤恵美子 | 001 | |
slack-area | |||
DSJ | 02 003 | 佐藤 敦 | 001 |
02 004 | 佐藤 剛 | 001 | |
slack-area |
HNB に納められる | 01 005 | 佐藤大地 | 001 |
[ 前提 ] (1) 部門 テーブル と従業員 テーブル が存在する。 (2) それぞれの テーブル は、更新 (UPDATE) が少ないが照会 (READ) が多い。 |
unclustered | |||
従業員 テーブル | 部門 テーブル | ||
EMP-NO | DEP-CD | DEP-CD | DEP-NM |
100 | 02 | 01 | A |
102 | 01 | 02 | B |
103 | 02 | ||
104 | 02 | ||
105 | 01 |
clustered | |||
部門. 従業員 | |||
DEP-CD | DEP-NM | EMP-NO | |
01 | A | 102 | |
105 | |||
02 | B | 100 | |
103 | |||
104 |
(1) I/O を削減できるので、照会に対して高 パフォーマンス を実現できる。
しかしながら、更新が多ければ、マージ された テーブル が物理的に再編成されるので、パフォーマンス が悪くなる。
[ 参考 ]
(1) 分離格納式
(2) JOIN 式
さて、いずれにしても、クラスタリング は使わないほうが良い。 |
<< もどる | HOME | すすむ >> | |
ベーシックス |