第5章リレーショナルデータベース入門 — なぜ表で関係を扱うか

この章で学ぶこと

リレーショナルデータベース (RDB) の「リレーショナル」が何を意味するか説明できる
すべてを 1 つの表で管理すると何が起きるかを具体的に説明できる
RDB と NoSQL の使い分けを 3 つ以上の判断軸で説明できる

前提知識

第 1 章データベースの基本概念と第 4 章 CRUD と ACID を理解していること。

リレーショナルデータベースとは

リレーショナルデータベース (Relational Database, RDB) は、データを表 (テーブル) の形で管理するデータベースです。1970 年に E. F. Codd (Edgar F. コッド) によって提唱され、現在も Web 開発の主流として広く使われています。

代表的な RDBMS には PostgreSQL / MySQL / Oracle Database / Microsoft SQL Server / SQLite などがあります。具体的な製品比較は第 6 章 DBMS と SQLで扱います。

「リレーショナル」とは何の関係か

「リレーショナル (Relational)」は「関係」を意味します。重要な点は、これがテーブル間の関係性を表現できる、ということです。逆に言うと、関係を持たないデータをぽんと放り込むだけならリレーショナルである必要はありません。

なぜ「関係」が必要なのかは、すべてを 1 つの表で管理しようとした場合を見ると分かります。

すべてを 1 つの表に詰め込むと

次の表は、注文情報を 1 つのテーブルだけで管理した例です。

注文 ID	顧客名	顧客住所	顧客電話	商品名	商品価格	数量
1	山田	東京都...	090-...	PC	100,000	1
2	山田	東京都...	090-...	マウス	3,000	2
3	鈴木	大阪府...	080-...	PC	100,000	1

問題が見えるでしょうか。

顧客情報の重複: 山田さんの住所と電話が 2 回繰り返されている
更新の手間: 山田さんが引っ越したら、山田さんの全行を更新する必要がある
不整合の温床: 一部だけ更新してしまったら、同じ「山田」さんなのに住所が違う状態になる
商品情報も同様: PC の価格が変わったら、全注文行で書き換える必要がある

関係を持つ複数のテーブルで解決する

これを解決するのが「関係を持つ複数のテーブル」という考え方です。

顧客情報は customers テーブルに 1 回だけ書く
商品情報は products テーブルに 1 回だけ書く
注文は orders テーブル + order_details テーブルで、顧客と商品への参照 (外部キー) だけを持つ

山田さんが引っ越したら customers テーブルの 1 行を更新するだけで、全ての注文から見た住所が即座に新しいものになります。これが「関係を持つ複数のテーブル」のメリットです。

用語

外部キー (Foreign Key, FK): 別のテーブルの主キーを参照するカラム。orders.customer_id は customers.customer_id を参照する外部キー。詳しくは第 10 章キー概念で扱います。

ER 図 (Entity-Relationship Diagram): テーブル間の関係を視覚的に表す図。詳しくは第 12 章 E-R 図で扱います。

テーブルの基本構造

リレーショナルデータベースの基本単位はテーブルです。テーブルは行 (レコード) と列 (カラム) で構成されます。

customers テーブル
+------------+----------+--------------------+------------+
| id (PK)    | name     | email              | created_at |
+------------+----------+--------------------+------------+
| 1          | 山田 太郎 | yamada@example.com | 2026-01-01 |
| 2          | 鈴木 花子 | suzuki@example.com | 2026-01-05 |
| 3          | 佐藤 次郎 | sato@example.com   | 2026-01-10 |
+------------+----------+--------------------+------------+
        ^         ^                                ^
        |         |                                |
     カラム     カラム                          1 行 = 1 レコード
     (主キー)

行 / カラム / 主キー / 外部キーといった用語の正式な定義は第 7 章基本用語で扱います。

リレーショナルデータベースの長所と短所

これらのトレードオフは、別の選択肢である NoSQL との比較を通じて理解しやすくなります。

RDB vs NoSQL — どう使い分けるか

NoSQL は「Not Only SQL」の略で、RDB の制約に縛られない様々なデータベースの総称です。

観点	リレーショナル DB	NoSQL
データ構造	表形式 (構造化)	柔軟 (JSON / グラフ / キーバリュー / ドキュメント)
整合性モデル	ACID (強い整合性)	BASE (緩やかな整合性)
スケーラビリティ	垂直拡張 (1 台を強くする) が中心	水平拡張 (台数を増やす) が得意
主な用途	業務システム・金融・在庫管理	ビッグデータ・リアルタイム配信
代表例	PostgreSQL / MySQL / Oracle DB	MongoDB / Redis / Cassandra / DynamoDB

判断軸

軸	RDB を選ぶ	NoSQL を選ぶ
データの整合性	強い整合性が必要 (金融・在庫)	多少の遅延・不整合を許容できる
データの構造	構造が安定 (顧客 / 注文 / 商品)	構造が頻繁に変わる / 半構造化
関係の複雑さ	テーブル間の関係を SQL で表現	単純なキーバリュー or グラフ
アクセスパターン	集計・検索が多い	読み書きが超高速・大量

