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

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

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

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

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

• ストレージ モード:どのビジュアルでバックエンド データ ソースをクエリするかを指定できるようになりました。 この機能はパフォーマンスの向上とバック エンドの負荷の軽減に役立ちます。 以前は、スライサーなどのシンプルなビジュアルでも、バックエンド ソースへのクエリが開始されていました。 詳細については、「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 側から取得することはできません。 また、同じソース内の多対多のリレーションシップと比較すると、パフォーマンスへの影響が見られる場合があります。

Note

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

複合モデルの例

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

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

しかし、各製品に割り当てられたプロダクト マネージャーに関するデータが、マーケティングの優先順位と共に、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 の [リレーションシップ] ビューには、ProductManagers という追加のテーブルが表示されています。

次は、これらのテーブルをモデルの他のテーブルに関連付ける必要があります。 通常どおり、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 でストレージ モードを管理する」をご覧ください。

Note

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

計算テーブル

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

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

重要

計算テーブルは、特定の要件を満たさない限り、この機能を利用する Power BI サービスではサポートされていません。 この機能の詳細については、この記事の「セマンティック モデルに基づく複合モデルの操作」セクションを参照してください。

セキュリティへの影響

複合モデルには、セキュリティへの影響がいくつかあります。 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 番目のソースに渡されることがよくあります。 このような状況では、次のような実行の形式になる可能性があります。

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

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

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

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

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

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

ソース グループ

ソース グループとは、DirectQuery ソースまたはデータ モデルに関係するすべてのインポート ソースからの項目 (テーブル、リレーションシップなど) のコレクションです。 複合モデルは、1 つまたは複数のソース グループから作られます。 次に例を示します。

• Sales という Power BI セマンティック モデルに接続し、元のセマンティック モデルでは使用できない Sales YTD メジャーを追加してセマンティック モデルをエンリッチする複合モデル。 このモデルは、1 つのソース グループで構成されます。
• Targets という Excel シートと Regions という CSV ファイルのテーブルをインポートし、Sales という Power BI セマンティック モデルへの DirectQuery 接続を行うことで、データを結合する複合モデル。 この場合、次の図に示すように、2 つのソース グループがあります。
  • 最初のソース グループには、Targets Excel シートと Regions CSV ファイルのテーブルが含まれています。
  • 2 番目のソース グループには、Sales Power BI セマンティック モデルの項目が含まれています。

Inventory という SQL Server データベースへの DirectQuery 接続など、別のソースに別の DirectQuery 接続を追加した場合、そのソースの項目は別のソース グループとして追加されます。

Note

別のソースからデータをインポートすると、インポートされたすべてのソースのすべての項目が 1 つのソース グループに含まれるので、別のソース グループは追加されません。

ソース グループとリレーションシップ

複合モデルには次の 2 種類のリレーションシップがあります。

• ソース グループ内のリレーションシップ。 これらのリレーションシップでは、ソース グループ内の項目を関連付けます。 これらのリレーションシップは、多対多 (制限付き) でない限り、常に通常のリレーションシップです。
• ソース グループ間のリレーションシップ。 これらのリレーションシップは、1 つのソース グループで始まり、別のソース グループで終わります。 これらのリレーションシップは常に制限付きリレーションシップです。

通常のリレーションシップと制限付きリレーションシップの違いとその影響について詳しくは、こちらを参照してください。

たとえば、次の図では、3 つのソース グループ間リレーションシップを追加し、さまざまなソース グループ間のテーブルを関連付けています。

ローカルとリモート

DirectQuery ソース グループであるソース グループ内の項目は、その項目が DirectQuery ソースの拡張またはエンリッチメントの一部としてローカルに定義され、メジャーや計算テーブルなどのリモート ソースの一部でない限り、リモートと見なされます。 DirectQuery ソース グループのテーブルに基づく計算テーブルは、"Import" ソース グループに属し、ローカルと見なされます。 "Import" ソース グループ内のすべての項目は、ローカルと見なされます。 たとえば、Inventory ソースへの DirectQuery 接続を使用する複合モデルで次のメジャーを定義した場合、そのメジャーはローカルと見なされます。

[Average Inventory Count] = Average(Inventory[Inventory Count])

計算グループ、クエリとメジャーの評価

