Power BI Desktop でのモデル リレーションシップ

この記事は、Power BI Desktop を使用するインポート データのモデラーを対象としています。 これはモデル設計に関する重要なトピックであり、直感的で、正確かつ最適なモデルを提供するために不可欠です。

テーブルのロールとリレーションシップなど、最適なモデルの設計に関する詳細な説明については、「スター スキーマと Power BI での重要性を理解する」を参照してください。

リレーションシップの目的

モデル リレーションシップは、あるモデル テーブルの列に適用されたフィルターを、別のモデル テーブルに伝達するものです。 フィルターは、たどれるリレーションシップのパスがある限り伝達されます。これにより、複数のテーブルへの伝達が生じる可能性があります。

リレーションシップのパスは決定論的です。つまり、フィルターは常に同じ方法で伝達され、ランダムなバリエーションは発生しません。 ただし、リレーションシップを無効にしたり、特定の DAX 関数を使用したモデルの計算によってフィルター コンテキストを変更したりできます。 詳細については、この記事で後述する「関連する DAX 関数」のトピックをご覧ください。

重要

モデル リレーションシップは、データの整合性を強制するものではありません。 詳細については、この記事で後述する「リレーションシップの評価」トピックを参照してください。データの整合性に問題がある場合に、モデル リレーションシップがどのように動作するかについて説明しています。

リレーションシップによってフィルターがどのように伝達されるかを、アニメーションの例で見てみましょう。

この例では、モデルは次の 4 つのテーブルで構成されています:Category、Product、Year、Sales です。 Category テーブルは Product テーブルに関連付けられ、Product テーブルは Sales テーブルに関連付けられています。 Year テーブルも Sales テーブルに関連付けられています。 リレーションシップはすべて、一対多です (その詳細については、この記事で後述します)。

クエリ (おそらく Power BI のカード ビジュアルによって生成されたもの) では、単一のカテゴリ Cat-A に対する、単一の年度 CY2018 に作成された販売注文の総販売数量が求められています。 このため、Category と Year のテーブルにフィルターが適用されています。 Category テーブルに対するフィルターが Product テーブルに伝達され、カテゴリ Cat-A に割り当てられている 2 つの製品が分離されます。 次に、Product テーブルのフィルターが Sales テーブルに伝達され、それらの製品に対する 2 つの販売行のみが分離されます。 これらの 2 つの販売行は、カテゴリ Cat-A に割り当てられた製品の販売を表しています。 合計数量は 14 ユニットです。 同時に、Year テーブルのフィルターが伝達されて Sales テーブルがさらにフィルター処理され、カテゴリ Cat-A に割り当てられていて、年度 CY2018 に注文された製品を表す販売行のみが表示されます。 このクエリによって返される数量の値は、11 ユニットです。 テーブル (この例の Sales テーブルなど) に対して複数のフィルターが適用された場合、それは常に AND 演算となり、すべての条件が true になる必要があることに注意してください。

スター スキーマの設計原則を適用する

スター スキーマの設計原則を適用して、ディメンションとファクトの各テーブルを構成するモデルを生成することをお勧めします。 ディメンション テーブルをフィルター処理する規則を適用するように Power BI を設定するのが一般的です。こうすることで、モデル リレーションシップによって、そのフィルターがファクト テーブルに効率的に伝達されます。

次の図は、Adventure Works の売上分析データ モデルのモデル図です。 Sales という名前の 1 つのファクト テーブルで構成されるスター スキーマ設計が示されています。 他の 4 つのテーブルは、日付、状態、地域、および製品別の販売施策の分析をサポートするディメンション テーブルです。 すべてのテーブルを接続するモデル リレーションシップに注目してください。 これらのリレーションシップは、フィルターを (直接的または間接的に) Sales テーブルに反映します。

分離されたテーブル

