データベース設計の基礎について

今回はデータベース設計について学んだことをまとめます。
特に実務でも必ず使う論理設計と正規化に重点を置き、初心者でもイメージしやすいように解説できたらと考えています。

1. DB設計の全体像

DB設計は、ざっくり以下3つのステップで進めます。

・扱う情報や関係性を明確にする
・ER図（Entity Relationship Diagram）で表す

例：ユーザーが商品を注文する → 「ユーザー」「注文」「商品」というエンティティを洗い出す

・データをRDB（リレーショナルデータベース）で使える形に変換
・主キー、外部キー、正規化を行う

・データ型やインデックス設計
・DBMSごとの最適化

【ポイント】
概念設計は「何を扱うか」、論理設計は「どう整理するか」、物理設計は「どう動かすか」

論理設計は、データを重複が少なく矛盾が起きにくい形に整理する作業です。

2-1. 主キー（Primary Key）
・各行を一意に識別するためのキー
・重複やNULLは禁止
例：user_id、order_id

2-2. 外部キー（Foreign Key）
・他のテーブルの主キーを参照するカラム
・データの関係性を保つ
例：orders.user_id → users.user_id

2-3. データ型の選択
・正しい型を選ぶことで性能や整合性が上がる
・数値はINTやBIGINT、日付はDATEやDATETIME

例：ユーザーと注文の関係
テーブル : users
・user_id (PK)
・name
・email

テーブル : orders
・order_id (PK)
・user_id (FK → users.user_id)
・order_date

正規化とは、冗長性を減らし整合性を保つためにテーブルを分割する作業です。
一言で言うと「意味ごとにテーブルを分けて整理する」ことです。

・各カラムには1つの値だけを入れる
・繰り返しカラムを作らない

・複合キーの一部にだけ依存する列を分ける
・主キーが2つ以上のカラムで構成されている場合に注意
例： (order_id, product_id) が主キーで、order_dateはorder_idだけで決まる場合、order_dateは別テーブルに分離する

・主キー以外の列同士の依存を排除
例：住所テーブルに郵便番号から都道府県が決まる場合、都道府県は郵便番号から導けるため別テーブルに分離する

4. 正規化のメリットとデメリット

【メリット】
・データの重複削減
・更新時の整合性維持
・論理的な整理による可読性向上

【デメリット】
・JOINが多くなり、性能が落ちる可能性がある
・過度な分割は管理が複雑

実務では第3正規形まで行い、必要に応じて非正規化するのが一般的です。

・最初にしっかり設計すれば、後からの修正コストが大幅に減る
・正規化は理屈だけでなく、サンプルを作って試すと理解が深まる
・ER図を描くと頭の中が整理される
・完璧な正規化は不要で、システムの性質や速度も考慮が必要になる

・論理設計は「データを整理する技術」
・正規化は「冗長性をなくし整合性を保つ方法」
・実務では正規化とパフォーマンスのバランスが重要
・最初の設計が後の保守性を左右する

・書籍「達人に学ぶDB設計徹底指南書」