第3正規形：推移的関数従属性がない状態。主キー以外のカラムが主キー以外のカラムに依存していない。

BCNF（ボイスコッド正規形）：第3正規形よりさらに厳密で、すべての決定子が候補キーである状態。

違い：ほとんどのテーブルでは第3正規形を満たせば自動的にBCNFも満たす。しかし、複数の候補キーが存在し、それらが重なる特殊なケースでは、第3正規形でもBCNFを満たさない場合がある。

実務では第3正規形まで正規化するのが一般的です。

理由：

• 第3正規形で、データの整合性、保守性、拡張性が十分に確保できる
• BCNFや第4正規形が必要になるケースは非常に稀
• 第3正規形を超えると設計が複雑になり、開発・保守コストが増大する
• パフォーマンス要件がある場合は、第3正規形から戦略的に非正規化する

1. 読み取り性能が極めて重要で、JOIN処理がボトルネックになっている場合（例：頻繁にアクセスされるレポート画面）
2. 更新頻度が非常に低いデータ（例：マスタデータ、注文時の商品名や単価の記録）
3. レポート・分析用のテーブル（データウェアハウス、集計済みデータのキャッシュテーブル）

重要：いずれの場合も、元の正規化されたテーブルは必ず残すことが前提です。

BCNFではない理由：

• 決定子「科目名」は候補キーではないが、「教室」を決定している
• 科目名 → 教室（科目名は候補キーではない）

BCNFへの変換：

改善点：
✅ 「科目名 → 教室」の関係を別テーブルに分離
✅ すべての決定子が候補キーになった
✅ BCNFを満たす

多値従属性の分析：

• 教員ID →→ 科目名（1人の教員が複数の科目を担当）
• 教員ID →→ 教科書名（1人の教員が複数の教科書を使用）
• 科目名と教科書名は独立している（多値従属性）

第4正規形への変換：

改善点：
✅ 独立した多値従属性を別テーブルに分離
✅ データの冗長性を削減（元は4レコード → 合計4レコード）
✅ 科目と教科書を独立して管理できる

非正規化の提案：

1. order_details テーブルに商品名と単価を追加

なぜこの非正規化が適切か：

• ✅ 読み取り頻度が高い（1日1万回以上）
• ✅ 更新頻度は低い（注文確定後はほぼ更新しない）
• ✅ 注文時の商品名・単価を保存することは業務的にも意味がある（価格変更の影響を受けない）
• ✅ JOINが不要になり、パフォーマンスが大幅に向上

重要な注意事項：

• ⚠️ 元の正規化されたテーブル（products）は必ず維持
• ⚠️ 注文登録時に、商品マスタから商品名と価格をコピーする
• ⚠️ 集計などの分析クエリは、元のテーブルを使用
• ⚠️ この設計判断をドキュメント化する

シナリオA：経費精算システム → 正規化（第3正規形）

• 理由：頻繁に更新されるため、データの整合性が最重要
• 正規化することで、更新異常を防ぎ、データの一貫性を保証
• 読み取り性能よりも、データの正確性が優先される

シナリオB：売上レポート → 非正規化（集計テーブル）

• 理由：読み取り専用で、更新は日次バッチのみ
• 集計済みデータを保持することで、レポート表示が超高速化
• 元の正規化されたトランザクションデータは別途保持
• 典型的なOLAP（分析処理）用途で、非正規化が適切

シナリオC：チャットアプリ → 正規化（第3正規形）+ 適度な非正規化

• 理由：読み書き両方が頻繁なため、バランスが重要
• 基本は正規化して、データの整合性を保証
• ただし、頻繁に表示される情報（ユーザー名など）は、適度に非正規化してパフォーマンスを確保
• 例：messages テーブルに user_id だけでなく username も保存（表示高速化）
• キャッシュ層（Redis など）も併用を検討

(1) 第3正規形か？

• 第3正規形ではない
• 主キー = (プロジェクトID, 従業員ID)
• 推移的関数従属性がある：(プロジェクトID, 従業員ID) → 従業員ID → 部署名

(2) BCNFか？

• BCNFでもない
• 決定子「従業員ID」は候補キーではないが、「部署名」を決定している

(3) 第3正規形への変換：

改善点：
✅ 推移的関数従属性を排除
✅ 従業員情報は employees テーブルで一元管理
✅ データの整合性が保証される
✅ 第3正規形を満たす（この場合、BCNFも満たす）