LESSON 25分

ストーリー

「設計レビューの前にER図を準備してくれ」

高橋アーキテクトの指示に、あなたは手が止まる。テーブル定義書は書けるが、ER図で表現するのは初めてだ。

「ER図はデータ設計の共通言語だ。チームメンバー、PM、時にはビジネスサイドとも会話できるツールになる。書き方を覚えれば、設計の議論が10倍スムーズになるよ」

ER図の基本要素

Entity（エンティティ）

ビジネスドメインにおける管理対象のオブジェクト。

┌──────────────┐
│    User       │
├──────────────┤
│ PK id         │
│    name       │
│    email      │
│    created_at │
└──────────────┘

Relationship（リレーションシップ）

エンティティ間の関連を表す。

[User] ──1:N──< [Order] ──N:1──> [Product]

Attribute（属性）

エンティティが持つデータ項目。PK（主キー）、FK（外部キー）を明示する。

カーディナリティ（多重度）

記号意味例
1
一対一ユーザー ↔ プロフィール
1
一対多ユーザー → 注文
N
多対多学生 ↔ 講義
0..1ゼロまたは一ユーザー ↔ パスポート
0..Nゼロ以上ユーザー → レビュー

IE記法（Information Engineering）

──||──  1（必須の1）
──|O──  0または1（任意の1）
──<|──  1以上（必須の多）
──<O──  0以上（任意の多）

概念ER図 → 論理ER図 → 物理テーブル

Step 1: 概念ER図

ビジネス要件から主要エンティティと関連を抽出する。

[ユーザー] ──注文する──< [注文] >──含む──< [商品]
                                    │
                              [注文明細]

Step 2: 論理ER図

属性、データ型、制約を追加する。

┌─────────────────┐       ┌─────────────────┐
│     users        │       │     orders       │
├─────────────────┤       ├─────────────────┤
│ PK id: INT       │──1:N─>│ PK id: INT       │
│    name: VARCHAR │       │ FK user_id: INT  │
│    email: VARCHAR│       │    status: ENUM  │
│    created_at    │       │    total: DECIMAL│
└─────────────────┘       │    ordered_at    │
                           └────────┬────────┘
                                    │ 1:N
                           ┌────────▼────────┐
                           │  order_items     │
                           ├─────────────────┤
                           │ PK id: INT       │
                           │ FK order_id: INT │
                           │ FK product_id    │
                           │    quantity: INT  │
                           │    unit_price    │
                           └─────────────────┘

Step 3: SQLでの実装

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100) NOT NULL,
  email VARCHAR(255) NOT NULL UNIQUE,
  created_at TIMESTAMP NOT NULL DEFAULT NOW()
);

CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  user_id INT NOT NULL REFERENCES users(id),
  status VARCHAR(20) NOT NULL DEFAULT 'pending'
    CHECK (status IN ('pending', 'paid', 'shipped', 'delivered', 'cancelled')),
  total DECIMAL(12, 2) NOT NULL DEFAULT 0,
  ordered_at TIMESTAMP NOT NULL DEFAULT NOW()
);

CREATE TABLE order_items (
  id SERIAL PRIMARY KEY,
  order_id INT NOT NULL REFERENCES orders(id),
  product_id INT NOT NULL REFERENCES products(id),
  quantity INT NOT NULL CHECK (quantity > 0),
  unit_price DECIMAL(10, 2) NOT NULL CHECK (unit_price >= 0)
);

TypeScriptの型定義との対応

// ER図のエンティティ → TypeScript interface
interface User {
  id: number;
  name: string;
  email: string;
  createdAt: Date;
}

interface Order {
  id: number;
  userId: number;  // FK: users.id
  status: 'pending' | 'paid' | 'shipped' | 'delivered' | 'cancelled';
  total: number;
  orderedAt: Date;
}

interface OrderItem {
  id: number;
  orderId: number;    // FK: orders.id
  productId: number;  // FK: products.id
  quantity: number;
  unitPrice: number;
}

多対多の解消

N

。

[学生] ──N:M── [講義]

    ↓ 中間テーブルで解消

[学生] ──1:N──< [受講] >──N:1── [講義]
CREATE TABLE students (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100) NOT NULL
);

CREATE TABLE courses (
  id SERIAL PRIMARY KEY,
  title VARCHAR(200) NOT NULL
);

-- 中間テーブル（追加属性を持てる）
CREATE TABLE enrollments (
  student_id INT REFERENCES students(id),
  course_id INT REFERENCES courses(id),
  enrolled_at TIMESTAMP NOT NULL DEFAULT NOW(),
  grade VARCHAR(2),
  PRIMARY KEY (student_id, course_id)
);

ER図作成のベストプラクティス

プラクティス説明
ビジネス用語を使うテーブル名はビジネスの言葉に揃える
主語を明確にリレーションシップに動詞を添える
レイヤーを分ける概念 → 論理 → 物理 を段階的に
ツールを活用dbdiagram.io, PlantUML, Mermaid
バージョン管理DDLをgit管理してER図と同期

まとめ

ポイント内容
ER図の3要素エンティティ、リレーションシップ、属性
カーディナリティ1
, 1
, N
の3パターン
設計ステップ概念ER図 → 論理ER図 → 物理テーブル
N
中間テーブルで1

理解度チェックリスト

  • ER図の基本要素（エンティティ・リレーション・属性）を説明できる
  • カーディナリティ（1
    , 1
    , N
    ）を正しく読める
  • N
  • 概念ER図から論理ER図への変換ができる

次のステップ

次のレッスンでは、各カラムのデータ型と制約の選び方を学ぶ。型の選択ミスがどのような問題を引き起こすか、具体例で理解しよう。

推定読了時間: 25分