Skip to main content

Implementing an effective data model


4 Tasks

45 mins

Visible to: All users
Advanced Pega Platform 8.5 English
This content is now archived and is no longer updated. Progress is not calculated. Pega Cloud instances are disabled, and badges are no longer awarded. Click here to continue your progress in the latest version.


Imagine that the Booking team is still in the design phase of their project; no development occurs. The Booking team’s first task is to review the current set of enterprise-level data classes developed by the FSG Center of Excellence (COE) team. This task aims to see which data classes the Booking team can reuse in their design. During their analysis, the Booking team is likely to discover data classes that the FSG COE team has not defined. The Booking team must then decide whether those undefined data classes are worthy of being defined at the enterprise level or, instead, be owned by the Booking team.

The following table provides the credentials you need to complete the challenge.

Role User name Password
Administrator COE@FSG rules
Administrator Admin@FSGPricingTest rules
Administrator Admin@Booking rules

Detailed Tasks

1 Analyze FSG Center of Excellence data model

After logging in as Admin@FSGPricingTest and COE@FSG, you notice a pattern. The classes shown in each application’s Data Types view are the ones that the application owns. The application is primarily responsible for testing, maintaining, and defining how to package and deploy those data types.

Application / Operator

Data Types Owned

Test-Only Data Types





Price, Priceable, Pricing, PricingInit, PricingPropertySource, PricingSummary



The FSGPricingTest application serves four purposes:

  1. Product rule creates the CustomerData schema tables for the Pricing component
  2. Includes the Pricing component in its Application rule. The Product rule also includes the component
  3. Tests the Pricing component
  4. Demonstrates how to use the Pricing component within an application




Address, Constant, Contact, Feedback, Hotel, Location, Venue


The FSG application contains organizational or enterprise layer classes. These classes describe the structure of objects that are shared by multiple applications within the organization. Objects are typically identified with nouns, and they represent “Persons," "Places," or "Things."

  • Business applications leverage standardized data classes that define Persons and Places.
  • Constant and Feedback are “Things.”
  • Every other data type owned by the FSG application is either a Person (Contact) or has something to do with a Place (Address, Location, Hotel, Venue).





  • The FSGEmail application does not define any data types.
  • The FSGEmail application defines a relevant record for the Work- WhenToSendEmail property.
  • FSG cannot define a Relevant Record applied to Work-, so it  defined one that is applied to the FSG-Email-Work-Email class.




Vehicle, Car, Truck, Motorcycle, RoadsideService

  • The FSGSample application is used to test and demonstrate how to use the data types that the FSG application owns. 
  • FSGSample does not include the FSG-defined data types that it tests within its own Data Types view; this is done to communicate which application is the owner of what data types. It avoids data type packaging redundancy.





Vehicle2, Car2, Truck2, Motorcycle2

  • The FSGSample2 application is used to demonstrate Data class Dynamic Class Referencing (DCR).
  • The Data Type view also includes FSG-Sample-Data-Vehicle and FSG-Sample-Data-RoadsideService.
  • The Vehicle class is added to the Data Type view to allow instances to be viewed.
  • FSGSample owns the Vehicle table, not FSGSample2.
  • FSGSample2 directly extends each FSG-Sample-Data-Vehicle class; this is done to demonstrate how it is possible to extend a CustomerData schema-defined Data class while simultaneously persisting it in the same database table. The FSG application does this with the Location and the classes that directly extend Location.

From the FSG application, the Booking team reuses the Persons and Places classes; to not do so cannot be justified.

The Constant class is reusable. Using the Constant class avoids hard-coding values that the business may want to adjust, control and maintain. The FSGSample application does not define a test-only data type to demonstrate how the Constant class is used. Instead, the FSGSample application uses the FSG-Sample-Work-TestConstants class itself to demonstrate how the FSG-Data-Constant class can be used. The Booking team needs to decide on an approach, either define a ConstantProps data type or use Application Settings or something in between.

The Booking application can potentially use the Feedback class after an event's conclusion. The class is used to capture from the customer how well FSG hosted the event.

