ここでは、素人の言葉で正規化を説明しようとします。まず、リレーショナルデータベース（Oracle、Access、MySQL）に適用されるものなので、MySQLだけではありません。
正規化とは、各テーブルに唯一の最小限のフィールドがあることを確認し、依存関係を取り除くことです。従業員レコードがあり、各従業員が部署に属していると想像してください。部門を従業員の他のデータとともにフィールドとして保存すると、問題が発生します。部門が削除されるとどうなりますか？すべての部門フィールドを更新する必要があり、エラーが発生する可能性があります。そして、一部の従業員が部署を持たない場合（おそらく新たに割り当てられますか？）。これでnull値があります。
そのため、簡単に言えば、正規化は、nullになるフィールドを避け、テーブル内のすべてのフィールドが、記述されているデータの1つのドメインにのみ属するようにすることです。たとえば、従業員テーブルでは、フィールドはID、名前、社会保障番号になりますが、これらの3つのフィールドは部門とは関係ありません。従業員が所属する部門を記述するのは従業員IDのみです。したがって、これは、従業員が所属する部署が別のテーブルにあることを意味します。
簡単な正規化プロセスを次に示します。
EMPLOYEE ( < employee_id >, name, social_security, department_name)
説明したように、これは正規化されていません。正規化された形式は次のようになります
EMPLOYEE ( < employee_id >, name, social_security)
ここでは、Employeeテーブルは1つのデータセットのみを担当しています。では、従業員が所属する部門はどこに保存しますか？別のテーブルに
EMPLOYEE_DEPARTMENT ( < employee_id >, department_name )
これは最適ではありません。部門名が変更された場合はどうなりますか？ （それは常に米国政府で起こります）。したがって、これを行うことをお勧めします
EMPLOYEE_DEPARTMENT ( < employee_id >, department_id )
DEPARTMENT ( < department_id >, department_name )
最初の標準形、2番目の標準形、3番目の標準形があります。しかし、DBコースを勉強していない限り、私は通常、理解できる最も正規化された形式を使用します。
お役に立てれば。
正規化はMYSql専用ではありません。その一般的なデータベースの概念。
正規化は、データベース内のデータを効率的に整理するプロセスです。正規化プロセスには2つの目標があります。冗長データを排除する（たとえば、複数のテーブルに同じデータを保存する）と、データの依存関係が理にかなっていることを保証する（テーブルに関連データのみを保存する）。これらはデータベースが消費するスペースを削減し、データが論理的に保存されることを保証するため、価値のある目標です。
SQLの通常の形式を以下に示します。
最初の正規形（1NF）：リレーションは、単一の値属性のみを持ち、繰り返しも配列も許可されていない場合、1NFであると言われます。
2番目の正規形（2NF）：リレーションは、1NFにあり、すべての非キー属性が完全に機能している場合、2NFにあると言われます。
第3正規形（3NF）：2NFにあり、推移的な依存関係がない場合、関係は3NFにあると言います。
Boyce-Codd Normal Form（BCNF）：関係のすべての行列式が候補キーである場合にのみ、関係はBCNFにあると言われます。
第4正規形（4NF）：BCNFにあり、複数値の依存関係が含まれていない場合、関係は4NFにあると言われます。
第5正規形（5NF）：リレーションのすべての結合依存関係がリレーションの候補キーによって暗示される場合にのみ、リレーションは5NFにあると言われます。
ドメインキー標準形式（DKNF）：すべての変更の異常がない場合、関係はDKNFにあると言います。挿入、削除、および更新の異常は、変更の異常になります
また見なさい
これは、重複を排除することにより、データの一貫性を維持するための手法です。したがって、同じ情報が複数のテーブルに格納されているデータベースは、normalizedではありません。
データベースの正規化 に関するWikipediaの記事を参照してください。
（これはリレーショナルデータベースの一般的な手法であり、MySQLに固有のものではありません。）
アプリケーションのデータベーススキーマを作成するとき、異なるテーブルの複数の列に情報が保存されないようにする必要があります。
DBのすべてのテーブルは、アプリケーションの重要なエンティティを識別するため、一意の識別子はそれらの必須の列です。
現在、ストレージスキーマを決定する際に、これらのエンティティ（テーブル）、つまり1対1、1対多、多対多の間でさまざまな種類の関係が識別されています。
- 1対1の関係の場合（たとえば、生徒がクラス内で一意のランクを持っている場合）、同じテーブルを使用して（両方のテーブルから）列を格納できます。
- 1対多のリレーションシップ（たとえば、学期は複数のコースを持つことができます）の場合、親テーブルに外部キーが作成されます。
- 多対多の関係（たとえば、教授が多くの学生に出席する場合、またはその逆）の場合、3番目のテーブルを作成する必要があり（両方のテーブルの主キーを複合キーとして）、両方の関連データテーブルが保存されます。
これらすべてのシナリオに参加すると、db-schemaは4NFに正規化されます。
リレーショナルデータベース設計の分野では、正規化は、データベース構造が汎用クエリに適しており、データの整合性が失われる可能性のある特定の望ましくない特性（挿入、更新、削除の異常）がないことを保証する体系的な方法です。[1]リレーショナルモデルの発明者であるE.F. Coddは、正規化の概念と、1970年に最初の正規形として知られるものを導入しました。[2] Coddは1971年に2番目と3番目の正規形を定義し[3]、CoddとRaymond F. Boyceは1974年にBoyce-Codd正規形を定義しました。[4]より高い標準形はその後の年に他の理論家によって定義され、最新のものは2002年にクリス・デイト、ヒュー・ダーウェン、ニコス・ロレンツォスによって紹介された6番目の標準形です。
非公式には、リレーショナルデータベーステーブル（リレーションのコンピューター化された表現）は、3番目の標準形式（3NF）である場合、「正規化」と呼ばれることがよくあります。[6]ほとんどの3NFテーブルには挿入、更新、および削除の異常がありません。つまり、ほとんどの場合、3NFテーブルはBCNF、4NF、および5NFに準拠しています（ただし、通常6NFには準拠していません）。
データベース設計ガイダンスの標準的な部分は、設計者が完全に正規化された設計を作成することです。その後、パフォーマンス上の理由から選択的な非正規化を実行できます。[7]ただし、データウェアハウス設計への次元モデリングアプローチなど、一部のモデリング分野では、非正規化設計、つまり大部分が3NFに準拠していない設計を明示的に推奨しています。[8]