5-1. RDB・テーブル設計・正規化

このセクションで学ぶこと

RDB（リレーショナルデータベース）が何を管理する仕組みなのか
テーブル・行・列・主キー・外部キーの役割
要件からテーブル設計へ落とし込む基本手順
正規化が必要な理由と、重複データが生む問題

この章では、アプリケーションが長く使われても壊れにくいデータの持ち方を学ぶ。
プログラム本体と同じくらい、データの置き方 は品質に直結する。

1. データベースとは何か

データベースとは、あとで安全に保存・検索・更新できる形でデータを管理する仕組み である。

たとえば書籍管理アプリを考えると、次のような情報を持ちたくなる。

書籍のタイトル
著者名
価格
在庫数
出版社

これを単なるテキストファイルへ好きな形式で書き続けると、検索や更新がすぐ難しくなる。

Book: Git, Author: Sato, Price: 2200
Book: SQL, Author: Suzuki, Price: 2800
Book: Web, Author: Sato, Price: 2500

この形だと、

著者 Sato の本だけ取り出したい
価格を一括で更新したい
タイトルの重複や入力ミスを防ぎたい

といった要求に弱い。

データベースは、このような問題を避けるために 構造を決めてデータを管理する。

2. RDB とは何か

RDB は Relational DataBase の略で、表（テーブル）どうしの関係を使ってデータを整理するデータベース である。

RDB では、データを次の形で考える。

テーブル: 同じ種類のデータをまとめる表
行（row / record）: 1 件分のデータ
列（column）: 項目の種類

たとえば books テーブルは次のように表せる。

books
+----+--------------+-----------+-------+
| id | title        | author_id | price |
+----+--------------+-----------+-------+
|  1 | Git          |        10 |  2200 |
|  2 | JavaScript   |        11 |  3200 |
|  3 | Network      |        10 |  2800 |
+----+--------------+-----------+-------+

この表では、

books がテーブル
1 行ごとの Git や JavaScript がレコード
title や price が列

である。

なぜ「表」で考えるのか

表で管理すると、データの意味がはっきりする。

どの項目が必須かを決めやすい
型（数値・文字列・日付など）を決めやすい
検索や集計のルールを共通化しやすい

つまり RDB は、「ただ保存する場所」ではなく、意味を守りながら扱うための土台 である。

3. 主キーと外部キー

主キー（Primary Key）

主キーとは、各行を一意に識別する列 である。

books テーブルなら id が典型例になる。

id = 1 なら Git
id = 2 なら JavaScript
id = 3 なら Network

主キーが重要なのは、タイトルや名前は重複しうるからである。

title = "Git" は別版や改訂版で重なるかもしれない
author_name = "Sato" は同姓同名がありうる

そこで、意味の重複があっても区別できるよう、識別専用の値 を置く。

外部キー（Foreign Key）

外部キーとは、別テーブルの主キーを参照する列 である。

authors
+----+----------+
| id | name     |
+----+----------+
| 10 | Sato     |
| 11 | Suzuki   |
+----+----------+

books
+----+------------+-----------+
| id | title      | author_id |
+----+------------+-----------+
|  1 | Git        |        10 |
|  2 | SQL        |        11 |
|  3 | Web        |        10 |
+----+------------+-----------+

ここで books.author_id は authors.id を指している。

books.author_id ----> authors.id
         10   ---->      10 (Sato)
         11   ---->      11 (Suzuki)

これにより、書籍テーブルへ毎回著者名を文字列で書かずに済む。

なぜキーが必要なのか

キーを使うと、次のような問題を減らせる。

同じ著者名を何度も書いて入力ミスが起きる
名前を変更したいときに大量更新が必要になる
「この本の著者は誰か」を安定して追えなくなる

キーは、データどうしのつながりを安全に表す仕組み である。

4. テーブル設計の基本手順

初学者は、いきなり CREATE TABLE を書こうとして詰まりやすい。
しかし実際には、先に「何を管理したいか」を整理したほうが分かりやすい。

基本手順は次の流れで考えるとよい。

手順	何を考えるか
1	管理したい対象は何か
2	各対象にどんな項目が必要か
3	どれを主キーにするか
4	対象どうしがどうつながるか
5	同じ情報を何度も書いていないか

例: 書籍管理アプリ

要件が次のように与えられたとする。

