外部キー制約

データベーススペシャリスト試験(DB)[Database Specialist Examination]というのがあったりして、何をテストするんだかという感じですが、データベースにはそれぞれの概念にそれぞれの名前がついています。その中に外部キー制約というものがあります。
その前に主キー制約というものがあります。これは、あるひとかたまりのデータを識別できるようにするためのデータの整理方法です。住所録を考えましょう。田中太郎さんがいたとします。彼は一個人でありますが、世の中には同姓同名がたくさんおります。田中太郎さんはもしかたら複数人いるかもしれません。その際に同じ住所録に二人の人間を登録すると識別ができなくなります。彼は全く別々の顔しているに違いないし全く別々の人生を歩んでいます。しかも東京都に住んでいたらさらに区別が付きません。当然見ず知らずの役所の人間などがデータを扱うときにはどっちの田中太郎さんなのか全く区別がつきません。そのようなときにはそのデータにユニークなIDなどを振ります。連番でもいいでしょう。123番の番号をもった田中太郎さんと321の番号をもった田中太郎さんだとすると識別できるはずです。先日住民票をとりにきたのは123の田中太郎さんで、税金をまだ払っていないのが321の田中太郎さんであるという風にです。
さて住所録の場合は各個人がレコードという単位で1つのデータをもつことになりますが、そのレコードには住所電話番号、性別、年齢、生年月日と様々な情報を格納しています。そのレコードにIDという固有の番号や記号を割り振るわけです。
私の祖父は1月1日生まれでした。しかしこれは戦時中のごたごたで誕生日がわからなくなってしまったわけです。彼は誕生日という情報が実際にはないのでブランクです。便宜的に1月1日にしていました。また、同様に性同一障害の人は男女という性別の情報が入れられないかもしれない。というのも極端な話しですが、データにはNULLというように「無し」というデータを入れることがあります。そのレコードに子供の情報を格納するかもしれません。子供のいない人は「無し」になります。そういうデータがその中には存在します。主キー制約はそのようなデータの性質から考えだされたものです。つまり、各個人を識別するための主キーは「無し」にすることはできない、絶対に無しであってはならないデータということになります。これは絶対的な約束であり、そういう「制約」を設けなければ先にあげたようにデータとしての整合性が保てないということになります。これを主キー制約(
Primary key constraint)としてデータ整理の約束にします。これを主キー制約という概念としているわけです。(試験に出ます。)
いっぽう外部キー制約とは何かという話しになると、これまた厄介です。(厄介でもないですが)先の住所録は単一のテーブルにレコードを格納することができます。しかし、この住所録に登録している人たちが役所にきた履歴を保存しようとしたらどうなるでしょうか。これらのデータの整合性はどうやって保てばよいでしょうか。
これはリレーショナル(関係性をもった)データテーブルが必要になります。個人のデータと個人が行動し履歴は別データとして扱います。あるいはそうした方が合理的な話というわけです。しかしここでも制約があります。それは、行動履歴のデータには住所録にいる人間しか管理できないという制約です。「誰が」行動したのかを主にしてその誰かが行動した履歴があるのですから、履歴のデータにいる人々はすなわち住所録にいる人々ということになります。つまり、履歴のデータには「誰が」に相当するデータが必ず入っていなければデータとしての意味がなくなります。この誰にそうとうするデータ、たいていの場合は先の主キーになりますが、それに相当するデータ外部キーが同一のものであり、必ず関係をもっているというデータの作りを「外部キー制約」といいます。
このデータは履歴の削除や日付の間違いなどで生じる前後の入れ替えはあるかもしれません。しかし住所録から削除された人間がいたとしたら、それと同時に行動履歴もすべて削除されることになります。そういった関係になります。このような場合、住所録を親テーブル、行動履歴を子テーブルといいます。この親テーブルと小テーブルの関係を保つ方法が「外部キー制約」というものになります。抽象的な言い方をすると「外部キー制約とは、テーブルの指定したカラムに格納できる値を他のテーブルに格納されている値だけに限定するもの」ということです。

主キーと外部キー

実際にMySQLで外部キーを作成する際には、こんな感じになります。

Last update: 2016.03.26 (土)