Greenfieldデータモデリング

 Pegaのデータモデリングには、次の2種類があります。

1. Greenfieldデータモデリング
2. 既存のデータモデルの拡張

Greenfieldデータモデリングとは、データモデルをゼロから作成する場合の名称です。 Pega、Partner、Marketplaceモデルが顧客のデータモデルを表現できない（または顧客がライセンスされたモデルを持っている）場合には、Greenfieldデータモデリングが必要になります。 オブジェクトモデルの開発手法の1つとして、文書を解析しながら名詞や動詞を抽出する方法があります。 名詞はデータタイプ、動詞はプロセスとして認識されます。 プロセスは、ケースタイプ、またはケースタイプの内部で発生するものになる可能性があります。 名詞を特定した後に、データモデリングの作業が始まります。

業界標準のデータモデリング技術は、ビジネスとアプリケーションのデータニーズにまず焦点を当て、物理データモデルの検討は、アプリケーションとビジネスのニーズが満たされるまで先送りされます。

データモデリングは、3段階のレベルアップで実行します。

1. 概念
2. 論理
3. 物理的

リードシステムアーキテクト（LSA）は、他のステークホルダーと協力しながら、データモデリングの全レベルで重要な役割を担っています。 次の表は、どのレベルでどのようなアクションが実行されるかを示しています。

データモデリングにおける概念レベル

このレベルの主なステークホルダーは、ビジネス、顧客、専門分野のエキスパート（SME）です。 目的は、ビジネス用語やルールを定義することです。 データを特定し、プロセスでのそのデータのフローを確認します。 この概念レベルでは、ビジネスニーズを満たすために必要なデータ（およびデータタイプ）に対する明確な理解が得られます。

データモデリングにおける論理レベル

このレベルの主なステークホルダーは、ビジネスデータアナリストとデータアーキテクチャーエキスパートです。 ビジネスデータアナリストの役割は、データの収集源と収集方法を明確にすることです。 また、ビジネスニーズや用語、ポリシーに基づき、論理設計とデータ収集の決定を行います。 データアーキテクチャーエキスパートの役割は、データタイプ間の関係（キーの定義）、データタイプを配置する再利用レイヤー（組織レイヤーまたは特定レイヤー）、データの継承パスを特定することです。

データモデリングにおける物理レベル

このレベルの主なステークホルダーは、DBA、開発者、その他の顧客アーキテクト（SOR担当のSME）です。 DBAは、開発者またはSMEから提供されたガイダンスに従って、物理データベーステーブルを作成します。 これは共同作業であり、 その目的は、データ要素の実装方法を確定することです。 このレベルに達すると、論理設計が物理的な形になります。

Pegaデータベースのテーブルまたは外部データベースのテーブルにマッピングする、必要なデータクラスを作成します。必要であれば、外部システムからデータにアクセスするコネクターを作成します。 Pega固有のLSAとして、付与されたビジネス要件に適したスキーマを選択することも必要です。 CustomerDataとPega DATAに入力すべきデータを準備します。 このレベルでPega Reporting Databaseも使用する必要性を分析します。

このレベルでデータのフォーマット、計算、操作が完了することで、ビジネスプロセスに必要なすべてのデータが揃います。

Pegaでは、Data Relationshipフィールドタイプを使用することで、高度でダイナミックなデータ構造をモデリングできます。 Pegaのデータモデルは強力かつ柔軟性が高く、ポリモーフィズムなどの概念をサポートしています。 設計時に抽象クラスにマッピングされたData Relationshipフィールドタイプを宣言すると、実行時にフィールドのpxObjClassは必要な具象クラス名で更新されます。

次のようなビジネスシナリオを考えてみましょう。

自動車保険会社のアプリケーションには、見積もりの一部として参照すべき車種のリストが用意されています。 車種のリストには、自転車、自動車、トラックなどが掲載されています。 車種ごとにビジネスルールやプロセスが違う場合があります。 このビジネス上の問題に対する解決策として、次のようなデータモデルが考えられます。

解決策1：車種ごとにData Relationshipフィールドタイプ（複数レコード）を分離する

Bikeリスト、Carリスト、Truckリストを持つ複数のレコードを備えた、別のData Relationshipフィールドタイプを作成します。 各Data Relationshipフィールドタイプのリストには静的ページクラスがあり、開発者は各ページクラスに対して個別のユーザーインターフェイスを作成すべき場合もあります。

解決策2：すべての車種に対して、単一のData Relationshipフィールドタイプ（複数レコード）と単一のページクラスを設定する

もう一つの選択肢は、すべての車種に対して1ページクラスを使用し、単一のData Relationshipフィールドタイプ（複数レコード）を使用することです。 この場合は、条件付きロジックや状況設定でプロセスやルールの差異を導入する必要があります。

解決策3：車種ごとに、単一のData Relationshipフィールドタイプ（複数レコード）と別のページクラスを設定する

対象車種（各ページが別のクラスタイプになる）の単一のData Relationshipフィールドタイプ（複数レコード）を使用できます。 ルールレゾリューションは、各ページのランタイムクラスを使用して、正しいルール、プロセス、ユーザーインターフェイスを適用します。

推奨事項：

• 解決策3が推奨されます。 この解決策では、新しい車種を追加し、Vehicle List内のページを新しいVehicleクラスに簡単にマッピングできます。
• 解決策1は拡張性がないため、推奨されません。 たとえば、Boatなどの新しい車種が追加された場合に、 複数のページリストがあると、この変更を実装するために複数のルールの修正が必要になることがあります。
• 解決策2は推奨されません。 ページリストクラスが1つしかないと、状況が多すぎることと、ビジネスロジックのバリエーションが増えることから、ビジネスルールの保守が困難になります。