独自の特性を持つ対策に関するアドバイス
メジャーのプロパティの数が増えている場合にデータベースをモデル化する方法についてのアドバイスを探しています。その値は、それ自体がディメンションと見なすことができます。
単純化したケースでは、StateIdとSalesがあるとしましょう。
StateId Sales
----------------
1 20
2 25
次に、どのタイプのメジャー「Sales」、それが含まれる必要があるカスタムグループ、および集計ルールに関する情報を保存する必要があります。
これをモデル化するための良い方法は何でしょうか？タイプとグループを含む他のディメンションにリンクするメジャーテーブルを作成できます。
Id Name TypeId GroupId Agg
-----------------------------------
1 Sales 1 5 Sum
ただし、実際のディメンションに関連するものか、メジャーに関連するものかを問わず、ディメンションのタイプを保存する必要があります。
メジャーのメタデータを保存する問題を他の人がどのように解決したかについて興味があります。
データベースに集計ルール（何に基づいてもかまいません）を入れたいようです。特に問題はありませんが、ただし SQLを動的に生成するために使用することを計画している場合を除きます。これは滑りやすい表面です。SQLの方がはるかにデバッグしやすいので、注意して進めてください。
ユーザーは推定メジャーテーブルに追加できますか？そうでない場合は、静的 SQLをストアドプロシージャとして生成することを検討することをお勧めします。これは、人間にとってもクエリオプティマイザにとっても理解しやすいでしょう。
ISTMは、対策の特性がどうなるかまだよくわからないので、私もあなたの質問に少し不安を感じています。このような状況では、多くの場合、1ダースほどのユースケースが発生するまで待つのが最善です。その時点で、識別されたプロパティを使用して、実際に使用できる具体的なセットが作成されます。そうすれば、質問がそれ自体で答えられると私が期待することを十分に知っているでしょう。しかし、その多くのケースが発生しない場合でも、私は驚かないでしょう。その場合、メジャーの抽象化は、それが価値があるよりも多くの問題を証明し、偶然に回避されました。
HTH。