Primary entities

To represent terminology found in each industry, the Common Data Model applies dynamic labels to the data entity class. The following table shows the data entity classes and labels for each industry:

In the Common Data Model ERD, top-level entities have a dark blue header that contains the logical name and class name. An entity contains fields and their data type. The following figure shows the Account entity:

The header of the Account entity shows its logical name, Customer, and the class name, 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. In the diagram, fields that begin with a period [.] indicate Embedded Data that can be referenced by using [.], for example the .AddressList field gets an address from the Contact methods object.

For example, a customer, Laura Smith, has an account with a company that sells telecom services. The following figure shows how the Account entity fields map to a record for the Laura Smith account:

In this scenario, the Account entity represents a customer account. The fields represent the data that comprise an account record:

• The .Contacts 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 ServiceAccounts field references the Service Accounts entity, which contains information about the services associated with the account. Laura Smith is subscribed to the Business Choice plan, a mobile phone 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, Embedded Data Objects have a light green header that contains a logical name and class name. The class key identifies the primary key and uses the identifier Data 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.

The following figure shows how the Account 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 Account is selected from a list of payment methods stored on the Payment methods object.

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 the Case, use an Embedded Data field type. Use a Query or Data reference field type when the Data Object must be sourced externally.

• Embedded Data: Used when a data object is within the context of an entity. The ERD describes these with a period to indicate that you can reference attributes in the related object from the entity (for example, .AddressList).
• Query: 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: Passes 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, a Transactions data reference can list all the transactions 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. 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.