Power BI Desktop で多対多リレーションシップを適用するApply many-many relationships in Power BI Desktop

Power BI Desktop で "多対多カーディナリティのリレーションシップ" を使用すると、"多対多" のカーディナリティを使用するテーブルを結合できます。With relationships with a many-many cardinality in Power BI Desktop, you can join tables that use a cardinality of many-to-many. 2 つ以上のデータ ソースを含むデータ モデルを、より簡単かつ直感的に作成できます。You can more easily and intuitively create data models that contain two or more data sources. "多対多カーディナリティのリレーションシップ" は、Power BI Desktop のより大きな機能である "複合モデル" の一部です。Relationships with a many-many cardinality are part of the larger composite models capabilities in Power BI Desktop.

[リレーションシップの編集] ペインの多対多リレーションシップ、Power BI Desktop

Power BI Desktop の "多対多カーディナリティのリレーションシップ" は、次の関連する 3 つの機能のいずれかで構成されます。A relationship with a many-many cardinality in Power BI Desktop is composed of one of three related features:

  • 複合モデル:"複合モデル" では、DirectQuery 接続やインポートなど、2 つ以上のデータ接続を任意の組み合わせでレポートに含めることができます。Composite models: A composite model allows a report to have two or more data connections, including DirectQuery connections or Import, in any combo. 詳細については、「Power BI Desktop で複合モデルを使用する」を参照してください。For more information, see Use composite models in Power BI Desktop.

  • 多対多カーディナリティのリレーションシップ:複合モデルでは、テーブル間に "多対多カーディナリティのリレーションシップ" を確立することができます。Relationships with a many-many cardinality: With composite models, you can establish relationships with a many-many cardinality between tables. このアプローチでは、テーブル内の一意の値の要件が除外されます。This approach removes requirements for unique values in tables. また、リレーションシップを作成するためだけに新しいテーブルを導入するなどの以前の回避策も除外されます。It also removes previous workarounds, such as introducing new tables only to establish relationships. この機能については、この記事で詳しく説明します。The feature is described further in this article.

  • ストレージ モード:どのビジュアルでバックエンド データ ソースへのクエリが必要かを指定できるようになりました。Storage mode: You can now specify which visuals require a query to back-end data sources. クエリを必要としないビジュアルは、それらが DirectQuery に基づいている場合でもインポートされます。Visuals that don't require a query are imported even if they're based on DirectQuery. この機能はパフォーマンスの向上とバック エンドの負荷の軽減に役立ちます。This feature helps improve performance and reduce back-end load. 以前は、スライサーなどの、シンプルなビジュアルでも、バックエンド ソースに送信されるクエリが開始されました。Previously, even simple visuals, such as slicers, began queries that were sent to back-end sources. 詳細については、「Power BI Desktop のストレージ モード」をご覧ください。For more information, see Storage mode in Power BI Desktop.

多対多カーディナリティのリレーションシップによって解決されるものWhat a relationship with a many-many cardinality solves

"多対多カーディナリティのリレーションシップ" が利用可能になるまでは、2 つのテーブル間のリレーションシップは Power BI で定義されていました。Before relationships with a many-many cardinality became available, the relationship between two tables was defined in Power BI. リレーションシップに関係する少なくとも 1 つのテーブルの列に、一意の値を含める必要がありました。At least one of the table columns involved in the relationship had to contain unique values. しかし多くの場合、一意の値を含む列はありませんでした。Often, though, no columns contained unique values.

たとえば、2 つのテーブルに Country というラベルが付いた列があるとします。For example, two tables might have had a column labeled Country. しかし、どちらのテーブルでも Country の値が一意ではありませんでした。The values of Country weren't unique in either table, though. このようなテーブルを結合するには、回避策を用意する必要がありました。To join such tables, you had to create a workaround. 1 つの回避策として、必要な一意の値を持つ追加のテーブルを導入することが考えられます。One workaround might be to introduce extra tables with the needed unique values. "多対多カーディナリティのリレーションシップ" では、"多対多" のカーディナリティを持つリレーションシップを使用する場合に、このようなテーブルを直接結合することができます。With relationships with a many-many cardinality, you can join such tables directly, if you use a relationship with a cardinality of many-to-many.

