Greenfield data modeling
Proactive greenfield data modeling
How data model design is approached depends on whether a pre-existing Foundation application data model exists or whether the application being developed has no prior work, hence no constraints. A name for the latter situation is “greenfield development”. How to work with a Foundation application data model is discussed in the module that follows. The discussion of proactive greenfield data model development begins in this module with some fundamentals.
An often-used technique for developing an object model is to parse a document while extracting nouns and verbs. The nouns would be analyzed to determine suitability as an object and, if so, is that object a specialization of a more generic object. For example, a document might mention a Car which is a type of Automobile or Vehicle. The verbs found in the document could be used for various purposes such as identifying possible cases, processes or steps within a case depending on the granularity of the document.
Avoid developing a data model in isolation. Perhaps a solution already exists. An example is when the price for a certain quantity of items purchased or consumed must be determined. The price per item can remain constant, i.e., unit pricing; or the price per item decrease as quantity increases, i.e., volume pricing; or the price can vary from range-to-range until the quantity is consumed, i.e., tiered pricing. In this example, a data Model that supports multiple pricing strategies would be, in the long run, the most beneficial.
The sample FSG Event Booking application contains an FSG-Data-Pricing class. Instead of maintaining prices per item within the database, preferable for a large number of items, this example maintains item prices within Decision Tables since the number of items is small. If prices were to change over time, the Decision Tables could be circumstanced using an “As-of-date” DateTime property. If prices were kept in the database, an AsOfDate property would need to be added as well as a QtyTo property to support the definition of a quantity range.
Being proactive is Key
Ideally, before any greenfield application development takes place within APP Studio, an LSA would be made aware of the application’s nature and goals. The LSA would analyze this information to derive a rough idea of the initial data model and case structure that APP Studio developers would leverage.
The next step is for the LSA to model this information at appropriate levels. The most abstract information such as Data-Vehicle would be placed at the lowest layer. Specializations of that class could also be made within the same layer such as Data-Vehicle-Car. The LSA must also decide whether the class should possess an Organization prefix, or when specific to a Division, give it an Org-Div- prefix.
If the potential exists for a Data instance to be obtained through Integration, which includes querying data stored locally, Data Pages should be defined. When APP Studio is used, a Data type will be created in the CustomerData schema. In DEV Studio it is possible to select the PegaDATA schema when a local data source is added to a Data type. Database table within the CustomerData schema do not contain “Pega” columns such as pzInsKey or pzPvStream, a.k.a., the BLOB.
The decision whether a Data class would always be used as a Field Group (Page) and never persisted on it own is important. Note the differences below in how that data is persisted if required for reporting.
| Data always embedded | Data persisted outside a BLOB |
|
If an embedded Page List property is optimized, a Rule-Declare-Index, Index class, Index table, Index class property, and index table column are generated.
|
A Field Group List (Page List) property can be defined that references a List Data Page where data is stored external to the object, i.e., not within the object’s BLOB.
An example in the solution provided for this mission is the FSG-Data-Pricing data type and the FSG-Booking-Work-BookEvent case’s .Pricing (Field Group List (PageList) that references D_PricingList passing it the pzInsKey of the BookEvent case as Ref parameter value.
A second example is FSG-Data-Address data type and the FSG-Data-Location class’s .Addresses Field Group List (Page List) property. |
|
If an embedded Page property is optimized, a column is created in the database table and mentioned in the Class rule’s Mapping tab.
|
A Field Group (Page) property can be defined that references a non-List Data Page where data is stored external to the object, i.e., not within the object’s BLOB.
The Field Group (Page) property only needs to contain the key(s) to a Lookup Data Page. An example in the solution provided in this mission is FSG-Booking-Work-RoomsRequest .Hotel where .Hotel.pyGUID is passed as the pyGUID parameter to D_Hotel. |
Note that the RoomsRequest case’s .Hotel property was overridden by the production Booking application.
Within the component Hotel application’s the RoomsRequest case’s .Hotel property is defined as a normal Field Group (page). This was done to support data capture and persistence to facilitate testing performed against the Hotel case component. The Booking application’s purpose is to book events, not define hotel instances. The Booking application’s RoomsRequest should only perform an FSG-Data-Hotel Lookup using a value it originally obtained from .RoomsRequest.HotelGUID within the InitFromRoomsRequest Hotel subcase spin-off data transform.
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?