書籍を管理したい
著者も管理したい
1 人の著者が複数冊書くことがある

このとき、まず対象は次の 2 つだと分かる。

書籍
著者

それぞれの項目を考える。

書籍: id, title, price, author_id
著者: id, name

次に、関係を考える。

1 人の著者
  ↓
複数の書籍を書ける

これを RDB では、books.author_id -> authors.id のように表す。

設計時に気を付ける点

列名は意味が分かる名前にする
1 つの列に複数の意味を混ぜない
1 つのテーブルに関係ない情報を詰め込みすぎない

つまりテーブル設計は、データをあとで安全に使うための整理整頓 である。

5. 正規化とは何か

正規化とは、同じ事実を何度も書かなくてよい形へ、テーブルを整理する考え方 である。

正規化が必要になる理由は、重複したデータが更新ミスを生みやすいからである。

たとえば次の 1 枚表を考える。

bad_books
+---------+--------------+-------------+-----------+
| book_id | title        | author_name | author_tel|
+---------+--------------+-------------+-----------+
|       1 | Git          | Sato        | 03-1111   |
|       2 | Network      | Sato        | 03-1111   |
|       3 | SQL          | Suzuki      | 03-2222   |
+---------+--------------+-------------+-----------+

Sato が 2 行に重複している。

ここで著者の電話番号が変わると、両方の行を直さなければならない。
片方だけ直すと、同じ著者なのに電話番号が食い違う。

重複データが生む代表的な問題

問題	何が困るか
更新時異常	1 つの事実を複数箇所直す必要がある
挿入時異常	本がなくても著者だけ登録したいのに登録しにくい
削除時異常	最後の 1 冊を消すと著者情報まで失われる

これを分けると次のようになる。

authors
+----+--------+-----------+
| id | name   | tel       |
+----+--------+-----------+
| 10 | Sato   | 03-1111   |
| 11 | Suzuki | 03-2222   |
+----+--------+-----------+

books
+----+----------+-----------+
| id | title    | author_id |
+----+----------+-----------+
|  1 | Git      |        10 |
|  2 | Network  |        10 |
|  3 | SQL      |        11 |
+----+----------+-----------+

これで電話番号は authors に 1 回だけ書けばよい。

1NF / 2NF / 3NF をどう考えるか

研修の最初の段階では、厳密な定義を丸暗記するより、次の感覚を持つことが重要である。

正規形	初学者向けの理解
第1正規形	1 つのセルには 1 つの値だけ入れる
第2正規形	複合キーの一部だけに依存する列を分ける
第3正規形	主キー以外の列どうしの依存を減らす

たとえば tag1,tag2,tag3 のような列は、第1正規形の考え方に反しやすい。
また「部署名から部署責任者が決まる」のに社員テーブルへ責任者名を直接持つと、第3正規形の考え方から外れやすい。

正規化しすぎればよいわけではない

正規化は大切だが、分けすぎると JOIN が増えて読みづらくなることもある。
実務では、まず 重複による事故を防げる形 を目指し、そのうえで性能や運用の都合に応じて調整する。

つまり正規化の目的は、ルールを守ること自体ではなく、データの意味を壊れにくくすること である。

6. テーブル設計をレビューするときの観点

設計案を見たときは、次の観点で確認するとよい。

1 行が 1 件の意味に対応しているか
主キーは一意か
外部キーで関係を表せているか
同じ事実を何度も書いていないか
将来の変更で更新漏れが起きにくいか

良い設計を考える視点

何を管理する？
  ↓
1件とは何？
  ↓
どの列が必要？
  ↓
主キーは何？
  ↓
他テーブルとの関係は？
  ↓
重複はない？

この順で見ると、「なんとなく表を作る」状態から抜けやすい。

まとめ

キーワード	説明
データベース	データを安全に保存・検索・更新する仕組み
RDB	表とその関係でデータを管理するデータベース
テーブル	同じ種類のデータをまとめた表
行	1 件分のデータ
列	項目の種類
主キー	各行を一意に識別する列
外部キー	別テーブルの主キーを参照する列
正規化	重複を減らし、更新しやすくする整理の考え方
更新時異常	同じ事実を複数箇所直す必要がある問題

次のステップ

演習問題に取り組んで、テーブル設計と正規化の考え方を確認しよう。

理解できたら 5-2. SQL基礎へ進もう。