通常は、あるモデル テーブルが別のモデル テーブルに関連付けられていないことはありません。 有効なモデル設計におけるそのようなテーブルは、"分離されたテーブル" として説明されます。 分離されたテーブルは、他のモデル テーブルにフィルターを伝達するためのものではありません。 そうではなく、(おそらくスライサーのビジュアルを使用して) "ユーザー入力" を受け取るものです。これによって、モデルの計算で入力値を意味のある方法で使うことができます。 たとえば、通貨為替レートの値の範囲と共に読み込まれる、分離されたテーブルについて考えてみます。 1 つのレート値でフィルター処理するようにフィルターが適用される限り、メジャー式でこの値を使って販売の値を変換できます。

Power BI Desktop の What-If パラメーターは、切断されたテーブルを作成する機能です。 詳細については、「Power BI Desktop で変数を視覚化する What-if パラメーターを作成して使用する」を参照してください。

リレーションシップのプロパティ

モデル リレーションシップにより、テーブル内の 1 つの列が、別のテーブル内の 1 つの列に関連付けられます。 (この要件が満たされない特殊なケースが 1 つあり、それは DirectQuery モデルの複数列リレーションシップにのみ適用されます。詳細については、DAX 関数「COMBINEVALUES」の記事を参照してください)。

注意

列を、"同じテーブル内の" 別の列に関連付けることはできません。 この概念は、リレーショナル データベースの、テーブルを自己参照する外部キー制約の定義機能と混同されることがあります。 このリレーショナル データベースの概念は、親子関係を格納するために使用できます (例: 各従業員レコードが "報告先" 従業員に関連付けられている)。 ただし、この種のリレーションシップに基づいてモデルの階層を生成するためにモデル リレーションシップを使うことはできません。 親子階層を作成するには、「親関数と子関数」を参照してください。

列のデータ型

リレーションシップの "from" 列と "to" 列の両方のデータ型は同じにする必要があります。 DateTime 列で定義されているリレーションシップを操作したとき、期待どおりに動作しないことがあります。 Power BI データを格納するエンジンでは、DateTime データ型のみが使用されます。Date、Time、Date/Time/Timezone データ型は、その上に実装される、Power BI 形式の構成体です。 モデルに依存するオブジェクトはすべて、引き続きエンジンに DateTime として表示されます (リレーションシップやグループなど)。 そのため、ユーザーがそれらの列に対して [モデリング] タブから Date を選択した場合でも、データの時刻部分が引き続きエンジンによって考慮されるので、同じ日付として登録されません。 日付/時刻型の処理方法については、こちらに詳しく記載されております。 この動作を修正するには、Power Query エディター で、該当する列のデータ型を更新して、インポートしたデータから Time 部分を削除する必要があります。そうすれば、エンジンによりデータが処理される場合に、値は同じように表示されます。

カーディナリティ

各モデル リレーションシップは、カーディナリティの種類によって定義されます。 カーディナリティの種類には 4 つのオプションがあり、それぞれ関連 "元" と関連 "先" の列のデータ特性を表しています。 "一" 側は、列に一意の値が含まれていることを意味します。"多" 側は、列に重複する値が含まれている可能性があることを意味します。

注意

データ更新の操作によって、"一" 側の列に重複する値を読み込もうとすると、データ更新全体が失敗します。

その 4 つのオプション (およびその略記法) について、次の箇条書きで説明します。

• 1 対多 (1:*)
• 多対一 (*:1)
• 一対一 (1:1)
• 多対多 (*:*)

Power BI Desktop でリレーションシップを作成する場合、デザイナーによって自動的にカーディナリティの種類が検出され、設定されます。 Power BI Desktop では、一意の値が含まれる列を特定するため、モデルのクエリが実行されます。 インポート モデルの場合は、内部ストレージの統計が使用されます。DirectQuery モデルの場合は、データ ソースに対してプロファイリング クエリが送信されます。 ただし、Power BI Desktop が間違っている場合もあります。 間違いが起きるのは、まだテーブルにデータが読み込まれていないため、あるいは、重複する値を含めることを想定している列に、現在は一意の値が含まれているためです。 どちらの場合でも、"一" の側の列に一意の値が含まれる限り (または、テーブルにまだデータ行が読み込まれていない限り)、カーディナリティの種類を更新できます。

一対多 (および多対一) のカーディナリティ

一対多と多対一のカーディナリティ オプションは、本質的に同じものであり、最も一般的なカーディナリティの種類でもあります。

一対多または多対一のリレーションシップを構成する場合は、列を関連付けた順序と一致するリレーションシップを選択します。 Product テーブルから Sales テーブルへのリレーションシップを、各テーブル内にある ProductID 列を使って構成する方法を検討してみます。 Product テーブルの ProductID 列には一意の値が含まれているため、カーディナリティの種類は "一対多" になります。 テーブルを逆方向に (Sales から Product へ) 関連付けた場合は、カーディナリティは "多対一" になります。

一対一のカーディナリティ

一対一のリレーションシップは、両方の列に一意の値が含まれていることを意味します。 このカーディナリティの種類は一般的ではなく、冗長データの格納による十分最適化されていないモデル設計を表している可能性があります。

このカーディナリティの種類の使用方法の詳細については、「一対一のリレーションシップのガイダンス」を参照してください。

多対多のカーディナリティ

多対多のリレーションシップは、両方の列に重複する値が含まれる可能性があることを意味します。 このカーディナリティの種類は、あまり使用されません。 これは、通常、複雑なモデル要件を設計する場合に役に立ちます。 これを使って、多対多のファクトを関連付けることや、より高い粒度のファクトを関連付けることができます。 たとえば、販売目標ファクトを製品カテゴリ レベルで格納し、製品ディメンション テーブルを製品レベルで格納する場合です。

このカーディナリティの種類の使用方法については、多対多リレーションシップのガイダンスに関するページを参照してください。

Note

2024 年 1 月以降に Power BI Report Server 向けに開発されたモデルでは、多対多のカーディナリティの種類がサポートされます。

ヒント

Power BI Desktop のモデル ビューでは、リレーションシップ線の両側にあるインジケーター (1 または *) を確認して、そのリレーションシップのカーディナリティの種類を解釈できます。 どの列が関連付けられているかを判断する場合は、そのリレーションシップ線を選択 (またはカーソルでポイント) して、列を強調表示する必要があります。

クロス フィルターの方向

各モデル リレーションシップは、クロス フィルターの方向と共に定義されています。 ユーザーの設定によって、フィルターが伝達される方向が決まります。 選択できるクロス フィルターのオプションは、カーディナリティの種類によって異なります。

カーディナリティの種類	クロス フィルターのオプション
一対多 (または多対一)	単一 両方
一対一	両方
多対多	一方 (Table1 から Table2) 一方 (Table2 から Table1) 両方

"一方" のクロス フィルターの方向は "一方向" を意味し、"両方" は "両方向" を意味します。 両方向にフィルター処理を行うリレーションシップは、一般に "双方向" として説明されます。

一対多のリレーションシップの場合、クロス フィルターの方向は常に "一" 側からで、必要に応じて "多" 側から (双方向) を使用できます。 一対一のリレーションシップでは、クロス フィルターの方向は常に両方のテーブルからです。 最後に、多対多のリレーションシップの場合、クロス フィルターの方向は、片方のテーブルから、または両方のテーブルからのいずれかにできます。 カーディナリティの種類に "一" 側が含まれている場合、そのフィルターは常にその側から伝達されることがわかります。

クロス フィルターの方向が両方に設定されている場合、その他のプロパティを使用できます。 Power BI によって行レベルのセキュリティ (RLS) 規則が適用されている場合は、双方向のフィルター処理を適用できます。 RLS に関する詳細については、「Power BI Desktop での行レベルのセキュリティ (RLS)」を参照してください。

(フィルターの伝達の無効化を含め) リレーションシップのクロス フィルターの方向を変更するには、モデルの計算を使います。 それは、CROSSFILTER DAX 関数を使用して実現されます。

双方向のリレーションシップは、パフォーマンスに悪影響を及ぼす可能性があること注意してください。 さらに、双方向のリレーションシップを構成しようとすることにより、フィルター伝達パスがあいまいになる可能性があります。 この場合、Power BI Desktop によるリレーションシップ変更のコミットが失敗し、エラー メッセージが表示される可能性があります。 ただし、Power BI Desktop により、テーブル間にあいまいなリレーションシップのパスを定義することが許可される場合があります。 リレーションシップ パスのあいまいさの解決方法については、この記事で後述します。

必要な場合にのみ双方向のフィルター処理を使用することをお勧めします。 詳細については、「双方向のリレーションシップのガイダンス」をご覧ください。

ヒント

Power BI Desktop のモデル ビューでは、リレーションシップ線に沿った矢印に注意することで、リレーションシップのクロス フィルターの方向を解釈できます。 1 つの矢印は、その矢印の方向の一方向のフィルターを表します。二重の矢印は、双方向のリレーションシップを表します。

このリレーションシップをアクティブにする

2 つのモデル テーブル間には、アクティブなフィルター伝達パスを 1 つだけ指定できます。 ただし、追加のリレーションシップのパスを導入することもできますが、これらのリレーションシップを "非アクティブ" に設定する必要があります。 非アクティブなリレーションシップは、モデルの計算の評価中にのみアクティブにすることができます。 これは、USERELATIONSHIP DAX 関数を使用して実現されます。

一般に、可能なときは常にアクティブなリレーションシップを定義することをお勧めします。 こうすることで、レポート作成者がモデルを使用できる方法の範囲と可能性が広がります。 アクティブなリレーションシップのみを使うことは、モデル内でロールプレイング ディメンション テーブルを複製する必要があることを意味します。

ただし、特定の状況では、ロールプレイング ディメンション テーブルに対して 1 つ以上の非アクティブなリレーションシップを定義できます。 この設計を検討できるのは、次の場合です。

• レポートのビジュアルにおいて、異なるロールで同時にフィルター処理を行う必要がない。
• USERELATIONSHIP DAX 関数を使用して、関連するモデルの計算のために特定のリレーションシップをアクティブにする。

詳細については、「アクティブなリレーションシップと非アクティブなリレーションシップのガイダンス」をご覧ください。

ヒント

Power BI Desktop のモデル ビューでは、リレーションシップのアクティブと非アクティブの状態を解釈することができます。 アクティブなリレーションシップは実線で表されます。非アクティブなリレーションシップは破線で表されます。

参照整合性を想定

[参照整合性を想定] プロパティは、同じデータ ソースに属する 2 つの DirectQuery ストレージ モードのテーブル間の、一対多と一対一のリレーションシップでのみ使用できます。 このプロパティは、"多" 側の列に NULL が含まれていない場合にのみ有効にすることができます。

有効にした場合、そのデータ ソースに送信されたネイティブ クエリでは、OUTER JOIN ではなく INNER JOIN を使って 2 つのテーブルが結合されます。 一般的には、このプロパティを有効にするとクエリのパフォーマンスが向上しますが、それはデータ ソースの仕様によって異なります。

2 つのテーブル間にデータベースの外部キー制約が存在するときは、常にこのプロパティを有効にします。 外部キー制約が存在しない場合でも、データ整合性の存在が確実な場合は、このプロパティを有効にすることを検討してください。

重要

データ整合性が損なわれた場合、内部結合によって、テーブル間の一致していない行が除去されます。 たとえば、関連付けられた Product テーブル内に存在しない ProductID 列の値を持つモデル Sales テーブルについて考えてみます。 Product テーブルから Sales テーブルへのフィルター伝達によって、不明な製品の販売行が削除されます。 これにより、販売結果が低く評価されることになります。

詳しくは、「Power BI Desktop で参照整合性設定を想定する」の記事をご覧ください。

関連する DAX 関数

モデル リレーションシップに関連する DAX 関数がいくつかあります。 各関数について、次の箇条書きで簡単に説明します。

• RELATED: リレーションシップの "一" 側から値を取得します。 行コンテキストで評価される、さまざまなテーブルからの計算を含む場合に便利です。
• RELATEDTABLE:リレーションシップの "多" 側から行のテーブルを取得します。
• USERELATIONSHIP: 計算で非アクティブなリレーションシップを使用できるようにします (技術的には、この関数を使用すれば、特定の非アクティブなモデル リレーションシップの重みを変更して、その使用に影響を与えることができます)。これは、ご利用のモデルにロールプレイング ディメンション テーブルが含まれていて、そのテーブルから非アクティブなリレーションシップを作成する場合に便利です。 この関数を使用して、フィルター パスのあいまいさを解決することもできます。
• CROSSFILTER:リレーションシップのクロス フィルターの方向を (一方か両方に) 変更するか、フィルター伝達を無効にします (なし)。 特定の計算の評価中にモデル リレーションシップを変更または無視する必要がある場合に便利です。
• COMBINEVALUES:2 つ以上のテキスト文字列を結合して 1 つのテキスト文字列にまとめます。 この関数の目的は、テーブルが同じソース グループに属している場合に、DirectQuery モデルで複数列のリレーションシップをサポートすることです。
• TREATAS:テーブル式の結果を、関連付けられていないテーブルの列にフィルターとして適用します。 特定の計算の評価中に仮想リレーションシップを作成する場合の高度なシナリオで役に立ちます。
• 親関数と子関数: 親子階層を取り入れるための計算列の生成に使用できる、関連する関数のファミリです。 その後、これらの列を使用して、固定レベルの階層を作成できます。

リレーションシップの評価

評価の観点から見た場合、モデル リレーションシップは "標準" か "制限付き" かに分類されます。 これは、構成可能なリレーションシップのプロパティではありません。 実際は、2 つの関連テーブルのカーディナリティの種類と、データ ソースから推論されます。 この評価の種類を理解しておくことが重要です。データ整合性が損なわれた場合に、パフォーマンスへの関係や影響がある可能性があるためです。 このトピックでは、これらの関係と整合性の影響について説明します。

まず、リレーションシップの評価を完全に理解するには、モデリングに関する多少の理論が必要です。

インポート モデルまたは DirectQuery モデルのすべてのデータは、Vertipaq キャッシュまたはソース データベースをソースに持ちます。 どちらの場合も、Power BI では、リレーションシップの "一" 側が存在することを確認できます。

しかし、複合モデルは、さまざまなストレージ モード (インポート、DirectQuery、またはデュアル) を使用したテーブルや、複数の DirectQuery ソースから構成できます。 各ソース (インポート データの Vertipaq キャッシュを含む) は、"ソース グループ" と見なされます。 さらに、モデルのリレーションシップは "ソース グループ内" または "ソース グループ間" として分類できます。 ソース グループ内リレーションシップは、1 つのソース グループ内の 2 つのテーブルを関連付けるものです。一方、ソース グループ間リレーションシップは、2 つのソース グループのテーブルを関連付けます。 インポートまたは DirectQuery モデルのリレーションシップは、常にソース グループ内であることに注意してください。

複合モデルの例を見てみましょう。

この例では、複合モデルは 2 つのソース グループ (Vertipaq ソース グループと DirectQuery ソース グループ) で構成されています。 Vertipaq ソース グループには 3 つのテーブルが含まれており、DirectQuery ソース グループには 2 つのテーブルが含まれています。 ソース グループ間リレーションシップが 1 つ存在し、Vertipaq ソース グループのテーブルが DirectQuery ソース グループのテーブルに関連付けられています。

標準リレーションシップ

モデル リレーションシップは、クエリ エンジンがリレーションシップの "一" 側を特定できる場合に、"標準" と呼ばれます。 そこでは、確実に "一" 側の列に一意の値が含まれていると言えます。 一対多のソース グループ内リレーションシップはすべて、標準リレーションシップです。

次の例では、標準リレーションシップが 2 つあり、両方とも R とマークされています。リレーションシップには、Vertipaq ソース グループ内に含まれる一対多のリレーションシップと、DirectQuery ソース内に含まれる一対多のリレーションシップも含まれています。

すべてのデータが Vertipaq キャッシュ内に格納されているインポート モデルの場合、データ更新時に、Power BI によってそれぞれの標準リレーションシップに対してデータ構造が作成されます。 このデータ構造は、すべての列から列への値のインデックス付きマッピングで構成されています。その目的は、クエリ時にテーブルの結合を高速化することです。

クエリ時に、標準リレーションシップによって "テーブルの展開" の実行が許可されます。 テーブルが展開されると、ベース テーブルのネイティブ列を含めてから関連テーブルに展開することで、仮想テーブルが作成されます。 インポート テーブルの場合、テーブルの展開はクエリ エンジンで実行されます。DirectQuery テーブルの場合は、ソース データベースに送信されたネイティブ クエリで実行されます ([参照整合性を想定] プロパティが有効になっていない場合)。 次に、展開されたテーブルに対してクエリ エンジンが動作し、展開されたテーブルの列の値に基づいてフィルターとグループ化が適用されます。

注意

非アクティブなリレーションシップも、そのリレーションシップが計算に使用されていない場合でも展開されます。 双方向のリレーションシップは、テーブルの展開には影響しません。

一対多のリレーションシップの場合、テーブルの展開は、LEFT OUTER JOIN セマンティクスを使用して "多" 側から "一" 側に実行されます。 "多" 側から "一" 側への一致する値が存在しない場合は、"一" 側のテーブルに空の仮想行が追加されます。 この動作は、標準リレーションシップにのみ適用され、制限付きリレーションシップには適用されません。

テーブルの展開は、一対一のソース グループ内リレーションシップに対しても実行されます。ただし、FULL OUTER JOIN セマンティクスが使用されます。 この結合の種類にすると、空の仮想行が両方の側に追加されます (必要な場合)。

空の仮想行は、実質的には "不明なメンバー" です。 不明なメンバーは、"多" 側の値に対応する "一" 側の値がないという参照整合性の違反を表します。 このような空白は存在しないことが理想的です。 これらを排除するには、ソース データをクレンジングまたは修復します。

テーブルの展開がどのように動作するかを、アニメーションの例で見てみましょう。

この例では、モデルは次の 3 つのテーブルで構成されています:Category、Product、Sales です。 Category テーブルが一対多のリレーションシップで Product テーブルに関連付けられ、Product テーブルが一対多のリレーションシップで Sales テーブルに関連付けられています。 Category テーブルには 2 つの行が含まれ、Product テーブルには 3 つの行が含まれ、Sales テーブルには 5 つの行が含まれています。 すべてのリレーションシップの両方の側に、一致する値があります。つまり、参照整合性の違反はありません。 クエリ時に展開されたテーブルが表示されます。 このテーブルは、3 つのテーブルすべての列で構成されています。 これは、実質的に、3 つのテーブルに含まれるデータの非正規化されたパースペクティブです。 Sales テーブルに新しい行が追加されます。この行に含まれている製品を識別する値 (9) は、Product テーブルに一致する値がありません。 これは参照整合性の違反です。 展開されたテーブルでは、新しい行の Category と Product テーブルの列に対する値が空白になります。

制限付きリレーションシップ

保証された "一" 側が存在しない場合、モデル リレーションシップは "制限付き" と呼ばれます。 制限付きリレーションシップは、次の 2 つの理由で発生することがあります。

• リレーションシップで、多対多のカーディナリティの種類が使用されている (一方または両方の列に一意の値が含まれている場合でも)
• リレーションシップがソース グループ間である (複合モデルの場合のみ)

次の例では、制限付きリレーションシップが 2 つあり、両方とも L とマークされています。この 2 つのリレーションシップには、Vertipaq ソース グループ内に含まれる多対多のリレーションシップと、一対多のソース グループ間リレーションシップが含まれています。

インポート モデルの場合、制限付きリレーションシップに対してデータ構造が作成されることはありません。 その場合、Power BI によってクエリ時にテーブル結合が解決されます。

テーブルの展開は、制限付きリレーションシップに対しては行われません。 テーブルの結合は、INNER JOIN セマンティクスを使用して実現されます。このため、参照整合性の違反を補正するために空の仮想行が追加されることはありません。

制限付きリレーションシップに関連するその他の制限があります。

• RELATED DAX 関数を使用して "一" 側の列の値を取得することはできない。
• RLS の適用についてトポロジの制限がある。

ヒント