計算グループでは、冗長メジャーの数を減らすだけでなく、一般的なメジャー式をグループ化する方法も提供されます。 一般的なユース ケースは、実績から月度累計、四半期累計、または年度累計の計算に切り替えることができるようにするタイム インテリジェンス計算です。 複合モデルを使用する場合は、計算グループ間の相互作用と、メジャーで単一のリモート ソース グループの項目のみが参照されているかどうかを認識することが重要です。 メジャーにより 1 つのリモート ソース グループの項目のみが参照され、リモート モデルでメジャーに影響を与える計算グループが定義されている場合、メジャーがリモート モデル、またはローカル モデルで定義されていても、その計算グループが適用されます。 ただし、メジャーで単一のリモート ソース グループの項目が排他的に参照されているのではなく、リモート計算グループが適用されているリモート ソース グループの項目が参照されている場合、メジャーの結果は引き続きリモート計算グループの影響を受ける可能性があります。 次に例を示します。

• Reseller Sales は、リモート モデルで定義されたメジャーです。
• リモート モデルには、Reseller Sales の結果を変更する計算グループが含まれています
• Internet Sales は、ローカル モデルで定義されたメジャーです。
• Total Sales はローカル モデルで定義されたメジャーであり、次の定義があります。

[Total Sales] = [Internet Sales] + [Reseller Sales]

このシナリオでは、Internet Sales メジャーは、同じモデルに含まれていないため、リモート モデルで定義されている計算グループの影響を受けません。 しかし、計算グループは、同じモデル内にあるReseller Sales メジャーの結果を変更できます。 この事実は、Total Sales メジャーによって返される結果は慎重に評価する必要があることを意味します。 リモート モデルの計算グループを使用して、年度累計の結果を返すとします。 Reseller Sales によって返される結果は年度累計の値になりましたが、Internet Sales によって返される結果は引き続き実績です。 Total Sales の結果は、実績が年間累計の結果に追加されるため、予期しないものになる可能性があります。

Power BI セマンティック モデルと Analysis Services での複合モデル

Power BI セマンティック モデルや Analysis Services で複合モデルを使用すると、DirectQuery 接続を使用して Power BI セマンティック モデル、Azure Analysis Services (AAS)、SQL Server 2022 Analysis Services に接続する複合モデルを構築できます。 複合モデルを使用すると、これらのソース内のデータを他の DirectQuery データやインポートされたデータと結合することができます。 レポート作成者がエンタープライズ セマンティック モデルのデータを Excel スプレッドシートなどの所有する他のデータと結合する必要がある場合、またはエンタープライズ セマンティック モデルのメタデータをパーソナル化または強化する必要がある場合に、この機能は特に便利です。

Power BI セマンティック モデルでの複合モデルの管理

Power BI セマンティック モデルで複合モデルの作成と使用を有効にするには、テナントで次のスイッチをオンにする必要があります。

• オンプレミスのセマンティック モデルを使った "Excel で分析" と XMLA エンドポイントを許可する。 このスイッチがオフになっている場合、Power BI セマンティック モデルへの DirectQuery 接続を作成できません。
• ユーザーは、ライブ接続を使用して Excel で Power BI セマンティック モデルを操作できます。 このスイッチが無効になっている場合、ユーザーは Power BI セマンティック モデルにライブ接続できないため、[このモデルに変更を加える] ボタンを使用できません。
• Power BI セマンティック モデルへの DirectQuery の接続を許可する。 このスイッチの詳細と、それをオフにしたときの影響については、次の段落を参照してください。

さらに、Premium 容量と Premium Per User の場合は、"XMLA エンドポイント" の設定を有効にし、"読み取り専用" または "読み取り/書き込み" に設定する必要があります。

テナント管理者は、管理ポータルで Power BI セマンティック モデルへの DirectQuery 接続を有効または無効にすることができます。 これは既定で有効になっていますが、無効にすると、ユーザーが Power BI セマンティック モデル上の新しい複合モデルをサービスに発行できなくなります。

Power BI セマンティック モデル上で複合モデルを利用する既存のレポートは引き続き機能し、ユーザーは Desktop を使用して複合モデルを作成できますが、サービスに発行することはできません。 代わりに、[このモデルに変更を加える] を選択して Power BI セマンティック モデルへの DirectQuery 接続を作成すると、次の警告メッセージが表示されます。

これにより、ローカルの Power BI Desktop 環境でセマンティック モデルを探索し、複合モデルを作成できます。 ただし、レポートをサービスに発行することはできません。 レポートとモデルを発行すると、次のエラー メッセージが表示され、パブリケーションはブロックされます。

このスイッチは、Power BI セマンティック モデルへのライブ接続、および Analysis Services へのライブ接続や DirectQuery 接続には影響しません。 スイッチがオフになっているかどうかに関係なく、これらは引き続き機能します。 また、Power BI セマンティック モデル上で複合モデルを使用する発行済みのすべてのレポートは、発行後にスイッチがオフになった場合でも引き続き機能します。

セマンティック モデルまたはモデルでの複合モデルの構築

Power BI セマンティック モデルまたは Analysis Services モデルで複合モデルを構築するには、レポートにローカル モデルが必要です。 ライブ接続から開始し、ローカル モデルに追加またはアップグレードするか、DirectQuery 接続またはインポートされたデータから開始し、レポートにローカル モデルを自動的に作成することができます。

モデルで使用されている接続を確認するには、Power BI Desktop の右下隅にあるステータス バーを確認します。 Analysis Services ソースにのみ接続している場合は、次の画像のようなメッセージが表示されます。

Power BI セマンティック モデルに接続している場合は、接続している Power BI セマンティック モデルを示すメッセージが表示されます。

ライブ接続されているセマンティック モデルのフィールドのメタデータをカスタマイズする場合は、ステータス バーで [このモデルに変更を加える] を選択します。 または、次の画像に示すように、リボンの [Make changes to this model](このモデルに変更を加える) ボタンを選択することもできます。 [レポート ビュー] の [モデリング] タブにある [Make changes to this model](このモデルに変更を加える) ボタン。[モデル ビュー] の場合、このボタンは [ホーム] タブにあります。

このボタンを選択すると、ローカル モデルの追加を確認するダイアログが表示されます。 Power BI セマンティック モデルまたは Analysis Services のフィールドに対して、[ローカル モデルの追加] を選択し、新しい列の作成またはメタデータの変更を有効にします。 次の図は、表示されたダイアログを示しています。

Analysis Services ソースにライブ接続している場合、ローカル モデルはありません。 Power BI セマンティック モデルや Analysis Services などのライブ接続ソースに DirectQuery を使用するには、レポートにローカル モデルを追加する必要があります。 ローカル モデルを含むレポートを Power BI サービスに発行すると、そのローカル モデルのセマンティック モデルが適切に発行されます。

チェーン

セマンティック モデルと、その基になっているセマンティック モデルは "チェーン" を形成します。 "チェーン" と呼ばれるこのプロセスを使用すると、他の Power BI セマンティック モデルに基づいてレポートとセマンティック モデルを発行できます。これは、以前は不可能であった機能です。

たとえば、同僚が "Sales" という Analysis Services モデルに基づく "Sales and Budget" という Power BI セマンティック モデルを発行し、それを "Budget" という Excel シートと組み合わせたとします。

同僚が発行した "Sales and Budget" Power BI セマンティック モデルに基づく "Sales and Budget Europe" という新しいレポート (とセマンティック モデル) を発行し、その際にさらに変更または拡張を行う場合は、"Sales" Analysis Services モデルから始まり、"Sales and Budget Europe" Power BI セマンティック モデルで終わる、長さが 3 のチェーンにレポートとセマンティック モデルを追加することになります。 次の画像は、このチェーン プロセスを視覚化したものです。

前の画像のチェーンの長さは、最大長の 3 です。 長さが 3 を超えるチェーンはサポートされておらず、エラーが発生します。

アクセス許可とライセンス

複合モデルを使ってレポートにアクセスするユーザーは、すべてのセマンティック モデルとチェーン内のモデルに対する適切なアクセス許可を持っている必要があります。

複合モデルの所有者は、ソースとして使われるセマンティック モデルに対するビルド アクセス許可が必要です。これにより、他のユーザーが所有者に代わってそれらのモデルにアクセスできるようにします。 その結果、Power BI Desktop で複合モデル接続を作成する場合、または Power BI でレポートを作成する場合は、ソースとして使われるセマンティック モデルに対するビルド アクセス許可が必要になります。

複合モデルを使ってレポートを表示するユーザーには、通常、複合モデル自体と、ソースとして使われるセマンティック モデルに対する読み取りアクセス許可が必要です。 レポートが Pro ワークスペースにある場合は、ビルド アクセス許可が必要になることがあります。 そのユーザーに対してこれらのテナント スイッチを有効にする必要があります。

