Greenfield data modeling
Two types of data modeling exist in Pega Platform™:
- Greenfield data modeling
- Extending the existing data model
A Greenfield data model is a data model that you create from scratch. A project requires Greenfield data modeling when a data model from Pega Marketplace might not represent the data model of a client, or the client has a licensed model. One technique for developing an object model is to parse a document while extracting nouns and verbs. Nouns become data types, and verbs become processes. Processes can be a case type or an action that occurs in a case type. Once project development teams identify the nouns, the data modeling job begins.
Industry-standard data modeling techniques focus on the data needs of the business and application first, deferring all considerations for the physical data models until the application and business needs are complete.
Data modeling follows a three-level approach:
- Conceptual
- Logical
- Physical
As a Lead System Architect (LSA), you play a significant role at every level of data modeling by collaborating with other stakeholders. The following table shows what actions different users perform at each level:
| Design level | Stakeholders | Actions |
|---|---|---|
| Conceptual | Business, client, and subject matter expert (SME) for a business domain |
|
| Logical | Business Data Analyst and Data Architecture Expert |
|
| Physical | Database analyst, developer, and client SME for a system of record (SOR) |
|
Conceptual level in data modeling
At this level, the main stakeholders are the business, client, and SME. The purpose is to define the business terms and rules. Identify the data and how it flows in the process. The output of this conceptual level is a clear understanding of the data (and data type) that is required for fulfilling the business needs.
The following list describes the output of the conceptual level:
- Clear listing of all data elements required for a given business scenario.
- Definition of the type of data element.
- Identified source of the data element.
- Flow of the data in the business process.
- Recognition of the ownership and access control requirements of the data.
Logical level in data modeling
At this level, the main stakeholders are the Business Data Analysts and the Data Architecture Expert.
The role of the Business Data Analyst is to clarify how and from where the data collection occurs. The role provides logical design and data collection decisions in the context of business needs, terms, and policies.
The Data Architecture Expert role identifies the relationship between data types (define keys), the reuse layer in which to place the data types (the organization layer or a specific layer), and the inheritance path for the data.
The following list describes the output of the logical level:
- Logical grouping of data elements to form data objects.
- Layer for data objects in the application structure. For example, the placement of a data object can be at the organization, division, or application layers.
- Defined relationship and cardinality between data objects.
Physical level in data modeling
At this level, the main stakeholders are database analysts, developers, and the other client architects who are SMEs for the SOR. Database analysts create a physical database table based on guidance from a developer or SME. The work at this level is a collaborative effort, and the purpose is to finalize the implementation methodology for data elements. The logical design takes a physical form at this level.
Create the required data classes in Pega mapping to the database tables in Pega Platform or external database tables. If necessary, create a connector to access the data from external systems. As an LSA specific to Pega, you also choose the appropriate schema for the given business requirement. Plan what information the CustomerData and Pega DATA require. Analyze the need to use Pega Reporting Database as well at this level.
Data formatting, calculations, and manipulations occur at this level so that all data required for the business process is ready.
Polymorphism in data modeling
In Pega Platform, you can model advanced and dynamic data structures by using data relationships. The data models in Pega Platform are powerful and flexible and support concepts such as polymorphism. Declare a data relationship field type mapped to an abstract class at design-time, and at run time, pxObjClass updates to reflect the required concrete class name.
Consider the following business scenario:
An application for an auto insurance company displays a list of vehicles to cover as part of a quote. The list of vehicles can include cars, motorcycles, and trucks. Each of these vehicle types may have differences in its 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 with lists for cars, trucks, and other vehicles, such as motorcycles. Each list for the data relationship has a static page class; developers might need to create separate user interfaces for each page class.
| Embedded field name | Applies to class | Comments |
|---|---|---|
| Car list | Data-Vehicle-Car | Different data relationship defined for each type of vehicle |
| Truck list | Data- Vehicle-Truck | Different data relationship defined for each type of vehicle |
| Other list | Data-Vehicle-Other | Different data relationship defined for each type of vehicle |
Solution 2: Create a single data relationship (multiple records) and a single-page class for all vehicle types
Another option is to use only a single-page class for all vehicles and a single data relationship (multiple records). In this case, you use conditional logic or circumstancing to introduce process and rule differences.
| Embedded field name | Applies to class | Comments |
|---|---|---|
| Vehicle list | Data-Vehicle | Only one embedded page is in use, and conditional logic identifies the required UI and other rules based on the type of vehicle. |
Solution 3: Create a single data relationship (multiple records) and a separate page class for different types of vehicles
You can use 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.
| Embedded field name | Applies to class | Comments |
|---|---|---|
| Vehicle list | Data-Vehicle | The Vehicle list is mapped to Data-Vehicle class, and every page can have a class mapped as required at run time. |
| Bike | Data-Vehicle-Bike | The first page of the Vehicle list is Bike. |
| Car | Data-Vehicle-Car | The second page of the Vehicle list is Car. |
| Truck | Data-Vehicle-Truck | The third page of the Vehicle list is Truck. |
The following figure shows the Clipboard view of the Bike, Car, and Truck specializations of the FSG-Data-Vehicle class being added to the same embedded page list, VehicleList.
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.
Note: Polymorphism is not the only and best solution to fit all needs of data modeling in Pega Platform. As an LSA, always explore the possible approaches and perform a comparative study to select the required approach.
Check your knowledge with the following interaction:
This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?