SAP BW/4HANA CompositeProviderの基礎と作成・結合・運用手順

SAP BW/4HANAでレポート用のデータモデルを組み立てるとき、複数のADSOやその他のInfoProviderを一つの分析用構造として公開する役割を持つのがCompositeProviderです。データを物理的に複製する格納先ではなく、基礎となるプロバイダーを論理的に組み合わせ、クエリから参照できる形に整理します。

CompositeProviderの設計では、最初に各入力プロバイダーの粒度、キー、期間、通貨、マスターデータ参照を確認します。入力側の粒度が異なるまま結合すると、レコード数の増加やキー figureの重複が発生しやすくなります。したがって、作成画面で接続する前に、データフロー上の役割と集計単位を文書化しておくことが重要です。

01CompositeProviderの役割

論理モデルとしての位置付け

CompositeProviderは、複数のInfoProviderから項目を受け取り、分析用の共通インターフェースを作成します。実データを保持するADSOとは役割が異なり、ロード処理の格納先ではありません。データの永続化はADSOや接続先のデータソース側で行い、CompositeProviderは必要なデータをクエリへ提供します。

InfoObjectをキーや特性として設計しておくと、異なるADSOに存在する同じ業務項目を統一しやすくなります。たとえば会社コード、会計年度、品目、得意先などを共通のInfoObjectとして扱えば、プロバイダー間で項目の意味をそろえられます。InfoObjectの属性やマスターデータを確認したい場合は、SAP BW/4HANA InfoObjectの設計と運用も参照してください。

クエリとの関係

クエリは通常、CompositeProviderをデータソースとして利用します。CompositeProviderの項目名、キー figure、通貨、単位、特性の定義を変更すると、下流のクエリやレポートに影響します。開発環境で定義を変更した後は、既存クエリの参照項目、フィルター、変数、集計結果を確認してから移送します。

02入力プロバイダーを設計する

粒度をそろえる

最初に、各入力プロバイダーが1レコードで表す業務単位を確認します。売上明細を1行で持つADSOと、月次・会社コード単位で集計したADSOを直接結合すると、明細側のレコードが集計側の複数条件に一致し、金額が重複することがあります。結合前に、日付、会社コード、品目、得意先などの結合条件を明確にします。

項目の意味を統一する

同じ名称の項目でも、片方が受注日、もう片方が請求日である場合、同じ特性として扱うと分析結果を誤解しやすくなります。技術項目名だけで判断せず、業務定義、データ型、長さ、通貨、単位、タイムゾーンを確認します。

既存のデータ格納と変換処理を整理するときは、SAP BW/4HANA Advanced DataStore Objectの基礎でADSOの役割とデータフローも確認できます。CompositeProviderでは入力側の構造がそのまま結果の品質に影響するため、ロード完了だけでなく、キーと集計単位まで確認します。

必要な項目だけを公開する

入力プロバイダーの全項目をそのまま公開すると、クエリ設計が複雑になり、利用者が似た項目を誤って選択する可能性があります。分析に必要な特性、キー figure、通貨、単位、時間項目を選び、技術管理用の項目は用途を明確にして公開範囲を決めます。

03Union結合とJoin結合を使い分ける

Union結合

Unionは、同じ意味を持つ複数のプロバイダーのレコードを縦方向にまとめる結合です。たとえば、同じ構造を持つ国内売上ADSOと海外売上ADSOを一つの販売データとして扱う場合に適しています。共通する項目は同じ特性やキー figureへマッピングし、片方にだけ存在する項目は空値や既定値の扱いを設計します。

Unionでは入力プロバイダー間で同じ業務事実が重複していないことを確認します。期間や会社コードの範囲が重複していると、合算時に二重計上が起こります。データの出所を示す特性を追加しておくと、結果の確認と障害調査が容易になります。

Join結合

Joinは、共通キーを使って複数のプロバイダーを横方向に結合します。販売実績に顧客属性や商品属性を関連付けるような用途で利用できます。Joinキーが一意でない場合、片側の1レコードに対して相手側の複数レコードが結び付き、結果行数とキー figureが増加するため、結合前に一意性を確認します。

Join条件には、業務上必須のキーを含めます。会社コードだけでなく、必要に応じて品目、販売組織、期間、言語などの条件を加え、不要な組み合わせを作らないようにします。属性を参照するだけであれば、マスターデータやナビゲーション属性を使う方が、複雑なJoinを避けられる場合があります。

UnionとJoinの判断基準

同じ種類のレコードを追加する場合はUnion、同じ業務事実へ別の項目を横付けする場合はJoinを基本に判断します。どちらを使う場合も、入力件数、結合後件数、キー figureの合計値をテストデータで比較します。

04CompositeProviderを作成する

事前確認

作成前に、次の情報を準備します。

• 入力するADSOまたはInfoProviderの名称
• 各入力のレコード粒度とキー
• UnionまたはJoinの結合方式
• 共通する特性とキー figure
• 通貨、単位、時間項目の扱い
• 下流で利用するクエリと移送単位

命名規則は、業務領域、用途、責任範囲が分かる形にします。短期検証用のオブジェクトと本番クエリ用のオブジェクトを同じ命名パターンで作ると、運用時に識別しにくくなります。

作成の流れ

SAP BW/4HANAのモデリング環境でCompositeProviderを作成し、最初に名前、説明、パッケージなどの基本属性を設定します。その後、入力プロバイダーを追加し、必要な結合方式を選びます。各入力の特性とキー figureを出力項目へマッピングし、結合条件、項目の参照元、通貨・単位の関係を確認して保存します。

