第二正規形（2NF）とは何ですか？

データベースを操作する際には、冗長なデータや整合性のない更新などの問題に遭遇することが一般的です。第二正規形は、最初の正規形（1NF）に基づいてよりクリーンで効率的なテーブルを作成するためのデータベース正規化の手順です。

2NFを理解することは、データベース設計やデータ管理を行う人にとって重要であり、第三正規形（3NF）などの高次の正規化形式の基盤となります。この記事では、2NFの仕組みやテーブルを2NFの要件に合致させる方法、実際の例を探求します。また、2NFの利点や欠点、最も適したユースケースについても説明します。

第二正規形の理解

第二正規形は、部分依存関係を排除することに焦点を当てたデータベース正規化の手順です。これは、関係データベースのパイオニアであるEdgar F. Coddによって、正規化の一環として導入されました。

テーブルが2NFになる前に、最初の正規形のルールを満たさなければなりません。

• アトミシティ：各セルには単一の値が含まれている必要があります（繰り返しグループや配列はありません）。
• ユニークな行：テーブルには明確な主キーが必要です。

2NFはさらに1つのステップを踏んで追加のルールを持っています：部分依存関係を排除する。

部分依存は、非主要属性（候補キーの一部ではない列）が、キー全体ではなく一部にのみ依存する場合に発生します。2NF規則は、すべての非主要属性が主キー全体に依存していることを保証し、キーの一部だけに依存していないことを確認します。テーブル内の部分依存を残しておくと、冗長なデータがデータベースに入り込み、更新や削除時に非効率性や潜在的な矛盾が生じる可能性があります。

理論だけでは少し乾燥しているかもしれませんので、実際の例を見てみましょう。

以下は、Datacampの学生のコース登録テーブルです。

ここで、主キーは 学生ID と コースID の複合です。しかし、非主属性 コース名 と コース料金 は コースID のみに依存し、全体のキーには依存しません。これは2NFに違反します。

<tablesを2NFに分解する手順

表が2NFのルールに従うことを確認するには、以下の手順が必要です:

1. すべての候補キーを特定する: 表内の行を一意に識別する属性の最小セットを特定します。これが候補キーです。
2. 関数従属関係を特定する: 表内のすべての関数従属関係を特定します。具体的には、非主属性（いずれの候補キーにも含まれない属性）が複合キーの一部にのみ依存する関数従属関係を探します。
3. 部分的な依存関係を排除する：各部分的な依存関係について：
• 依存する属性をキーの一部と共に新しいテーブルに移動します。
• 新しいテーブルに一意の主キーがあることを確認します。
4. 部分的な依存関係がなくなるまで繰り返します：すべてのテーブル内の非主属性がそれぞれの主キーに完全に依存していることを確認します。

実践における第二正規形の例

さて、2つの例を見てみましょう。

例1：コース登録テーブル

以前、次のコース登録テーブルを見ました：

前のセクションで概説したステップに従いましょう。

1. 候補キーを特定します。

この場合、候補キーは 学生ID と コースID の複合キーです。このユニークな組み合わせがテーブル内の各行を特定します。

2. 機能的依存関係を特定します

コース名と講師名はコースIDに依存しており、完全な複合キー（学生ID、コースID）には依存していません。これは部分依存性であり、これらの属性は複合キーの一部にのみ依存しています。

3. 部分依存関係の排除

キーの一部にのみ依存する属性（コース名 と インストラクター名）を コースID のみに基づく新しいテーブルに移動する必要があります。

分解後、新しいテーブルは次のようになります：

コース登録表

コース詳細表

例2：注文テーブル

このOrdersテーブルから始めます。上で説明した手順に従って、このテーブルを自分で分解してみてください！

1. 候補キーを特定する

注文IDと製品IDの組み合わせは、各行を一意に識別し、（注文ID、製品ID）を複合候補キーとして構成します。単一の列では行を一意に識別できません。:

• 注文IDは単独ではユニークではありません。複数の製品が同じ注文に含まれる可能性があります。
• 製品IDは単独ではユニークではありません。同じ製品が異なる注文に含まれることがあります。

これは、（注文ID、製品ID）も私たちの主キーです。

2. 私たちの機能依存関係を決定します。

注文日は注文IDに依存します（完全な複合キーではなく）。これは部分的な依存関係です。

製品名およびサプライヤー名は製品IDに依存します（完全な複合キーではありません）。これらも部分依存関係です。

3. 部分的な依存関係を排除する

各論理依存関係に対処する小さなテーブルにテーブルを分割する必要があります。 

まず、注文IDに特有の情報を含む注文情報のテーブルを作成します。

注文テーブル

次に、製品IDに特有の情報を含むテーブルを作成します。

オーダーテーブル

現在、私たちのデータベースは2NFにあります。なぜなら、1) すべての部分依存関係が排除され、2) nプライム属性はそれぞれのプライマリーキーに完全に依存しています。

第二正規形を実装するタイミング

では、なぜデータベースを2NFにリファクタリングする必要があるのでしょうか？それだけで十分なのか、それとももう一歩進んで3NFを目指すべきなのでしょうか？

第二正規形の利点と制限

