データベースを2番目の正規形にする
先月、データベーステーブルを正規化するいくつかの面を見てきました。 まず、データベースの正規化の基本原則について説明しました。 前回、最初の正規形（1NF）で定められた基本的な要件を調査しました。 さて、私たちの旅を続けて、2番目の正規形（2NF）の原則をカバーしましょう。
2NFの一般的な要件を思い出してください。
- テーブルの複数の行に適用されるデータのサブセットを削除し、別々のテーブルに配置します。
- 外部キーを使用して、これらの新しいテーブルとその前のテーブルとの関係を作成します。
これらのルールは、簡単なステートメントで要約できます。2NFは、テーブル内の冗長データの量を減らして新しいテーブルに配置し、それらのテーブル間の関係を作成することによってテーブル内の冗長データの量を削減しようとします。
例を見てみましょう。 顧客情報をデータベースに保存するオンラインストアを想像してみてください。 次の要素を持つCustomersという単一の表があります。
- CustNum
- ファーストネーム
- 苗字
- 住所
- シティ
- 状態
- ZIP
この表を簡単に見てみると、少量の冗長データが明らかです。 私たちは "Sea Cliff、NY 11579"と "Miami、FL 33157"のエントリをそれぞれ2回保管しています。 さて、単純な例ではあまりにも多く追加されたストレージのようには見えないかもしれませんが、テーブルに何千もの行があれば無駄なスペースを想像してください。 また、Sea CliffのZIPコードを変更する場合は、データベース全体のさまざまな場所で変更を加える必要があります。
2NF準拠のデータベース構造では、この冗長な情報が抽出され、別のテーブルに格納されます。 新しいテーブル（ZIPと呼ぶ）は、次のフィールドを持つことができます：
- ZIP
- シティ
- 状態
私たちが超効率的になりたいなら、事前にこの表を記入することもできます。郵便局は、有効なすべての郵便番号と都市/州の関係のディレクトリを提供しています。 確かに、あなたはこの種のデータベースが利用された状況に遭遇しました。 誰かがあなたの郵便番号を尋ねた後、あなたが電話していた市と州を知っていたかもしれません。 このタイプの構成はオペレータのエラーを減らし、効率を上げます。
重複したデータをCustomersテーブルから削除したので、2番目の正規形の最初のルールを満たしました。 2つのテーブルを結合するために外部キーを使用する必要があります。 ZIPコード （ZIPテーブルの主キー）を使用してその関係を作成します。 新しいCustomersテーブルがあります：
- CustNum
- ファーストネーム
- 苗字
- 住所
- ZIP
これで、データベースに格納されている重複情報の量が最小限に抑えられ、構造は2番目の通常の形式になりました！
データベースが正規化されていることを確認するには、このシリーズの他の記事をご覧ください。
- データベースの正規化の基礎
- データベースを最初の正規形にする
- データベースを2番目の正規形にする
- データベースを第3の標準形式にする