SAP
SAP BW/4HANAとは？概要・アーキテクチャ・データフローを実務目線で解説
SAP BW/4HANAとは何かを、SAP BW on HANAとの違い、主要オブジェクト、アーキテクチャ、データフロー、運用設計の観点から整理します。
SAP BW/4HANAとは、SAP HANAのインメモリデータベースを基盤に、データウェアハウスの収集、統合、変換、分析用モデルの提供を行う製品です。単にデータを保存するだけではなく、業務システムから取得したデータを意味のある分析モデルへ整形し、複数のデータソースを横断した集計を実現します。
実務では、製品名だけを理解するよりも、どのオブジェクトがどの役割を持ち、どの順序でデータが流れるかを押さえることが重要です。設計時には、取得元、履歴保持、変換、統合、クエリ提供を分けて考えると、モデルの責任範囲を明確にできます。
SAP BW/4HANAの基本概要
データウェアハウスとしての役割
SAP BW/4HANAは、SAP ERPやSAP S/4HANAなどの業務システム、ファイル、データベース、外部アプリケーションからデータを取り込み、分析しやすい形に統合します。業務システムは登録処理やトランザクション処理を優先しますが、データウェアハウスは時系列分析、部門横断の比較、履歴の蓄積を優先します。
取り込んだデータには、元システムのコード体系、通貨、単位、組織、日付などの意味を付与します。そのうえで、販売、購買、在庫、会計など異なる領域のデータを共通の分析軸にそろえます。この共通化が、レポートごとに個別ロジックを作る構成を減らします。
HANAを基盤にした処理
BW/4HANAはSAP HANA上で動作し、データベース側の処理能力を活用して大量データの読み込みや集計を行います。列ストアを中心としたデータ格納と、プッシュダウンを意識した変換設計によって、アプリケーション層からデータベース層へ処理を寄せられる場面があります。
ただし、HANAを使えばすべての処理が自動的に高速化するわけではありません。不要な項目をモデルに含めないこと、結合条件を明確にすること、データの粒度をそろえること、不要な中間データを増やさないことが、実際の性能に影響します。
BW/4HANAのアーキテクチャ
主要レイヤー
一般的なデータフローは、データ取得、ステージング、変換、永続化、仮想統合、クエリ提供という層に分けて設計します。取得層ではソースシステムからデータを受け取り、ステージング層では再処理や監査に必要な状態を保持します。
変換層では項目変換、コード変換、計算、参照、エラー処理を行います。永続化層では履歴や再利用性を重視したデータを保存し、仮想統合層では複数のデータモデルを組み合わせます。クエリ提供層では、利用者が必要とするディメンション、キー数値、フィルタ条件を定義します。
システムコンポーネントの関係
SAP BW/4HANAの設計では、データベース、BW/4HANAアプリケーション、ソースシステム、データ取得処理、フロントエンドを分けて捉えます。SAP HANAは保存とデータベース処理を担い、BW/4HANAはデータウェアハウスのメタデータ、データフロー、モデル、処理制御を担います。
処理チェーンなどのスケジューリング機能は、データ取得、変換、ロード、後続処理を順序付けます。障害時には、どの層で停止したかを確認し、ソース側の抽出、BW側の要求、変換、ターゲットへの書き込み、後続処理を分けて調査します。
BW/4HANAの主要モデリングオブジェクト
InfoObject
InfoObjectは、特性、キー数値、時間特性、単位、通貨など、分析モデルで再利用する意味を定義するオブジェクトです。会社コード、製品、得意先、会計年度のような分析軸を共通化すると、複数のデータフローで同じ定義を利用できます。
InfoObjectには、技術的なデータ型だけでなく、マスターデータ、テキスト、階層、属性といった分析上の関係も関連します。設計では、値の粒度、履歴の扱い、言語依存のテキスト、未割当値の扱いを先に決めておくと、後続のクエリ設計が安定します。
詳細な属性設計や再利用方針は、BW/4HANAのInfoObject設計ガイドで確認できます。
Advanced DataStore Object
Advanced DataStore Object（ADSO）は、BW/4HANAでデータを保持する中心的なオブジェクトです。入荷データを一時的に保持する用途、変換後の明細を蓄積する用途、デルタを管理する用途など、目的に応じて設計します。
ADSOでは、キー、データ項目、更新処理、削除や上書きの考え方を明確にします。明細粒度のデータを保存するADSOと、集計結果を保存するADSOでは、キー設計と更新方法が異なります。再処理が必要な業務では、元データを追跡できる項目やロード単位を持たせると、障害調査が容易になります。
保存モデルの使い分けは、BW/4HANA Advanced DataStore Objectの設計に整理しています。
CompositeProvider
CompositeProviderは、複数のプロバイダーを統合して分析用の仮想モデルを提供するオブジェクトです。ADSOなどの永続化オブジェクトを組み合わせ、共通する特性やキー数値を分析時に扱えるようにします。
物理的にすべてのデータを一つのテーブルへ集約する代わりに、用途ごとの保存モデルを維持しながら、分析上の統合ビューを作れる点が特徴です。結合とユニオンの意味を明確にし、重複行、粒度の違い、欠損値、キー数値の集計性を確認します。
統合モデルの設計手順は、BW/4HANA CompositeProviderの使い方を参照してください。
BW/4HANAのデータフロー
取得から永続化まで
典型的な流れは、ソースシステムからの抽出、データ転送、ステージング、変換、ADSOへの書き込み、統合モデルへの公開です。各段階で、要求の識別子、ロード時刻、データ件数、エラー件数を追跡できるようにします。
初回ロードとデルタロードでは、確認すべき点が異なります。初回ロードでは全件量、処理時間、重複、対象期間を確認し、デルタロードでは抽出ポインタ、変更データの取りこぼし、再実行時の重複を確認します。
変換とルール設計
変換では、項目マッピング、ルーチン、参照、単位変換、通貨換算、エラー処理を構成します。変換ロジックは、業務ルールと技術的な整形を分離して記述すると、仕様変更の影響範囲を追いやすくなります。
変換前後の件数だけでなく、キー項目の分布、未変換値、NULLや初期値、エラーレコードを確認します。特に、文字列から数値への変換、日付のタイムゾーン、通貨と単位の組み合わせは、ロードが成功しても結果が誤る可能性があるため、代表データで検証します。
変換処理の構成と障害調査は、BW/4HANAのTransformation設計で詳しく扱っています。
BW/4HANAとBW on HANAの違い
BW on HANAは、既存のSAP BWをSAP HANAデータベース上で動かす構成を指します。一方、BW/4HANAはHANAを前提に設計されたデータウェアハウス製品で、データモデル、オブジェクト、運用方式が整理されています。
両者はどちらもHANAの処理性能を活用できますが、採用できるオブジェクトや移行時の設計方針には差があります。既存環境から移行する場合は、利用中のデータフロー、古いオブジェクト、カスタムロジック、外部接続、権限、運用ジョブを棚卸ししてから、移行対象と再設計対象を分けます。
比較の観点を一覧で確認する場合は、BW/4HANAとBW on HANAの違いが役立ちます。
実務での設計と運用チェック
粒度とキーを先に決める
モデルを作成する前に、1レコードが何を表すかを文章で定義します。受注明細、請求明細、日次在庫、月次残高のように粒度を明記し、同じモデル内で異なる粒度を混在させないことが重要です。
キーは重複排除や上書きの単位になります。業務上の一意性と技術上の一意性が異なる場合は、ソースレコード識別子、ロード単位、変更日時などを補助項目として保持します。
データ品質を処理の各段階で確認する
データ品質は最終レポートだけで判断せず、取得直後、変換後、永続化後、統合後に分けて確認します。件数、合計値、未割当、重複、期間、通貨、単位を段階ごとに比較すると、問題が発生した地点を絞り込めます。
エラーを無条件に除外すると、業務上重要な欠損を隠すことがあります。エラーレコードを保存し、原因、対応者、再処理方法、再処理済みの判定を記録する運用を用意します。
性能と保守性を両立する
性能改善では、データ量、選択条件、結合、集計、並列処理、ロード時間を測定してから対策します。モデルを細かく分割しすぎると処理経路が複雑になり、反対に一つへ集約しすぎると再利用性や変更容易性が下がります。
処理チェーンには依存関係と失敗時の通知を設定し、再実行の単位を明確にします。日次、月次、緊急再処理で異なる運用手順を用意し、担当者がログ、要求、データ件数を同じ順序で確認できるようにします。
まとめ
SAP BW/4HANAの全体像は、HANAを基盤にしたデータウェアハウスとして、取得、変換、永続化、統合、分析提供を分担させる構成として捉えると理解しやすくなります。InfoObject、ADSO、CompositeProviderは、それぞれ意味の共通化、データ保持、分析モデル統合を担います。
設計や障害対応では、オブジェクト名を覚えるだけでなく、データの粒度、キー、履歴、変換、再処理、件数確認を一つの流れで管理します。これにより、モデルの拡張とロード障害の切り分けを同じ設計原則で進められます。