多対多カーディナリティのリレーションシップを使用するUse relationships with a many-many cardinality

Power BI で 2 つのテーブル間のリレーションシップを定義する場合、リレーションシップのカーディナリティを定義する必要があります。When you define a relationship between two tables in Power BI, you must define the cardinality of the relationship. たとえば、ProductSales と Product の間のリレーションシップ —ProductSales[ProductCode] と Product[ProductCode] を使用する— は、"多対一" として定義されます。For example, the relationship between ProductSales and Product—using columns ProductSales[ProductCode] and Product[ProductCode]—would be defined as Many-1. リレーションシップをこのように定義するのは、各製品に対して多くの売上が存在し、Product テーブル内の列 (ProductCode) が一意であるためです。We define the relationship in this way, because each product has many sales, and the column in the Product table (ProductCode) is unique. リレーションシップのカーディナリティを "多対一"、"一対多"、または "一対一" として定義すると、Power BI によってそれが検証されるため、選択したカーディナリティが実際のデータと一致します。When you define a relationship cardinality as Many-1, 1-Many, or 1-1, Power BI validates it, so the cardinality that you select matches the actual data.

たとえば、この画像のシンプルなモデルを見てみましょう。For example, take a look at the simple model in this image:

ProductSales および Product テーブル、リレーションシップ ビュー、Power BI Desktop

ここで、Product (製品) で次の 2 つの行のみが表示されているとします。Now, imagine that the Product table displays just two rows, as shown:

2 つの行を含む Product テーブルのビジュアル、Power BI Desktop

また、Sales テーブルには、製品 C の行を含め、4 行しかないとします。参照整合性エラーのため、製品 C の行は Product テーブルには存在しません。Also imagine that the Sales table has just four rows, including a row for a product C. Because of a referential integrity error, the product C row doesn't exist in the Product table.

4 つの行を含む Sales テーブルのビジュアル、Power BI Desktop

ProductNamePrice (Product テーブルからのもの)、および各製品の合計 Qty (ProductSales テーブルからのもの) は、次のように表示されます。The ProductName and Price (from the Product table), along with the total Qty for each product (from the ProductSales table), would be displayed as shown:

製品名、価格、および数量が表示されたビジュアル、Power BI Desktop

前の画像からわかるように、空白の ProductName 行は製品 C の売上に関連付けられています。この空白行は次のことを示しています。As you can see in the preceding image, a blank ProductName row is associated with sales for product C. This blank row accounts for the following:

  • Product (製品) テーブルに対応する行が存在しない、ProductSales (製品売上) テーブルの任意の行がある。Any rows in the ProductSales table for which no corresponding row exists in the Product table. この例の製品 C の場合のように、参照整合性の問題が存在する。There's a referential integrity issue, as we see for product C in this example.

  • 外部キー列が null である ProductSales (製品売上) テーブルの行がある。Any rows in the ProductSales table for which the foreign key column is null.

これらの理由により、どちらの場合の空白行も、ProductName (製品名) と Price (価格) が不明な売上を示しています。For these reasons, the blank row in both cases accounts for sales where the ProductName and Price are unknown.

テーブルが 2 つの列で結合されていても、どちらの列も一意ではない場合があります。Sometimes the tables are joined by two columns, yet neither column is unique. たとえば、これらのテーブルについて考えてみます。For example, consider these two tables:

  • Sales (売上) テーブルでは、State (州) 別の売上データが表示されており、各行にはその州の売上の種類が含まれています。The Sales table displays sales data by State, and each row contains the sales amount for the type of sale in that state. 州はカリフォルニア州、ワシントン州、テキサス州などです。The states include CA, WA, and TX.

    州別の売上が表示されている Sales テーブル、Power BI Desktop

  • CityData テーブルでは、人口や州 (カリフォルニア州、ワシントン州、テキサス州など) を含む、市区町村に関するデータが表示されています。The CityData table displays data on cities, including the population and state (such as CA, WA, and New York).

    市区町村、州、および人口が表示されている Sales テーブル、Power BI Desktop

