正規化しすぎて業務が見えなくなった話（バランスの取り方）

1. 問題になりやすい具体例（NG例）

「注文情報」を正規化しすぎた例。
注文
├ 注文ID（PK）
├ 顧客ID
注文状態
├ 注文ID（PK, FK）
├ 状態区分コード
状態区分
├ 状態区分コード（PK）
├ 状態名
注文日
├ 注文ID（PK, FK）
├ 注文日
支払方法
├ 支払方法コード（PK）
├ 支払方法名
注文支払
├ 注文ID（PK, FK）
├ 支払方法コード

👉 テーブルが細かく分かれすぎている。

2. なぜこの設計がつらくなるのか

•注文一覧を出すだけでJOINが多い
•業務担当者がER図を見て理解しにくい
•SQLが冗長になり保守性が下がる
「注文の状態と支払方法を一覧で見たい」
という業務的に自然な要求が重くなる。

3. 考え方の整理

正規化は重要だが、
•頻繁に一緒に使う属性
•業務上ひとまとまりの情報
は、無理に分けない方がよい場合もある。

4. 理想の具体例（改善後）

注文テーブル（業務単位でまとめる）
注文
├ 注文ID（PK）
├ 顧客ID（FK）
├ 注文日
├ 状態区分コード
├ 支払方法コード

区分マスタ
状態区分
├ 状態区分コード（PK）
├ 状態名
支払方法
├ 支払方法コード（PK）
├ 支払方法名

✔ 注文は1テーブルで完結
✔ マスタは参照用に分離
✔ SQLがシンプル

1. デスぺ視点でのポイント
   午後Ⅱでは、
   •正規化の正しさ
   •業務処理のしやすさ
   の両立が求められる。
   「正規化されているか」だけでなく
   **「業務要件に合っているか」**が評価される。

まとめ
・正規化は目的ではない
・業務上のまとまりを意識する
・JOINが増えすぎていないか確認する