Primary entities

In the diagram, entities have a dark blue header that contains the logical name and class name. An entity contains fields and their data type.

Entities represent the core data used in Pega Platform™ applications.

The header of the Accounts entity shows its logical name, Accounts, and the class name, Entity-Account. All entities are defined in the Common-LDM-Entity class, so the full class name for the Accounts entity is Common-LDM-Entity-Account.

The class key, AccountID, is the primary key and is an identifier type.

Fields define the entity. Fields can reference data from another entity or data object. Fields that begin with a period [.] indicate embedded data that can be referenced using [.], for example the .AddressList () field gets an address from the Contact methods object.

Consider that a customer, Laura Smith, has an account with a company that sells telecom services. In this case, the Accounts entity represents a consumer account. The fields represent the data that comprise an account record. For example, the .Contact () field connects to the Contacts entity, which contains information for the people associated with the account. Fields for address, phone, and email are referenced from other data objects. The ServiceAccount () field references the Service Accounts entity, which contains information about the services associated with the account, in this case, Laura Smith is subscribed to the Business Choice plan, a mobile phone service and internet service.

The entities in a logical data model, such as Accounts, Contacts, and Service Accounts, specify the data relationships that let you use the actual data in multiple entities and multiple cases. The actual data can be stored on different physical sources.

In the Entity Relationship Diagram, data objects have a light green header that contains a logical name and class name below it. The class key is indicated as the primary key and is an identifier type. Data objects describe a set of related fields. Fields in a data object indicate their data type and do not begin with a period, because the fields exist on the data object.

For example, the Accounts entity uses the .PaymentMethodList() field to connect to the Payment methods object. The Payment methods object stores the records that define various methods of payment, such as credit cards and checking accounts, associated with each account.

The reference for the payment method field in Accounts is selected from a list of payment methods stored on the Payment methods object.

The connections between entities in a data model are called relationships. Relationships reflect business rules. Relationships between entities can be one-to-one, one-to-many, or many-to-many.

One-to-one

A one-to-one relationship could be a patient record with a field for the spouse's name.

Many-to-many across different data objects

A contact-to-account relationship could be one in which many contacts can be related to one account, and a contact can be related to many accounts.

One-to-many across different data objects

A service account-to-transaction relationship could be one in which a service account can have many transactions, and a transaction can have one service account.

One-to-many within the same data object

An object can have one parent object, and a parent object can have many children objects.

In Pega Platform, you create data relationships by using a set of specialized field types. When deciding which field type to use, consider the sourcing of the data for which you want to establish a data relationship. As best practice, if the data object does not need to be sourced outside of the case, use an Embedded data field type. For use cases in which the data object needs to be sourced outside the case, use a Query or Data reference field type.

• Embedded data. Embedded data is used when a data object is within the context of an entity. The Entity Relationship Diagram describes these with a period to indicate that you can reference attributes in the related object from the entity.
• Query. A query field references a data page that retrieves data from a specified data source and caches that data in memory. For example, the Accounts entity uses a query field to display information about associated service accounts.
• Data reference. A data reference can pass data from entity to entity. Data reference lists help you source data from your application and display that information in a table where every row represents a field in a record, or a combo box. For example, in the data model, a Transactions data reference can produce a list of all the transactions that are recorded for a given Service Account.

As you develop the data model for your application, consider the entities and data relationships that best fit your data. As much as possible, use the entities and data objects in the Common Data Model. If needed, consider where to extend the model to add your case types and data objects.

For more information, refer to the "data dictionary" document that describes the entities and objects in the Common Data Model.