DirectQuery モード (SSAS テーブル)

Analysis Services では、DirectQuery モードを使用してリレーショナル データベース システムからデータを直接取得して集計するテーブル モデルおよびレポートを作成できます。 DirectQuery モードを使用する利点としてよく挙げられるのは、メモリに収まらないほど大きなデータセットに対するクエリを実行できることと、リアルタイムでデータを更新できることです。

ここでは、メモリにのみ存在する標準テーブル モデルと、リレーショナル データ ソースにクエリを実行できるテーブル モデルの違いを紹介し、DirectQuery モードで使用するモデルを作成および配置する方法について説明します。

このトピックのセクション:

• DirectQuery モードの概要

• DirectQuery モードで使用するためのモデルの作成

  • DirectQuery モデルのデータ ソース

  • DirectQuery モードでの検証とデザインの制限

  • 数式の互換性

  • DirectQuery モデルへの接続

  • セキュリティ

• DirectQuery プロパティ

• 関連項目およびタスク

DirectQuery モードの概要

既定では、テーブル モデルでは、インメモリ キャッシュを使用してデータを格納およびデータにクエリを実行します。 テーブル モデルではメモリ内のデータを使用するため、複雑なクエリでも非常に高速に実行できます。 ただし、キャッシュされたデータの使用にはいくつかの欠点があります。

• ソース データが変更された場合、データは更新されません。 データを更新するには、モデルを処理する必要があります。

• モデルをホストするコンピューターの電源をオフにすると、キャッシュがディスクに保存され、モデルの読み込み時または PowerPivot ファイルを開くときに再び開かれます。 保存と読み込みの操作は時間がかかる場合があります。

対照的に、DirectQuery モードのテーブル モデルでは、SQL Server データベースまたは SQL Server PDW データ ウェアハウスに格納されているデータを使用します。 デザイン時に、すべてのデータまたはデータの小さなサンプルをキャッシュにインポートし、モデルを通常どおり作成します。 モデルを配置する準備ができたら、動作モードを DirectQuery に変更します。 動作モードを変更した後は、そのモデルに対するすべてのクエリで、キャッシュされたデータではなく、指定されたリレーショナル データ ソース (SQL Server またはSQL Server PDW) が使用されます。

モデルに対するレポートまたはクエリを作成するときは DAX を使用しますが、DAX クエリは、Analysis Services によって、指定されたリレーショナル データ ソースに対する同等の Transact-SQL ステートメントに変換されます。

DirectQuery モードを使用したモデルの配置には、かなりの利点があります。

• 大きすぎて Analysis Services サーバーのメモリに収まらないデータ セットのモデルを作成できます。

• データが最新であることが保証され、データの別のコピーを維持するための追加の管理オーバーヘッドがありません。 基になるソース データに対する変更は、データ モデルに対するクエリに即時に反映できます。

• DirectQuery では、xVelocity メモリによって最適化された列インデックスで提供されるアクセラレーションなど、プロバイダー側のクエリ アクセラレーションを利用できます。 xVelocity 列ストア インデックスは、SQL Server 2012 とSQL Server PDWの両方で、強化された DirectQuery のパフォーマンスをサポートするために用意されています。

• バックエンド データベースによって適用されるセキュリティは、行レベル セキュリティを使用して適用されることが保証されます。 対照的に、キャッシュされたデータを使用する場合は、サーバー上とまったく同様にキャッシュが保護されることを保証するのが困難な場合があります。

• 複数のクエリを必要とする可能性のある複雑な数式がモデルに含まれる場合、Analysis Services は最適化を実行して、バックエンド データベースに対して実行されるクエリのクエリ プランができるだけ効率的になることを保証できます。

DirectQuery モードのためのモデルのデザイン

すべてのテーブル モデルは、SQL Server データ ツール (SSDT) のモデル デザイナーを使用して作成されます。このモデル デザイナーは、既定でモデルを常にメモリに作成します。 つまり、大きすぎてメモリに収まらないデータを操作する場合は、デザイン時にデータの小さなサブセットを操作し、モデルを配置した後にのみ完全なデータ ソースにアクセスする必要があります。 データの小さなサブセットを操作するには、いくつかの方法があります。

• テーブルのインポート ウィザードを使用してデータをモデルに追加するときに、フィルターを使用して、ワークスペース データベースで使用するキャッシュにデータのサブセットのみをインポートします。 モデルを配置した後は、クエリ定義を編集してフィルターを削除または変更できます。

