ER図は、データベースを扱う上で非常に重要な「設計図」です。このガイドでその核心を掴み、自在に使いこなせるようになりましょう。
ER図の基本：データベースの設計図を理解する
ER図（Entity-Relationship Diagram）は、その名の通り**「何が（Entity）」「どう関係しているか（Relationship）」**を視覚的に表現した図です。家を建てる前に設計図が必要なように、データベースを作る前にはER図でデータの構造を設計します。
- 歴史と立ち位置: ガイドにあるように、ER図は「お父さん世代」の技術と言われることがあります。これは、プロセスの流れを示す「おじいちゃん世代」のフローチャートから、システムの振る舞いや構造をより包括的に示す「息子世代」のUML（クラス図など）へと設計手法が進化してきた歴史があるためです。
- 現代での重要性: しかし、アプリケーションの設計がUML中心になった現代でも、データの構造を専門に扱う場面（データ分析、ビッグデータ基盤構築、既存システムの改修など）では、ER図が依然として最も強力で分かりやすいツールです。データの関係性を議論する際の「共通言語」と言えるでしょう。
ER図の主要な登場人物
ER図を構成する基本的な3つの要素を覚えましょう。
1. エンティティ (Entity)
「実体」と訳され、管理したいデータのまとまりを指します。データベースの「テーブル」に相当し、通常は四角形で表現されます。
- 例：「顧客」「商品」「注文」
2. アトリビュート (Attribute)
エンティティが持つ個別の情報項目です。データベースの「カラム」に相当します。
- 例：「顧客」エンティティには「顧客ID」「氏名」「メールアドレス」などのアトリビュートがある。
3. リレーションシップ (Relationship)
エンティティ同士の関係性を示し、線で表現されます。この関係性を定義するために、後述するキーが重要な役割を果たします。
- 例：「顧客」が商品を「注文する」という関係。
データベースの重要概念とER図
ER図を理解するには、データベースの基本的な用語との対応を知ることが不可欠です。
テーブル、主キー、外部キー
- テーブル: ER図のエンティティそのものです。データを格納する表形式の構造です。
- プライマリーキー (PK: 主キー): テーブル内の各行（レコード）を一意に識別するための特別なアトリビュートです。マイナンバーのように、絶対に重複が許されません。これにより、「このデータ！」と確実に一つを特定できます。ER図では
(PK)のように明記されます。 - フォリンキー (FK: 外部キー): 他のテーブルの主キーを参照するアトリビュートです。これこそがテーブル同士を繋ぐ「架け橋」であり、ER図のリレーションシップを具体的に実現するものです。ER図では
(FK)と明記されます。
重要なポイント: 外部キーのカラム名と、それが参照する主キーのカラム名は必ずしも同じである必要はありません。しかし、両者のデータ型（例：数値、文字列）は必ず一致している必要があります。
具体例で見る関係性
ガイドの例を見てみましょう。「1つのフィードバックに対して複数のボタンが存在する」という関係は、ER図で次のように表現できます。
フィードバックマスター (テーブル)
- フィードバックID (PK)
- タイトル
- ボディ
フィードバックボタン (テーブル)
- ボタンID (PK)
- フィードバックID (FK)
- ボタン名
- リンク
フィードバックボタンテーブルにあるフィードバックID (FK)が、フィードバックマスターテーブルのフィードバックID (PK)と繋がることで、「どのフィードバックに属するボタンか」という関係性が生まれます。これは典型的な**「1対多」**の関係です。
正規化：美しく整理されたデータ構造を目指す
正規化とは、データの重複をなくし、矛盾が起きないようにテーブルを整理整頓するプロセスです。ガイドにある通り、「大きいテーブルを論理的な理屈に基づいて細かく分割していく作業」とイメージしてください。
なぜ正規化が必要か？
例えば、1つの注文テーブルに顧客情報も商品情報もすべて詰め込むと、同じ顧客が何度も注文するたびに氏名や住所が重複して記録されます。もしその顧客が引っ越した場合、過去の全注文データの住所を修正する必要があり、修正漏れや入力ミス（更新異常）の原因になります。
正規化を行うことで、顧客情報は「顧客テーブル」に1つだけ保持し、注文テーブルからはその顧客IDを参照するだけで済むようになります。
正規化のステップ
通常、第三正規形までを目指します。
- 第一正規形: 1つのセルに1つの値しか入っていない状態にする。（繰り返し項目をなくす）
- 第二正規形: 主キーの一部だけで決まる項目を別のテーブルに切り出す。（部分従属の解消）
- 第三正規形: 主キー以外の項目によって決まる項目を別のテーブルに切り出す。（推移的従属の解消）
ER図と正規化の関係: 正規化はテーブルを分割するプロセスです。そしてER図は、その分割されたテーブル間の関係性を可視化するためのものです。両者は切っても切れない関係にあり、セットで学ぶことが不可欠です。
注意点: 正規化を進めすぎるとテーブルが細分化されすぎ、かえってデータの取得が複雑になったり、処理速度が低下したりすることがあります。そのため、通常は第三正規形までが実用的とされています。
システム設計への応用：CRUDと見積もり
CRUD操作
CRUD（クラッド）は、データに対する基本的な4つの操作の頭文字です。
- Create: 作成
- Read: 読み出し
- Update: 更新
- Delete: 削除
ER図とCRUDで何ができるか？
システム開発の見積もりにおいて、ER図は絶大な力を発揮します。
設計されたER図（＝テーブル一覧）があれば、各テーブルに対してどのようなCRUD操作が必要かを洗い出すことができます。
例えば、「顧客」テーブルには、顧客情報を「新規作成」「一覧表示」「詳細表示」「更新」「削除」する機能が必要だと分かります。このように、テーブルごと、ひいてはシステム全体で必要な機能の数を網羅的に把握できるため、開発工数の正確な見積もりに繋がるのです。
設計思想の今と昔
- 過去 (20年前): データ中心。まずER図でデータ構造を固め、それに対するCRUD操作を基本にシステムを設計していました。
- 現在: ユーザー体験（UI/UX）中心。ユーザーが何をしたいか（ユースケース）を起点に画面や操作性を設計し、それに合わせて必要なデータを考えるアプローチが主流です。
しかし、どのようなアプローチであれ、最終的にデータを保存する構造（データベース）は必要です。そのため、既存システムの構造を理解したり、データ中心の機能を改修したりする場面では、ER図とCRUDの知識が今もなお必須のスキルとなっています。