正規化しない方がよい状況についてご意見をお聞かせください。私はちょうど、データベースがあまりにも正規化されていると主張しているアーキテックとDBAの間のいくつかの白熱した議論を目撃しました。
4876 次
10 に答える
12
ルールは、痛くなるまで正規化し、うまくいくまで非正規化することです。（誰が言った？）
一般に、多くの親子関係がある場合は非正規化することが多く、1 つのデータ (たとえばクライアント ID など) を取得するために 5 つまたは 6 つの大きなテーブルに参加する必要があることがよくありますが、それらのいずれも必要ありません。多くの場合、中間テーブルからの情報。可能であれば、頻繁に変更されないもの (id フィールドなど) を非正規化するようにしています。ただし、非正規化するときはいつでも、トリガーまたはその他のプロセスを作成する必要があります (ただし、PK/FK 関係およびカスケード更新によって処理できるものでない場合は通常トリガーします)、データの同期が維持されるようにします。データベース レベルでこれを行わないと、データの整合性の問題が発生し、データが役に立たなくなります。アプリケーション コードで非正規化を維持できるとは思わないでください。これは災害のレシピです。
正しく非正規化すると、特に大量のデータのバッチを実行する必要がある場合に、挿入、更新、および削除が遅くなる可能性があります。データのクエリ方法によっては、選択クエリの速度が向上する場合と向上しない場合があります。データを取得するために多くの自己結合を行う必要がある場合は、非正規化しないほうがよかった可能性があります。パフォーマンスが向上したかどうかをテストせずに非正規化しないでください。多くのユーザーがシステムを使用している場合、挿入/更新/削除の速度が低下すると、システム全体に影響を与えることに注意してください。1 つの問題を修正するために非正規化を行うと、システム全体にさらに悪い問題が発生する可能性があります。高速化しようとしている 1 つのクエリだけをテストするのではなく、システム全体のパフォーマンスをテストしてください。1 か月に 1 回実行されるクエリを高速化し、1 日に何千回も実行される他のクエリを低速化する場合があります。
非正規化は、通常、ユーザーが一度に 1 つのレコードではなく、スケジュールに従って自動的に更新される特殊なケースであるデータ ウェアハウスに対して行われます。データ ウェアハウスを専門とする DBA も構築する傾向があり、データの整合性の問題を回避する方法を知っています。
もう 1 つの一般的な非正規化手法は、リアルタイム データで実行する必要のない複雑なレポートに関連するデータ用のステージング テーブルを作成することです。これは貧乏人のデータ ウェアハウスのようなものであり、スケジュールに従ってステージング テーブルを更新する方法なしでは絶対に実行しないでください (できるだけ頻繁に行う必要はありませんが、ほとんどの場合、別の場所で使用したほうがよいサーバー リソースを使用します。 ) 多くの場合、これらのタイプのテーブルは、システムに少数のユーザーがいて、リアルタイム データから 1 日遅れているときに更新されます。データをステージングしているクエリが本当に遅く、他の方法で最適化できない場合を除き、これを行うことを検討しないでください。多くの遅いクエリは、非正規化なしで最適化できます。開発者は、最もパフォーマンスの高い方法でデータを選択するのではなく、最も理解しやすい方法を使用することが多いためです。
于 2010-01-14T16:20:26.927 に答える
11
クエリの可能性のパフォーマンス：DBが正規化されすぎると、クエリで多くの結合が発生し、特定の属性を検索する可能性が制限される可能性があります。DB設計を行うときは、アクセスパス分析を行って、DBの使用方法を検討する必要があります。
詳述すると、頻繁に更新されるデータを正規化し、ほとんどが読み取られるデータを非正規化するのが経験則です。
于 2010-01-14T15:43:59.977 に答える
6
時期尚早に最適化する場合
将来の成長を可能にするためにいくつかの正規化があり、それは必要ないかもしれません。
たとえば、personテーブルがあるとします。birthday各人の誕生日は1回だけなので、列として持つことができます。
厳密に正規化する場合は、とを列として持つことはありませんがphone_number、cell_number代わりfax_numberにperson、phonenumber各行に数値、タイプ、およびperson_idの関係があるテーブルがある可能性があります。personこれは、テーブルに新しい列を貼り付けるよりも優れている可能性があります。
- 多くの人はそれらのすべてを持っているわけではなく、多くの空白を残し、そして
- 誰かが3つのセル番号を持っている場合、次のような厄介な列を追加することになります。
cell_number_2
懸念＃1は有効ですが、懸念＃2は「あなたはそれを必要としない」の例かもしれません。「1つのセル番号のみを許可します。それだけです」と言うのは妥当です。その場合、電話番号用に別のテーブルを作成する必要はありません。
これはトレードオフです。個別のテーブルを作成しないことにより、厳密に正規化することはなく、多くのNULLスペースが存在する可能性があります。ただし、実行する結合も少なく、作業も少なくて済みます。
多くのグッドプラクティスと同様に、正規化はそれ自体で目的になる可能性があります。つまり、あなたが正しくやったので、個人的に自分に与えるゴールドバッジです。そして、それは大丈夫です。しかし、物事を単純に保つために、ルールが時々曲がることがあることを理解するのは良いことです。
最後にもう1つ、コードが起動して実行されたら、dbスキーマを変更するのが面倒であるという事実を比較検討する必要があります。したがって、「必要ない」と言ってもかまいませんが、コミットする前に十分に確認してください。
于 2010-01-14T15:58:40.583 に答える
5
ストレージとパフォーマンスについてはすでにいくつかの良い答えがありますが、それに加えて、非正規化を検討する必要があることを示すもう1つの指標は、自己結合を使用したクエリが必要になる場所です。
概念的にはもちろん、自己結合テーブルには何の問題もありませんが、経験上、経験の浅いプログラマーにとっては理解が難しい概念の1つであり、その結果、バグが発生する傾向があります。これらの必要性を設計できれば、将来のメンテナンスパスが容易になる可能性があります。
もちろんそれは判断の問題であり、ルールではなく指標です。
于 2010-01-14T15:59:46.823 に答える
2
彼らがあまりにも正常化した場所で働いた。彼らは、郵送先住所テーブルから「state」列を削除しました。2バイトの状態列の代わりに、状態テーブルにリンクする整数の外部キーフィールドを配置します。
要約すれば：
アドレステーブルの2バイトの状態列を4バイトの列に置き換えました。これで、すべての行にさらに2バイトのストレージが必要になります。
彼らは、4バイトの主キー列と2バイトの状態列を持つ状態テーブルを追加しました。このテーブルを格納するためにより多くのスペースを占有します。
データベースは、キーのbtreeインデックスを状態テーブルに保持します。より多くのスペースを占有します。
アドレスを取得するSQLは記述が困難です。
アドレスを取得するSQLは、元のSQLよりも低速です。
確かに、これは重複した不変のデータを素朴に削除します。その結果、より多くのディスクスペースを使用し、使用が難しくなり、使用が遅くなります。
あなたは間違いなくあまりにも多くを正規化することができます。
于 2010-01-14T16:24:56.413 に答える
2
スイートスポットを見つける必要があります...正規化されすぎると、1列または2列のデータのみを含む多くの「膨らんだ」抽象構造になり、ほとんどのクエリで5つのテーブルを結合することになります。
正規化が不十分であると、さまざまな場所に大量のデータが存在することになります。これにより、キャッシュサイズなどが原因でDBの速度が低下する可能性があります。また、何かを更新する必要がある場合は、1つではなく4つの異なるテーブルを更新する必要があります。また、さまざまな場所のすべてのデータが一致することを確認することもできません。
基本的に、あなたの毒を選び、あなたのDBがどのように使われるかを見て、それについて正気である。すべてのルールは破られることを意図しており、非常に一般的にアクセスされる2つの場所にデータがある場合は、それで問題ありません。これは、（おそらく2つ以上の）テーブルを結合するとコストがかかりすぎる可能性がある重要な部分です。ただし、データベースのスペースや速度を微最適化しないでください。
于 2010-01-14T15:49:09.903 に答える
1
データウェアハウジングは、パフォーマンス上の理由から、正規化されていないアプローチを使用することがよくあります。ウィキペディアごと：
データベース設計ガイダンスの標準的な部分は、設計者が完全に正規化された設計を作成する必要があるということです。その後、パフォーマンス上の理由から、選択的非正規化を実行できます。ただし、データウェアハウス設計への次元モデリングアプローチなど、一部のモデリング分野では、正規化されていない設計、つまり大部分が3NFに準拠していない設計を明示的に推奨しています。
于 2010-01-14T15:47:18.270 に答える
1
正規化は冗長性を排除しますが、ある意味でパフォーマンスが低下する場合（必要なすべての結合のため）、ハードウェアのコストが不十分であり、パフォーマンスのために冗長性を許可する時期です。それが私の親指のルールです。回答時間が長い場合も同様です。
于 2010-01-14T15:44:02.003 に答える
0
レポートとデータウェアハウジングは、おそらくデータが非正規化されているのを見つける最大の場所です。OLAPシステムは通常、常に単一のテーブルまたはテーブルのセットに非正規化されます。
于 2010-01-14T16:23:58.967 に答える
0
完全に正規化されていないスキーマになる設計規則に従っている場合は、正規化しないでください。そのような設計分野の 1 つがスター スキーマ設計であり、それに近い変形がスノーフレーク スキーマです。
スターとスノーフレークの両方を使用すると、さまざまなレポート、カスタマイズされた抽出、および Cognos Power Play などの OLAP ツールへのインターフェイスで使用するのがはるかに簡単なスキーマが得られます。欠点は？通常の形式 (1NF を除く) からのすべての逸脱は、データの挿入/更新/削除時に異常を伴います。正規形を本当に知っていれば、関連する異常が何であるかがわかります。スター/スノーフレークを最新の状態に保つために ETL (抽出、変換、およびロード) 手順を記述する場合、これらの異常に対処する必要があります。
では、スター スキーマまたはスノーフレーク スキーマが正規化されたスキーマよりも優れているのはどのような場合でしょうか? 通常、データ ウェアハウス、データ マート、およびレポート データベース用です。私自身の実践では、OLTP データベースのバックエンド以外のものを構築したことはありません。OLPT データベースは、ほぼ完全な正規化の恩恵を受けています。非正規化してすべての規律を放棄しないでください。それはランダムに設計するようなものです。
于 2010-01-14T20:58:10.683 に答える