1

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

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

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

SELECT { [SalesAmount], [Days] } on 0,
    { [Shop].[Shop].[Shop].members } on 1
FROM
    [MyCube]
WHERE
    ( [Shop].[Country].[USA], [Calendar].[Month].&[201406] )

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

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

SELECT { [SalesAmount], [Days] } on 0,
    { [Shop].[Shop].[Shop].members * 
      [Employee].[Employee].[Employee].members } on 1
FROM
    [MyCube]
WHERE
    ( [Shop].[Country].[USA], [Calendar].[Month].&[201406] )

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

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

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

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

4

2 に答える 2