これで、State の列が両方のテーブルに含まれるようになりました。A column for State is now in both tables. 州ごとの総売上と、各州の総人口の両方についてレポートすることをお勧めします。It's reasonable to want to report on both total sales by state and total population of each state. しかし、問題があります。State 列がどちらのテーブルでも一意ではありません。However, a problem exists: the State column isn't unique in either table.

以前の回避策The previous workaround

Power BI Desktop の 2018 年 7 月のリリースより前では、これらのテーブル間に直接のリレーションシップを作成することはできませんでした。Before the July 2018 release of Power BI Desktop, you couldn't create a direct relationship between these tables. 以下が一般的な回避策でした。A common workaround was to:

  • 一意の State ID のみを含む 3 番目のテーブルを作成します。Create a third table that contains only the unique State IDs. テーブルには、次のいずれか、またはすべてを指定できます。The table could be any or all of:

    • 計算テーブル (Data Analysis Expressions [DAX] を使用して定義されたもの)。A calculated table (defined by using Data Analysis Expressions [DAX]).
    • クエリ エディターで定義されたクエリに基づくテーブル。テーブルのいずれかから抽出された一意の ID を表示する場合があります。A table based on a query that's defined in Query Editor, which could display the unique IDs drawn from one of the tables.
    • 結合された完全なセット。The combined full set.
  • 次に、一般的な "多対一" リレーションシップを使用して、2 つの元のテーブルをその新しいテーブルに関連付けます。Then relate the two original tables to that new table by using common Many-1 relationships.

回避策テーブルは表示したままでかまいません。You could leave the workaround table visible. または、回避策テーブルを非表示にして、 [フィールド] のリストに表示されないようにすることもできます。Or you may hide the workaround table, so it doesn't appear in the Fields list. テーブルを非表示にする場合、"多対一" リレーションシップが一般的に両方向にフィルター処理するように設定され、いずれのテーブルからでも State フィールドを使用できます。If you hide the table, the Many-1 relationships would commonly be set to filter in both directions, and you could use the State field from either table. この後のクロス フィルタリングは、もう 1 つのテーブルに反映されます。The later cross filtering would propagate to the other table. このアプローチを次の図に示します。That approach is shown in the following image:

非表示の State テーブル、ProductSales ビュー、Power BI Desktop

State (州) (CityData (市区町村データ) テーブル) と共に合計の Population (人口) と合計の Sales (売上) を表示するビジュアルは、次のようになります。A visual that displays State (from the CityData table), along with total Population and total Sales, would then appear as follows:

State (州)、Population (人口)、Sales (売上) の各データを示すスクリーンショット。

注意

この回避策では CityData テーブルの州が使用されるため、そのテーブルの州のみがリストされます。したがって、テキサス州は除外されます。Because the state from the CityData table is used in this workaround, only the states in that table are listed, so TX is excluded. また、"多対一" リレーションシップとは異なり、合計行にはすべての Sales (テキサス州のデータを含む) が含まれますが、このような不一致の行を対象とする空白行は含まれません。Also, unlike Many-1 relationships, while the total row includes all Sales (including those of TX), the details don't include a blank row covering such mismatched rows. 同様に、State が null 値の Sales を対象とする空白行はありません。Similarly, no blank row would cover Sales for which there's a null value for the State.