必要なアクセス許可は、次の例のように図示することができます。

• 複合モデル A (所有者 A が所有)

  • データ ソース A1: セマンティック モデル B。
    ユーザーが複合モデル A を使ってレポートを表示するには、所有者 A がセマンティック モデル B に対してビルド アクセス許可を持っている必要があります。

• 複合モデル C (所有者 C が所有)

  • データ ソース C1: セマンティック モデル D
    ユーザーが複合モデル C を使ってレポートを表示するには、所有者 C がセマンティック モデル D に対してビルド アクセス許可を持っている必要があります。
  • データ ソース C2: 複合モデル A
    所有者 C は、複合モデル A に対するビルド アクセス許可と、セマンティック モデル B に対する読み取りアクセス許可を持っている必要があります。

複合モデル A を使ってレポートを表示するユーザーは、複合モデル A とセマンティック モデル B の両方に対して読み取りアクセス許可を持っている必要があります。一方、複合モデル C を使ってレポートを表示するユーザーは、複合モデル C、セマンティック モデル D、複合モデル A、およびセマンティック モデル B に対する読み取りアクセス許可が必要です。

Note

Power BI セマンティック モデルと Analysis Services モデルの複合モデルに必要なアクセス許可に関する重要な情報については、こちらのブログ投稿を参照してください。

チェーン内のデータセットが Premium Per User ワークスペースにある場合、それにアクセスするユーザーには Premium Per User ライセンスが必要です。 チェーン内のデータセットが Pro ワークスペースにある場合、それにアクセスするユーザーには Pro ライセンスが必要です。 チェーン内のすべてのデータセットが Premium 容量または Fabric F64 以上の容量にある場合、ユーザーは無料ライセンスを使ってそれにアクセスできます。

セキュリティの警告

Power BI セマンティック モデルと Analysis Services モデルでの複合モデル機能を使用すると、次の画像のようなセキュリティ警告ダイアログが表示されます。

データは、あるデータソースから別のデータソースにプッシュされる場合があります。これは、データ モデルで DirectQuery とインポート ソースを組み合わせる場合と同じセキュリティ警告です。 この動作の詳細については、Power BI Desktop での複合モデルの使用に関するページを参照してください。

サポートされるシナリオ

Power BI セマンティック モデルまたは Analysis Services モデルのデータを使用して、次のシナリオに対応する複合モデルを構築することができます。

• さまざまなソースからのデータへの接続:インポート (ファイルなど)、Power BI セマンティック モデル、Analysis Services モデル
• さまざまなデータ ソース間のリレーションシップを作成する
• さまざまなデータ ソースのフィールドを使用するメジャーを作成する
• Power BI セマンティック モデルまたは Analysis Services モデルからテーブルの新しい列を作成する
• さまざまなデータ ソースの列を使用する視覚化を作成する
• できるだけ簡潔で無駄のないモデルに保つために、フィールド リストを使用してモデルからテーブルを削除することができます (パースペクティブに接続する場合、モデルからテーブルを削除することはできません)
• テーブルの特定のサブセットのみが必要な場合は、すべてのテーブルを読み込む必要はなく、読み込むテーブルを指定できます。 このドキュメントの後半の、テーブルのサブセットの読み込みに関するセクションを参照してください。
• モデルで接続を行った後にセマンティック モデルに追加されるテーブルを追加するかどうかを指定できます。

セマンティック モデルに基づく複合モデルの操作

DirectQuery for Power BI semantic models and Analysis Services を操作する際には、次の情報を考慮してください。

• データ ソースを更新し、フィールド名またはテーブル名が競合するエラーが発生した場合、Power BI によってエラーが解決されます。

• 同じ Power BI セマンティック モデルまたは Analysis Services ソース内で、リレーションシップを編集したり、削除したり、新規作成したりすることはできません。 これらのソースに対する編集アクセス権を持っている場合は、代わりにデータ ソースで直接変更を行うことができます。

• Power BI セマンティック モデルや Analysis Services のソースから読み込まれる列のデータ型を変更することはできません。 データ型を変更する必要がある場合は、ソースで変更するか、計算列を使用します。

• 別のセマンティック モデルに基づく複合モデルで Power BI サービスのレポートを作成するには、すべての資格情報が設定されている必要があります。

• オンプレミスまたは IAAS の SQL Server 2022 以降の Analysis Services サーバーへの接続には、オンプレミス データ ゲートウェイ (標準モード) が必要です。

• リモート Power BI セマンティック モデルへのすべての接続は、シングル サインオンを使用して行われます。 サービス プリンシパルを使用した認証は現在サポートされていません。

• RLS ルールは、それらが定義されているソースには適用されますが、モデル内の他のセマンティック モデルには適用されません。 レポートに定義されている RLS はリモート ソースに適用されず、リモート ソースに設定された RLS は他のデータ ソースに適用されません。 また、リモート ソースから読み込まれたテーブルで RLS を定義することはできず、ローカル テーブルで定義されている RLS では、リモート ソースから読み込まれたテーブルはフィルター処理されません。

• KPI、行レベルのセキュリティ、翻訳はソースからインポートされません。

• 日付の階層を使用すると、予期しない動作が発生する場合があります。 この問題を解決するには、代わりに日付列を使用してください。 視覚化に日付の階層を追加した後、 [日付の階層] を使用せずに、フィールド名の下矢印をクリックし、そのフィールドの名前をクリックすると、日付列に切り替えることができます。

  

  日付列を使用する場合と日付の階層を使用する場合の比較の詳細については、「Power BI Desktop で自動の日付/時刻を適用する」を参照してください。

• モデルのチェーンの最大長は 3 です。 長さが 3 を超えるチェーンはサポートされておらず、エラーが発生します。

• モデルに "チェーンを推奨しない" フラグを設定して、チェーンが作成または拡張されないようにすることができます。 詳細については、「公開済みのセマンティック モデルに対する DirectQuery 接続を管理する」を参照してください。

• Power BI セマンティック モデルまたは Analysis Services モデルへの接続は、Power Query には表示されません。

DirectQuery for Power BI semantic models and Analysis Services を操作する際には、次の制限が適用されます。

• データベースとサーバーの名前のパラメーターは現在無効になっています。
• リモート ソースからテーブルに RLS を定義することはサポートされていません。
• DirectQuery ソースとして次のソースを使用することはできません。
  • バージョン 2022 以前の SQL Server Analysis Services (SSAS) 表形式モデル
  • SSAS 多次元モデル
  • SAP HANA
  • SAP Business Warehouse
  • リアルタイム セマンティック モデル
  • サンプル セマンティック モデル
  • Excel Online の更新
  • サービス上の Excel または CSV ファイルからインポートされたデータ
  • 使用状況メトリック
  • "マイ ワークスペース" に格納されているセマンティック モデル
• 外部 Analysis Services モデル (Azure Analysis Services/SQL Server Analysis Services) への DirectQuery 接続を含むセマンティック モデルで Power BI Embedded を使用することは現在サポートされていません。
• [Web に公開] 機能を使用した Web へのレポートの公開はサポートされていません。
• リモート ソースの計算グループはサポートされておらず、クエリ結果は未定義になります。

• 計算テーブルおよび計算列で、シングル サインオン (SSO) 認証を使用してデータ ソースから DirectQuery テーブルを参照することは、共有可能なクラウド接続や詳細なアクセス コントロールが割り当てられた Power BI サービスでサポートされています。

• DirectQuery 接続を設定した後でワークスペースの名前を変更した場合は、レポートの処理を続行するために Power BI Desktop のデータ ソースを更新する必要があります。
• ページの自動更新 (APR) は、データ ソースの種類によっては、一部のシナリオでのみサポートされています。 詳細については、「Power BI でのページの自動更新」を参照してください。
• 現在のところ、他のセマンティック モデルに DirectQuery を利用してセマンティック モデルを継承する機能はサポートされていません。
• 他の DirectQuery データ ソースと同様に、Excel を使用して DirectQuery モードでモデルまたはセマンティック モデルに接続しているときは、Analysis Services モデルまたは Power BI セマンティック モデルに定義されている階層は表示されません。

DirectQuery for Power BI semantic models and Analysis Services を操作する際に考慮することが他にもいくつかあります。

