SAP BW/4HANAのADSOを設計・作成する実務ガイド：種類の選び方と旧DSOとの違い

SAP BW/4HANAでデータモデルを設計するとき、Advanced DataStore Object（ADSO）はデータの受け入れ、統合、履歴保持、レポーティング向けの提供を担う中心的なオブジェクトです。用途に合わないタイプを選ぶと、後から変換、削除、更新、性能の設計をやり直すことになります。最初にデータの粒度と更新方式を整理し、データのライフサイクルに合わせてADSOを選択します。

01ADSOとは

ADSOは、データを格納し、変換やデータ転送プロセスから後続の分析モデルへ渡すためのBW/4HANAのデータストアです。データソースから直接ロードするステージング領域、複数ソースを統合する中間層、分析用に整えたデータを保持するレイヤーなど、同じADSOでも配置する場所によって役割が変わります。

設計時は、次の項目を先に決めます。

• 1レコードが表す業務上の粒度
• キーとして重複を判定する項目
• 新規レコードを追加するのか、既存レコードを更新するのか
• 変更履歴やデルタを保持する期間
• 下流のCompositeProviderやクエリが参照する状態
• データを削除する単位と運用担当者

ADSOのキーは、技術的に一意であればよいとは限りません。たとえば受注明細を日次で保持する場合、伝票番号だけでは日付別の状態を区別できないことがあります。業務上の粒度、デルタの到着単位、再送時の振る舞いを合わせてキーを定義します。

関連する特性やキー数値を共通化する場合は、SAP BW/4HANA InfoObjectの設計も確認し、ADSOとInfoObjectの責任範囲を分けて設計します。

02ADSOの主な種類

ADSOのタイプは、ロードしたデータをどのように保持し、後続処理へ渡すかで選びます。名称だけで決めず、更新と照会の両方を想定することが重要です。

BW/4HANAでADSOのType(タイプ)プロパティとして選択できるのは、標準型（Standard）、書き込み最適化型（Write-Optimized）、およびNavigation Attributeとして全特性を保持するタイプの3種類です。以下の「データマート型」「リアルタイム対応型」は、これらのTypeプロパティの選択肢そのものではなく、標準型などを組み合わせた設計上の使い方（利用パターン）を指す呼び方である点に注意してください。

標準型のADSO

標準型は、入ってきたデータを有効化し、データの整合性を保ちながら後続処理へ提供する用途に向きます。キーによる更新や有効化後の参照を使うモデルでは、まず標準型を候補にします。マスターデータとトランザクションデータを統合する中間層にも適しています。

ロードを完了しただけで下流から期待どおりに見えるとは限りません。データ転送プロセスの実行後に有効化や後続のデータフローを実行する設計では、処理順序を運用ジョブに組み込みます。

書き込み最適化型のADSO

書き込み最適化型は、受信データを高速に蓄積するステージング用途に向きます。複雑な更新処理をその場で行わず、次の変換処理で整形して別のADSOへ渡す構成にします。

大量データの初回ロードや、ソースから届いたデータを一時的に受ける層で使いやすい一方、直接の分析参照先として設計すると、集約、重複排除、履歴管理の責任が曖昧になります。ステージング後にどのオブジェクトへ移すかをデータフロー図に記載してください。

データマート型のADSO

データマート型は、分析やレポーティングのために整形したデータを提供する用途で検討します。複数の中間層から必要な項目を集約し、下流のCompositeProviderやクエリが読みやすい形に整えます。

参照性能を重視する場合でも、元データの取り込みと分析用の提供を一つのADSOに詰め込まないことが大切です。更新頻度、集約方法、削除方式が異なる場合は、レイヤーを分けることで障害時の切り分けが容易になります。

リアルタイム対応型のADSO

リアルタイムに近い更新を扱う構成では、データの到着頻度、同時実行数、下流参照の負荷を確認します。オンライン更新とバッチ更新を同じ領域で混在させる場合は、ロックや有効化のタイミングが業務処理に影響しないかを検証します。

このタイプを選ぶ前に、業務要件が本当に即時性を必要としているか確認します。数分単位の遅延で許容される場合、安定したバッチ処理の方が監視や再処理を単純化できることがあります。

03ADSOを作成する手順

1. 要件とデータ粒度を定義する

まず、ソース項目、キー項目、更新単位、保持期間、削除条件を一覧化します。項目名だけでなく、日付の意味、通貨や単位、空値の扱いも確認します。

次に、ADSOの前後にあるオブジェクトを決めます。典型的な流れは、データソース、変換、データ転送プロセス、ステージングADSO、統合ADSO、CompositeProvider、クエリです。すべての層を必須にするのではなく、各層に明確な責任を持たせます。

2. ADSOのタイプを選択する

受信データをそのまま蓄積するのか、キー更新を行うのか、分析向けの読み取りを優先するのかを基準にタイプを決めます。タイプを選んだ理由を設計書に残しておくと、将来の項目追加やロード方式変更で判断しやすくなります。

