第3正規形（データベース）はリレーショナルデータベースの設計手法であり、これを構成するさまざまなテーブルは、第2正規形に準拠するだけでなく、そのすべての属性またはフィールドが主キーに直接依存します。
データベースを設計するときの主な目標は、データの正確な表現、それらの間の関係、および関連するデータの制限を作成することです。
出典：pixabay.com
この目標を達成するために、いくつかのデータベース設計手法を使用できます。
これは、データベース内のデータを整理して、データの挿入、更新、または削除における冗長性や起こり得る異常を回避し、概念モデルのシンプルで安定した設計を生成するプロセスです。
まず、属性間の機能的な関係または依存関係を調べます。これらは、データのいくつかのプロパティまたはそれらの間の関係を記述します。
通常の形状
正規化は、正規フォームと呼ばれる一連のテストを使用して、これらの属性の最適なグループを特定し、最終的に企業のデータ要件をサポートする適切な関係のセットを確立します。
つまり、正規化手法は、制約のシステムを定義する正規形の概念を中心に構築されています。関係が特定の正規形の制約を満たす場合、その関係はその正規形であるといいます。
第1正規形（1FN）
テーブル内のすべての属性またはフィールドに一意の値のみが含まれている場合、そのテーブルは1FNにあるといいます。つまり、各属性のすべての値は分割できない必要があります。
定義により、属性値は常にアトミックであるため、リレーショナルデータベースは常に最初の正規形に正規化されます。データベース内のすべての関係は1FNにあります。
ただし、このようにデータベースをそのままにしておくと、冗長性やアップグレードの失敗など、多くの問題が発生します。これらの問題を修正するために、より高い正規形が開発されました。
第2正規形（2FN）
テーブルから循環依存関係を削除することを扱います。リレーションが1FNにあり、さらに各非キーフィールドまたは属性が主キーに完全に依存している場合、リレーションは2FNにあるといいます。より具体的には、テーブルが単一の目的を持つことを保証します。
非キー属性は、関係の主キーの一部ではない属性です。
第3正規形（3FN）
テーブルから推移的な依存関係を排除することを扱います。つまり、主キーではなく別の属性に依存する非キー属性を削除します。
推移的依存関係は、機能的な依存関係の一種であり、非キーフィールドまたは属性の値が、キーではない別のフィールドの値によって決定されます。
非キー属性で繰り返し値を探し、これらの非キー属性が主キー以外のものに依存しないことを確認します。
属性のどれもが他の組み合わせに機能的に依存していない場合、属性は相互に独立していると言われます。この相互独立性により、別の属性に影響を与えることなく、属性を個別に更新できます。
したがって、データベース内の関係が第3正規形であるためには、以下に準拠する必要があります。
-2FNのすべての要件。
-主キーに関連しない属性がある場合は、それらを削除して別のテーブルに配置し、両方のテーブルを外部キーによって関連付けます。つまり、推移的な依存関係があってはなりません。
第3正規形の例
例1
テーブルをSTUDENTとし、その主キーは学生のID（STUDENT_ID）で、STUDENT_NAME、STREET、CITY、およびPOST_CODEの属性で構成され、2FNの条件を満たすものとします。
この場合、STREETとCITYは主キーSTUDENT_IDと直接の関係はありません。これらは学生に直接関連しているわけではなく、郵便番号に完全に依存しているためです。
学生はCODE_POSTALによって決定されたサイトに位置しているため、STREETとCITYはこの属性に関連しています。この2番目の依存関係により、これらの属性をSTUDENTテーブルに格納する必要はありません。
新しいテーブルを作成
同じ郵便番号に複数の学生がいて、STUDENTテーブルに膨大な量のレコードがあり、通りまたは都市の名前を変更する必要がある場合、この通りまたは都市を検索してテーブル全体で更新する必要があるとします。学生。
たとえば、ストリート「ElLimón」を「ElLimónII」に変更する必要がある場合、STUDENTテーブル全体で「ElLimón」を検索してから、「ElLimónII」に更新する必要があります。
巨大なテーブルを検索して1つまたは複数のレコードを更新すると、時間がかかるため、データベースのパフォーマンスに影響します。
代わりに、これらの詳細は、POST_CODE属性を使用してSTUDENTテーブルに関連する別のテーブル（POSTCARD）に保持できます。
POSTテーブルのレコードは比較的少なく、このPOSTテーブルは一度だけ更新する必要があります。これは自動的にSTUDENTテーブルに反映され、データベースとクエリが簡素化されます。したがって、テーブルは3FNになります。
例2
次の表を、Project_Numフィールドを主キーとして使用し、キーではない属性の値を繰り返して使用します。
電話の値は、マネージャーの名前が繰り返されるたびに繰り返されます。これは、電話番号がプロジェクト番号に2度だけ依存しているためです。それは本当に最初にマネージャに依存し、これは今度はプロジェクト番号に依存し、推移的な依存関係を作ります。
同じマネージャーが複数のプロジェクトを管理しているため、Project_Manager属性をProjectsテーブルのキーとして使用することはできません。これに対する解決策は、繰り返されるデータ（電話）を持つ属性を削除し、別のテーブルを作成することです。
対応する属性をグループ化して、それらを保存する新しいテーブルを作成する必要があります。データが入力され、繰り返される値が主キーの一部ではないことが確認されます。主キーはテーブルごとに設定され、必要に応じて外部キーが追加されます。
第3正規形に準拠するために、問題を解決するための新しいテーブル（マネージャー）が作成されます。両方のテーブルは、Project_Managerフィールドを介して関連付けられています。
参考文献
- Teradata（2019）。1番目、2番目、3番目の正規形。docs.teradata.comから取得。
- チュートリアルカップ（2019）。第3正規形（3NF）。取得元：tutorialcup.com。
- データベース開発（2015）。第3正規形（3NF）-データベースの正規化。取得元：databasedev.co.uk。
- リレーショナルDB設計（2019）。第3正規形の紹介。Relationaldbdesign.comから取得。
- ダミー（2019）。SQLの第1、第2および第3正規形。取得元：dummies.com。