• ソース グループ間リレーションシップには低カーディナリティの列を使う: 2 つの異なるソース グループにまたがるリレーションシップを作成する場合、そのリレーションシップに参加する列 (結合列とも呼ばれます) のカーディナリティは低く抑えるようにします (理想的には 50,000 以下)。 この考慮事項は、文字列型ではないキー列に適用されます。文字列型キー列の場合は、次の考慮事項を参照してください。
• ソース グループ間リレーションシップには大きな文字列型キー列を使わないようにする: ソース グループ間リレーションシップを作成する場合、リレーションシップ列として大きな文字列型列を使わないようにします (特にカーディナリティが大きい列の場合)。 リレーションシップ列として文字列型列を使う必要がある場合、カーディナリティ (C) に文字列型列の平均の長さ (A) を掛けて、フィルターの予想される文字列長を計算します。 A ∗ C < 250,000 のように、予想される文字列長が 250,000 未満であることを確認します。

その他の考慮事項とガイダンスについては、複合モデルのガイダンスに関するページを参照してください。

テナントに関する考慮事項

Power BI セマンティック モデルまたは Analysis Services に DirectQuery で接続するすべてのモデルでは、同じテナント内で発行する必要があります。これは、次の図のように、B2B ゲスト ID を使用して Power BI セマンティック モデルまたは Analysis Services のモデルにアクセスする場合に特に重要です。 発行用のテナントの URL を検索するには、「コンテンツを編集および管理できるゲスト ユーザー」を参照してください。

次の図について考えてみましょう。 この図の番号付きの手順については、次の段落を参照してください。

この図では、Ash は Contoso で働いており、Fabrikam が提供するデータにアクセスしています。 Ash は Power BI Desktop を使用し、Fabrikam のテナントでホストされている Analysis Services モデルに DirectQuery で接続を作成します。

Ash は認証に、B2B ゲストユーザー ID を使用します (図の手順 1)。

レポートが Contoso の Power BI サービスに発行される場合 (手順 2)、Contoso テナントに発行されたセマンティック モデルは、Fabrikam の Analysis Services モデルに正常に認証されません (手順 3)。 その結果、レポートは機能しません。

このシナリオでは、使用される Analysis Services モデルが Fabrikam のテナントでホストされているため、レポートも Fabrikam のテナントに発行する必要があります。 Fabrikam のテナントに正常に発行されると (手順 4)、セマンティック モデルは Analysis Services モデルに正常にアクセスでき (手順 5)、レポートは正常に機能します。

オブジェクト レベルのセキュリティの使用

複合モデルで DirectQuery を使用して Power BI セマンティック モデルまたは Analysis Services からデータを取得し、そのソース モデルがオブジェクトレベルのセキュリティで保護されている場合、複合モデルのコンシューマーで予期しない結果が発生することがあります。 次のセクションでは、これらの結果がどのようにして発生するかを説明します。

オブジェクトレベルのセキュリティ (OLS) を使用すると、モデル作成者はモデルのコンシューマー (たとえば、レポート ビルダーや複合モデルの作成者) に対してモデル スキーマ (つまり、テーブル、列、メタデータなど) を構成するオブジェクトを非表示にすることができます。 オブジェクトの OLS の構成で、モデル作成者はロールを作成した後、そのロールに割り当てられているユーザーのオブジェクトへのアクセス権を削除します。 これらのユーザーからすると、非表示のオブジェクトは存在しません。

OLS は、ソース モデルに対して定義され、適用されます。 それをソース モデルに基づいて構築された複合モデルに対して定義することはできません。

DirectQuery 接続を使用して、OLS で保護された Power BI セマンティック モデルまたは Analysis Services モデルの上に複合モデルを構築すると、ソース モデルのモデル スキーマが複合モデルにコピーされます。 コピーされる内容は、複合モデルの作成者がソース モデルに適用される OLS 規則に従って何の参照を許可するかによって異なります。 データは複合モデルにコピーされません。その代わり、必要に応じてソース モデルから常に DirectQuery を使用して取得されます。 言い換えれば、データ取得は常に OLS 規則が適用されるソース モデルに戻ります。

複合モデルは OLS 規則で保護されていないため、複合モデルのコンシューマーが参照するオブジェクトは、コンシューマー自体がアクセス権を持っているものではなく、複合モデルの作成者がソース モデルで参照できるものです。 このため、次のような状況が発生する可能性があります。

• 複合モデルを参照するユーザーに対して、ソース モデルで OLS によって非表示になっているオブジェクトが表示される場合があります。
• 逆に、ソース モデルで参照できる複合モデルのオブジェクトを参照できない場合もあります。これは、ソース モデルへのアクセスを制御する OLS 規則によって、そのオブジェクトが複合モデルの作成者に対して非表示になっているためです。

