Basics of a Data Model
A Data Model is the visual representation of all the data elements of an organization and the connections between them.
A well-designed Data Model provides your application with several benefits, including:
- Efficient reuse.
- Easy maintenance.
- Increased adaptability and scalability.
Data Model design is as important as process redesign to a successful Pega Platform™ application. Throughout the design and development stages of your project, you, as a Pega Business Architect, will work with Business team stakeholders and Pega System Architects to develop your application's Data Model.
In this topic, you explore fundamental considerations for the design and build of your application's Data Model.
The Data Model
All applications require the right data at the right time to operate effectively. The main purpose of the Data Model is to define the data that your application requires to achieve the business outcome.
As a Pega Business Architect, you will work with three variations of the Data Model over the course of a project. The three variations of the Data Model are the Conceptual Data Model, the Logical Data Model, and the Physical Data Model.
The Conceptual Data Model
For the Pega BA, documenting the Conceptual Data Model for an application starts by understanding the data entities and attributes the business uses to process work, as well as the relationship between those data elements.
The following diagram represents a Conceptual Data Model for books stored in a warehouse. The illustration shows the basic entities, attributes, and relationships between the key elements of the book warehouse inventory model. In this example, Warehouse is the entity, while Name, City, and Capacity are the attributes. Additionally, Warehouse has a direct relationship with the Address and Inventory entities:
Consider the Conceptual Data Model as a living document. Use the Conceptual Data Model when meeting with business stakeholders about your design for the business process as it helps business stakeholders visualize the data entities you have identified. This visualization makes gaps in the process or data easier to identify.
As you construct the Conceptual Data Model, you do not need to model every single piece of data required to achieve the business outcome, but a time spent in data design early in the project can save time later if you find that the data requirements of the business are not fully understood.
Overall, the Conceptual Data Model helps to mitigate the risk of rework due to misunderstandings in the early stages of the project. Of course, as the project progresses and the team obtains additional insights, the Conceptual Data Module might change. Still, this Conceptual Data Model is a solid starting point for the application development discussions.
The Logical Data Model
The Logical Data Model is the Conceptual Data Model translated and refined for Pega Platform.
In the center of the following image, slide the vertical line to see an example about how the Conceptual Data Model translates to the Logical Data Model using the Warehouse scenario as the example:
The Logical Data Model converts the data entities and attributes of the Conceptual Data Model into data objects and fields, respectively.
In Pega, fields are reusable UI components that consist of a name and a Field Type. The Field Type determines the format of the data that can be entered into the field. Each field stores a value that is associated with a Case.
Note: For the relevant training materials, see Fields and Field Types.
A data object is a structure for describing an entity by grouping a set of related fields. Data objects are reusable across all of an application's Case Types.
Note: For the relevant training materials, see Understanding data objects.
In the following image, click the + icons to learn more about how data objects and fields combine to define the application's Logical Data Model:
As a Pega Business Architect, you will work with System Architects to create an application's Logical Data Model. You will configure the primary Data Model elements including the data objects, fields, and relationships in App Studio, while System Architects configure the more advanced requirements in Dev Studio.
The Physical Data Model
The Physical Data Model reflects data as it is stored and accessed in the application.
The focus of the Physical Data Model is the integration settings required to access the organization's data, including local storage with the Pega database and any external systems of record used by the organization.
Details of the Physical Data Model are visible on App Studio's Integration Designer landing page. The Integration Designer provides a single location in App Studio for accessing the data objects, data Views, data object dependencies, and Systems of record in an application. The Integration Designer also provides insight into how the entities that define the Physical Data Model are connected.
In the following image, click the + icons to learn about the information displayed on the Integration Designer landing page:
Although you, as a Pega Business Architect, will need to have a basic understanding of the system of records that an organization uses. The Lead and Senior System Architects are primarily responsible for the design and configuration of the Physical Data Model as most of the work is done in Dev Studio.
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?