• ステージング データ ソースを使用し、ステージング テーブルにデータのサブセットのみが含まれているときにモデルをデザインします。

• テーブルにパーティションを追加して、任意の時点で処理する必要があるデータの量を管理します。

DirectQuery モードに切り替える準備ができたら、DirectQuery モードを有効にするプロパティを変更できます。 詳細については、「DirectQuery デザイン モードの有効化 (SSAS テーブル)」を参照してください。

この操作を行うと、モデル デザイナーは、キャッシュされたデータの操作を継続できるハイブリッド モードで実行するようにワークスペース データベースを自動的に構成します。 モデル デザイナーによって、モデル内の DirectQuery モードと互換性がない機能も通知されます。 考慮する必要のある主な要件を次の一覧にまとめます。

• データ ソース: DirectQuery モデルでは単一のリレーショナル データ ソースのデータのみ使用できます。 SQL Server のインスタンスまたはSQL Server PDWのインスタンスをソースとして使用できます。 モデルに対して DirectQuery モードを有効にした後は、コピーと貼り付け操作によって追加されたテーブルなど他の種類のデータをモデル デザイナーで使用できなくなります。 他のすべてのインポート オプションが無効になります。 さらに、クエリに含まれるテーブルは、指定されたデータ ソースに属している必要があります。 詳細については、「データ ソース」を参照してください。

• 計算列のサポート: 計算列は、DirectQuery モデルではサポートされません。 ただし、データ セットを操作するメジャーと KPI を作成できます。 詳細については、検証に関するセクションを参照してください。

• DAX 関数の制限された使用: 一部の DAX 関数は DirectQuery モードで使用できないため、他の関数で置き換えるか、データ ソースの派生列を使用して値を作成する必要があります。 モデル デザイナーには、DirectQuery モードと互換性のない数式を作成したときに発生するエラーのデザイン時検証が用意されています。 詳細については、検証に関するセクションを参照してください。

• 数式の互換性: 特定の既知のケースでは、同じ数式で返される結果が、キャッシュ モデルまたはハイブリッド モデルと、リレーショナル データ ストアのみを使用する DirectQuery モデルとで異なる場合があります。 これらの相違は、xVelocity メモリ内分析 (VertiPaq) エンジンと SQL Server 間のセマンティックの相違によるものです。 これらの相違の詳細については、数式の互換性に関するセクションを参照してください。

• セキュリティ: モデルの保護には、モデルの配置方法に応じて異なる方法を使用できます。 テーブル モデルのキャッシュされたデータは、Analysis Services インスタンスのセキュリティ モデルを使用して保護されます。 DirectQuery モデルはロールを使用して保護することもできますが、リレーショナル データ ストアに定義されているセキュリティも使用できます。 DirectQuery のみのモデルに基づいてレポートを開くユーザーは、SQL Server のアクセス許可で許可されているデータのみ表示できるようにモデルを構成できます。 詳細については、セキュリティに関するセクションを参照してください。

• クライアントの制限: モデルが DirectQuery モードの場合は、DAX を使用しないとクエリを実行できません。 MDX を使用してクエリを作成することはできません。 つまり、Excel では MDX を使用するため Excel PivotClient を使用できません。

  ただし、DAX テーブル クエリを XMLA Execute ステートメントの一部として使用する場合は、SQL Server Management Studio で DirectQuery モデルに対してクエリを作成できます。詳細については、「DAX クエリ構文のリファレンス」を参照してください。

デザインの問題をすべて解決し、モデルをテストすると、配置の準備ができます。 この時点で、モデルに対するクエリの応答に対して優先される方法を設定できます。 ユーザーがキャッシュにアクセスできるようにしますか。または常にリレーショナル データ ソースのみ使用するようにしますか。

モデルをハイブリッド モードで配置する場合も、キャッシュは使用可能で、クエリに使用できます。 ハイブリッド モードには、多くのオプションが用意されています。

• キャッシュとリレーショナル データ ソースの両方が使用可能な場合は、優先される接続方法を設定できますが、最終的には、クライアントが DirectQueryMode 接続文字列プロパティを使用して、使用されるソースを制御します。

• DirectQuery モードに使用されるプライマリ パーティションが処理されず、常にリレーショナル ソースが参照されるような方法で、キャッシュにパーティションを構成することもできます。 モデル デザインとレポート環境を最適化するために、多くの方法でパーティションを使用できます。 詳細については、「パーティションと DirectQuery モード (SSAS テーブル)」を参照してください。

