データベース設計が過度に正規化されていると説明されるのはいつですか? この特徴付けは絶対的なものですか？それとも、アプリケーションでの使用方法に依存していますか? ありがとう。
emkay
質問する
12601 次
11 に答える
32
一般的な意味では、過度に正規化されているとは、データを取得するために非常に多くの JOIN を実行しているため、インデックスを完全に調整した後でも、データベースに顕著なパフォーマンスの低下とデッドロックを引き起こしている場合だと思います。明らかに、MySpace や eBay のような巨大なアプリケーションやサイトの場合、非正規化はスケーリングの要件です。
いくつかの中小企業の開発者として、私の経験では、正規化から非正規化に移行する方が、その逆よりも常に簡単であり、実際にはその逆に移行する方が簡単であると言っています要件が 1 年ほど後に変更された場合) は、はるかに困難です。
「結合を避けるために、別のアドレス テーブルではなく、顧客テーブルにアドレスを配置する必要があります」などの一般的なステートメントを読むと、身震いします。監査証跡を維持したり、顧客ごとに複数のアドレスを保存したりするなど、まったく予測していなかったアドレスを持つもの。データベースでインデックス付きビューの作成が許可されている場合は、データセットが非常に大きくなり、単一のサーバーまたは一連のサーバーで 1-書き込み、多読み取り環境。私たちのほとんどにとって、そのシナリオが頻繁に起こるとは思いません。
疑わしい場合は、いくつかの例外を除いて、第 3 正規形を目指します (たとえば、別の角度からデータを見ることは決してないとわかっているため、フィールドに区切られた文字列の CSV リストを含めるなど)。統合する必要があるときは、まず自分のビューまたはインデックスを調べます。お役に立てれば。
于 2008-11-15T17:44:13.187 に答える
15
それは常にアプリケーション ドメインの問題です。通常は正確性の問題ですが、パフォーマンスの問題になることもあります。
一応、過剰正規化のケースを考えることができるケースが 1 つあります。たとえば、注文と注文アイテムがあり、注文アイテムが productID を参照し、価格設定を product.price に任せているとします。それは一時的なカップリングを導入するため、価格がまったく変わらない限り、過剰な正規化がすでに出荷された注文に影響するため、誤って正規化しました。これは単なるモデリング エラー (コメントのように) であると確かに主張できますが、ほとんどの場合、不十分な正規化もモデリング エラーと見なされます。
もう 1 つのカテゴリはパフォーマンス関連です。原則として、マテリアライズド ビューなどのデータを非正規化するよりもパフォーマンスに優れたソリューションが一般的にあると思いますが、多くの結合によってアプリケーションのパフォーマンスが低下する場合は、非正規化が役立つかどうかを評価する価値があるかもしれません。アプリケーションを適切にプロファイリングする前に、非正規化に手を伸ばすことがあるからです。
人々はまた、データベースの標準的な形式を維持したり、頻繁に読み取られるが頻繁に変更されないデータに対してウェアハウジングやその他の戦略を使用したりするなど、代替手段を忘れがちです。
于 2008-11-15T17:47:04.537 に答える
11
正規化は絶対です。データベースが正規形に従うか、従わないか。半ダースの正規形があります。ほとんどの場合、First から Fifth のような名前が付いています。さらに、ボイス・コッドの通常形もあります。
正規化は、「更新の異常」を防ぐという 1 つの目的のために存在します。
正規化は主観的ではありません。判断ではありません。各テーブルおよびテーブル間の関係は、通常の形式に従うか、または従わないかのいずれかです。
したがって、「過剰正規化」または「正規化不足」になることはありません。
そうは言っても、正規化にはパフォーマンス コストがかかります。パフォーマンスを向上させるために、さまざまな方法で非正規化を選択する人もいます。最も一般的な賢明な非正規化は、3NF を破って派生データを含めることです。
よくある間違いは、2NF を壊して、キーと非キー値の間の関数依存関係のコピーを複製することです。これには、追加の更新が必要になるか、さらに悪いことに、コピーを並行して維持するためのトリガーが必要になります。
トランザクション データベースの非正規化は、ケースバイケースである必要があります。
また、データ ウェアハウスは (本質的に) 決して更新されないため、トランザクションの正規化ルールに従うことはめったにありません。
「過度の正規化」は、多数の結合が原因でデータベースが遅すぎることを意味する場合があります。これは、データベースがハードウェアを超えていることを意味する場合もあります。または、アプリケーションがスケーリングするように設計されていないこと。
ここでの最も一般的な問題は、人々がトランザクションの進行中にレポート用にトランザクション データベースを使用しようとすることです。トランザクションのロックはレポートに干渉します。
ただし、「正規化不足」とは、NF 違反があり、レプリケートされたデータを処理して更新の異常を修正するために不必要な処理が行われていることを意味します。
于 2008-11-15T18:05:31.100 に答える
5
パフォーマンス コストが、アプリケーションの意図された目的に対する利点を超える場合。
于 2008-11-15T17:41:51.677 に答える
4
OLTP データベースを正規化し、OLAP データベースを非正規化します。それぞれに、そのスキーマを指示する使命があります。正規化されたトランザクション データベースと同様に、データ ウェアハウスが存在するのには理由があります。完全なシステムには両方が必要です。
于 2011-08-25T02:33:31.433 に答える
3
多くの人がパフォーマンスについて話している。重要な問題は柔軟性だと思います。一般に、データベースは正規化されているほど柔軟性が高くなります。
現在、「過度に正規化された」データベースを使用しています。これは、当社の運用環境ではクライアントの要件が毎月変化するためです。「過度に正規化」することで、データベース構造を変更することなく、それに応じてソフトウェアを採用できます。
于 2008-11-17T16:17:52.640 に答える
2
これに対する私の見解：
できる限り常に正規化してください。私は通常、正規化に夢中になり、考えられるすべての将来の拡張を処理できるものを設計しようとします。私が最終的にたどり着いたのは、非常に柔軟なデータベース設計です...そして実装することは不可能です.
それから本当の仕事が始まります: 非正規化。ここでは、結合が多すぎるために実装に問題がある、および/またはクエリが遅くなることがわかっていることを解決します。
このようにして、デザインを使いやすくするために何をスカリファイするかがわかります。
編集：ドキュメント！非正規化を文書化することが非常に重要であることを忘れていました。選択の背後にある理由を知ることは、プロジェクトを引き継ぐときに非常に役立ちます。
于 2008-11-15T18:06:44.233 に答える
1
結合が多すぎるとパフォーマンスが影響を受ける場合は、レポート用に非正規化テーブルを作成すると、速度が向上する可能性があります。データを新しいテーブルにコピーすることで、結合なしでレポートを実行できる場合があります。
于 2008-11-17T16:03:11.720 に答える
1
于 2008-11-15T17:51:38.663 に答える
0
私の経験では、住所を文字列として保存することは通常許容できるため、住所を含む正規化されたデータベースを見たことがありません。理想的には、国、郡/州、都市、地区、および通りのテーブルがあります。通りのレベルで報告する必要がある人に出会ったことがないので、それは必要ではありませんでした。住所は郵便での連絡にのみ使用されているため、単一のエンティティとして扱われます。
于 2008-11-17T16:07:56.420 に答える