3分間データベース講座 第4回: データベース設計の基礎～正規化とER図の考え方～
登場人物：
チャット先生（通称:先生）： オブジェクト指向マスター。最近はデータベースの世界にも詳しい。
ボット助手（通称:ボット君）： プログラミングを始めたばかりの若手。データベースはまだ未知の世界。
ボット君： 先生！JOINや集約関数のおかげで、データが思い通りに扱えるようになりました！でも、そもそもどうやってテーブルの構造を考えればいいんでしょうか？
先生： 良い質問だね。それが今日のテーマ、データベース設計だ。どんなに優れたSQLのテクニックを学んでも、そもそも設計が間違っていたら、後で大きな問題になる。今日のゴールは、データの重複をなくし、効率的にデータを管理するための考え方「正規化」と、その設計図である「ER図」を理解することだ。
1. なぜ設計が必要なのか？～データの重複と不整合の問題～
先生： もしテーブルにデータの重複がたくさんあったら、どうなると思う？例えば、顧客情報と注文情報を1つのテーブルにまとめていたら...
ボット君： user_idが1の山田さんの情報が、2回も重複しています！
先生： そうだね。この設計だと、山田さんの住所が変更になったら、複数の行を更新しないといけなくなる。もし1つだけ更新し忘れたら、住所データに不整合が起きてしまう。
先生： この問題を解決するために、データベースを適切に設計する「正規化」という考え方が生まれたんだ。
2. データの重複をなくす！～正規化の概念～
先生： **正規化（Normalization）**とは、テーブルを適切な形に分割することで、データの重複をなくし、データの整合性を保つための手法だ。段階的にテーブルを分割していく「第1正規化」「第2正規化」「第3正規化」といったルールがある。
先生： さっきのテーブルを正規化してみよう。
先生： 今回の例では、第3正規化まで進めることで、usersテーブルとordersテーブル、productsテーブルという3つのテーブルに分けることができる。
usersテーブル: 顧客情報
productsテーブル: 商品情報
ordersテーブル: 注文情報（どのユーザーがどの商品を注文したか）
このように、関連するデータごとにテーブルを分けることで、データの重複がなくなり、更新や削除も簡単に、安全にできるんだ。
3. 設計図を描く！～ER図（実体関連図）～
先生： データベースの設計をするとき、頭の中だけで考えるのは難しい。そこで、設計図として使われるのが「ER図（Entity-Relationship Diagram）」だ。
先生： ER図は、データベースの構造を視覚的に表現したものだ。ER図は主に3つの要素で構成されている。
実体（Entity）: データのまとまり。テーブルに相当する。
属性（Attribute）: 実体が持つデータ項目。列（カラム）に相当する。
関連（Relationship）: 実体と実体の関係。
users と orders の ER図イメージ
+-------------+ +-----------------+
| users | 1 --< | orders |
+-------------+ +-----------------+
| user_id (PK)| | order_id (PK) |
| user_name | | user_id (FK) |
| ... | | ... |
+-------------+ +-----------------+先生： この図では、usersとordersが1対多の関係にあることがわかるね。「1つのユーザーは複数の注文を持つが、1つの注文は1人のユーザーにしか紐づかない」という意味だ。
ボット君： すごい！これなら、テーブル同士の関係性が一目で分かります！
まとめと次回の予告
先生： 今日のまとめだ。
データベース設計: データの重複をなくし、整合性を保つための重要な工程。
正規化: データの重複を排除するための手法。
ER図: データベースの設計図。実体、属性、関連で構成される。
これらの設計の考え方を身につけることで、ただデータを保存するだけでなく、将来の変更にも強い、堅牢なデータベースを作ることができるようになる。
先生： 次回は、データベースのデータ品質を守るための「キーの多様性」と「整合性制約」について学んでいこう。
次回：第5回: キーの多様性と整合性制約～データ品質を守る番人たち～
#データベース #SQL #正規化 #ER図 #データベース設計 #プログラミング学習