The Booking team has concerns about the Feedback class. The FSGSample application does not demonstrate how to use the Feedback class. Presently, the Feedback class is abstract and contains only two properties. Other rule types such as sections or data transforms are missing. The Booking team also wonders if an Event Manager must populate the values after corresponding with the customer or if automated approach interfaces with a Pega Survey form.

The first stage in the Booking application involves quoting the price to a customer (Contact) to host an event at a certain location. The Booking application can reuse the data types owned by the FSGPricingTest application. There is a test-only data type named PricingDisplay that is defined by the FSGPricingTest application; this a clue that the Booking application must define its own PricingDisplay class.

2 Analyze the Booking team’s data model

FSG COE’s Constant class has properties such as Application, CaseUsage, Description, and DataType. The FSG COE’s FSGSample application contains two test cases related to its FSG-Data-Constant data type.

FSGSample’s TestAppConstantsLibrary case defines a D_FSGSampleConstants data page that sources a data transform named LoadConstantsForClass. The Booking team follows this example to define D_BookingConstantProps, D_HotelConstantProps, and D_WeatherConstantProps data pages.

The Booking team considered using categorizable Application Settings. The Booking team likes how the FSG COE’s solution supports dotted-path syntax to a property with a data type other than text.

For the Booking application specifically, the Booking team likes how the FSG COE modeled an example event quoting screen where a PricingDisplay data type was utilized. The Pricing component supports a PricingDisplayPage page name parameter within three data transforms: Work- WorkRecalculatePrices, @baseclass RecalculatePrices, and FSG-Data-Pricing Recalculate. The capability is there; the Booking Team might as well use it. Doing so saves the time and effort spent building that functionality themselves.

The Booking team has created a table like the one used to analyze and review the FSG COE’s data model. The Test-Only Data Types column is repurposed as a New Data Types where ownership is undecided column.

Application / Operator

Data Types Owned / Shared

New Data Types where ownership is undecided





BookingConstantProps, PricingDisplay

EventVenue  (concrete)


The Booking application quotes a customer’s event and the start and end dates. Subcases are spun off as required. Those subcases must not be spun off immediately; each waits until the appropriate time before the event.

Hotel / HotelProxy



HotelConstantProps, RoomsRequest


The Hotel application must communicate with a separate HotelProxy application for various reasons. The two applications are hosted on different databases. The HotelProxy application does not need access to code other than its own and FSG. The Hotel application needs access to FSGEmail.

Weather Forecast




Weather, Precipitation, Forecast


The Weather Forecast application aims to forecast the weather ahead of an event and then assist with whether preparation must occur due to a likely probability of rain.




ParkingConstantProps, ParkingLot, ParkingGarage


The Parking application aims to record the number of cars parked within each selected parking lot or garage close to an event venue’s location.




ShuttleConstantProps, ShuttleCompany, ShuttleVan, ShuttleTrip

Trip, Vehicle, Company

The Shuttle application aims to interact with shuttle companies to ensure expedient roundtrip transportation of event attendees to/from a Venue and another type of Location, for example, a Hotel or ParkingLocation. The Shuttle application can apply the “center out” principle since it would know the location that has the most urgent need to transport attendees. When a shuttle driver places requests on a tablet or smartphone, the Shuttle application directs the driver to the next best pickup location.

The Booking team’s BookEvent case needs to capture information about an event, such as its start and end date.  Hosting an event is core to FSG’s business model, yet the Booking application’s BookEvent case is the only place, so far, where an Event data type is used.

The Booking team can extend the COE-owned FSG-Data-Hotel class for its Hotel application but does not see an immediate need to do so.

The Booking team could extend the abstract FSG-Data-Feedback class to form a concrete FSG-Data-Feedback-EventVenue class. The Booking team recommends that FSG COE add a reference property to FSG-Data-Feedback. A report definition is defined within the -EventVenue class and performs a JOIN to FSG-Booking-Work-BookEvent and a JOIN to the BookEvent case.VenueGUID reference property to FSG-Data-Venue. The venue’s name might change since the last recording of the data. Defining a JOIN by using a name property is poor practice, and it is a data integrity violation. The venue's name can be recorded for historical reasons, but the property name should reflect that fact (for example, .HistoricalVenueName).

The Booking team’s extension of FSG-Data-Feedback can be incorporated into the FSGSample2 application to make other higher-layer development teams aware of what is possible. On FSG’s to-do list is developing a common way to send out a Pega Survey, receive the response, and then persist the response to the appropriate FSG-Data-Feedback able. 

The persisted data does not include a property where a Net Promoter Score has been converted to a category (promoter, passive, detractor). Doing so is also a data integrity violation. A report definition can utilize a custom three-input parameterized SQL Function to derive a category. The first parameter is populated using the raw promoter score property. The second and third parameters are the start and end of the category’s integer range (for example, 0 and 6 are the start and end of the “detractor” range). The custom SQL Function outputs 1 if the first parameter falls within the range. Otherwise, it outputs 0. The report definition aggregates the column using the SQL-standardized SUM() function.

The Hotel application and Hotel Proxy application communicate by using the RESTful Pega API. For various reasons such as application size, security, and ease of maintenance, the Hotel Proxy application is not built on the Hotel application. Either a RoomsRequest data type must be defined at the FSG COE level for both applications to inherit. The Hotel and Hotel Proxy applications must use another mechanism to share the class. However, it is necessary to share the REST integration classes that both applications use. The logical conclusion was to build a component to house the shared classes and related code.

The COE has not defined a set of data types related to weather forecasting. So, the Booking team must decide whether its Weather Forecast application owns those data types. Weather forecasting is not essential to FSG’s business model. Should other applications use the same weather forecasting data types but disregard weather preparation? What impact is there if the code to perform both are packaged together? The assumption is the weather forecasting code is lightweight.

The Parking application deals with different types of locations, such as a parking lot or garage. Attendees attending an event and wanting to park nearby would want to view their choices where to park on a map.

A Shuttle application can handle any location, whether a venue, hotel, or where cars are parked. This knowledge reinforces the notion that FSG COE must define a ParkingLocation class. The Booking team can directly inherit, or pattern inherit, that class as needed.

Finally, a Shuttle application requires data types that are related to shuttle trips. The Booking team can define its data types, but can other applications leverage an abstraction of those Data Types such as Trip, Vehicle, and Company?

3 Decide who owns undecided data types

Hosting an event is central to FSG’s line of business. The potential exists for other applications within FSG, such as Billing and Advertising, to use the same data type definition. As time goes on, other applications can add properties to FSG-Data-Event. A customer might contact a Booking Team member to ask how an event hosting is billed. Property-Read ABAC security can be applied to mask information that only Billing Team members should be allowed to view. The Booking team member can relay the information that the team member can see and then refer the customer to the Billing team if the customer wants detailed information.

A best practice is to standardize the definitions for Persons and Places across an enterprise. It makes sense that the FSG COE maintains the core definitions for classes that extend FSG-Data-Location. One reason for doing so is that Locations are stored in the same CustomerData schema table. When it is built, the Shuttle application must define a Trip as taking place in any two Locations regardless of the type of Location. Best to let the FSG COE take ownership of a ParkingLocation class.

The following table records the decisions made regarding the original set of undefined Data Types.


New data types where ownership is undecided

Should be owned by FSG COE?








Trip, Vehicle, Company


It is unknown when the Shuttle application is due for construction. The Booking team can certainly benefit if  FSG COE designs an abstract data model where any Vehicle with a limited capacity makes Trips between two Locations. In all likelihood, the Company that owns the Vehicle is not FSG. FSG does not want its employees to become full-time shuttle dispatchers. Instead, FSG wants to automate decision-making as much as possible. For example, the system runs by itself unattended. Over-reliance on stale data could lead to a “garbage in = garbage out” situation. The solution must be capable of accepting data in real-time and making decisions in real-time.

4 Complete the following assignments

Sketch out the data model for a shuttle application. The data model's definition here includes the data model for each case type, not just Data- class-extending data types.

For each data model class show:

  • The full class name and what class is extended
  • Whether the class is abstract or concrete
    • If concrete, the class shows the schema in which instances are persisted
  • Properties used for data relationships
    • Say embedded or, if a reference. add Ref to the property name
    • Say list if something is a list
  • Critical scalar properties
Note: An Interaction Diagram may help to gain a better perspective of the problem domain, especially the timing of inputs received by the system.

Available in the following mission:

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice