SQLでの正規化：1NF、2NF、3NF、およびBCNF

正規化は、リレーショナルデータベースモデルが効率的で、汎用クエリに適しており、挿入、更新、削除の異常などの望ましくない特性がなく、データの整合性が失われることを保証する体系的なプロセスです。 この正規化プロセスは、データの冗長性を排除し、挿入、更新、または削除操作後の不整合の可能性を減らすのにも役立ちます。

理解を深めるために、次のスキーマを検討してください。学生（名前、住所、件名、学年）

このスキーマにはいくつかの問題または非効率性があります。

1）冗長性：学生の住所は、登録されている科目ごとに繰り返されます。

2）異常の更新：1つのタプル（行）のアドレスを更新し、他の行では変更しない可能性があります。 したがって、生徒ごとに一貫して一意の住所を設定することはできません。

3）挿入異常：少なくとも1つの科目を登録せずに学生の住所を記録することはありません。 同様に、学生が新しい科目に登録したい場合、別の住所が挿入される可能性があります。

4）削除の異常：学生が登録されているすべての科目を中止することを決定した場合、削除の過程で学生の住所も失われます。

したがって、タプルの追加、削除、または更新操作の後に異常を作成しないリレーションによってユーザーデータを表すことが重要です。 これは、整合性制約、特にデータベースのデータ依存関係を注意深く分析することによってのみ達成できます。

リレーションは、自然に共存する属性のみがグループ化されるように設計する必要があります。 これは主に、すべてのデータ属性の意味を基本的に理解することで実行できます。 ただし、設計目標を確実にするために、まだいくつかの正式な手段が必要です。

正規化はその正式な尺度です。 これは、属性の特定のグループが他のグループよりも優れている理由の質問に答えます。

今日の時点で、7つの正規形が存在します。

• 第一正規形（1NF）
• 第2正規形（2NF）
• 第3正規形（3NF）
• ボイスコッド正規形（BCNF）
• 第4正規形（4NF）
• 5番目の通常の形式（5NF）
• 6番目またはドメインキーの正規形（6NF）

読む： SQLのビューの種類

第一正規形（1NFまたは最小形）

• 行には上から下への順序、列には左から右への順序はありません。
• 重複する行はありません。
• すべての行と列の共通部分には、該当するドメインの値またはnull値が1つだけ含まれています。 この条件は、すべての列の値がアトミック、スカラー、または単一の値のみを保持する必要があることを示します。 ここでは、複数の列で情報や値を繰り返すことはできません。
• すべての列は規則的です（つまり、行には行ID、オブジェクトID、非表示のタイムスタンプなどの非表示のコンポーネントはありません）。

正規化されていないスキーマの例を見てみましょう。 設計者が顧客の名前と電話番号を記録したいとします。 次に示すように、顧客テーブルを定義します。

ここでは、1NFではありません。 電話番号列はアトミックではないか、スカラー値を持っていません。つまり、1NFでは許可されない複数の値があります。

1NFにする

• まず、1つのテーブルを2つに分割（分解）します。
• 各テーブルには、1つのエンティティに関する情報のみが含まれている必要があります。

この設計では、電話番号のグループが繰り返されることはありません。 代わりに、顧客から電話番号への各リンクが独自のレコードに表示されます。

チェックアウト：最も一般的なSQLインタビューの質問と回答

2番目の正規形

各正規形には、前の形式よりも多くの制約基準があります。 したがって、第2正規形（2NF）以上のテーブルは、定義上、1NFでもあります。 一方、1NFにあるテーブルは、2NFにある場合とない場合があります。 2NFにある場合は、3NFにある場合とない場合があります。

1NFテーブルは、その非プライム属性のいずれも候補キーの一部（適切なサブセット）に機能的に依存していない場合にのみ、2NFにあると言われます。 （非プライム属性はどの候補キーにも属していません。）

1NFテーブルに複合候補キー（複数の属性で構成される候補キー）がない場合、テーブルは自動的に2NFになります。

FDが{BC？ D、AC？ BE、B？ E}は2NFにありますか？

