次元モデリングまたはスター スキーマに関する洞察が必要です。
通常、データ ウェアハウスを設計するときは、ファクト テーブルとディメンション テーブルを用意します。
ただし、ディメンションをファクト テーブルに埋め込むことには意味があります。特に、他の属性を持たず、ほとんど値を変更しない単純なディメンションの場合。
実際のテーブルにディメンションがあると、クエリが非常に高速に実行され、ディメンション テーブルを個別に維持する必要がなくなり、ETL を実行するときにディメンション テーブルを検索する必要がなくなります。
次元を事実から分離しておく考慮事項はありますか?
ファクトにはたくさんの行があります。たとえば、ファクトに長さ 20 の属性を配置すると、INT代理キー (4 バイト) だけを格納する場合よりも多くのストレージが必要になります。ストレージが増える = テーブルが大きくなる = パフォーマンスが低下します。
ほとんどの場合、特定の属性に対して他の階層と属性を格納する必要があります。今はしていなくても、将来はしたくなるかもしれません
通常、レポートでは、これらの属性のリストがドロップダウンに表示され、フィルターで絞り込むことができます。これらを事実からどのように引き出すのですか？SELECT DISTINCT非常に大きなテーブルで、インデックスなしでは高価です。インデックスを使用すると、読み込みのパフォーマンスに影響します。
事実ではなく次元に物事を入れる場合、それがビジネスにどのように適合するかについて何らかの分析を行ったことを意味します