リレーショナルDBの仕組み
このレッスンで分かること
- RDB はテーブル (リレーション)・行 (タプル)・列 (アトリビュート) の 3 要素で構成
- 関連は外部キーで表現、整合性は DBMS が自動で保証
- 関係は 1 対 1 / 1 対 多 / 多対多 の 3 種、設計の 7 割はこの見極め
リレーショナルDBの仕組み とは
リレーショナルデータベースの基本構造と、データ管理の仕組みをSQLで実践的に学びます。本レッスンでは、リレーショナルDBの仕組み の基本から実際の使いどころまでを整理し、現場で迷わず使える形に落とし込みます。
なぜ重要か
世の中には NoSQL、KVS、グラフ DB などさまざまなデータベースがありますが、業務システムの大部分はいまも リレーショナルデータベース (RDB) が中心です。理由はシンプルで、表形式 (テーブル) でデータを表現し、テーブル同士を関連付けることで、ほとんどの業務モデルを綺麗に表現できるからです。顧客と注文、商品と在庫、社員と部署といった「実世界の関係」をそのままテーブルに落とせるので、長期メンテに耐える設計を作りやすいのです。
本レッスンでは RDB がなぜ「関係」と呼ばれるのか、テーブルがどう構成され、どのように関連付けられるのかを掴みます。難解な集合論には踏み込まず、まずは図と例で全体像を押さえます。
リレーショナルモデルの 3 要素
リレーショナルモデルでは、データを次の 3 つで表します。
- テーブル (
リレーション) は、関心ある対象 (顧客、商品、注文など) を表す表 - 行 (
タプル/ レコード) は、その対象の 1 件のインスタンス (1 人の顧客、1 件の注文) - 列 (
アトリビュート/ カラム) は、対象の属性 (名前、価格、日付など)
| 用語 (理論) | 用語 (実務) | 例 |
|---|---|---|
| リレーション | テーブル | customers |
| タプル | 行 / レコード | (1, '田中', 'tanaka@x.com') |
| アトリビュート | 列 / カラム | name email |
| ドメイン | データ型 | VARCHAR(50) |
表計算ソフトとそっくりに見えますが、決定的に違うのは 「行に順序がない」「列には型と制約がある」「テーブル同士は ID で繋がる」 の 3 点です。Excel のような自由さの代わりに、データの意味と整合性を厳密に守れる仕掛けが用意されています。
テーブル同士を ID でつなぐ
RDB の強みは、1 つのテーブルに何でも詰め込まない点にあります。たとえば顧客と注文を 1 つのテーブルに入れてしまうと、同じ顧客の情報が注文の数だけ重複してしまいます。これを避けるために、顧客は customers、注文は orders のように分け、orders.customer_id で customers.id を参照します。
SQL クエリ
-- customers テーブル (顧客マスタ)
CREATE TABLE customers (
id INT PRIMARY KEY,
name VARCHAR(50) NOT NULL
);
-- orders テーブル (注文)
CREATE TABLE orders (
id INT PRIMARY KEY,
customer_id INT NOT NULL, -- どの顧客の注文か
total INT NOT NULL,
FOREIGN KEY (customer_id) REFERENCES customers (id)
);この customer_id が 外部キー (Foreign Key) で、参照される側の customers.id が 主キー (Primary Key) です。外部キーは表と表をつなぐ糸であり、これがあるおかげで「存在しない顧客の注文」が登録されないように DBMS が守ってくれます。
集合演算としての SQL
リレーショナルモデルの数学的な背景には「集合論」があります。テーブルは集合、行は要素と考えると、SELECT は集合から条件を満たす要素を取り出す操作 (フィルタ)、JOIN は 2 つの集合の積、UNION は和集合、と整理できます。
プレーンテキスト
SELECT -> 縦切り (列の選択) + 横切り (行のフィルタ)
JOIN -> 複数テーブルを 1 つの大きな表として扱う
UNION -> 2 つの結果セットを縦に連結
GROUP BY -> 行を仲間でまとめて集計リレーショナルモデルの本質は「集合演算で考える」ことです。ループや if 文ではなく、集合を絞り込んだり結合したりするイメージで SQL を書くと、複雑なクエリも素直に表現できます。
1 対 1 / 1 対 多 / 多対多
テーブル同士の関係には大きく 3 種類あります。
- 1 対 1 は、ユーザとプロフィール詳細のように 1 件と 1 件が結びつくケース
- 1 対 多 は、顧客と注文のように 1 件に複数件がぶら下がるケース (最も多い)
- 多対多 は、生徒と授業のように両側が複数件を持ち合うケース。中間テーブルでつなぐ
| 関係 | 例 | 中間テーブル |
|---|---|---|
| 1 対 1 | ユーザ ↔ プロフィール | 不要 (どちらかに FK) |
| 1 対 多 | 顧客 → 注文 | 不要 (子側に FK) |
| 多対多 | 生徒 ↔ 授業 | 必要 (enrollments 等) |
テーブル設計の 7 割は「この関係は 1 対 多か、多対多か」を見極める作業です。早い段階で関係を見極めると、後からの修正コストが激減します。
演習でやること
演習エディタには customers と orders の 2 テーブルが入っています。同じ顧客が複数の注文を持つ「1 対 多」の関係を、SQL で繋いで取り出してみましょう。JOIN の練習は後の章で詳しく扱うので、ここではまず customers 側だけを id 順に取り出します。
ここまでの要点 RDB はテーブル・行・列の 3 要素、関連は外部キーで表現。SQL は集合演算 (フィルタ・結合・和) として捉えると見通しが良い。関係の見極め (1 対 1 / 1 対 多 / 多対多) が設計の中心。
まとめ
- RDB のデータはテーブル・行・列の 3 要素で表す
- 関連は外部キーで表現し、整合性は DBMS が保証する
- SQL は集合演算として捉えると見通しが良くなる
- 関係は 1 対 1 / 1 対 多 / 多対多 の 3 種に分類できる
- 早めに関係を見極めることが設計の肝
次のレッスン
次は テーブル・行・列の基本 です。テーブル・行・列の操作を通して、データベースの構造を理解します。
事前確認 — 進む前に次の 3 つができることを確認しましょう。
- RDBの仕組み の要点を自分の言葉で説明できる
- このレッスンの最小コード (または操作手順) を見ずに書ける
- 練習問題やクイズで間違えた箇所を読み直して理解した
理解度チェック (30 秒)
Q. RDBの仕組み とは何か、1 文で説明してください。
A. 本文の「このレッスンで分かること」または冒頭の説明文を見直し、自分の言葉で要約できれば OK。詰まったら本レッスンの最初の H2 セクションを読み返してみましょう。
関連レッスン
テーブル構造
schema.sql
CREATE TABLE customers (
id INT PRIMARY KEY,
name VARCHAR(50) NOT NULL,
city VARCHAR(30) NOT NULL
);
CREATE TABLE orders (
id INT PRIMARY KEY,
customer_id INT NOT NULL,
amount INT NOT NULL,
ordered_on DATE NOT NULL
);
INSERT INTO customers (id, name, city) VALUES
(1, '田中', '東京'),
(2, '鈴木', '大阪'),
(3, '佐藤', '名古屋'),
(4, '高橋', '札幌');
INSERT INTO orders (id, customer_id, amount, ordered_on) VALUES
(101, 1, 1200, '2026-04-01'),
(102, 1, 3400, '2026-04-15'),
(103, 2, 2200, '2026-04-20'),
(104, 3, 5000, '2026-05-01');期待される出力
| id | name | city |
|---|---|---|
| 1 | 田中 | 東京 |
| 2 | 鈴木 | 大阪 |
| 3 | 佐藤 | 名古屋 |
| 4 | 高橋 | 札幌 |