ページ分割されたレポートでのデータ取得のガイダンス

  • [アーティクル]

この記事の対象読者は、Power BI のページ分割されたレポートをデザインするレポート作成者です。 効果的かつ効率的なデータ取得をデザインするのに役立つ推奨事項を提供します。

データ ソースの種類

ページ分割されたレポートでは、リレーショナル データ ソースと分析データ ソースの両方がネイティブでサポートされます。 これらのソースは、クラウドベースまたはオンプレミスのいずれかにさらに分類されます。 オンプレミスのデータ ソース (オンプレミスでホストされているか、仮想マシン内にあるかにかかわらず) には、Power BI が接続できるようにデータ ゲートウェイが必要です。 クラウドベースとは、Power BI がインターネット接続を使用して直接接続できることを意味します。

データ ソースの種類を選択できる場合は (新しいプロジェクトの場合もあります)、クラウドベースのデータ ソースを使用することをお勧めします。 ページ分割されたレポートは、データ ソースがご使用の Power BI テナントと同じリージョンに存在する場合は特に、短いネットワーク待機時間で接続できます。 また、シングル サインオン (SSO) を使用して、これらのソースに接続することもできます。 これは、レポート ユーザーの ID をデータ ソースにフローさせて、ユーザーごとの行レベルのアクセス許可を適用できることを意味します。 現在、SSO は、SQL Server および Oracle のオンプレミス データ ソースでのみサポートされています (「Power BI のページ分割されたレポートでサポートされるデータ ソース」を参照してください)。

注意

現在、SSO を使用してオンプレミスのデータベースに接続することはできませんが、行レベルのアクセス許可を適用することはできます。 これを行うには、UserID 組み込みフィールドをデータセット クエリ パラメーターに渡します。 データ ソースには、クエリ結果を正しくフィルター処理できるように、ユーザー プリンシパル名 (UPN) 値を格納する必要があります。

たとえば、各販売員がテーブル Salesperson 内に 1 行として格納されているとします。 このテーブルには、UPN と販売員の販売地域の列も含まれています。 クエリ時には、テーブルはレポート ユーザーの UPN によってフィルター処理され、内部結合を使用して売上ファクトにも関連付けられます。 このように、クエリで売上ファクト行がレポート ユーザーの販売地域の行に効果的にフィルター処理されます。

[リレーショナル データ ソース]

一般に、リレーショナル データ ソースは、販売請求書などの運用スタイルのレポートに適しています。 また、非常に大規模なデータセット (10,000 行超) を取得する必要があるレポートにも適しています。 リレーショナル データ ソースでは、レポート データセットによって実行できるストアド プロシージャを定義することもできます。 ストアド プロシージャには、次のような複数の利点があります。

  • [パラメーター化]
  • プログラミング ロジックのカプセル化により、より複雑なデータ準備 (一時テーブル、カーソル、スカラー ユーザー定義関数など) が可能
  • 保守容易性の向上により、ストアド プロシージャのロジックを簡単に更新可能 場合によっては、ページ分割されたレポートを変更および再発行することなくこれを行うことが可能 (列名とデータ型をが変わらない場合)
  • 実行プランが再利用のためにキャッシュされるため、パフォーマンスが向上
  • 複数のレポート間でのストアド プロシージャの再利用

Power BI Report Builder では、リレーショナル クエリ デザイナーを使用してクエリ ステートメントをグラフィカルに作成できますが、使用できるのは Microsoft データ ソースに対してだけです。

分析データ ソース

分析データ ソース (''データ モデル'' または単に ''モデル'' ともいう) は、運用と分析の両方のレポートに適しており、非常に大規模なデータ量に対しても、迅速に要約されたクエリ結果を提供できます。 モデルのメジャーと KPI により、複雑なビジネス ルールをカプセル化して、データの要約を実現できます。 しかし、これらのデータ ソースは、大量のデータ (10,000 行超) を取得する必要があるレポートには適していません。

Power BI Report Builder では、Analysis Services DAX クエリ デザイナーと Analysis Services MDX クエリ デザイナーという 2 つのクエリ デザイナーから選択できます。 これらのデザイナーは、Power BI セマンティック モデル (旧称: データセット) のデータ ソース、または任意の SQL Server Analysis Services または Azure Analysis Services モデル (表形式または多次元) に使用できます。

ご自分のクエリのニーズが完全に満たされる場合は、DAX クエリ デザイナーを使用することをお勧めします。 必要なメジャーがモデルで定義されていない場合は、クエリ モードに切り替える必要があります。 このモードでは、(要約を実現するために) 式を追加することによって、クエリ ステートメントをカスタマイズできます。

MDX クエリ デザイナーでは、モデルにメジャーを含める必要があります。 このデザイナーには、DAX クエリ デザイナーでサポートされていない 2 つの機能があります。 具体的には、次のことができます。

  • クエリレベルで計算されたメンバーを定義する (MDX 内)。
  • 詳細以外のグループでサーバー集計を要求するデータ領域を構成する。 レポートで、準加法または非加法メジャー (タイム インテリジェンス計算、個別カウントなど) のサマリーを提示する必要がある場合、低レベルの詳細行を取得してレポートで要約を計算するよりも、サーバー集計を使用する方が効率的な場合があります。

