database - データベースに関しては、「正確さのために正規化し、パフォーマンスのために非正規化する」というのは正しいマントラですか?

Question

ノーマライゼーションは、美的快楽を含む多くの本質的で望ましい特性につながります。その上、それは理論的にも「正しい」です。このコンテキストでは、パフォーマンスを達成するための妥協、修正として非正規化が適用されます。データベースが非正規化される可能性があるのは、パフォーマンス以外の理由がありますか?

score 81 · Accepted Answer

非正規化の最も一般的な理由は次の 2 つです。

パフォーマンス
無知

前者はプロファイリングで検証する必要があり、後者は丸めた新聞紙で修正する必要があります;-)

より良いマントラは、「正確さのために正規化し、速度のために非正規化する-そして必要な場合にのみ」であると思います

score 50 · Accepted Answer

元の質問の重要性を完全に理解するには、システム開発におけるチームのダイナミクスと、さまざまな役割/種類の人々が素因となる行動 (または不正行為) の種類について理解する必要があります。ノーマライゼーションは重要です。なぜなら、ノーマライゼーションは設計パターンについて冷静に議論するだけではないからです。それはまた、システムがどのように設計され、時間の経過とともに管理されるかにも大きく関係しています。

データベース担当者は、データの整合性が最も重要な問題であることを訓練されています。データが 100% 正確であるという観点から考えるのが好きなので、データが DB に入ったら、論理的に間違っていることを考えたり対処したりする必要はありません。この考え方は、データとシステムの根底にあるロジックをチームに理解させる (強制する) ため、正規化に高い価値を置いています。些細な例を考えると、顧客は名前と住所を 1 つしか持っていませんか、それとも複数持っている可能性がありますか? 誰かが決定する必要があり、システムはそのルールが一貫して適用されることに依存するようになります。これは単純な問題のように聞こえますが、かなり複雑なシステムを設計すると、その問題が 500 倍に増加し、問題が明らかになります。規則は紙の上に存在するだけではなく、施行する必要があります。適切に正規化されたデータベース設計 (一意性制約、外部キー、チェック値、ロジック強制トリガーなどの追加の助けを借りて) は、明確に定義されたコアデータモデルとデータの正確性ルールを保持するのに役立ちます。これは、次の場合に非常に重要です。多くの人がシステムのさまざまな部分 (さまざまなアプリ、レポートなど) で作業し、さまざまな人が時間の経過とともにシステムで作業するときに、システムが期待どおりに機能することを望みます。別の言い方をすれば、堅固なコアデータモデルを定義して運用を強化する方法がなければ、システムは機能しません。多くの人がシステムのさまざまな部分 (さまざまなアプリ、レポートなど) で作業し、さまざまな人が時間の経過とともにシステムで作業するときに、システムが期待どおりに機能するようにする場合、これは非常に重要です。別の言い方をすれば、堅固なコアデータモデルを定義して運用を強化する方法がなければ、システムは機能しません。多くの人がシステムのさまざまな部分 (さまざまなアプリ、レポートなど) で作業し、さまざまな人が時間の経過とともにシステムで作業するときに、システムが期待どおりに機能するようにする場合、これは非常に重要です。別の言い方をすれば、堅固なコアデータモデルを定義して運用を強化する方法がなければ、システムは機能しません。

他の人 (多くの場合、経験の浅い開発者) は、このようには見なしません。彼らは、データベースをせいぜい自分たちが開発しているアプリケーションの奴隷になるツール、最悪の場合は避けなければならない官僚主義だと考えています。(私が言っているのは「経験の浅い」開発者であることに注意してください。優れた開発者は、データベース担当者と同じように、堅実なデータモデルとデータの正確性の必要性を認識しています。それを達成するための最善の方法については異なる場合がありますが、私の経験では、DB チームが何をしているかを理解し、開発者に対応できる限り、DB 層でこれらのことを行うことに合理的にオープンです)。これらの経験の浅い人々は、多かれ少なかれ、データモデルの設計と管理という迅速で汚い仕事をするための言い訳として、非正規化を推進する人です。これが、アプリケーション画面とレポートを含む 1:1 のデータベーステーブルを取得する方法であり、それぞれが異なる開発者の設計上の仮定を反映しており、テーブル間の健全性/一貫性が完全に欠如しています。私はこれまでのキャリアで何度か経験してきました。システムを開発するのは、がっかりし、非常に非生産的な方法です。

