【要約】【初心者メモ】DB設計の正規化を第1〜第5正規形まで、注文テーブルで整理してみた [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
DB設計の初心者が、データの重複や矛盾を防ぐための「正規化」の具体的な手順と、その適用範囲に迷うという課題がある。設計者が直面する具体的な問題は以下の通りである。
- ・正規化の各段階が、具体的にどのようなデータの不整合を解決するのかが不明瞭である。
- ・第3正規形以降の高度な正規形が、実務のどのような場面で必要になるのか判断しにくい。
- ・正規化を徹底することで、JOINコストの増大や集計処理の遅延といった性能劣化を招く懸念がある。
// Approach
筆者は、注文テーブルを用いた段階的な分解プロセスと、特殊なケースを用いた専用の例示により、正規化の概念を構造的に整理している。採用された手法は以下の通りである。
- ・第1〜第3正規形：注文テーブルを使い、1セル1値、部分関数従属、推移的関数従属の排除を順に説明する。
- ・BCNF・第4・第5正規形：塾の受講や社員のスキル等の例を用い、特殊な従属関係を解説する。
- ・非正規化の検討：マスタとトランザクションの特性を分け、高負荷な場合にのみ、整合性リスクを承知で重複を許容する手法を提示する。
// Result
学習者が正規化の理論的背景から、実務における判断基準までを体系的に理解できる。得られる成果は以下の通りである。
- ・第1〜第3正規形が実務の主要なゴールであることを明確に示した。
- ・4NFや5NFは、理論的な知識として保持すべき境界線であることを提示した。
- ・「まず正規化し、必要に応じて非正規化する」という、設計の優先順位を明確に定義した。
Senior Engineer Insight
> 理論と実務の境界線を明確に引いている点が評価できる。大規模システムでは、正規化による整合性確保は絶対条件だ。しかし、トランザクションの増大に伴うJOINコストは、致命的なレイテンシを招く。設計者は、マスタは徹底的に正規化し、高頻度な読み取りが発生するトランザクション系では、整合性維持のコストと引き換えに非正規化を戦略的に選択する「引き算の設計」が求められる。