3. 項目とキーを定義する

ADSOに必要な項目を追加し、キーを設定します。キーには、同じ業務レコードを再送したときに同一レコードとして扱える項目を含めます。リクエスト番号やロード日時をキーへ追加すると、再送データが別レコードになる場合があるため、業務要件に基づいて判断します。

特性をInfoObjectとして管理する場合は、マスターデータ、テキスト、階層、属性変更の影響を確認します。単純な技術項目として保持する項目と、分析モデル全体で意味を共有する項目を区別します。

4. データフローを接続する

作成したADSOを変換とデータ転送プロセスへ接続し、ソースから対象ADSOまでの経路を確認します。変換では、型変換、通貨換算、項目マッピング、ルックアップ、エラー処理を定義します。

ステージングADSOから統合ADSOへ渡す場合、デルタの取得条件と削除レコードの扱いを明確にします。フルロードだけでテストすると、実運用で発生する変更レコードや削除レコードを見落とします。

5. 開発・テスト・本番の移送を確認する

開発環境でオブジェクトを作成したら、少量の正常データ、重複データ、必須項目欠落データ、更新データ、削除データを使って検証します。テスト結果には、入力件数、処理件数、エラー件数、ADSO内の件数、下流クエリの結果を記録します。

移送前には、依存するInfoObject、変換、データ転送プロセス、CompositeProviderの順序を確認します。移送後に有効化できない場合は、対象オブジェクトだけでなく参照先の依存関係も確認してください。

04旧DSOとの違い

旧来のDSOでは、アクティブテーブル、変更ログ、アクティベーション処理などを意識した設計が必要でした。ADSOでは、これらの機能が用途別のテンプレートやプロパティに整理され、データフロー上の役割を選択しやすくなっています。

ただし、旧DSOをADSOへ置き換えるだけで同じ動作になるとは限りません。次の項目を移行前に確認します。

• キーの定義と重複レコードの扱い
• 有効化が必要なタイミング
• 変更ログやデルタの提供方法
• データ削除と再ロードの単位
• 下流の変換やクエリが参照する状態
• 管理対象のリクエストとパーティション

旧環境から移行する場合は、既存のデータフローを図に起こしてから、ADSOのタイプを割り当てます。移行手順や互換性の確認では、SAP BW/4HANA変換アプローチを関連資料として参照できます。

05ロード失敗を切り分ける

件数が期待値と合わない場合

最初に、ソースの抽出件数、変換の入力件数、エラー件数、ADSOの有効化後件数を分けて確認します。入力件数とADSO件数が一致しない理由には、キー更新、重複排除、削除レコード、エラー除外があります。

同じデータを再実行したときに件数が増える場合は、キー設計とデルタ条件を確認します。ロード日時やリクエストIDを業務キーに含めていると、再送が新規データとして蓄積されることがあります。

有効化や後続処理が止まる場合

処理チェーンの実行順序、前段のリクエスト状態、変換のエラー、ロック状態を確認します。ステージングから統合層へ渡す処理では、対象期間やデルタの選択条件が想定どおりかを確認してください。

エラーを修正した後は、失敗したリクエストをそのまま繰り返すのか、対象データを再抽出するのかを決めます。部分的に反映されたデータがある場合、再実行前に重複や二重計上の有無を確認します。

性能が低下した場合

ロード時間、変換時間、有効化時間、下流クエリの応答時間を分けて測定します。データ量だけでなく、キー数、同時実行、頻繁な小口ロード、不要な項目、複雑なルックアップも確認対象です。

大量データを小さな単位で頻繁に処理すると、管理 overhead や後続処理の回数が増えることがあります。処理単位を見直し、不要な変換を前段または後段へ移し、監視対象を明確にします。関連する運用確認には、SAP BW/4HANAのパフォーマンスチューニングも役立ちます。

06運用設計のチェックポイント

ADSOを本番運用へ移す前に、次の内容を決めます。

• 正常終了と異常終了を判定する監視項目
• エラー時の通知先と再処理担当者
• フルロードとデルタロードの実行条件
• 保持期間と古いデータの削除方法
• リクエストやデータパッケージの追跡方法
• 下流レポートへの影響確認
• 障害時に戻す基準と再ロードの範囲

特に、再処理の手順は成功ケースとは別に作成します。変換だけを再実行するのか、ソース抽出からやり直すのか、ADSOの対象期間を削除してからロードするのかを明文化します。

07まとめ

ADSOの設計では、名称やテンプレートよりも、データの粒度、更新方式、履歴要件、下流の利用方法を先に整理します。ステージング、統合、分析提供の役割を分け、各ADSOの責任を明確にすると、ロード失敗や件数差異を切り分けやすくなります。

作成後はフルロードだけでなく、更新、削除、再送、エラー再処理を検証します。旧DSOから移行する場合も、オブジェクトを置き換えるだけでなく、キー、デルタ、変更ログ、後続処理の挙動を一つずつ確認することが安定運用につながります。