DirectQuery モデルを開発するタイミングを決定する
DirectQuery モデルは、ストレージ モード プロパティが DirectQuery に設定されているテーブルで構成され、それらは同じソース グループに属しています。
ソース グループは、データ ソースに関連するモデル テーブルのセットです。 次の 2 つの種類があります。
- インポート – 計算テーブルを含むすべてのインポート ストレージ モード テーブルを表します。 モデルにはインポート ソース グループが 1 つだけ存在できます。
- DirectQuery – 特定のデータ ソースに関連するすべての DirectQuery ストレージ モード テーブルを表します。
注意
インポート モデルと DirectQuery モデルは、1 つのソース グループのみで構成されます。 複数のソース グループがある場合、そのモデル フレームワークは複合モデルと呼ばれます。 複合モデルについては、ユニット 5 で説明します。
DirectQuery モデルの利点
DirectQuery モデルの開発には、いくつかの利点があります。
大きなデータ ソースや変化の速いデータ ソースをモデル化する
DirectQuery モデルは、ソース データのデータ量や変化の速さに顕著な特性が見られる場合に、最適なフレームワークとなります。 DirectQuery テーブルは更新を必要としないため、データ ウェアハウスなどの大規模なデータ ストアに適しています。 データ ウェアハウス全体をモデルにインポートすることは、不可能ではないにしても実用的ではなく、非効率的です。 ソース データの変化が急速で、ユーザーが最新のデータを参照する必要がある場合は、DirectQuery モデルを使用することで、ほぼリアルタイムのクエリ結果を提供できます。
レポートで DirectQuery モデルへのクエリが実行された場合、それらのクエリは Power BI によって基になるデータ ソースへと渡されます。
ソース RLS を適用する
DirectQuery は、ソース データベースで行レベルのセキュリティ (RLS) が適用されている場合にも役立ちます。 Power BI モデルで RLS ルールをレプリケートする代わりに、ソース データ ベースでルールを適用できます。 このアプローチは、一部のリレーショナル データベースに対してのみ機能します。その場合、データセットのデータ ソースに対してシングル サインオンを設定する必要があります。 詳しくは、「Azure SQL Data Warehouse と DirectQuery」をご覧ください。
データ主権の制限
オンプレミス外へのデータ送信を制限するセキュリティ ポリシーが組織で実施されている場合、データをインポートすることはできません。 その場合は、オンプレミスのデータ ソースに接続する DirectQuery モデルが役に立つ可能性があります (オンプレミス レポート用に Power BI Report Server のインストールを検討することもできます)。
特殊なデータセットを作成する
通常、DirectQuery モードではリレーショナル データベース ソースがサポートされます。 これは、Power BI で、分析クエリをデータ ソース側で認識されるネイティブ クエリへと変換する必要があるためです。
ただし、強力な例外措置が 1 つあります。 Power BI データセット (または Azure Analysis Services モデル) に接続し、それを DirectQuery ローカル モデルに変換することができます。 ローカル モデルとは、1 つのモデルと別のモデルとの関係を表す相対語です。 この場合は、元のデータセットがリモート モデルで、新しいデータセットがローカル モデルです。 これらのモデルはチェーン化されます。チェーンとは、関連する複数のモデルを表す用語です。 この方法で、最大 3 つのモデルをチェーン化できます。
モデルをチェーン化するこの機能を使えば、リモート モデルをカスタマイズしたり、拡張したりすることができます。 最もシンプルな用途は、テーブルや列などのオブジェクトの名前を変更したり、ローカル モデルにメジャーを追加したりすることです。 また、計算列や計算テーブルを使用してモデルを拡張したり、新しいインポート テーブルや DirectQuery テーブルを追加したりすることもできます。 ただし、これらの拡張機能を使用すると、新しいソース グループが作成されます。つまり、モデルが複合モデルになります。 このシナリオについては、ユニット 5 で説明します。
詳細については、Power BI データセットおよび Azure Analysis Services 用の DirectQuery の使用に関するページを参照してください。
DirectQuery モデルの制限事項
DirectQuery モデルの使用にあたっては、関連する多数の制限事項を念頭に置く必要があります。 主な制限事項は次のとおりです。
すべてのデータ ソースがサポートされているわけではありません。 通常は、主要なリレーショナル データベース システムのみがサポートされます。 Power BI データセットと Azure Analysis Services モデルもサポートされます。
Power Query (M) 変換はいずれも実行できません。これらのクエリは、ソース システムで認識されるネイティブ クエリへと変換する必要があるためです。 そのため、たとえば、ピボット変換やピボット解除変換を使用することはできません。
分析クエリのパフォーマンスが低下する可能性があります。これは特に、ソース システムが (インデックスや具体化されたビューを使用して) 最適化されていない場合や、分析ワークロード用の十分なリソースがない場合に顕著です。
分析クエリがソース システムのパフォーマンスに影響を与える可能性があります。 その結果、OLTP 操作を含め、すべてのワークロードのエクスペリエンスが低下する可能性があります。
DirectQuery モデルのパフォーマンスを向上させる
DirectQuery モデルを開発する妥当な理由がある場合は、2 つの方法で一部の制限を軽減できます。
データ ソースの最適化
ソース データベースを最適化して、予想される分析クエリ ワークロードが良好に実行されるようにすることができます。 具体的には、インデックスと具体化されたビューを作成し、すべてのワークロードに対して十分なリソースがデータベースにあることを確認できます。
ヒント
必ず、データベース所有者と共同で作業することをお勧めします。 DirectQuery モデルによってデータベースに配置できる追加のワークロードを把握することが重要です。
DirectQuery のユーザー定義集計テーブル
DirectQuery モデルには、ユーザー定義の集計テーブルを追加できます。 ユーザー定義集計テーブルは、非表示の特殊なモデル テーブルです (ユーザー、計算、RLS から隠されます)。 これらは、大規模なファクト テーブルに対する高粒度の分析クエリに対応できる場合に最適に機能します。 集計テーブルで DirectQuery ストレージ モードを使用するように設定すると、データ ソース内の具体化されたビューに対してクエリを実行できます。 また、集計テーブルでインポート ストレージ モードを使用するように設定したり、自動集計を有効にしたりすることもできます。これらのオプションについては、ユニット 4 で説明します。
詳細については、「Power BI Desktop の DirectQuery モデルのガイダンス」を参照してください。