SAP HANA開発の概要：ネイティブ開発の進め方と実務ツール

SAP HANAの開発では、データをデータベース内で処理する設計と、アプリケーション側で処理する設計を分けて考えます。SQLによるデータアクセス、SQLScriptによる複雑な処理、計算ビューによるセマンティックなデータモデル、CDSやHDIコンテナを使ったアプリケーション開発が主要な構成要素です。

開発作業は、要件の整理、データモデルの設計、オブジェクトの実装、権限設定、テスト、性能確認、デプロイという流れで進めます。開発用のSAP HANAシステムでは、SAP HANAデータベースエクスプローラーでSQLやデータベースオブジェクトを確認し、SAP HANA cockpitでシステム状態、メモリ、アラート、トレースを確認します。

01SAP HANA開発の全体像

SAP HANA開発の中心は、業務データをどのような粒度で公開し、どの処理をデータベース内で実行するかを決めることです。単純な参照はSQLで実装し、再利用するデータモデルは計算ビューやCDSで構造化します。複数のSQL処理、条件分岐、ループ、例外処理をまとめる場合はSQLScriptプロシージャを検討します。

ネイティブ開発では、アプリケーションから直接テーブルを参照する構成よりも、用途に合わせた公開モデルを用意する構成が扱いやすくなります。公開モデルに項目の意味、結合条件、集計単位を集約すると、アプリケーションごとの重複ロジックを減らせます。

設計時には、次の観点を最初に決めます。

• 業務上の事実を保持するテーブルと、説明用のマスターデータを分ける
• 明細、日次集計、現在状態など、データの粒度を明確にする
• 時間項目、通貨、数量、単位などの意味をデータモデルに反映する
• NULL、重複、削除済みデータ、履歴データの扱いを決める
• 読み取り処理と書き込み処理の責任範囲を分ける

既存のモデルを読み解くときは、まず計算ビューの入力、結合、フィルター、集計、出力項目を確認します。グラフィカルなモデルの構造を確認したうえで、SQLによる計算ビューが適する処理かどうかを判断すると、実装方式を選びやすくなります。関連する設計判断は、SAP HANA計算ビューの概要とSAP HANAのグラフィカル計算ビューとSQL計算ビューの違いでも整理しています。

02開発で使う主要なツール

SAP HANAデータベースエクスプローラーは、SQLの実行、スキーマやテーブルの確認、ビューやプロシージャの検証に使います。小さなSQLを実行して結果を確認し、実行計画やエラーの内容を見ながら処理を段階的に組み立てる運用が基本です。

SAP HANA cockpitは、開発環境を含むSAP HANAシステムの運用状態を確認するために使います。CPU、メモリ、ディスク、サービス状態、アラート、トレースを確認できるため、開発オブジェクトの問題とシステムリソースの問題を切り分ける際に役立ちます。開発環境の接続情報やユーザー権限を変更した場合も、cockpitとデータベースエクスプローラーの双方で接続状態を確認します。

SQLScriptを実装するときは、処理を小さな単位に分け、入力、変換、出力を明確にします。プロシージャの設計やデバッグ手順は、SAP HANA SQLScriptプロシージャの実装方法を参照できます。

03SQLとSQLScriptの使い分け

SQLは、検索、結合、集計、挿入、更新など、宣言的に表現できる処理に適しています。読み取り専用のデータアクセスでは、必要な列だけを選び、不要な行を早い段階で絞り込みます。アプリケーションから発行するSQLは、入力値をパラメータ化し、文字列連結によるSQLインジェクションを避けます。

SQLScriptは、複数のSQL文をまとめる処理、変数を使った中間結果の管理、条件による処理分岐、再利用するデータベースロジックに適しています。ただし、すべての処理をSQLScriptに移すのではなく、単純な検索はSQL、再利用可能な意味モデルはビュー、手続き的な処理はプロシージャというように責務を分けます。

性能を確認するときは、次の順序で調べます。

1. 返却行数と入力データの粒度を確認する
2. 不要な列と不要な結合を削除する
3. フィルターが適切な位置で適用されているか確認する
4. 集計前にデータが過剰に増えていないか確認する
5. 実行計画と実行時間を比較する
6. 必要に応じてSAP HANA cockpitのメモリやアラートを確認する

実行時間が長い場合、SQLScriptの文法だけを調べるのではなく、データ量、結合キー、集計単位、同時実行数を確認します。開発用データでは再現しない問題があるため、検証用データの量と分布を本番相当に近づけることも重要です。

04計算ビューとデータモデルの設計

計算ビューは、複数のテーブルやビューを組み合わせ、分析やアプリケーションが利用する意味のあるデータセットを提供します。モデルを作る前に、ファクトに相当する明細と、属性や説明を提供するディメンションを整理します。

集計を含むモデルでは、キー項目、メジャー、属性を明確に分けます。数量や金額を集計する場合は、単位や通貨の扱いを決め、異なる単位を単純に合算しないようにします。JOINによって明細が重複すると、金額や数量が過大計上されるため、結合後の行数と代表的な集計値をテストします。

