今日は、データベースの**「候補キー」**について勉強しました。
これまで正規化について勉強してきましたが、候補キーについては何となく分かっているようで、きちんと説明しようとすると少し曖昧なところがありました。
そこで今回は、ChatGPTに問題を作ってもらい、実際に問題を解きながら理解を深めてみました。
候補キーとは？
今回の勉強で、まず覚えておきたいと思ったのが、
候補キー ＝ 一意性 ＋ 極小性
という考え方です。
「一意性」とは、その属性を使えば表の中の1行（タプル）を一意に特定できること。
「極小性」とは、余分な属性が含まれておらず、どれか1つでも属性を取り除くと一意に特定できなくなることです。
そして候補キーの中から、実際に代表として選んだものが主キーになります。
最初は社員表から考えてみた
例えば、社員表に「社員番号」と「メールアドレス」があり、どちらも社員ごとに重複しないとします。
この場合、
（社員番号）
（メールアドレス）
のどちらも候補キーになります。
最初は「社員番号＋氏名」のように、一意に特定できる組合せも候補キーなのでは？と考えました。
しかし、「社員番号」だけで一意に特定できるので、「氏名」は余分です。
つまり、
一意に特定できるだけでは候補キーとは限らない
ということが分かりました。
ここで「極小性」が重要になってきます。
複合候補キーもある
次に、学生の履修表について考えました。
同じ学生が同じ科目を別の学期にも履修できる場合、
（学生番号、科目番号）
だけでは1行を特定できません。
そこで、
（学生番号、科目番号、学期）
まで組み合わせることで一意に特定できます。
しかも、どれか1つを取り除くと一意に特定できなくなります。
このように複数の属性を組み合わせたものも候補キーになることが分かりました。
スーパーキーとの違いも分かった
今回もう一つ理解できたのが、スーパーキーと候補キーの違いです。
スーパーキーは、タプルを一意に特定できれば、余分な属性を含んでいても構いません。
一方、候補キーには極小性が必要です。
つまり、
スーパーキー → 一意に特定できる
候補キー → 一意に特定できる＋極小である
という違いです。
関数従属性から候補キーを求める
後半は少し難しくして、関数従属性から候補キーを探す問題にも挑戦しました。
例えば、
R（A, B, C, D, E）
A → B
B → C
AD → Eという関数従属性がある場合です。
AからB、BからCを求められるので、
A⁺ = {A, B, C}となります。
さらにADから考えると、
(AD)⁺
= {A, D}
→ {A, B, D}
→ {A, B, C, D}
→ {A, B, C, D, E}となり、Rのすべての属性を求めることができます。
さらにAまたはDのどちらかを取り除くと全属性を決定できません。
したがって、
ADが候補キー
となります。
ここで初めて、**「属性閉包」**と候補キーの関係がかなり分かってきました。
候補キーが複数ある問題にも挑戦
最後は、
A → B
B → C
C → A
D → E
E → D
CD → Fという少し複雑な問題にも挑戦しました。
A・B・Cはお互いにたどることができ、D・Eもお互いに決定できます。
その結果、候補キーは、
AD、AE、BD、BE、CD、CE
の6個になりました。
最初に候補キーを勉強したときには、ここまで求められるとは思っていませんでした。
今日の勉強で理解できたこと
今日の一番の収穫は、
候補キー ＝ 一意性 ＋ 極小性
ということです。
さらに、
スーパーキー → 候補キー → 主キー
の関係や、関数従属性から候補キーを求めるときには属性閉包を使うことも理解できました。
また、関数従属性の右辺に一度も登場しない属性に注目すると、候補キーを探す手掛かりになることも学びました。
ただし、今回の最後の問題のように、すべての属性が右辺に登場するケースもあるので、それだけで候補キーが決まるわけではありません。
追記：候補キーはNULLを許してもよい？
候補キーについて勉強したあと、参考書を読み返していて一つ気になる記述を見つけました。
私が使っている三好康之著『データベーススペシャリスト 2026〜2027年版』の276ページには、候補キーについて、
「主キーとは異なり、NULLを許可する属性を持つ（もしくは含む）ものでも可」
と説明されています。
ここで少し混乱しました。
候補キーは「タプルを一意に識別するためのもの」なのに、**NULLを許してよいのだろうか？**と思ったからです。
候補キーと主キーの違い
改めて整理してみると、候補キーの基本的な条件は、
① タプルを一意に識別できること
② 極小であること
です。
そして、候補キーが複数存在する場合、その中から一つを選んだものが主キーになります。
ここで重要なのがNULLの扱いです。
参考書では、
| 種類 | 一意に識別 | 極小性 | NULLを許可する属性 |
|---|---|---|---|
| スーパーキー | ○ | 不要 | 含む場合あり |
| 候補キー | ○ | ○ | 含んでもよい |
| 主キー | ○ | ○ | 不可 |
と整理できます。
つまり、
「候補キーだから必ずNOT NULL」というわけではない
ということです。
「NULLを含んでもよい」の意味に注意
ここで私が注意したいと思ったのは、
「候補キーはNULLを許可する属性を含んでもよい」
ということと、
「NULLがいくつあっても重複して構わない」
ということは同じ意味ではない、という点です。
候補キーを構成する属性の中に、NULLを許可する属性が存在する場合があるということです。
一方、候補キーの中から主キーとして選択されたものには非NULL制約が必要になります。
そのため、
候補キー
↓
その中から1つを選択
↓
主キー
↓
NULLは許可されないと考えると理解しやすそうです。
最初の問題を振り返ってみる
実は候補キーの勉強を始めたとき、私は、
「候補キーはNULLがあってもよいが、主キーはNULLがダメなのでは？」
と考えていました。
その後、「候補キーもタプルを一意に識別するのだからNULLはダメなのでは？」と少し迷いました。
そこで参考書を確認してみると、データベーススペシャリスト試験の学習では、
候補キーはNULLを許可する属性を含むこともある。主キーはNULLを許可しない。
と整理しておくのがよいことが分かりました。
参考書にも、過去のデータベーススペシャリスト試験で、NULLを許可する属性を含む組を候補キーとして扱った例があることが紹介されています。
SQLのUNIQUE制約とも混同しない
もう一つ注意したいのが、候補キーとSQLのUNIQUE制約は同じものではないということです。
候補キーはデータベース設計上の考え方です。
一方、
PRIMARY KEY
UNIQUE
NOT NULLなどはSQLでデータベースに制約を設定するときに使います。
特にNULLとUNIQUEの扱いについてはDBMSによる違いもあるため、候補キーそのものの定義とは分けて考えた方がよさそうです。
試験ではこう覚えておく
今回の勉強で、私は次のように整理することにしました。
候補キー ＝ 一意性 ＋ 極小性
そして、
主キー ＝ 候補キーの中から選んだ1つ ＋ NULL不可
です。
さらに、
候補キーにはNULLを許可する属性が含まれる場合がある
という点も覚えておきます。
参考書を確認することも大切
今回、問題を解くだけではなく、疑問に思ったところを参考書で確認したことで、候補キーについてもう一段理解が深まりました。
データベースの用語は、似ているものが多く、
スーパーキー → 候補キー → 主キー
の違いも、最初はなかなか分かりにくいです。
でも、一つずつ違いを確認していけば整理できそうです。
「分からないところをそのままにしない」
これも59歳からの資格勉強では大切にしていきたいと思います。
次回は、候補キーの知識を使って、
候補キー → 主属性 → 部分関数従属 → 第2正規形
へ進んでみます。
一歩ずつ、でも着実に。
データベーススペシャリスト合格を目指して頑張ります！
今日の学習はここまで
今日は候補キーについて、基本的な問題から関数従属性を使った問題まで段階的に取り組みました。
最初は少し曖昧だった候補キーですが、自分で問題を解いて間違いを確認していくことで、かなり整理できたと思います。
次回は今回勉強した候補キーを使って、
候補キー → 主属性 → 部分関数従属 → 第2正規形
へ進んでみたいと思います。
59歳からの挑戦。焦らず、一歩ずつ。
データベーススペシャリスト合格を目指して、引き続き頑張ります！
コメント