Previous: テーブルとキー
Up: データベースの論理設計
Next: 第一正規形
Previous Page: テーブルとキー
Next Page: 第一正規形

関数従属

「行が一意に指定可能である」という概念を、もう少し詳しく見るために、少し形式的 な準備をしよう。

関係R上の項目Aと項目Bとの間に、項目Aの値が決まれば、項目Bの値が一意に決まる時 「関係Rにおいて、AはBを一意に決定する」といい、次のような図式で表そう。

　　　　　　　R.A ---> R.B

あるいは、関係Rを強調して、

R(A) ---> R(B)

と書いても良い。関係Rが、前後の文脈から明らかなときには、単に、「Aは、Bを一意 に決定する」といい次のように表す。

A ---> B

反対に、AがBを一意に決定しないときには、

　　　　　　　　A -/-> B

と表記する事にしよう。

この概念を、項目の組の上にも拡張して、もし、関係R上の項目の組 A,B,..,C が、同 じく関係R上の項目の組 X,Y,..,Zを一意に決定するならば、

　　　　　　　( R.A , R.B , ... , R.C ) ---> ( R.X , R.Y , ... , R.Z )　
 あるいは、        R( A , B , ... , C ) ---> R( X , Y , ... , Z )

と表す。もちろん、Rを特に断らなくてもいい場合には、

　　　　　　　( A , B , ... , C ) ---> ( X , Y , ... , Z )

と表記して構わない。特に、全項目の組をRowで表すことにしよう。

こうした形式的な表記法を使って、前節の内容を記述してみよう。 まず、ある項目の組α＝(A,B,..,C)が、「主キー候補キー」であるとは、

　　　　　　　R(A,B,..,C) ---> Row

であることである。これを簡単に、α ---> Row と略記する。 ある項目の組βが、γを一意に決定する最小の組であるとは、

　　　　　　　β ---> γ 
　かつ、　α≦βなる、全てのαについて、α -/-> γ

であることとする。この時、βはγを、強い意味で一意に決定するという。 ある項目の組βが、「強い意味で主キー」であるとは、

　　　　　　　β ---> Row 
　かつ、　α≦βなる、全てのαについて、α -/-> Row

すなわち、βが、行を一意に決定する最小の組であることである。

次の命題が成り立つ。

(i)　　　Row ---> Row
        (ii)     α≦β で　α ---> Row なら β ---> Row
        (iii)    α≦β ならβ ---> α
\begin{verbatim}

\section{データベースの内的整合性}

主キーの設計は、テーブルの設計で重要な意味を持つ。後でみる「高次の正規化」の
問題は、この問題に深い関わりを持つ。

この問題は、後に主題的に論じられるので、ここでは、主キーが満たすべき要件を考
えてみよう。主キーが選ばれれば、「行の一意の指定可能性」は、「主キーの一意
性」に帰着する。これは、重要な要件である。この「主キーの一意性」の系として、
「主キーは、null値をとらない」という要請がうまれる。

リレーショナル・データベースが、現実世界のモデルだという見方にたって、この要請
を、次のように解釈することが出来る。\ 

リレーショナル・データベースがモデルする現実では、実体は相互に識別可能であると
みなされる。リレーショナル・モデルでは、テーブルの各行が一つの実体を表現してい
るのだが、この各行を相互に区別しているのが主キーである。もし、主キーが、NULLで
あるような行がテーブル中に存在すれば、その行は、他の行との区別は出来ないことに
なり、実体は相互に識別可能であるという前提に反することになる。
こうした意味で、この要請は、「実体の内的整合性の規約」と呼ばれる。\ 

外部参照キーについては、それは、他のテーブルの主キーであるので、データベース
の首尾一貫性のために、次のような要請が置かれなければならない。
「テーブルＴの主キーを参照する外部参照キーは、完全にNULLであるか、Ｔ内のいずれ
かの行の主キーの値と一致しているかのいずれかでなければならない。」
なぜなら、Ｔの主キーと一致しない外部参照キーがあるとすれば、それは、Ｔに存在し
ていないある実体を指し示すことになるからである。
こうした意味で、この要請は、「参照の内的整合性の規約」と呼ばれる。

\subsection{データベースの内的整合性と更新が引き起こす問題}

主キーや外部参照キーの更新は、上にみた、データベースの二つの内的整合性にとっ
て、問題を引き起こす危険性があることに留意しておこう。

今、テーブルＡの主キーの内容を更新したとしよう。このキーの内容を、テーブルＢの
フォーリン・キーが参照していたとしよう。そうすれば、テーブルＢのフォーリン・
キーが、テーブルＡのどの主キーの値とも一致しなくなる可能性がある。

こうした参照の矛盾は、テーブルＢに、新しいフォーリン・キーを持つ行を挿入しよう
とした時にも起こりえる。すなわち、このキーが、参照しているテーブルＡの中の、
主キーのいずれの値とも一致しなければ、たちまち、参照の整合性は破られることに
なる。
逆に、主キーの挿入や、フォーリン・キーの削除は、それだけでは、こうした問題を
引き起こさないことも分かる。次表に、問題をまとめておいた。

\begin{verbatim}
PKの挿入　　問題無し
PKの更新　　マッチしているフォーリン・キーは？
PKの削除　　マッチしているフォーリン・キーは？

FKの挿入　　マッチしているプライマリー・キーがなければ不可能
FKの更新　　マッチしているプライマリー・キーがなければ不可能
FKの削除　　問題無し

後に、「トリガー」を論ずるときに、この問題に対する一つの実践的な対応について 見ることになるだろう。