LASSIC Media らしくメディア

データベースは、顧客・注文・商品といった情報を、いくつもの表（テーブル）に分けて管理します。このとき、「どの行がどの行なのかを見分ける」「表と表を正しくつなぐ」という二つの働きを担うのが、主キーと外部キーです。地味な存在に見えますが、ここの設計を誤ると、同じ人が二重に登録されたり、存在しない顧客への注文が残ったりと、データの土台が揺らぎます。

主キーと外部キーは、テーブル設計のもっとも基礎的な部品でありながら、発注する側からは見えにくく、要件の議論から抜け落ちがちな部分でもあります。この記事では、発注者やプロジェクトマネージャー、これから開発に関わる方に向けて、主キーと外部キーそれぞれの役割と、両者がどう組み合わさってデータの整合性を保つのかを整理していきます。

主キーと外部キーとは

主キーとは、テーブルのなかで「その行が一つに定まる」ように定めた列、またはいくつかの列の組み合わせです。たとえば顧客テーブルなら「顧客ID」がこれにあたり、同じ顧客IDを持つ行は二つと存在しません。名前や電話番号は重複したり変わったりしますが、主キーはその行をつねに指し示す背番号のような役目を果たします。

一方の外部キーは、別のテーブルの主キーを指し示す列です。注文テーブルに「顧客ID」の列を置き、それが顧客テーブルの主キーを指すようにすると、「この注文は、どの顧客のものか」がたどれるようになります。外部キーは、ばらばらに分かれた表と表を結びつける糸の役割を担います。

整理すると、主キーは「行を見分けるためのもの」、外部キーは「表と表をつなぐためのもの」です。この二つがそろってはじめて、分割して保存されたデータを、意味のあるまとまりとして扱えるようになります。データベース設計の出発点にあたる考え方といえるでしょう。

主キーの役割

主キーの働きは、「テーブルのなかの一行を、ただ一つに特定する」ことに尽きます。この役目を果たすために、主キーにはいくつかの決まりごとがあります。

なぜここまで厳しく定めるのかというと、行を取り違えると、あらゆる処理が崩れるからです。ある顧客の情報を更新したつもりが別人のものだった、という事態は避けなければなりません。主キーは、そうした取り違えを起こさないための土台であり、他のテーブルから「この行」を名指しするときの宛先にもなります。だからこそ、値が変わらず、重複せず、つねに存在することが求められるのです。

外部キーの役割と参照整合性

外部キーの働きは、テーブルとテーブルを関連づけ、その関連が壊れないよう見張ることにあります。ここで鍵になるのが「参照整合性」という考え方です。下の図で、注文テーブルと顧客テーブルの関係を見てみましょう。

参照整合性とは、「外部キーが指す先の行は、つねに存在していなければならない」という約束です。たとえば注文テーブルに「顧客ID＝105」の注文があるなら、顧客テーブルにも顧客ID＝105の行が存在していなければなりません。もし存在しない顧客を指す注文があれば、それは持ち主のわからない「宙に浮いたデータ」になってしまいます。

外部キーを制約としてデータベースに設定しておくと、この約束が自動で守られます。存在しない顧客を指す注文を登録しようとすれば、データベースがそれを拒むのです。また、顧客の行を削除しようとしたときの振る舞い——関連する注文があれば削除を止める、あるいは関連ごとまとめて消す——も、あらかじめ定めておけます。こうして外部キーは、データのつながりが知らないうちに壊れることを防いでいるのです。

おさえておきたい関連概念

主キーと外部キーを理解するうえで、あわせて知っておくと役立つ考え方をいくつか挙げておきます。

複合キー

主キーは、一つの列だけでなく、複数の列の組み合わせで定めることもできます。これを複合キーと呼ぶのです。たとえば「注文明細」のように、注文IDと商品IDの二つがそろってはじめて一行が特定できる場合に用いられます。単独の列では一意に定まらないときの選択肢です。

サロゲートキーとナチュラルキー

主キーの決め方には、大きく二つの考え方があります。連番など、業務上の意味を持たない値をシステムが振り出す「サロゲートキー」と、メールアドレスのように業務上すでに意味を持つ値を用いる「ナチュラルキー」です。ナチュラルキーは自然に見えますが、値が変わりうる点が弱みになります。値が変わらない連番のサロゲートキーを主キーに据える設計が、実務では多く採られています。

参照整合性の制約

外部キーによる参照整合性は、データベースの機能として制約に設定するやり方と、アプリケーション側の処理で担保するやり方があります。データベースの制約に任せると取りこぼしが起きにくい一方、大量データの処理では性能を考えた判断が要る場面もあります。どちらに寄せるかは、システムの性質に応じて決める設計事項です。

発注・開発でおさえる点

キーの設計は、いったんデータを貯め始めると後から変えるのが大変な部分です。だからこそ、発注や設計の早い段階で方針を固めておきたいところです。

データの関連を図で共有する

どのデータとどのデータが、どうつながるのか——この関連は、ER図（実体関連図）のような形で図にして共有しておくと、認識のずれを防げます。発注する側も、主要なテーブルの関連図に目を通しておくと、要件との食い違いに早く気づけます。

キーの変更しにくさを前提に置く

主キーは、他の多くのテーブルから参照される宛先になります。そのため、後から主キーを変えようとすると、参照している側すべてに影響が及び、大がかりな作業になりがちです。「主キーは原則として変わらない値にする」という前提を、設計の初めに共有しておくことが、将来の手戻りを抑えます。

参照整合性をどこで守るか決める

存在しない行を指すデータを防ぐ参照整合性を、データベースの制約で守るのか、アプリケーションの処理で守るのかを、あらかじめ決めておきます。これは性能やデータ量にも関わる判断のため、要件として整理し、開発側と方針を合わせておくとよいでしょう。

よくある誤解と勘所

キーまわりは、言葉の印象で誤解されやすいテーマです。代表的なつまずきを表にまとめました。

勘所をひとことでいえば、主キーは「変わらない宛先」、外部キーは「壊れないつながり」として捉えることです。行をつねに名指しできる宛先を定め、その宛先を指す糸が宙に浮かないよう見張る——この二つがそろうことで、分割して保存したデータが、意味を保ったまま扱えるようになります。設計の初めにここを固めておくと、後々の安定につながっていくでしょう。

まとめ

• 主キーは、テーブルの各行を一つに定めて見分けるための列（または列の組）である。
• 主キーは重複せず、空にできず、一つのテーブルに一組という決まりを持つ。
• 外部キーは、別テーブルの主キーを指して表と表をつなぎ、関連づける。
• 外部キーは参照整合性を保ち、存在しない行を指す宙に浮いたデータを防ぐ。
• キーの設計は後から変えにくいため、関連を図で共有し、発注・設計の初めに方針を固める。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

出典

• PostgreSQL文書「制約」
• MySQL 8.0 リファレンスマニュアル「外部キー制約」

Tweet