レコード・アット・ア・タイム （record-at-a-time） 法は、データ に対して、キー を使って レコード 単位に アクセス する技術である。主な キー としては、以下のような キー がある。

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

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

[ 注意 ]
　キー と 「indexing」 は違う点に注意されたい。
　キー として使われても 「indexing」 を編成しない キー もある （たとえば、ハッシュ・キー）。

　まず、ネイティブ・キー と マスター・キー を対照して考えてみる。
　ネイティブ・キー は 「（データ を ロード するときに） 物理的な配置を構成する」 キーである。
　マスター・キー は 「一意性の検証をする」 キーである。

　それらの キー の違いを、以下の従業員 レコード を例にして解説する。

　
　つまり、データ は 「社会保険番号」 順に並ぶ。
　そして、もし、新たな従業員が入社して、以下のような データ を作成して従業員 テーブル に追加した、とする。
　　{ 03, 佐藤 敦, 021 }.

　新たな従業員の データ は マスター・キー （「一意性の検証」） が重複することになって、リジェクト （reject） される。

　さて、プロダクト として RDB を作るときに、ネイティブ・キー と マスター・キー は、以下のように扱うことができる。

　（1） ネイティブ・キー と マスター・キー を 1つの キーとして扱う。
　（2） ネイティブ・キー と マスター・キー を、それぞれ、べつべつの キー として扱う。

　ネイティブ・キー と マスター・キー が、どのように扱われているかは、それぞれの プロダクト を調べられたい。

　1つの テーブル （ファイル） に対して、複数の キー を用意したとすれば、それらのなかの 1つが主 キー となって、ほかの キー は二次 キー となるが、主 キー として、マスター・キー が選らばれる。
　キー を設計する際に論点になるのは以下の 2点である。

　（1） キー の値を変更することを認めるのか。
　（2） キー の値が重複することを認めるのか。

　主 キー である マスター・キー は 「一意性の検証」 のために使われるので、以上の 2点は、いずれも、認められない。
　二次 キー に対しては、以上の 2点を認めている。
　言い換えれば、主 キー （マスター・キー） と二次 キー との違いは、「キー 値の変更」 と 「キー 値の重複」 が、いずれも 「no （否定）」 であれば マスター・キー となるし、いずれも 「yes （肯定）」 であれば、一般 キー （ネイティブ・キー および マスター・キー のほかの キー） である、ということである。

　とすれば、プロダクト として RDB を作るとき、「キー 値の変更」 と 「キー 値の重複」 という 2つの パラメータ を用意して、「yes」 または 「no」 （あるいは、「on」 と 「off」） を定義することを ユーザ に任せれば、1つの テーブル に対して、マスター・キー を、かならずしも、定義しないことがあり得る。

　なぜなら、データ は、「row （レコード としてもよい） 全体として一意であればよい」 のであって、キー （および 「indexing」） は データ に対する アクセス 効率の論点であって、データ 解析 （論理 データ 設計） と キー の定義 （物理 データ 設計） を同時に実施して混同してはいけない。

　次回は、「indexing」 について解説する。
　なお、クラスター・キー、ヌル・キー、インヴァーティド・キー および ハッシュ・キー については、後日、説明する。