データリレーションシップ

データオブジェクトとは、氏名や住所などのフィールドでエンティティを説明するテンプレートのことをいいます。 データリレーションシップは、関連するフィールドのセットを関連付けるコンテナになります。 データリレーションシップを使用すると、データオブジェクト間の関係や、ケース間の関係を作成できます。 データリレーションシップは、データそのものを保管する代わりに、データを関連付けます。

たとえば、顧客がビデオストリーミングアカウントにサインアップする場合、姓、名、メールなどの基本情報を提供します。 メールはその顧客のものなので、メールフィールドに入力する値は、顧客の姓名に関連付ける必要があります。 システムでは、Customerデータリレーションシップで3つの関連する値を収集できます。

Customerデータリレーションシップの例では、データリレーションシップは、姓、名、およびメールフィールドの共通のコンテキストを確立します。 次の図に示すように、これらのフィールドにはすべて顧客を説明するデータが含まれています。

データリレーションシップは、単一レコードまたは複数レコードを参照するように設定できます。 違いは、複数レコードのデータリレーションシップでは、グループ化された値のリストを参照する、という点です。 単一レコードのデータリレーションは、1つの値のセットのみを参照します。 前のセクションのCustomerデータリレーションシップの例は、単一レコードのデータリレーションシップを示しています。

たとえば、動画配信会社が、ユーザーがアカウントに登録した際に収集した顧客情報を利用して、マーケティングキャンペーンを行うとします。 Campaignケースタイプでは、Current Customersという複数レコードのデータリレーションシップを使用します。 Current Customersデータリレーションシップには、各顧客のレコードが含まれます。

次の画像の中央にある縦棒をスライドすると、左に複数のレコードを持つ顧客データが、右にシステム設定が表示されます。

 ケースタイプまたはデータオブジェクトにより、データリレーションシップのデータモデルが定義されます。 データリレーションシップを作成するには、新しいデータオブジェクトを作成するか、既存のデータオブジェクトまたはケースタイプを使用します。 以下のResident submissions複数レコードのデータリレーションシップの例では、Person データオブジェクトによりデータリレーションシップのデータモデルが定義されています。

各データリレーションシップでは、定義されたすべてのフィールドを使用する必要はありませんが、すべてのフィールドが使用可能です。 たとえば、Customerデータリレーションシップを使用して、姓、名、メール、ユーザー名、パスワードなど、ユーザーの顧客情報を取得できます。 同じCustomerデータリレーションシップを使用して、「Confirmation」ページに情報を表示できます。 ユーザーが確認するのは氏名とメールだけで良いため、ユーザー名とパスワードは表示されません。 フィールドは顧客データオブジェクトの一部として残り、別のビューで参照できます。

複数のレコードを持つデータリレーションシップは、グループ化された各フィールドのインスタンスのテンプレートとして機能します。 複数レコードのデータリレーションシップでは、値はそれぞれフィールドタイプの構成に基づいて設定されます。 たとえば、求人応募の例で、応募者の氏名、会社名、連絡先、メールを含む複数レコードのデータリレーションシップで収集するとします。 「Full Name」フィールドと「Contact Number」フィールドは必須の値として設定できるため、「Full Name」と「Contact Number」列の下の新しい各フィールドは同じ設定となります。 以下の画像では、応募者がShaun Millsの連絡先を入力していないため、エラーメッセージが出ています。

また、複数レコードのデータリレーションシップでは、エンドユーザーが必要に応じてアイテムを追加、削除、更新できるように設定できます。 たとえば、「References」データリレーションシップは、関連する値の3つのグループまたは行を持つテーブルとして表示されます。 応募者は、「Add item」をクリックして、4番目の推薦者をリストに追加できます。

データオブジェクトには、他のデータオブジェクトを含めることができます。 同様に、データリレーションシップには他のデータリレーションシップを含めることができます。 たとえば、オンラインショッピングのアプリケーションでは、顧客は1つのアカウントに複数のクレジットカードを関連付けることができます。 Customerエンティティはアプリケーションの単一レコードのデータリレーションシップです。Credit Cardsエンティティは複数レコードのデータリレーションシップです。 各エンティティは、それぞれのデータオブジェクトと関係しています。

次の画像では、Customerエンティティにより顧客の氏名、ユーザー名、パスワード、クレジットカードが取得され、参照データオブジェクトに関連付けられます。 CustomerエンティティのCredit Cardsエンティティによりカード番号、有効期限、および認証ードが取得され、参照データオブジェクトに関連付けられます。 各顧客は、アカウントに複数のクレジットカードを保存し、必要に応じてカード情報を追加、削除、および更新できます。

氏名や住所の入力など、ケースタイプの内部で行われるユーザーインタラクションがデータの取得元となる場合は、Embedded dataフィールドを使用します。 情報はケースに埋め込まれ、ケースとは無関係に参照されません。 たとえば、Pega Platform™では住所（Data-Address-Postal）のデータオブジェクトが標準で提供されています。 住所情報を取得するために、住所を構成するすべてのフィールドをケースタイプに定義する代わりに、データオブジェクトタイプPostal Addressの埋め込みフィールドを構築することで、事前定義されているデータ構造を再利用できます。

Embedded dataのユースケースには、ユーザーが氏名や住所などのデータを入力するあらゆる状況が含まれます。 サービスリクエストのケースの場合、サービスプロバイダーからの対応を受けられるように、顧客が問題の簡単な説明を入力します。 問題の説明は、データページから取得されるのではなく、顧客が入力します。 

ケースの処理では、他のアプリケーションやシステムをソースとするデータへアクセスする必要がよくあります。 Pega Platform™アプリケーションでは、データページが指定のデータソースからデータを取得してメモリー内にキャッシュします。 Query フィールドタイプは、システムがケースの外部のデータに一貫してアクセスして取得するフィールドを定義するために使用されます。 Queryフィールドは、データのソースを定義するデータページを参照します。 これは複数のレコード、単一レコードのどちらの設定でも同じです。 

Referenceフィールドタイプ

Case reference およびData referenceフィールドタイプは、Query フィールドタイプの特殊なバージョンで、識別子やキーによって選択可能なアイテムや明示的に参照されるアイテムのリストを定義するために使用するものと考えることができます。 ユーザーは、UIにより参照フィールドタイプのパラメーターを選択します。 

Referenceフィールドタイプは、ユーザーが選択できるオプションのリストを表示するために使用されます。 ユーザーは、単一レコードタイプで1つのオプション（メイン口座の選択）を選択するか、複数レコードタイプで多数のオプション（注文商品の選択）を選択するようにできます。 保存可能なデータページのほとんどのユースケースでは、Referenceフィールドタイプを使用しますが、Query フィールドタイプを使用することもできます。 

以下のインタラクションで理解度をチェックしてください。