Relationships

A one-to-one relationship exists when one record in an entity is related to one record in another entity. For example, a patient record might include a field for the name of a spouse.

A parent-child relationship occurs when a record in an entity is associated with multiple records in the same entity.

For example, in the insurance industry, a Whole Life insurance product includes coverage that describes what is insured and for what amount. These records and relationships can be defined in one entity by creating a parent record for the product and relating the parent record to several coverage records. An alternative approach is to use separate classes for the insurance product and coverages, and then create a one-to-many relationship between them.

The relationship of the Products entity to individual products is one-to-many in the same Data Object. The following figure shows the parent product and related child products in the Product entity:

The parent object, .ParentProduct, can have many child objects. The connecting line with crow's foot notation shows the one-to-many relationship and indicates that the child product, .AssociatedChildProducts, is selected from a list of products stored on the Product entity.

The header of the entity shows its logical name, Product Specification, and the class name, Common-LDM-Entity-Product. The class key, ProductID, is the primary key and is an identifier type.

In App Studio, you can see the configuration of this one-to-many relationship. In the Product Case Type, the Data Model tab contains all data fields, as shown in the following figure. The Product field is a data reference field that holds the details of a product record.

You can view the sample data in the Common application to view a list of products and the parent product name (Security) and ID (PRD-001) as shown in the following figure:

In a one-to-many relationship, a record in one data entity is related to multiple records in another data entity. For example, a mortgage can have multiple statements for time periods or purposes, but each statement is for only one mortgage.

In the Common Data Model, the Service Account entity represents contracts between the customer (account entity) and a supplier of products and services. In financial services, the contracts are what consumers refer to as their account, such as their credit, or checking or savings accounts.  Other industries use terms such as policy, plan, or group plan.

In the entity-relationship model, the relationship between the Service Accounts entity and the Transactions entity is a one-to-many relationship. Each service account can have many transactions, while a transaction can have one service account. The following figure shows the Service Accounts and related Transactions entities:

The connecting line with the crow's foot notation shows the one-to-many relationship between the Service Accounts and Transactions entities. In this configuration, the .Transactions field in the Service Accounts entity references a list of transactions stored on the Transactions entity.

The header of the Service Accounts entity shows its logical name, Service Accounts, and the class name, Common-LDM-Entity-ServiceAccount. The class key, ServiceAccountID, serves as the primary key and is an identifier type.

The header of the Transactions entity shows its logical name, Transactions, and the class name, Common-LDM-Entity-Transactions. The class key, TransactionID, is the primary key and is also an identifier type.

To represent a one-to-many relationship, the Service Account entity class uses a Page List property to maintain the list of transactions associated with each service account. A query field references a Data Page that retrieves data from a specified data source and caches that data in memory. The Transactions entity class includes the ServiceAccount.ServiceAccountID property, which establishes the link between the service account and the transaction. The data reference field type can produce a list of all the transactions that are recorded for a given Service Account.

In App Studio, you can see the configuration of this one-to-many relationship. In the Service Account Case Type, the Data Model tab contains all data fields, including those that define and support the relationship between service accounts and transactions, as shown in the following figure:

The Service accounts to transactions list field uses a query to retrieve transactions related to a service account. For example, a telecom provider offers a Quad Play Plus mobile and internet service. The Service Account represents the Quad Play Plus service, and a transaction represents the customer's monthly bill. Service Account records and Transaction records are stored in separate databases.

You click the Gear icon to view the configuration of the field. This field, shown in the following figure, retrieves a list of transactions linked to the selected service account:

The Transaction field is a data reference field that stores the data of a single transaction record. For each transaction, the associated service account details are stored in the ServiceAccount data reference field in the transaction entity record, as shown in the following figure:

You can view the sample data in the Common application to view how the Quad Play Plus service account and the transaction relationships are displayed on the Related transactions tab, as shown in the following figure:

In a many-to-many relationship, records in two data entities relate to multiple records of the other entity. For example, a patient can have multiple doctors, while doctors can have multiple patients.

The Common Data Model defines a many-to-many relationship between Account and Contact. Each account can have many contacts, and each contact can link to many accounts. The following figure shows the Accounts and Contacts entities. The connecting line with crow's foot notation for the contact and the account fields shows the many-to-many relationship.

Entities can use data reference fields to connect other entities. For example, the Account entity uses the .Contacts field, a data reference, to connect to the Contact entity. The Contact entity also uses a data reference field to connect to the Account entity because a contact can have multiple accounts.

Objects with a light blue header represent a relationship between two top-level entities. The Common-LDM-Relation class creates these objects, which inherit from Pega Link association. For the many-to-many relationships between an account and a contact, the system creates an instance of the Common-LDM-Relation-AccountToContact relationship class, which inherits the many-to-many relationship classes from Link-Association-M2M. With this design, users can manage these relationships through a flow that begins with a Search and select form, then captures input values for the many-to-many records in a second form. You use the API service layer to directly maintain many-to-many records through API calls.

In App Studio, you can see the configuration of this many-to-many relationship in the Account Case Type on the Data Model tab, as shown in the following figure:

The Contacts to account field uses a query to retrieve a list of contacts associated with the account. The Account to contact relationship field holds the relationship between an account and contact (for example, Primary or Owner).

The Data Model of the Contact Case Type shows the Account and Account to contact relationship fields in the Contact entity, as shown in the following figure: