Skip to main content

業界基盤データモデルの拡張

業界基盤データモデルの拡張

次のプロセスに従って、業界の基盤となるデータモデルを拡張します。

  • 業界基盤データモデルドキュメントの入手
  • システムオブレコードデータモデルの入手
  • システムオブレコードデータモデルの業界基盤データモデルへのマッピング
  • 業界基盤のデータモデルにプロパティを追加し、必要に応じてデータクラスを追加
  • データディクショナリーの整備

マッピング作業を開始する前に、データのどの部分をマッピングするかを決定します。 たとえば、最初のMinimum lovable Product(MLP)を作成する場合は、本稼働前にソースからすべてのデータをマッピングする必要がないこともあります。

業界基盤データモデルドキュメントの入手

各業界基盤データモデルのPega Communityランディングページには、実体関連図(ERD)とデータディクショナリーが掲載されています。 業界基盤データモデルをシステムオブレコードデータモデルへマッピングするには、これらのドキュメントが必要です。 業界基盤データモデルが提供するデータタイプ、クラス、プロパティの関係を把握しておきましょう。

たとえば、Pega Customer Serviceデータモデルには、次の3つの主要なクラスがあります。

1. Pega-Interface-Account
2. Pega-Interface-Customer
3. Pega-Interface-Contact

銀行のような業界では、顧客は通常、当座預金や普通預金など複数の口座を保有しています。 顧客は、口座ごとに複数の連絡先を定義できるようにする必要があります。 したがって、AccountとContactの関係は多対多となります。

Pegaの業界フレームワークでは、データモデルの利用者に中間的な多対多のアソシエーションクラスの使用を強制することはありません。 その代わり、Pegaのフレームワークは厳密に関心の分離(SoC)原則に従い、データ消費者が適切な名前付けとパラメーター化が行われたデータページを参照することで、多対多関係の複雑性を隠蔽します。

システムオブレコードデータモデルの入手

組織のエンタープライズアーキテクチャーチームと協力して、システムオブレコードのモデルを入手します。 このデータモデルドキュメントは、以下のような形式の場合もあります。

  • 実体関連図
  • 正規データモデル(一般的に使用されるESBソリューション)
  • WSDLまたはXSD
  • スプレッドシート

上記のドキュメントは、形式に関係なく、業界モデルをシステムオブレコードにマッピングするためのソースとして利用できます。

システムオブレコードデータモデルの業界基盤データモデルへのマッピング

次の手順は、システムオブレコードデータモデルを業界基盤データモデルにマッピングすることです。 このプロセスをサポートするには、スプレッドシートなどの表形式でこの情報を記録してください。 出力は、統合応答からアプリケーションのデータ構造にプロパティ値をマッピングする際に使用する参照ドキュメントです。

この分析作業中に、アプリケーションに新しいプロパティが必要であることがわかる場合もあります。 たとえば、ヘルスケア業界の基盤データモデルをマッピングする際に、保険加入者の本国以外で保険金請求があった場合の情報を保存するプロパティが必要になることがあります。 アプリケーションのデータモデルに追加する必要があるため、プロパティが存在する名前とクラスを記録してください。

データクラスとプロパティの追加

新しいデータクラスとプロパティは、アプリケーションがソースシステムからそのデータを必要とする場合にのみ作成します。 できる限り、業界基盤データモデルのデータクラスとプロパティを使用してください。

新しいプロパティとデータクラスを作成する場合は、組織レベルの統合ルールセットに統合ルールを生成してください。 各データページをテストし、ソースデータとアプリケーションのデータモデルが正しくマッピングされていることを確認します。

ヒント: 時間の経過とともに、ウェブサービスやRESTサービスの定義が変更されることがあります。 このため、ルールセットを使用して統合ルールのバージョンを管理します。 ベストプラクティスとして、センターオブエクセレンスがこれらのルールを管理し、開発環境にデプロイできるようにしてください。

データディクショナリーの整備

データマッピングが記録されていないと、モデルを保守する別のチームが、必要に応じてマッピングを元に戻すことが困難または不可能になる場合があります。 データディクショナリーは、2つ以上のソースデータ項目が1つの出力データ項目に対応する場合に、特に重要です(このような種類の関係を全射(surjection)といいます)。 たとえば、同じタイプの情報が統合データモデル内の2つの異なるパスに存在する場合です。 開発チームに、データモデルのプロパティの意味と適切な使用方法を文書化するよう奨励してください。


このトピックは、下記のモジュールにも含まれています。

If you are having problems with your training, please review the Pega Academy Support FAQs.

このコンテンツは役に立ちましたか?

改善できるところはありますか?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice