次の方法で共有

双方向のリレーションシップのガイダンス

  • [アーティクル]

この記事では、Power BI Desktop を使用するデータ モデリング担当者を対象にしています。 双方向のモデル リレーションシップを作成する条件についてのガイダンスを提供します。 双方向のリレーションシップとは、"両方向" にフィルター処理を行うリレーションシップです。

注意

この記事には、モデル リレーションシップの概要は含まれません。 リレーションシップやそのプロパティ、あるいはその構成方法に完全には慣れていない場合は、まず、Power BI Desktop でのモデル リレーションシップに関する記事をお読みになることをお勧めします。

スター スキーマの設計について理解していることも重要です。 詳細については、「スター スキーマと Power BI での重要性を理解する」を参照してください。

一般に、双方向リレーションシップの使用は最小限にすることをお勧めします。 これは、モデル クエリのパフォーマンスに悪影響を及ぼす可能性があり、レポート ユーザーにとって混乱を招く可能性があるためです。

ただし、双方向フィルター処理で特定の要件を解決できるシナリオは 3 つあります。

特殊なモデル リレーションシップ

双方向のリレーションシップは、次の 2 つの特殊なモデル リレーションシップの種類を作成するときに重要な役割を果たします。

  • 一対一:すべての一対一のリレーションシップは双方向である必要があります。それ以外に構成することはできません。 一般に、この種類のリレーションシップを作成することはお勧めしません。 完全なディスカッションと代替設計パターンについては、一対一リレーションシップのガイダンス参照してください。
  • 多対多: 2 つの ディメンション テーブルを関連付ける場合は、ブリッジ テーブル が必要です。 フィルターがブリッジング テーブルを越えて伝達されるようにするには、双方向のフィルターが必要です。 詳細については、多対多リレーションシップ ガイダンスを参照してください。

スライサー オプション「データ付き」

双方向リレーションシップは、データが存在する場所にオプションを制限するスライサーを提供できます。 (Excel のピボットテーブルとスライサーに慣れている場合は、Power BI セマンティック モデルまたは Analysis Services モデルからデータをソーシングする場合の既定の動作です)。それが何を意味するのかを説明するために、まず次のモデル図を検討してください。

3 つのテーブルが含まれるモデルを示す図。設計については、次の段落で説明します。

最初のテーブルは Customerという名前で、Country-Region、Customer、および CustomerCodeの 3 つの列が含まれています。 2 番目のテーブルは Productという名前で、Color、Product、および SKUの 3 つの列が含まれています。 3 番目のテーブルは Salesという名前で、CustomerCode、OrderDate、Quantity、および SKUの 4 つの列が含まれています。 Customer テーブルと Product テーブルはディメンション テーブルであり、それぞれに Sales テーブルとの一対多リレーションシップがあります。 各リレーションシップでは、一方向にフィルター処理されます。

双方向のリレーションシップの動作のしくみを説明するのに役立つように、モデル図が変更されてテーブル行が表示されています。 この記事に含まれるすべての例は、このデータに基づいています。

モデルでテーブル行が表示されるようになったことを示す図。行の詳細については、次の段落で説明します。

3 つのテーブルの行の詳細については、次の箇条書きで説明します。

  • Customer テーブルには、次の 2 つの行があります。
    • CustomerCodeCUST-01, CustomerCustomer-1, Country-Region米国
    • CustomerCodeCUST-02、 CustomerCustomer-2、 オーストラリア Country-Region
  • Product テーブルには、次の 3 つの行があります。
    • SKUCL-01、 ProductTシャツ、 Colorグリーン
    • SKUCL-02、 Productジーンズ、 Colorブルー
    • SKU AC-01、Product帽子、Color青
  • Sales テーブルには、次の 3 つの行があります。
    • OrderDate2019 年 1 月 1 日, CustomerCodeCUST-01, SKUCL-01, Quantity10
    • OrderDate2019 年 2 月 2 日, CustomerCodeCUST-01, SKUCL-02, Quantity20
    • OrderDate2019 年 3 月 3 日, CustomerCodeCUST-02, SKUCL-01, Quantity30

ここで、次のレポート ページについて考えてみましょう。

3 つのビジュアルが含まれるレポート ページを示す図。詳細については、次の段落で説明します。

このページは、2 つのスライサーとカード ビジュアルで構成されています。 最初のスライサーは Country-Region フィールドに基づいており、オーストラリアと米国の 2 つのオプションがあります。 現在は、オーストラリアでスライスされています。 2 番目のスライサーは Product フィールドに基づいており、ハット、ジーンズ、T シャツの 3 つのオプションがあります。 項目は選択されていません (つまり、フィルター処理されている "製品はありません")。 カード ビジュアルには、30 という数量が表示されています。

