Power BI Desktop で多対多リレーションシップを適用する

  • [アーティクル]

Power BI Desktop で "多対多カーディナリティのリレーションシップ" を使用すると、"多対多" のカーディナリティを使用するテーブルを結合できます。 2 つ以上のデータ ソースを含むデータ モデルを、より簡単かつ直感的に作成できます。 "多対多カーディナリティのリレーションシップ" は、Power BI Desktop のより大きな機能である "複合モデル" の一部です。 複合モデルの詳細については、「Power BI Desktop で複合モデルを使用する」を参照してください。

Screenshot of a many-to-many relationship in the Edit relationship pane.

多対多カーディナリティのリレーションシップによって解決されるもの

"多対多カーディナリティのリレーションシップ" が利用可能になるまでは、2 つのテーブル間のリレーションシップは Power BI で定義されていました。 リレーションシップに関係する少なくとも 1 つのテーブルの列に、一意の値を含める必要がありました。 しかし多くの場合、一意の値を含む列はありませんでした。

たとえば、2 つのテーブルに CountryRegion というラベルが付いた列があるとします。 しかし、どちらのテーブルでも CountryRegion の値が一意ではありませんでした。 このようなテーブルを結合するには、回避策を用意する必要がありました。 1 つの回避策として、必要な一意の値を持つ追加のテーブルを導入することが考えられます。 "多対多カーディナリティのリレーションシップ" では、"多対多" のカーディナリティを持つリレーションシップを使用する場合に、このようなテーブルを直接結合することができます。

多対多カーディナリティのリレーションシップを使用する

Power BI で 2 つのテーブル間のリレーションシップを定義する場合、リレーションシップのカーディナリティを定義する必要があります。 たとえば、ProductSales と Product のリレーションシップ (ProductSales[ProductCode] と Product[ProductCode] の列を使用) は、"多対一" として定義されます。 リレーションシップをこのように定義するのは、各製品に対して多くの売上が存在し、Product テーブル内の列 (ProductCode) が一意であるためです。 リレーションシップのカーディナリティを "多対一"、"一対多"、または "一対一" として定義すると、Power BI によってそれが検証されるため、選択したカーディナリティが実際のデータと一致します。

たとえば、この画像のシンプルなモデルを見てみましょう。

Screenshot of ProductSales and Product table in Relationship view.

ここで、Product (製品) で次の 2 つの行のみが表示されているとします。

Screenshot of a Product table visual with two rows.

また、Sales テーブルには、製品 C の行を含め、4 行しかないとします。参照整合性エラーのため、製品 C の行は Product テーブルには存在しません。

Screenshot of a Sales table visual with four rows.

ProductName と Price (Product テーブルからのもの)、および各製品の合計 Qty (ProductSales テーブルからのもの) は、次のように表示されます。

Screenshot of a Visual displaying the product name, price, and quantity.

前の画像からわかるように、空白の ProductName 行は製品 C の売上に関連付けられています。この空白行は次の考慮事項を示しています。

  • Product (製品) テーブルに対応する行が存在しない、ProductSales (製品売上) テーブルの任意の行がある。 この例の製品 C の場合のように、参照整合性の問題が存在する。

  • 外部キー列が null である ProductSales (製品売上) テーブルの行がある。

これらの理由により、どちらの場合の空白行も、ProductName (製品名) と Price (価格) が不明な売上を示しています。

テーブルが 2 つの列で結合されていても、どちらの列も一意ではない場合があります。 たとえば、これらのテーブルについて考えてみます。

  • Sales (売上) テーブルでは、State (州) 別の売上データが表示されており、各行にはその州の売上の種類が含まれています。 州はカリフォルニア州、ワシントン州、テキサス州などです。

    Screenshot of a Sales table displaying sales by state.

  • CityData テーブルでは、人口や州 (カリフォルニア州、ワシントン州、テキサス州など) を含む、市区町村に関するデータが表示されています。

    Screenshot of a Sales table displaying city, state, and population.

これで、State の列が両方のテーブルに含まれるようになりました。 州ごとの総売上と、各州の総人口の両方についてレポートすることをお勧めします。 しかし、問題があります。State 列がどちらのテーブルでも一意ではありません。

以前の回避策

Power BI Desktop の 2018 年 7 月のリリースより前では、これらのテーブル間に直接のリレーションシップを作成することはできませんでした。 以下が一般的な回避策でした。

  • 一意の State ID のみを含む 3 番目のテーブルを作成します。 テーブルには、次のいずれか、またはすべてを指定できます。

    • 計算テーブル (Data Analysis Expressions [DAX] を使用して定義されたもの)。
    • Power Query エディターで定義されたクエリに基づくテーブル。テーブルのいずれかから抽出された一意の ID を表示する場合があります。
    • 結合された完全なセット。

  • 次に、一般的な "多対一" リレーションシップを使用して、2 つの元のテーブルをその新しいテーブルに関連付けます。

回避策テーブルは表示したままでかまいません。 または、回避策テーブルを非表示にして、[フィールド] のリストに表示されないようにすることもできます。 テーブルを非表示にする場合、"多対一" リレーションシップが一般的に両方向にフィルター処理するように設定され、いずれのテーブルからでも State フィールドを使用できます。 この後のクロスフィルタリングは、もう 1 つのテーブルに反映されます。 このアプローチを次の図に示します。

Screenshot of a hidden State table in Relationship view.

State (州) (CityData (市区町村データ) テーブル) と共に合計の Population (人口) と合計の Sales (売上) を表示するビジュアルは、次のようになります。

Screenshot showing a table with State, Population, and Sales data.

Note

この回避策では CityData テーブルの州が使用されるため、そのテーブルの州のみがリストされます。したがって、テキサス州は除外されます。 また、"多対一" リレーションシップとは異なり、合計行にはすべての Sales (テキサス州のデータを含む) が含まれますが、このような不一致の行を対象とする空白行は含まれません。 同様に、State が null 値の Sales を対象とする空白行はありません。

また、そのビジュアルに City を追加するとします。 市区町村ごとの人口はわかっていますが、City に対して表示される Sales では、対応する State の Sales が単に繰り返されます。 このシナリオは通常、ここに示すように、列のグループ化が集計メジャーと関連付けられていない場合に発生します。

Screenshot of a table showing State and city population and sales.

たとえば、ここですべての州の組み合わせとして新しい Sales テーブルを定義し、 [フィールド] リストに表示されるようにするとします。 同じビジュアルで、(新しいテーブルに) State、Population の合計、および Sales の合計が表示されます。

Screenshot of a visual showing State, population, and sales visual.

ご覧のように、TX (Sales データはあるが、Population データは不明) と New York (Population データはわかっているが、Sales データがない) が含まれます。 この回避策は最適ではなく、多くの問題を含んでいます。 多対多カーディナリティのリレーションシップの場合は、次のセクションで説明するように、発生する問題に対処します。

この回避策の実装の詳細については、「多対多のリレーションシップのガイダンス」を参照してください。

回避策ではなく、多対多カーディナリティのリレーションシップを使用する

前に説明したもののようなテーブルを直接関連付けることができます。同様の回避策を利用する必要はありません。 リレーションシップのカーディナリティを "多対多" に設定できるようになりました。 この設定は、どちらのテーブルにも一意の値が含まれていないことを示しています。 そのようなリレーションシップでも、他のテーブルをフィルター処理するテーブルを制御できます。 または、テーブルで相互にフィルター処理を行う、双方向のフィルター処理を適用することができます。

Power BI Desktop では、いずれのテーブルにもリレーションシップ列に一意の値が含まれていないと判断された場合、カーディナリティは既定で "多対多" に設定されます。 このような場合は、リレーションシップの設定と、変更がデータの問題による意図しない結果ではないことを確認する警告メッセージが表示されます。

たとえば、CityData と Sales 間に直接リレーションシップを作成する場合 (ここでは、フィルターのフローが CityData から Sales となるようにする必要があります)、Power BI Desktop で [リレーションシップの編集] ダイアログが表示されます。

Screenshot of the Edit relationship dialog box with Cardinality and Cross filter direction highlighted.

その結果、 [リレーションシップ] ビューには、2 つのテーブル間に直接かつ多対多のリレーションシップが表示されるようになります。 [フィールド] リストでのテーブルの外観と、ビジュアルの作成時のその後の動作は、回避策を適用した場合と似ています。 回避策では、個別の State データを表示する追加のテーブルは表示されません。 前述のとおり、State、Population、および Sales データを表示するビジュアルが表示されます。

Screenshot of a State, Population, and Sales table.

"多対多カーディナリティのリレーションシップ" と、より一般的な "多対一" のリレーションシップの主な違いは、次のとおりです。

  • 表示される値に、もう一方のテーブルの一致しない行を示す空白行が含まれません。 また、もう一方のテーブルのリレーションシップで使用される列が null である行を示す値も含まれません。

  • 複数の行が関連する可能性があるため、RELATED() 関数を使用することはできません。

  • テーブルに ALL() 関数を使用しても、多対多のリレーションシップによって関連付けられているもう一方のテーブルに適用されているフィルターは削除されません。 前の例では、以下に示すように定義されているメジャーでは、関連する CityData テーブルの列に対するフィルターは削除されません。

    Screenshot of a script example. The example is, Sales total = Calculate(Sum('Sales'[Sales]), All('Sales')).

    State、Sales、および Sales total のデータを表示するビジュアルは、この図のようになります。

    Screenshot of a table visual showing State, Sales, and Sales total resulting from the formula.

前述の相違点に注意しながら、ALL(<Table>) を使用する計算 ("合計に対する割合" など) で、意図した結果が返されることを確認します。

考慮事項と制限事項

このリリースの "多対多カーディナリティのリレーションシップ" と複合モデルには、いくつかの制限事項があります。

次の Live Connect (多次元) ソースは、複合モデルでは使用できません。

  • SAP HANA
  • SAP Business Warehouse
  • SQL Server Analysis Services
  • Power BI セマンティック モデル
  • Azure Analysis Services

DirectQuery を使用してこれらの多次元ソースに接続すると、別の DirectQuery ソースに接続することも、これをインポートしたデータと結合することもできません。

DirectQuery を使用する際の既存の制限は、"多対多カーディナリティのリレーションシップ" を使用する場合にも適用されます。 多くの制限事項が、テーブルのストレージ モードに応じて、テーブルごとに適用されるようになりました。 たとえば、インポートしたテーブルの計算列からは他のテーブルを参照できますが、DirectQuery テーブルの計算列からは引き続き同じテーブルの列しか参照できません。 モデル内のいずれかのテーブルが DirectQuery である場合、モデル全体に他の制限事項が適用されます。 たとえば、モデル内のいずれかのテーブルにストレージ モードの DirectQuery がある場合、そのモデルでは QuickInsights と Q&A 機能を使用できません。

関連するコンテンツ

複合モデルと DirectQuery について詳しくは、次の記事をご覧ください。