多対多リレーションシップと多対多リレーションシッププロパティを定義する。

2017-06-13

このトピックでは、Analysis Services の多対多ディメンションについて説明します。このディメンションの用途や作成方法について説明します。

イントロダクション

Analysis Services では多対多ディメンションがサポートされているため、従来のスタースキーマで記述できる分析よりも複雑な分析が可能になります。クラシックスタースキーマでは、すべてのディメンションにファクトテーブルとの一対多リレーションシップがあります。各ファクトは、1 つのディメンションメンバーに結合されます。1 つのディメンションメンバーは、多くのファクトに関連付けられています。

多対多では、ファクト (口座残高など) を同じディメンションの複数のメンバーに関連付けることで、このモデリングの制限を取り除きます (共同口座の残高は、共同口座の 2 人以上の所有者に帰属できます)。

概念的には、Analysis Services の多対多ディメンションリレーションシップは、リレーショナルモデルの多対多リレーションシップと同等であり、同じ種類のシナリオをサポートします。多対多の一般的な例を次に示します。

学生は多くのコースに登録されています。各コースには多くの学生がいます。
医師は多くの患者を持っています;患者は多くの医師を持っています.
顧客は多くの銀行口座を持っています。銀行口座は、複数の顧客に属している可能性があります。
Adventure Works では、多くのお客様が製品を注文する理由が多数あり、販売の理由は多くの注文に関連付けることができます。

分析的には、多対多リレーションシップで解決される問題は、ディメンションリレーションシップに対するカウントまたは合計の正確な表現です (通常は、特定のディメンションメンバーの計算を実行するときに二重カウントを排除します)。この点を明確にするには、例が必要です。複数のカテゴリに属する製品またはサービスについて考えてみましょう。サービスの数をカテゴリ別にカウントする場合は、両方のカテゴリに属するサービスを各カテゴリに含める必要があります。同時に、提供するサービスの数を過大評価する必要はありません。多対多ディメンションのリレーションシップを指定すると、カテゴリまたはサービス別にクエリを実行するときに、正しい結果が返される可能性が高くなります。ただし、これが当てはまることを確認するには、常に徹底的なテストが必要です。

構造上、多対多のディメンションリレーションシップを作成することは、リレーショナルデータモデルで多対多を作成する方法と似ています。リレーショナルモデルでは ジャンクションテーブル を使用して行の関連付けを格納しますが、多次元モデルでは 中間メジャーグループが使用されます。中間メジャーグループ（Intermediate Measure Group）は、異なるディメンションのメンバーをマッピングするテーブルを指す用語です。

視覚的には、多対多のディメンションリレーションシップはキューブダイアグラムには示されません。代わりに、[ディメンション使用法] タブを使用して、モデル内の多対多リレーションシップをすばやく識別します。多対多リレーションシップは、次のアイコンで示されます。

ディメンション使用での多対多アイコン

このボタンをクリックして [リレーションシップの定義] ダイアログボックスを開き、リレーションシップの種類が多対多であることを確認し、リレーションシップで使用されている中間メジャーグループを表示します。

ディメンション使用法における [リレーションシップの定義] ボタン

以降のセクションでは、多対多ディメンションを設定し、モデルの動作をテストする方法について説明します。追加情報を確認するか、最初にチュートリアルを試す場合は、この記事の最後にある 「詳細情報 」を参照してください。

多対多ディメンションを作成する

単純な多対多リレーションシップには、多対多カーディナリティを持つ 2 つのディメンション、メンバーの関連付けを格納するための中間メジャーグループ、および売上合計や銀行口座の残高などの測定可能なデータを含むファクトメジャーグループが含まれます。

多対多リレーションシップのディメンションは DSV に対応するテーブルを持つ場合があり、モデル内の各ディメンションはデータソース内の既存のテーブルに基づいています。逆に、モデル内のディメンションは、DSV 内の少数の物理テーブルまたは異なる物理テーブルから派生する場合があります。 Sales Reasons と Sales Orders をケースインポイントとして使用すると、Adventure Works サンプルキューブは、モデルのみのデータ構造として存在するディメンションを使用して、DSV に対応する物理ディメンションを使用しない多対多リレーションシップを示します。 Sales Order ディメンションは、基になるデータソースのディメンションテーブルではなくファクトテーブルに基づいています。

次の手順では、多対多リレーションシップに参加するエンティティが既にわかっていることを前提としています。詳しくはLearn Moreをご参照ください。

多対多リレーションシップの作成に使用する手順を示すために、この手順では Adventure Works サンプルキューブに多対多リレーションシップのいずれかを再作成します。リレーショナルデータベースエンジンインスタンスにソースデータ (Adventure Works サンプルデータウェアハウス) がインストールされている場合は、次の手順を実行できます。

手順 1: DSV リレーションシップを確認する

SQL Server Data Tools では、多次元プロジェクトで、SQL Server データベースエンジンインスタンスでホストされている Adventure Works DW 2012 リレーショナルデータウェアハウスへのデータソースを作成します。
次の既存のテーブルを使用してデータソースビューを作成します。
- FactInternetSales
- ファクトインターネット販売理由
- DimSalesReason（販売理由ディム）
多対多リレーションシップで使用する予定のすべてのテーブルが、主キーリレーションシップを介して DSV に関連付けられていることを確認します。これは、後続の手順で中間メジャーグループへのリンクを確立するための要件です。

注

基になるデータソースで主キーリレーションシップと外部キーリレーションシップが提供されない場合は、DSV でリレーションシップを手動で作成できます。詳細については、「データソースビューでの論理リレーションシップの定義 (Analysis Services)」を参照してください。