重要な点は、最初の箇条書きで説明したケースにもかかわらず、複合モデルのコンシューマーは参照できないことになっている実際のデータを参照できないことです。これは、データが複合モデルに存在しないためです。 むしろ、DirectQuery のために、それはソース セマンティック モデルから必要に応じて取得され、OLS によって許可されてないアクセスがブロックされます。

この背景を踏まえて、次のシナリオを考察してみましょう。

1. Admin_user は、Customer テーブルと Territory テーブルを含む Power BI セマンティック モデルまたは Analysis Services モデルを使用して、エンタープライズ セマンティック モデルを発行しました。 Admin_user は、このセマンティック モデルを Power BI サービスに発行し、次のような効果を持つ OLS 規則を設定します。

   • Finance_user は Customer テーブルを参照できない
   • Marketing_user は Territory テーブルを参照できない

2. Finance_user は、"Finance セマンティック モデル" という名前のセマンティック モデルと、手順 1 で発行されたエンタープライズ セマンティック モデルに DirectQuery 経由で接続する "Finance レポート" という名前のレポートを発行します。 Finance レポートには、Territory テーブルの列を使用するビジュアルが含まれています。

3. Marketing_user は、Finance レポートを開きます。 Territory テーブルを使用するビジュアルが表示されますが、エラーが返されます。これは、レポートを開いたときに、DirectQuery が Marketing_user の資格情報を使用してソース モデルからデータを取得しようとしますが、エンタープライズ セマンティック モデルに設定されている OLS 規則に従って Territory テーブルの参照がブロックされるためです。

4. Marketing_user は、Finance セマンティック モデルをソースとして使用する "Marketing レポート" という名前の新しいレポートを作成します。 フィールドの一覧に、Finance_user がアクセスできるテーブルと列が表示されます。 したがって、フィールドの一覧に Territory テーブルは表示されますが、Customer テーブルは表示されません。 ただし、Marketing_user が Territory テーブルの列を利用するビジュアルを作成しようとすると、エラーが返されます。これは、その時点で DirectQuery が Marketing_user の資格情報を使用してソース モデルからデータを取得しようとし、再び OLS 規則が作動してアクセスがブロックされるためです。 Marketing_user が DirectQuery 接続を使用して Finance セマンティック モデルに接続する新しいセマンティック モデルやレポートを作成した場合も、同じ現象が発生します。Territory テーブルは Finance_user が参照できるものなので、フィールドの一覧に表示されますが、そのテーブルを利用する視覚化を作成しようとすると、エンタープライズ セマンティック モデルの OLS 規則によってブロックされます。

5. ここで、Admin_user がエンタープライズ セマンティック モデルの OLS 規則を更新して、Finance_user が Territory テーブルを参照できないようにしたとします。

6. 更新された OLS ルールは、更新時にのみ Finance セマンティック モデルに反映されます。 したがって、Finance_user が Finance セマンティック モデルを更新すると、フィールドの一覧に Territory テーブルが表示されなくなります。また、Finance_user に Territory テーブルへのアクセスが許可されていないため、Territory テーブルの列を使用する Finance レポート内の視覚化によってエラーが返されます。

まとめ

• 複合モデルのコンシューマーは、モデルの作成時に複合モデルの作成者に適用された OLS 規則の結果を参照します。 したがって、複合モデルに基づいて新しいレポートが作成されると、フィールドの一覧には、現在のユーザーがソース モデル内でアクセス権を持っているものに関係なく、複合モデルの作成者がモデルの作成時にアクセス権を持っていたテーブルが表示されます。
• 複合モデル自体に OLS 規則を定義することはできません。
• 複合モデルのコンシューマーは、参照できないことになっている実際のデータを参照できません。これは、DirectQuery がコンシューマーの資格情報を使用してデータを取得しようとしたときに、ソース モデルの関連する OLS 規則によってコンシューマーがブロックされるためです。
• ソース モデルで OLS 規則が更新された場合、それらの変更は複合モデルの更新時にのみ複合モデルに影響します。

Power BI セマンティック モデルまたは Analysis Services モデルからのテーブルのサブセットの読み込み