レポートユーザーがオーストラリアでスライスする際、製品スライサーを制限し、データ がオーストラリアの売上に関連する選択肢を表示するようにすることができます。 これは、スライサー オプションを "データと共に" 表示することで意味します。 この動作を達成するには、Product テーブルと Sales テーブルの間にリレーションシップを設定して、を双方向にフィルターする必要があります。

Product テーブルと Sales テーブル間のリレーションシップが双方向になったことを示すモデルを示す図。

製品スライサーに、T シャツという 1 つのオプションが一覧表示されるようになりました。 このオプションは、オーストラリアのお客様に販売された唯一の製品を表します。

3 つの視覚エフェクトが含まれ、Product が強調表示されているレポート ページを示す図。その詳細については、次の段落で説明します。

最初に、このデザインがレポート ユーザーに対して機能するかどうかを慎重に検討することをお勧めします。 一部のレポート ユーザーは、スライサー オプションが他のスライサーと対話するときに動的に表示または非表示になる理由を理解していないため、エクスペリエンスが混乱を招きます。

"データあり" のスライサー オプションを表示する場合は、双方向リレーションシップを設定しないことをお勧めします。 双方向リレーションシップでは処理が増える必要があるため、特にモデル内の双方向リレーションシップの数が増えるにつれて、クエリのパフォーマンスに悪影響を与える可能性があります。

同じ結果を得るより優れた方法があります。双方向フィルターを使用する代わりに、製品スライサー自体にビジュアル レベルのフィルターを適用できます。

次に、Product テーブルと Sales テーブル間のリレーションシップが双方向でフィルタリングされなくなったことを考えてみましょう。 また、次のメジャー定義が Sales テーブルに追加されています。

Total Quantity = SUM(Sales[Quantity])

"データあり" の製品スライサー オプションを表示するには、"is not blank" 条件を使用して、Total Quantity メジャーでフィルター処理するだけです。

製品スライサーの [フィルター] ウィンドウが [合計数量] でフィルター処理されるようになったことを示す図が空白ではありません。

ディメンション間の分析

双方向リレーションシップを含む別のシナリオでは、ファクト テーブルブリッジ テーブルのように扱われます。 これにより、異なるディメンション テーブルのフィルター コンテキスト内のディメンション テーブル データの分析がサポートされます。

この記事に含まれているモデルの例を使って、次の質問に答える方法を考えてみましょう。

  • オーストラリアの顧客に販売された色の数はいくつですか?
  • ジーンズを購入した国/地域の数はいくつですか?

どちらの質問も、ブリッジファクト テーブルにデータを要約 することなく、答えることができます。 ただし、一方のディメンション テーブルから他方のディメンション テーブルにフィルターを伝達する必要があります。 ファクト テーブルを介してフィルターを伝達する場合、ディメンション テーブル列の集計は、DISTINCTCOUNT DAX 関数 (場合によっては、MIN と MAX DAX 関数 ) を使用して実現できます。

ファクト テーブルはブリッジ テーブルのように動作するため、多対多リレーションシップガイダンスを適用して、2 つのディメンション テーブルを関連付けることができます。 双方向でフィルター処理するには、少なくとも 1 つのリレーションシップを設定する必要があります。 詳細については、多対多リレーションシップ ガイダンスを参照してください。

ただし、この記事で既に説明したように、この設計はパフォーマンスに悪影響を及ぼす可能性があり、スライサーオプション "with data"に関連するユーザーエクスペリエンスへの影響が懸念されます。 そのため、代わりに CROSSFILTER DAX 関数を使用することで、"メジャーの定義で" 双方向のフィルター処理をアクティブにすることをお勧めします。 CROSSFILTER 関数を使用すると、式の評価中にフィルターの方向を変更したり、リレーションシップを無効にしたりできます。

Sales テーブルに追加された次のメジャー定義について考えてみましょう。 この例では、Customer テーブルと Sales テーブルの間のモデル リレーションシップが、の一方向でフィルター処理するように設定されています。

Different Countries Sold =
CALCULATE(
    DISTINCTCOUNT(Customer[Country-Region]),
    CROSSFILTER(
        Customer[CustomerCode],
        Sales[CustomerCode],
        BOTH
    )
)

Different Countries Sold メジャーの評価中に、Customer テーブルと Sales テーブルの関係は双方向でフィルター処理されます。

次のテーブル ビジュアルは、販売された各製品の統計情報を表示しています。 Quantity 列は、単に数量値の合計です。 Different Countries Sold 列は、製品を購入したすべての顧客の国と地域の値の個別の数を表します。

2 つの製品がテーブル ビジュアルに一覧表示されていることを示す図。[異なる国の販売] 列では、ジーンズは 1 で、T シャツは 2 です。

関連するコンテンツ

この記事に関する詳細については、次のリソースを参照してください。