次の例では、この手順で使用するテーブルが主キーを使用してリンクされていることを確認します。

手順 2: データ分析のためのディメンションとメジャーグループを作成する

SQL Server データツールの多次元プロジェクトで、[ ディメンション ] を右クリックし、[ 新しいディメンション] を選択します。
既存のテーブル DimSalesReason に基づいて新しいディメンションを作成します。ソースを指定するときは、すべての既定値をそのまま使用します。

属性の場合は、すべて選択します。
既存のテーブル Fact Internet Sales に基づいて 2 番目のディメンションを作成します。これはファクトテーブルですが、販売注文情報が含まれています。これを使用して販売注文ディメンションを作成します。
[ソース情報の指定] に、[名前] 列を指定する必要があることを示す警告が表示されます。名前として SalesOrderNumber を選択します。
ウィザードの次のページで、属性を選択します。この例では、 SalesOrderNumber のみを選択できます。
ディメンションの名前を Dim Sales Orders に変更して、ディメンションの一貫した名前付け規則を使用できるようにします。
[キューブ] を右クリックし、[新しいキューブ] を選択します。
メジャーグループテーブル で、FactInternetSales と FactInternetSalesReason を選択します。

FactInternetSales にはキューブで使用するメジャーが含まれているため、 FactInternetSales を選択します。 FactInternetSalesReason を選択するのは、これが中間メジャーグループとして販売注文を販売理由に関連付けるメンバー関連データを提供するからです。
各ファクトテーブルの指標を選択します。

モデルを簡略化するには、すべてのメジャーをクリアし、一覧の下部にある Sales Amount と Fact Internet Sales Count のみを選択します。 FactInternetSalesReason はメジャーが 1 つだけなので、自動的に選択されます。
ディメンション一覧には、 Dim Sales Reason と Dim Sales Orders が表示されます。

[新しいディメンションの選択] ページで、 Fact Internet Sales Dimension の新しいディメンションを作成するように求められます。このディメンションは必要ないため、一覧から削除できます。
キューブに名前を付け、[完了] をクリック します。

手順 3: 多対多リレーションシップを定義する

キューブデザイナーで、[ディメンションの使用法] タブをクリックします。 Dim Sales Reason と Fact Internet Sales の間には、既に多対多のリレーションシップがあることに注意してください。次のアイコンは多対多のリレーションシップを示していることを思い出してください。
Dim Sales Reason と Fact Internet Sales の間の交差セルをクリックし、ボタンをクリックして [リレーションシップの定義] ダイアログボックスを開きます。

このダイアログボックスは、多対多リレーションシップを指定するために使用されていることがわかります。代わりに通常のリレーションシップを持つディメンションを追加する場合は、このダイアログボックスを使用して多対多に変更します。
Analysis Services 多次元インスタンスにプロジェクトをデプロイします。次の手順では、Excel でキューブを参照して動作を確認します。

多対多のテスト

キューブで多対多リレーションシップを定義する場合、クエリが期待される結果を確実に返すようにテストすることが不可欠です。エンドユーザーが使用するクライアントアプリケーションツールを使用して、キューブをテストする必要があります。この次の手順では、Excel を使用してキューブに接続し、クエリ結果を確認します。

Excel でキューブを参照する

プロジェクトをデプロイし、キューブを参照して集計が有効であることを確認します。
Excel で、[データ] | [その他のソース] | [Analysis Services から] の順にクリックします。サーバーの名前を入力し、データベースとキューブを選択します。
次を使用するピボットテーブルを作成します。
- 値としての売上金額
- 列の上のSales Reason Name
- 行にある販売注文番号
結果を分析する。サンプルデータを使用しているため、最初の印象は、すべての販売注文の値が同じであるという点です。ただし、下にスクロールすると、データのバリエーションが表示され始めます。

途中で、注文番号 SO5382 の販売金額と販売理由を確認できます。この特定の注文の総計は 539.99 で、この注文に起因する購入理由には、プロモーション、その他、および価格が含まれます。

売上金額が注文に対して正しく計算されていることに注意してください。注文全体では 539.99 です。 理由ごとに 539.99 が示されていますが、その値は 3 つの理由すべてで合計されず、総計が誤って増大します。

最初に各販売理由の下に売上金額を配置する理由答えは、各理由に起因する売上の量を特定できるということです。
ワークシートの一番下までスクロールします。他の理由と総計に比べて、価格が顧客購入の最も重要な理由であることがわかります。

予期しないクエリ結果を処理するためのヒント

クエリで有意な結果を返さない中間メジャーグループの、カウントなどのメジャーを非表示にします。これにより、人々は無意味なデータを生成する集計を使用することを防ぐことができます。メジャーを非表示にするには、ディメンションデザイナーの属性で [可視性] を False に設定します。
提供する分析エクスペリエンスをサポートするメジャーとディメンションのサブセットを使用するパースペクティブを作成します。場合によっては、多くのメジャーグループとディメンションを含むキューブは、どのような場合でもうまく連携しない可能性があります。一緒に使用するディメンションとメジャーグループを分離することで、より予測可能な結果を得られます。
モデルを変更した後は、必ずデプロイと再接続を忘れないでください。 Excel では、[ピボットテーブル分析] リボンの [更新] ボタンを使用します。
リンクメジャーグループは、複数の多対多リレーションシップで使用しないでください。特に、これらのリレーションシップが異なるキューブにある場合は使用しないでください。これを行うと、あいまいな集計が発生する可能性があります。詳細については、「多対多リレーションシップを含むキューブ内でリンクされたメジャーの不正な量」を参照してください。