正規化とは、基本的に、重複するデータや冗長なデータが回避されるようにデータベーススキーマを設計することです。データの一部がデータベース内の複数の場所で複製された場合、ある場所では更新されても別の場所では更新されず、データが破損するリスクがあります。
1.正規形から5.正規形まで、多数の正規化レベルがあります。各標準形式は、通常冗長性に関連する特定の問題を取り除く方法を説明しています。
いくつかの典型的な正規化エラー：
（1）セルに複数の値がある。例：
UserId | Car
---------------------
1 | Toyota
2 | Ford,Cadillac
ここで、「Car」列（文字列）にはいくつかの値があります。これは、各セルに1つの値のみを含める必要があることを示す最初の正規形を怒らせます。車ごとに個別の行を作成することで、この問題を標準化できます。
UserId | Car
---------------------
1 | Toyota
2 | Ford
2 | Cadillac
1つのセルに複数の値があることの問題は、更新が難しく、クエリを行うのが難しく、インデックスや制約などを適用できないことです。
（2）冗長な非キーデータ（つまり、複数の行で不必要に繰り返されるデータ）がある。例：
UserId | UserName | Car
-----------------------
1 | John | Toyota
2 | Sue | Ford
2 | Sue | Cadillac
名前は常にUserIdによって決定されますが、名前は各列ごとに繰り返されるため、この設計は問題です。これにより、理論的には1つの行でSueの名前を変更し、他の行では変更できなくなります。これはデータ破損です。この問題は、テーブルを2つに分割し、主キー/外部キーの関係を作成することで解決されます。
UserId(FK) | Car UserId(PK) | UserName
--------------------- -----------------
1 | Toyota 1 | John
2 | Ford 2 | Sue
2 | Cadillac
UserIdが繰り返されているため、冗長なデータがあるように見えるかもしれません。ただし、PK/FK制約により、値を個別に更新できないことが保証されるため、整合性は安全です。
それは重要ですか？はい、それは非常に重要です。正規化エラーのあるデータベースを使用すると、無効または破損したデータをデータベースに取り込むリスクが生じます。データは「永久に」存続するため、最初にデータベースに入ったときに破損したデータを取り除くことは非常に困難です。
正規化を恐れないでください。正規化レベルの公式の技術的定義は非常に鈍いです。正規化は複雑な数学的プロセスのように聞こえます。ただし、正規化は基本的には常識であり、常識を使用してデータベーススキーマを設計すると、通常は完全に正規化されます。
正規化に関する誤解がいくつかあります。
正規化されたデータベースの方が遅く、非正規化によりパフォーマンスが向上すると考える人もいます。ただし、これは非常に特殊な場合にのみ当てはまります。通常、正規化されたデータベースも最速です。
正規化は段階的な設計プロセスとして説明されることがあり、「いつ停止するか」を決定する必要があります。しかし実際には、正規化レベルは異なる特定の問題を説明するだけです。 3番目のNFを超える通常の形式で解決される問題は、そもそも非常にまれな問題であるため、スキーマがすでに5NFになっている可能性があります。
データベース外の何かに適用されますか？直接ではなく、いいえ。正規化の原則は、リレーショナルデータベースに非常に固有です。ただし、一般的な基本テーマ-異なるインスタンスが同期できなくなった場合に重複データを使用しないようにする-は、広く適用できます。これは基本的に DRY原則 です。
最も重要なことは、データベースレコードから重複を削除することです。たとえば、人の名前が出てくる可能性のある場所（テーブル）が複数ある場合、名前を別のテーブルに移動し、他の場所で参照します。この方法で、後で人名を変更する必要がある場合は、1か所で変更するだけで済みます。
適切なデータベース設計には不可欠であり、理論的には可能な限りそれを使用してデータの整合性を維持する必要があります。ただし、多くのテーブルから情報を取得するとパフォーマンスが低下するため、パフォーマンスが重要なアプリケーションで非正規化されたデータベーステーブル（フラット化とも呼ばれる）が使用されることがあります。
私のアドバイスは、かなりの程度の正規化から始めて、本当に必要なときだけ非正規化を行うことです。
追伸また、この記事を確認してください： http://en.wikipedia.org/wiki/Database_normalization でこのテーマといわゆるnormalフォームについて詳しく読む
正規化テーブルの列間の冗長性と機能的な依存関係を排除するために使用される手順。
一般に番号で示されるいくつかの標準形式があります。数値が大きいほど、冗長性と依存関係が少なくなります。 SQLテーブルはすべて1NF（最初の標準形式、定義上ほぼ）にあります。正規化とは、スキーマを可逆的に変更し（多くの場合、テーブルをパーティション分割する）、冗長性と依存性が少ないことを除いて機能的に同一のモデルを提供することです。
データの冗長性と依存性は、データを変更するときに矛盾を引き起こす可能性があるため、望ましくありません。
データの冗長性を減らすことを目的としています。
より正式な議論については、ウィキペディアを参照してください http://en.wikipedia.org/wiki/Database_normalization
少し単純化した例を挙げます。
通常家族を含む組織のデータベースを想定
id, name, address
214 Mr. Chris 123 Main St.
317 Mrs. Chris 123 Main St.
として正規化できます
id name familyID
214 Mr. Chris 27
317 Mrs. Chris 27
ファミリーテーブル
ID, address
27 123 Main St.
準完全正規化（BCNF）は通常、実稼働では使用されませんが、中間ステップです。データベースをBCNFに配置したら、次のステップは通常De-normalizeで、論理的な方法でクエリを高速化し、複雑さを軽減します特定の一般的な挿入の。ただし、最初に適切に正規化しない限り、これをうまく行うことはできません。
冗長な情報が単一のエントリに削減されるという考え方です。これは、住所などのフィールドで特に役立ちます。Chris氏はUnit-7 123 Main St.として住所を送信し、Mrs。ChrisはSuite-7 123 Main Streetをリストします。
通常、使用される手法は、繰り返される要素を見つけ、それらのフィールドを一意のIDを持つ別のテーブルに分離し、繰り返される要素を新しいテーブルを参照する主キーに置き換えることです。
CJ日付の引用：理論IS実用的。
正規化から逸脱すると、データベースに特定の異常が発生します。
First Normal Formからの出発は、アクセス異常を引き起こします。つまり、探しているものを見つけるために、個々の値を分解およびスキャンする必要があります。たとえば、値の1つが以前の応答で指定された文字列「Ford、Cadillac」であり、「Ford」のすべての出現を探している場合は、文字列を分割して開き、部分文字列。これは、ある程度、リレーショナルデータベースにデータを格納する目的を無効にします。
First Normal Formの定義は1970年以降変更されていますが、これらの違いは今のところ気にする必要はありません。リレーショナルデータモデルを使用してSQLテーブルを設計する場合、テーブルは自動的に1NFになります。
同じ事実が複数の場所に保存されているため、第2正規形以降の出発は更新の異常を引き起こします。これらの問題により、存在しない可能性のある他のファクトを保存せずに、いくつかのファクトを保存することが不可能になるため、発明する必要があります。または、ファクトが変更されたときに、ファクトが格納されているすべての場所を見つけて、それらすべての場所を更新する必要がある場合があります。また、データベースから行を削除しようとすると、必要なファクトが保存されている唯一の場所を削除していることに気付くかもしれません。
これらは論理的な問題であり、パフォーマンスの問題やスペースの問題ではありません。注意深いプログラミングによって、これらの更新の異常を回避できる場合があります。時には（多くの場合）通常の形式に固執することで、そもそも問題を防ぐほうが良い場合があります。
すでに述べたことの価値にもかかわらず、正規化はトップダウンのアプローチではなく、ボトムアップのアプローチであることに言及する必要があります。データの分析および初期設計で特定の方法論に従うと、設計が少なくとも3NFに準拠することを保証できます。多くの場合、設計は完全に正規化されます。
正規化で教えられた概念を本当に適用したいのは、レガシーデータ、レガシーデータベース、またはレコードで構成されたファイルが与えられ、データが通常の形式と出発の結果を完全に無視して設計された場合です。それらから。これらの場合、正規化からの逸脱を発見し、設計を修正する必要があります。
警告：正規化は宗教的な倍音で教えられることがよくあります。まるで完全な正規化からのすべての逸脱は罪であり、コッドに対する犯罪です。 （少ししゃれ）。それを買わないでください。データベース設計を実際に実際に学ぶと、ルールに従う方法を知るだけでなく、ルールを破るのが安全である時期を知ることができます。
正規化は、基本的な概念の1つです。これは、2つのことが互いに影響を与えないことを意味します。
データベースでは、特に2つ（またはそれ以上）のテーブルに同じデータが含まれていない、つまり冗長性がないことを意味します。
いくつかの同期の問題を起こす可能性がゼロに近いため、本当に良い一見では、データがどこにあるかなどを常に知っています。いくつかの要約結果を取得します。
そのため、最後に、純粋な正規化ではなく、ある程度の冗長性を持つデータベース設計を完了します（正規化の可能なレベルの一部になります）。
正規化とは何ですか？
正規化は、data redundancyと 更新の異常 は最小化されます。
正規化プロセス
礼儀
最初の正規形各属性のドメインにアトミック値のみが含まれる場合のみ（アトミック値は分割できない値）、および値各属性のには、そのドメインからの単一の値のみが含まれます（例：-性別列のドメインは、「M」、「F」です）。
最初の正規形はこれらの基準を実施します：
- 個々のテーブルの繰り返しグループを削除します。
- 関連データのセットごとに個別のテーブルを作成します。
- 主キーで関連データの各セットを識別します
2番目の標準形式= 1NF +部分的な依存関係なし、つまり、すべての非キー属性は、主キーに完全に機能的に依存しています。
第3正規形= 2NF +推移的な依存関係なし、つまり、すべての非キー属性は、主キーにのみ完全に機能的に依存しています。
Boyce–Codd正規形（またはBCNFまたは3.5NF）は、3番目の正規形（3NF）のわずかに強力なバージョンです。
注：-Second、Third、およびBoyce–Coddの標準形式は、機能的な依存関係に関係しています。 例
第4正規形= 3NF +多値依存関係を削除
第5正規形= 4NF +結合依存関係の削除