したがって、人々がノーマライゼーションに強い思いを抱く理由の 1 つは、この問題が、彼らが強く感じている他の問題の代役であるということです。正規化についての議論に夢中になっている場合は、当事者が議論に持ち込んでいる可能性のある根本的な (非技術的な) 動機について考えてください。

そうは言っても、元の質問に対するより直接的な回答は次のとおりです:)

データベースは、論理設計に可能な限り近いコア設計 (高度に正規化され制約された設計) と、安定したアプリケーションインターフェイスやパフォーマンスなどの他の問題に対処する拡張設計で構成されていると考えると便利です。

コアデータモデルを制約して正規化する必要があります。そうしないと、データの基本的な整合性と、システムが構築されているすべてのルール/前提が損なわれるためです。これらの問題をあなたから遠ざけると、システムはすぐにダメになります. 要件と実世界のデータに対してコアデータモデルをテストし、機能するまで狂ったように繰り返します。このステップは、ソリューションを構築するというよりも、要件を明確にするように感じるでしょう。コアデータモデルを強制機能として使用して、関係者全員がこれらの設計上の問題について明確な答えを得ることができます。

拡張データモデルに進む前に、コアデータモデルを完成させます。それを使用して、どこまで到達できるかを確認してください。データ量、ユーザー数、および使用パターンによっては、拡張データモデルがまったく必要ない場合もあります。インデックス作成に加えて、DBMS で調整できる 1,001 のパフォーマンス関連のノブを使用して、どこまで到達できるかを確認してください。

DBMS のパフォーマンス管理機能を真に活用する場合は、非正規化を追加する方法でデータモデルを拡張することを検討する必要があります。これは、コアデータモデルを非正規化することではなく、非正規化データを処理する新しいリソースを追加することであることに注意してください。たとえば、パフォーマンスを低下させる巨大なクエリがいくつかある場合、それらのクエリが生成するデータを事前に計算するテーブルをいくつか追加することをお勧めします。つまり、クエリを事前に実行します。非正規化されたデータとコア (正規化された) データの一貫性を維持する方法でこれを行うことが重要です。たとえば、それらをサポートする DBMS では、MATERIALIZED VIEW を使用して denorm データのメンテナンスを自動化できます。DBMS にこのオプションがない場合は、

現実的なパフォーマンスの課題に対処するために一貫した方法でデータベースを選択的に非正規化することと、単純に弱いデータ設計を使用してパフォーマンスを正当化することとの間には、大きな違いがあります。

私が低から中程度の経験を持つデータベース担当者や開発者と一緒に仕事をするとき、私は彼らが完全に正規化された設計を作成することを主張します...その後、選択的非正規化の議論に少数の経験豊富な人々を巻き込む可能性があります。コアデータモデルでは、非正規化は多かれ少なかれ常に悪いことです。コアの外では、よく考えて一貫した方法で非正規化を行うのであれば、何の問題もありません。

言い換えれば、通常の設計から、通常の設計を維持しながら非正規化を追加する設計 (データの本質的なロジックを維持しながらデータの物理的な現実を扱う設計) に非正規化することは問題ありません。通常の設計のコアを持たない設計 (非正規化と呼ぶべきではない) は、最初から正規化されておらず、規律ある方法で意識的に設計されていないため、問題ありません。

弱くて統制の取れていない設計を「非正規化」設計という用語を受け入れないでください。意図的/慎重に非正規化されたデータと、設計者が不注意なばかだったために非正規化データをもたらす単純な古いくだらないデータベース設計との間の混乱が、非正規化に関する多くの議論の根本的な原因であると私は信じています。

score 16 · Accepted Answer

通常、非正規化は検索効率の向上を意味しますが (それ以外の場合、なぜそれを行う必要があるのか)、変更 (挿入、更新、場合によっては削除) 操作中にデータを検証するという複雑なコストがかかります。ほとんどの場合、余分な複雑さは無視され (説明するのが非常に難しいため)、データベース内の偽のデータにつながります。これは、後になるまで検出されないことがよくあります。非正規化されているため、データが自己矛盾していたことが判明しました。

私は、マントラは「正しさのために正常化し、上級管理職があなたの仕事を他の誰かに与えることを申し出た場合にのみ非正規化する」に行くべきだと思います.したいです。

または、「経営陣が、作成される混乱についてあなたを免罪する電子メールを送信した場合にのみ、非正規化します」。

