Class structure of the Common Data Model

All the entities provided by CDM inherit from the Common-LDM-Entity base Entity class. For example, the Account entity class is Common-LDM-Entity-Account. An entity contains fields of the following Field Types: 

• Identifier 
• Single value field 
• Embedded 
• Data reference 
• Query 

Identifier is a single-value property, generally used to define the primary key of that entity. It is a best practice for an entity to have its own primary key besides the default pyGUID. 

Single value fields can be text, currency, Boolean value, and so on. The Embedded, Data Reference, and Query types are used when you need a group value field but not a single value. For example, Address is a group value field that consists of single-value fields such as street, city, and zip code. These group values are important in an entity as they create relationships with Data Objects. The field type of a group value field is decided based on the business need and usage of the group value field in entity processing. 

Embedded applies when you want to capture the field values from user input. This field value is in the context of an entity. You can have a single instance or multiple instances, such as a Page or Pagelist.

A Data Reference is a mechanism designed to access or retrieve data from another entity or data object. This data is obtained based on specific parameters or criteria and is used as a source for combo boxes or any suitable control within a user interface view.

A Query functions similarly to a data reference by extracting records according to predetermined parameters or criteria and presenting them within the view. These parameters or criteria must be defined at design time, meaning during the development phase of the code, and cannot be altered at runtime. The Query field operation is a unidirectional process: data is retrieved and displayed without further modification in the view.

In contrast, the data reference field type offers a more dynamic interaction. It allows you to modify parameter values at runtime and retrieve data again based on these updated parameters, providing greater flexibility in data handling and display within an application.

The Field Types in CDM are not different from core Pega Platform™ Field Types. The only difference is that the fields are in the context of the entity-data object relationship, which is predefined according to the business requirements of the provided entity. The cardinality of the relationship can be one-to-one, one-to-many, or many-to-many.  

Generally, we see relationships between two different objects. The special relationship you find in the Common Data Model is a one-to-many relationship within the same data object. This definition of the relationship between the fields of the same data object is required to embed the related data objects into one single entity. For example, the Product entity class structure contains ParentProduct as a data reference Field Type, which refers to another field, AssociatedChildProduct. This kind of complex relationship handling becomes straightforward with the Common Data Model class structure, as shown in the following figure:

Another complex relationship is many-to-many, which was not handled by default in earlier versions. Because of that, LSAs defined their own way of handling many-to-many relationships. Now, with the Common Data Model, it is standardized and predefined in the required entity. For example, if you look at two entities, Account and Contact, their relationship is many-to-many. An account can have many contacts, and a contact can be associated with many accounts. The following figure shows the many-to-many relationship between Account and Contact.

Common-LDM-Entity is in the Work-Cover- class direct hierarchy, so it has Case Management features. Common-LDM-Relation is in the Link-Association-M2M class direct hierarchy so that it can manage many-to-many relationships. For example, for the many-to-many relationships between an account and a contact, an instance of the Common-LDM-Relation-AccountToContact relationship class is created. 

Check your knowledge with the following interaction: