OLAPデータベースは読み取りパフォーマンスのために非正規化する必要がありますか？
OLAPデータベース設計で行われ、OLTP設計ではさらに3NFを誇張されていないため、データベースは読み取りパフォーマンスのために非正規化する必要があると常に考えていました。
時間ベースのデータに対するさまざまなアプローチのパフォーマンス など、さまざまな投稿のPerformanceDBAは、データベースが常に5NFおよび6NF（通常の形式）への正規化によって適切に設計されるべきであるというパラダイムを守ります。
私はそれを正しく理解しましたか（そして私が正しく理解したことは何ですか）？
OLAPデータベース（3NF未満））の従来の非正規化アプローチ/パラダイム設計の何が問題になっているか、およびOLTPデータベースのほとんどの実際的なケースには3NFで十分であるというアドバイス
例えば：
非正規化が読み取りパフォーマンスを促進するという理論を決して把握できなかったことを告白しなければなりません。誰かが私にこれとこれとは逆の信念についての論理的な説明を付けた参考資料を与えることはできますか？
OLAP /データウェアハウスデータベースを正規化する必要があることを関係者に納得させるために参照できる情報源は何ですか？
見やすくするために、コメントからここにコピーしました：
「参加者が6NFで実際に（科学プロジェクトを含まない）データウェアハウス実装の数を追加（開示）するといいでしょう。これは、参加または参加したものです。一種のクイックプールです。私=0。」 – Damir Sudarevic
「正規化されたアプローチ[対ラルフキンボールによる次元の1つ]は、3NFモデル（第3正規形）とも呼ばれ、そのサポーターは「インモナイト」と呼ばれます。 「データウェアハウスはERモデル/正規化モデルを使用してモデル化する必要があると述べられているBill Inmonのアプローチを信じてください。」
正規化されたデータウェアハウジングアプローチ（Bill Inmonによる）は3NF（？）を超えないと認識されているようです。
データウェアハウジング/ OLAPが非正規化の同義語であるという神話の起源（または遍在する公理的信念）を理解したいだけです。
Damir Sudarevicは、彼らはよく舗装されたアプローチであると答えました。質問に戻りましょう：なぜ非正規化が読書を促進すると信じられているのですか？
神話
OLAPデータベース設計で行われているように、データベースは読み取り用に非正規化する必要があり、OLTPデザイン。
その影響には神話があります。リレーショナルデータベースのコンテキストでは、6つの非常に大きな、いわゆる「非正規化」「データベース」を再実装しました。そして、それらを正規化し、標準とエンジニアリングの原則を適用するだけで、他の問題を修正する80以上の割り当てを実行しました。神話の証拠は見たことがありません。マントラをある種の魔法の祈りのように繰り返している人だけが。
正規化と非正規化
（「非正規化」とは、私が使用を拒否する詐欺的な用語です。）
これは科学産業です（少なくとも、壊れないソフトウェアを提供するビット、人々を月に乗せるビット、銀行システムを実行するビットなど）。それは魔法ではなく、物理法則に支配されます。コンピュータとソフトウェアはすべて、物理法則の対象となる有限で有形の物理オブジェクトです。私が受けた中等・高等教育によると：
大きく、太く、整理されていないオブジェクトは、小さく、薄く、整理されたオブジェクトよりもパフォーマンスがよくありません。
はい、正規化により多くのテーブルが生成されますが、各テーブルははるかに小さくなります。また、テーブルの数が多くても、実際には（a）結合が少なく、（b）セットが小さいため、結合が高速です。必要なインデックスが少ないほど、インデックスの数が少なくなります。正規化されたテーブルでは、行サイズがはるかに短くなります。
リソースの特定のセットについて、正規化されたテーブル：
- より多くの行を同じページサイズに合わせる
- したがって、同じキャッシュスペースにより多くの行が収まるため、全体的なスループットが向上します）
- したがって、同じディスクスペースにより多くの行が収まるため、I/Oの回数が減ります。 I/Oが必要な場合は、各I/Oの方が効率的です。
。
- 複製が多いオブジェクトは、単一のバージョンの真実として格納されているオブジェクトよりもパフォーマンスが高くなることはありません。例えば。テーブルと列のレベルで5倍の重複を削除すると、すべてのトランザクションのサイズが縮小されました。ロッキングが減少しました。更新異常が消えました。これにより競合が大幅に減少し、同時使用が増加しました。
したがって、全体的な結果ははるかに高いパフォーマンスでした。
同じデータベースからOLTPとOLAPの両方を提供している）私の経験では、正規化された構造を「非正規化」する必要はありませんでした。読み取り専用（OLAP）クエリの速度を向上させることも神話です。
- いいえ、他の人から要求された「非正規化」は速度を低下させ、それは排除されました。私には驚きはありませんでしたが、繰り返しになりますが、要求者は驚きました。
神話を売って、多くの本が人々によって書かれました。これらは非技術者であることを認識しておく必要があります。彼らは魔法を販売しているので、彼らが販売する魔法には科学的根拠がなく、販売ピッチで物理法則を都合よく回避しています。
（上記の物理科学に異議を唱えたい場合は、マントラを繰り返しても効果はありません。マントラを裏付ける具体的な証拠を提供してください。）
なぜ神話が流行しているのですか？
まあ、最初に、それは物理学の法則を克服する方法を求めない科学のタイプの間で流行していません。
私の経験から、有病率の3つの主な理由を特定しました。
データを正規化できない人にとって、それを行わないことの正当な理由はそれです。彼らは魔法の本を参照でき、魔法の証拠がなくても、「有名な作家が私がしたことを検証するのを見る」と敬意を込めて言うことができます。正確には、完了していません。
多くのSQLコーダーは、単純な単一レベルのSQLしか記述できません。正規化された構造には、SQL機能が少し必要です。彼らがそれを持っていない場合;一時テーブルを使用せずにSELECTを生成できない場合。サブクエリを記述できない場合は、心理的に心理的にフラットファイルのヒップファイル（「非正規化」構造と呼ばれるもの）に接着され、canプロセスになります。
人愛本を読んだり、理論について話し合ったりする。経験なし。特に魔法について。それは強壮剤であり、実際の経験の代わりです。実際にデータベースを正しく正規化した人は、「非正規化は正規化よりも速い」とは述べていません。マントラを述べている人には、単に「証拠を見せて」と言ってください。したがって、現実には、人々はこれらの理由で神話を繰り返します正規化の経験なし。私たちは動物の群れであり、未知は私たちの最大の恐怖の1つです。
そのため、プロジェクトには常に「高度な」SQLとメンタリングを含めています。
私の答え
私があなたの質問のすべての部分に答える場合、または他のいくつかの答えの誤った要素に対応する場合、この回答は途方もなく長くなるでしょう。例えば。上記は1つの項目のみに回答しています。したがって、私は特定のコンポーネントに取り組むことなく、全体的にあなたの質問に答え、異なるアプローチをとります。私はあなたの質問に関連する科学のみを扱います。私は資格があり、非常に経験があります。
科学を扱いやすいセグメントで紹介します。 
6つの大規模なフル実装割り当ての典型的なモデル。
- これらは、小規模な企業で一般的に見られる閉じた「データベース」であり、組織は大規模な銀行でした
- 第一世代のアプリを実行するという考え方では非常にいいが、パフォーマンス、整合性、品質の面で完全に失敗
- アプリごとに個別に設計されています
- レポートは不可能でした、彼らは各アプリを介してのみレポートできました
- 「非正規化」は神話なので、正確な技術定義は、非正規化でした。
- 「非正規化」するには、まず正規化する必要があります。次に、「非正規化された」データモデルが表示されたすべてのインスタンスでプロセスを少し逆にします。単純な事実は、正規化されていないことです。したがって、「非正規化」は不可能でした。それは単に正規化されていなかった
- リレーショナルテクノロジー、またはデータベースの構造と制御があまりなかったため、「データベース」として受け渡されたため、これらの単語を引用符で囲みました。
- 正規化されていない構造について科学的に保証されているように、それらは複数のバージョンの真理（データの重複）に苦しんでいるため、それぞれの中で高い競合と低い同時実行性がありました
- 彼らはデータ複製の追加の問題を抱えていましたacross「データベース」
- 組織はこれらすべての複製を同期させようと試みていたため、複製を実装しました。もちろん、これは追加のサーバーを意味しました。開発するETLおよび同期スクリプト。そして維持;等
- 言うまでもなく、同期は十分ではなく、彼らは永遠にそれを変更していました
- こうしたすべての競合と低いスループットにより、「データベース」ごとに個別のサーバーを正当化することはまったく問題ありませんでした。それはあまり役に立ちませんでした。
そこで、物理法則を検討し、少し科学を適用しました。 
データは企業（部門ではなく）に属し、企業は1つのバージョンの真実を必要とするという標準の概念を実装しました。データベースは5NFに正規化された純粋なリレーショナルでした。純粋なオープンアーキテクチャ。これにより、あらゆるアプリやレポートツールがアクセスできるようになります。ストアドプロシージャ内のすべてのトランザクション（ネットワーク全体のSQLの制御されていない文字列とは対照的）。 「高度な」教育を受けた後、各アプリの同じ開発者が新しいアプリをコーディングしました。
明らかに科学は働いた。まあ、それは私の私的な科学や魔法ではなく、それは普通の工学と物理法則でした。すべてが1つのデータベースサーバープラットフォーム上で実行されました。サーバーの2つのペア（運用とDR）が廃止され、別の部門に渡されました。合計720GBの5つの「データベース」は、合計450GBの1つのデータベースに正規化されました。約700のテーブル（多くの重複および重複した列）は、500の重複しないテーブルに正規化されました。全体的には10倍高速で、一部の関数では100倍以上高速でした。それは私の意図であり、科学はそれを予測したので、それは私を驚かせませんでしたが、それはマントラで人々を驚かせました。
より正規化
まあ、すべてのプロジェクトでノーマライゼーションに成功し、関係する科学に自信を持っているので、ノーマライゼーションへの自然な進歩でしたmore、それ以下ではありません。昔は3NFで十分で、後のNFはまだ特定されていませんでした。過去20年間、私は更新の異常がゼロのデータベースのみを提供してきました。そのため、今日のNFの定義により、常に5NFを提供してきました。
同様に、5NFは優れていますが、制限があります。例えば。大きなテーブルのピボット（MS PIVOT拡張による小さな結果セットではない）は低速でした。そこで、私（および他の人）は、ピボットが（a）簡単で（b）非常に高速になるように、正規化されたテーブルを提供する方法を開発しました。 6NFが定義されたので、これらのテーブルは6NFであることがわかります。
同じデータベースからOLAPおよびOLTPを提供しているので、科学と一致して、構造がより正規化されていることがわかりました。
彼らがより速く実行する
そして、それらはより多くの方法で使用できます（例：ピボット）
ですから、私は一貫して変わらない経験をしています。これは、正規化されているだけでなく、正規化されていない、または「非正規化されている」よりもはるかに高速です。 more正規化はlessよりも高速です。
成功の1つの兆候は、機能の成長です（失敗の兆候は、機能の成長を伴わないサイズの成長です）。つまり、彼らはすぐに、より多くのレポート機能を要求し、つまりNormalizedさらに多くのを要求し、それらの特殊なテーブルをさらに提供しました（数年後に判明し、6NFとなりました）。
そのテーマに進んでいます。私は常にデータベーススペシャリストであり、データウェアハウススペシャリストではなかったため、ウェアハウスを使用した最初のいくつかのプロジェクトは本格的な実装ではなく、かなりのパフォーマンスチューニングの割り当てでした。彼らは私の専門分野である製品について私の夢の中にいました。 
私たちは典型的なケースを見ているので、正規化の正確なレベルなどについて心配する必要はありません。 OLTPデータベースは合理的に正規化されていたが、OLAPに対応しておらず、組織は完全に別のOLAPプラットフォーム、ハードウェアを購入していた; ETLコードの大量の開発と保守に投資しました。その後、実装に続いて、生涯の半分を彼らが作成した複製の管理に費やしました。ここで、本の作家とベンダーは、ハードウェアと個別組織が購入するプラットフォームソフトウェアライセンス。
- まだ確認していない場合は、一般的な第1世代の「データベース」と一般的なデータウェアハウスの類似点にご注意ください。
その間、ファーム（上記の5NFデータベース）に戻って、どんどんどんどん追加していきましたOLAP機能。アプリの機能は確実に成長しましたが、それはわずかでした。ビジネスは変わっていません。彼らはより多くの6NFを要求し、それを提供することは簡単でした（5NFから6NFは小さなステップです; 0NFは何でも、5NFはもちろん、大きなステップです;体系的なアーキテクチャは簡単に拡張できます）。
OLTPとOLAPの大きな違いの1つは、個別 OLAPプラットフォームソフトウェアの基本的な理由として、OLTPは行指向であり、トランザクション的に安全な行を必要とし、高速です。OLAPは、トランザクションの問題を気にせず、列を必要とし、高速です。それがすべてのハイエンドBIまたはOLAPplatformsは列指向であるため、OLAPmodels（スタースキーマ、ディメンションファクト）は列指向です。
しかし6NFテーブルでは：
行はなく、列だけがあります。同じ目くらまし速度で行と列を提供します
テーブル（つまり、6NF構造の5NFビュー）はすでにDimension-Factsに編成されています。実際、これらはallディメンションであるため、他のOLAPモデルが識別できるよりも多くのディメンションに編成されています。
（少数の派生列のPIVOTとは対照的に）オンザフライで集計を使用してテーブル全体をピボットすることは、（a）簡単なコードであり、（b）非常に高速です。
![Typical Data Warehouse]()
私たちが長年にわたって提供してきたのは、定義により、OLTP使用の場合は少なくとも5NF、OLAP要件の場合は6NFのリレーショナルデータベースです。
これは、最初から使用しているのとまったく同じ科学であることに注意してください。 一般的な非正規化「データベース」から5NF企業データベースに移動します。実績のある科学のmoreを適用するだけで、より高い機能性とパフォーマンスが得られます。
5NF Corporate Databaseと6NF Corporate Databaseの類似点に注意してください
個別のOLAPハードウェア、プラットフォームソフトウェア、ETL、管理、保守のすべてのコストが排除されます。
データのバージョンは1つだけであり、更新の異常やメンテナンスはありません。 OLTPの場合は行として、OLAPの場合は列として提供された同じデータ
私たちが行っていない唯一のことは、新しいプロジェクトから始めて、最初から純粋な6NFを宣言することです。それが私が次に並べたものです。
第6正規形とは何ですか？
あなたが正規化のハンドルを持っていると仮定すると（ここでは定義しません）、このスレッドに関連する非学術的な定義は次のとおりです。これはテーブルレベルで適用されるため、同じデータベースに5NFテーブルと6NFテーブルを混在させることができます。
- 第5正規形：データベース全体で解決されたすべての機能依存関係
- 4NF/BCNFに加えて
- すべての非PK列はそのPKで1 :: 1です
- そして他のPKに
- 更新異常なし
。
- Sixth Normal Form：既約NFであり、データをさらに削減または正規化できないポイントです（7NFはありません）
- 5NFに加えて
- 行は主キーと最大で1つの非キー列で構成されます
- ヌル問題を解消
6NFはどのようなものですか？
データモデルはお客様のものであり、弊社の知的財産は無料で公開されていません。しかし、私はこのWebサイトに参加し、質問に対する具体的な回答を提供します。実際の例が必要なので、内部ユーティリティの1つにデータモデルを公開します。
これは、任意の期間、任意の顧客のサーバー監視データ（エンタープライズクラスのデータベースサーバーとOS）を収集するためのものです。これを使用して、パフォーマンスの問題をリモートで分析し、実行するパフォーマンスチューニングを検証します。構造は10年以上変更されていません（追加され、既存の構造に変更はありません）。これは、何年も後に6NFと識別された特殊な5NFの典型です。完全なピボットが可能です。任意のディメンションで描画されるチャートまたはグラフ（22ピボットが提供されますが、これは制限ではありません）;スライスとダイス;混ぜ合わせます。 all次元であることに注意してください。
監視データまたはメトリクスまたはベクトルは、モデルに影響を与えずに変更できます（サーバーバージョンの変更です。さらに何かを取得したいと思います）（別の投稿で思い出します。EAVは6NFのろくでなしの息子です。希釈されていない父親であり、したがって、標準、整合性、または関係の力を犠牲にすることなく、EAVのすべての機能を提供します。行を追加するだけです。
▶モニター統計データモデル◀ 。 （インラインには大きすぎます。一部のブラウザはインラインで読み込めません。リンクをクリックしてください）
▶Charts Like This◀ を生成することができ、顧客から生のモニタリング統計ファイルを受け取った後、6回のキーストロークを行います。組み合わせに注意してください。同じチャート上のOSとサーバー。さまざまなピボット。 （許可を得て使用）
リレーショナルデータベースのモデリングの標準に慣れていない読者は、 ▶IDEF1X Notation◀ が役立つと思います。
6NFデータウェアハウス
これは最近 Anchor Modeling によって検証されており、6NFを「次世代」OLAPデータウェアハウス用のモデルとして提示しています。（ OLTPおよびOLAPデータの単一バージョン、つまり私たちだけのもの）。
データウェアハウス（のみ）エクスペリエンス
データウェアハウスのみ（上記の6NF OLTP-OLAPデータベースではない）での私の経験は、完全な実装プロジェクトとは対照的に、いくつかの主要な任務でした。結果は、驚きではありませんでした：
科学と一致して、正規化された構造ははるかに速く実行されます。メンテナンスが簡単です。データ同期が少なくて済みます。キンボールではなく、インモン。
魔法と一致して、一連のテーブルを正規化し、物理法則を適用することでパフォーマンスを大幅に向上させた後、驚いたのはそのマントラを持つ魔術師だけです。
科学者はそれをしません。彼らは銀の弾丸と魔法を信じていない、または頼っていない。彼らは科学を使って問題を解決しています。
有効なデータウェアハウスの正当化
他の投稿で私が述べたのはそのためです。個別のデータウェアハウスプラットフォーム、ハードウェア、ETL、メンテナンスなどの唯一の有効正当化は、多くのデータベースまたは「データベース」があり、すべてマージされているところです。レポートとOLAPのために中央の倉庫に。
キムボール
キンボールについての言葉は、彼がデータウェアハウスにおける「パフォーマンスの非正規化」の主な提唱者であるために必要です。上記の私の定義によると、彼は明らかにが生活の中で正規化されていない人の一人です。彼の出発点は非正規化（「非正規化」として偽装された）ものであり、単純にDimension-Factモデルに実装しました。
もちろん、パフォーマンスを得るには、彼はさらに「非正規化」し、さらに複製を作成し、それをすべて正当化する必要がありました。
したがって、統合失調症のような方法で、非正規化された構造を「非正規化」することは、より専門的なコピーを作成することによって「読み取りパフォーマンスを向上させる」ことは事実です。全体が考慮されている場合は当てはまりません。外ではなく、その小さな庇護の内部でのみ真実です。
同様に、すべての「テーブル」がモンスターである場合、その奇妙な方法で、「結合は高価」であり、回避する必要があることは事実です。彼らは小さなテーブルやセットを結合する経験をしたことがないので、より小さなテーブルがより速いという科学的事実を信じることはできません。
作成重複する「テーブル」の方が速いという経験があるため、削除する重複がそれよりも速いとは信じられません。
彼の次元は、正規化されていないデータに追加です。データは正規化されていないため、ディメンションは公開されていません。正規化モデルでは、ディメンションは既に公開されていますが、データの不可欠な部分として、追加は必要ありません。
舗装されたキンボールズの道は崖へと続き、そこではより多くのレミングがより早く彼らの死に落ちます。レミングスは群れの動物であり、彼らが一緒に道を歩いていて、一緒に死んでいる限り、彼らは幸せに死ぬ。レミングスは他の経路を探しません。
すべての単なる物語、一緒にたむろしてお互いをサポートする1つの神話の一部。
あなたの使命
それを受け入れることを選択する必要があります。自分で考え、科学と物理法則に矛盾する考えを楽しませるのをやめてください。それらがどれほど一般的、神秘的、または神話的であるかに関係なく。信頼する前に、何かの証拠を求めてください。科学的になり、自分自身の新しい信念を検証します。 「パフォーマンスのために非正規化」というマントラを繰り返しても、データベースが高速になるわけではありません。データベースについて気分が良くなるだけです。サイドラインに座っている太った子供が彼がレースのすべての子供よりも速く走ることができると自分に言っているように。
- その上で、「OLTPの正規化」という概念でさえ反対ですが、「OLAPの非正規化」という概念は矛盾しています。物理法則は、あるコンピューターでは述べられているように機能しますが、別のコンピューターでは逆に機能しますか？心が揺れる。すべてのコンピューターで同じように作業することは不可能です。
質問？
非正規化と集計は、データウェアハウスでパフォーマンスを達成するために使用される2つの主要な戦略です。読み取りパフォーマンスが向上しないことを示唆するのは愚かです！きっと私はここで何かを誤解したに違いありませんか？
Aggregation： 10億の購入を保持するテーブルを考えます。購入金額の合計が1行のテーブルと比較してください。今、どちらが速いですか？ 10億行のテーブルからsum（amount）を選択するか、1行のテーブルから金額を選択しますか？もちろんこれはばかげた例ですが、集計の原理を非常にはっきりと示しています。なぜそれが速いのですか？使用する魔法のモデル/ハードウェア/ソフトウェア/宗教に関係なく、100バイトを読み取る方が100ギガバイトを読み取るよりも速いためです。そのような単純な。
非正規化：小売データウェアハウスの一般的な製品ディメンションには、列のシットロードがあります。一部の列は「名前」や「色」などの簡単なものですが、階層などの複雑なものもあります。複数の階層（製品範囲（5レベル）、意図したバイヤー（3レベル）、原材料（8レベル）、製造方法（8レベル）、および平均リードタイムなどの計算された数値（年の初めから） 、重量/パッケージングの測定など。
select product_id
from table1
join table2 on(keys)
join (select average(..)
from one_billion_row_table
where lastyear = ...) on(keys)
join ...table70
where function_with_fuzzy_matching(table1.cola, table37.colb) > 0.7
and exists(select ... from )
and not exists(select ...)
and table20.version_id = (select max(v_id from product_ver where ...)
and average_price between 10 and 20
and product_range = 'High-Profile'
...非正規化モデルの同等のクエリより高速です：
select product_id
from product_denormalized
where average_price between 10 and 20
and product_range = 'High-Profile';
どうして？一部には、集約シナリオと同じ理由があります。ただし、クエリが「複雑」になっているだけでもあります。これらは非常に複雑で、オプティマイザ（そして今はOracleの詳細）が混乱し、実行計画をめちゃくちゃにしています。クエリが少量のデータを処理する場合、次善の実行プランはそれほど大きな問題ではない可能性があります。しかし、ビッグテーブルに参加し始めるとすぐに、データベースが実行プランを正しく取得するのは重要です。単一の合成キーを使用して1つのテーブルのデータを非正規化すると（ヘク、なぜこの進行中の火に燃料を追加しないのですか）、フィルターは事前に調理された列の単純な範囲/等式フィルターになります。データを新しい列に複製すると、オプティマイザが選択性を推定し、適切な実行計画を提供するのに役立つ列の統計を収集できます（まあ、...）。
明らかに、非正規化と集計を使用すると、スキーマの変更に対応することが難しくなりますが、これは悪いことです。一方、読み取りパフォーマンスを提供するのは良いことです。
それで、読み取りパフォーマンスを達成するためにデータベースを非正規化する必要がありますか？地獄！それはあなたのシステムに非常に多くの複雑さを加え、あなたが配達する前にそれがあなたをねじ込む方法に終わりがありません。その価値はありますか？はい、特定のパフォーマンス要件を満たすために実行する必要がある場合があります。
更新1
PerformanceDBA：1行が1日に10億回更新される
これは、（ほぼ）リアルタイムの要件を意味します（これにより、まったく異なる技術要件のセットが生成されます）。多くの（ほとんどではないにしても）データウェアハウスには、その要件はありません。集約が機能する理由を明確にするために、非現実的な集約の例を選択しました。ロールアップ戦略についても説明したくありませんでした:)
また、データウェアハウスの一般的なユーザーと下敷きの一般的なユーザーのニーズを対比する必要がありますOLTPシステム。どの要素が輸送コストを押し上げているのかを理解しようとしているユーザーは、気にすることができませんでした今日のデータの50％が欠落している場合、または10台のトラックが爆発して運転手が死亡した場合は少なくなります。2年分に相当するデータを分析しても、最新の情報があったとしても、同じ結論が得られます。彼の処分で。
これを、そのトラックのドライバー（生き残ったドライバー）のニーズと比較してください。いくつかの愚かな集約プロセスが終了しなければならないという理由だけで、彼らはいくつかの通過点で5時間待つことができません。データの2つの別個のコピーがあると、両方のニーズが解決されます。
運用システムとレポートシステムで同じデータセットを共有する場合のもう1つの大きなハードルは、リリースサイクル、Q＆A、展開、SLAと何が違うか）が大きく異なることです。ここでも、2つの個別のコピーはこれを扱いやすくします。
「OLAP」とは、意思決定支援に使用されるサブジェクト指向のリレーショナル/ SQLデータベース、別名データウェアハウスを意味することを理解しています。
通常の形式（通常は5番目/ 6番目の標準形式）は、データウェアハウスの最適なモデルです。データウェアハウスを正規化する理由は、他のデータベースとまったく同じです。冗長性を減らし、潜在的な更新異常を回避します。組み込みのバイアスを回避するため、スキーマの変更と新しい要件をサポートする最も簡単な方法です。データウェアハウスで正規フォームを使用すると、データの読み込みプロセスをシンプルで一貫したものにすることもできます。
「従来の」非正規化アプローチはありません。優れたデータウェアハウスは常に正規化されています。
読み取りパフォーマンスのためにデータベースを非正規化しないでください。
わかりました、「あなたのマイレージは変化するかもしれません」、「それは依存します」、「すべてのジョブに適切なツールを使用する」、「1つのサイズはすべてに適合しない」という答えと、「それを修正しないでください」のビットの合計です。壊れていない」
非正規化は、特定の状況でクエリのパフォーマンスを向上させる1つの方法です。他の状況では、実際にパフォーマンスが低下する可能性があります（ディスクの使用量が増えるため）。それは確かに更新をより困難にします。
パフォーマンスの問題が発生した場合にのみ検討する必要があります（正規化の利点を提供し、複雑さを導入しているため）。
非正規化の欠点は、決して更新されない、またはバッチジョブでのみ更新される、つまりOLTP data。
非正規化によって解決する必要のあるパフォーマンスの問題が解決され、侵襲性の低い手法（インデックスやキャッシュ、またはより大きなサーバーの購入など）で解決できない場合は、そうすべきです。
まず私の意見、次にいくつかの分析
意見
Wordの非正規化の一般的な使用には、通常のフォームの破壊だけでなく、システムへの挿入、更新、削除の依存関係の導入も含まれることが多いため、非正規化はデータの読み取りに役立ちます。
これは、厳密に言えば、falseです。これを参照してください question/answer 、厳密な意味での非正規化は、通常の1NF-6NFからのフォーム、その他の挿入、更新、削除の依存関係は 直交設計の原則 で対処されます。
つまり、人々は 空間と時間のトレードオフの原則 を採用し、冗長性という用語（非正規化に関連付けられていますが、それとは等しくありません）を思い出して、メリットがあると結論付けます。これは不完全な意味合いですが、誤った意味合いでは逆を結論付けることはできません。
正常な形式を壊すかもしれませんが確かにスピードアップします一部データの取得（以下の分析の詳細）が、原則として同時：
- 特定のタイプのクエリのみを優先し、他のすべてのアクセスパスを遅くする
- システムの複雑さを増す（データベース自体のメンテナンスに影響するだけでなく、データを消費するアプリケーションの複雑さも増す）
- データベースの意味の明確性を難読化し、弱める
- データベースシステムの主要なポイント。問題空間を表す中央データは事実を記録する際に公平であるため、要件が変更されても、実際には独立しているシステムの部分（データとアプリケーション）を再設計する必要はありません。この人為的な依存関係を実行できるようにするには、最小限にする必要があります。1つのクエリを高速化するという今日の「重要な」要件は、ごくわずかに重要になることがよくあります。
分析
それで、私はときどき破壊正規形が検索に役立つと主張しました。いくつかの引数を与える時間
1）1NFを破る
6NFに財務記録があるとします。そのようなデータベースから、あなたは確かに毎月の各アカウントの残高についてのレポートを得ることができます。
そのようなレポートを計算する必要があるクエリがnレコードを通過する必要があると仮定すると、テーブルを作成できます
account_balances(month, report)
各アカウントのXML構造化残高を保持します。これは1NFを壊します（後述の注記を参照）が、特定のクエリを最小I/Oで実行できます。
同時に、財務レコードの挿入、更新、または削除で任意の月を更新できると仮定すると、システム上の更新クエリのパフォーマンスは、neach update。 （上記のケースは原則を示していますが、実際にはより良いオプションがあり、最小限のI/Oを取得することのメリットは、実際にデータを頻繁に更新する現実的なシステムでは、実際のワークロードのタイプ。必要に応じてこれについて詳しく説明できます）
注：これは実際には些細な例であり、1つの問題があります-1NFの定義です。上記のモデルが1NFを破るという仮定は、属性の値（に、該当するドメイン）の値が1つだけ含まれているという要件に従っています。
これにより、属性レポートのドメインはすべての可能なレポートのセットであり、それらすべてから1つの値があり、1NFは壊れていないと主張できます（単語を保存しても1NFは壊れないという引数と同様）モデルのどこかにletters関係がある可能性があります）。
一方、このテーブルをモデル化する方法ははるかに優れています。これは、クエリの範囲が広い場合（1年のすべての月の単一アカウントの残高を取得する場合など）に役立ちます。この場合、このフィールドは1NFにないことを言って、その改善を正当化します。
とにかく、NFを壊すことでパフォーマンスが向上すると人々が主張する理由を説明しています。
2）Breaking 3NF
3NFのテーブルを想定
CREATE TABLE `t` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`member_id` int(10) unsigned NOT NULL,
`status` tinyint(3) unsigned NOT NULL,
`amount` decimal(10,2) NOT NULL,
`opening` decimal(10,2) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `member_id` (`member_id`),
CONSTRAINT `t_ibfk_1` FOREIGN KEY (`member_id`) REFERENCES `m` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB
CREATE TABLE `m` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB
サンプルデータあり（tに100万行、mに100k行）
改善したい一般的なクエリを想定する
mysql> select sql_no_cache m.name, count(*)
from t join m on t.member_id = m.id
where t.id between 100000 and 500000 group by m.name;
+-------+----------+
| name | count(*) |
+-------+----------+
| omega | 11 |
| test | 8 |
| test3 | 399982 |
+-------+----------+
3 rows in set (1.08 sec)
属性nameをテーブルmに移動する提案を見つけることができます。これにより、3NFが壊れます（FDにはmember_id-> nameがあり、member_idはtのキーではありません）。
後
alter table t add column varchar(255);
update t inner join m on t.member_id = t.id set t.name = m.name;
ランニング
mysql> select sql_no_cache name, count(*)
from t where id
between 100000 and 500000
group by name;
+-------+----------+
| name | count(*) |
+-------+----------+
| omega | 11 |
| test | 8 |
| test3 | 399982 |
+-------+----------+
3 rows in set (0.41 sec)
注：上記のクエリ実行時間は半分にカットされますが、
- テーブルはもともと5NF/6NFにはありませんでした
- テストはno_sql_cacheを使用して行われたため、ほとんどのキャッシュメカニズムは回避されました（実際の状況では、システムのパフォーマンスに影響します）。
- スペース消費は、列名のサイズの約9倍x 100k行増加します。
- データの整合性を維持するためにtにトリガーが必要です。これにより、名前へのすべての更新が大幅に遅くなり、tに挿入する必要がある追加のチェックが追加されます。
- おそらく、より良い結果は、代理キーを削除して自然キーに切り替えるか、インデックスを作成するか、またはより高いNFに再設計することによって達成できます。
正規化は長期的には適切な方法です。ただし、会社のERP（たとえば、ほとんどが3NFにすぎない）など）を再設計するオプションが常にあるとは限りません。特定のリソース内で特定のタスクを達成する必要がある場合もあります。 「ソリューション」という用語。
ボトムライン
あなたの質問に対する最も適切な答えは、「非正規化」という用語を使用して業界と教育を見つけることだと思います
- 厳密な意味、breaking NFs
- 大まかに、の挿入、更新、削除の依存関係の紹介（-===-）（元のCoddの引用コメント正規化についてのコメント： 'undesirable（！）挿入、更新、削除の依存関係'、詳細を参照 こちら ）
したがって、厳密な定義の下では、集計（集計テーブル）は非正規化とは見なされず、パフォーマンスの点で非常に役立ちます（非正規化として認識されないキャッシュと同様）。
緩やかな使用法には、前述のように、正規形と直交計画の原理 の両方が含まれます。
もう少し光を放つかもしれないことは、論理モデルと物理モデルの間に非常に重要な違いがあるということです。
たとえば、インデックスは冗長なデータを格納しますが、非正規化とは誰も考えていません。この用語を大まかに使用している人々でさえ、この2つの理由（関連）があります
- それらは論理モデルの一部ではありません
- それらは透明であり、モデルの整合性を壊さないことが保証されています
論理モデルを適切にモデル化できないと、データベースの一貫性が失われます-エンティティ間の関係のタイプが正しくなくなり（問題のスペースを表現できない）、事実の矛盾（情報が失われる可能性があります）。正しい論理モデルです。これは、その上に構築されるすべてのアプリケーションの基盤です。
述語の正規化、直交で明確なセマンティクス、明確に定義された属性、正しく識別された機能の依存関係はすべて、落とし穴を回避するうえで重要な役割を果たします。
物理的な実装に関して言えば、非キーに依存している実体化された計算列が3NFを壊す可能性があるという意味で、物事はより緩和されますが、一貫性を保証するメカニズムがあれば、インデックスと同じように物理モデルで許可されますは許可されますが、非常に注意深く正当化する必要があります。通常、正規化すると、全体にわたって同じまたはより良い改善が得られ、悪影響がまったくないか少なくなり、デザインが明確に保たれるためです（これにより、アプリケーションの開発とメンテナンスのコストが削減されます。その結果、ハードウェアのアップグレードに簡単に費やすことができ、NFを壊すことで達成される速度をさらに向上させることができます。
データウェアハウス（DW）を構築するための最も一般的な2つの方法は、Bill InmonとRalph Kimballのようです。
Inmonの方法論は正規化されたアプローチを使用し、Kimballは次元モデリング-非正規化されたスタースキーマを使用します。
どちらも細かいところまで文書化されており、多くの実装が成功しています。どちらも、DWの目的地への「広く舗装された道路」を示しています。
6NFアプローチやアンカーモデリングについてはコメントできません。その方法論を使用したDWプロジェクトを見たことも、参加したこともないためです。実装に関しては、十分にテストされたパスをたどるのが好きですが、それは私だけです。
つまり、要約すると、DWは正規化されるのか、それとも非正規化されるのか？あなたが選ぶ方法論に依存します-少なくともプロジェクトの終わりまで、1つを選んでそれに固執するだけです。
EDIT-例
私が現在働いている場所では、本番サーバーでこれまでから実行されているレガシーレポートがありました。単純なレポートではありませんが、毎日30のサブレポートのコレクションが全員と彼のアリに電子メールで送信されました。
最近、DWを実装しました。 2つのレポートサーバーと多数のレポートが用意されているので、レガシのことは忘れられることを期待していました。しかし、そうではありません。レガシーはレガシーです。私たちは常にそれを持っているので、それが欲しい、それが必要、それなしでは生きられない、などです。
問題は、pythonスクリプトとSQLの混乱が毎日実行するのに8時間（そう、8時間）かかったことです。言うまでもなく、データベースとアプリケーションは数バッチの開発者によって数年-つまり、まさに5NFではありません。
DWからレガシーのものを再作成するときがきました。わかりました。短くしておくと、完了し、作成に3分（t-h-r-e-e分）かかります（サブレポートごとに6秒）。そして、私は提供を急いでいたため、すべてのクエリを最適化することさえしませんでした。これは、8 * 60/3 = 160倍高速です。実稼働サーバーから8時間のジョブを削除することの利点は言うまでもありません。私はまだ1分かそこらを剃ることができると思いますが、今のところ誰も気にしません。
興味深い点として、私はDWにキンボールの方法（次元モデリング）を使用しており、このストーリーで使用されているものはすべてオープンソースです。
これは、このすべて（データウェアハウス）が想定されていることだと思います。使用された方法論（正規化または非正規化）も問題になりますか？
EDIT 2
興味深い点として、ビル・インモンは彼のウェブサイトに上手に書かれた論文を掲載しています-2つのアーキテクチャの物語。
「非正規化」という言葉の問題は、それが進むべき方向を指定していないことです。それは、ニューヨークから車でシカゴからサンフランシスコに行こうとするようなものです。
スタースキーマまたはスノーフレークスキーマは、正規化されていません。また、特定の使用パターンでは、正規化されたスキーマよりもパフォーマンスが優れています。しかし、非正規化のケースでは、デザイナーがまったく規律に従わず、直感的にテーブルを作成するだけでした。時々それらの努力はうまくいかない。
つまり、単に非正規化しないでください。その利点に自信がある場合、および正規化された設計に同意しない場合でも、別の設計規則に従ってください。しかし、不規則な設計の言い訳として非正規化を使用しないでください。
短い答えはこれまでにないパフォーマンスの問題を修正しないでください！
時間ベースのテーブルについては、一般に受け入れられている枠組みは、すべての行にvalid_fromおよびvalid_toの日付を含めることです。これは、セマンティクスを「これはこのエンティティーの唯一かつ唯一のバージョン」から「これはこのエンティティーの唯一かつ唯一のバージョンです」に変更されるため、基本的には3NFのままです現時点 "
簡素化：
OLTPデータベースは（意味のある限り）正規化する必要があります。
OLAPデータウェアハウスは、ファクトテーブルとディメンションテーブルに非正規化する必要があります（結合を最小限にするため）。