まずは RDB から始める

迷ったら RDB から始めるのが Jr にとって安全です。RDB は教材・ツール・経験者が多く、設計の判断軸が確立しています。NoSQL は「RDB では性能が足りない」「データ構造が RDB に収まらない」と分かってから検討するのが一般的です。

実際の利用例 — EC サイトのデータ構造

EC サイトの一般的なテーブル構成を ER 図で見てみましょう。

この図はまだ読めなくて構いません。各テーブルが他のテーブルとつながっている「線」が見えれば、それで十分です。具体的な ER 図の読み方・書き方は第 12 章 E-R 図で扱います。

演習

演習 1: 単一テーブルの問題点

以下のように 1 つの表で書籍と著者を管理しているとします。問題点を 3 つ挙げてください。

書籍 ID	書籍タイトル	著者名	著者プロフィール
1	リーダブルコード	Dustin Boswell	カリフォルニア在住の...
2	リーダブルコード	Trevor Foucher	元 Google の...
3	プログラマが知るべき97のこと	和田卓人	東京工業大学卒...

解答例

主な問題点:

書籍タイトルの重複: 「リーダブルコード」は 1 冊の本だが、共著なので 2 行に分かれて重複している。同じタイトルなのに別の書籍 ID が振られている点で「同じ本」と「別の本」の区別が曖昧
著者プロフィールの肥大: 同じ著者が複数の本を書いている場合、プロフィールがその本の数だけ重複する。プロフィール更新時に複数行を更新する必要がある
「1 冊に 3 人の著者」のような関係が表現できない: 行を増やせば一応書けるが、書籍タイトルが 3 回重複し、整合性を保つのが困難

解決方針: books テーブルと authors テーブルに分け、「どの本にどの著者が関わっているか」を中間テーブル book_authors で表現する (多対多の関係)。詳しくは第 14 章多対多で扱います。

ありがちな間違い: 「著者を CSV で 1 列に入れる」("Dustin Boswell, Trevor Foucher")。一見シンプルだが、著者で検索したり、著者のプロフィールを引いたりする SQL が非常に書きにくくなる (パース処理が必要)。これは「第 1 正規形を満たさない」と表現される問題で、第 11 章正規化で扱います。

演習 2: RDB か NoSQL か

次のシステムは、まず RDB と NoSQL のどちらで設計を始めるべきでしょうか? それぞれの理由とともに考えてみてください。

会員制サイトの会員情報管理 (名前・メール・住所・購入履歴)
リアルタイムチャットのメッセージ履歴 (秒間 1000 件以上の書き込み)
在庫管理システム (商品 / 在庫数 / 入出庫履歴 / 棚卸)
IoT センサーから 1 秒に 100 件流入する温度・湿度データ

解答例

番号	推奨	理由
1. 会員情報	RDB	データ構造が安定 (名前・メール・住所) / 個人情報の整合性が重要 / 購入履歴との関係を SQL で表現したい
2. リアルタイムチャット	NoSQL (or 併用)	秒間 1000 件以上の書き込みは RDB だと厳しい。MongoDB や Cassandra で書き込み性能を優先
3. 在庫管理	RDB	在庫数の整合性が金銭価値に直結 (二重出荷 / 在庫不足) / ACID 特性が重要 / トランザクション必須
4. IoT 時系列	NoSQL or 時系列 DB	大量の書き込み・古いデータの順次削除に最適化された InfluxDB / TimescaleDB などが向く

ありがちな間違い: 「最近 NoSQL が流行りだから」と理由なしに NoSQL を選ぶこと。RDB のほうがツールも事例も豊富で、設計の指針も明確。性能・スケール上の必要性が明確に見えてから NoSQL を検討するのが Jr にとって安全な順序です。

別解 (ハイブリッド): 大規模システムでは「マスターデータは RDB、ログ・キャッシュは NoSQL」と用途別に併用するのが一般的です (例: 在庫数は PostgreSQL、商品検索のキャッシュは Redis)。

まとめ

この章で学んだことを整理します。

リレーショナルデータベースは「関係を持つ複数のテーブル」でデータを管理する仕組み
すべてを 1 つの表に詰め込むと、データ重複・更新の手間・不整合の温床になる
関係を表現する道具として外部キー / 主キーがある (詳細は第 7 / 10 章)
NoSQL との使い分けは「整合性 / 構造の安定性 / 関係の複雑さ / アクセスパターン」で判断する
迷ったら RDB から始めるのが Jr にとって安全

次章では、データベースを操作する仕組み (DBMS) と共通言語 (SQL) を見ていきます。

次の章

第 6 章 DBMS と SQL

この章で学ぶこと​

リレーショナルデータベースとは​

「リレーショナル」とは何の関係か​

すべてを 1 つの表に詰め込むと​

関係を持つ複数のテーブルで解決する​

テーブルの基本構造​

リレーショナルデータベースの長所と短所​

RDB vs NoSQL — どう使い分けるか​

判断軸​

実際の利用例 — EC サイトのデータ構造​

演習​

まとめ​