データベースを第3正規形（3NF）にする

第3正規形（3NF）は、データベースの原則に基づいて構築することにより、データの整合性をサポートします。 データベースの正規化の原則 によって提供された 第一正規形（1NF） と 2番目の正規形（2NF）. 3NFの目的は、ストレージコストを最小限に抑えながら、データベース処理を改善することです。

3番目の正規形の要件

データベースを3NFにするための2つの基本的な要件があります。

• データベースは、1NFと2NFの両方の要件を満たしている必要があります。
• すべてのデータベース列は、に依存する必要があります 主キー、つまり、任意の列の値は主キーからのみ取得できます。

主キーの依存関係

すべての列が主キーに依存する必要があるという事実の意味をさらに詳しく見ていきましょう。 列の値が主キーとテーブル内の別の列の両方から取得できる場合、3NFに違反します。 次の列を持つ従業員のテーブルについて考えてみます。

• 従業員ID
• ファーストネーム
• 苗字

LastNameとFirstNameはどちらもEmployeeIDの値のみに依存しますか？ さて、LastNameはFirstNameに依存できますか？ いいえ、LastNameに固有のものはFirstNameの値を示唆しないためです。

FirstNameはLastNameに依存できますか？ 繰り返しになりませんが、同じことが当てはまります。LastNameが何であれ、FirstNameの値に関するヒントを提供できませんでした。 したがって、このテーブルは3NFに準拠しています。

次に、この車両の表を検討してください。

• VehicleID
• メーカー
• モデル

メーカーとモデルはVehicleIDから派生できますが、特定のメーカーが1つだけ車両モデルを作成するため、モデルはメーカーから派生することもできます。 このテーブルデザインは3NFに準拠していないため、データの異常が発生する可能性があります。 たとえば、モデルを更新せずにメーカーを更新して、不正確さを導入する場合があります。

データベースを第3正規形（3NF）にする

追加の従属列を別のテーブルに移動し、 外部キー 準拠します。 これにより、「車両」と「モデル」という2つのテーブルが作成されます。

「Vehicles」テーブルでは、ModelIDは「Models」テーブルへの外部キーです。

• VehicleID
• メーカー
• ModelID

新しい「モデル」テーブルは、モデルをメーカーにマップします。 モデルに固有の車両情報を更新する場合は、「Vehicles」テーブルではなく、このテーブルで更新します。

• ModelID
• メーカー
• モデル

3NFモデルの派生フィールド

テーブルには、テーブル内の他の列に基づいて計算される派生フィールドが含まれる場合があります。 たとえば、次のウィジェット順序の表について考えてみます。

• 注文番号
• 顧客番号
• 単価
• 量
• 合計

Totalは、主キーに完全に依存するのではなく、単価に数量を掛けることで導出できるため、3NFコンプライアンスを破ります。 3番目の正規形に準拠するには、テーブルから合計を削除する必要があります。

派生しているため、データベースにまったく保存せず、代わりにデータベースクエリを実行するときにオンザフライで計算することをお勧めします。 たとえば、以前にこのクエリを使用して注文番号と合計を取得したことがあるかもしれません。

SELECT OrderNumber、Total
FROMWidgetOrders

次に、次のクエリを使用して、正規化ルールに違反せずに同じ結果を達成します。

SELECT OrderNumber、UnitPrice *数量AS合計
FROMWidgetOrders