• ご覧のとおり、メンバーシップアルゴリズムを適用することにより、ACのクロージャは（AC）+ = {A、C、B、E、D}になります。 ただし、そのサブセットのいずれも、それ自体で関係のすべての属性を判別できるわけではないため、ACがこの関係の候補キーです。 さらに、AもCも関係の他の属性から導出できないため、{AC}である候補キーは1つだけになります。
• ここで、{A、C}はプライム属性であり、{B、D、E}は非プライム属性です。
• 1NFのリレーショナルDBMSは複数値または複合属性を許可しないため、リレーションRはすでに第1正規形になっています。

紀元前？ BCは候補キーACの適切なサブセットではないため、Dは第2正規形です。

交流 ？ AC自体が候補キーであるため、BEは第2正規形であり、

B？ Eは第2正規形ですが、Bは候補キーACの適切なサブセットではありません。

したがって、与えられた関係Rは第2正規形になります。

第3正規形

テーブルは、その機能依存性のそれぞれについてのみ、3NFにあると言われます。

X→A 、次の条件の少なくとも1つが成り立ちます。

• XにAが含まれている（つまり、X→Aは自明な機能従属性です）、または
• Xはスーパーキー、または
• Aは主要な属性です（つまり、Aは候補キー内に存在します）

3NFの別の定義では、Rのすべての非キー属性がRの主キーに非遷移的に依存している（つまり直接依存している）。これは、非プライム属性（候補キーの一部ではない）が他の非プライム属性に機能的に依存していないことを意味します。 A？のような2つの依存関係がある場合BとBC、そしてこれらのFDから、Aを導き出すことができますか？ C.この依存関係ACは推移的です。

3NFの例：

指定されたFDのセットとの次の関係Order（Order＃、Part、Supplier、UnitPrice、QtyOrdered）について考えてみます。

注文＃ ？ 部品、サプライヤー、QtyOrderedおよびサプライヤー、部品？ 単価）

ここで、Order＃が関係の鍵となります。

アムストロングの公理を使用して、

注文＃ ？ パーツ、注文？ サプライヤー、および注文？ QtyOrdered。

注文＃ ？ 部品、サプライヤーおよびサプライヤー、部品？ 単価、両方とも注文番号を示しますか？ 単価。

したがって、すべての非プライム属性がキー（Order＃）に依存していることがわかります。 ただし、Order＃とUnitPriceの間には推移的な依存関係があります。 したがって、この関係は3NFにはありません。 どうやって3NFでそれを作るのですか？

誰かがその部品を注文しない限り、サプライヤーから供給された部品のUnitPriceを保存することはできません。 したがって、次のようにテーブルを分解して3NFに従うようにする必要があります。

Order （Order＃、Part、Supplier、QtyOrdered）およびPrice Master （Part、Supplier、UnitPrice）。

現在、推移的な依存関係はありません。 関係は3NFにあります。

また読む：データサイエンスのためのSQL

世界のトップ大学からオンラインでソフトウェアコースを学びましょう。 エグゼクティブPGプログラム、高度な証明書プログラム、または修士プログラムを取得して、キャリアを早急に進めましょう。

結論

正規化には、BCNF、4NF、5NF、6NFなどがあります。 つまり、3NFの最後のルールはここでは適用されないため、BCNFは3NFの拡張に他なりません。 すべての機能依存性は、左側にキー属性を持ち、右側にキー属性を持たない必要があります。 （BCNFは3.5NFとも呼ばれます）。 ただし、4NF以降の正規形は、通常の慣行ではほとんど実装されていません。

フルスタック開発の詳細に興味がある場合は、upGrad＆IIIT-Bのフルスタックソフトウェア開発のエグゼクティブPGプログラムをチェックしてください。これは、働く専門家向けに設計されており、500時間以上の厳格なトレーニング、9以上のプロジェクトを提供します。および割り当て、IIIT-B卒業生のステータス、実践的な実践的なキャップストーンプロジェクト、およびトップ企業との雇用支援。