入力パラメータや変数を使う場合は、既定値、許容値、NULLの扱いを定義します。利用者が指定した値が、どのノードでフィルターとして適用されるかも確認します。計算ビューを変更した後は、依存するビュー、プロシージャ、アプリケーションのテストを実施します。

05CDSとHDIコンテナの位置付け

CDSは、データ構造と業務上の意味を定義するためのモデル記述として使われます。エンティティ、項目、関連、注釈などを整理し、アプリケーションが利用しやすい形でデータを公開します。CDSを採用する場合は、モデル定義、生成されるデータベースオブジェクト、デプロイ順序を確認します。

HDIコンテナは、アプリケーションに関連するデータベースオブジェクトを分離して管理するための実行環境です。テーブル、ビュー、プロシージャ、ロールなどをアプリケーション単位で管理し、開発、テスト、本番へのデプロイを再現しやすくします。

HDIコンテナを使うプロジェクトでは、次の情報をリポジトリで管理します。

• データベースオブジェクトの定義
• デプロイ対象と依存関係
• コンテナ間の参照関係
• アプリケーションからのサービス接続
• ロールと権限の定義
• 初期データやテストデータの投入方法

開発者個人の環境だけで作成したオブジェクトを手動で移送すると、再現性が失われます。変更を小さく分け、デプロイログとテスト結果を変更単位で残します。

06権限と接続の確認

開発用ユーザーには、作業対象のスキーマやコンテナに必要な権限だけを付与します。設計時には、開発者が実行する権限、アプリケーション実行ユーザーの権限、デプロイ用ユーザーの権限を分離します。

接続できない場合は、データベースエクスプローラーの接続情報、対象データベース、ユーザーの状態、パスワードの有効性、ネットワーク経路を順番に確認します。接続できてもオブジェクトが見えない場合は、現在のユーザー、スキーマ、オブジェクト権限を確認します。

SQL実行時に権限エラーが出る場合は、エラー対象のオブジェクトと実行者を特定し、必要な権限を最小単位で追加します。開発用の管理ユーザーをアプリケーション接続に使わず、用途別のユーザーとロールを用意します。

07デプロイとテストの実務フロー

デプロイ前に、変更対象、依存オブジェクト、データ移行の有無、ロール変更の有無を一覧化します。テーブル構造を変更する場合は、既存データ、アプリケーションの互換性、ロールバック手順を確認します。

基本的な検証では、次のテストを分けて実施します。

• オブジェクトが正常に作成または更新されるか
• 代表的な入力値で期待する行数と値が返るか
• NULL、空文字、境界値、重複データを処理できるか
• 権限のあるユーザーとないユーザーの動作が適切か
• 想定データ量で実行時間とメモリ使用量が許容範囲か
• 既存の依存オブジェクトに影響がないか

SAP HANA cockpitでは、デプロイの前後にシステムアラートとサービス状態を確認します。SAP HANAデータベースエクスプローラーでは、オブジェクトの存在、定義、データ、SQLエラーを確認します。問題がアプリケーション、データベースオブジェクト、接続設定、システムリソースのどこにあるかを切り分けてから修正します。

08開発時のトラブルシューティング

SQLが失敗するときは、まず接続先データベースとスキーマを確認し、次にオブジェクト名、列名、データ型、権限を確認します。複雑なSQLは、FROM句、結合、フィルター、集計、出力列の順に簡略化して、どの段階で結果が変わるかを調べます。

結果が想定より多い場合は、結合キーの一意性、1対多の結合、フィルターの適用位置を確認します。結果が少ない場合は、INNER JOIN、NULL値、暗黙のデータ型変換、期間条件を確認します。

メモリ使用量が増える場合は、取得列、結合前の行数、中間結果、同時実行数を調べます。SAP HANA cockpitでメモリの推移とアラートを確認し、必要に応じてデータベースエクスプローラーで処理を分割して再実行します。大きな結果セットをクライアントへ返さず、必要な集計をデータベース側で行う設計も検討します。

デプロイが失敗した場合は、最初に失敗したオブジェクトのログを確認します。依存オブジェクトの作成順序、権限、既存オブジェクトとの名前衝突、無効な参照、ロール定義を確認し、原因を一つずつ解消します。修正後は、失敗したステップだけでなく依存するテストも再実行します。

09実務で使える開発チェックリスト

開発開始時には、次の項目を確認します。

• 要件、データ粒度、利用者、更新頻度が定義されている
• テーブル、ビュー、プロシージャ、CDSの責務が整理されている
• 開発用ユーザーとアプリケーション用ユーザーが分離されている
• テストデータと期待結果が用意されている
• デプロイ順序とロールバック手順が決まっている

実装完了時には、結果の正確性だけでなく、性能、権限、監視、障害時の調査方法も確認します。データモデルの変更履歴、SQLScriptの入力と出力、テスト結果、デプロイログを残すと、後続の保守と障害調査が容易になります。

SAP HANA開発は、SQLの記述だけで完了する作業ではありません。データモデル、処理ロジック、権限、デプロイ、監視を一つの運用単位として設計し、SAP HANAデータベースエクスプローラーとSAP HANA cockpitを使い分けることが、安定した開発につながります。