• モデルが配置された後、優先される接続方法を変更できます。 たとえば、テストにはハイブリッド モードを使用し、モデルを使用するレポートまたはクエリを完全にテストした後でのみ DirectQuery のみのモードに切り替えることができます。 詳細については、「DirectQuery の優先接続方法の設定または変更」を参照してください。

DirectQuery モデルのデータ ソース

デザイン環境を変更して DirectQuery モードを有効にするとすぐに、ワークスペース データベースのデータ ソースが検証されて、データ ソースが単一のリレーショナル データ ソースから取得されたことが確認されます。 コピー貼り付けデータなど他のソースからのデータは、DirectQuery モデルでは許可されていません。

DirectQuery モードでモデルを使用する場合は、レポートに必要なすべてのデータが指定したデータ ソースに格納されていることを確認する必要があります。 モデリングに必要なデータがそのソースで使用可能でない場合は、Integration Services またはその他のデータ ウェアハウジング ツールを使用して、DirectQuery データ ソースとして使用するデータベースまたはデータ ウェアハウスにデータをインポートすることを検討してください。

DirectQuery モードでの検証とデザインの制限

DirectQuery モードで使用するモデルを作成する場合は、最初にデータの一部をキャッシュに読み込む必要があります。 最終的に使用するデータが大きすぎてメモリに収まらない場合は、テーブルのインポート ウィザードの [プレビューとフィルター] オプションを使用してデータのサブセットを選択するか、目的のデータを取得する SQL スクリプトを作成できます。 別の方法として、データ ウェアハウスのデータのサブセットをステージングし、デザイン フェーズが終了した後にデータ ストアを拡大する方法があります。

注意
DirectQuery モードでは計算列の使用がサポートされないため、計算列を削除する必要があります。 一部の計算列はメジャーに変換できますが、それ以外の場合は、派生列をデータ インポート クエリまたはスクリプトの一部として作成するか、リレーショナル データ ソース内で追加します。

検証エラーを表示して解決するには、SQL Server Data Tools の [エラー一覧] を開きます。 DirectQuery モードの使用を妨げる重大なエラーが [エラー] タブに表示されます。 DirectQuery モードに変更する前にこれらのエラーを修正する必要があります。 解決が難しい検証エラーは、通常、DirectQuery モードではサポートされない数式に関連します。 数式と計算列に関連するエラーの概要については、数式の互換性に関するセクションを参照してください。

DirectQuery アクセス用のモデルの作成時に考慮するその他の事項を次の一覧で説明します。

• DirectQuery のみのモードでは、レポートの結果は結果を表示するユーザーのセキュリティ コンテキストによって異なる可能性があります。 ユーザーが期待どおりの結果を得られるように、さまざまな資格情報でモデルをテストする必要があります。

• ハイブリッド モードで動作するようにモデルを構成して、リレーショナル ソースのキャッシュまたはデータを使用できるようにするには、各ソースに接続するクライアントが異なる結果を参照する可能性がある (接続文字列に指定されたモードによって異なる) ことを認識する必要があります。 レポートを表示するユーザーにリレーショナル ソースのデータのみ表示されるようにする必要がある場合は、キャッシュをクリアするかモデルを DirectQueryOnly に変更する必要があります。

DirectQuery モデルでの数式の互換性

一部のモデルには DirectQuery モードではサポートされない数式が含まれており、検証エラーを防ぐためにモデルを再デザインする必要があります。 DirectQuery モードでサポートされている数式の制限を次に示します。

• 計算列は、ハイブリッド モデルの場合でも、DirectQuery モードが有効になっているテーブル モデルではサポートされません。 モデルに計算列が必要な場合は、インポート定義で Transact-SQL を使用して派生列に変換することを検討してください。

• DirectQuery モデルでは、メジャーで使用する DAX 数式の使用がサポートされます。これらの数式は、リレーショナル データ ストアに対するセットベースの操作に変換されます。 暗黙的なメジャーを使用して作成できるメジャーもサポートされます。

• すべての関数がサポートされるわけではありません。 Analysis Services は、DirectQuery モデルにクエリを実行するときにすべての DAX 数式およびメジャー定義を SQL ステートメントに変換するため、Transact-SQL に変換できない要素を含む数式はモデルで検証エラーをトリガーします。 たとえば、タイム インテリジェンス関数はサポートされていません。 統計関数などのサポートされている関数も、動作が異なる可能性があります。 互換性の問題の一覧については、「DirectQuery モードでの数式の互換性」を参照してください。

