Power BI Desktop で複合モデルを使用する

以前の Power BI Desktop では、レポートに DirectQuery を使用した場合、そのレポートで他のデータ接続は (DirectQuery またはインポートにかかわらず) 許可されませんでした。 複合モデルでは、その制限が除外されます。 複数の DirectQuery またはインポート データ接続からのデータ接続を、任意の組み合わせでシームレスにレポートに含めることができるようになりました。

Power BI Desktop の複合モデル機能は、3 つの関連する機能で構成されています。

  • 複合モデル:1 つまたは複数の DirectQuery 接続およびインポート接続、2 つ以上の DirectQuery 接続、またはそれらの任意の組み合わせなど、さまざまなソース グループからの 2 つ以上のデータ接続をレポートに含めることができます。 この記事では、複合モデルについて詳しく説明します。

  • 多対多のリレーションシップ:複合モデルでは、テーブル間で "多対多のリレーションシップ" を確立することができます。 このアプローチでは、テーブル内の一意の値の要件が除外されます。 また、リレーションシップを作成するためだけに新しいテーブルを導入するなどの以前の回避策も除外されます。 詳細については、「Power BI Desktop で多対多リレーションシップを適用する」を参照してください。

  • ストレージ モード:どのビジュアルでバックエンド データ ソースをクエリするかを指定できるようになりました。 クエリを必要としないビジュアルは、それらが DirectQuery に基づいている場合でもインポートされます。 この機能はパフォーマンスの向上とバック エンドの負荷の軽減に役立ちます。 以前は、スライサーなどのシンプルなビジュアルでも、バックエンド ソースへのクエリが開始されていました。 詳細については、「Power BI Desktop でストレージ モードを管理する」をご覧ください。

複合モデルを使用する

複合モデルを使用すると、Power BI Desktop または Power BI サービスを使用するときに、さまざまな種類のデータ ソースに接続することができます。 それらのデータ接続は、いくつかの方法で行うことができます。

  • Power BI にデータをインポートする方法 (データを取得する最も一般的な方法です)。
  • DirectQuery を使用して、元のソース リポジトリ内のデータに直接接続する方法。 DirectQuery について詳しくは、「Power BI で DirectQuery を使用する」をご覧ください。

DirectQuery を使用するときに複合モデルを使用すると、以下のアクションのいずれかまたは両方を実行する Power BI モデル (単一の .pbix Power BI Desktop ファイルなど) を作成できます。

  • 1 つ以上の DirectQuery ソースのデータを結合する。
  • DirectQuery ソースのデータとインポート データを結合する。

たとえば、複合モデルを使用すると、次の種類のデータを結合するモデルを構築できます。

  • エンタープライズ データ ウェアハウスの売上データ。
  • 部門の SQL Server データベース内にある売上目標のデータ。
  • スプレッドシートからインポートしたデータ。

複数の DirectQuery ソースのデータを結合したモデル、または DirectQuery とインポート データを結合したモデルは、複合モデルと呼ばれます。

テーブル間のリレーションシップは、テーブルが異なるソースからのものであっても、いつもと同様に作成できます。 異なるソース間のリレーションシップは、実際のカーディナリティに関係なく、多対多のカーディナリティで作成されます。 これらは、一対多、多対一、または一対一に変更できます。 どのカーディナリティを設定しても、ソース間のリレーションシップの動作は異なります。 Data Analysis Expressions (DAX) 関数を使用して one 側の値を many 側から取得することはできません。 また、同じソース内の多対多のリレーションシップとの比較において、パフォーマンスへの影響が見られる場合があります。

注意

複合モデルのコンテキスト内では、実際の基のデータ ソースにかかわらず、すべてのインポート元テーブルは、実質的には単一のソースになります。

複合モデルの例

複合モデルの例として、DirectQuery を使用して SQL Server 内の会社のデータ ウェアハウスに接続されているレポートを考えます。 この例のデータ ウェアハウスには、次の図に示すように、Sales by Country (国別売上)、Quarter (四半期)、Bike (Product) (自転車 (製品)) のデータが含まれています。