Power BI Desktop モデル ビューでは、リレーションシップが制限されていると解釈できます。 制限付きリレーションシップはカーディナリティ インジケーターの後のかっこのようなマーク ( ) で表されます。

リレーションシップ パスのあいまいさを解決する

双方向のリレーションシップでは、モデル テーブル間に、複数の (したがって、あいまいな) フィルター伝達パスが発生する可能性があります。 あいまいさを評価する場合、Power BI では次の優先度と重みに従ってフィルター伝達パスを選択します。

Priority

優先度レベルでは、Power BI がリレーションシップ パスのあいまいさを解決するために使用する一連の規則を定義します。 最初の規則の一致によって、Power BI がたどるパスが決まります。 以下の各規則では、フィルターがソース テーブルからターゲット テーブルにどのように流れるかについて説明します。

1. 一対多のリレーションシップで構成されるパス。
2. 一対多または多対多のリレーションシップで構成されるパス。
3. 多対一リレーションシップで構成されるパス。
4. ソース テーブルから中間テーブルへの 1 対多のリレーションシップと、それに続く中間テーブルからターゲット テーブルへの多対 1 のリレーションシップで構成されるパス。
5. ソース テーブルから中間テーブルへの 1 対多または多対多のリレーションシップと、それに続く中間テーブルからターゲット テーブルへの多対 1 または多対多のリレーションシップで構成されるパス。
6. その他の任意のパス。

使用可能なすべてのパスにリレーションシップが含まれている場合、それはすべてのパスの考慮事項から削除されます。

Weight

パス内の各リレーションシップには、重みが割り当てられています。 USERELATIONSHIP 関数を使用しない限り、既定では各リレーションシップの重みは等しくなります。 パスの重みは、パスに沿ったすべてのリレーションシップの重みの最大値となります。 Power BI では、パスの重みを使用して、同じ優先度レベル内の複数のパス間に存在するあいまいさを解決します。 優先度がより低いパスは選択されず、重みがより高いパスが選択されます。 パス内のリレーションシップの数は、重みに影響を与えません。

USERELATIONSHIP 関数を使用すると、リレーションシップの重みに影響を与えることができます。 重みは、この関数の呼び出しの入れ子レベルによって決まります。ここで、最も内側の呼び出しが最も高い重みを受け取ります。

例を次に示します。 Product Sales メジャーでは、Sales[ProductID] と Product[ProductID] のリレーションシップにより高い重みを割り当て、その後に Inventory[ProductID] と Product[ProductID] のリレーションシップに対して割り当てを行います。

Product Sales = 
CALCULATE(
    CALCULATE(
        SUM(Sales[SalesAmount]), 
        USERELATIONSHIP(Sales[ProductID], Product[ProductID])
    ),
    USERELATIONSHIP(Inventory[ProductID], Product[ProductID])
)

注意

Power BI によって同じ優先度と同じ重みを持つパスが複数検出されると、あいまいなパスであることを示すエラーが返されます。 この場合、あいまいさを解決する必要があります。それには、USERELATIONSHIP 関数を使用するか、モデル リレーションシップを削除または変更することによって、リレーションシップの重みに影響を与えます。

パフォーマンスの選択

次の一覧では、フィルター伝達のパフォーマンスが、最速からもっとも低速のパフォーマンスの順に並べられています。

1. 一対多のソース グループ内リレーションシップ
2. 中間テーブルを使用して実現され、少なくとも 1 つの双方向リレーションシップが関係する、多対多のモデル リレーションシップ
3. 多対多のカーディナリティのリレーションシップ
4. ソース グループ間リレーションシップ

関連するコンテンツ

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

• Power BI のスター スキーマおよび重要性について
• 一対一のリレーションシップのガイダンス
• 多対多のリレーションシップのガイダンス
• アクティブなリレーションシップと非アクティブなリレーションシップのガイダンス
• 双方向のリレーションシップのガイダンス
• リレーションシップのトラブルシューティング ガイダンス
• ビデオ:Power BI リレーションシップの注意事項
• わからないことがある場合は、 Power BI コミュニティで質問してみてください。
• Power BI チームへのご提案は、 Power BI を改善するためのアイデアをお寄せください