もちろん、これはあなたが自分の能力と会社にとっての価値に自信を持っていることを前提としています。

score 11 · Accepted Answer

マントラはほとんどの場合、主題を単純化しすぎています。これはその一例です。

正規化の利点は、単なる理論的または審美的なものではありません。2NF 以降の通常のフォームから逸脱するたびに、通常のフォームに従わない場合に発生し、通常のフォームに従うと消える更新異常があります。1NF からの出発はまったく別のワームの缶詰であり、ここでは扱いません。

これらの更新の異常は、通常、新しいデータの挿入、既存のデータの更新、および行の削除に分類されます。通常、巧妙でトリッキーなプログラミングを行うことで、これらの異常を回避できます。問題は、コストに見合う巧妙でトリッキーなプログラミングを使用することの利点です。時々、コストはバグです。場合によっては、適応性の喪失が代償となります。場合によっては、信じられないかもしれませんが、パフォーマンスの低下が実際のコストになることもあります。

さまざまな正規形を学習した場合、付随する更新の異常を理解するまで、学習は不完全であると考えるべきです。

ガイドラインとしての「非正規化」の問題は、何をすべきかを教えてくれないことです。データベースを非正規化する方法は無数にあります。それらのほとんどは不幸であり、それは慈善的です. 最もばかげた方法の 1 つは、特定のクエリを高速化するたびに、一度に 1 ステップずつ単純に非正規化することです。アプリの歴史を知らなければ理解できない、クレイジーなミッシュモッシュになってしまいます。

「当時は良いアイデアのように思えた」多くの非正規化ステップは、後で非常に悪い動きであることが判明します。

完全に正規化しないことを決定した場合のより良い代替手段は次のとおりです。設計規律が完全な正規化から逸脱している場合でも、特定の利点をもたらす設計規律を採用します。例として、データウェアハウジングやデータマートで広く使用されているスタースキーマ設計があります。これは、単なる気まぐれによる非正規化よりも、はるかに首尾一貫した統制のとれたアプローチです。スタースキーマ設計から得られる特定の利点があり、スタースキーマ設計が正規化された設計と矛盾するために被る更新の異常と比較することができます。

一般に、スタースキーマを設計する多くの人は、OLTP アプリケーションプログラムと対話しないセカンダリデータベースを構築しています。このようなデータベースを最新の状態に保つ上で最も困難な問題の 1 つは、いわゆる ETL (抽出、変換、およびロード) 処理です。幸いなことに、このすべての処理は少数のプログラムにまとめることができ、正規化された OLTP データベースを扱うアプリケーションプログラマーは、このようなことを学ぶ必要はありません。ETL を支援するツールは世の中にあり、正規化された OLTP データベースからスタースキーマのデータマートまたはウェアハウスにデータをコピーすることはよく知られています。

スタースキーマを構築し、ディメンションを適切に選択し、列に適切な名前を付け、特に粒度を適切に選択した場合、Cognos や Business Objects などの OLAP ツールでこのスタースキーマを使用するのは、遊ぶのと同じくらい簡単です。ビデオゲーム。これにより、データアナリストは、データのコンテナーがどのように機能するかを学習する代わりに、データの分析に集中できます。

スタースキーマ以外にも正規化から逸脱する設計はありますが、スタースキーマは特筆に値します。

score 6 · Accepted Answer

データベースの一部を非正規化するたびに、コードのバグのリスクが高まり、システム全体の持続可能性が低下するため、データベースをさらに適応させる能力が低下することを忘れないでください。

幸運を！

score 6 · Accepted Answer

次元モデルのデータウェアハウスは、多くの場合、(非正規化された) スタースキーマでモデル化されます。これらの種類のスキーマは、(通常) オンラインの実動システムまたはトランザクションシステムには使用されません。

根本的な理由はパフォーマンスですが、ファクト/ディメンションモデルは、従来の ER スタイルのモデルで実行できるゆっくりと変化するディメンションなどの多くの時間的機能も考慮していますが、信じられないほど複雑で遅くなる可能性があります (有効な日付、アーカイブテーブル、アクティブなレコード)など）。

score 5 · Accepted Answer

正規化はパフォーマンスとは何の関係もありません。Erwin Smout がこのスレッドで述べたよりもうまく表現することはできません: データベースの正規化によるリソースへの影響は何ですか?

