SAP HANA
SAP HANA Calculation View基礎：設計・作成・性能確認の実務手順
SAP HANAのCalculation View（カリキュレーションビュー）について、種類の選び方、作成手順、ノード設計、権限、デプロイ、性能問題の切り分けまで実務向けに解説します。
SAP HANAのCalculation Viewは、テーブルや他のビューを組み合わせて、分析やアプリケーションから利用しやすいデータモデルを作るためのオブジェクトです。単にテーブルを結合するだけでなく、集計、フィルタ、計算列、入力パラメータ、階層などをモデルに組み込めます。
実務では、最初に業務上の出力粒度を決め、次にデータソースと結合条件を整理します。その後、必要なノードだけでモデルを構成し、少量のデータで結果を確認してからデプロイします。設計の中心は、出力粒度の明確化です。
Calculation Viewの役割
Calculation Viewは、分析用のデータセットを再利用可能な形で公開するデータモデルです。たとえば、受注明細と製品マスタを結合し、製品別・月別の売上を集計するモデルを作成できます。
Calculation Viewの出力には、分析に使う属性と、集計対象となるメジャーを定義します。数量や金額のようなメジャーには集計方法を設定し、伝票番号や製品コードのような属性には適切な粒度を設定します。
モデルの利用者がSQL、BIツール、アプリケーションのいずれであっても、データを取得する入口を統一できます。開発全体の位置付けを確認する場合は、SAP HANA開発の全体像も参照してください。
Calculation Viewの種類
Calculation Viewは、用途と設計方法に応じて選択します。現場では、既存のデータソースをグラフィカルに組み合わせるモデルと、SQLScriptを使って処理を記述するモデルを使い分けます。
グラフィカルなCalculation Viewは、Projection、Join、Union、Aggregationなどのノードを配置して処理を組み立てます。結合や集計の構造が視覚的に確認でき、保守時にデータの流れを追いやすい点が特徴です。
SQLScriptベースのCalculation Viewは、複雑な条件分岐、複数段階の変換、テーブル関数を含む処理に適しています。SQLScriptを使う場合は、処理の再利用単位と入力・出力の型を先に定義します。選択基準は、グラフィカルとSQLのCalculation Viewの違いで整理できます。
作成前の設計
作成画面を開く前に、次の項目を設計書またはチケットにまとめます。
- 利用者が必要とする出力項目
- 出力行の粒度
- データソースと主キーまたは結合キー
- 必須フィルタと任意フィルタ
- 集計するメジャーと集計方法
- 入力パラメータの用途と初期値
- 想定データ量と利用頻度
出力粒度を決めずに複数テーブルを結合すると、明細の重複やメジャーの過大集計が起きます。特にヘッダと明細、マスタと履歴を結合する場合は、結合後の1行が何を表すのかを明文化します。
既存のCalculation Viewを拡張する場合は、利用中の列、フィルタ、権限設定、呼び出し元を確認します。公開済みの列名を変更すると、BIレポートやアプリケーション側の修正が必要になります。
グラフィカルCalculation Viewの作り方
SAP HANA開発環境でCalculation Viewを作成したら、次の順序でモデルを構成します。
- データソースを追加し、必要な列だけをProjectionで選択します。
- データ型、列名、説明、非表示にする列を整理します。
- 結合が必要な場合はJoinを追加し、結合条件と結合種別を設定します。
- 複数のデータソースを縦に統合する場合はUnionを使います。
- 集計が必要な場合はAggregationを追加し、属性とメジャーを定義します。
- 最終ノードで外部に公開する列だけを出力します。
- データプレビューで件数、NULL、重複、集計結果を確認します。
Projectionでは、後続ノードで使わない列を早い段階で除外します。不要な列をモデルの最後まで持ち回ると、読み取り量と中間結果が増えます。
Joinでは、結合キーのデータ型と値の形式をそろえます。NULLの扱い、片側にだけ存在する行の扱い、1対多結合による行数増加を確認してから、集計ノードへ進めます。
Aggregationでは、メジャーの集計方法を業務要件と一致させます。平均値、件数、合計は同じ結果にならないため、元データの粒度と利用者が求める指標を照合します。
入力パラメータとフィルタ
入力パラメータは、実行時に値を受け取り、対象期間や組織などを絞り込むために使います。パラメータ名、データ型、必須 여부、初期値、適用先を定義し、利用者が入力する値の形式を決めておきます。
固定条件として常に適用するものは、モデル内のフィルタとして実装します。利用者が変更する条件は入力パラメータにし、どのノードで適用するかを明確にします。
期間条件を上流のProjectionで適用できる場合は、読み込むデータ量を抑えられます。ただし、結合後の列や集計結果に対する条件を上流へ移すと意味が変わるため、フィルタの適用位置と結果をデータプレビューで確認します。
デプロイと権限確認
モデルの保存後は、依存するデータソース、関連オブジェクト、デプロイ対象を確認します。デプロイ前に開発用データで結果を比較し、主要な業務ケースと境界値を検証します。
デプロイ後は、SAP HANA database explorerでオブジェクトの存在、列、サンプル結果を確認できます。SAP HANA cockpitでは、データベースの状態やリソース状況を確認し、実行時間の変化と合わせて監視します。
利用者がCalculation Viewを実行するには、対象オブジェクトを読み取る権限と、参照する基礎オブジェクトへの必要な権限が関係します。権限設計では、開発者、運用担当者、レポート利用者の役割を分け、不要な広範囲権限を付与しない構成にします。関連する確認手順は、SAP HANAのユーザー権限管理で確認できます。
性能問題の切り分け
Calculation Viewが遅い場合は、まず実行時間、読み取りデータ量、結合後の行数、集計前後の件数を分けて確認します。最終結果だけを見ていると、どのノードでデータが増えたかを特定できません。
次の順で切り分けると、原因を絞り込みやすくなります。
- 同じ入力条件で再実行し、再現性を確認します。
- 各ノードのデータプレビューで行数とNULLを確認します。
- Projectionの列数とフィルタ位置を確認します。
- Joinの結合条件と結合後の行数を確認します。
- Aggregation前のデータ量とメジャーの集計方法を確認します。
- SAP HANA cockpitとSAP HANA database explorerで、実行時間やリソース使用状況を確認します。
大量の更新後に列ストアの読み取り性能が変化した場合は、デルタ領域の状態も確認します。運用上のマージ判断は、SAP HANAのデルタマージの考え方と、対象システムの負荷・運用時間帯を合わせて行います。
よくある設計上の問題
メジャーの二重計上は、1対多のJoin後に元の金額を合計すると発生します。結合前後の粒度を確認し、必要に応じて先に集計してから結合します。
不要な列の持ち回りは、中間結果と転送量を増やします。最終出力に必要な列を基準に、各Projectionで列を絞り込みます。
フィルタの意味の変化は、Joinの前後で条件を移動したときに起きます。外部結合の結果やNULLの扱いを確認し、条件を移動するたびに代表データで結果を比較します。
権限不足による実行失敗は、Calculation View自体だけでなく依存オブジェクトの参照権限も確認します。実行ユーザー、接続先データベース、対象オブジェクトを一つずつ記録すると、調査の再現性を保てます。
運用チェックリスト
リリース前には、出力粒度、結合条件、メジャーの集計、入力パラメータ、NULLの扱い、権限、代表データでの結果を確認します。変更前後で件数と主要指標を比較し、既存レポートへの影響を記録します。
リリース後は、利用頻度の高い条件で実行時間を測定し、エラー、タイムアウト、リソース使用率を監視します。モデル変更時には、依存するレポートやアプリケーションのテスト結果も合わせて保存します。
Calculation Viewは、ノードを増やすほど柔軟になる一方、処理の流れと粒度が複雑になります。まず小さく正しいモデルを作り、必要性が確認できた処理だけを追加することが、長期運用しやすい設計につながります。