join - スター スキーマで複雑な結合を回避するにはどうすればよいですか?

Question

私のファクト テーブルには、彼が受講したコースのユーザー スコアが保持されます。レポートに表示する必要があるコースの詳細の一部は、複数のテーブル (実際の OLTP データベース内) から取得されます。
そのコース エントリの正規化されていないバージョンをディメンション テーブルに作成する必要がありますか?
または、ファクト テーブルをコース テーブルに直接結合するだけですか?このコースを説明する他のテーブルに結合します (course_type、このコースを作成した学部など)。

Answer 1

スノーフレークまたはブリッジテーブルは、結合をより複雑にし、コーディングの観点からだけでなく、BIユーザーにとっても単純ではなくなります。

ほとんどの場合、これらを既存または追加のディメンションテーブルに直接配置します。

たとえば、スコアファクトテーブルがあります。このテーブルには、ユーザーの人口統計を保持している場合と保持していない場合があるディメンションにユーザーの詳細が含まれています（おそらくそれは単なるブリッジです）。人口統計情報を分割する方がよい場合もあります。したがって、性別と年齢がユーザーエンティティに関連付けられている場合でも、ディメンションモデルでは、これらは個々のディメンションであるか、単一のディメンションにまとめられている可能性があります。これらはすべて、使用シナリオによって異なります。

おそらく、あなたのスコアは州に添付されており、州には地域（スノーフレーク）があります。状態ディメンションを経由するのではなく、領域ディメンションを直接リンクする方が、分析にとってはるかに効率的である可能性があります。

次元モデルは非常に実用的な非正規化アプローチであることがわかります。交渉不可能な主なことは、事実です。その後、ディメンションの選択は、データの動作、一般的な使用シナリオに対する先見性によって非常に多くの情報が得られ、ディメンションが少なすぎたり多すぎたりする問題に陥らないようにします。

Answer 2

質問が理解できないかもしれませんが、スター スキーマ内のファクト テーブルは、それを囲むディメンション テーブルに結合されることになっています。結合したくない場合は、単純にビューを作成し、そのビューをレポートに使用してください。

モデル（スキーマ）を投稿すると、コメント/ヘルプが簡単になります。

Answer 3

パフォーマンスを優先して正規化を犠牲にして、いくつかのディメンションを統合するのが一般的な方法です。これは通常、通常のクエリですべてのディメンションが一緒に必要になる場合に実行されます（ユースケースごとに異なるビットを使用するのではありません）。

また、結合のオーバーヘッドが削減されますが、いくつかの欠点があることにも注意してください。

• 柔軟性の喪失。倉庫が拡張するにつれて開発が妨げられる可能性があります
• 全表スキャンには時間がかかります（SQL Serverなどの従来の行ベースのRDBMSでは）
• ディスクスペースの消費

それぞれのケースを個別に検討する必要があります。

RDBMSによってそのような機能が提供されている場合は、マテリアライズド・ビューを作成するオプションも検討する価値があるかもしれません。

Answer 4

通常、物理 DWH 設計としてスノーフレーク スキーマがありますが、スノーフレーク スキーマをスター スキーマにフラット化するレポート ビュー レイヤーを追加します。

このようにして、OLAP キューブはよりシンプルになり、管理が容易になります。