リレーショナルデータベース（RDB）

街の本屋さんの注文帳簿をイメージしてみましょう。お客さんが本を買うたびに、名前、電話番号、住所、本のタイトル、価格を帳簿に毎回すべて書き込むとしたらどうなるでしょうか？ 同じお客さんが100回本を買ったら、まったく同じ名前と住所を100回も繰り返して書かなければなりません。その途中でその人が引っ越して住所が変わったら、過去100回分の記録を一つずつ探して書き直す必要がありますよね。その作業の中で書き間違いや修正漏れといったミスがどうしても起きてしまいます。

リレーショナルデータベースは、表を分割することでこの問題を解決します。「顧客名簿の表」には顧客番号、名前、住所だけを一度だけ記録しておきます。そして「注文履歴の表」には、長い住所を書く代わりに顧客番号と買った本の名前だけをシンプルに記録するのです。

このように情報を役割ごとに分けて整理すれば、不要なデータの重複をなくし、保存容量を節約できます。あとから住所が変わっても顧客名簿のたった1行を直すだけで、すべての注文履歴に自動的に正しい情報が反映されます。

別々に分けた表同士は、どうやって相手を識別してペアを見つけるのでしょうか？ その秘密は、表の各行（レコード）に、表の中で絶対に重複しない固有の値を割り振ることにあります。マイナンバーや学籍番号のように、その表の中で唯一無二の番号をつけるのです。これを「主キー（Primary Key）」と呼びます。

顧客名簿の表に「顧客番号」という主キーがあれば、注文の表ではその番号をそのまま使って顧客を参照します。このように別の表の主キーを指し示す通路となる項目を「外部キー（Foreign Key）」と呼びます。まるで鍵穴（主キー）にぴったり合う鍵（外部キー）を差し込んで、二つの表をしっかり連結するような仕組みです。

私たちが通販サイトで「注文履歴」を開いた瞬間、システムはこの鍵同士を照合します。外部キーをたどって複数の表を瞬時につなぎ合わせることで、名前や配送先住所、購入した商品名が一目でわかる一つの画面をあっという間に組み立ててくれるのです。

ここで言う「リレーション（関係）」とは、単に表と表の間のつながりだけを指す言葉ではありません。数学におけるリレーション（関係）とは、複数の要素が組み合わさった組（タプル）の集合を意味します。1970年にエドガー・F・コッド（E. F. Codd）がこの数学理論をデータ管理に応用し、表そのものを一つのリレーションとみなしたことからこの名前がつきました。つまり、データを厳格なルールに基づく表形式へと規格化して扱う、という意味が込められています。

厳格なスキーマ（データの設計図）や制約条件、そしてトランザクション（ACID特性）のおかげで、リレーショナルデータベースは極めて高い一貫性と正確性を保証できるように設計されています。1円の狂いも許されない銀行の口座振替システムなどで、長年にわたり圧倒的な信頼を得て使われ続けている理由がここにあります。

もちろんデメリットもあります。形式がバラバラだったり頻繁に変わるデータは決まった表の枠組み（スキーマ）に当てはめるのが難しく、アクセスやデータ量が急増した際に複数のサーバーへ分散して拡張するのが比較的苦手です。そのため現在では、柔軟な形式でデータを保存できる「非リレーショナルデータベース（NoSQL）」などと状況に合わせて使い分けられています。