データベースの設計

はじめに

本記事は現在Progate Pathでデータベースのコースを学んでいる初学者が内容の整理をかねてまとめたものです。そのため記事の内容に誤りが含まれている可能性があります。ご容赦ください。

RDBの設計まとめ

論理設計の流れ

1. エンティティの抽出
2. エンティティの定義
3. エンティティの関連性定義
4. 正規化
5. ER図を書く

💡 エンティティ ≒ テーブル、エンティティの属性 ≒ カラム と考えてOK。
最初から完璧なエンティティ抽出を目指す必要はなく、正規化の過程でテーブルを追加していくことで、徐々に完成に近づけるのが現実的。

---

物理設計

テーブル関連

• データ型
  • デフォルト値
• 制約（NOT NULL、UNIQUE、PRIMARY KEY、FOREIGN KEYなど）
• インデックス

ハードウェア関連

• サイジング（容量見積もり）
• 冗長構成（RAID、クラスタ構成など）
• バックアップ（定期的なスナップショット、リカバリ対策）

---

論理設計の詳細

エンティティの抽出と定義

DBで管理したい「実体（対象）」を抽出する。

例：TODOアプリ

エンティティ

• user
• todo

属性（カラム）

user

• mail_address
• password
• username

todo

• title
• deadline
• content

主キーの定義

• 実務では id を使うことが多い（サロゲートキー）

エンティティの関連性定義（リレーション）

• 外部キーを持たせて関連性を表現する
  例: todo に user の id を外部キーとして持たせる

---

正規化

第1正規化（1NF）

• 1カラム1データを守る
• 多対多の関係は中間テーブルを作成することで対応

第2正規化（2NF）

• 複合主キーの部分従属を排除
  例：クラス, クラス内番号, 生徒, 担任 の場合、
  担任はクラスに従属する → 生徒テーブルから切り出して 担任テーブルを作る

第3正規化（3NF）

• 非キー属性同士の従属を排除

例：クラス, クラス内番号, 生徒, 委員会ID, 委員会名 の場合、
委員会ID と 委員会名 が非キー属性で従属している → 委員会テーブルを作成

---

ER図の作成

• エンティティごとに箱を描き、属性（カラム）をリスト化
• 関係性を線で結び、エンティティAから見たエンティティBの関係をB側に記述

関係性の表現

• カーディナリティ（多重度）
  • 1対多、1対1、など
• オプショナリティ（任意性）
  • 0を含むか（必須 or 任意）

---