また、そのビジュアルに City を追加するとします。Suppose you also add City to that visual. 市区町村ごとの人口はわかっていますが、City に対して表示される Sales では、対応する StateSales が単に繰り返されます。Although the population per City is known, the Sales shown for City simply repeats the Sales for the corresponding State. このシナリオは通常、ここに示すように、列のグループ化が集計メジャーと関連付けられていない場合に発生します。This scenario normally occurs when the column grouping is unrelated to some aggregate measure, as shown here:

州と都市の人口と売上、Power BI Desktop

たとえば、ここですべての州の組み合わせとして新しい Sales テーブルを定義し、 [フィールド] リストに表示されるようにするとします。Let's say you define the new Sales table as the combination of all States here, and we make it visible in the Fields list. 同じビジュアルで、(新しいテーブルに) StatePopulation の合計、および Sales の合計が表示されます。The same visual would display State (on the new table), the total Population, and total Sales:

州、人口、売上のビジュアル、Power BI Desktop

ご覧のように、TX — Sales データはあるが "Population" データは不明 — と New York — Population データはわかっているが Sales データがない — が含まれます。As you can see, TX—with Sales data but unknown Population data—and New York—with known Population data but no Sales data—would be included. この回避策は最適ではなく、多くの問題を含んでいます。This workaround isn't optimal, and it has many issues. 多対多カーディナリティのリレーションシップの場合は、次のセクションで説明するように、発生する問題に対処します。For relationships with a many-many cardinality, the resulting issues are addressed, as described in the next section.

回避策ではなく、多対多カーディナリティのリレーションシップを使用するUse a relationship with a many-many cardinality instead of the workaround

2018 年 7 月バージョンの Power BI Desktop では、前に説明したもののようなテーブルを直接関連付けることができます。同様の回避策を利用する必要はありません。With the July 2018 version of Power BI Desktop, you can directly relate tables, such as the ones we described earlier, without having to resort to similar workarounds. リレーションシップのカーディナリティを "多対多" に設定できるようになりました。It's now possible to set the relationship cardinality to many-to-many. この設定は、どちらのテーブルにも一意の値が含まれていないことを示しています。This setting indicates that neither table contains unique values. そのようなリレーションシップでも、他のテーブルをフィルター処理するテーブルを制御できます。For such relationships, you may still control which table filters the other table. または、テーブルで相互にフィルター処理を行う、双方向のフィルター処理を適用することができます。Or you can apply bidirectional filtering, where each table filters the other.

Power BI Desktop では、いずれのテーブルにもリレーションシップ列に一意の値が含まれていないと判断された場合、カーディナリティは既定で "多対多" に設定されます。In Power BI Desktop, the cardinality defaults to many-to-many when it determines neither table contains unique values for the relationship columns. このような場合は、リレーションシップの設定と、変更がデータの問題による意図しない結果ではないことを確認する警告メッセージが表示されます。In such cases, a warning message confirms you want to set a relationship, and the change isn't the unintended effect of a data issue.

たとえば、CityData と Sales 間に直接リレーションシップを作成する —ここではフィルターのフローが CityData から Sales になるようにする必要があります— 場合、Power BI Desktop で [リレーションシップの編集] ダイアログ ボックスが表示されます。For example, when you create a relationship directly between CityData and Sales—where filters should flow from CityData to Sales—Power BI Desktop displays the Edit relationship dialog box:

[リレーションシップの編集] ダイアログボックス、Power BI Desktop

その結果、 [リレーションシップ] ビューには、2 つのテーブル間に直接かつ多対多のリレーションシップが表示されるようになります。The resulting Relationship view would then display the direct, many-to-many relationship between the two tables. [フィールド] リストでのテーブルの外観と、ビジュアルの作成時のその後の動作は、回避策を適用した場合と似ています。The tables' appearance in the Fields list, and their later behavior when the visuals are created, are similar to when we applied the workaround. 回避策では、個別の State データを表示する追加のテーブルは表示されません。In the workaround, the extra table that displays the distinct State data isn't made visible. 前述のとおり、StatePopulation、および Sales データを表示するビジュアルが表示されます。As described earlier, a visual that shows State, Population, and Sales data would be displayed:

State、Population、Sales のテーブル、Power BI Desktop

"多対多カーディナリティのリレーションシップ" と、より一般的な "多対一" のリレーションシップの主な違いは、次のとおりです。The major differences between relationships with a many-many cardinality and the more typical Many-1 relationships are as follows:

  • 表示される値に、もう一方のテーブルの一致しない行を示す空白行が含まれません。The values shown don't include a blank row that accounts for mismatched rows in the other table. また、もう一方のテーブルのリレーションシップで使用される列が null である行を示す値も含まれません。Also, the values don't account for rows where the column used in the relationship in the other table is null.

  • 複数の行が関連する可能性があるため、RELATED() 関数を使用することはできません。You can't use the RELATED() function, because more than one row could be related.

  • テーブルに ALL() 関数を使用しても、多対多のリレーションシップによって関連付けられているもう一方のテーブルに適用されているフィルターは削除されません。Using the ALL() function on a table doesn't remove filters that are applied to other, related tables by a many-to-many relationship. 前の例では、以下に示すように定義されているメジャーでは、関連する CityData テーブルの列に対するフィルターは削除されません。In the preceding example, a measure that's defined as shown here wouldn't remove filters on columns in the related CityData table:

    スクリプトの例

    StateSales、および Sales total のデータを表示するビジュアルは、この図のようになります。A visual showing State, Sales, and Sales total data would result in this graphic:

    テーブルのビジュアル

前述の相違点に注意しながら、ALL(<Table>) を使用する計算 ("合計に対する割合" など) で、意図した結果が返されることを確認します。With the preceding differences in mind, make sure the calculations that use ALL(<Table>), such as % of grand total, are returning the intended results.

制限事項と考慮事項Limitations and considerations

このリリースの "多対多カーディナリティのリレーションシップ" と複合モデルには、いくつかの制限事項があります。There are a few limitations for this release of relationships with a many-many cardinality and composite models.

次の Live Connect (多次元) ソースは、複合モデルでは使用できません。The following Live Connect (multidimensional) sources can't be used with composite models:

  • SAP HANASAP HANA
  • SAP Business WarehouseSAP Business Warehouse
  • SQL Server Analysis ServicesSQL Server Analysis Services
  • Power BI データセットPower BI datasets
  • Azure Analysis ServicesAzure Analysis Services

DirectQuery を使用してこれらの多次元ソースに接続すると、別の DirectQuery ソースに接続することも、これをインポートしたデータと結合することもできません。When you connect to these multidimensional sources by using DirectQuery, you can't connect to another DirectQuery source or combine it with imported data.

DirectQuery を使用する際の既存の制限は、"多対多カーディナリティのリレーションシップ" を使用する場合にも適用されます。The existing limitations of using DirectQuery still apply when you use relationships with a many-many cardinality. 多くの制限事項が、テーブルのストレージ モードに応じて、テーブルごとに適用されるようになりました。Many limitations are now per table, depending upon the storage mode of the table. たとえば、インポートしたテーブルの計算列からは他のテーブルを参照できますが、DirectQuery テーブルの計算列からは引き続き同じテーブルの列しか参照できません。For example, a calculated column on an imported table can refer to other tables, but a calculated column on a DirectQuery table can still refer only to columns on the same table. モデル内のいずれかのテーブルが DirectQuery である場合、モデル全体に他の制限事項が適用されます。Other limitations apply to the whole model if any tables within the model are DirectQuery. たとえば、モデル内のいずれかのテーブルにストレージ モードの DirectQuery がある場合、そのモデルでは QuickInsights と Q&A 機能を使用できません。For example, the QuickInsights and Q&A features are unavailable on a model if any table within it has a storage mode of DirectQuery.

次の手順Next steps

複合モデルと DirectQuery について詳しくは、次の記事をご覧ください。For more information about composite models and DirectQuery, see the following articles: