データウェアハウジング-スタースキーマとフラットテーブル
私は、ファイナンスシステム、プロジェクトスケジューリングシステム、無数の科学システムなど、一般的に必要とされるデータの単一ストア用にデータウェアハウスを設計しようとしています。つまり多くの異なるデータマート。
私はデータウェアハウジングと、スタースキーマやキンボール法などの一般的な方法について読んでいますが、答えが見つからない質問の1つは次のとおりです。
DWデータマートを単一のフラットテーブルではなくスタースキーマとして設計する方が良いのはなぜですか？
ファクトと属性/ディメンションの間に結合がないことは、すべてのディメンションテーブルに多数の小さな結合があるよりも速くて簡単ですか？ディスク容量は問題ではありません。必要に応じて、データベースにディスクを追加します。スタースキーマは最近少し古くなっていますか、それともデータアーキテクトの教義ですか？
あなたの質問はとても良いです。次元モデリングのキンボールのマントラは、パフォーマンスを向上させ、使いやすさを向上させることです。
しかし、私はそれが古くなっているとは思いません。あるいは、それは多くの状況やプラットフォームにとって合理的で実用的なアプローチです。
リレーショナルDBがデータを格納する方法は、テーブルの数とタイプ、一般的なクエリのデータへのルート、データ間の関係の簡単な保守性と説明、結合の数、結合の方法の間でバランスを取る必要があることを意味します列のインデックス可能性などが構築されます。
3NF（またはそれ以上）はスペクトルの一方の端であり、OLTPシステムに適しています。1つのテーブルがスペクトルのもう一方の端です。ディメンションモデルは中間にあり、少なくともレポートに適しています。特定のテクノロジーを使用する場合。
スタースキーマは完全に正規化されたデータベースよりもレポートワークロードのパフォーマンスが優れていますが、結合の数が減ったことも一因です。通常、寸法は非常に広いです。すべてのファクトのすべての行にこれらすべてのディメンションフィールドを含める場合、実際には非常に大きな行があり、それらの行への道を見つけると、一般的なクエリのパフォーマンスが非常に悪くなります。
事実は数多くあるため、これらのテーブルをコンパクトにして、「ワード」のディメンションをフィルタリングできるようにすると、高度にインデックスを作成しない限り、単一のテーブルが一致しないパフォーマンスのスイートスポットに到達します。
そしてはい、ファクトの単一のテーブルはテーブルの数の点でより単純ですが、ナビゲートするのは本当に簡単ですか？ディメンションとファクトは理解しやすい概念です。ファクト間でクエリをクロスさせたい場合はどうでしょうか。多くの異なるデータマートがありますが、最初にデータウェアハウスを使用する利点の1つは、これらが区別されないことです。これらは関連しており、全体にわたってレポートできます。適合寸法はこれを可能にします。
ファクトとディメンションを1つのテーブルに結合すると、使用されていないディメンション属性の可視性が失われるか、未使用のディメンション属性のダミーイベントが含まれることにより、メジャーが破棄されます。
たとえば、レストランのメニューは次元であり、購入した食品は事実です。これらを1つのテーブルにまとめた場合、注文されたことのない食品をどのように特定しますか？そのため、最初の注文の前に、メニューで利用可能な食べ物をどのように識別しましたか？
次元は可能性を表し、事実は可能性の実現を表します。
同じテーブルでファクトとディメンションを組み合わせると、スケーラビリティと柔軟性が制限されます。
ある日、企業がディメンションの説明（たとえば、製品名）を変更することにしたとします。ディメンションテーブルはファクトテーブルほど深くはありません。更新プロセスまたはSCD管理はより簡単で、リソース集中型ではありません。