私は現在、次元モデリング アプローチを大まかに利用してウェアハウス スキーマに取り組んでいます。
一般的な考え方は、最小レベルの粒度で、関心のあるイベント メトリックでいっぱいの単一のファクト テーブルを持つことです。これに加えて、もちろん、記録されているイベントの次元が保持される次元テーブル(a)になります。これらのテーブルはdimension_id.
私の質問は、何かがディメンションとメトリックの両方になることは可能ですか、それとも理にかなっていますか?
例としては、検索結果での製品の位置が考えられます。特定の製品の位置は、メトリックと見なすことができます。ユーザーは、製品に対して次のクエリを実行できます。
ディメンション x = y の商品が先週表示された平均掲載順位は?
同時に、位置自体を次元と見なすこともできます。
先月の掲載順位 = 2 のすべての商品のクリック率を表示
データ ウェアハウスでこのような問題に取り組む正しい方法は何ですか (違いが生じる場合は、列指向のソリューションを検討しています)。
どちらの場合も、実際にはメジャーに対してクエリを実行しているだけのようです
先月の順位 = 2 の商品
これを生成する方法について考えると、これは、その場でファクト テーブルから製品の正しいリストを生成し、外部のファクト クエリをこれらの製品に限定することによって導き出すことができます。
カスタム SQL を実行している有能なアナリストがいる場合はこれで問題ありませんが、技術アナリスト以外がこれまで使用したレポート ツールでこれを構築するのははるかに困難です。
また
属性としての自分の位置をゆっくりと変化する次元に「固める」ことができます。しかし、急速に変化するデータの場合、これは通常オプションではありません...次元が非常に速く変化するため、実用的ではありません。
必要な分析期間を 1 か月に結び付けることができる場合、月次評価 (およびローリング期間タイプの属性を含む他の多くの属性) をゆっくりと変化するディメンションに実装することが実用的である可能性があります。これは、少なくとも 12 個の製品ディメンションがあることを意味します。しかし、考えられるすべての実際の KPI をディメンションの列にまとめることができます。これは通常、非常に役立ちます。
しかし、これはあなたにとって新しいことではないと思います。