SAP HANA
SAP HANAのグラフィカル計算ビューとSQLScript計算ビューの違い・使い分け
SAP HANAのグラフィカル計算ビューとSQLScript計算ビューを、処理の表現力、保守性、性能確認、権限、テストの観点から比較します。実際のモデリングで迷わない選択基準と運用手順を解説します。
SAP HANAで分析用のデータモデルを作るとき、グラフィカル計算ビューとSQLScript計算ビューのどちらを選ぶかは、見た目の好みよりも処理内容と運用方法で決めます。単純な結合や集計はグラフィカル計算ビューで整理しやすく、複雑な条件分岐や再利用するロジックはSQLScript計算ビューで明示しやすい構成です。
この記事では、両者の構造上の違い、グラフィカルビューが得意な処理、SQLScriptビューへ切り替える判断、性能確認と障害対応の進め方を、SAP HANA on-premiseの開発現場を想定して説明します。全体の開発方針を確認する場合は、SAP HANA開発の全体像も参照してください。
グラフィカル計算ビューとSQLScript計算ビューの基本
グラフィカル計算ビューは、データソース、投影、結合、集計、計算列、フィルターなどの処理をノードとして配置し、データの流れを視覚的に表現します。各ノードの入力と出力が確認しやすいため、処理の構造をチームで共有しやすい方式です。
SQLScript計算ビューは、SQLまたはSQLScriptを中心にロジックを記述します。結合条件、派生列、共通テーブル式、条件分岐、複数段階のデータ加工などをコードとして管理できるため、処理を細かく制御できます。コードレビューや差分確認では、変更内容を行単位で追跡しやすい点が利点です。
どちらも最終的には、分析クライアントやSQL文から参照できる計算ビューとして利用します。選択の中心になるのは、処理を図として管理する価値と、コードとして明示する価値のどちらが大きいかです。
処理内容で選ぶ判断基準
最初に、必要な処理を次のように分類します。
- 既存テーブルやビューの読み込み
- 列の選択、名前変更、データ型の整理
- 等価結合や外部結合
- 集計、グループ化、重複排除
- 固定的な計算列や単純なフィルター
- 条件分岐、複数段階の中間結果、再利用ロジック
- パラメーターを使った複雑な抽出
- 一時的なデータ加工や手続き的な処理
前半の処理が中心で、データの流れを図で説明できる場合はグラフィカル計算ビューが適しています。業務担当者や保守担当者が、どのテーブルを結合してどの項目を集計しているかを確認する場面でも、ノード構成が役立ちます。
後半の処理が中心で、条件分岐や中間結果が増える場合はSQLScript計算ビューを検討します。処理の意図をコメントや命名規則で説明でき、複雑なロジックを一つのコードベースで管理しやすくなります。
既存の計算ビューを調査するときは、まず入力データ、出力列、フィルター、集計粒度を整理します。処理の目的と粒度が明確になってから方式を決めると、作り直しを抑えられます。計算ビューの構成要素を確認する場合は、SAP HANA計算ビューの基本も役立ちます。
グラフィカル計算ビューが向くケース
グラフィカル計算ビューは、処理の流れが安定していて、各段階を明確なノードに分けられるモデルに向いています。たとえば、売上明細と商品マスタを結合し、期間で絞り込み、商品カテゴリ単位で数量と金額を集計するモデルです。
設計時に確認する項目
- どのノードで行数が増減するか
- 結合前後でキーの一意性が保たれているか
- 集計前の明細粒度が適切か
- 計算列のデータ型とNULLの扱いが明確か
- 入力列を必要最小限に絞っているか
- セマンティックな出力列名と説明が設定されているか
グラフィカルな構成では、各ノードの役割を短い名前で表します。結合、投影、集計を一つのノードに詰め込まず、意味のある段階に分けると、データプレビューと障害調査が容易になります。
ただし、ノード数が増えすぎると、画面上の見通しが悪くなり、同じ計算式が複数箇所に分散します。計算列の依存関係や複雑な条件が図だけで読み取りにくくなった時点で、ロジックの分割方法を再評価します。
グラフィカルビューで起きやすい制限
グラフィカル計算ビューは、定型的なリレーショナル処理を視覚化する用途に強みがあります。一方で、処理の形がノードの組み合わせに収まりにくい場合は、設計と保守の負担が増えます。
代表的な判断ポイントは次のとおりです。
- 複数の条件分岐が連続する
- 同じ複雑な式を複数のノードで再利用する
- 中間結果を段階的に加工する
- 入力条件によって処理経路が大きく変わる
- SQLの集合演算や共通テーブル式を明示したい
- ロジックをコードレビューで比較したい
- 既存のSQLScript処理を同じ意図のまま移植したい
このような場合は、図を細かく分割するだけで解決しようとせず、SQLScript計算ビュー、テーブル関数、または別の再利用可能なモデルへの分割を検討します。方式の変更は、処理の正しさ、権限、性能、デプロイ単位をまとめて評価して決めます。
SQLScript計算ビューが向くケース
SQLScript計算ビューは、データ加工の手順や条件をコードで管理するモデルに向いています。複数の入力を組み合わせ、段階ごとに中間結果を作り、最後に出力を整形する処理では、SQLScriptの記述が意図を表しやすくなります。
特に次のような処理で有効です。
- 複数の条件に応じた派生値の計算
- 共通テーブル式を使った段階的な抽出
- 複数ソースの結果を集合演算で統合する処理
- 同じロジックを複数の出力列で参照する処理
- SQLで表現したほうが結合条件を確認しやすい処理
- テスト用の入力条件を固定しやすい処理
SQLScriptを選ぶ場合は、コードを書けることだけでなく、読み手が処理順序と出力粒度を追跡できることを重視します。変数名、CTE名、出力列名を業務上の意味に合わせ、複雑な式は小さな段階へ分けます。
SQLScriptのプロシージャや関連する設計方針を確認する場合は、SAP HANA SQLScriptプロシージャの実装ポイントを参照してください。
性能を比較する実務手順
グラフィカルかSQLScriptかを性能だけで決める場合は、同じ入力条件と同じ出力粒度で比較します。入力行数、結合後の行数、集計前の行数、最終出力行数を記録すると、遅延の発生箇所を特定しやすくなります。
比較の進め方
- 同じデータソースと同じフィルター条件で2つのモデルを用意する
- 出力列、NULL処理、重複処理、集計粒度をそろえる
- 少量データと本番に近いデータ量で実行する
- 初回実行と繰り返し実行を分けて計測する
- 実行計画と高負荷になった処理段階を確認する
- 結果件数と代表的な集計値を照合する
計測では、総実行時間だけでなく、データ転送量、結合方法、フィルターが適用される位置、不要列の読み込みを確認します。計算ビューの設計が正しくても、結合前のデータを過剰に読み込むと処理時間が伸びます。
SQLScriptでは、処理を細かく書ける反面、不要な中間結果の生成や同じデータの複数回読み込みが起きることがあります。グラフィカル計算ビューでは、ノードの分割によって意図しないデータ増加が起きることがあります。どちらも実行計画と実データで判断します。
テストとデプロイの確認項目
開発環境での検証では、正常系だけでなく、空の入力、NULLを含む入力、重複キー、境界日付、想定外のコード値を用意します。グラフィカル計算ビューではノードごとに出力を確認し、SQLScript計算ビューでは中間結果を個別に検証できる形でSQLを整理します。
確認する項目は次のとおりです。
- 出力列の名前とデータ型
- 主キー相当の粒度と重複の有無
- NULL、空文字、ゼロの扱い
- 日付と時刻のタイムゾーン
- 通貨や数量の単位
- フィルター条件と入力パラメーター
- 必要なオブジェクト権限
- デプロイ後の参照先と依存関係
デプロイ後は、開発環境と同じ条件で結果件数を比較します。権限エラーが発生した場合は、実行ユーザーが参照するオブジェクトと計算ビューに必要な権限を確認します。権限設計を整理する際は、SAP HANAのユーザー権限とロール管理も関連します。
障害発生時の切り分け
結果が空になる場合は、入力データ、フィルター、結合条件、パラメーター値、集計条件の順に確認します。行数が想定より多い場合は、結合キーの重複と結合種別を調べます。列の値が異なる場合は、データ型変換、NULL処理、丸め、単位変換を確認します。
グラフィカル計算ビューでは、疑わしいノードの入力と出力を比較し、最初に結果が変化した箇所を探します。SQLScript計算ビューでは、CTEや中間結果を個別に実行できる形にして、条件式と結合条件を確認します。
SQL実行の検証にはSAP HANA database explorerのSQLコンソールを使えます。計算ビューを参照するSQLを段階的に実行し、結果件数、代表キー、集計値を確認します。管理状況やアラートの確認にはSAP HANA cockpitを使い、データモデルの結果とシステム状態を分けて調査します。
実務での選択フロー
次の順序で判断すると、方式の選択を標準化できます。
- 入力ソースと最終出力の粒度を定義する
- 結合、投影、集計、固定的な計算列に分解する
- 図で表現したときに処理の意図が明確か確認する
- 条件分岐、中間結果、再利用ロジックの量を確認する
- グラフィカル計算ビューを最初の候補として作成する
- コードのほうが読みやすく、テストしやすい部分をSQLScriptへ分離する
- 同じデータと条件で結果と性能を比較する
- 権限、デプロイ、監視、障害対応の手順を文書化する
単純なモデルをグラフィカル計算ビューで始め、複雑なロジックだけをSQLScriptへ分ける構成は、可視性と表現力のバランスを取りやすい方法です。反対に、最初から複雑なコードへまとめると、SQLの再利用性が高まる一方で、業務担当者が処理の全体像を確認しにくくなる場合があります。
まとめ
グラフィカル計算ビューは、結合、投影、集計、固定的な計算を視覚的に管理し、データの流れを共有する場面に適しています。SQLScript計算ビューは、条件分岐、段階的な加工、集合演算、再利用ロジックをコードとして明示する場面に適しています。
選択時は、処理の表現力だけでなく、出力粒度、テスト方法、性能確認、権限、デプロイ、障害対応まで含めて評価します。方式を決めた後も、実データに近い条件で結果と実行計画を確認し、モデルの保守性を定期的に見直すことが重要です。