リレーショナルデータベース(RDB)

異なるエクセルの表を「固有のキー」でつなぎ、データの重複なくスッキリ整理するデータ引き出しです。

定義 データを縦横の「表(テーブル)」の形にきれいに整理し、複数の表同士を結びつけて管理する技術です。情報が重複してたまらないよう小分けにして保管しつつ、必要なときには表同士を合体させて目的のデータをすばやく取り出すことができます。

なぜ1つの大きな表に全部書かないの?

街の本屋さんの注文帳をイメージしてみてください。お客さんが本を買うたびに、名前、電話番号、住所、本のタイトル、価格をすべて1つのノートに書いていたらどうなるでしょうか? 同じお客さんが本を100回買ったら、同じ名前と住所を100回も繰り返し書くことになります。もしそのお客さんが引っ越して住所が変わったら、過去の100カ所をすべて探して書き直さなければなりません。その途中で書き間違えたり、修正し忘れたりするミスが起きてしまいますよね。

関係データベースは、この問題を「表を分ける」ことで解決します。「顧客名簿の表」には顧客番号、名前、住所を1回だけ記録します。そして「注文履歴の表」には、長い住所の代わりに顧客番号と買った本だけをシンプルに記録するのです。

このように情報の性質ごとに分けて整理することで、無駄なデータの重複をなくし、保存容量を節約できます。あとから住所変更があっても、顧客名簿のたった1行を直すだけで、すべての注文履歴に正しく反映されます。

RDBの表分割と結合の概念図 重複帳簿(非効率) 表分割 顧客表 1 2 番号で結合 注文表 1 1 2

表と表をつなぐ「鍵」の秘密

分けた表同士は、どうやって相手を見つけてペアを組むのでしょうか? その秘密は、表ごとに1つずつ割り当てる「特別な識別番号」にあります。マイナンバーや学生番号のように、世界に1つしかない固有の番号を振っておくのです。これを「主キー(Primary Key)」と呼びます。

顧客名簿の表に「顧客番号」という主キーがあれば、注文表はその番号をそのまま参照します。他の表の主キーを指し示すこの通路を「外部キー(Foreign Key)」と呼びます。まるで鍵穴(主キー)にぴったりの鍵(外部キー)を差し込んで、2つの表をしっかり連結するようなものです。

ネットショッピングで「注文履歴」を開いた瞬間、システムはこの鍵同士をつなぎ合わせます。外部キーをたどって複数の表を一瞬で連結し、名前や配送先住所、購入した商品名がまとまった1つの画面をパッと作り出してくれます。

主キーと外部キーによるテーブル結合 会員テーブル 会員ID(主キー) 名前 配送先住所 注文テーブル 注文番号 注文者ID(FK) 決済商品 外部キーで2つのテーブルを結合

もう少し正確に言うと

ここでいう「関係(リレーション)」とは、表と表のつながりだけを意味するのではありません。数学の集合論において、表のようなデータ構造そのものを「リレーション」と呼んでいたことに由来します。つまり、厳格なルールを持った表形式に規格化してデータを扱うという意味が込められています。

この厳格な規格化のおかげで、関係データベースはデータが矛盾したり壊れたりしない完璧な一貫性と正確さを誇ります。銀行の口座振込のように1円の狂いも許されないシステムで、何十年もの間もっとも信頼されるデータ保管庫として使われ続けている理由がここにあります。

もちろん弱点もあります。決まった表の枠組み(スキーマ)に収まりきらない複雑な画像や動画、長文テキストなどは扱いにくく、一度に膨大なデータが押し寄せると処理速度が落ちることがあります。そのため現在では、決まった形式を持たずに柔軟に保管できる「非関係データベース(NoSQL)」などと状況に応じて使い分けられています。

🤔 よくある誤解

✕ 誤解

表がいくつにも分かれていると、データを検索するときにいつも遅くなる。

✓ 事実

むしろ重複が減って全体の容量が軽くなり、固有のキーを使って必要な部分だけをピンポイントで合体させるため、膨大なデータからでも驚くほど速く正確に目的の情報を見つけ出せます。

🧺 日常で出会う場面

1 ECサイトで会員情報テーブルと注文履歴テーブルを会員IDで紐付けて管理する。
2 学校のシステムで生徒の基本情報テーブルと学期ごとの成績テーブルを学籍番号で連結して表示する。
💡 つまり ひとことで

データを規格化された表に小分けにして重複をなくし、固有のキーで表同士をつないで正確に管理するデータベースです。