効果的なデータモデルの実装

Admin@FSGPricingTestとCOE@FSGでログインすると、あるパターンがあることがわかります。 各アプリケーションのData Typesビューに表示されているクラスは、そのアプリケーションが所有しているクラスです。 アプリケーションの主な役割は、これらのデータタイプのテスト、メンテナンス、パッケージ化とデプロイの方法の定義です。

FSGアプリケーションでは、BookingチームがContractクラス、Addressクラス、Locationクラスを再利用します。再利用しないことは合理的ではありません。

Constantクラスは再利用できます。 Constant クラスを使用すれば、ビジネスが調整、管理、メンテナンスする可能性のある値をハードコーディングしなくて済みます。 FSGSampleアプリケーションでは、Constantクラスの使用方法を示すテスト専用のデータタイプが定義されていません。 その代わり、FSGSampleアプリケーションでは、FSG-Sample-Work-TestConstantsクラスそのものを使用して、FSG-Data-Constantクラスをどのように使用できるかが示されます。 Bookingチームは、ConstantPropsデータタイプを定義するか、Application Settingsを使用するか、またはその中間のアプローチを取るかを決定する必要があります。

Bookingアプリケーションでは、イベント終了後にFeedbackクラスを使用する可能性があります。 このクラスは、FSGのイベント運営に関する評価を顧客から収集するために使用されます。

Bookingチームには、Feedbackクラスに関する懸念事項があります。 FSGSampleアプリケーションでは、Feedbackクラスの使用方法は示されていません。 現在、Feedbackクラスは抽象的で、プロパティを2つしか持っていません。 セクションやデータトランスフォームなどの他のルールタイプはありません。 また、Bookingチームは、顧客とのやり取りの後にイベントマネージャーが値を入力する必要があるのか、あるいはPega Survey画面を使う自動化されたインターフェイスアプローチを採用するかを決めかねています。

Bookingアプリケーションの第1ステージでは、特定の場所でイベントを開催するために、顧客（Contact）に価格を提示します。 Bookingアプリケーションは、FSGPricingTestアプリケーションが所有するデータタイプを再利用できます。 FSGPricingTestアプリケーションで定義されているPricingDisplayというテスト専用データタイプがありますが、これは、Bookingアプリケーションが独自のPricingDisplayクラスを定義しなければならないことを示しています。

FSG COEのConstantクラスには、Application、CaseUsage、Description、DataTypeなどのプロパティがあります。 FSG COEのFSGSampleアプリケーションには、そのFSG-Data-Constantデータタイプに関連する2つのテストケースが含まれています。

FSGSampleのTestAppConstantsLibraryケースは、LoadConstantsForClassという名前のデータトランスフォームをソースとするD_FSGSampleConstantsデータページを定義します。 Bookingチームは、この例に従って、D_BookingConstantProps、D_HotelConstantProps、D_WeatherConstantPropsの各データページを定義します。

Bookingチームは、分類可能なApplication Settingsを使用することを検討しました。 Bookingチームは、FSG COEのソリューションが、Text以外のデータタイプを持つプロパティへのドットパス構文をサポートしている点を評価しています。

特にBookingアプリケーションについては、FSG COEがPricingDisplayデータタイプを利用したイベントの見積もり画面の例をモデル化したことを、Bookingチームは高く評価しています。 Pricingコンポーネントは、Work-WorkRecalculatePrices、@baseclass RecalculatePrices、FSG-Data-Pricing Recalculateの3つのデータトランスフォーム内で、PricingDisplayPageページ名パラメーターをサポートしています。 すでにこうした機能があるため、Bookingチームはそれを利用できます。 これにより、自分たちでその機能を構築する時間と工数を省けます。

Bookingチームは、FSG COEのデータモデルの分析とレビューに使用したものと同様のテーブルを作成しました。 Test-Only Data Types列はNew Data Types where ownership is undecided列として再利用されます。

BookingチームのBookEventケースでは、開始日や終了日など、イベントに関する情報を取得する必要があります。  イベントの開催はFSGのビジネスモデルの中核をなすものですが、BookingアプリケーションのBookEventケースは、今のところEventデータタイプが使用されている唯一の場所です。

Bookingチームは、COE所有のFSG-Data-Hotel クラスをHotelアプリケーションにまで拡張できますが、緊急な必要性はないと考えています。

Bookingチームが、抽象 FSG-Data-Feedback クラスを拡張して具象FSG-Data-Feedback-EventVenueクラスを形成することは可能です。 Bookingチームは、FSG COEがFSG-Data-Feedbackに参照プロパティを追加することを推奨します。 レポートディフィニッションは-EventVenueクラス内で定義され、 FSG-Booking-Work-BookEventへのJOINと、 FSG-Data-VenueへのBookEvent case.VenueGUID参照プロパティへのJOINを実行します。 前回のデータ記録時から施設名が変更になっている場合があります。 名前のプロパティを使ってJOINを定義することは好ましくない方法であり、データ整合性違反になります。 施設の名前は歴史的な理由で記録することができますが、プロパティ名にその事実を反映させる必要があります（例：.HistoricalVenueName）。

