テーブルが複数ある場合、それらのすべてのテーブルからデータを使用して分析を実行する可能性が高くなります。 結果を正確に計算し、レポートに正しい情報を表示するためには、これらのテーブル間のリレーションシップが必要です。 ほとんどの場合、何もする必要はありません。 自動検出機能によって自動的に実行されます。 ただし、場合によっては、自分でリレーションシップを作成したり、リレーションシップを変更したりすることが必要な場合があります。 いずれの場合も、Power BI Desktop におけるリレーションシップおよびその作成方法と編集方法を理解することが重要です。
読み込み中の自動検出
データが読み込まれるときに、同時に複数のテーブルのクエリを実行する場合、Power BI Desktop はリレーションシップの検索および作成を試みます。 リレーションシップのオプション [カーディナリティ] 、 [クロス フィルターの方向] 、 [このリレーションシップをアクティブにする] は、自動的に設定されます。 Power BI Desktop では、クエリを実行しているテーブルの列名が調べられて、潜在的なリレーションシップがあるかどうかが判断されます。 そのようなリレーションシップがある場合は、自動的に作成されます。 Power BI Desktop によって高いレベルの信頼度で一致するものがあると判断できない場合、リレーションシップは作成されません。 ただし、その場合でも、 [リレーションシップの管理] ダイアログ ボックスを使用して、手動でリレーションシップを作成または編集できます。
自動検出を使用してリレーションシップを作成する
[モデリング] タブで、[リレーションシップの管理]>[自動検出] の順に選択します。
手動でのリレーションシップの作成
[モデリング] タブで、[リレーションシップの管理]>[新規] の順に選択します。
[リレーションシップの作成] ダイアログ ボックスで、最初のテーブルのドロップダウン リストからテーブルを選択します。 リレーションシップで使用する列を選択します。
2 番目のテーブルのドロップダウン リストで、リレーションシップに必要なもう一方のテーブルを選択します。 使用する他の列を選択し、[OK] を選択します。
既定では、新しいリレーションシップの [カーディナリティ] (方向)、 [クロス フィルターの方向] 、 [このリレーションシップをアクティブにする] の各オプションは、Power BI Desktop によって自動的に構成されます。 ただし、これらの設定は必要に応じて変更できます。 詳しくは、「詳細設定オプションについて」をご覧ください。
リレーションシップに対して選択したどのテーブルにも一意の値がない場合は、次のエラーが表示されます: "いずれかの列に、一意の値が必要です"。 リレーションシップの少なくとも 1 つのテーブルに別個の (一意の) キー値リストが含まれている必要があります。これはあらゆるリレーショナル データベース技術における共通の要件です。
このエラーに遭遇した場合、いくつかの方法で問題を解決できます。
- [重複の削除] を使用して、一意の値を含む列を作成します。 この方法の短所は、重複行が削除されると、情報が失われる可能性があることです。 多くの場合、キー (行) は正当な理由があって複製されています。
- 個別キー値の一覧で構成される中間テーブルをモデルに追加します。このモデルがリレーションシップの両方の元の列にリンクされます。
詳細については、こちらのブログ記事を参照してください。
または、モデル ビューのダイアグラム レイアウトで、あるテーブルの列を他のテーブルの列にドラッグしてリレーションシップを作成できます。
リレーションシップの編集
Power BI でリレーションシップを編集するには 2 つの方法があります。
リレーションシップを編集する最初の方法として、[モデル ビュー] の [プロパティ] ペインでリレーションシップの編集を使用します。この場合、2 つのテーブル間の任意の行を選択して、[プロパティ] ペインにリレーションシップ オプションを表示できます。 必ず [プロパティ] ペインを展開して、リレーションシップのオプションを確認してください。
![[プロパティ] ペインでのリレーションシップの調整のスクリーンショット。](media/desktop-create-and-manage-relationships/relationships-options-03.png)
また、[プロパティ] ペインでリレーションシップを編集するビデオ デモを見ることもできます。
リレーションシップを編集する別の方法として、リレーションシップ エディター ダイアログを使用します。これにより、Power BI Desktop 内からさまざまな方法で開くことができます。 次の一覧は、リレーションシップ エディター ダイアログを開くさまざまな方法を示しています。
レポート ビューで、次のいずれかの操作を行います。
- [モデリング] リボン >[リレーションシップの管理] を選択してから、リレーションシップを選択し、[編集] を選択します。
- [フィールド] 一覧のテーブルを選択し、[テーブル ツール] リボン >[リレーションシップの管理] を選択してから、リレーションシップを選択し、[編集] を選択します。
[テーブル] ビューから、[テーブル ツール] リボン >[リレーションシップの管理] を選択してから、リレーションシップを選択し、[編集] を選択します。
[モデル] ビューで、次のいずれかの操作を行います。
- [ホーム] リボン >[リレーションシップの管理] を選択してから、リレーションシップを選択し、[編集] を選択します。
- 2 つのテーブル間の任意の行をダブルクリックします。
- 2 つのテーブル間の任意の行を右クリックし、[プロパティ] を選択します。
- 2 つのテーブル間の任意の行を選択し、[プロパティ] ペインで [リレーションシップ エディターを開く] を選択します。
最後に、任意のビューからリレーションシップを編集することもできます。右クリックするか省略記号を選択し、任意のテーブルのコンテキスト メニューに移動したら、[リレーションシップの管理] を選択して、リレーションシップを選択し、[編集] を選択します。
次の画像は、[リレーションシップの編集] ウィンドウのスクリーン ショットを示しています。
![[リレーションシップの編集] ウィンドウのスクリーンショット。](media/desktop-create-and-manage-relationships/relationships-options-04.png)
さまざまな方法を使用したリレーションシップの編集
リレーションシップの編集ダイアログの使用は、Power BI でリレーションシップを編集するためのより詳しいガイド付きのエクスペリエンスで、現在プレビュー段階です。 各テーブルのデータのプレビューを確認できます。 異なる列を選択したときに、ウィンドウによってリレーションシップが自動的に検証され、適切なカーディナリティとクロス フィルターの選択項目が提供されます。
[プロパティ] ペインでのリレーションシップの編集は、Power BI でリレーションシップを編集するための効率化されたアプローチです。 表示されるのは、選択可能なテーブル名と列だけで、データのプレビューや行ったリレーションシップの選択は、[変更を適用] を選択した場合にのみ検証されます。 [プロパティ] ペインとその効率化されたアプローチを使用すると、リレーションシップの編集時に生成されるクエリの数が減り、これは、ビッグデータのシナリオで (特に DirectQuery の接続を使用したときに) 重要になる場合があります。 [プロパティ] ペインを使用して作成されたリレーションシップも、リレーションシップの編集ダイアログで作成を許可されたリレーションシップより高度になる場合があります。
また、Ctrl キーを押しながら複数の行を選択して複数のリレーションシップを選択することで、[モデル] ビュー ダイアグラム レイアウトでリレーションシップを複数選択することもできます。 共通プロパティは [プロパティ] ペインで編集でき、[変更の適用] では 1 つのトランザクション内での変更が処理されます。
単一または複数選択されたリレーションシップは、キーボードの Delete キーを押して削除することもできます。 削除操作を取り消すことはできません (そのため、リレーションシップの削除を確認するダイアログが表示されます)。
重要
[プロパティ] ペインでのリレーションシップの編集機能は、現在プレビュー段階です。 プレビュー段階では、機能とドキュメントが変更される可能性があります。 Power BI Desktop でこの機能を有効にする必要があります。そのためには、[ファイル] > [オプションと設定] > [オプション] > [プレビュー機能] に移動し、GLOBAL セクションで、リレーションシップ ペインの横にあるチェックボックスをオンにします。
追加のオプションを構成する
リレーションシップを作成または編集するときは、追加のオプションを構成できます。 既定では、Power BI Desktop により、最善の推測に基づいて追加のオプションが自動的に構成されます。これは、列のデータに応じてリレーションシップごとに異なる可能性があります。
カーディナリティ
[カーディナリティ] オプションには、次のいずれかの設定を指定できます。
- 多対 1 (*:1): 多対 1 のリレーションシップは最も一般的なものであり、既定の種類のリレーションシップです。 つまり、一方のテーブル内の列には、1 つの値の複数のインスタンスが存在していてもよく、関連するもう一方のテーブル (多くの場合ルックアップ テーブルとして知られる) では 1 つの値のインスタンスは 1 つだけです。
- 一対一 (1:1) : 一対一のリレーションシップでは、一方のテーブル内の列には特定の値のインスタンスが 1 つだけあり、関連するもう一方のテーブルも、特定の値のインスタンスは 1 つだけです。
- 一対多 (1:*) : 一対多のリレーションシップでは、一方のテーブル内の列には特定の値のインスタンスが 1 つだけあり、関連するもう一方のテーブルには、ある値のインスタンスが複数存在していてもかまいません。
- 多対多 (*:*): 複合モデルでは、テーブル間に多対多のリレーションシップを確立できます。これにより、テーブル内に一意の値を含めるという要件は取り除かれます。 また、リレーションシップを作成するためだけに新しいテーブルを導入するなどの以前の回避策も除外されます。 詳しくは、多対多カーディナリティのリレーションシップに関する記事をご覧ください。
どのようなときにカーディナリティを変更するのかについて詳しくは、「詳細設定オプションについて」をご覧ください。
クロス フィルターの方向
[クロス フィルターの方向] オプションには、次のいずれかの設定を指定できます。
双方向: フィルター処理の場合は、両方のテーブルが 1 つのテーブルであるかのように扱われます。 [双方向] の設定は、周囲に複数のルックアップ テーブルが存在する 1 つのテーブルの場合に、うまく機能します。 一例として、部門のルックアップ テーブルのある販売実績テーブルがあります。 この構成は、多くの場合、スター スキーマ構成 (複数のルックアップ テーブルと 1 つの中心テーブル) と呼ばれます。 ただし、複数のルックアップ テーブル (一部は共通) を含むテーブルが 2 つ以上ある場合は、双方向の設定を使用しません。 前の例で言えば、この場合、各部門のターゲット予算を記録する予算売上テーブルもあるということです。 そして、部門テーブルが、売上テーブルと予算のテーブルの両方に接続されます。 この種の構成には、双方向の設定を使わないようにします。
単一: 最も一般的な、既定の方向です。接続されたテーブルでのフィルター処理の選択内容が、値が集約されているテーブルに対して機能することを意味します。 Excel 2013 以前のデータ モデルに Power Pivot をインポートすると、すべてのリレーションシップが一方向になります。
どのようなときにクロス フィルターの方向を変更するのかについて詳しくは、「詳細設定オプションについて」をご覧ください。
このリレーションシップをアクティブにする
オンにすると、リレーションシップはアクティブな既定のリレーションシップとして機能します。 2 つのテーブル間に複数のリレーションシップがある場合、両方のテーブルを含む視覚化を Power BI Desktop が自動的に作成するには、アクティブなリレーションシップが使用されます。
どのようなときに特定のリレーションシップをアクティブにするかについて詳しくは、「詳細設定オプションについて」をご覧ください。
リレーションシップについて
2 つのテーブルをリレーションシップで接続すると、両方のテーブルのデータを 1 つのテーブルのように作業できます。 リレーションシップの詳細を気にしたり、テーブルをインポートする前に 1 つのテーブルにフラット化したりする必要はなくなります。 多くの場合、Power BI Desktop ではリレーションシップを自動的に作成できます。 ただし、2 つのテーブル間にリレーションシップが存在することがかなり確実に特定できる場合以外、Power BI Desktop ではリレーションシップは自動的に作成されません。 その場合は、手動で行う必要があります。
Power BI Desktop でのリレーションシップのしくみを理解できるように、簡単なチュートリアルを見てみましょう。
ヒント
このレッスンは自分で行うことができます。
- 次の ProjectHours テーブルを Excel のワークシートにコピーし (タイトルを除く)、すべてのセルを選択して、[挿入]>[テーブル] を選択します。
- [テーブルの作成] ダイアログ ボックスで、 [OK] を選択します。
- テーブルの任意のセルを選択し、[テーブル デザイン]>[テーブル名] を選択して、「ProjectHours」と入力します。
- CompanyProject テーブルについても同じ操作を行います。
- Power BI Desktop の [データを取得] を使用して、データをインポートします。 データソースとして 2 つのテーブルを選択し、 [読み込み] を選択します。
最初のテーブル ProjectHours は、ある人が特定のプロジェクトで作業した時間数を記録する作業チケットのレコードです。
ProjectHours
| Ticket | SubmittedBy | Hours | Project | DateSubmit |
|---|---|---|---|---|
| 1001 | ブルワー、アラン | 22 | ブルー | 2013 年 1 月 1 日 |
| 1002 | ブルワー、アラン | 26 | レッド | 2013 年 2 月 1 日 |
| 1003 | 伊藤 秀 | 34 | イエロー | 2012 年 12 月 4 日 |
| 1004 | ブルワー、アラン | 13 | オレンジ | 2012 年 1 月 2 日 |
| 1005 | Bowen、Eli | 29 | 紫 | 2013/10/1 |
| 1006 | ベント,ヌノ | 35 | グリーン | 2013 年 2 月 1 日 |
| 1007 | ハミルトン、David | 10 | イエロー | 2013/10/1 |
| 1008 | Han、Mu | 28 | オレンジ | 2012 年 1 月 2 日 |
| 1009 | 伊藤 秀 | 22 | 紫 | 2013 年 2 月 1 日 |
| 1010 | Bowen、Eli | 28 | グリーン | 2013/10/1 |
| 1011 | Bowen、Eli | 9 | ブルー | 2013 年 10 月 15 日 |
2 番目のテーブル CompanyProject は、次の優先度が割り当てられたプロジェクトの一覧です: A、B、C。
CompanyProject
| ProjName | Priority |
|---|---|
| ブルー | A |
| レッド | B |
| グリーン | C |
| イエロー | C |
| 紫 | B |
| オレンジ | C |
各テーブルにプロジェクトの列があることに注意してください。 それぞれのテーブルで名前はわずかに異なりますが、値は同じように見えます。 この違いは重要です。後でまた説明します。
2 つのテーブルをモデルにインポートしたので、レポートを作成してみましょう。 最初に取得するものは、プロジェクトの優先度ごとに送信された時間数です。そのため、 [フィールド] ペインから Priority と Hours を選択します。
![[フィールド] ペインで選択された [Priority] と [Hours] フィールドのスクリーンショット。](media/desktop-create-and-manage-relationships/candmrel_reportfiltersnorel.png)
レポート キャンバスでテーブルを見ると、各プロジェクトの時間数が 256 で、これが合計でもあることがわかります。 この値は明らかに正しくありません。 なぜでしょうか。 理由は、2 つのテーブル間にリレーションシップがない状態では、1 つのテーブルの値 (ProjectHours テーブルの Hours) の合計を、別のテーブルの値 (CompanyProject テーブルの Priority) でスライスして計算することはできないためです。
そこで、これら 2 つのテーブル間のリレーションシップを作成しましょう。
両方のテーブルのプロジェクト名が含まれる列を見たとき、値が似ていたことを覚えていますか。 ここでは、これら 2 つの列を使用して、テーブル間のリレーションシップを作成します。
なぜこれらの列なのでしょうか。 ProjectHours テーブルの Project 列を見ると、ブルー、レッド、イエロー、オレンジなどの値があります。 そして、いくつかの行が同じ値を持っていることがわかります。 実際、Project には多数の色の値があります。
CompanyProject テーブルの ProjName 列を見ると、プロジェクト名の色の値ごとに 1 つの色の値だけがあります。 このテーブルの各色の値は一意です。このことは、これら 2 つのテーブル間にリレーションシップを作成できるようになるという点で重要です。 この場合は、多対一リレーションシップです。 多対一のリレーションシップでは、いずれかのテーブルの少なくとも 1 つの列に一意の値が含まれる必要があります。 一部のリレーションシップには他にも追加のオプションがあります。これについては後で説明します。 ここでは、2 つの各テーブルのプロジェクト列の間にリレーションシップを作成します。
リレーションシップを新規作成するには
[モデリング] タブで、[リレーションシップの管理] を選択します。
[リレーションシップの管理] で、[新規] を選択して [リレーションシップの作成] ダイアログ ボックスを開きます。ここでは、リレーションシップに必要なテーブル、列、その他の設定を選択できます。
最初のドロップダウン リストで、最初のテーブルとして ProjectHours を選択してから、Project 列を選択します。 こちらは、リレーションシップの "*多" の側になります。
2 番目のドロップダウン リストでは、2 番目のテーブルとして CompanyProject が既に選択されています。 ProjName 列を選択します。 この側は、リレーションシップの "一" の側になります。
リレーションシップのオプションは既定値のままにして、 [OK] を選択します。
![[リレーションシップの作成] ダイアログのスクリーンショット。](media/desktop-create-and-manage-relationships/candmrel_create_compproj.png)
[リレーションシップの管理] ダイアログ ボックスで、 [閉じる] を選択します。
すべてを示すために、ここではリレーションシップを厳密な方法で作成しました。 [リレーションシップの管理] ダイアログ ボックスの [自動検出] も選択できました。 実際、両方の列の名前が同じ場合は、データを読み込むと、自動検出によってリレーションシップが自動的に作成されます。
ここで、もう一度レポート キャンバスで、テーブルを見てみましょう。
![[フィールド] ペインで選択された [Priority] と [Hours] フィールドの新しいリレーションシップのスクリーンショット。](media/desktop-create-and-manage-relationships/candmrel_reportfilterswithrel.png)
全体的な見た目が良くなっています。
Priority ごとに時間数を集計すると、Power BI Desktop によって、CompanyProject ルックアップ テーブルで一意の色の値のすべてのインスタンスが検索され、ProjectHours テーブルでそれらの各値に対するすべてのインスタンスが検索された後、一意の値ごとに合計が計算されます。
自動検出を使用すると、これらの操作さえ不要な可能性があります。
詳細設定オプションについて
自動検出または手動でリレーションシップを作成する場合、Power BI Desktop により、テーブル内のデータに基づいて詳細設定オプションが自動的に構成されます。 リレーションシップのこれらの詳細オプションは、 [リレーションシップの作成] および [リレーションシップの編集] ダイアログ ボックスの下部にあります。
![[カーディナリティ] と [クロス フィルターの方向] オプションを示す [リレーションシップの作成] ダイアログ ボックスの下部のスクリーンショット。](media/desktop-create-and-manage-relationships/candmrel_advancedoptions2.png)
Power BI では通常、これらのオプションが自動的に設定されるため、調整の必要はありません。 ただし、これらのオプションを自分で構成しなければならない状況もあります。
リレーションシップの自動更新
レポートおよびモデル内のリレーションシップを Power BI で処理し、自動的に調整する方法を管理できます。 Power BI によるリレーションシップ オプションの処理方法を指定するには、Power BI Desktop の [ファイル]>[オプションと設定]>[オプション] を選択し、左側のペインで [データの読み込み] を選択します。 [リレーションシップ] のオプションが表示されます。
![[データの読み込み] タブの [リレーションシップ] 設定を示す [オプション] ボックスのスクリーンショット。](media/desktop-create-and-manage-relationships/relationships-options-01.png)
選択して有効にすることができるオプションが 3 つあります。
[最初の読み込みでデータ ソースからリレーションシップをインポートします] : 既定では、このオプションはオンになっています。 オンにすると、データ ウェアハウス内の外部キーと主キーのリレーションシップなど、データ ソースで定義されているリレーションシップが Power BI によって確認されます。 このようなリレーションシップが存在する場合は、データを最初に読み込むときに、これらのリレーションシップが Power BI データ モデルに反映されます。 このオプションを使用すると、自分でリレーションシップを検索または定義する必要がなく、モデルの操作をすぐに開始できます。
[データを更新する際にリレーションシップを更新または削除します] : 既定では、このオプションはオフになっています。 オンにすると、セマンティック モデルが更新されたときに、Power BI によってデータ ソースのリレーションシップの変更が確認されます。 これらのリレーションシップが変更または削除された場合、Power BI では、それらの変更を独自のデータ モデルでミラー化し、同じになるように更新または削除を行います。
警告
定義されたリレーションシップに依存する行レベルのセキュリティを使用している場合は、このオプションをオンにしないことをお勧めします。 RLS の設定が依存しているリレーションシップを削除すると、モデルのセキュリティが低下する可能性があります。
[データが読み込まれた後に新しいリレーションシップを自動検出する] : このオプションについては、「読み込み中の自動検出」で説明しています。
データの今後の更新には、異なるカーディナリティが必要になります。
通常、Power BI Desktop は、リレーションシップに最適なカーディナリティを自動的に判断できます。 今後データが変更されることがわかっているため、自動設定をオーバーライドする必要がある場合は、 [カーディナリティ] コントロールで変更できます。 異なるカーディナリティを選択する必要がある場合の例を見てみましょう。
CompanyProjectPriority テーブルは、会社のプロジェクトとその優先度の一覧です。 ProjectBudget テーブルは、予算が承認されたプロジェクトのセットです。
CompanyProjectPriority
| ProjName | Priority |
|---|---|
| ブルー | A |
| レッド | B |
| グリーン | C |
| イエロー | C |
| 紫 | B |
| オレンジ | C |
ProjectBudget テーブル
| 承認済みプロジェクト | BudgetAllocation | AllocationDate |
|---|---|---|
| ブルー | 40,000 | 2012 年 12 月 1 日 |
| レッド | 100,000 | 2012 年 12 月 1 日 |
| グリーン | 50,000 | 2012 年 12 月 1 日 |
ProjectBudget テーブルの Approved Projects 列と、CompanyProjectPriority テーブルの ProjectName 列の間にリレーションシップを作成すると、Power BI によって自動的に、 [カーディナリティ] は [一対一 (1:1)] に、 [クロス フィルターの方向] は [双方向] に設定されます。
![[カーディナリティ] が 1 対 1 (1:1) で、[クロス フィルターの方向] が [両方] の [リレーションシップの作成] ダイアログ ボックスのスクリーンショット。](media/desktop-create-and-manage-relationships/candmrel_create_compproj_appproj2.png)
Power BI によってこのような設定が行われる理由は、Power BI Desktop にとって 2 つのテーブルの最適な組み合わせは次のようなものであるためです。
| ProjName | Priority | BudgetAllocation | AllocationDate |
|---|---|---|---|
| ブルー | A | 40,000 | 2012 年 12 月 1 日 |
| レッド | B | 100,000 | 2012 年 12 月 1 日 |
| グリーン | C | 50,000 | 2012 年 12 月 1 日 |
| イエロー | C | ||
| 紫 | B | ||
| オレンジ | C |
結合されたテーブルの ProjName 列には値の繰り返しがないため、2 つのテーブル間には一対一のリレーションシップがあります。 各値が 1 回のみ発生するため、ProjName 列は一意です。したがって、2 つのテーブルの行を重複なしで直接結合することができます。
しかし、次回データを更新すると、データが変更されることが分かっているとしましょう。 更新後の ProjectBudget テーブルには、ブルーとレッドのプロジェクトの行が追加されています。
ProjectBudget
| 承認済みプロジェクト | BudgetAllocation | AllocationDate |
|---|---|---|
| ブルー | 40,000 | 2012 年 12 月 1 日 |
| レッド | 100,000 | 2012 年 12 月 1 日 |
| グリーン | 50,000 | 2012 年 12 月 1 日 |
| ブルー | 80,000 | 2013 年 6 月 1 日 |
| レッド | 90,000 | 2013 年 6 月 1 日 |
追加されたこれらの行は、2 つのテーブルの最適な組み合わせが次のようになることを意味します。
| ProjName | Priority | BudgetAllocation | AllocationDate |
|---|---|---|---|
| ブルー | A | 40,000 | 2012 年 12 月 1 日 |
| レッド | B | 100,000 | 2012 年 12 月 1 日 |
| グリーン | C | 50,000 | 2012 年 12 月 1 日 |
| イエロー | C | ||
| 紫 | B | ||
| オレンジ | C | ||
| ブルー | A | 80000 | 2013 年 6 月 1 日 |
| レッド | B | 90000 | 2013 年 6 月 1 日 |
この結合された新しいテーブルでは、ProjName 列に値の繰り返しがあります。 テーブルが更新されると、元の 2 つのテーブルに一対一のリレーションシップはなくなります。 この場合、今後の更新によって ProjName 列に重複が生じることがわかっているため、[カーディナリティ] を [多対 1 (*:1)] に設定する必要があります。"多" の側は ProjectBudget で、1 の側は CompanyProjectPriority です。
複雑なテーブルとリレーションシップのセットでクロス フィルターの方向を調整する
ほとんどのリレーションシップでは、クロス フィルターの方向は双方向に設定されています。 ただし、このオプションを既定とは異なる方法で設定する必要がある、一般的でない状況もあります。 たとえば、古いバージョンの Power Pivot からモデルをインポートしている場合、すべてのリレーションシップが 1 つの方向に設定されています。
[双方向] に設定すると、Power BI Desktop では、接続されたテーブルのすべての側面を、1 つのテーブルであるかのように扱えるようになります。 ただし、状況によっては、Power BI Desktop がリレーションシップのクロス フィルターの方向を双方向に設定できず、レポート作成のために使用できる既定値のセットを曖昧さのない状態に維持できない場合もあります。 リレーションシップのクロス フィルターの方向が双方向に設定されていない場合、通常は曖昧さが生じていることが原因です。 既定のクロス フィルターの設定が適切でない場合は、特定のテーブルに対して設定するか、双方向に設定してみてください。
一方向のクロス フィルターは、多くの状況で機能します。 実際に、Excel 2013 以前の Power Pivot からモデルをインポートした場合、すべてのリレーションシップは一方向に設定されます。 一方向とは、接続されたテーブルでのフィルター処理の選択内容が、集約作業が発生しているテーブルで機能することを意味します。 クロス フィルター処理を理解することは少し難しいことがあるので、例を見てみましょう。
一方向のクロス フィルターを使用すると、プロジェクトの時間数をまとめたレポートを作成する場合、CompanyProject テーブルとその Priority 列または CompanyEmployee テーブルとその City 列でまとめる (またはフィルター処理する) ことができます。 ただし、プロジェクトごとの従業員数をカウントする場合 (あまり一般的なテーマではありません) は機能しません。 すべてが同じ値の列が得られます。 次の例では、両方のリレーションシップのクロス フィルターの方向を、ProjectHours テーブルへの一方向に設定しています。 [値] ウェルでは、Project フィールドが Count に設定されています。
![[Employee] と [Project] フィールドで使用される [視覚化] タブのスクリーンショット。](media/desktop-create-and-manage-relationships/candmrel_repcrossfiltersingle.png)
フィルターの指定では、CompanyProject から ProjectHours へは流れますが (次の図に示すように)、CompanyEmployee に向かっては流れません。
![[CompanyProject] から [ProjectHours] へのフローを含むクロス フィルターの例の図。](media/desktop-create-and-manage-relationships/candmrel_singledircrossfiltering.png)
ただし、クロス フィルターの方向を双方向に設定すると、流れるようになります。 [双方向] に設定すると、フィルターの指定で CompanyEmployee に向かって流れるように指定できます。
クロス フィルターの方向を [双方向] に設定すると、レポートが正しく表示されるようになります。
![クロス フィルターの方向が [両方] に設定されているスクリーンショット。](media/desktop-create-and-manage-relationships/candmrel_repcrossfilterbi.png)
先に示したパターンのようなテーブルのリレーションシップのパターンでは、双方向のクロス フィルターが適切に機能します。 このスキーマの最も一般的な呼び方はスター スキーマで、次のようなものです。
クロス フィルターの方向は、この図のように、データベースによく見られるより一般的なパターンでは適切に機能しません。
このようなループがあるテーブルのパターンの場合、クロス フィルターによりあいまいなリレーションシップのセットが作成されます。 たとえば、TableX のフィールドを合計してから、TableY のフィールドでフィルター処理する場合、フィルター処理が上のテーブルを通るのか、下のテーブルを通るのか、どのように進むかが明確ではありません。 この種のパターンの一般的な例は、TableX を実際のデータを含む売上テーブルとして使用し、TableY を予算のデータに使用するというものです。 次に、中央のテーブルは、部門や地域など、両方のテーブルが使用するルックアップ テーブルです。
アクティブと非アクティブのリレーションシップのように、レポートで曖昧さが生じる場合、Power BI Desktop ではリレーションシップを双方向に設定することはできません。 このような状況は、いくつかの方法で対処できます。 最も一般的なものは次の 2 つです。
- あいまいさを減らすため、リレーションシップを削除するか、非アクティブとしてマークする。 その後、リレーションシップのクロス フィルターを双方向に設定できる場合があります。
- ループをなくすために、テーブルを 2 回指定する (2 回目は異なる名前で)。 このようにすると、リレーションシップのパターンはスター スキーマのようになります。 スター スキーマでは、すべてのリレーションシップを双方向に設定できます。
正しくないアクティブなリレーションシップ
Power BI Desktop が自動的にリレーションシップを作成する際、2 つのテーブル間に複数のリレーションシップが作成される場合があります。 このような状況が発生すると、1 つのリレーションシップだけがアクティブに設定されます。 アクティブなリレーションシップは、既定のリレーションシップとして機能します。それにより、2 つの異なるテーブルからフィールドを選択すると、Power BI Desktop で自動的に視覚エフェクトを作成できるようになります。 ただし、場合によっては、自動的に選択したリレーションシップが正しくないことがあります。 [リレーションシップの管理] ダイアログ ボックスを使用して、リレーションシップをアクティブまたは非アクティブに設定します。または、 [リレーションシップの編集] ダイアログ ボックスで、アクティブなリレーションシップを設定します。
既定のリレーションシップが確実にあるようにするため、Power BI Desktop では、特定の時点で 2 つのテーブル間に許可されるアクティブなリレーションシップは 1 つだけです。 したがって、まず、現在のリレーションシップを非アクティブにしてから、アクティブにするリレーションシップを設定する必要があります。
例を見てみましょう。 1 つ目のテーブルは ProjectTickets で、2 つ目のテーブルは EmployeeRole です。
ProjectTickets
| Ticket | OpenedBy | SubmittedBy | Hours | Project | DateSubmit |
|---|---|---|---|---|---|
| 1001 | Perham、Tom | ブルワー、アラン | 22 | ブルー | 2013 年 1 月 1 日 |
| 1002 | ローマン、ダニエル | ブルワー、アラン | 26 | レッド | 2013 年 2 月 1 日 |
| 1003 | Roth、Daniel | 伊藤 秀 | 34 | イエロー | 2012 年 12 月 4 日 |
| 1004 | Perham、Tom | ブルワー、アラン | 13 | オレンジ | 2012 年 1 月 2 日 |
| 1005 | ローマン、ダニエル | Bowen、Eli | 29 | 紫 | 2013/10/1 |
| 1006 | Roth、Daniel | ベント,ヌノ | 35 | グリーン | 2013 年 2 月 1 日 |
| 1007 | Roth、Daniel | ハミルトン、David | 10 | イエロー | 2013/10/1 |
| 1008 | Perham、Tom | Han、Mu | 28 | オレンジ | 2012 年 1 月 2 日 |
| 1009 | ローマン、ダニエル | 伊藤 秀 | 22 | 紫 | 2013 年 2 月 1 日 |
| 1010 | Roth、Daniel | Bowen、Eli | 28 | グリーン | 2013/10/1 |
| 1011 | Perham、Tom | Bowen、Eli | 9 | ブルー | 2013 年 10 月 15 日 |
EmployeeRole
| Employee | ロール |
|---|---|
| ベント,ヌノ | プロジェクト マネージャー |
| Bowen、Eli | プロジェクト リーダー |
| ブルワー、アラン | プロジェクト マネージャー |
| ハミルトン、David | プロジェクト リーダー |
| Han、Mu | プロジェクト リーダー |
| 伊藤 秀 | プロジェクト リーダー |
| Perham、Tom | プロジェクト スポンサー |
| ローマン、ダニエル | プロジェクト スポンサー |
| Roth、Daniel | プロジェクト スポンサー |
ここには 2 つのリレーションシップが存在しています。
- EmployeeRole テーブルの Employee と、ProjectTickets テーブルの SubmittedBy の間。
- ProjectTickets テーブルの OpenedBy と、EmployeeRole テーブルの Employee の間。
モデルに両方のリレーションシップを追加した場合 (OpenedBy が先)、 [リレーションシップの管理] ダイアログ ボックスでは OpenedBy がアクティブであることが表示されます。
![[リレーションシップの管理] ダイアログ ボックスで [OpenedBy] がアクティブになっているスクリーンショット。](media/desktop-create-and-manage-relationships/candmrel_managerelactive.png)
ここで、レポート キャンバスのテーブルの視覚化に含まれる EmployeeRole の Role フィールドと Employee フィールド、および ProjectTickets の Hours フィールドを使用してレポートを作成すると、プロジェクト スポンサーのみが表示されます。これは、プロジェクト チケットを開いたのがプロジェクト スポンサーのみであるためです。
![スクリーンショットには、[Employee]、[Role]、[Hours] の各フィールドが選択されています。](media/desktop-create-and-manage-relationships/candmrel_repcrossfilteractive.png)
アクティブなリレーションシップを変更すると、OpenedBy ではなく SubmittedBy を取得することができます。 [リレーションシップの管理] で、ProjectTickets(OpenedBy) から EmployeeRole(Employee) へのリレーションシップをオフにした後、EmployeeRole(Employee) から Project Tickets(SubmittedBy) へのリレーションシップをオンにします。
![[リレーションシップの管理] ダイアログ ボックスでアクティブなリレーションシップを変更するスクリーンショット。](media/desktop-create-and-manage-relationships/candmrel_managerelactivesubmittedby.png)
リレーションシップ ビューですべてのリレーションシップを表示する
場合によっては、モデルに複数のテーブルがあり、それらのテーブル間に複雑なリレーションシップが含まれることがあります。 Power BI Desktop の [リレーションシップ] ビューでは、モデル内のすべてのリレーションシップ、その方向、カーディナリティが、わかりやすくカスタマイズ可能なダイアグラムに表示されます。
詳しくは、「Power BI Desktop でリレーションシップ ビューを操作する」をご覧ください。
トラブルシューティング
このセクションでは、Power BI でリレーションシップを操作する場合のガイダンスとトラブルシューティング情報を提供します。
フィールド間のリレーションシップを判断できない
Power BI では、使用されているモデルからリレーションシップを推測することにより、関連するデータをビジュアルに表示しようとします。 このような推測は明確ではない場合があり、特定の列の間にリレーションシップがないことを示すエラーがビジュアルに表示されて驚くことがあります。
Power BI で、フィールドが関連しているかどうかがどのように判断されるかを説明するために、以降のセクションでは、モデルの例を使用して、いくつかのシナリオについて説明します。 次の図は、シナリオ例で使用するサンプル モデルを示しています。
シナリオ 1: 従来のスター スキーマ、メジャー制約なし。 前の図のサンプル モデルを参照して、まず、Vendor - Purchases - Product の各テーブルがある図の右半分を見てみましょう。 この例は、ファクト テーブル ([Purchases]) と 2 つのディメンション テーブル ([Product] と [Vendor]) を含む従来のスター スキーマです。 ディメンション テーブルとファクト テーブルの間のリレーションシップは、1 対多 です (1 つの製品が多数の購入に対応し、1 つのベンダーが多数の購入に対応します)。 この種類のスキーマでは、"製品 X の売上はどのくらいか?"、"ベンダー Y の売上はどのくらいか"、"ベンダー Y で販売されている製品は何か?" などの質問に答えることができます。
[Products] と [Vendors] を関連付ける必要がある場合、[Purchases] テーブルを調べて、同じ製品とベンダーを含むエントリがあるかどうかを確認します。 サンプル クエリは次の例のようになります。
Correlate Product[Color] with Vendor[Name] where CountRows(Purchases)>0
where CountRows(Purchases)>0 は、関連するデータが返されることを保証するために Power BI で追加される暗黙的な制約です。
Purchases テーブルを介してこの関連付けを行うことにより、ファクト テーブルに少なくとも 1 つのエントリがある製品とベンダーのペア (データから見て意味のあるペア) を返すことができます。 販売されたことがない (分析には役に立たない) 製品とベンダーの意味のない組み合わせは表示されないと想定できます。
シナリオ 2: 従来のスター スキーマ、メジャー制約あり。 シナリオ 1 の前の例では、ユーザーが要約列 (たとえば、Sum、Average、Count of Purchase Qty) またはモデル メジャー (Distinct Count of VendID) の形式で制約を指定すると、Power BI では、次の例のような形式でクエリを生成できます。
Correlate Product[Color] with Vendor[Name] where MeasureConstraint is not blank
このような場合、Power BI では、ユーザーが指定した制約に対して意味のある値 (空白以外) を持つ組み合わせを返そうとします。 ユーザーによって提供された制約で十分であるため、Power BI では、前のシナリオ 1 で追加されたような CountRows(Purchases)>0 などの独自の暗黙的な制約を追加する必要もありません。
シナリオ 3: 非スター スキーマ、メジャー制約なし。 このシナリオでは、Sales - Product - Purchases の各テーブルがあるモデルの中央に注目します。ここには、1 つのディメンション テーブル (Product) と 2 つのファクト テーブル (Sales、Purchases) があります。 この例はスター スキーマではないため、シナリオ 1 と同じ種類の質問に答えることはできません。 [Purchases] と [Sales] を関連付けようとするとしましょう。[Purchases] には、[Product] との "多対 1" のリレーションシップがあり、[Product] には、[Sales] との "1 対多" のリレーションシップがあります。 [Sales] と [Purchase] は、間接的に "多対多" です。 1 つの [Product] を多数の [Purchases] に関連付け、1 つの [Product] を多数の Sale に関連付けることができますが、1 つの [Sale] を多数の [Purchases] に関連付けることはできません。また、その逆の関連付けもできません。 多数の Purchases を多数の Salesにのみ関連付けることができます。
このような状況では、ビジュアルで Purchase[VenID] と Sales[CustID] を組み合わせようとすると、これらのテーブルの間は "多対多"のリレーションシップであるため、Power BI には、適用可能な具体的な制約はありません。 さまざまなシナリオに適用できるカスタム制約 (必ずしもモデルで確立されたリレーションシップから生じるとは限りません) がある場合でも、Power BI では、リレーションシップのみに基づいて既定の制約を推測することはできません。 Power BI で 2 つのテーブルのすべての組み合わせを返そうとすると、大きなクロス結合が作成され、関連性のないデータが返されることになります。 このため、Power BI では、代わりに、ビジュアルで次のようなエラーを発生させます。
シナリオ 4: 非スター スキーマ、メジャー制約あり。 シナリオ 3 の例を取り上げ、ユーザー提供の制約を要約列 (たとえば、Count of Product[ProdID])、またはモデル メジャー (Sales[Total Qty]) の形式で追加すると、Power BI では、Correlate Purchase[VenID] および Sales[CustID] の形式でクエリを生成できます。この場合、MeasureConstraint は空白ではありません。
この場合、Power BI は、ユーザーの制約を、Power BI が適用する必要のある唯一の制約として尊重し、空白以外の値を生成する組み合わせを返します。 ユーザーは目的のシナリオを Power BI にガイドし、Power BI はそのガイダンスを適用します。
シナリオ 5: メジャー制約は提供されているが、それが列に部分的に関連している場合。 ユーザーが提供するメジャー制約が、ビジュアル内のすべての列全体には関連していない場合があります。 モデル メジャーは常にすべてを関連付けます。 Power BI では、ビジュアル内の列間のリレーションシップを検出しようとするときに、このシナリオをブラック ボックスとして扱い、ユーザーがそれを使用して何をしているかを認識していると想定します。 ただし、Sum、Average の形式の要約列、およびユーザー インターフェイスから選択された同様の要約は、その列が属するテーブルのリレーションシップに基づいて、ビジュアルで使用される列またはテーブルのサブセットのみに関連付けることができます。 そのため、制約は、列の一部のペアに適用されますが、すべてには適用されません。 その場合、Power BI では、ユーザーが指定した制約 (シナリオ 1 など) によって関連付けられていない列に適用できる既定の制約を見つけようとします。 見つからない場合、Power BI により、次のエラーが返されます。
リレーションシップ エラーの解決
フィールド間の関係を決定できません というエラーが表示された場合、次の手順を実行して、エラーの解決を試みることができます。
モデルを確認します。 分析から回答を得る質問の種類に合わせて適切に設定されていますか? テーブル間のリレーションシップの一部を変更できますか? 間接的な "多対多" の作成を回避できますか?
逆 V 字形スキーマを 2 つのテーブルに変換し、「Power BI Desktop で多対多リレーションシップを適用する」で説明されているように、それらの間に直接的な "多対多" のリレーションシップを使用することを検討してください。
要約列またはモデル メジャーの形式で制約をビジュアルに追加します。
要約列を追加してもエラーが発生する場合は、モデル メジャーの使用を検討してください。
関連するコンテンツ
モデルとリレーションシップの詳細については、次の各記事を参照してください。