クエリ結果のサイズ

通常は、レポートに必要なデータのみを取得することをお勧めします。 そのため、レポートに必要のない列または行を取得しないでください。

行を制限するには、最も制限の厳しいフィルターを常に適用し、集計クエリを定義する必要があります。 集計クエリでは、より詳細な結果を取得するため、ソース データがグループ化されて集計されます。 たとえば、レポートで販売員の売上のサマリーを提示する必要があるとします。 すべての販売注文行を取得するのではなく、販売員別にグループ化して、各グループの売上を集計するデータセット クエリを作成します。

式ベースのフィールド

式に基づくフィールドでレポート データセットを拡張することができます。 たとえば、データセットで顧客の姓と名を提供している場合、2 つのフィールドを連結して顧客の氏名を生成するフィールドが必要になることがあります。 この計算を実現するには、2 つの選択肢があります。 次のようにすることができます。

  • 式に基づくデータセット フィールドの "計算フィールド" を作成する。
  • (データ ソースのネイティブ言語を使用して) データセット クエリに式を直接挿入する。これにより、通常のデータセット フィールドが生成されます。

可能な場合は、後者の選択肢をお勧めします。 データセット クエリに式を直接挿入した方が良い理由は 2 つあります。

  • データ ソースが Power BI よりも効率的に式を評価できるように最適化されている可能性があります (特にリレーショナル データベースの場合)。
  • レポートのレンダリング前に計算フィールドを具体化するために Power BI を必要としないため、レポートのパフォーマンスが向上します。 データセットが大量の行を取得する場合、計算フィールドのレポートのレンダリング時間が著しく長くなることがあります。

フィールド名

データセットを作成すると、そのフィールドには、クエリ列に基づいて自動的に名前が付けられます。 これらの名前は、わかりにくく、直観的でない場合もあります。 また、ソース クエリの列名に、レポート定義言語 (RDL) のオブジェクト識別子で禁止されている文字 (スペースやシンボルなど) が含まれている場合もあります。 この場合、禁止されている文字はアンダースコア文字 (_) に置き換えられます。

まず、すべてのフィールド名がわかりやすく、簡潔ながらも意味がわかる名前になっていることを確認することをお勧めします。 そうでない場合は、レポートのレイアウトを開始する "前に"、それらの名前を変更することをお勧めします。 これは、フィールドの名前変更が、レポート レイアウトで使用される式に波及しないようにするためです。 レポート レイアウトの開始後にフィールドの名前を変更すると、破損した式をすべて検索して更新しなければならなくなります。

フィルターとパラメーター

ページ分割されたレポート デザインにレポート パラメーターが含まれる可能性があります。 レポート パラメーターは、レポート ユーザーにレポートのフィルター処理を求めるためによく使用されます。 ページ分割されたレポートの作成者は、2 通りの方法でレポートのフィルタリングを実現できます。 レポート パラメーターを次にマップできます。

  • データセットによって既に取得されているデータのフィルター処理にレポート パラメーター値が使用される場合は、データセット "フィルター"。
  • レポート パラメーター値がデータ ソースに送信されるネイティブ クエリに挿入される場合は、データセット "パラメーター"。

注意

すべてのレポート データセットは、"最後に使用されてから" 最大 10 分間、"セッション単位で" キャッシュされます。 データセットは、新しいパラメーター値 (フィルタリング) を送信するとき、別の形式でレポートをレンダリングするとき、または表示の切り替えや並べ替えなど、何らかの方法でレポート デザインを操作するときに再利用できます。

次に、単年度でレポートをフィルター処理する 1 つのレポート パラメーターがある売上レポートの例を考えてみましょう。 データセットでは、"すべての年" の売上が取得されます。 レポート パラメーターがデータセット フィルターにマップされるためにこのようになります。 レポートには、要求された年のデータが表示されます。これは、データセット データのサブセットです。 レポート ユーザーがレポート パラメーターを別の年に変更し、レポートを表示する際に、Power BI でソース データを取得する必要はありません。 代わりに、既にキャッシュされているデータセットに別のフィルターが適用されます。 データセットがキャッシュされると、フィルタリングが非常に高速になることがあります。

次に、別のレポート デザインを考えてみましょう。 今度は、レポート デザインによって売上の年度レポート パラメーターがデータセット パラメーターにマップされます。 このように、Power BI によって年の値がネイティブ クエリに挿入され、データセットではその年のデータのみが取得されます。 レポート ユーザーが年度レポート パラメーター値を変更して、レポートを表示するたびに、データセットによってその年だけの新しいクエリ結果が取得されます。

どちらのデザイン方法でもレポート データをフィルター処理でき、どちらのデザインもご自分のレポート デザインで問題なく機能します。 ただし、最適化されたデザインは、予想されるデータの量、データの変動、およびレポート ユーザーの予想される動作によって異なります。

