database-design - 大規模系で最適な正規形は?

Question

大規模なシステムがある場合、3NF、BCNF、4NF、5NF、またはそれ以上のどの正規形を使用する必要がありますか?

Answer 1

場合によります。

可能な限り正規化することをお勧めします-つまり、5NF、-次に、パフォーマンスまたはレポートの目的で必要に応じて非正規化されたフィールドを追加します(既存の正規化されたデータベースに非正規化された要素を追加する方が、既に存在する非正規化された構造を正規化するよりもはるかに簡単です)使用する）

Answer 2

場合によります。データで何をするつもりですか？

データベースはオンライン トランザクション処理 (OLTP) をサポートするように設計されていますか? それとも、オンライン分析処理 (OLAP)、レポート、データ マート、またはデータ ウェアハウス アクティビティをサポートすることを目的としていますか?

OLAP の場合、スター スキーマまたはスノーフレーク スキーマの設計を検討し、通常のフォームについて心配する必要はありません。OLTP の場合、正規化されたデータベースは、正規化されていないデータベースよりも優れた結果をもたらす可能性があります。

正確なデータはどれほど重要ですか? 矛盾するデータベースは、本当に混乱する可能性があります。同等であるはずの 2 つの出力が、代わりに互いに矛盾していますか? これはどのように起こりますか？

データベースが同じ事実をデータベース内のいくつかの場所に保存する場合、その事実の相互に矛盾する異なるバージョンを異なる場所に保存することができるかもしれません。データベースは、ファクトの複数のコピーを複数の場所にどのように格納しますか? 完全に正規化されていない場合。

各正規形に関連付けられているのは、行が挿入、更新、または削除されたときに発生する可能性のある 1 つ以上の更新異常です。これらの異常は、対応する正規形によって回避されます。更新プログラムを慎重にプログラミングすることでこの問題を回避できますが、回避するよりも回避する方が確実です。必要に応じて正規形を確認して、異常に慣れ、自分のケースでそれらがどれほど大きな問題であるかを判断してください。

更新時のパフォーマンスはどの程度重要ですか? クエリ時に？

データベースのスペースを節約するために、正規化することを勧める人もいます。ディスク容量は安価です。処理時間を気にする人もいます。これは一般的に些細なことです。余分なディスク アクセスによる遅延は顕著ですが、多くの場合、管理可能です。

ただし、正規化に失敗すると、パフォーマンスが低下する可能性がある場所があります。これは、重い負荷と保守的な同時実行制御に関連するボトルネックです。ほとんどの DBMS サーバーは、ファントム更新のような不可解なタイミング依存のバグからデータを保護するために、保守的な同時実行制御ポリシーを採用しています。同時実行制御ポリシーを緩めることができたとしても、それを行うのは危険です。

正規化が不十分なデータベースには、多くの場合、これらのボトルネックまたは「ホット スポット」があります。システムの負荷が軽い場合、これらは表示されません。システムは、実際の運用ではクロールまで遅くなるだけで、フライングカラーでベータテストを通過する可能性があります. Web サイトをバックアップするデータベースは、この欠陥があることで有名です。正規化は、更新トランザクションをシンプルに保つことで、この状況を回避するのに役立ちます。

では、何を目指すべきか？私がデータベースを構築していたとき、私は一般的に 3NF または BCNF を目指しました。3NFは本当に簡単です。キー以外のデータがキー、キー全体、およびキーのみに依存することを確認するだけです（Coddを助けてください）。通常、4NF または 5NF について心配する必要はありませんでしたが、これも場合によって異なります。