第三正規形（3NF）とは：データベース正規化の定義と判定基準

第三正規形（3NF）の定義と判定基準をわかりやすく解説。主キー依存や非キー列の削除で冗長性を排除し、安全で効率的なデータ設計を実践する方法を紹介。

第3正規形（3NF）とは、関係モデル、特にテーブルの設計における正規化の基準の一つで、冗長性の低減と更新異常の回避を目的とします。

定義と本質

一般に第3正規形は、表がまず第二正規形（および第一正規形）であることを前提とし、さらに「推移的依存（transitive dependency）」が存在しないことを要求します。より形式的には、関係Rにおける任意の関数従属性 X → A について次のいずれかが成り立てばRは3NFである、と定義できます。

• XがRのスーパーキー（行を一意に識別する列の組み合わせ）である。
• Aが「素属性（prime attribute）」である（つまり、Aがいずれかの候補キーの一部である）。

ここで素属性とは、ある候補キー（最小のキー）の一部となる列を指します。逆に、どの候補キーにも含まれない列は非素属性（non-prime attribute）と呼ばれます。

判定の手順（チェックリスト）

• まず表が第一正規形（列に原子値のみを持つ）であることを確認する。
• 第二正規形（主キーが複合キーの場合に部分依存がない）を満たしていることを確認する。
• 表内のすべての関数従属性 X → A を列挙する。
• 各従属性について、Xがスーパーキーであるか、またはAが素属性であるかをチェックする。どちらにも当てはまらない従属性が存在すれば3NF違反である。

トランジティブ依存（例と解決）

典型的な違反例を示します。従属性が次のように存在する場合：

• StudentID → DeptID
• DeptID → DeptName

このとき StudentID → DeptName は推移的依存です（DeptName は StudentID の非キー属性 DeptID を介して決まる）。DeptName が候補キーの一部でない場合、3NFに違反します。解決策は Dept テーブルを分割して、DeptID、DeptName を別の表に移すことです。これにより DeptName の重複や更新異常を防げます。

BCNFとの違い

第3正規形は素属性に関する例外を許しますが、ボイス＝コッド正規形（BCNF）はさらに厳しく、任意の関数従属性 X → A に対して常に X がスーパーキーであることを要求します。したがって、BCNF は 3NF より強い（制約が厳しい）正規形です。ただし実務では、3NF の方が候補キーに関する例外により実装上の利便性を保てる場合があります。

実務上の注意点

• 利点：データの冗長性と更新・削除・挿入の異常を低減できる。
• 欠点：正規化を進めすぎるとテーブル分割が増え、結合（JOIN）が多くなり性能に影響することがある。実運用ではパフォーマンスや運用性を考慮して部分的な非正規化（デノーマライズ）を行うことがある。
• 判断基準：理論的には3NFを満たすことが望ましいが、システム要件（読み取り頻度、書き込み頻度、インデックス戦略、トランザクション要件など）に応じて最適な設計を選ぶ。

まとめ（ポイント）

• 第3正規形は第1・第2正規形を満たした上で、非キー属性が主キーに対して推移的に依存しないことを要求する。
• 形式的には「任意の X → A に対し、X がスーパーキーであるか、A が素属性である」ことが必要条件。
• BCNF はこれより厳しく、すべての決定子がスーパーキーであることを要求する。
• 実務では正規化と性能（結合コスト）のバランスを取りながら設計するのが現実的。

参考：主キーとは、テーブルの行を一意に識別し、インデックス等で利用される1つ以上の列の組み合わせを指します。不要な列（主キーと関連しない列や、推移的に決まる列）は分割して別表にすることで冗長性を減らします。

文字で検索