● キー の種類

　主な キー としては、以下のような キー があることを前述した （192 ページを参照されたい）。

　　（1） ネイティブ・キー （the native-key）
　　（2） マスター・キー （the master-key）
　　（3） 一般キー （keys）──ネイティブ・キー および マスター・キー を除いた キー （通常、secondary-keys）
　　（4） クラスター・キー （cluster-key）
　　（5） ヌル・キー （null-key）
　　（6） インヴァーティド・キー （inverted-key）
　　（7） ハッシュ・キー （hash-key）

　（1） から （6） までは、「indexing」 編成を構成する キー であるが、（7） は 「indexing」 を編成しない キー である。

　以上の キー のなかで、唯一、不可欠の キー は ネイティブ・キー である。
　なぜなら、データ を ロード したときに物理的な配置をきめる キー だから。

　ネイティブ・キー 以外の キー は、RDB に対して 「アクセス の効率を図るための外付けの キー」 であって、RDB の internals とは無関係である。したがって、データ 設計の段階において、マスター・キー を使って 「一意性の検証」 を前提して データ を設計することは避けなければならない。なぜなら、データ は全体 （row） の値が一意であれば良いのであって、アクセス の効率はべつの論点である。

　
● ネイティブ・キー と マスター・キー

　flat-file に対しては、マスター・キー と一般 キー の関係が primary と secondary という関係にはならない。キー は、すべて、対等の キー である （duplicate-master-key ＝ yes, change-master-key ＝ yes）。そして、一意性を検証したいのであれば、1つの テーブル に対して 1つ （one and only） の マスター・キー を一般 キー のなかから生成することができる（duplicate-master-key ＝ NO, change-master-key ＝ NO）。
　マスター・キー は、RDB の internals に対して関与しないべつの論点であって、一般 キー のなかから マスター・キー を生成しても良いし生成しなくても良い──ただし、プロダクト によっては、マスター・キー （ユニーク・キー） を、あらかじめ、a must として定義しなければならない物もある。
　[ 192ページ を参照されたい。]

　
● クラスタ・キー

　クラスター・キー は物理的な再編成のための キー であるから、データ は、すでに、ネイティブ・キー を前提にして物理的に配置されているので、クラスター・キー は ネイティブ・キー を前提にして生成される。
　[ 208ページ を参照されたい。]

　
● ヌル・キー

　ヌル・キー は キー の値をヌル値にできる キー であるが、ネイティブ・キー および マスター・キー に対して ヌル （null） を代入することはできない。したがって、ヌル・キー は一般 キー に対して適用される。

[ 参考 ]
　ヌル・キー は B-tree 構造から排除されることが前提になる。
　この点に関しては、後日、記述する。

　
● indexing

　以上の キー を使って indexing が編成されるが、indexing は B-tree 構造を基本形として、VSAM 式と inverted 式があることは前述した。
　[ 196ページ と 200ページ を参照されたい。]

　
● ハッシュ・キー

　ハッシュ・キー は indexing ではないので──しかも、パフォーマンス が良いので──、RDB の internals に適用することができる。たとえば、デッドロック を回避するために、データ の アクセス を監視する内部 テーブル には ハッシュ・キー が使われる。
　[ 204ページ を参照されたい。]

　
● まとめ （キー の系統樹）

　以上に述べたことをまとめれば、
　ネイティブ・キー が基底になって、その他の キー は、すべて、一般 キー （keys） である。
　そして、アクセス の観点から言えば、その一般 キー のなかから 「一意性の検証をするための」 キー を生成することができるし、ヌル・キー を使うことができる。また、データ の物理配置の観点から言えば、クラスター・キー は ネイティブ・キー を前提にしている。