Data modeling basics

Data modeling is a crucial aspect of application development because it enables you to identify the elements required to process the business use case, define the structure and relationships between the elements, and contribute to completing a process. These abilities, in turn, enable effective process automation and seamless integration with other systems. 

The following reasons highlight why data modeling is essential in Pega application development: 

1. Efficient data management 
2. Effective process automation 
3. Seamless integration with all objects in a system 
4. Faster application development 
5. Improved data security and compliance. 
6. Enhanced reporting and analytics 
7. Reusability and maintainability 
8. Scalability and extension  

You apply the principles of object-oriented programming, including encapsulation, inheritance, and polymorphism, in enterprise data modeling. 
 
Encapsulation defines the scope and applicability of attributes, determining how developers define each data type in a Pega Platform™ application. All data elements that logically fit into the same scope and applicability are grouped to form a data type. 

For example, Street, City, State, and postal code comprise an Address data type.

Inheritance defines the reusability and hierarchy, which determines how to arrange each data type from most general to specific. 

For example, Data-Party is the most general data type for Case participants, while Data-Party-Person is specific to the data object of a person.

Polymorphism defines the different forms of abstract objects, which determines how an object can take the required form according to the need in the context or hierarchy of the abstract object. 

For example, Data-Bird can be defined as an abstract data type; then, at run time, it can be object classes such as Data-Bird-Peacock and Data-Bird-Sparrow.

In Pega Platform, you can use data relationships to model advanced and dynamic data structures. The Data Models are flexible and powerful, supporting concepts such as polymorphism. At design time, declare a data relationship field type that maps to an abstract class. At run time, the required concrete class name is displayed in pxObjClass. 

Business scenario

An auto insurance company's application displays a list of vehicles to cover as part of a quote. The list can include motorcycles, cars, and trucks, each with unique business rules and processes. The following data models are possible solutions for this business problem: 

Solution 1: Create separate data relationships (multiple records) for each type of vehicle

Create a separate data relationship with multiple records for cars, trucks, and other vehicles, such as motorcycles. Each list for the data relationship has a static page class. Developers may need to create separate user interfaces for each page class. 

Solution 2: Create a single data relationship (multiple records) and a single-page class for all vehicle types

An alternative approach is to utilize a single-page class for all vehicle types and a single data relationship (multiple records). To differentiate between processes and rules, conditional logic or circumstancing can be employed. 

Solution 3: Create a single data relationship (multiple records) and a separate page class for different types of vehicles

You can create a single data relationship (multiple records) of covered vehicles where each page is a different class type. Rule resolution uses the run-time class of each page to apply the correct rules, processes, and user interface. 

The following figure shows the pictorial representation of the previous three solutions:

Recommendation

• Solution 3 is the best option. You can add a new vehicle type, and then map the page in the vehicle list to the new vehicle class.
• Solution 1 is not a recommended option because it is not scalable. For example, suppose the application updates to include a new vehicle type, such as Boats. Having multiple page lists might require modification of multiple rules to implement this change.
• Solution 2 is not a recommended option. With only a single-page list class, business rules become more difficult to maintain because there are too many circumstances and more variants of business logic.

The following figure shows the small portion of the Pega clipboard view of the Van, Car, and Truck specializations of the MDC-Data-Vehicle class being added to the same embedded page list, VehicleList: