リレーショナルモデル — 表と表を「キー」でつなぐ

現実のデータは「顧客」と「その注文」のように互いに関係し合っています。リレーショナルモデルは、データを複数の表に分け、主キーと外部キーという“合言葉”で表どうしをつなぎます。全部を1つの表に詰め込むと何が困るのか、キーをたどるとは何かを、クリックしながら確かめます。

1. 行を1つに特定する鍵 — 主キー

表の各行を「これだ」と1件に特定するための列を主キー（primary key）と呼びます。顧客IDのように重複せず、空(NULL)でない値です。名前だけだと同姓同名で区別できませんが、主キーがあれば必ず1行に定まります。

下の表で行をクリックしてみてください。検索キーを「主キー(ID)」にすると必ず1行に確定します。「名前」に切り替えて同姓同名（田中さんが2人）をクリックすると、特定できないことが分かります。

主キーなら1行に確定、名前だと曖昧
行をクリックすると、その行の「キーの値」で何件が該当するかを判定します。IDは重複しないので常に1件（緑）。名前だと田中さんが2人いて2件該当（赤）＝どちらか特定できません。だから主キーには重複しない列を選びます。
POINT — 主キー = 各行を一意に識別する 主キーは重複しない・空にしない列（またはその組）。これがあるからこそ、他の表からその行を番号で名指しできる。名前や住所のように重複・変更しうる値は主キーに向かない。

2. 表と表をつなぐ — 外部キー

注文の表に顧客の名前や住所を丸ごと書くと、同じ顧客の情報が何度も重複します。代わりに注文表には顧客ID（＝顧客表の主キー）だけを持たせます。これが外部キー（foreign key）。注文.顧客ID が 顧客.ID を「参照」しているのです。

下で注文の行をクリックすると、外部キーの矢印をたどって、対応する顧客の行へ光の玉が走ります。番号をたどれば、実体（顧客の情報）に必ずたどり着けます。

外部キーをたどる — 注文 → 顧客のルックアップ
注文の行をクリックして顧客をたどる →
右の注文の各行が持つ顧客IDが外部キー。選んだ注文の顧客IDから、左の顧客表の同じIDへ矢印をたどると、必ず1件の顧客に着きます（顧客IDが主キーIDを参照しているから）。佐藤さん(ID=2)のように、1人が複数の注文から参照されることもあります。
注文.顧客ID → 顧客.ID 「→」は参照。参照する側＝子（注文）、される側＝親（顧客）。顧客の情報は1か所だけに置き、注文からは番号で指す。

3. キーでつないで1枚にする — 結合（JOIN）

見たいときには、外部キーをたどって両方の表の情報を1枚に組み合わせられます。これが結合（JOIN）です。各注文に、その顧客IDが指す顧客の名前をくっつけて、読みやすい表を作ります。

下のボタンで結合を実行。各注文が対応する顧客を見つけ、合体した行ができていく様子を見てください。

結合の実演 — 注文 × 顧客 を1枚に
上の2つの表から、注文を1行ずつ処理。顧客IDで顧客表を引き、注文ID・商品・顧客名を並べた結合結果を下に組み立てます。結合結果は元の表を書き換えない“見え方”で、必要なときだけ作られます。

4. 壊さないための約束 — 参照整合性

外部キーが指す先は必ず存在しなければなりません。もし注文が参照している顧客をうっかり消すと、その注文は宛先を失った“みなしご（orphan）”になってしまいます。DBはこれを防ぎます — 参照されている親の削除を「拒否」するか、子ごと「カスケード削除」するかのどちらかで。

下で顧客を選んで削除実行してみてください。注文を持つ顧客を消そうとすると、拒否モードでは止められ、カスケードモードでは関連する注文も一緒に消えます。注文を持たない顧客（山田さん）は普通に削除できます。

参照整合性 — 親を消すと子はどうなる？
拒否モードで注文を持つ顧客を削除しようとすると 🚫 ブロック（参照元の注文が黄色で示されます）。カスケードモードなら顧客とその注文が一緒に消えます。どちらもみなしごの注文を残しません。

5. まとめ — 表を分けてキーでつなぐ

一歩先へ — なぜ「関係（リレーション）」なのか リレーショナルモデルは1970年、E. F. Codd が集合論をもとに提案しました。表＝関係（relation）、行＝組（タプル）という数学的な土台の上に立っています。次章のSQLはこのモデルへの問い合わせ言語で、重複を消す正規化、速さを生む索引、安全を守るトランザクションも、すべてこの土台の上に成り立っています。