作成後は、オブジェクトを有効化します。有効化エラーが発生した場合は、未割り当て項目、互換性のないデータ型、結合条件の不足、通貨または単位の不整合を順に確認します。エラーを無視して下流のクエリを作ると、原因が複数のオブジェクトに分散します。

データ変換とロードを含む構成では、SAP BW/4HANA変換処理の設計と確認も関連します。CompositeProvider自体にデータをロードするのではなく、入力側のロードが完了し、正しいステータスになっていることを確認します。

有効化後の検証

有効化後は、まず各入力プロバイダー単体の件数と合計値を確認します。次にCompositeProviderを通した件数、合計値、期間別の推移、主要な特性別の内訳を比較します。Unionでは入力合計と出力合計、Joinでは結合による行数増加とキー figureの重複を重点的に確認します。

05Infosetとの違いを整理する

Infosetは、主に複数のデータソースを結合して利用するための論理的なビューとして使われてきたモデルです。CompositeProviderは、BW/4HANAのデータウェアハウスモデルで複数のInfoProviderを統合し、クエリへ提供するための中心的なオブジェクトです。

実際の選択では、既存環境のデータモデル、利用可能なプロバイダー、クエリ要件、運用方針を確認します。新しいモデルでは、必要な結合条件とデータフローを明確に記述できる構造を優先し、旧来オブジェクトとの関係を移行計画に含めます。名称の違いだけで判断せず、データの格納場所、結合方式、下流の利用方法を比較します。

06データ不整合を切り分ける

件数が想定より多い場合

Join後の件数が増えた場合は、結合キーの一意性を確認します。入力側で同じキーが複数行存在する場合、結合結果が掛け算になります。期間や組織などの条件が欠けていないか、片側に重複データがないか、特性のマッピングが正しいかを確認します。

Union後に件数が多い場合は、入力プロバイダーの対象期間や会社範囲が重複していないかを確認します。移行期間に旧データと新データが同じ期間を持つケースでは、出所を示す項目とロード状態を使って重複範囲を特定します。

金額が二重計上される場合

金額の二重計上は、Joinの多対多結合、Unionの重複期間、異なる粒度のキー figureを同じ構造へ配置した場合に発生します。代表的な伝票、会社コード、期間の組み合わせを一つ選び、入力側の明細、結合後の行数、各キー figureの値を段階的に比較します。

また、通貨換算や単位換算が別の層で実行されていないかを確認します。入力側ですでに換算済みの金額へ、クエリ側の換算を重ねると、値の意味が変わります。通貨、単位、換算日、基準通貨を設計書と照合します。

項目が空になる場合

項目が空になる場合は、マッピング元のプロバイダー、Joinキー、フィルター条件、マスターデータ参照を確認します。Unionで片方の入力に項目がない場合は、空値が仕様なのか、既定値または別のマッピングが必要なのかを決めます。

07性能を確認する

CompositeProviderの性能は、入力データ量、選択条件、結合方式、結合キー、下流クエリの集計方法に左右されます。最初から全項目を公開するのではなく、実際のクエリで使う項目を中心にモデルを設計します。

Joinの前にデータを適切な粒度へ集約できる場合は、不要な明細を結合対象へ渡さない構成を検討します。入力側のフィルター条件がクエリまで正しく伝播するか、実行時間が特定の結合や計算へ偏っていないかを確認します。

性能問題の調査では、同じ選択条件を入力プロバイダー単体とCompositeProviderで実行し、処理時間と件数を比較します。単体では速く、統合後だけ遅い場合は、Join条件、Union対象数、不要な項目、クエリの集計粒度を重点的に調べます。運用環境では、SAP BW/4HANAのパフォーマンスチューニングも併せて確認してください。

08移送と運用を管理する

開発環境でCompositeProviderを変更したら、入力プロバイダー、変換、クエリへの依存関係を確認して移送します。構造変更を先に本番へ移送し、入力側やクエリを後から移送すると、短時間でも参照エラーや不完全な結果が発生します。

本番反映後は、オブジェクトの有効化状態、入力データの最新ロード時刻、代表クエリの件数と金額、主要な期間の欠落を確認します。変更記録には、結合方式、結合キー、追加・削除した項目、影響を受けるクエリ、検証結果を残します。

障害時は、直近のCompositeProvider変更だけでなく、入力ADSOのロード、変換、マスターデータ更新、権限変更も時系列で確認します。入力データが不足している状態でCompositeProviderを再有効化しても、データ欠落は解消しません。データフローの各段階を単独で検証し、最初に結果が変わった地点を特定します。

09実務で使える確認チェックリスト

• 入力プロバイダーの粒度とキーを記録した
• UnionとJoinの選択理由を設計書に残した
• Joinキーの一意性を確認した
• Union対象の期間と組織範囲を確認した
• 特性、キー figure、通貨、単位を正しくマッピングした
• 有効化後に入力件数と出力件数を比較した
• 代表的な金額の合計と明細を照合した
• 下流クエリへの影響を確認した
• 移送順序と切り戻し手順を準備した
• 本番反映後の監視項目と担当者を決めた

CompositeProviderは、複数のデータモデルを分析用にまとめるための強力な構成要素です。成功の鍵は、作成画面の操作よりも、入力側の粒度、結合キー、重複の可能性、通貨・単位の定義を先に整理することにあります。設計、作成、検証、移送、運用監視を一続きの手順として扱うと、集計誤りと性能問題を早期に発見できます。