前のパーツ： 1-3、4-6、7-9
10.データベースの正規化
リレーショナルデータベースの適切な設計のためのガイダンスは、リレーショナルデータモデルで提供されます 。 それらは通常のフォームと呼ばれる5つのグループに収集されます 。 最初の正規形は、データベースの正規化の最低レベルを表します。 5番目のレベルは、最高レベルの正規化を表します。
通常のフォームは、データベースを設計するための推奨事項です。 データベースを設計する際に、5つの通常のフォームすべてに従う必要はありません。 ただし、データベースの効率と使いやすさの点でこのプロセスには多くの重要な利点があるため、データベースをある程度正規化することをお勧めします。
- 正規化されたデータベース構造では、比較的単純なSQLクエリで複雑なデータサンプルを作成できます。
- データの整合性 。 正規化されたデータベースを使用すると、データを確実に保存できます。
- 正規化は、保存されたデータの冗長性を防ぎます 。 データは常に1か所にのみ保存されるため、データの挿入、更新、削除のプロセスが簡単になります。 このルールには例外があります。 キー自体は、外部キーとして他のテーブルにコピーされるため、いくつかの場所に保存されます。
- スケーラビリティは、システムが将来の成長に対処する能力です。 データベースの場合、これは、ユーザー数とデータ量が増加したときに迅速に動作できる必要があることを意味します。 スケーラビリティは、RDBMSのデータベースモデルの非常に重要な特性です。
データベースの正規化に関連する主なポイントの一部を次に示します 。
- データを論理的なグループまたはセットに整理します。
- データセット間の関係を見つける。 1対多および多対多の関係の例をすでに見ました。
- データの冗長性を最小限に抑えます。
非常に少数のデータベースが、リレーショナルデータモデルで提供される5つの標準形式すべてに従います。 データベースは通常、2番目または3番目の正規形に正規化されます。 4番目と5番目の形式はほとんど使用されません。 したがって、最初の3つについてのみ説明することに限定します。
11.最初の標準形（1NF）
最初の標準形式では、データベーステーブルは、作成しているシステムの本質を表すものです。 エンティティの例：注文、顧客、注文チケット、ホテル、商品など。 データベースの各エントリは、1つのエンティティインスタンスを表します。 たとえば、顧客テーブルでは、各レコードは1人の顧客を表します。
主キー
ルール：各テーブルには、可能な限り少ない数のフィールドで構成される主キーがあります。
ご存じのように、主キーは複数のフィールドで構成できます。 たとえば、姓と名を主キーとして選択できます（この組み合わせが常に一意になることを期待します）。 それははるかに良い選択のソーシャルルームでしょう。 主キーとしての保険 個人を一意に識別する唯一のフィールドです。
さらに良いことに、主キーのタイトルの明確な候補がない場合は、数値の自動インクリメントフィールドの形式で代理主キーを作成します。
原子性。
ルール：各レコードにはフィールドが重複しておらず、各フィールドには1つの値のみが含まれています。
たとえば、すべてのコレクターが自分の車を登録できるカーコレクターのWebサイトを見てください。 以下の表には、登録された車に関する情報が格納されています。
水平方向のデータ複製は悪い習慣です。
この設計オプションを使用すると、5台の車しか保存できず、5台未満の場合は、空のセルを保存するためにデータベース内の空き領域を無駄にしています。
悪い設計手法のもう1つの例は、セルに複数の値を格納することです。
1つのセルに複数の値。
この場合の正しい決定は、別のテーブルでの車の割り当てと、このテーブルを参照する外部キーの使用です。
エントリの順序は重要ではありません。
ルール：テーブルエントリの順序は重要ではありません。
顧客テーブルのエントリの順序を使用して、どの顧客が最初に登録したかを判断する場合があります。 これらの目的のために、顧客を登録するための日付と時刻のフィールドを作成する方が適切です。 顧客が削除、変更、または追加されると、レコードの順序は必然的に変わります。 これが、テーブル内のエントリの順序に決して依存すべきではない理由です。
次のパートでは、2番目の正規形（2NF）について検討します。
12. 2番目の標準形。
データベースを2番目の正規形に従って正規化するには、最初の正規形に従って正規化する必要があります。 2番目の標準形式は、データの冗長性に関連付けられています。
データの冗長性。
規則：非主キーを持つフィールドは、主キーに依存してはなりません。
少し難解に聞こえるかもしれません。 そしてこれは、別のエンティティに関連せず、テーブルに直接関連するデータのみを保存する必要があることを意味します。 2番目の標準形式に続くのは、テーブルエントリで重複していることが多く、別のエンティティに属している可能性のあるデータを見つける問題です。
ストアフィールド内のレコード間のデータの複製。
上記の表は、自動車を販売し、オランダに複数の店舗を持っている会社のものです。
この表を見ると、レコード間のデータ重複の複数の例が表示されます。 ブランドフィールドは、別のテーブルで強調表示できます。 タイプフィールド（モデル）だけでなく、別のテーブルに分離することもできます。ブランドは異なるモデルを持つことができるため、ブランドテーブルと多対 1の関係になります。
ストア列には、マシンが現在置かれているストアの名前が含まれています。 Storeは、データの冗長性の明らかな例であり、 外部キー通信によって車のテーブルに接続する必要がある別のエンティティの適切な候補です。
以下は、データの冗長性を回避して、自動車用のデータベースをモデル化する方法の例です。
上記の例では、 carテーブルには外部キーがあります-typeおよびstoreテーブルへのリンク。 タイプ表を介したブランドへの暗黙的なリンクがあるため、ブランド列は表示されなくなりました。 タイプへのリンクがある場合、ブランドへのリンクがあります。 タイプはブランドに属します。
データベースモデルからデータの冗長性が実質的に排除されました。 あなたがうるさいなら、この決定に満足できないかもしれません。 ブランドテーブルのcountry_of_originフィールドはどうですか？ 異なる国のブランドは4つしかないため、重複はありません。 注意深いデータベース設計者は、別の国テーブルで国名を強調する必要があります。
また、別のテーブルで色フィールドを選択することもできるため、結果に満足できないはずです。
テーブルの作成にどの程度厳密に取り組むかはユーザー次第であり、特定の状況によって異なります。 膨大な数の自動車ユニットをシステムに保存する予定があり、色で検索できるようにする場合は、色が重複しないように別のテーブルで色を選択するのが賢明です。
別のテーブルで色を強調したい場合もあります。 会社の従業員が新しい車のデータを入力できるようにする場合は 、定義済みのリストから車の色を選択できるようにします 。 この場合、すべての可能な色をデータベースに保存する必要があります。 この色の車がまだない場合でも、従業員が選択できるようにこれらの色をデータベースに表示する必要があります。 これは、別のテーブルで色を強調表示する必要がある場合は間違いありません。
13. 3番目の標準形。
3番目の標準形式は、 推移的な依存関係に関連付けられています。 非キーフィールドの値が他の非キーフィールドの値に依存する場合、データベースフィールド間の推移的な依存関係が存在します。 データベースを3番目の標準形式にするためには、2番目の標準形式にする必要があります。
推移的な依存関係。
ルール：テーブル内のフィールド間に推移的な依存関係はありません。
以下の顧客テーブル（私の顧客はドイツとフランスのサッカーチームの選手です）には推移的な依存関係が含まれています。
この表では、すべてのフィールドが主キーのみに依存するわけではありません。 postal_codeフィールドと市および県のフィールドとの間には個別の関係があります。 オランダでは、両方の意味：市と県-郵便番号、郵便番号によって決定されます。 したがって、市区町村をクライアントテーブルに保存する必要はありません。 郵便番号を知っていれば、すでに市と州を知っています。
データベースモデルを3番目の標準形式にする場合は、このような推移的な依存関係を避ける必要があります。
この場合、テーブルから都市と州のフィールドを削除し、郵便番号（主キー）、州名、都市名を含む別のテーブルに格納することで、テーブルから推移的な依存関係を削除できます。 全国の郵便番号と都市と都道府県の組み合わせを取得することは、非常に重要な作業です。 そのため、このようなテーブルが頻繁に販売されています。
3番目の標準形式を適用する別の例は、以下の（あまりにも）オンラインストア注文表の簡単な例です。
VAT（付加価値税）は、製品の価格に追加される割合です（この表では19％）。 つまり、total_ex_vatの値はtotal_inc_vatの値から計算でき、その逆も同様です。 これらの値のいずれかをテーブルに保存する必要がありますが、一度に両方を保存することはできません。 total_ex_vatからtotal_inc_vatを計算するタスク、またはその逆をデータベースを使用するプログラムに割り当てる必要があります。
3番目の標準形式では、テーブル内の他の（キーではない）フィールドから取得できるデータをテーブルに保存しないでください。 特に、顧客テーブルを使用した例では、3番目の標準形式を使用するには、大量の作業が必要になるか、そのようなテーブルの商用バージョンのデータを取得する必要があります。
3番目の標準形式は、データベース設計で常に使用されるとは限りません。 データベースを設計するときは、3番目の標準形式を適用してデータをその状態に保つために必要な作業量と比較して、より高い標準形式の利点を常に比較する必要があります。 クライアントテーブルの場合、個人的には、テーブルを3番目の標準形式に正規化しない方がよいでしょう。 VATの最後の例では、3番目の標準形式を使用します。 通常、 既存のデータからデータを保持することは悪い考えです。