• モデル内の一部の数式は、モデルを DirectQuery モードに切り替えるときに検証できますが、キャッシュとリレーショナル データ ストアに対して実行したときに 異なる結果を返します。 これは、キャッシュに対する計算では Excel の動作をエミュレートすることを意図した多くの機能を含む xVelocity メモリ内分析 (VertiPaq) エンジンのセマンティクスが使用され、リレーショナル データ ストアに格納されているデータに対するクエリでは SQL Server のセマンティクスを使用する必要があるためです。 モデルがリアルタイムで配置される場合に異なる結果を返す可能性のある DAX 関数の一覧については、「DirectQuery モードでの数式の互換性」を参照してください。

DirectQuery モデルへの接続

クエリ言語として MDX を使用するクライアントは、DirectQuery モードを使用するモデルに接続できません。 DirectQuery モデルに対して MDX クエリを作成しようとした場合は、キューブが見つからない、または処理されていないことを示すエラーが発生します。 Power View、DAX 数式、または XMLA クエリを使用して、DirectQuery モデルに対するクエリを作成できます。 テーブル モデルに対するアドホック クエリの実行方法の詳細については、「テーブル モデル データ アクセス」を参照してください。

ハイブリッド モデルを使用している場合は、接続文字列プロパティ DirectQueryMode を指定して、ユーザーがキャッシュに接続するか DirectQuery データを使用するかを指定できます。

DirectQuery モードでのセキュリティ

モデル作成時に、ソース データの取得に使用するアクセス許可を指定します。 これは、多くの場合、自分の資格情報か、開発に使用されるアカウントになります。 ただし、DirectQuery モードを使用するようにモデルを切り替えると、セキュリティ コンテキストはより複雑になります。

• ユーザーに、リレーショナル データ ストアのデータに必要なアクセス レベルがあるかどうかを検討します。

• 同じモデルまたはレポートを表示するユーザーは、ユーザーのセキュリティ コンテキストに応じて異なるデータを参照する場合があります。

• モデル キャッシュが保持されている場合、キャッシュは Analysis Services セキュリティ モデル (ロール) を使用して保護されます。 キャッシュには、モデル デザイナーが表示権限を持ち、ユーザーが表示権限を持たないデータが含まれている場合があります。 モデルおよびレポート デザイナーでキャッシュをクリアするか、ロールによってアクセスを制御することでこのデータを保護する必要があります。

• キャッシュからクエリに応答するモデルは、データ ソースに接続するときに現在のユーザーの権限を借用できません。 データ ソースに接続するときに現在のユーザーの権限を借用する場合には、DirectQuery モードを使用する必要があります。

• レポート モデルにセキュリティが必要な場合は、Analysis Services ロールを使用するか、またはデータ ソースに行レベルのアクセス許可を設定するという、2 つのオプションがあります。 テーブルへのアクセスの制御にはリレーショナル データ ソースのセキュリティが使用され、列レベルのセキュリティはサポートされていません。 したがって、1 つの地域のユーザーが異なる地域の売上金額を表示する権限を持たない場合、Sales テーブルに基づくメジャーを含むレポートでは空白またはエラーが返されます。

DirectQuery のみのモデルでも、DirectQuery を使用してクエリに応答するハイブリッド モデルでも、権限借用設定プロパティによって、DirectQuery を使用してモデルに接続するときに使用される資格情報が指定されます。 プロパティの値は次のとおりです。

• 既定
  インポート ウィザードで指定した資格情報を使用して、データ ソースに接続します。 これには、特定の Windows ユーザーまたはサービス アカウントを指定できます。

• ImpersonateCurrentUser
  現在のユーザーの資格情報を使用して、データ ソースに接続します。

これらのプロパティの設定方法については、「DirectQuery の配置シナリオ (SSAS テーブル)」を参照してください。

DirectQuery プロパティ

DirectQuery を有効にし、モデルに対するクエリに使用されるデータのソースを制御するために SQL Server Data Tools および SQL Server Management Studio で設定できるプロパティの一覧を次の表に示します。

また、モデルにパーティションが含まれる場合は、DirectQuery モードでクエリのソースとして使用するパーティションを 1 つ選択する必要があります。 詳細については、「パーティションと DirectQuery モード (SSAS テーブル)」を参照してください。

関連項目およびタスク

関連項目

概念

パーティション (SSAS テーブル)

テーブル モデル プロジェクト (SSAS テーブル)

Excel で分析 (SSAS テーブル)