複合モデルのリレーションシップ ビュー

この段階では、このソースのフィールドを使用して簡単なビジュアルを作成できます。 選択した四半期の合計売上高を ProductName (製品名) 別に表示する図を次に示します。

データに基づくビジュアル

しかし、各製品に割り当てられたプロダクト マネージャーに関するデータが、マーケティングの優先順位と共に、Office Excel スプレッドシート内で管理されている場合はどうでしょうか。 Product Manager (プロダクト マネージャー) 別の Sales Amount (売上高) を確認する必要がある場合、このローカル データを会社のデータ ウェアハウスに追加することは不可能である可能性があります。 または、うまくいっても数か月かかるかもしれません。

DirectQuery を使用する代わりに、データ ウェアハウスからその売上データをインポートできる場合があります。 また、その売上データを今度はスプレッドシートからインポートしたデータと結合できる場合があります。 ただし、DirectQuery を使用するそもそもの理由を考えると、この方法は合理的ではありません。 次のような理由が考えられます。

  • 基になるソースに適用されるセキュリティ規則の組み合わせ。
  • 最新のデータを確認できる必要がある。
  • 膨大な量のデータ。

このような場合に、複合モデルが役立ちます。 複合モデルを使用すると、DirectQuery を使用してデータ ウェアハウスに接続し、追加のソースに対して [データの取得] を使用できます。 この例では、最初に会社のデータ ウェアハウスへの DirectQuery 接続を確立します。 [データの取得] を使用して [Excel] を選択した後、ローカル データを含むスプレッドシートに移動します。 最後に、Product Names (製品名)、割り当てられた Sales Manager (セールス マネージャー)、および Priority (優先度) を含むスプレッドシートをインポートします。

[ナビゲーター] ウィンドウ

[フィールド] リストには、2 つのテーブルが表示されます。SQL Server の元の Bike テーブルと、新しい Product Managers テーブルです。 新しいテーブルには、Excel からインポートされたデータが含まれます。

テーブルのフィールド ビュー

同様に、Power BI Desktop の [リレーションシップ] ビューには、Product Managers という追加のテーブルが表示されています。

テーブルのリレーションシップ ビュー

次は、これらのテーブルをモデルの他のテーブルに関連付ける必要があります。 通常どおり、SQL Server の Bike テーブルとインポートされた ProductManagers テーブル間のリレーションシップを作成します。 つまり、Bike[ProductName]ProductManagers[ProductName] の間のリレーションシップです。 前述のように、ソース間にわたるすべてのリレーションシップは、既定で多対多のカーディナリティになります。

[リレーションシップの作成] ウィンドウ

これでこのリレーションシップの作成が完了したので、想定どおりに Power BI Desktop の [リレーションシップ] ビューに表示されます。

新しいリレーションシップ ビュー

[フィールド] リストの任意のフィールドを使用してビジュアルを作成できるようになりました。 この方法では、複数のソースのデータがシームレスに混在しています。 たとえば、Product Manager (プロダクト マネージャー) ごとの SalesAmount (売上高) の合計を次の図に示します。

フィールド ウィンドウ

次の例では、別の場所からインポートした追加データを使用して拡張された "ディメンション" テーブル (Product (製品) や Customer (顧客) など) の一般的なケースを示します。 テーブルで DirectQuery を使用して、さまざまなソースに接続することもできます。 引き続きこの例を使用して、Country (国) 別と Period (期間) 別の SalesTargets (売り上げ目標) が個別の部門データベースに格納されているとします。 次の図のように、通常どおりに [データの取得] を使用してそのデータに接続できます。

[ナビゲーター] ウィンドウ

前の手順と同様に、新しいテーブルとモデル内の他のテーブルの間にリレーションシップを作成し、そのテーブルのデータを結合するビジュアルを作成することができます。 [リレーションシップ] ビューをもう一度確認すると、新しいリレーションシップが確立されています。

多数のテーブルがあるリレーションシップ ビュー