ほとんどの SQL DBMS では、論理モデルを損なうことなくデータの物理表現を変更するためのサポートが制限されているため、残念ながら、これが非正規化が必要になる理由の 1 つです。もう 1 つの理由は、多くの DBMS が複数テーブルの整合性制約を適切にサポートしていないため、これらの制約を実装するための回避策として、無関係な属性をいくつかのテーブルに入れることを余儀なくされる可能性があることです。

score 4 · Accepted Answer

データベースの正規化は、理論的な正確さのためだけではなく、データの破損を防ぐのにも役立ちます。@aSkywalkerが示唆するように、「単純さ」のために非正規化することは絶対にありません。破損したデータの修正とクリーニングは簡単ではありません。

score 3 · Accepted Answer

「正確さ」自体を正規化することはありません。これが事です：

非正規化されたテーブルには、パフォーマンスが向上するという利点がありますが、冗長性と開発者の頭脳が必要になります。

正規化されたテーブルには、冗長性を減らし、開発を容易にするという利点がありますが、パフォーマンスが必要です。

それは古典的なバランスの取れた方程式のようなものです。そのため、必要に応じて (データベースサーバーにどれだけ多くの負荷がかかっているかなど)、本当に必要でない限り、正規化されたテーブルを使用する必要があります。ただし、正規化から非正規化への開発は、その逆よりも簡単で低コストです。

score 1 · Accepted Answer

非正規化されたデータは、正規化が十分に行われていない場所でよく見られます。

私のモットーは「正確さのために正規化し、パフォーマンスのために排除する」です。RDBM は非常に柔軟なツールですが、OLTP の状況に合わせて最適化されています。RDBMS をより単純なもの (たとえば、メモリ内のトランザクションログを持つオブジェクト) に置き換えると、非常に役立ちます。

score 1 · Accepted Answer

とんでもない。正規化する必要があるのは、テーブル (物理レベル) ではなく、関係 (論理レベル) であることに注意してください。

score 1 · Accepted Answer

正規化されたデータベースは常に、よりシンプルでクリーンで堅牢なコードに関連付けられているというここの人々の主張に異議を唱えます。完全に正規化されたコードが、部分的に非正規化されたコードよりも単純なコードに関連付けられる場合が多いことは確かですが、これはせいぜいガイドラインであり、物理法則ではありません。

ある人が、言葉を生きた考えの皮膚と定義したことがあります。CS では、オブジェクトまたはテーブルは、理想的なオブジェクトのプラトニックな反映ではなく、問題のニーズと既存のインフラストラクチャの観点から定義されていると言えます。理論的には、理論と実践の間に違いはありませんが、実際には、理論からの変化が見られます。この言葉は CS にとって特に興味深いものです。この分野の焦点の 1 つは、これらの違いを見つけて可能な限り最善の方法で処理することだからです。

DB 側から離れてコーディング側に目を向けると、オブジェクト指向プログラミングは、密接に関連する多くのコードをオブジェクトクラス名の下にグループ化することで、スパゲッティコーディングの多くの弊害から私たちを救ってくれました。覚えやすく、関連付けられているすべてのコードに何らかの形で適合する英語の意味を持っています。クラスター化された情報が多すぎると、各オブジェクト内で大量の複雑さが生じ、スパゲッティコードを連想させます。クラスターを小さくすると、「マカロニコード」と呼ばれる、各オブジェクトの情報が非常に少ない多数のオブジェクトを検索せずにロジックのスレッドをたどることができなくなります。

プログラミング側の理想的なオブジェクトサイズと、データベースを正規化した結果のオブジェクトサイズとの間のトレードオフを見ると、データベースに基づいて選択した方がよい場合が多いという意見に同意します。コードでその選択を回避します。特に、場合によっては、休止状態やそのようなテクノロジーとの結合からオブジェクトを作成できるためです。しかし、これは絶対的なルールであるとは言えません。OR-Mapping レイヤーは、最も単純なケースに複雑さを追加することを犠牲にして、最も複雑なケースをより単純にするという考えで書かれています。また、複雑さはサイズの単位ではなく、複雑さの単位で測定されることに注意してください。そこにはあらゆる種類の異なるシステムがあります。数千行のコードに成長し、そこに永遠に留まると予想されるものもあります。他のものは、企業のデータへの中心的なポータルとなることを意図しており、理論的には制約なしであらゆる方向に成長する可能性があります. 一部のアプリケーションは、更新ごとに何百万回も読み取られるデータを管理します。また、監査やアドホックの目的でのみ読み取られるデータを管理するものもあります。一般的なルールは次のとおりです。

