Power BI Desktop または Power BI サービスを使用すると、あらゆる種類のデータ ソースに、さまざまな方法で接続できます。 Power BI へのデータの "インポート" は、最もよく使われるデータ取得方法です。または、元のソース リポジトリ内のデータに直接接続することもでき、これは DirectQuery と呼ばれます。 この記事では DirectQuery とその機能について説明します。内容は次のとおりです。

  • DirectQuery のさまざまな接続オプション
  • インポートではなく DirectQuery の使用を検討する必要があるときのためのガイダンス
  • DirectQuery を使用する欠点
  • DirectQuery を使用する場合のベスト プラクティス

インポートと DirectQuery を使用する場合のベスト プラクティスを比較すると次のようになります。

  • 可能な場合は常に、Power BI にデータをインポートする必要があります。 この方法は、Power BI の高パフォーマンス クエリ エンジンを活用し、データに対する高い対話性とあらゆる機能を備えたエクスペリエンスを提供します。

  • データのインポートでは目的を達成できない場合にのみ、DirectQuery の使用を検討します。 たとえば、頻繁に変更されるデータの最新の状態をレポートに反映する必要がある場合は、DirectQuery が最適である可能性があります。 ただし、一般に、DirectQuery を使うのが適しているのは、基になるデータ ソースが一般的な集計クエリに対する対話型クエリを (5 秒未満で) 提供でき、生成されるクエリの負荷を処理できる場合のみです。 さらに、DirectQuery の使用に付随する制限事項の一覧を慎重に検討し、それでも目的を達成できることを確認する必要があります。

インポートと DirectQuery の両方の接続モードに対して Power BI が提供する機能のセットは、今後も徐々に拡充されます。 これには、インポートしたデータを使用するときの柔軟性の向上 (インポートを使用できるケースの増加など) や、DirectQuery を使用するときのいくつかの欠点の除去などが含まれます。 機能強化に関係なく、DirectQuery を使うときは、基になるデータ ソースのパフォーマンスが常に大きな考慮事項になります。 基になるデータ ソースが遅い場合、そのソースで DirectQuery を使うことはできません。

このトピックでは、Power BI での DirectQuery の使用について説明します。SQL Server Analysis Services については説明しません。 DirectQuery は SQL Server Analysis Services の機能でもあり、ここで説明する詳細の多くは SQL Server Analysis Services にも当てはまりますが、重要な相違点もあります。 SQL Server Analysis Services での DirectQuery の使用については、SQL Server Analysis Services 2016 での DirectQuery の詳細に関するホワイトペーパーをご覧ください。

この記事で注目する DirectQuery の推奨されるワークフローではレポートを Power BI Desktop で作成しますが、Power BI サービスでの直接接続についても説明します。

Power BI の接続モード

Power BI は、次のような非常に多くの多様なデータ ソースに接続します。

  • オンライン サービス (Salesforce、Dynamics 365、その他)
  • データベース (SQL Server、Access、Amazon Redshift、その他)
  • 単純なファイル (Excel、JSON、その他)
  • その他のデータ ソース (Spark、Web サイト、Microsoft Exchange、その他)

これらのソースについて、通常は Power BI にデータをインポートできます。 一部については、DirectQuery を使って接続することもできます。 DirectQuery をサポートしているソースについて詳しくは、「DirectQuery でサポートされるデータ ソース」をご覧ください。 今後、主に優れた対話型クエリ パフォーマンスを提供できるソースという観点から、DirectQuery に対応するソースが増えるものと思われます。

SQL Server Analysis Services は特殊なケースです。 SQL Server Analysis Services に接続するときは、データのインポートまたは "ライブ接続" の使用を選択できます。 ライブ接続は、データがインポートされず、表示を更新するときに基になるデータ ソースが常にクエリされる点は DirectQuery と似ていますが、"ライブ接続" は他の多くの点で異なるため、異なる用語 ("ライブ" と "DirectQuery") が使われています。

以下では、これら 3 つのデータ接続オプション (インポートDirectQueryライブ接続) について詳しく説明します。

インポートの接続

Power BI Desktop[データの取得] を使用して SQL Server などのデータ ソースに接続し、[インポート] を選択した場合、接続の動作は次のようになります。

  • 最初の [データの取得] エクスペリエンスの間に、選択した各テーブル セットによってデータ セットを返すクエリが定義されます (データを読み込む前にこれらのクエリを編集し、フィルターの適用、データの集計、異なるテーブルの結合などを行うことができます)。
  • 読み込みでは、クエリによって定義されているすべてのデータが Power BI のキャッシュにインポートされます。
  • Power BI Desktop で視覚エフェクトを作成するときに、インポートされたデータのクエリが行われます。 Power BI ストアにより非常に高速なクエリが行われるため、視覚エフェクトに対する変更はすべてすぐに反映されます。
  • 基のデータに対する変更は、どの視覚エフェクトにも反映されません。 データが再インポートされたら直ちに、"更新" を行う必要があります。
  • レポート (.pbix ファイル) を Power BI サービスに発行すると、データセットが作成されて、Power BI サービスにアップロードされます。 インポートされたデータは、そのデータセットに含まれます。 その後は、そのデータの更新スケジュールを設定できます (たとえば、毎日データを再インポート)。 元のデータ ソースの場所によっては、オンプレミス データ ゲートウェイの構成が必要になる場合があります。
  • 既存のレポートを Power BI サービスで開くと、または新しいレポートを作成すると、インポートされたデータのクエリが再び行われて、対話性が保証されます。
  • 視覚エフェクトまたはレポート ページ全体を、ダッシュボード タイルとしてピン留めできます。 基になるデータセットが更新されるたびに、タイルは自動的に更新されます。

DirectQuery の接続

