問題タブ [dimensional-modeling]

Sales というファクトを持ち、Product ディメンションにリンクされたセールス分析用のディメンション モデルを構築しています。

ポイントは、製品の在庫が日ごとに変化することです。この情報は、特定の製品が販売されなかった理由を分析するために重要です (たとえば、XX/XX 日に製品 123456 が販売されなかったのは、製品が販売されていないためです)。インベントリにあります)。

この状況をモデル化するための最良のオプションと、可能であればそれがどのように機能するかについての簡単な説明を知りたいです。

前もって感謝します！

これが私がやろうとしていることです: 次のような典型的な列を持つ典型的な販売ファクトテーブルがあるとしましょう:

ここで、単純に、Amount を合計して、次のように Region に対してロールアップできます。

しかし、次のように別の方法で使用したい場合はどうすればよいでしょうか。

それは、定量的な事実を次元として扱い、その逆を意味するのではないでしょうか? しかし、どうすればメジャーをディメンションに変換できますか?

正しい方向へのプッシュは大歓迎です。

SSAS OLAP キューブのデータ ソースとして、次の (簡略化された) スター スキームを使用しています。

私の立方体には、メジャー [Days] があります。これには、各日付に「1」が含まれているだけです。これは、ある期間の日数を取得するための適切な方法であり、毎日の平均などを計算するのに役立ちます。明らかに、このメジャーはショップ次元と従業員次元の両方とは無関係です。

たとえば、次の MDX クエリを使用するとします。

これは、2014 年 6 月の売上高と 6 月の日数を含む、米国内のすべてのショップのリストを返します。期待どおりに動作し、パフォーマンスは素晴らしいです。

ここで、同じリストが必要であるとしますが、ショップに加えて、売上高を従業員ごとに分割したいとします。当然のことながら、従業員の次元とショップの次元を交差させます。

これには 2 つの問題があります。まず、これら 2 つの (潜在的に) 大きな次元を超えると、パフォーマンスが大幅に低下します。NULL第 2に、アメリカのショップと提携していないすべての従業員について、Sales Amount = のレコードをたくさん取得します。[Days] メジャーを削除すると、期待どおりの結果が得られますが、毎日の平均などにはそのメジャーが必要です。

この問題を回避するために、キューブをモデル化する別の方法を探しています。つまり、Shop-dimension でファクト テーブルをフィルター処理すると、表示されている Employee-dimension からの関連レコードのみが必要になります (Employee と Shop ディメンションはファクト テーブルを介して関連付けられているため、この記事のタイトルです)。

Shop と Employee ディメンションを 1 つの "organization" ディメンションに結合することを検討しましたが、これには複数の問題が生じます。

注: 私のエンドユーザーは、生成された MDX を制御できないさまざまなフロントエンド ツールを使用しているため、別の MDX ソリューションを探しているわけではありません。私が見ているように、この問題はフロントエンドではなく、多次元モデリングで解決する必要があります。モデリング手法と文献への参照は非常に高く評価されます。

私は SSAS を使い始めたばかりで、何年にもわたる四半期ごとの特定の年齢範囲の人々の数のグラフを作成できるデータ キューブを作成しようとしています。たとえば、次のようになります。

ここで、# は 10 ～ 20 歳、@ は 20 ～ 30 歳、$ は 30 ～ 40 歳です。

私が見つけた問題は、2010 年には誰かが 29 歳だった可能性があるため、20 歳から 30 歳の範囲に分類されることですが、2014 年には同じ人を 30 歳から 40 歳の範囲に数えたいと考えています。 33. 日付と時間に依存するディメンションを作成する方法がわかりません (または作成できるかどうかもわかりません)。

I have a fact table with 100 millions+ rows and with 4 dimensions and everything works fine from query performance point of view and from processing cube perspective (~it takes around 5-6 minutes to process the cube).

1/ Now I have to add a new dimension with 6 millions rows. The cube processing time will explode?

2/ Is that a good practice? Do I have other alternatives to model this dimension?

3/ What about if my fact table raises to 300 millions rows and my dimension to 15 millions rows?

Any thought is welcome. Thanks in advance.

MS が生成した日付ディメンションではなく、独自の日付ディメンションを使用しています。次のようなテーブル構造があります。

作成された階層: 年、四半期、月、月の日

関係: DateDim->DayOfMonth->Month->Quarter->Year

用に作成された複合キー

ただし、これを作成して処理した後、年、四半期、月、日を取得しますが、それぞれに関連付けられている FullDate は「月の日」レベルでのみ関連付けられているようです。実際の日付は、階層には関係ありません。途中で何かが欠けているに違いないことはわかっていますが、何が間違っているのかわかりません。

冗長な関係を作成したり、列を複製したりせずに、これを適切に設定する方法についての指針はありますか? (前者が不適切であることは承知しています)

キューブを設計する際に提案が必要です。これが私のシナリオです。製品、会社、販売などの 3 つのテーブルがあります。製品テーブルには、各月の各製品の意味を表す各月の製品に関する詳細が含まれており、このテーブルに記録されます。同様に、company テーブルには、各月の会社に関する詳細が保持されます。Sales テーブルには、各月の売上に関する詳細が保持されます。

そして、私は簡単な時間次元のテーブルを持っています。このテーブルを使用して、キューブのディメンションおよびファクトとして機能するビューを作成する予定です。上記のシナリオから、Sales ビューをキューブの Fact として扱うことができ、Id と Month 列を使用して Product と Company テーブルに接続できます。私の質問は、このデータ モデルからディメンションを設計するにはどうすればよいですか? 製品と会社はディメンションとして扱うことができますか? もしそうなら、キューブで関係を指定する方法を教えてください。このデータ モデルを使用してキューブを作成することはできますか? お知らせ下さい。あなたの助けは非常に高く評価されます。ありがとうございました。