正規化は、分割の両側のデータを変更でき、潜在的な変更が互いに独立している場合、中規模以上のアプリではほとんどの場合良い考えです。
通常、単一のテーブルからの更新または選択は、複数のテーブルを操作するよりも簡単ですが、適切に記述された OR を使用すると、データモデル空間の大部分でこの違いを最小限に抑えることができます。単純な SQL を使用すると、オブジェクト指向ではない方法ではありますが、個々のユースケースを回避するのはほとんど簡単です。
コードは管理しやすいように比較的小さく保つ必要があり、これを行う効果的な方法の 1 つは、データモデルを分割し、データモデルのさまざまな部分にサービス指向のアーキテクチャを構築することです。データ (非) 正規化の最適な状態の目標は、全体的な複雑さの管理戦略のパラダイム内で考える必要があります。

複雑なオブジェクト階層には、更新のカスケードなど、データベース側では見られない複雑さがあります。リレーショナル外部キーとクロスリンクをオブジェクト所有関係でモデル化する場合、オブジェクトを更新するときに、更新をカスケードするかどうかを決定する必要があります。これは、SQL よりも複雑になる可能性があります。これは、データファイルをロードすることと、そのタイプのファイル用のパーサーを作成することの違いのようなものです。C++ や Java などで更新または削除をカスケードするコードは、さまざまなシナリオで適切な決定を下す必要があり、このロジックの誤りの結果は非常に深刻になる可能性があります。

また、正規化の教訓の 1 つを説明するに値する点もあります。データベースの正規化に関する中心的な議論は、データの重複は常に悪いという考えです。多くの場合、これは真実ですが、ソリューションのさまざまな部分にさまざまな所有者がいる場合は特に、従順に従うことはできません。ある開発者グループが特定のタイプのトランザクションを管理し、別の開発者グループがこれらのトランザクションの監査可能性をサポートしている状況を見たことがあります。そのため、2 番目の開発者グループは、トランザクションが発生するたびに複数のテーブルをスクレイピングし、非正規化テーブルを作成するサービスを作成しました。実際には、トランザクション時のシステムの状態を示すスナップショットレコード。このシナリオは興味深い使用例です (少なくとも質問のデータ複製部分について)。しかし、それは実際には、より大きなカテゴリの問題の一部です。データの一貫性を求めると、データベース内のデータの構造に特定の制約が課せられることがよくあります。これにより、エラーの処理とトラブルシューティングが簡単になり、誤ったケースの一部が不可能になります。ただし、データのサブセットを変更すると、一貫性ルールの下で過去のトランザクションが無効になるため、これはデータの一部を「凍結」するという影響も与える可能性があります。明らかに、これを整理するにはある種のバージョン管理システムが必要です。したがって、明らかな問題は、正規化されたバージョン管理システム (有効時間と有効期限) を使用するか、スナップショットベースのアプローチ (トランザクション時間の値) を使用するかです。スナップショットアプローチでは心配する必要のない、正規化されたバージョンの内部構造に関する質問がいくつかあります。

大きなテーブルでも日付範囲クエリを効率的に実行できますか?
日付範囲が重複しないことを保証できますか?
状況イベントを追跡して、オペレーター、トランザクション、または変更の理由を突き止めることはできますか? (おそらくそうですが、これは追加のオーバーヘッドです)
より複雑なバージョン管理システムを作成することで、適切な所有者に適切なデータを任せていますか?

ここでの最適な目標は、理論的に正しいことだけでなく、なぜそれが正しいのか、違反の結果は何かを学ぶことだと思います。そうすれば、現実の世界にいるときに、どの結果を得るために取る価値があるかを判断できます。他にどのようなメリットがありますか。それがデザインの本当の挑戦です。

score -2 · Accepted Answer

シンプル？スティーブンが彼の新聞で私をたたくかどうかはわかりませんが、私がぶらぶらしている場所では、非正規化されたテーブルが、データベース/開発者に常にバグを与えることなく、レポート/読み取り専用の人が仕事を成し遂げるのに役立つ場合があります...

database - データベースに関しては、「正確さのために正規化し、パフォーマンスのために非正規化する」というのは正しいマントラですか?

14 に答える 14

Related

Reference