第三正規形（3NF）とは何ですか？

大規模で構造化されていないデータベースを想像してみてください。繰り返し、冗長な情報で満たされています。更新や削除ごとに、エラーや矛盾をリスクとする潜在的な災害となります。第三正規形（3NF）は、この混乱を避けるための証明済みのデータベース正規化手法です。3NFを実装することで、データ構造がきれいに整理され、効率的で整然とし、不要な冗長性がないことが確認されます。

この記事では、3NFの仕組み、価値、および実践方法について探求します。また、3NFを他の形式と比較し、それぞれを使用するタイミングについて学びます。これらの構造についてさらに学ぶことは誰にとっても有益ですが、データベースデザイナーやデータサイエンティストの場合は特に価値があります。なぜなら、これにより作業が大幅に簡素化され、データベースが信頼性を保つことができるからです。データベース設計全体に興味がある場合は、当社の完全なデータベース設計コースをご覧ください。

第三正規形（3NF）の定義

第三正規形は、不要な依存関係を排除するデータベース正規化の重要な概念です。3NFは第一正規形（1NF）および第二正規形（2NF）に基づいており、それらのルールを継承しています。1NFは各セルに原子（不可分）値を要求し、2NFは複合主キーに対する部分依存を排除します。3NFはさらに進んで、推移的依存関係を排除します。これは、非キー属性が主キーに間接的に依存する状況です。

これに焦点を当てることで、3NFはテーブル内の各非キー列が主キーに直接結びついていることを保証し、他の何にも依存しないようにします。より実用的な観点から見ると、3NFは冗長性を最小限に抑え、データの挿入、更新、または削除時の異常を回避するのに役立ちます。

1970年代にエドガー・F・コッドは、完全に正規化されたデータベース構造を実現するための条件を定式化するために3NFを導入しました。その数年後、カルロ・ザニオロによる再定式化は、「古典的な」3NFとより制限的なボイス・コッド正規形（BCNF）の違いについてより明確な説明を提供しました。今のところBCNFについてあまり心配しないでください。後で戻ってきます。

第三正規形の条件を理解する

3NFを達成するには、具体的には何が必要ですか？ テーブルが資格を得るには、いくつかの条件を満たす必要があります：

• 2NFにあること：これは、すでに原子的で、繰り返しグループもなく、複合キーに対する部分的な依存関係もないことを意味します。

3NFは2NFと1NFを含みます。著者によるイメージ

• 推移的な依存関係がないこと：このルールが重要です。3NFのテーブルでは、任意の非主キーカラムは、他の非キーカラムを介するのではなく、単に主キーにのみ依存する必要があります。

それが実際に何を意味するのかを見てみましょう。

3NFを達成するためのテーブルの分解

テーブルを分解して3NFに達するプロセスを見ていきましょう。各ステップを説明するために、DataCampのコースからいくつかのサンプルデータを使用します。

ステップ1: 推移的依存関係の特定

まず、テーブル内の任意の属性が主キーに間接的に依存しているかどうかを調べます。一般的な基準として、属性が主キー以外の何かに依存している場合、これは推移的依存関係を示します。これは、テーブルを分割する時期が来ている可能性があることを示しています。

以下の3つのテーブルを見てください。どれに推移的依存関係がありますか？

テーブル1: コース

テーブル2: インストラクター

この表では、コース名はコースIDに依存していますが、登録ID（主キー）には直接依存していません。この間接的な依存関係により、コース名は推移的依存関係となります。

ステップ2：データを新しいテーブルに分ける

推移的依存関係に対処するために、テーブル1を2つのテーブルに分割します。各テーブルは直接依存するデータに焦点を当てます。

修正された登録テーブル

コーステーブル

この分解により、テーブルは今や3NFの要件を満たし、冗長性が排除され、各テーブルが直接関連する情報のみを格納することが保証されます。

自分でデータベースを作成してみたい場合は、当社の「PostgreSQLデータベースの作成」コースをご覧ください。少し進んでいる方は、「Snowflakeにおけるデータモデリング入門」もおすすめです。エンティティ関係および次元モデリングなどの考え方がカバーされています。

第三正規形の利点と制限

では、なぜこのような努力をして3NFに到達するのでしょうか？主な特典は以下の通りです。

• データ整合性の向上: 3NFによって推移的依存関係が排除されることで、更新や削除が表全体にわたって競合や古いデータを引き起こすことが防がれます。
• 冗長性の削減: 冗長性の低減により、データベースのメンテナンスが容易になり、ストレージの使用量が削減されます。
• データ保守の簡素化: 類似情報を専用のテーブルに保持することで、冗長なエントリを追跡する必要がなくなり、レコードの更新が容易になります。

それは、3NF構造がデータの正確性をサポートする一方、追加のテーブル結合によって複雑なクエリが遅くなることがあるため、より分割されたデータにつながることがあります。速度が正規化の必要性よりも優先されるケースでは、BCNFまたは4NFがより実用的なオプションになるかもしれません。

比較：第1、第2、第3、およびBC正規形

フォームの違いを見てみましょう。

比較表：第1、第2、第3正規形

以下は、1NF、2NF、および3NFの要件を理解するのに役立つ比較表です。

BCNFは、重複する候補キーによって生じる異常をさらに排除する、3NFの「厳格な」形式です。3NFだけでは依存関係を完全に排除できない複雑なケースで特に有用です。BCNFは、非プライマリ属性が複合候補キーの一部である属性に依存する場合に適用されます。難しそうに聞こえるかもしれませんが、例を使って分解してみましょう。

現在の構造（3NFにおいて）

3NFを達成するために分解した結果、次の2つのテーブルが得られました：

登録テーブル

コーステーブル

新しい要件の紹介

さて、Coursesに新しい属性を追加します:各コースが開講される教室。この新しい属性は、BCNFが必要なシナリオを引き起こす可能性があります。

更新されたコーステーブル（3NF）

これにより、現在2つの候補キーがあります：

1. コースID
2. コース名

両方の候補キーを持つことで、3NFが対処していない問題が生じました：教室はコース名に依存しており、単にコースIDには依存していません。

BCNFを適用する

この依存関係の問題を解消するために、コーステーブルを2つにさらに分解して、BCNFにより適合するようにします:

1. 新しいコーステーブルは、コースIDとコース名だけを含んでいます。
2. A コース詳細テーブルで、コース名と教室の関連を保存します。

これは次のようになります：

改訂されたコーステーブル（BCNF）

CourseDetailsテーブル（BCNF）

• コース テーブルでは、コースID が主キーであり、すべての属性がそれに完全に依存しています。
• CourseDetailsテーブルでは、Course Nameが主キーであり、ClassroomはCourse Nameにのみ依存しています。。

このセットアップは、重複する候補キーによって引き起こされる依存関係の問題を取り除き、厳密に正規化された構造を保証します。

結論

第3正規形は、データをクリーンで一貫性があり、問題のある依存関係から解放された状態に保つことを目指すデータベース設計者にとって貴重なツールです。3NFを使用することで、データの整合性が向上し、管理がスムーズになり、冗長性が減少します。3NFはほとんどの状況でうまく機能しますが、より複雑なデータベースではBCNFや4NFのような追加の形態が有益な場合があります。

この記事が役に立ったと思ったら、次のステップとして私たちのSQLアソシエイト認定を取得することを検討してください。これは、あなたのSQLとデータベース管理のスキルを検証し、潜在的な雇用主に専門性を示す素晴らしい方法です！