正規化（または正規化）とは何ですか？
回答:
正規化とは、基本的に、重複した冗長なデータが回避されるようにデータベーススキーマを設計することです。データの一部がデータベースの複数の場所で複製されている場合、一方の場所でしか更新されず、もう一方の場所では更新されず、データが破損するリスクがあります。
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つの行でスーの名前を変更し、他の行では変更できないようにすることができます。これはデータの破損です。この問題は、テーブルを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か所で変更するだけで済みます。
適切なデータベース設計にとって非常に重要です。理論的には、データの整合性を維持するために、可能な限りそれを使用する必要があります。ただし、多くのテーブルから情報を取得すると、パフォーマンスが低下するため、パフォーマンスが重要なアプリケーションで非正規化されたデータベーステーブル（フラット化とも呼ばれます）が使用されることがあります。
私の忠告は、ある程度の正規化から始め、本当に必要な場合にのみ非正規化を行うことです。
PSはこの記事もチェックします：http : //en.wikipedia.org/wiki/Database_normalizationこの件に関する詳細と、いわゆる正規形について
データの冗長性を減らすことを目的としています。
より正式な議論については、Wikipedia 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に配置したら、次のステップは通常、論理的な方法でデータベースを非正規化して、クエリを高速化し、特定の一般的な挿入の複雑さを軽減することです。ただし、最初に適切に正規化しないと、これをうまく行うことはできません。
冗長な情報が1つのエントリに削減されるという考えです。これは、住所などのフィールドで特に役立ちます。クリス氏は自分の住所をUnit-7 123 Main St.として送信し、クリス夫人はSuite-7 123 Main Streetをリストします。これは、元のテーブルに2つの異なる住所として表示されます。
通常、使用される手法は、繰り返される要素を見つけ、それらのフィールドを一意のIDを持つ別のテーブルに分離し、繰り返される要素を新しいテーブルを参照する主キーに置き換えることです。
CJ日付の引用：理論は実用的です。
正規化から逸脱すると、データベースに特定の異常が発生します。
第1正規形から逸脱すると、アクセス異常が発生します。つまり、探しているものを見つけるために、個々の値を分解してスキャンする必要があります。たとえば、値の1つが以前の応答で指定された文字列 "Ford、Cadillac"であり、 "Ford"のすべての出現を探している場合、文字列を分割して開き、部分文字列。これは、ある程度、リレーショナルデータベースにデータを格納する目的に反します。
第一正規形の定義は1970年以来変更されていますが、それらの違いは今のところあなたに関係する必要はありません。リレーショナルデータモデルを使用してSQLテーブルを設計する場合、テーブルは自動的に1NFになります。
同じ事実が複数の場所に保存されているため、第2正規形以降から出発すると、更新異常が発生します。これらの問題は、存在しない可能性がある他のファクトを保存せずにいくつかのファクトを保存することを不可能にするため、発明する必要があります。または、ファクトが変更されたときに、ファクトが格納されているすべての場所を特定し、それらすべての場所を更新する必要がある場合があります。また、データベースから行を削除する場合、削除すると、まだ必要なファクトが格納されている唯一の場所が削除されていることに気付く場合があります。
これらは論理的な問題であり、パフォーマンスの問題やスペースの問題ではありません。時々、注意深いプログラミングによってこれらの更新異常を回避することができます。時々（多くの場合）、通常の形式に固執することで、最初から問題を回避する方が良い場合があります。
すでに述べられていることの価値にもかかわらず、正規化はトップダウンアプローチではなく、ボトムアップアプローチであることを言及しておく必要があります。データの分析や初期設計で特定の方法論に従う場合、設計が少なくとも3NFに準拠することが保証されます。多くの場合、設計は完全に正規化されます。
正規化の下で教えられた概念を本当に適用したいのは、レガシーデータが与えられたとき、レガシーデータベースから、またはレコードで構成されたファイルから与えられたときであり、そのデータは、通常の形式と出発の結果を完全に無視して設計されていますそれらから。これらの場合、正規化からの逸脱を発見し、設計を修正する必要があるかもしれません。
警告：正規化は、完全な正規化からのすべての逸脱が罪であり、コッドに対する犯罪であるかのように、しばしば宗教的な含みで教えられます。（そこに少ししゃれ）。それを購入しないでください。データベース設計を本当に学ぶと、ルールに従う方法がわかるだけでなく、ルールを破るのが安全かどうかもわかります。
正規化は基本的な概念の1つです。これは、2つのものが互いに影響を与えないことを意味します。
特にデータベースでは、2つ（またはそれ以上）のテーブルに同じデータが含まれていない、つまり冗長性がないことを意味します。
同期の問題が発生する可能性がゼロに近いため、本当に良い一見では、常にデータの場所などを知っています。しかし、おそらく、テーブルの数が増加し、データをクロスするのに問題が発生します。そして、いくつかの要約結果を取得します。
したがって、最終的には、ある程度正規化された（正規化の可能なレベルの一部になる）純粋な正規化されていないデータベース設計を終了します。
正規化とは何ですか？
正規化は、データの冗長性と更新の異常の両方が最小限に抑えられるようにデータベーステーブルを分解できるようにする段階的な正式なプロセスです。
正規化プロセスの礼儀
各属性のドメインにアトミック値（アトミック値は分割できない値）のみが含まれ、各属性の値にそのドメインからの単一の値のみが含まれる場合に限り、最初の正規形（例：-ドメイン性別の列は「M」、「F」です。）。
最初の正規形では、次の基準が適用されます。
- 個々のテーブルで繰り返しグループを排除します。
- 関連データのセットごとに個別のテーブルを作成します。
- 関連データの各セットを主キーで識別します
第2正規形 = 1NF +部分的な依存関係なし。つまり、すべての非キー属性は主キーに依存して完全に機能します。
第3正規形 = 2NF +推移的な依存関係なし。つまり、すべての非キー属性は、主キーにのみ直接完全に機能依存します。
Boyce–Codd正規形（またはBCNFまたは3.5NF）は、第3正規形（3NF）のわずかに強いバージョンです。
注：-2番目、3番目、およびBoyce–Coddの正規形は、機能の依存関係に関係しています。 例
第4正規形 = 3NF +複数値の依存関係を削除
第5正規形 = 4NF +結合の依存関係を削除
これは、データの重複（さらに悪いことに、競合）を防ぐのに役立ちます。
ただし、パフォーマンスに悪影響を及ぼす可能性があります。