第二正規形は、データベースの正規化プロセスにおいて有用なステップであり、いくつかの利点を提供します：

• データの整合性が向上：部分依存関係を排除することで、2NFは挿入、更新、削除の異常を最小限に抑え、より信頼性の高いデータベースを実現します。
• 冗長性の削減：2NFはデータの重複を減少させ、ストレージの使用を最適化し、データの保守を簡素化します。
• 改善されたデータ構造:よりクリーンで効率的なデータベース設計を作成することで、第三正規形への進行など、さらなる正規化の基盤を築きます。

しかし、いくつかの制限があります:

• 複雑性の増加:2NFを満たすためにテーブルを分解することは、特に複合キーと依存関係を扱う際に、設計プロセスをより複雑にする可能性があります。
• 追加の結合: テーブルの分割には、クエリでより多くの結合が必要になる場合があり、大規模なデータセットや複雑なクエリを持つシステムのパフォーマンスに影響を与える可能性があります – 以下で詳しく説明します。
• 残余冗長性: 2NFは部分依存関係を減らすものの、推移的依存関係には対処しておらず、3NFで対処されるまで一部の冗長性が残ります。

第2正規形に関するパフォーマンス上の考慮

テーブルを分解して部分的依存を排除することは、データベースのパフォーマンスに直接影響する可能性があります。一方で、第2正規形を達成することでデータの冗長性が減少し、整合性が向上し、挿入、更新、削除操作時の異常が少なくなります。しかし、正規化はテーブルの数を増やす可能性があり、関連データを取得する際に追加の結合が必要になるため、大規模なデータセットのクエリパフォーマンスに影響を与える可能性があります。

正規化したデータベースがパフォーマンスを維持するためには、以下のベストプラクティスに従うことが重要です:

• インデックス: 分解されたテーブル間の結合を高速化するためにインデックスを使用します。
• クエリの最適化: 追加の結合のコストを最小限に抑えるためにクエリを最適化します。
• ハイブリッドアプローチ: パフォーマンスが重要なレポートテーブルなどの領域で正規化と非正規化を組み合わせます。
• 定期的なモニタリング: 潜在的な問題を見逃さないようにプロファイリングツールを使用してデータベースのパフォーマンスを継続的に評価します。

2NF は第三正規形を達成するための過渡的な段階にすぎませんか？

ほとんどの場合、データベース設計者は、冗長性をさらに減少させ、全体的なデータ整合性を向上させる能力を持つ第三正規形を達成しようと努力します。ただし、3NFを達成するには、さらなる作業が必要であり、より多くのテーブルや関係を作成するなど、クエリの実行に複雑さとパフォーマンスのトレードオフを導入する可能性があります。

第二正規形のみを使用するだけで十分なケースもあります。シンプルさと迅速な実装が優先事項である場合、例えば小規模プロジェクト、プロトタイピング、データ冗長性が最小限である状況などでは、2NFで十分です。例えば、すべての属性がすでに単純な主キーに完全に依存しているシステムでは、2NFを達成することで部分的な依存性を減らす主要目標を達成でき、さらなる正規化の必要がない場合があります。

第二正規形を超えて: 第三正規形に向けて

データベースをさらに正規化したい場合は、テーブルをリファクタリングして第三正規形に到達することができます。

3NFは、2NFを基にして推移的依存関係に対処します。これは、非キー属性が主キーではなく他の非キー属性に依存する状況です。この進展により、各属性が主キーに直接依存し、それ以外のものに依存しないことが保証されます。

たとえば、コースの登録を追跡するテーブルでは：

• 第2正規形 (2NF): コース名や学生名などの属性が、それぞれの主キー（例: 学生ID と コースID）に完全に依存していることを保証します。これにより、非キー属性が複合キーの一部のみに依存する部分的依存関係が排除されます。
• 3NF：講師の詳細や部門情報などの属性が別々のテーブルに格納され、推移的依存関係が排除されることを保証します。

データのボリュームが増えるにつれて、データの整合性と効率が重要な複雑なシステムには3NFが理想的です。3NFおよびより制限が厳しいBCNFについて詳しく知りたい場合は、当社の第3正規形とは何か？記事をご覧ください。

結論

第2正規形は、データベースの正規化において1NFと3NFなどの高次の形式との間の重要なステップです。部分的依存関係を除去することで、2NFは冗長性を減らし、データの信頼性を向上させます。いくらかの複雑さを伴うかもしれませんが、データ整合性の向上と保守の簡素化の利点により、効果的なデータベース設計の重要な要素となります。

スキルをさらに向上させる準備ができているなら、データベース設計コースを探求して、正規化技術とその実用的な応用についての理解を深めてください。また、当社のSQLアソシエイト認証を通じて、SQLおよびデータベース管理スキルを検証し、潜在的な雇用主に専門知識を示すこともできます！

最後に、もしあなたがビジネスの意思決定者であり、よりクリーンで効率的なデータベースを作成する必要があることを知っているなら、DataCamp for Businessのデモリクエストを検討してください。私たちは、チームの能力を変革し、ビジネスの効率性と革新を促進するスケーラブルなデータベースシステムを構築できるようお手伝いします。カスタマイズされた学習パスやトラックの作成も可能です。。