BookingチームのFSG-Data-Feedback can の拡張をFSGSample2アプリケーションに組み込むことで、その可用性を他の上位レイヤーの開発チームに認識してもらえます。 FSGのTo-Doリストには、Pega Surveyを送信して回答を受け取り、その回答を適切なFSG-Data-Feedback テーブルで永続化するための一般的な方法を開発するという案件があります。 

ネットプロモータースコアがカテゴリー（promoter、passive、detractor）に変換されたプロパティは、永続化されるデータには含められません。 これを含めると、データ整合性違反にもなります。 レポートディフィニッションでは、カスタムの3入力パラメーター付きSQL Functionを利用してカテゴリーを導き出せます。 最初のパラメーターは、未加工のプロモータースコアのプロパティを使用して読み込まれます。 2番目と3番目のパラメーターは、カテゴリーの整数範囲の開始と終了です（たとえば、0と6は「detractor」の範囲の開始と終了です）。 カスタムのSQL Functionは、最初のパラメーターが範囲内にある場合、1を出力します。 それ以外の場合は0を出力します。 レポートディフィニッションでは、SQLで標準化されたSUM()関数を使って列を集約します。

HotelアプリケーションとHotel ProxyアプリケーションはRESTful Pega APIを使用してやり取りします。 アプリケーションのサイズ、セキュリティ、メンテナンスのしやすさなどさまざまな理由から、Hotel Proxyアプリケーションの作成ではHotelアプリケーションをベースにしていません。 また、両アプリケーションが継承するためには、FSG COEレベルでRoomsRequestデータタイプが定義されている必要があります。 HotelアプリケーションとHotel Proxyアプリケーションがクラスを共有するには、別のメカニズムを使用する必要があります。 ただし、両アプリケーションが使用するREST統合クラスは共有する必要があります。 論理的な結論は、共有クラスと関連コードが含まれるコンポーネントを構築することでした。

COEでは、天気予報に関連するデータタイプのセットをまだ定義していません。 そのため、Bookingチームは、Weather Forecastアプリケーションがこれらのデータタイプを所有するかどうかを決定する必要があります。 FSGのビジネスモデルでは、天気予報は必須ではありません。 他のアプリケーションでは、同じ天候のForcastingデータタイプを使用しながら、天候に対する準備は考えなくても構わないでしょうか。 両方を実行するコードが一緒にパッケージ化されている場合、どのような影響があるでしょうか。 天気予報のコードは軽量であるものと想定します。

Parkingアプリケーションでは、駐車場やガレージなど、さまざまなタイプの場所を扱います。 イベントに参加する参加者が近くの駐車場に停めたいと考えた場合、駐車場のオプションを地図上で確認することを望むと思われます。

Shuttleアプリケーションは、施設、ホテル、駐車場など、あらゆる場所に対応できます。 このことを知っていれば、FSG COEがParkingLocationクラスを定義する必要があることが明確になります。 Bookingチームは、必要に応じてそのクラスを直接継承したり、パターンを継承したりできます。

最後に、Shuttleアプリケーションでは、シャトルでの移動に関連するデータタイプが必要です。 Bookingチームはデータタイプを定義することができますが、他のアプリケーションはTrip、Vehicle、Companyなどのデータタイプの抽象化を利用できるでしょうか。

イベントの開催は、FSGの中心的なビジネスです。 FSG内の他のアプリケーション（BillingやAdvertisingなど）でも同じデータタイプ定義を使用できる可能性があります。 今後、他のアプリケーションがFSG-Data-Eventにプロパティを追加することもあります。 Bookingチームのメンバーは、イベント開催がどのように請求されるかについて顧客から問い合わせを受けることがあります。 Property-Read ABACセキュリティを適用することで、Billingチームのメンバーのみが閲覧を許可される情報を非表示にできます。 Bookingチームのメンバーは、チームメンバーが見ることのできる情報を顧客に伝え、詳細な情報が求められている場合にはBillingチームに照会します。

ベストプラクティスは、企業全体でPersonとPlaceの定義を標準化することです。 FSG COEがFSG-Data-Locationを拡張するクラスのコア定義をメンテナンスすることは合理的です。 その理由の一つは、Locationが同じCustomerDataスキーマテーブルに格納されていることです。 Shuttleアプリケーションを構築する際には、Locationの種類に関わらず、任意の2つのLocationで実施されるTripを定義する必要があります。 FSG COEがParkingLocationクラスのオーナーになることが最善です。

次の表に、元の未定義データタイプのセットについての決定事項をまとめました。

Shuttleアプリケーションがいつ作成されるかはわかっていません。 乗車人数に制限のあるVehicle が2つのLocationsの間でTrips を行う抽象的データモデルをFSG COEが設計すれば、Bookingチームは当然、それを活用できます。 おそらく、Vehicle を所有しているCompany はFSGではないと思われます。 FSGは、社員がシャトルの専任発車担当者になることを望んでいません。 その代わり、FSGは意思決定をできるだけ自動化したいと考えています。 たとえば、システムが無人で動作するようにします。 古くなったデータに頼りすぎると、無意味なデータを入力して無意味な結果を出力するような状態になりかねません。 リアルタイムでデータを受け取り、リアルタイムで意思決定できるソリューションでなければなりません。