Power BI Desktop[データの取得] を使用してデータ ソースに接続し、[DirectQuery] を選択した場合、接続の動作は次のようになります。

  • 最初の [データの取得] エクスペリエンスの間に、ソースが選択されます。 リレーショナル ソースの場合、一連のテーブルが選択され、それぞれにおいて論理的にデータ セットを返すクエリが定義されます。 SAP BW などの多次元ソースでは、ソースのみが選択されます。
  • ただし、読み込み時には、データは実際には Power BI ストアにインポートされません。 代わりに、Power BI Desktop での視覚エフェクトの作成時に、クエリが基になるデータ ソースに送信されて、必要なデータが取得されます。 視覚エフェクトの更新にかかる時間は、基になるデータ ソースのパフォーマンスによって異なります。
  • 基のデータに対する変更は、既存の視覚エフェクトにすぐには反映されません。 更新を行う必要があります。各視覚エフェクトに必要なクエリが再送信され、必要に応じて視覚エフェクトが更新されます。
  • レポートを Power BI サービスに発行すると、インポートと同じように、Power BI サービスにデータセットが作成されます。 ただし、そのデータセットに "データは含まれません"。
  • Power BI サービスで既存のレポートを開くか、新しいレポートを作成すると、基になるデータ ソースのクエリが再び行われて、必要なデータが取得されます。 インポート モードでのデータ更新と同様に、元のデータ ソースの場所によっては、オンプレミス データ ゲートウェイの構成が必要になる場合があります。
  • 視覚エフェクトまたはレポート ページ全体を、ダッシュボード タイルとしてピン留めできます。 ダッシュボードがすばやく開くように、タイルはスケジュール (たとえば、1 時間ごと) に従って自動的に更新されます。 この更新頻度は、データの変更頻度や、最新のデータを表示する重要性を反映するように、制御できます。 したがって、ダッシュボードを開くと、タイルに反映されるのは最終更新時のデータであり、必ずしも基になるソースに対して行われた最新の変更ではありません。 開かれているダッシュボードは常に更新されて、最新の状態であることが保証されます。

ライブ接続

SQL Server Analysis Services (SSAS) に接続するときは、選択したデータ モデルからデータをインポートするか、またはデータ モデルにライブ接続するかを選択できます。 インポートを選択する場合は、その外部 SSAS ソースに対するクエリを定義します。データは普通にインポートされます。 ライブ接続を選択する場合は、クエリを定義しません。外部モデル全体が、フィールド一覧に表示されます。 DirectQuery を選択すると、視覚エフェクトが作成されるときに、クエリが外部 SSAS ソースに送信されます。 ただし、DirectQuery とは異なり、新しい "モデル" を作成しても意味はありません。つまり、新しい計算列、階層、リレーションシップなどを定義することはできません。 代わりに、外部の SSAS モデルに直接接続するだけです。

前の段落で説明した状況は、データをインポートするオプションがないことを除けば、次のソースへの接続にも当てはまります。

  • Power BI データセット (たとえば、新しいレポートを作成するために、前に作成してサービスに発行した Power BI データセットに接続する場合)
  • Common Data Service

Power BI サービスに発行するときの SSAS に対するレポートの動作は、次の点で DirectQuery レポートに似ています。

  • Power BI サービスで既存のレポートを開くか、新しいレポートを作成すると、基になる SSAS ソースのクエリが実行されます (オンプレミス データ ゲートウェイが必要な場合があります)

  • ダッシュボードのタイルは、スケジュール (1 時間ごとなどの定義されている頻度) に従って自動的に更新されます。

ただし、重要な相違点もあります。たとえば、ライブ接続では、レポートを開いたユーザーの ID が、基になる SSAS に常に渡されます。

これらの比較は本題ではないので、これ以降は DirectQuery のみに注目します。

DirectQuery が役に立つ状況

次の表では、データを元のソースに残しておくのがよいと思われる場合など、DirectQuery による接続が特に役に立つシナリオを説明します。 指定したシナリオが Power BI で使用できるかどうかについても説明します。

制限事項 説明
データが頻繁に変更され、ほぼ "リアルタイム" でのレポート作成が必要である インポートされたデータのモデルでは、更新できるのは多くても 1 時間に 1 回です。 そのため、データが継続的に変更され、レポートで最新データを表示する必要がある場合は、スケジュールされた更新でのインポートを使うのは単にニーズを満たしていない可能性があります。 また、Power BI にデータを直接ストリーミングすることもできますが、この場合はサポートされるデータ量に制限があることに注意してください。

一方、DirectQuery を使った場合は、レポートまたはダッシュボードを開くか更新すると、ソースの最新データが常に表示されます。 さらに、ダッシュボードのタイルはさらに頻繁に更新できます (最高で 15 分ごと)。
データが非常に大きい データが非常に大きい場合、すべてを確実にインポートすることはできません。 これに対し、DirectQuery を使うと、その都度クエリが行われるので、大量のデータ転送は必要ありません。

ただし、大量のデータでは、基になるソースのクエリのパフォーマンスが遅くなりすぎる可能性もあります (後の「*DirectQuery を使用する影響*」の説明を参照)。 もちろん、常に詳細データを完全にインポートする必要があるわけではありません。 代わりに、インポートの間にデータを事前集計することもできます (クエリ エディターを使うと簡単にできます)。 極端な例では、各視覚エフェクトに必要な集計データだけをインポートすることができます。 ですから、大規模なデータには DirectQuery が最も簡単な方法ではありますが、基になるソースが遅すぎる場合は集計データのインポートが解決策になる可能性があることに常に留意する必要があります。
基になるソースでセキュリティ規則が定義されている データをインポートするとき、Power BI は、現在のユーザーの資格情報 (Power BI Desktop から)、または更新スケジュールの構成の一部として定義される資格情報 (Power BI サービスから) を使って、データ ソースに接続します。 したがって、そのようなレポートを発行および共有するときは、同じデータの表示を許可されているユーザーとだけ共有するか、またはデータセットの一部として行レベル セキュリティを定義することに、注意する必要があります。

DirectQuery は基になるソースを常にクエリするので、理想的には、このようにするとその基になるソースにおけるセキュリティを適用できます。 ただし、現在の Power BI は、インポートの場合と同じ資格情報を使って、基になるソースに常に接続します。

したがって、Power BI がレポート ユーザーの ID を使って基になるソースにパススルーできるようになるまでは、データ ソースのセキュリティに関して DirectQuery に利点はありません。
データ主権の制限が適用される 組織によっては、データ主権に関するポリシーが設けられている場合あります。つまり、データを組織外に持ち出すことができません。 インポートに基づくソリューションでは、明らかに問題があります。 これに対し、DirectQuery では、データは基になるソースに残っています。

ただし、DirectQuery でも、視覚エフェクト レベルでデータのキャッシュがいくつか Power BI サービスに保持されることに注意する必要があります (タイルのスケジュールされた更新のため)。
基になるデータ ソースがメジャーを含む OLAP ソースである 基になるデータ ソースに "メジャー" が含まれている場合 (SAP HANA や SAP Business Warehouse など)、データをインポートすると他の問題が発生します。 つまり、インポートされるデータは、クエリによって定義された特定のレベルで集計されたものです (たとえば、Class、Year、City によるメジャー TotalSales など)。 その場合、視覚エフェクトがさらに高いレベルの集計データ (Year 別の TotalSales など) で作成される場合、集計値をさらに集計することになります。 これは、加法メジャー (Sum、Min など) の場合は問題ありませんが、非加法メジャー (Average、DistinctCount など) では問題になります。

ソースから直接 (特定の視覚エフェクトで必要な) 正しい集計データを簡単に取得するには、DirectQuery のように、視覚エフェクトごとにクエリを送信する必要があります。

SAP Business Warehouse (BW) に接続するときは、DirectQuery を選ぶと、このようなメジャーの処理に対応できます。 SAP BW のサポートについて詳しくは、「DirectQuery と SAP BW」をご覧ください。

ただし、現在は、SAP HANA に対する DirectQuery ではリレーショナル ソースと同じように扱われるので、インポートと同様の動作になります。 詳しくは、「DirectQuery と SAP HANA」をご覧ください。

まとめると、Power BI における DirectQuery の現在の機能では、メリットのあるシナリオは次のようになります。

  • データが頻繁に変更され、ほぼ "リアルタイム" でのレポート作成が必要である
  • 事前集計の必要がない、非常に大きなデータを処理する
  • データ主権の制限が適用される
  • ソースがメジャーを含む多次元ソースである (SAP BW など)

上記の一覧の詳細は Power BI の使用にのみ関連することに注意してください。 常に、代わりに外部の SQL Server Analysis Services (または Azure Analysis Services) モデルを使ってデータをインポートし、Power BI を使ってそのモデルに接続することもできます。 この方法では追加のスキルが必要になりますが、柔軟性は大きくなります。 たとえば、はるかに大量のデータをインポートすることができ、データを更新する頻度に制限はありません。

DirectQuery を使用する影響

DirectQuery を使うと、ここで詳しく説明するような悪影響が発生する可能性があります。 これらの制限の一部は、使われているソースにより若干異なります。 該当する場合は明記されており、大幅に異なるソースについては別のトピックで説明されています。

基になるソースでのパフォーマンスと負荷

DirectQuery を使う場合、全体的なエクスペリエンスは基になるデータ ソースのパフォーマンスに大きく依存します。 各視覚エフェクトの更新 (たとえば、スライサーの値を変更した後) に数秒 (5 秒以下) かかる場合、エクスペリエンスとしては妥当かもしれませんが、Power BI にデータをインポートするときの即時応答と比較すると、遅く感じられる可能性があります。 ソースの遅さにより個別の視覚エフェクトにそれより長くかかる場合 (数十秒)、エクスペリエンスは非常に悪くなり、クエリがタイムアウトする可能性もあります。

基になるソースのパフォーマンスと共に、ソースに対する負荷にも注意を払う必要があります (もちろん、多くの場合、パフォーマンスに影響します)。 以下でさらに説明するように、共有レポートを開く各ユーザーおよび定期的に更新される各ダッシュボード タイルは、視覚エフェクトごとに少なくとも 1 つのクエリを基になるソースに送信します。 このため、ソースはこのようなクエリ負荷を処理しながら、適切なパフォーマンスを維持できることが必要です。

1 つのソースへの制限

データをインポートするときは、複数のソースのデータを 1 つのモデルに結合できます。たとえば、社内の SQL Server データベースからのデータと Excel ファイルで保持されているローカル データを、簡単に結合することができます。 DirectQuery を使うとこのようなことはできません。 ソースに対して DirectQuery を選択すると、その 1 つのソース (単一の SQL Server データベースなど) からのデータしか使うことができません。

データ変換の制限

同様に、クエリ エディターで適用できるデータ変換にも制限があります。 インポートしたデータの場合は、高度な変換のセットを簡単に適用して、データをクリーンアップおよび再形成してから、視覚エフェクトを作成できます (JSON ドキュメントの解析や、列指向形式から行指向形式へのデータのピボットなど)。 これらの変換は DirectQuery では大きく制限されます。 最初に、SAP Business Warehouse などの OLAP ソースに接続するときに、変換をまったく定義できず、外部の "モデル" がそのままソースから取得されます。 SQL Server のようなリレーショナル ソースの場合は、クエリごとに変換のセットを定義できますが、パフォーマンス上の理由からその変換も制限されます。 そのような変換は、データ更新時に 1 回ではなく、基になるソースに対するすべてのクエリで適用する必要があるため、1 つのネイティブ クエリに無理なく組み込むことができる変換に制限されます。 複雑すぎる変換を使うと、エラーが発生し、変換を削除するか、モデルをインポート モードに切り替える必要があります。

さらに、[データの取得] ダイアログまたはクエリ エディターで作成したクエリが、視覚エフェクトに必要なデータを取得するために生成されて送信されるクエリ内のサブセレクトで使われます。 したがって、このようなコンテキストで有効なクエリをクエリ エディターで定義する必要があります。 具体的には、共通テーブル式を使うクエリや、ストアド プロシージャを呼び出すクエリを使うことはできません。

モデリングの制限事項

このコンテキストでの "モデリング" という用語は、レポート作成の一環としての生データの調整や補強を意味します。 次のようなものです。

  • テーブル間のリレーションシップの定義
  • 新しい計算の追加 (計算列とメジャー)
  • 列やメジャーの名前変更や非表示
  • 階層の定義
  • 列の書式、既定の概要作成、並べ替え順序の定義
  • 値のグループ化またはクラスタリング

DirectQuery を使うと、これらのモデル強化の多くを行うことができ、後での使用の改善に関しては確かに生データが強化される原則があります。 ただし、DirectQuery では、いくつかのモデリング機能は使用できないか、制限されます。 制限事項は、一般にパフォーマンスの問題を回避するために適用されます。 すべての DirectQuery ソースに共通する制限を次にまとめて示します。 後の "データ ソース固有の詳細" で説明するように、個別のソースについて追加の制限が適用される可能性があります。

  • 組み込みの日付階層がない: データをインポートするときは、すべての日付/日時列で組み込みの日付階層を既定で使用できます。 たとえば、OrderDate 列を含む受注テーブルをインポートし、視覚エフェクトで OrderDate を使用する場合、適切なレベル (Year、Month、Day) を選択して使用できます。 DirectQuery モードではこの組み込み日付階層を使用できません。 ただし、基になるソースに利用可能な日付テーブルがある場合は (多くのデータ ウェアハウスで一般的)、DAX タイム インテリジェンス関数を通常どおり使用できることに注意してください。

  • 計算列での制限事項: 計算列は集計関数を使用しない行内に制限されます。たとえば、同じテーブルの他の列の値だけを参照できます。 さらに、許可される DAX スカラー関数 (LEFT() など) は基になるソースに単純にプッシュできるものに制限され、したがってソースの正確な機能によって異なります。 計算列の DAX を作成するときはサポートされない関数はオートコンプリートに表示されず、使うとエラーが発生します。

  • 親子 DAX 関数がサポートされない: DirectQuery モデルでは、一般に親子構造 (アカウントのグラフや従業員の階層など) を処理する DAX PATH() 関数ファミリを使うことはできません。

  • メジャーに対する制限 (既定): 既定では、メジャーで使用できる DAX 関数と式が制限されます。 やはり、オートコンプリートに表示される関数は制限され、無効な関数または式を使うとエラーが発生します。 理由は単に、メジャー自体がパフォーマンスの問題の原因にならないように、既定では簡単なメジャーに制限することです。 詳しい知識のあるユーザーなら、[ファイル] > [オプション]、次に [設定] > [オプション] > [DirectQuery] の順に選んでから、オプション [DirectQuery モードで無制限のメジャーを許可する]** を選べば、この制限を回避できます。 このオプションを選ぶと、メジャーに使用できる DAX 式ならどれでも使用できるようになります。 しかし、ユーザーが注意すべき点として、データのインポート時のパフォーマンスが良好な式の中には、DirectQuery モードでバックエンド ソースにクエリを実行する際に非常に低速になるものがあります。

    • たとえば、既定では次のようになります。

      • 単に売り上げ高を集計するメジャーを作成できます: SalesAmount = SUMX(Web_Sales, [ws_sales_price]* [ws_quantity])
      • すべての Item についてその SalesAmount を平均するメジャーを作成することは "できません": AverageItemSalesAmount = AVERAGEX('Item', [SalesAmount])

      理由は、Item の数が非常に多い場合、このようなメジャーによりパフォーマンスが低下する可能性があるためです。

  • 計算テーブルがサポートされない: DirectQuery モードでは、DAX 式を使って計算テーブルを定義する機能はサポートされません。

  • リレーションシップのフィルタリングが一方向に制限される: DirectQuery を使うと、リレーションシップでのクロス フィルターの方向を "両方" に設定することはできません。 たとえば、次の 3 つのテーブルで、各 Customer[Gender] が購入した Product[Category] の数を表示する視覚エフェクトは作成できません。 このような双方向フィルタリングの使用について詳しくは、このホワイトペーパーをご覧ください (SQL Server Analysis Services のコンテキストでの例が示されていますが、基本的なポイントは Power BI にも同じように当てはまります)。

    やはり、制限の理由はパフォーマンスへの影響です。 これの具体的な応用で重要なアプリケーションの 1 つは、レポートの一部として行レベル セキュリティを定義する場合です。一般的なパターンでは、ユーザーとユーザーがアクセスを許可されるエンティティの間には多対多のリレーションシップがあり、これを適用するには双方向のフィルターが必要です。 ただし、DirectQuery モデルでの双方向フィルタリングは、パフォーマンスへの悪影響を考慮して慎重に使う必要があります。

  • クラスタリングがない: DirectQuery を使うと、クラスタリング機能を使って自動的にグループを検索することはできません。

レポート作成の制限事項

ほとんどすべてのレポート機能は、DirectQuery モデルでもサポートされます。 そのため、基になるソースが適切なレベルのパフォーマンスを提供する限り、同じ視覚エフェクトのセットを使うことができます。 ただし、以下で説明するように、レポートを発行した後に Power BI サービスで提供される他の機能の一部には重要な制限があります。

  • クイック分析情報がサポートされない: Power BI のクイック分析情報は、興味がある可能性のある情報を検出するために一連の高度なアルゴリズムを適用しながら、データセットのさまざまなサブセットを検索します。 非常に高いパフォーマンスのクエリを必要とするため、この機能は DirectQuery を使うデータセットでは利用できません。

  • Q&A がサポートされない: Power BI の Q&A を使うと、直感的な自然言語の機能を使ってデータを調査し、チャートやグラフの形式で質問に対する回答を受け取ることができます。 ただし、現時点では、DirectQuery を使うデータセットではサポートされていません。

  • Excel で分析を使うとパフォーマンスが低下する可能性がある: データセットで "Excel で分析" 機能を使ってデータを調べることができます。 この機能を使うと、Excel でピボットテーブルとピボットグラフを作成できます。 DirectQuery を使うデータセットでもこの機能はサポートされますが、一般にパフォーマンスは Power BI で視覚エフェクトを作成する場合より遅く、したがって Excel の使用が重要なシナリオの場合、DirectQuery の使用を判断する際に考慮する必要があります。

セキュリティ

前に説明したように、DirectQuery を使うレポートでは、Power BI サービスに発行された後、基になるデータ ソースに接続するときに常に同じ固定の資格情報が使われます。 繰り返しますが、これは DirectQuery に固有の問題であり、SQL Server Analysis Services へのライブ接続では異なることに注意してください。 そのため、DirectQuery レポートを発行したら直ちに、使用されるユーザーの資格情報を構成する必要があります。 これが完了するまで、Power BI サービスでレポートを開くとエラーになります。

ユーザーの資格情報を指定した後は、"レポートを開くユーザーに関係なく" これらの資格情報が使われます。 この点に関して、レポートの一部として行レベル セキュリティを定義しない限り、すべてのユーザーに同じデータが表示されるのは、インポートされたデータの場合と同じです。 そのため、基になるソースでセキュリティ ルールが定義されている場合、レポートの共有に同じ注意を払う必要があります。

Power BI サービスでの動作

このセクションでは、Power BI サービスでの DirectQuery レポートの動作について説明します。主として、レポートとダッシュボードを共有するユーザーの数、レポートの複雑さ、および行レベル セキュリティがレポートで定義されているかどうかに応じて、バックエンド データ ソースで発生する負荷の大きさを理解することが目的です。

レポート - 表示、操作、編集

レポートを開くと、表示されるページ上のすべての視覚エフェクトが更新されます。 各視覚エフェクトでは、通常、基になるデータ ソースに対して少なくとも 1 回クエリを実行する必要があります。 視覚エフェクトによっては、複数回のクエリが必要になります (たとえば、2 つの異なるファクト テーブルの集計値を表示する場合、複雑なメジャーが含まれる場合、Count Distinct のような非加法メジャーの合計が含まれる場合など)。 新しいページに移動すると、これらの視覚エフェクトは更新され、結果として基になるソースに対して新しい一連のクエリが実行されます。

レポートでのすべてのユーザー操作により、視覚エフェクトが更新される可能性があります。 たとえば、スライサーで別の値が選択されると、影響を受けるすべての視覚エフェクトを更新するために新しいクエリ セットを送信する必要があります。 視覚エフェクトをクリックして他の視覚エフェクトをクロス強調表示したり、フィルターを変更したりする場合も同様です。

同様に、新しいレポートを編集しても、パスの各手順でクエリを送信して最終的な目的の視覚エフェクトを生成する必要があります。

結果のキャッシュがいくつかあり、まったく同じ結果が最近取得されている場合は視覚エフェクトがすぐに更新されます。 レポートの一部として行レベル セキュリティが定義されている場合、このようなキャッシュはユーザー間で共有されません。

ダッシュボードの更新

個々の視覚エフェクトまたはページ全体を、タイルとしてダッシュボードにピン留めできます。 DirectQuery データセットに基づくタイルはスケジュールに従って自動的に更新され、結果としてバックエンド データ ソースにクエリが送信されます。 既定では 1 時間ごとに更新されますが、データセットの設定の一部として、毎週から 15 分間隔の範囲で構成することができます。

行レベル セキュリティがモデルで定義されていない場合は、各タイルは 1 回で更新され、すべてのユーザーが結果を共有します。 行レベル セキュリティが定義されている場合は、大きな相乗効果が発生する可能性があります。つまり、各タイルがユーザーごとに異なるクエリを、基になるソースに送信する必要があります。

したがって、10 個のタイルを含み、100 人のユーザーによって共有されるダッシュボードが、行レベル セキュリティを設定された DirectQuery を使うデータセットに作成され、15 分ごとに更新するように構成されている場合、15 分ごとに少なくとも 1000 個のクエリがバックエンド ソースに送信されます。

そのため、行レベル セキュリティの使用および更新スケジュールの構成については、慎重に検討する必要があります。

タイムアウト

Power BI サービスでは個々のクエリに対して 4 分のタイムアウトが適用され、それより長い時間がかかるクエリは失敗します。 前に説明したように、DirectQuery は対話形式に近いクエリ パフォーマンスを提供するソースに対して使うことが推奨されるので、この制限は過度に長い実行時間による問題を回避するためのものです。

その他の影響

DirectQuery の使用に伴うその他の一般的な影響は次のとおりです。

  • データが変更された場合、更新して最新データを表示する必要がある: キャッシュを使っている場合、視覚エフェクトに常に最新データが表示されている保証はありません。 たとえば、視覚エフェクトに前日のトランザクションが表示されている可能性があります。 スライサーの変更により、ごく最近の新たに到着したトランザクションを含む過去 2 日間のトランザクションが表示される可能性があります。 スライサーを元の値に戻すと、以前に取得されたキャッシュの値が再び表示され、新しく到着したトランザクションが含まれなくなることがあります。

    更新を選択すると、すべてのキャッシュがクリアされ、ページ上のすべての視覚エフェクトが更新されて最新のデータが表示されます。

  • データが変化している場合、視覚エフェクト間の一貫性が保証されない: 異なる視覚エフェクトは、同じページ上でも別のページ上でも、異なるタイミングで更新される可能性があります。 したがって、基になるソースのデータが変更された場合、各視覚エフェクトにまったく同じ時点のデータが表示される保証はありません。 実際、単一の視覚エフェクトに対して複数のクエリが必要であると (たとえば、詳細情報と合計を取得する場合など)、1 つの視覚エフェクト内であっても整合性は保証されません。 これを保証するには、基になるデータ ソースでのスナップショット分離のようなコストの高い機能の使用と併せて、いずれかの視覚エフェクトが更新されるときは常にすべての視覚エフェクトを更新するオーバーヘッドが必要になります。

    やはり、更新を選択してページ上のすべての視覚エフェクトを更新することで、この問題を大幅に軽減できます。 また、インポート モードを使っている場合でも、複数のテーブルからデータをインポートする場合は、整合性の保証に関する同様の問題があることに注意してください。

  • メタデータの変更を反映するには Power BI Desktop での更新が必要である: レポートを発行した後の更新では、レポートの視覚エフェクトが更新されるだけです。 基になるソースのスキーマに対する変更は、フィールド リストで使用可能なフィールドの変更には自動的に適用されません。 したがって、基になるソースからテーブルや列を削除した場合、更新時にクエリが失敗する可能性があります。 Power BI Desktop でレポートを開き、[更新] を選択すると、モデルのフィールドが更新されて変更が反映されます。

  • クエリで返される行が 100 万行に制限される: 基になるソースに対する 1 回のクエリで返される行の数には、100 万行という固定の制限があります。 一般に、これによる実際的な影響はなく、視覚エフェクト自体でこれだけ多くのポイントは表示されません。 ただし、Power BI で送信されるクエリが完全に最適化されておらず、制限を超える中間結果が要求される場合、この制限が発生する可能性があります。 また、視覚エフェクトの作成中に、より適切な最終状態への過程でも、発生することがあります。 たとえば、顧客が 100 万を超える場合、フィルターが適用されるまで、Customer や TotalSalesQuantity を含めるとこの制限に達します。

    "外部データ ソースに対するクエリの結果セットが、許可されている最大サイズの '1000000' 行を超えています" というエラーが返ります。

  • インポート モードから DirectQuery モードに変更できない: DirectQuery モードからインポート モードを使うようにモデルを切り替えることは一般に可能ですが、これは必要なすべてのデータをインポートする必要があることを意味することに注意してください。 また、元に戻すこともできません (主として、DirectQuery モードでサポートされていない機能セットのため)。 SAP BW などの多次元ソースに対する DirectQuery モデルでは、外部メジャーの処理が完全に異なるため、DirectQuery からインポートに切り替えることもできません。

Power BI サービスでの DirectQuery

すべてのソースは Power BI Desktop からサポートされます。 一部のソースは、Power BI サービス内から直接使用することもできます。 たとえば、ビジネス ユーザーは Power BI を使って Salesforce のデータに接続し、Power BI Desktop を使わずにダッシュボードをすぐに取得できます。

サービスで直接利用できる DirectQuery 対応のソースは次の 2 つだけです。

  • Spark
  • Azure SQL Data Warehouse

ただし、これら 2 つのソースに対する DirectQuery の使用はすべて Power BI Desktop 内で始めることを強くお勧めします。 なぜなら、Power BI サービスで最初に接続するときは、多くの重要な制限が適用されます。つまり、最初は簡単ですが (Power BI サービスで開始)、結果のレポートをさらに強化する場合は制限があります (たとえば、計算の作成、多くの分析機能の使用、基になるスキーマの変更を反映するためのメタデータの更新などは不可能です)。

DirectQuery を正常に使用するためのガイダンス

DirectQuery を使う場合は、このセクションで提供する確実に成功する方法についての概要的なガイダンスを参考にしてください。 このセクションのガイダンスは、これまでに説明してきた DirectQuery を使用したときの影響から得られたものです。

バックエンド データ ソースのパフォーマンス

簡単な視覚エフェクトが適切な時間で更新できるかどうかを検証することを強くお勧めします。 妥当な対話型操作のためには、これは 5 秒以内である必要があります。 視覚エフェクトの更新に 30 秒以上かかるようでは、レポートを発行した後でさらに問題が発生する可能性が高く、ソリューションが動作しなくなります。

クエリが遅い場合は最初に、基になるソースに送信されるクエリを調べて、観察されるクエリのパフォーマンスの理由を明らかにします。 このトピックでは、可能性のあるすべてのソースに対するデータベース最適化のベスト プラクティスについて広範には説明しませんが、ほとんどの状況に適用される標準的なデータベース プラクティスに当てはまります。

  • 通常、整数型の列に基づくリレーションシップの方が、他のデータ型の列での結合よりパフォーマンスがよくなります
  • 適切なインデックスを作成する必要があります。一般に、これは列ストア インデックスをサポートするソース (たとえば、SQL Server) ではそれらを使用することを意味します。
  • ソースで必要なすべての統計を更新する必要があります

モデルの設計のガイダンス

モデルを定義するときは、次のことを考慮します。

  • クエリ エディターで複雑なクエリを作成しない。 クエリ エディターで定義したクエリは単一の SQL クエリに変換されて、そのテーブルに送信されるすべてのクエリのサブセレクトに組み込まれます。 そのクエリが複雑な場合、送信されるクエリでパフォーマンスの問題が発生する可能性があります。 一連の手順に対する実際の SQL クエリは、クエリ エディターで最後のステップを選択し、コンテキスト メニューから [ネイティブ クエリを表示]** を選択することによって取得できます。

  • メジャーを単純に保つ。 少なくとも最初は、単純な集計にメジャーを制限することをお勧めします。 その後、パフォーマンスに問題がなければさらに複雑なメジャーを定義してもかまいませんが、それぞれのパフォーマンスに注意するようにします。

  • 計算列ではリレーションシップを使用しない。 これは、複数列の結合を実行する必要があるデータベースに特に関係があります。 現在、Power BI では、FK/PK として複数列に基づくリレーションシップは許可されません。 一般的な回避策は、計算列を使って列を連結し、それを基にして結合することです。 この回避策はインポートされたデータの場合は妥当ですが、DirectQuery の場合は、式での結合になり、一般にインデックスを使用できず、パフォーマンスの低下につながります。 唯一の回避策は、基になるデータベースで実際に複数の列を 1 つの列に具体化することです。

  • uniqueidentifier の列ではリレーションシップを使用しない。 Power BI は、データ型 uniqueidentifier をネイティブにサポートしていません。 したがって、uniqueidentifier 型の列の間にリレーションシップを定義すると、キャストを含む結合を使用するクエリになります。 この場合も、一般にパフォーマンスが低下します。 このケースが特に最適化されるまでの唯一の回避策は、基になるデータベースで代替型の列を具現化することです。

  • リレーションシップの to 列を非表示にする。 リレーションシップの to 列 (通常は、to テーブルの主キー) を非表示にして、フィールド リストに表示されないようにし、それによって視覚エフェクトで使うことができないようにする必要があります。 多くの場合、リレーションシップの基になっている列は実際には "システム列" であり (たとえば、データ ウェアハウス内のサロゲートキー)、このような列を非表示にするのはいずれにしてもよいことです。 列に意味がある場合は、表示され、主キーと同等になる単純な式を持つ、計算列を導入します。 例:

    ProductKey_PK   (Destination of a relationship, hidden)
    ProductKey (= [ProductKey_PK],   visible)
    ProductName
    ...
    

    このようにする理由は、視覚エフェクトに主キー列が含まれている場合に発生する可能性があるパフォーマンスの問題を回避することです。

  • 計算列とデータ型の変更の使用をすべて調べる。 これらの機能を使っても必ずしも有害ではありませんが、基になるソースに送信されるクエリに単純な列参照ではなく式が含まれるようになり、インデックスが使われなくなる可能性があります。

  • (プレビューの) 双方向クロス フィルタリングをリレーションシップで使わない。

  • 設定 [参照整合性を想定] で実験する。** リレーションシップで [参照整合性を想定]** を設定すると、OUTER JOIN ではなく INNER JOIN ステートメントをクエリで使えるようになります。 一般的にはこれによりクエリのパフォーマンスが向上しますが、データ ソースの仕様に依存します。

  • クエリ エディターで相対データ フィルタリングを使わない。 クエリ エディターでは相対データ フィルタリングを定義できます。 たとえば、日付が過去 14 日間である行をフィルター処理するような場合です。

    ただし、クエリが作成されたときの固定の日付に基づくフィルター処理に変換されます。 これは、ネイティブ クエリの表示から確認できます。

    これは、ほぼ確実に望んだことではありません。 レポート実行時の日付に基づいてフィルターが適用されるようにするには、代わりにレポート フィルターとしてレポートでフィルターを適用します。 現在、これを実現するには、過去の日数を計算する計算列を作成し (DAX DATE() 関数を使用)、それをフィルターで使います。

レポートの設計のガイダンス

DirectQuery 接続を使ってレポートを作成する場合は、次のガイドラインに従います。

  • フィルターを最初に適用する: 常に、視覚エフェクト作成の最初の段階で該当するフィルターを適用します。 たとえば、TotalSalesAmount と ProductName をドラッグしてから特定の年でフィルター処理するのではなく、最初に年でフィルターを適用します。 これは、視覚エフェクト作成の各ステップでクエリが送信され、最初のクエリが完了する前に別の変更を加えることができるので、基になるソースに不要な読み込みが残る可能性があるためです。 最初にフィルターを適用することで、一般にこれらの中間クエリのコストが低下します。 また、最初にフィルターを適用しないと、100 万行の上限に達する可能性があります。

  • ページ上の視覚エフェクトの数を制限する: ページを開くと (または、ページ レベルのスライサーやフィルターを変更すると)、ページ上のすべての視覚エフェクトが更新されます。 また、並列に送信されるクエリの数にも制限があるので、視覚エフェクトの数が増えると、一部の視覚エフェクトは順番に更新されるようになり、ページ全体の更新にかかる時間が増えます。 このため、1 ページの視覚エフェクトの数を制限し、代わりに単純なページを多数作成します。

  • 視覚エフェクト間の相互作用を無効にすることを検討する: 既定では、レポート ページ上の 1 つの視覚エフェクトを使って、そのページ上の他の視覚エフェクトに処理とクロス強調表示を適用できます。 たとえば、円グラフで "1999" を選択すると、縦棒グラフが "1999" のカテゴリの売上を表示するようにクロス強調表示されます。

    ただし、この相互作用は、こちらの記事で説明されているように制御できます。 DirectQuery でクロス フィルター処理やクロス強調表示を行うには、基になるソースにクエリを送信する必要があるので、ユーザー選択への応答に非常に長い時間を要する場合は、相互作用をオフにする必要があります。

  • レポートのみを共有することを検討する: Power BI サービスへの発行後にコンテンツを共有するにはさまざまな方法があります。 DirectQuery の場合は、新しいレポートの作成を他のユーザーに許可する (そして、作成される特定の視覚エフェクトでパフォーマンスの問題が発生する可能性を招く) のではなく、完成したレポートのみの共有を検討することをお勧めします。

これまでに説明したガイダンスに加えて、次の各レポート機能がパフォーマンスの問題の原因になる可能性があることに注意してください。

  • メジャー フィルター: 視覚エフェクトのメジャー (または列の集計) にはフィルターを含めることができます。 たとえば、次の視覚エフェクトではカテゴリ別の SalesAmount が表示されますが、売上が 2,000 万を超えるカテゴリのみが含まれます。

    これにより、基になるソースに 2 つのクエリが送信されます。

    • 最初のクエリでは、条件 (売上が 2,000 万を超える) を満たすカテゴリが取得されます。
    • 2 番目のクエリでは、WHERE 句の条件を満たすカテゴリなど、視覚エフェクトに必要なデータが取得されます。

    一般に、この例のようにカテゴリの数が数百から数千の場合はパフォーマンスに問題はありません。 カテゴリの数が非常に多い場合は、パフォーマンスが低下する可能性があります (実際、条件を満たすカテゴリが 100 万を超えると、前に説明した 100 万行の制限のため、クエリは失敗します)。

  • TopN フィルター: メジャーによるランクで上位 (または下位) N 個の値だけを表示するように、高度なフィルターを定義できます。たとえば、上の視覚エフェクトでは上位 10 のカテゴリだけを含めることができます。 これにより、基になるソースに 2 つのクエリが送信されます。 ただし、最初のクエリは基になるソースからすべてのカテゴリを返し、返された結果に基づいて TopN が決定されます。 関係する列の基数によっては、パフォーマンスの問題が発生します (または、100 万行の制限によりクエリが失敗します)。

  • 中央値: 一般に、すべての集計 (Sum、Count Distinct など) は基になるソースにプッシュされます。 ただし、中央値の場合、この集計は一般に基になるソースによってサポートされないので、プッシュされません。 このような場合は、詳細データが基になるソースから取得され、返された結果から中央値が計算されます。 これは、比較的少数の結果について中央値を計算するときは問題ありませんが、基数が大きい場合はパフォーマンスの問題が発生します (または、100 万行の制限によりクエリが失敗します)。 たとえば、Median Country Population は問題がなくても、Median Sales Price は問題になることがあります。

  • 高度なテキスト フィルター ("contains" など): テキスト列をフィルター処理する場合、高度なフィルタリングでは "contains" や "begins with" などのフィルターを使用できます。 一部のデータ ソースでは、これらのフィルターにより確実にパフォーマンスが低下します。 具体的には、実際に必要なのが完全な一致 ("is" や "is not") である場合は、既定の "contains" フィルターを使わないようにする必要があります。 結果は同じかもしれませんが、実際のデータによっては、インデックスの使用のためにパフォーマンスが大きく異なる可能性があります。

  • 複数選択スライサー: 既定では、スライサーで可能な選択は 1 つのみです。 フィルターで複数選択を許可した場合、ユーザーがスライサーで複数の項目を選択すると (たとえば、関心のある 10 製品)、新しい選択ごとにクエリがバックエンド ソースに送信されるため、パフォーマンスの問題が発生する可能性があります。 ユーザーがクエリが完了する前に次の項目を選択できるので、基になるソースで余分な負荷が発生します。

パフォーマンスの問題の診断

このセクションでは、パフォーマンスの問題を診断する方法、またはレポートを最適化できるより詳細な情報を取得する方法について説明します。

パフォーマンスの問題の診断は、Power BI サービスではなく Power BI Desktop で始めることを強くお勧めします。 一般に、パフォーマンスの問題は単に基になるソースのパフォーマンス レベルによるものであり、Power BI Desktop の分離環境で最初に特定のコンポーネント (Power BI ゲートウェイなど) を除外する方が、より簡単に問題を識別して診断できます。 Power BI Desktop にパフォーマンスの問題が存在しないことがわかった場合にのみ、Power BI サービスでレポートの詳細に焦点を当てて調査する必要があります。

同様に、ページにある多くの視覚エフェクトではなく、最初に個々の視覚エフェクトに問題を分離することをお勧めします。

それでは、このセクションの前の段落の手順を実施して、Power BI Desktop のページにある 1 つの視覚エフェクトの動作が遅いことがわかったものとします。 Power BI Desktop によって基になるソースに送信されるクエリを特定するには、そのソースから出力される可能性があるトレース/診断情報を見ることができます。 このようなトレースには、クエリの実行方法および改善方法の詳細に関する有用な情報も含まれることがあります。

