SAP BW/4HANA
SAP BW/4HANAのInfoArea設計：情報モデルを整理する実践ガイド
SAP BW/4HANAでInfoArea、InfoObject、ADSO、CompositeProviderをどのように整理するかを、データフローと運用の観点から解説します。
InfoArea設計の目的
SAP BW/4HANAのInfoAreaは、オブジェクトを業務領域やデータウェアハウスの層に沿って整理するための論理的な構造です。単なるフォルダとして作るのではなく、データの所有範囲、再利用単位、ライフサイクル、権限管理を考慮して設計すると、開発後の検索や変更の影響調査が容易になります。
InfoAreaの設計では、最初にレポート名を並べるのではなく、データの流れを定義します。取得元からステージング、統合、提供までの役割を分け、その役割に対応するInfoObject、Advanced DataStore Object（ADSO）、CompositeProviderなどを配置します。
既存環境の全体像を確認する場合は、SAP BW/4HANAの概要からシステム構成と主要オブジェクトの関係を先に把握できます。
InfoAreaの階層を決める
InfoAreaの最上位は、組織名だけでなく、データウェアハウスの責務を表す単位にすると運用しやすくなります。たとえば、取得、統合、マスターデータ、基盤、提供といった大分類を設け、その下に販売、購買、在庫、財務などの業務領域を配置します。
代表的な構成例は次のとおりです。
ZBW_ACQ：取得・受信に関するオブジェクトZBW_STG：受信データを保持するステージング領域ZBW_CORE：標準化・統合済みデータZBW_MDM：共通マスターや参照データZBW_CONS：分析用途に提供するセマンティック層ZBW_TECH：技術用の補助オブジェクト
この分け方では、取得側の変更と分析側の変更を分離できます。業務領域を表す階層と、データ処理の層を混在させる場合は、命名規則で役割を補う必要があります。大規模環境では、処理層を最上位に置き、その下に業務領域を置く構造が変更範囲を把握しやすくなります。
InfoAreaの配下には、関連するInfoObject、ADSO、CompositeProvider、変換、データ転送プロセスなどをまとめます。ただし、実行順序そのものをInfoAreaの並び順で表現せず、データフローとプロセスチェーンで明示します。
InfoObjectの共通定義
InfoObjectは、顧客、会社コード、品目、通貨、数量、日付などの意味と技術属性を共通化する基盤です。同じ業務概念を複数のADSOで使用する場合、共通のInfoObjectを利用すると、データ型、マスターデータ、テキスト、階層、権限関連の扱いを統一できます。
InfoObjectを作る前に、次の観点を確認します。
- 業務上の意味が既存のInfoObjectと一致していないか
- キーとして扱うか、属性やメジャーとして扱うか
- 大文字・小文字、前ゼロ、単位、通貨の扱いをどうするか
- 有効期間やテキスト言語を管理する必要があるか
- 複数のデータフローで再利用する値か
再利用する意味をInfoObjectに集約し、単一のデータフローだけで意味を持つ項目はADSO側のフィールドとして保持する、という境界が実務上の判断基準になります。過剰に共通化すると変更の影響範囲が広がり、個別項目を増やし過ぎるとモデル全体の意味が分散します。
InfoObjectの属性設計を確認したい場合は、SAP BW/4HANAのInfoObject設計を参照してください。
ADSOをデータ保持層に配置する
ADSOは、データを保持し、更新や統合の単位を定義する中心的なオブジェクトです。InfoAreaでは、ADSOの名前だけでなく、保持するデータの粒度と利用目的が分かるように配置します。
用途ごとの考え方は次のとおりです。
- 取得用ADSO：受信したデータを確認可能な状態で保持する
- ステージング用ADSO：変換前後の検証や再処理に利用する
- 統合用ADSO：複数ソースを共通の粒度とキーに整える
- 集約用ADSO：定型的な集計や提供単位に合わせて保持する
- 履歴用ADSO：監査や期間比較に必要な履歴を保持する
ADSOの粒度を決めるときは、1レコードが何を表すかを文章で定義します。たとえば「受注明細と日付の組み合わせ」や「品目・プラント・評価期間の組み合わせ」のように、キーと非キー項目の関係を明確にします。粒度が曖昧なまま複数の用途を1つのADSOに集約すると、重複、上書き、デルタ処理、再処理の判断が難しくなります。
ADSOの技術的な役割やデータフローへの組み込み方は、SAP BW/4HANA Advanced DataStore Objectの使い方で整理できます。
CompositeProviderを提供層に置く
CompositeProviderは、複数のプロバイダーを結合またはユニオンし、分析用途に意味のあるデータセットを提供する層です。通常は、取得用ADSOを直接レポートに接続せず、統合済みのADSOや参照オブジェクトをCompositeProviderで組み合わせます。
設計時には、結合条件、共通項目、粒度、欠損値、重複レコードを明示します。結合する双方の粒度が異なる場合、結果のレコード数が増える可能性があるため、キーの対応と集計動作を検証します。ユニオンを使う場合は、各プロバイダーの項目対応、データ型、単位、通貨、期間項目をそろえます。
CompositeProviderを提供層に置くと、バックエンドの保持構造と利用者向けの分析構造を分離できます。データ取得の変更があっても、提供層の項目契約を維持できれば、下流の利用箇所への影響を抑えられます。
結合とユニオンの設計例は、SAP BW/4HANA CompositeProviderの設計で確認できます。
変換とデータフローを分離する
InfoAreaの階層は、変換ロジックの責任範囲も示す必要があります。取得層では形式変換や基本的なコード整形に集中し、統合層で業務ルール、キー変換、参照、重複処理を行い、提供層では分析向けの計算や表示用の整形を扱う構成が管理しやすくなります。
変換を設計するときは、次の情報を併記します。
- 入力オブジェクトと出力オブジェクト
- 入力と出力の項目マッピング
- 固定値、参照、計算、単位変換の処理
- エラー行の扱いと再処理方法
- 初期ロードとデルタロードで異なる処理
- 変更時に再ロードが必要な範囲
同じロジックを複数のデータフローで使う場合は、共通化の効果と依存関係を比較します。共通化によって整合性を保てる一方、1つの変更が複数の業務領域へ波及することがあります。データフローの依存関係を文書化し、テストデータと期待結果をオブジェクト単位で保存します。
変換のマッピング、ルーチン、エラー処理を詳しく確認するには、SAP BW/4HANAの変換設計が役立ちます。
命名規則と責任範囲を定義する
命名規則は、InfoAreaの階層と同じく、オブジェクトの役割を短い名前で伝えるために使います。名前には、層、業務領域、データ種別、粒度、用途などの要素を含めます。例として、ZADSO_STG_SD_ORDERのように、カスタムオブジェクト、層、業務領域、対象を分けて表現できます。
命名規則を決める際は、次の項目を文書にします。
- カスタム名前空間の扱い
- InfoArea、ADSO、CompositeProvider、変換の接頭辞
- 略語と業務用語の対応表
- 開発、テスト、本番で共通にする部分
- 廃止、置換、保留を示す状態の扱い
名前だけで全てを説明しようとせず、オブジェクト説明、データフロー図、担当チーム、保持期間も管理します。特に、同じ業務領域に複数の粒度が存在する場合は、説明欄に粒度を明記すると調査が速くなります。
権限とライフサイクルを組み込む
InfoAreaを作成した段階で、誰が参照、変更、移送、削除できるかを決めます。開発者が自由に全領域を変更できる構造ではなく、業務領域、データ層、運用担当の責任範囲を権限設計に反映します。
ライフサイクルでは、少なくとも次の状態を管理します。
- 設計中：粒度、項目、データ所有者を確定する
- 開発中：サンプルデータで変換とエラー処理を検証する
- テスト中：件数、キー、合計値、デルタ動作を確認する
- 運用中：監視、再処理、保持期間、変更手順を適用する
- 廃止準備：依存オブジェクトと利用状況を調査する
本番で使われているオブジェクトを直接変更する場合は、下流のCompositeProvider、クエリ、プロセスチェーン、権限への影響を確認します。変更前後のレコード件数や主要メジャーを比較できる検証手順を用意しておくと、移送後の確認が安定します。
設計レビューの進め方
設計レビューでは、オブジェクト一覧よりもデータフローを中心に確認します。取得元から提供層までを一つの図にし、各ステップについて、入力粒度、出力粒度、キー、エラー処理、再処理方法、責任者を確認します。
レビュー用のチェックリストは次のとおりです。
- InfoAreaの階層がデータの責務と一致している
- 同じ意味の項目が不要に複数定義されていない
- ADSOごとのレコード粒度と更新方式が明確である
- CompositeProviderの結合で重複が発生しない
- 変換ロジックの配置層が適切である
- 初期ロード、デルタロード、再処理の手順がある
- エラー行を特定し、修正後に再実行できる
- 命名、説明、担当者、保持期間が登録されている
- 変更が権限、プロセスチェーン、下流の提供層に与える影響を確認している
性能面では、データ量、結合条件、パーティション、頻繁なロード時間、同時実行の有無を早期に確認します。モデルを細かく分割することだけで性能が改善するとは限らないため、実データに近い量で測定します。
実装後の運用
運用開始後は、ロード件数、エラー件数、処理時間、未処理データ、データの鮮度を継続的に確認します。監視項目はInfoAreaの階層と対応させ、どのデータ層で問題が発生したかを特定できるようにします。
障害時は、まず最後に正常終了した処理、対象期間、対象パーティション、入力件数、出力件数を確認します。その後、入力データ、変換、ADSOの更新、CompositeProviderの結果を順に切り分けます。再処理では、重複登録や二重集計を避けるため、対象キーとロード範囲を限定します。
InfoAreaは一度作って終わる分類ではなく、データの責任範囲と変更履歴を維持する運用基盤です。新しい業務領域を追加する際も、既存の層、共通InfoObject、ADSOの粒度、提供層との関係を確認してから配置します。