次の図は、新しいデータと作成したリレーションシップに基づいています。 左下のビジュアルに合計の Sales Amount (売上合計) と Target (目標) が表示され、分散計算でその差が示されています。 Sales Amount (売上合計) と Target (目標) は、2 つの異なる SQL Server データベースのデータです。

多数のデータが表示されている図

ストレージ モードを設定する

複合モデルの各テーブルには、テーブルが DirectQuery とインポートのどちらに基づいているかを示すストレージ モードがあります。 ストレージ モードは、 [プロパティ] ウィンドウで表示および変更できます。 ストレージ モードを表示するには、 [フィールド] リスト内のテーブルを右クリックし、 [プロパティ] を選択します。 SalesTargets (売り上げ目標) テーブルのストレージ モードを次の図に示します。

ストレージ モードは、各テーブルのツールヒント上でも確認できます。

ストレージ モードを表示するツールヒント

いくつかの DirectQuery のテーブルといくつかのインポート テーブルを含む Power BI Desktop ファイル ( .pbix ファイル) の場合、ステータス バーには [混合] というストレージ モードが表示されます。 ステータス バーのその単語をクリックすると、すべてのテーブルを簡単に [インポート] に切り替えることができます。

ストレージ モードについて詳しくは、「Power BI Desktop でストレージ モードを管理する」をご覧ください。

注意

Power BI Desktop と Power BI サービスでは、 [混合] ストレージ モードを使用できます。

計算テーブル

DirectQuery を使用するモデルに計算テーブルを追加することができます。 計算テーブルを定義する Data Analysis Expressions (DAX) は、インポート テーブル、DirectQuery テーブル、またはその両方の組み合わせを参照できます。

計算テーブルは常にインポートされ、テーブルを更新するとそのデータが更新されます。 計算テーブルが DirectQuery テーブルを参照している場合、DirectQuery テーブルを参照するビジュアルには、基になるソースの最新の値が常に表示されます。 または、計算テーブルを参照するビジュアルには、計算テーブルが最後に更新されたときの値が表示されます。

セキュリティへの影響

複合モデルには、セキュリティへの影響がいくつかあります。 1 つのデータ ソースに送信されるクエリには、別のソースから取得されたデータ値を含めることができます。 前述の例では、Product Manager (プロダクト マネージャー) 別の Sales Amount (売上高) を表示するビジュアルによって、Sales (売上) リレーショナル データベースに SQL クエリが送信されます。 その SQL クエリには、Product Managers (プロダクト マネージャー) の名前とそれらに関連付けられた Products (製品) の名前を含めることができます。

セキュリティへの影響を示すスクリプト

その結果、スプレッドシートに格納されている情報が、リレーショナル データベースに送信されるクエリに含まれるようになりました。 これが機密情報である場合は、セキュリティへの影響を考慮する必要があります。 具体的には、次の点を検討してください。

  • トレースまたは監査ログを表示できるデータベースの管理者は、元のソースのデータに対するアクセス許可を持っていなくても、この情報を表示できます。 この例では、管理者には Excel ファイルに対するアクセス許可が必要です。

  • 各ソースの暗号化設定を考慮する必要があります。 暗号化された接続を使用して 1 つのソースから情報を取得した後、暗号化されていない接続を使用して別のソースに送信されるクエリにその情報を誤って含めないようにする必要があります。

あらゆるセキュリティへの影響が考慮されていることを確認するために、Power BI Desktop では、複合モデルを作成するときに警告メッセージが表示されます。

さらに、作成者が Table1 を "モデル A" から複合モデル (参照用に "モデルC" と呼びます) に追加した場合、"モデル C" で作成されたレポートを表示しているユーザーは、RLS によって保護されていない "モデル A" の 任意のテーブル に対してクエリを実行することが可能です。