さらに、ソースからのこのようなトレースがない場合であっても、次に示すように、実行時間に沿って Power BI によって送信されるクエリを表示することができます。

Power BI Desktop によって送信されたクエリの特定

既定では、Power BI Desktop は特定のセッションの間のイベントを FlightRecorderCurrent.trc という名前のトレース ファイルに記録します。

一部の DirectQuery ソースの場合、このログには基になるデータ ソースに送信されたすべてのクエリが含まれています (他の DirectQuery ソースは将来的に含まれる予定です)。 ログにクエリを送信するソースは次のとおりです。

  • SQL Server
  • Azure SQL Database
  • Azure SQL Data Warehouse
  • Oracle
  • Teradata
  • SAP HANA

トレース ファイルは、現在のユーザーの AppData フォルダーにあります。

\<User>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces

このフォルダーに簡単にアクセスするには、Power BI Desktop[ファイル] > [オプションと設定] > [オプション] の順に選択し、[診断] を選択します。 次のダイアログ ウィンドウが表示されます。

[診断オプション] の [トレース フォルダーを開く]** リンクを選択すると、次のフォルダーが表示されます。

\<User>\AppData\Local\Microsoft\Power BI Desktop\Traces

そのフォルダーの親フォルダーに移動すると、AnalysisServicesWorkspaces を含むフォルダーが表示され、これには Power BI Desktop の開いているインスタンスごとに 1 つのワークスペース フォルダーが含まれます。 これらのサブフォルダーは整数のサフィックスが付いた名前になっています (例: AnalysisServicesWorkspace2058279583)。

そのフォルダー内の \Data サブフォルダーには、現在の Power BI セッションのトレース ファイル FlightRecorderCurrent.trc が含まれます。 関連する Power BI Desktop セッションが終了すると、対応するワークスペース フォルダーは削除されます。

トレース ファイルは、SQL Server Profiler ツールを使って読むことができます。このツールは、SQL Server Management Studio の一部として無料でダウンロードできます。 この場所から入手できます。

SQL Server Management Studio をダウンロードしてインストールした後、SQL Server Profiler を実行します。

トレース ファイルを開くには、次の手順のようにします。

  1. SQL Server Profiler で、[ファイル] > [開く] > [トレース ファイル] の順に選択します。
  2. 現在開いている Power BI セッションのトレース ファイルへのパスを入力します。次はその例です。

        C:\Users\<user>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces\AnalysisServicesWorkspace2058279583\Data
    
  3. FilghtRecorderCurrent.trc を開きます。

現在のセッションのすべてのイベントが表示されます。 注釈付きの例を以下に示します。イベントのグループが強調表示されています。 各グループには次のものが含まれます。

  • Query Begin イベントと Query End イベント。これらは、UI によって生成された DAX クエリの開始と終了を表します (たとえば、視覚エフェクトから、またはフィルター UI 内の値の一覧の作成から)。

  • 1 つまたは複数の DirectQuery Begin イベントと DirectQuery End イベントのペア。これらは、DAX クエリの評価の一部として、基になるデータ ソースに送信されたクエリを表します。

複数の DAX クエリを並列して実行できるので、異なるグループからのイベントが混在している可能性があることに注意してください。 ActivityID の値を使って、同じグループに属しているイベントを特定できます。

必要なその他の列は次のとおりです。

  • TextData: イベントのテキスト形式の詳細です。 "Query Begin/End" イベントの場合は、DAX クエリです。 "DirectQuery Begin/End" イベントの場合は、基になるソースに送信された SQL クエリです。 現在選択されているイベントの TextData は、下部の領域にも表示されます。

  • EndTime: イベントが完了した日時です。

  • Duration: DAX クエリまたは SQL クエリの実行にかかった時間です (ミリ秒単位)。

  • Error: エラーが発生したかどうかを示します (発生した場合は、イベントも赤で表示されます)。

上の図では、重要な列がわかりやすいように、重要ではない列の表示が狭くなっていることに注意してください。

潜在的なパフォーマンスの問題の診断に役立つトレースをキャプチャする推奨される方法は次のとおりです。

  • 1 つの Power BI Desktop セッションを開きます (複数のワークスペース フォルダーで混乱するのを避けるため)。

  • Power BI Desktop で関心のあるアクションのセットを実行します。 それ以外にいくつかの操作を実行し、目的のイベントがトレース ファイルにフラッシュされるようにします。

  • SQL Server Profiler を開き、前述のようにトレースを確認します。 Power BI Desktop を閉じるとトレース ファイルが削除されることに注意してください。 また、Power BI Desktop でのその後の操作はすぐに表示されません。新しいイベントを表示するには、トレース ファイルいったん閉じてから再度開く必要があります。

  • トレース ファイルを容易に解釈できるよう (および、トレース ファイルのサイズには制限があり、非常に長いセッションでは前の方のイベントが破棄される可能性があるため)、個々のセッションを適度な小ささ (数百秒ではなく 10 秒くらいの操作) にします。

Power BI Desktop によって送信されるクエリの形式の概要

Power BI Desktop によって作成および送信されるクエリの一般的な形式では、参照されるテーブルごとにサブセレクトが使われます。サブセレクトは、クエリ エディターで定義されるクエリによって定義されます。 たとえば、SQL Server に次のような TPC-DS テーブルがあるものとします。

次のようなクエリについて考えます。

このクエリは、次の視覚エフェクトになります。

この視覚エフェクトを更新すると、次の段落の後で示す SQL クエリが生成されます。 ご覧のように、Web Sales、Item、Date_dim に対する 3 つのサブセレクトがあり、それぞれが対応するテーブルのすべての列を返しますが、視覚エフェクトで実際に参照されているのは 4 つの列だけです。 サブセレクトでのこれらのクエリは (網掛けの部分)、クエリ エディターで定義されているクエリの結果です。 現時点で DirectQuery についてサポートされているデータ ソースの場合、この方法でサブセレクトを使っても、パフォーマンスには影響ないことがわかっています。 SQL Server などのデータ ソースでは、他の列への参照は最適化により除外されます。

Power BI でこのパターンが使われる理由の 1 つは、使用される SQL クエリをアナリストが直接提供でき、書き換えられることなく "そのまま" 使用されるようにするためです。

詳細

この記事では、すべてのデータ ソースに共通する DirectQuery の側面について説明しました。 個々のソースに固有の特定の詳細があります。 特定のソースについては、以下のトピックをご覧ください。

DirectQuery について詳しくは、次のリソースをご覧ください。