データセット行の異なるサブセットが何度も再利用されることが予想される場合は、"データセットのフィルタリング" をお勧めします (これにより、新しいデータを取得する必要がなくなるため、レンダリング時間が短縮されます)。 このシナリオでは、大規模なデータセットを取得するためのコストは、再利用される回数とのトレードオフになる可能性があることを認識します。 そのため、生成に時間がかかるクエリには役立ちます。 ただし、大規模なデータセットをユーザー単位でキャッシュすると、パフォーマンスや容量のスループットに悪影響を与える可能性があることに注意してください。

データセットの行の異なるサブセットが要求される可能性が低いことが予想される場合、またはフィルター処理されるデータセットの行数が、(キャッシュするには非効率的なほど) 非常に大きくなる可能性がある場合は、"データセットをパラメータ化" することをお勧めします。 ご使用のデータ ストアが揮発性の場合には、このデザイン手法でもうまく機能します。 この場合、レポート パラメーター値を変更するたびに最新のデータが取得されます。

ネイティブ以外のデータ ソース

改ページ対応レポートでネイティブにサポートされていないデータ ソースに基づいて改ページ対応レポートを開発する必要がある場合は、まず Power BI Desktop でデータ モデルを開発する必要があります。 そうすることで、Power BI でサポートされている数百のデータ ソースに接続できます。 Power BI サービスに発行されると、Power BI データセットに接続する改ページ対応レポートを作成できます。

データ統合

複数のデータ ソースからのデータを結合する必要がある場合は、次の 2 つの選択肢があります。

ネットワーク待機時間

ネットワーク待機時間は、要求が Power BI サービスに到達するまでに要する時間と、応答の配信に要する時間が増えることで、レポートのパフォーマンスに影響を及ぼす可能性があります。 Power BI のテナントは、特定のリージョンに割り当てられています。

ヒント

ご自身のテナントが配置されている場所を特定するには、「Power BI テナントの場所」をご覧ください。

テナントのユーザーが Power BI サービスにアクセスすると、要求は常にこのリージョンにルーティングされます。 要求が Power BI サービスに到達すると、サービスからさらに要求が送信されることがあります (たとえば、基になるデータ ソースやデータ ゲートウェイに対して)。これもネットワーク待機時間の影響を受けます。 一般に、ネットワーク待機時間の影響を最小限に抑えるには、データ ソース、ゲートウェイ、および Power BI 容量をできるだけ近くに配置するようにします。 可能であれば、それらを同じリージョン内に配置します。 ネットワーク待機時間が問題になっている場合は、ゲートウェイとデータ ソースをクラウドでホストされる仮想マシン内に配置することで、Power BI 容量により近い位置に配置してみてください。

SQL Server の複合データ型

SQL Server はオンプレミスのデータ ソースであるため、Power BI はゲートウェイ経由で接続する必要があります。 ただし、ゲートウェイでは、複合データ型のデータの取得はサポートされていません。 複合データ型には、GEOMETRY や GEOGRAPHY 空間データ型のような組み込み型、および hierarchyid が含まれます。 また、Microsoft.NET Framework 共通言語ランタイム (CLR) のアセンブリのクラスを使用して実装されたユーザー定義型が含まれる場合もあります。

マップの視覚化で空間データと分析をプロットするには、SQL Server 空間データが必要です。 そのため、データ ソースが SQL Server である場合は、マップの視覚化を使用できません。 誤解のないように言うと、Power BI はゲートウェイ経由では接続されないため、これはデータ ソースが Azure SQL Database の場合は機能します。

画像は、レポート レイアウトにロゴや画像を追加するために使用できます。 画像がレポート データセットによって取得される行に関連している場合、次の 2 つの選択肢があります。

  • ご自分のデータ ソースから画像データを取得することもできます (既にテーブルに格納されている場合)。
  • 画像が Web サーバーに格納されている場合は、動的な式を使用して画像の URL パスを作成できます。

詳細と提案については、ページ分割されたレポートの画像に関するガイダンスを参照してください。

冗長データの取得

レポートで冗長データが取得される可能性があります。 これは、データセット クエリフ ィールドを削除した場合や、レポートに未使用のデータセットがある場合に発生する可能性があります。 このような状況は、ご利用のデータ ソース、ネットワーク、および Power BI 容量リソースに不要な負荷がかかるため、避けてください。

削除されたクエリ フィールド

[データセットのプロパティ] ウィンドウの [フィールド] ページでは、データセット クエリ フィールドを削除できます (クエリ フィールドは、データセット クエリによって取得される列にマップされます)。 ただし、Report Builder によって、データセット クエリから対応する列が削除されることはありません。

クエリ フィールドをデータセットから削除する必要がある場合は、データセット クエリから対応する列を削除することをお勧めします。 重複するクエリ フィールドはすべて、Report Builder によって自動的に削除されます。 意図せずクエリフ ィールドを削除してしまった場合は、データセット クエリ ステートメントも変更して列を削除する必要があります。

未使用のデータセット

レポートを実行すると、すべてのデータセットが (レポート オブジェクトにバインドされていない場合でも) 評価されます。 このため、レポートを発行する前に、必ずテスト データセットまたは開発データセットを削除してください。

関連するコンテンツ

この記事に関する詳細については、次のリソースを参照してください。