What are the implementation approaches for mapping between Logical and Physical data models?

The preferred pattern for mapping between an instance of a Logical Data Model (*-Data-* class) and Physical Data Model (*-Int-* class) is to encapsulate Request and Response Data Transforms with the operation (e.g. Report Definition, Connector, Robotic Automation) that looks up the instance(s) from (or saves them to) their System of Record. 

The Data Page rule is purpose-built to accomplish this. Ideally there is:

• A Data Transform that maps a single Logical Data Model instance to a single Physical Data Model instance. This is typically used as a Request Data Transform (for POST/PUT operations in the case of REST); 
• A Data Transform that maps a single Physical Data Model instance to a single Logical Data Model instance. This is typically used as a Response Data Transform;
• For List-structured Data Pages, their Response Data Transform will typically iterate over a Page List in the *-Int-* class, mapping each instance to .pxResults. In an ideal world, the Logical/Physical mapping of each instance in the list corresponds to operations that map single instances, so the single-instance Response Data Transform from the previous point may be re-usable within the iteration to standardize how the mapping is accomplished.

Where the Pega database, Connectors and Robotic Automations are not the System of Record, an Activity is likely needed to source and save the data. However the above philosophy of the Request/Response Data Transform mapping between an instance of a *-Data-* class and an instance of a *-Int-* class should be retained.

Discussion on this topic was sought from the LSA Data Excellence (Pega 8.4) webinar conducted in July 2020. The webinar and its full set of discussions that arose from it are available at LSA Data Excellence: Webinar, Questions & Answers.