Power BI で DirectQuery を使用して SAP HANA データ ソースに接続する
DirectQuery を使用して、SAP HANA データ ソースに直接接続できます。 SAP HANA には 2 つの方法で接続できます。
SAP HANA を多次元ソースとして扱う (既定): この場合の動作は、Power BI から SAP Business Warehouse や Analysis Services など、他の多次元ソースに接続するときの動作に似ています。 この設定を使用して SAP HANA に接続すると、単一の分析または計算ビューが選択され、そのビューのすべてのメジャー、階層、属性がフィールド リストに表示されます。 ビジュアルを作成すると、集計データは常に SAP HANA から取得されます。 この技法は推奨される手法であり、SAP HANA を利用する新しい DirectQuery レポートの既定の手法です。
SAP HANA をリレーショナル ソースとして扱う: この場合、Power BI は SAP HANA をリレーショナル ソースとして扱います。 この手法により、柔軟性が向上します。 この方法では、メジャーを想定どおりに確実に集計し、パフォーマンスの問題を回避するように注意する必要があります。
接続手法はグローバル ツール オプションによって決定されます。これを設定するには、次の画像に示すように、[ファイル]>[オプションと設定]、[オプション]>[DirectQuery] の順に選択し、[SAP HANA をリレーショナル ソースとして扱う] オプションをオンにします。
SAP HANA をリレーショナル ソースとして扱うオプションは、SAP HANA を介して DirectQuery を使う "新しい" レポートに対して使われる方法を制御します。 現在のレポートの既存の SAP HANA 接続に影響を与えることはありません。開いている他のレポートの接続に影響を与えることもありません。 そのため、このオプションが現在選択されていない場合は、[データの取得] を使って SAP HANA への新しい接続を追加すると、その接続は SAP HANA を多次元ソースとして扱うように作成されます。 ただし、別のレポートを開いていて、それも SAP HANA に接続されている場合は、そのレポートは引き続き、"その作成時に" 設定されたオプションに従って動作します。 このことは、2018 年 2 月より前に作成されたレポートが SAP HANA に接続されている場合、そのレポートは引き続き、SAP HANA をリレーショナル ソースとして扱うことを意味します。
この 2 つの手法は動作が異なっており、既存のレポートの手法を切り替えることはできません。
SAP HANA を多次元ソースとして扱う (既定)
SAP HANA に対するすべての新規接続では、この接続方法が既定で使われ、SAP HANA を多次元ソースとして扱います。 SAP HANA への接続をリレーショナル ソースとして扱うためには、[ファイル]>[オプションと設定]>[オプション] を選択し、[直接クエリ]>[SAP HANA をリレーショナル ソースとして扱う] チェック ボックスをオンにします。
多次元ソースとして SAP HANA に接続する場合は、次の考慮事項が適用されます。
データ取得ナビゲーターでは、SAP HANA ビューを 1 つ選択できます。 メジャーや属性を個々に選択することはできません。 接続時に定義するクエリはありません。これは、データをインポートする場合や、SAP HANA をリレーショナル ソースとして扱い、DirectQuery を使用する場合とは異なります。 この考慮事項は、この接続方法を選択すると、SAP HANA SQL クエリを直接使用することはできないことも意味します。
選択したビューのすべてのメジャー、階層、属性がフィールド リストに表示されます。
ビジュアルでメジャーが使用されると、SAP HANA に対して、そのビジュアルに必要な集計レベルでメジャー値を取得するようにクエリが実行されます。 カウンターや比率など、非加法メジャーを扱う場合、集計はすべて SAP HANA によって実行され、その後の集計が Power BI によって実行されることはありません。
SAP HANA から正しい集計値が常に得られるように、特定の制約を課す必要があります。 たとえば、計算列を追加することはできません。同じレポート内で複数の SAP HANA ビューのデータを組み合わせることはできません。
SAP HANA を多次元ソースとして扱うと、代替の "リレーショナル" 手法によって提供される高い柔軟性は得られませんが、シンプルになります。 また、この手法により、より複雑な SAP HANA メジャーを扱う際に正しい集計値が保証され、一般にパフォーマンスが向上します。
[フィールド] リストには、SAP HANA ビューのすべてのメジャー、属性、階層が含まれます。 この接続手法で発生する次の動作に注意してください。
属性が少なくとも 1 つの階層に含まれるとき、その属性は既定では表示されません。 ただし、必要であれば、フィールド一覧のコンテキスト メニューで [非表示を表示] を選択すると表示できます。 必要に応じて、同じコンテキスト メニューから、表示するように変更できます。
SAP HANA では、そのラベルとして別の属性を使用するように属性を定義できます。 たとえば、Product (値は
1、2、3...) で、ProductName (値はBike、Shirt、Glovesなど) をそのラベルとして使用できます。 この場合、1 つのフィールド Product がフィールド リストに表示されます。その値はBike、Shirt、Glovesなどのラベルですが、並べ替えと一意性の決定にはキー値の1、2、3が使われます。 非表示列の Product.Key も作成され、必要に応じて、基になるキー値にアクセスできます。
基になる SAP HANA ビューで定義されている変数が接続時に表示され、必要な値を入力できます。 これらの値は、リボンから [データの変換] を選択し、表示されるドロップダウン メニューから [パラメーターの編集] を選択すると、後で変更できます。
許可されるモデリング操作には、DirectQuery 使用時の一般的なケースよりも制約が多くなります。SAP HANA から常に正しい集計データが得られるようにする必要があるためです。 ただし、さまざまな追加や変更が可能です。たとえば、メジャーを定義したり、フィールドの名前を変更したり、フィールドを非表示にしたり、表示形式を定義したりできます。 このような変更はすべて更新時に保存され、SAP HANA ビューに行われた競合しない変更が適用されます。
その他のモデリングの制限
DirectQuery を使用して SAP HANA に接続する (多次元ソースとして扱う) 場合のその他の主なモデリング上の制限は次のとおりです。
- 計算列のサポートがない: 計算列を作成する機能は無効です。 このことは、計算列を作成するグループ化とクラスタリングを使用できないことも意味します。
- メジャーのその他の制限: SAP HANA から提供されるサポート レベルを反映するために、メジャーで使用できる DAX 式には他にも制限あります。
- リレーションシップ定義のサポートがない: 1 つのレポート内では、1 つのビューにのみクエリを実行できます。そのため、リレーションシップ定義はサポートされていません。
- データ ビューがない:[データ ビュー] は、通常詳細レベル データをテーブルに表示します。 SAP HANA などの OLAP ソースの性質上、このビューは SAP HANA では使用できません。
- 列とメジャーの詳細が固定されている: フィールド リストに表示される列とメジャーのリストは、基になるソースによって固定されており、変更できません。 たとえば、列を削除したり、そのデータ型を変更したりできません。 ただし、名前を変更することはできます。
- DAX のその他の制限: ソースの制限を反映するために、メジャー定義で使用できる DAX には他にも制限があります。 たとえば、テーブルに集計関数は使用できません。
視覚エフェクトのその他の制限
DirectQuery を使用して SAP HANA に接続する (多次元ソースとして扱う) とき、ビジュアルには制約があります。
- 列集計なし: ビジュアルでは列の集計を変更できません。常に [集計しない] です。
SAP HANA をリレーショナル ソースとして扱う
リレーショナル ソースとして SAP HANA に接続することを選択すると、柔軟性がさらに強化されます。 たとえば、計算列を作成したり、複数の SAP HANA ビューからデータを含めたり、生成されたテーブル間で関係を構築したりできます。 ただし、SAP HANA を多次元ソースとして扱う場合、特に、単純な合計ではなく、個別のカウントや平均など、非加法メジャーが SAP HANA ビューに含まれる場合の動作とは異なり、SAP HANA に対して実行されるクエリの効率に関連します。
[データの取得] または [Power Query エディター] で定義したクエリで集計を実行するとき、SQL Server など、リレーショナル ソースの動作を最初に確認することをお勧めします。 次の例では、 [Power Query エディター] で定義したクエリによって、ProductID 別に平均価格が返されます。
Power BI にデータをインポートする場合と DirectQuery を使用する場合では、次の状況になります。
- データは、 [Power Query エディター] で作成したクエリで定義されている集計レベルでインポートされます。 たとえば、製品ごとの平均価格です。 このことにより、ビジュアルで使用できる ProductID と AveragePrice の 2 つの列を持つテーブルが作成されます。
- ビジュアルでは、Sum、Average、Min など、後続の集計はすべて、そのインポートされたデータに対して実行されます。 たとえば、ビジュアルに AveragePrice を含めると、既定で Sum 集計が使用され、各 ProductID の AveragePrice の合計 (この例では 13.67) が返されます。 同じことが、ビジュアルで使用される Min や Average などの代替集計関数にも当てはまります。 たとえば、AveragePrice の Average では、6.66、4、および 3 の平均である 4.56 が返されます。元の表の 6 つのレコードの Price の平均 (5.17) ではありません。
インポートの代わりに同じリレーショナル ソースに DirectQuery が使用される場合、同じセマンティクスが適用され、結果はまったく同じになります。
クエリが同じ場合は、データが実際にインポートされなくても、論理的にまったく同じデータがレポート層に表示されます。
ビジュアルでは、Sum、Average、Min など、後続の集計はすべて、クエリの論理テーブルに対して再度実行されます。 ここでも、AveragePrice の Average を含むビジュアルでは、同様に 4.56 が返されます。
接続をリレーショナル ソースとして扱う場合は、SAP HANA を検討します。 Power BI は SAP HANA の、メジャーを含むことができる分析ビューと計算ビューの両方で使用することができます。 しかしながら、現在、SAP HANA に対する手法は、このセクションで前述したのと同じ原則に従います。つまり、[データの取得] または Power Query エディターで定義したクエリによって使用可能なデータが決定され、ビジュアル内の以降の集計はすべて、そのデータに対して行われます。同じことが、インポートと DirectQuery の両方に適用されます。 ただし、SAP HANA の性質上、最初の [データの取得] ダイアログまたは [Power Query エディター] で定義されるクエリは常に集計クエリであり、一般に、実際に使用される集計が SAP HANA ビューで定義されるメジャーが含まれます。
先ほどの SQL Server の例と同等なものとして、ID、ProductID、DepotID を含む SAP HANA ビューと、ビュー内に Average of Price と定義された AveragePrice を含むメジャーがあります。
[データの取得] エクスペリエンスで、選択されたのが ProductID と AveragePrice メジャーだった場合、それは、ビューに対するクエリを定義し、その集計データを要求しています。 前の例では、わかりやすくするために、SAP HANA SQL の正確な構文と一致しない擬似 SQL が使用されています。 すると、ビジュアルで定義されている以降の集計は、このようなクエリの結果がさらに集計されます。 SQL Server について前述したように、この結果もインポートと DirectQuery の両方に適用されます。 DirectQuery の場合、[データの取得] または Power Query エディターからのクエリは SAP HANA に送信される単一のクエリのサブセレクト内で使用されます。したがって、その後の集計の前に、すべてのデータが読み込まれるわけではありません。
これらのすべての考慮事項と動作では、SAP HANA で DirectQuery を使用するとき、重要な事項に従うことが要求されます。
単純な Sum、Min または Max ではないなど、SAP HANA のメジャーが非加法の場合、ビジュアルで実行されるその後の集計に注意を払う必要があります。
[データの取得] または Power Query エディターでは、結果が SAP HANA に送信できる妥当なクエリでなければならないという事実を反映して、必要なデータを取得するために必要な列のみを含める必要があります。 たとえば、以降のビジュアルで必要になる可能性があると考え、数十列を選択すると、DirectQuery の単純なビジュアルであっても、サブセレクトで使用される集計クエリに、それらの数十列が含まれることになるため、通常、パフォーマンスが低下します。
次の例で、[データの取得] ダイアログで 5 つの列 (CalendarQuarter、Color、LastName、ProductLine、SalesOrderNumber) をメジャー OrderQuantity と共に選択すると、Min OrderQuantity を含む単純なビジュアルを後で作成したときに、SAP HANA への次の SQL クエリが含まれることを意味します。 灰色の部分は、[データの取得] または Power Query エディターからのクエリを含むサブセレクトです。 このサブセレクトにより結果のカーディナリティが高くなる場合、結果の SAP HANA のパフォーマンスが低下する可能性があります。
この動作のため、 [データの取得] または [Power Query エディター] で選択するアイテムは、それが結果として SAP HANA で妥当なクエリとなる、必要なもののみに制限することをお勧めします。
ベスト プラクティス
SAP HANA に接続する両方の手法について、DirectQuery を使用するための推奨事項、特に、優れたパフォーマンスの確保に関連する推奨事項は、SAP HANA にも適用されます。 詳細については、Power BI Desktop での DirectQuery の使用に関する記事を参照してください。
考慮事項と制限事項
次の一覧は、完全にサポートされていないか、Power BI を使用した場合に異なる動作をする SAP HANA の機能をすべてまとめたものです。
- 親子階層: 親子階層は Power BI に表示されません。 これは、Power BI では SAP HANA にアクセスするのに SQL インターフェイスを使用していて、SQL を使用すると、親子階層に完全にはアクセスできないからです。
- その他の階層メタデータ: 階層の基本構造が Power BI に表示されますが、不均衡階層の動作制御など、一部の階層メタデータには効力がありません。 これもまた、SQL インターフェイスによって課される制限が原因です。
- SSL を使用した接続: TLS と共にインポートと多次元を使用して接続できますが、リレーショナル コネクタに TLS を使用するように構成された SAP HANA インスタンスに接続することはできません。
- 属性ビューのサポート: Power BI は分析ビューと計算ビューに接続できますが、属性ビューには直接接続できません。
- カタログ オブジェクトのサポート: Power BI からカタログ オブジェクトに接続することはできません。
- 公開後、変数に変更する: レポートの公開後、Power BI サービスで直接、SAP HANA 変数の値を変更することはできません。
既知の問題
次の一覧は、Power BI を使用して SAP HANA (DirectQuery) に接続するときに発生する既知の問題をまとめたものです。
カウンターやその他のメジャーについてクエリを実行するときの SAP HANA の問題: 分析ビューに接続していて、カウンター メジャーやその他の比率メジャーが同じビジュアルに含まれている場合、SAP HANA から正しくないデータが返されます。 この問題は、SAP ノート 2128928 (計算列とカウンターにクエリを実行すると、予想外の結果が返される) で説明されています。 この場合、比率メジャーが正しくありません。
1 つの SAP HANA 列からの複数の Power BI 列: 一部の計算ビューで、複数の階層で 1 つの SAP HANA 列が使用されるとき、SAP HANA により、この列は 2 つの別々の属性として公開されます。 この手法では、結果的に Power BI に 2 つの列が作成されます。 ただし、このような列は既定で非表示になります。階層を伴うか、列を直接伴うクエリはすべて正しく動作します。
関連するコンテンツ
DirectQuery の詳細については、次のリソースを参照してください。