DirectQuery 接続を使用して Power BI セマンティック モデルまたは Analysis Services モデルに接続する場合は、どのテーブルに接続するかを決定できます。 また、モデルへの接続を確立した後に、セマンティック モデルまたはモデルに追加される可能性のあるテーブルを自動的に追加するように選択することもできます。 パースペクティブに接続する場合、モデルにはセマンティック モデル内のすべてのテーブルが含まれ、パースペクティブに含まれていないテーブルはすべて非表示になります。 さらに、パースペクティブに追加される可能性のあるすべてのテーブルは自動的に追加されます。 [設定] メニューでは、最初に接続を設定した後にセマンティック モデルに追加されたテーブルに、自動的に接続することを決定できます。

ライブ接続の場合、このダイアログは表示されません。

Note

このダイアログは、Power BI セマンティック モデルに DirectQuery 接続を追加した場合、または既存のモデルに Analysis Services モデルを追加した場合にのみ表示されます。 また、DirectQuery 接続を作成した後にデータソースの設定で、Power BI セマンティック モデルか Analysis Services モデルに変更して、このダイアログを開くこともできます。

重複除去規則を設定する

前に示されたダイアログの [設定] オプションを使用して、複合モデルでメジャーとテーブルの名前を一意に保つための重複除去規則を指定できます。

前の例では、複合モデル内の別のソースと競合しているテーブルまたはメジャーの名前にサフィックスとして "(marketing)" を追加しました。 次のことを実行できます。

• 競合するテーブルまたはメジャーの名前に追加するテキストを入力する
• テキストを、テーブルまたはメジャーの名前にプレフィックスまたはサフィックスのどちらとして追加するかを指定する
• 重複除去規則をテーブルかメジャー、またはこの両方に適用する
• 重複除去規則を、名前の競合が発生した場合にのみ適用するか、常に適用するかを選択する。 既定では、重複が発生した場合にのみ規則を適用します。 この例では、売り上げのソースに重複がないマーケティングのソースのテーブルまたはメジャーは、名前が変更されません。

接続を作成し、重複除去規則を設定すると、この例で設定した重複除去規則に従って、フィールドの一覧に "Customer" と "Customer (marketing)" の両方が表示されます。

重複除去規則を指定しない場合、または指定した重複除去規則で名前の競合が解決されない場合でも、標準の重複除去規則は適用されます。 標準の重複除去規則では、競合する項目の名前に番号を追加します。 "Customer" テーブルで名前の競合が発生した場合、"Customer" テーブルの 1 つが "Customer 2" という名前に変更されます。

XMLA の変更と複合モデル

XMLA を使用してセマンティック モデルを変更する場合は、変更されたオブジェクトの ChangedProperties コレクションと PBI_RemovedChildren コレクションを更新して、変更または削除されたプロパティを含める必要があります。 その更新を実行しない場合、次にスキーマがデータ ソースと同期されるときに、Power BI モデリング ツールによって変更が上書きされる可能性があります。

セマンティック モデル オブジェクト系列タグの詳細については、Power BI セマンティック モデルの 系列タグに関する記事 参照してください。

考慮事項と制限事項

複合モデルには、いくつかの考慮事項と制限事項があります。

混合モード接続 - オンライン データ (Power BI セマンティック モデルなど) とオンプレミス セマンティック モデル (Excel ブックなど) を含む混合モード接続を使う場合、視覚エフェクトを適切に表示するには、ゲートウェイ マッピングを確立する必要があります。

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

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

• SAP HANA
• SAP Business Warehouse
• バージョン 2022 より前の SQL Server Analysis Services
• 使用状況メトリック (マイ ワークスペース)

複合モデルでのストリーミング セマンティック モデルの使用はサポートされていません。

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

テーブルの一部が DirectQuery モードである複合モードで行レベルのセキュリティを使用している場合、DirectQuery テーブルから新しい更新を適用するためにモデルを更新する必要があります。 たとえば、DirectQuery モードの Users テーブルにソース側で新しいユーザー レコードがある場合、新しいレコードは次のモデルの更新後にのみ含まれます。 Power BI サービスは、パフォーマンスを向上させるために Users クエリをキャッシュし、次の手動またはスケジュールされた更新までソースからデータをリロードしません。

関連するコンテンツ

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

• Power BI Desktop で多対多リレーションシップを適用する
• Power BI Desktop でストレージ モードを管理する
• Power BI の DirectQuery
• Power BI データ ソース
• Power BI Desktop でのモデル リレーションシップ