データベース担当者が正規化について話し続けるのはなぜですか?
それは何ですか？それはどのように役立ちますか？
データベース以外にも適用されますか?
65813 次
8 に答える
185
正規化とは、基本的に、重複した冗長なデータを避けるようにデータベース スキーマを設計することです。データベース内の複数の場所で同じ情報が繰り返される場合、ある場所では更新されず、他の場所では更新されず、データが破損する危険性があります。
1. 正規形から 5. 正規形まで、多数の正規化レベルがあります。各正規形は、特定の問題を取り除く方法を説明しています。
第 1 正規形 (1NF) は、冗長性に関するものではないため、特別です。1NF は、ネストされたテーブル、より具体的にはテーブルを値として許可する列を許可しません。入れ子になったテーブルはそもそも SQL でサポートされていないため、通常のリレーショナル データベースのほとんどはデフォルトで 1NF になります。したがって、残りの議論では 1NF を無視できます。
通常の形式 2NF から 5NF はすべて、同じ情報が同じテーブルで複数回表されるシナリオに関係しています。
たとえば、月と惑星のデータベースを考えてみます。
Moon(PK) | Planet | Planet kind
------------------------------
Phobos | Mars | Rock
Daimos | Mars | Rock
Io | Jupiter | Gas
Europa | Jupiter | Gas
Ganymede | Jupiter | Gas
冗長性は明らかです。木星がガス惑星であるという事実は、月ごとに 1 つずつ、3 回繰り返されます。これはスペースの無駄ですが、さらに深刻なことに、このスキーマは一貫性のない情報を可能にします。
Moon(PK) | Planet | Planet kind
------------------------------
Phobos | Mars | Rock
Deimos | Mars | Rock
Io | Jupiter | Gas
Europa | Jupiter | Rock <-- Oh no!
Ganymede | Jupiter | Gas
クエリは、悲惨な結果をもたらす可能性のある一貫性のない結果を与える可能性があります。
(もちろん、データベースは間違った情報が入力されるのを防ぐことはできません。しかし、同じくらい深刻な問題である矛盾した情報を防ぐことはできます。)
正規化された設計では、テーブルが 2 つのテーブルに分割されます。
Moon(PK) | Planet(FK) Planet(PK) | Planet kind
--------------------- ------------------------
Phobos | Mars Mars | Rock
Deimos | Mars Jupiter | Gas
Io | Jupiter
Europa | Jupiter
Ganymede | Jupiter
現在、事実が複数回繰り返されることはないため、データが矛盾する可能性はありません。(惑星名が繰り返されているため、まだ繰り返しがあるように見えるかもしれませんが、主キーの値を外部キーとして繰り返しても、データの一貫性が失われるリスクがないため、正規化に違反しません。)
経験則: 外部キーを数えずに、同じ情報をより少ない個々のセル値で表すことができる場合、テーブルをより多くのテーブルに分割して正規化する必要があります。たとえば、最初のテーブルには 12 個の個別の値がありますが、2 つのテーブルには 9 個の個別の (非 FK) 値しかありません。これは、3 つの冗長な値を削除することを意味します。
join元の正規化されていないテーブルと同じデータを返すクエリを作成できるため、同じ情報がまだそこにあることがわかります。
このような問題を回避するにはどうすればよいですか? 正規化の問題は、エンティティー関係図を描くなど、概念モデルに少し手を加えることで簡単に回避できます。惑星と月は 1 対多の関係にあるため、外部キー関連付けを使用して 2 つの異なるテーブルで表す必要があります。正規化の問題は、1 対多または多対多の関係を持つ複数のエンティティが同じテーブル行に表示される場合に発生します。
正規化は重要ですか？はい、とても重要です。データベースに正規化エラーがあると、無効なデータや破損したデータがデータベースに取り込まれるリスクが生じます。データは「永久に存続する」ため、最初にデータベースに入ったときに破損したデータを取り除くのは非常に困難です。
しかし、2NF から 5NF までの異なる正規形を区別することは重要だとは思いません。通常、スキーマに冗長性が含まれている場合はかなり明白です。問題が修正されている限り、違反が 3NF であるか 5NF であるかはそれほど重要ではありません。
(データ ウェアハウスのような特別な目的のシステムにのみ関連する DKNF や 6NF などの追加の標準形式もいくつかあります。)
正規化を恐れないでください。正規化レベルの公式の技術的定義は非常に曖昧です。正規化は複雑な数学的プロセスのように聞こえます。ただし、正規化は基本的に単なる常識であり、常識に基づいてデータベース スキーマを設計すると、通常は完全に正規化されることがわかります。
正規化に関しては、多くの誤解があります。
正規化されたデータベースは遅く、非正規化によりパフォーマンスが向上すると考える人もいます。ただし、これは非常に特殊な場合にのみ当てはまります。通常、正規化されたデータベースも最速です。
正規化は段階的な設計プロセスとして説明される場合があり、「いつ停止するか」を決定する必要があります。しかし実際には、正規化レベルはさまざまな特定の問題を説明しているだけです。3rd NF を超える通常の形式で解決される問題は、そもそも非常にまれな問題であるため、スキーマが既に 5NF にある可能性があります。
データベース以外にも適用されますか? 直接ではありません。正規化の原則は、リレーショナル データベースに固有のものです。ただし、異なるインスタンスが同期しなくなる可能性がある場合にデータを重複させてはならないという一般的な基本テーマは、広く適用できます。これは基本的にDRY 原則です。
于 2008-10-29T13:14:59.937 に答える
19
最も重要なことは、データベース レコードから重複を削除するのに役立ちます。たとえば、人の名前が表示される可能性のある場所 (テーブル) が複数ある場合は、名前を別のテーブルに移動して、他の場所で参照します。このようにして、後で人の名前を変更する必要がある場合、1 か所で変更するだけで済みます。
これは適切なデータベース設計にとって重要であり、理論的には、データの整合性を維持するために可能な限り使用する必要があります。ただし、多くのテーブルから情報を取得すると、パフォーマンスが低下するため、パフォーマンスが重要なアプリケーションで非正規化されたデータベース テーブル (フラット化とも呼ばれます) が使用されることがあります。
私のアドバイスは、十分な正規化から始めて、本当に必要な場合にのみ非正規化を行うことです
PS もこの記事をチェックしてください: http://en.wikipedia.org/wiki/Database_normalizationこの件名といわゆる正規形についての詳細を読む
于 2008-10-29T13:07:52.777 に答える
7
正規化は、テーブル内の列間の冗長性と機能の依存関係を排除するために使用される手順です。
いくつかの正規形が存在し、通常は数字で示されます。数値が大きいほど、冗長性と依存関係が少なくなります。すべての SQL テーブルは 1NF (最初の正規形、ほぼ定義上) です。正規化とは、スキーマを可逆的に変更すること (多くの場合、テーブルを分割すること) を意味し、冗長性と依存性が少ないことを除けば、機能的に同一のモデルを提供します。
データの冗長性と依存性は望ましくありません。データを変更するときに矛盾が生じる可能性があるからです。
于 2008-10-29T13:13:54.200 に答える
5
データの冗長性を減らすことを目的としています。
より正式な議論については、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.
Near-Complete Normalization (BCNF) は通常、本番環境では使用されませんが、中間ステップです。データベースを BCNF に配置したら、次のステップは通常、論理的な方法でデータベースを非正規化して、クエリを高速化し、特定の一般的な挿入の複雑さを軽減することです。ただし、最初に適切に正規化しないと、これをうまく行うことはできません。
冗長な情報を 1 つのエントリに減らすという考え方です。これは、住所のようなフィールドで特に役立ちます。Chris 氏が自分の住所を Unit-7 123 Main St. として送信し、Mrs. Chris が Suite-7 123 Main Street をリストすると、元のテーブルには 2 つの異なる住所として表示されます。
通常、使用される手法は、繰り返される要素を見つけて、それらのフィールドを一意の ID を持つ別のテーブルに分離し、繰り返される要素を新しいテーブルを参照する主キーに置き換えることです。
于 2008-10-29T13:14:03.700 に答える
4
CJ Date の引用: 理論は実用的です。
正規化から逸脱すると、データベースに特定の異常が発生します。
第 1 正規形からの逸脱は、アクセスの異常を引き起こします。つまり、探しているものを見つけるために、個々の値を分解してスキャンする必要があります。たとえば、値の 1 つが以前の応答で指定された文字列 "Ford, Cadillac" であり、"Ford" のすべての出現を探している場合、文字列を壊して開いて調べる必要があります。部分文字列。これは、リレーショナル データベースにデータを格納するという目的にある程度反します。
第 1 正規形の定義は 1970 年から変更されていますが、今はその違いを気にする必要はありません。リレーショナル データ モデルを使用して SQL テーブルを設計すると、テーブルは自動的に 1NF になります。
同じファクトが複数の場所に格納されているため、第 2 正規形以降からの逸脱は更新の異常を引き起こします。これらの問題により、存在しない可能性のある他の事実を保存せずにいくつかの事実を保存することが不可能になるため、発明する必要があります。または、事実が変化した場合、矛盾するデータベースになってしまわないように、事実が保存されているすべての場所を見つけて、それらすべての場所を更新する必要がある場合があります。また、データベースから行を削除しようとすると、まだ必要なファクトが格納されている唯一の場所を削除していることに気付く場合があります。
これらは論理的な問題であり、パフォーマンスの問題やスペースの問題ではありません。注意深いプログラミングによって、これらの更新の異常を回避できる場合があります。場合によっては (多くの場合)、通常の形式に固執することによって、最初から問題を回避する方がよい場合があります。
すでに述べたことの価値にもかかわらず、正規化はトップダウンのアプローチではなく、ボトムアップのアプローチであることに言及する必要があります。データの分析と初期設計で特定の方法論に従えば、設計が少なくとも 3NF に準拠することが保証されます。多くの場合、設計は完全に正規化されます。
正規化の下で教えられた概念を実際に適用したいのは、レガシー データベースまたはレコードで構成されたファイルからレガシー データが与えられた場合であり、そのデータは通常の形式と離脱の結果を完全に無視して設計されています。それらから。このような場合、正規化からの逸脱を発見し、設計を修正する必要がある場合があります。
警告: 完全な正規化からのすべての逸脱は罪であり、Codd に対する侮辱であるかのように、正規化はしばしば宗教的なニュアンスで教えられます。（少ししゃれがあります）。それを買わないでください。データベースの設計を本当に本当に学べば、ルールに従う方法がわかるだけでなく、ルールを破っても安全な場合もわかります。
于 2008-10-31T13:25:25.747 に答える
3
ノーマライゼーションとは？
正規化は、データの冗長性と更新の異常の両方を最小限に抑える方法でデータベース テーブルを分解できる、段階的な正式なプロセスです。
正規化プロセスの礼儀
第 1 正規形は、各属性のドメインに原子値のみが含まれ (原子値は分割できない値です)、各属性の値にそのドメインからの単一の値のみが含まれる場合に限ります (例:-性別欄は「M」「F」です。）
第 1 正規形では、次の基準が適用されます。
- 個々のテーブルで繰り返しグループを排除します。
- 関連データのセットごとに個別のテーブルを作成します。
- 主キーを使用して、関連するデータの各セットを識別します
第 2 正規形= 1NF + 部分的な依存関係なし、つまり、すべての非キー属性は主キーに完全に依存して機能します。
第 3 正規形= 2NF + 推移的な依存関係なし、つまり、すべての非キー属性は完全に機能し、主キーのみに直接依存します。
ボイス・コッド正規形(または BCNF または 3.5NF) は、第 3 正規形 (3NF) のわずかに強いバージョンです。
注:- Second、Third、および Boyce–Codd の正規形は、関数の依存関係に関係しています。 例
第 4 正規形= 3NF + 多値依存関係の削除
第 5 正規形= 4NF + 結合の依存関係を削除
于 2015-07-27T01:20:22.697 に答える
2
正規化は基本概念の 1 つです。これは、2 つのものが互いに影響を与えないことを意味します。
データベースでは、具体的には、2 つ (またはそれ以上) のテーブルに同じデータが含まれていない、つまり冗長性がないことを意味します。
同期の問題が発生する可能性はゼロに近いため、一見すると、データがどこにあるかなどを常に把握できるため、これは非常に良いことです。いくつかの要約結果を取得します。
したがって、最終的には、純粋に正規化されていない、冗長性を備えたデータベース設計で終了します (正規化の可能なレベルの一部になります)。
于 2008-10-29T13:09:56.827 に答える