同様の理由から、信頼できないソースから送信された Power BI Desktop ファイルを開くときには注意が必要です。 ファイルに複合モデルが含まれている場合、そのファイルを開くユーザーの資格情報を使用して、だれかがあるソースから取得した情報が、クエリの一部として別のデータ ソースに送信される場合があります。 その情報は、Power BI Desktop ファイルの悪意のある作成者によって閲覧される可能性があります。 複数のソースを含む Power BI Desktop ファイルを最初に開くときに、Power BI Desktop によって警告が表示されます。 この警告は、ネイティブの SQL クエリを含むファイルを開くときに表示される警告と似ています。

パフォーマンスへの影響

DirectQuery を使用する場合は、常にパフォーマンスを考慮する必要があります。これは主に、バックエンド ソースに十分なリソースがあることを確認して、良好なユーザー エクスペリエンスを提供するためです。 良好なエクスペリエンスとは、ビジュアルが 5 秒以内に更新されるということです。 パフォーマンスに関するアドバイスについては、「Power BI での DirectQuery の使用について」を参照してください。

複合モデルを使用する場合、その他のパフォーマンスの考慮事項が追加されます。 1 つのビジュアルによって複数のソースにクエリが送信される場合があり、この場合は、1 つのクエリの結果が 2 番目のソースに渡されることがよくあります。 このような状況では、次のような実行の形式になる可能性があります。

  • 多数のリテラル値を含む SQL クエリ:たとえば、選択した Product Managers (プロダクト マネージャー) のセットに関する合計の Sales Amount (売上高) を要求するビジュアルの場合、まずそのプロダクト マネージャーが管理した Products (製品) を検索する必要があります。 このシーケンスは、WHERE 句にすべての製品 ID を含む SQL クエリがビジュアルによって送信される前に発生する必要があります。

  • 低いレベルの粒度でクエリを実行する SQL クエリ (データは後でローカルで集計されます) :Product Manager (プロダクト マネージャー) に対するフィルターの条件を満たす Products (製品) の数が多くなるにつれて、すべての製品を WHERE 句に含めることが非効率または不可能になる場合があります。 代わりに、Product (製品) の下位レベルでリレーショナル ソースにクエリを実行した後、ローカルでその結果を集計することができます。 Products (製品) のカーディナリティが 100 万の制限を超えると、クエリは失敗します。

  • 複数の SQL クエリ、値ごとに各グループで 1 つ:集計で DistinctCount が使用され、別のソースの列によってグループ化されるときに、外部ソースでグループ化を定義する多数のリテラル値を効率的に渡す処理がサポートされていない場合は、値ごとに各グループで 1 つの SQL クエリを送信する必要があります。

    スプレッドシートからインポートされる Product Manager (プロダクト マネージャー) ごとに SQL Server テーブルの CustomerAccountNumber (顧客アカウント番号) の個別の数を要求するビジュアルの場合、SQL Server に送信されるクエリで Product Managers (プロダクト マネージャー) テーブルの詳細を渡す必要があります。 他のソース (Redshift など) を使用する場合、このアクションは使用できません。 代わりに、Sales Manager (セールス マネージャー) ごとに 1 つの SQL クエリが送信されます。この送信は、クエリが失敗する実用限界まで実行されます。

これらの各ケースは、パフォーマンスに独自の影響を及ぼします。その詳細は各データ ソースによって異なります。 2 つのソースを結合するリレーションシップで使用される列のカーディナリティは低いまま (数千) であり、パフォーマンスへの影響はありません。 このカーディナリティが大きくなるほど、結果として得られるパフォーマンスへの影響をさらに注意する必要があります。

さらに、多対多のリレーションシップの使用は、詳細な値をローカルで集計するのではなく、合計または小計レベルごとに、独立したクエリが基のソースに送信されることを意味します。 合計がある単純なテーブル ビジュアルでは、1 つではなく 2 つの SQL クエリを送信します。

制限事項と考慮事項

このリリースの複合モデルには、いくつかの制限事項があります。

現在、SQL、Oracle、Teradata データ ソースにのみ接続する複合モデルに対しては、増分更新がサポートされています。

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

  • SAP HANA
  • SAP Business Warehouse
  • SQL Server Analysis Services
  • Power BI データセット
  • Azure Analysis Services

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

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

次の手順

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