2003年 2月16日 ネイティブ・キー と マスター・キー >> 目次 (テーマ ごと)


 
 レコード・アット・ア・タイム (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」 を編成しない キー もある (たとえば、ハッシュ・キー)。

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

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

 

「従業員」 テーブル
従業員番号 従業員名称 社会保険番号
01 佐藤正美 035
02 稲森いずみ 011
03 佐藤恵美子 040


 
[ 注意 ]
 T字形 ER手法を使った設計では以上のような テーブル 設計はあり得ないが、以上の テーブル 設計は コッド 氏流の正規形を使ったとする。

 以上の データ に対して、以下の キー を定義する。

 (1) 従業員番号を マスター・キー とする。
 (2) 社会保険番号を ネイティブ・キー とする。

 とすれば、データ は 「物理的には」 以下のように並ぶ。

 

「従業員」 テーブル
従業員番号 従業員名称 社会保険番号
02 稲森いずみ 011
01 佐藤正美 035
03 佐藤恵美子 040


 
 つまり、データ は 「社会保険番号」 順に並ぶ。
 そして、もし、新たな従業員が入社して、以下のような データ を作成して従業員 テーブル に追加した、とする。
  { 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」 について解説する。
 なお、クラスター・キー、ヌル・キー、インヴァーティド・キー および ハッシュ・キー については、後日、説明する。

 

  << もどる ベーシックス すすむ >>
  データベースの基礎知識