Focus on the needs of the Application first (i.e. the Client's business data model). Design the Classes and Data Model that the Application needs to the extent of having a working end-to-end Application that use Data Pages that represent the points where your Application will interact with the Systems of Record. 

Some of those Data Types will need their instances persisted for later retrieval; whereas some Data Types will be used only to compose other more complex Data Types or Case Types, and their instances are persisted as part of the composing type. For those Data Types whose instances need to be persisted, work with your Client's Architects to confirm the appropriate System of Record for instances of that data. Sometimes it will be Pega, but often it won't be. 

Where the System of Record is Pega, then a Database Table is needed (if not more than one). If how the data is persisted (the Physical Data Model) varies from how the application expects the data (the Logical Data Model), then implement additional Classes to reflect the Physical Data Model needed.

For example, a "Customer" Logical Data Model Class may be composed of a Page List of Addresses, but the Physical Data Model may benefit from persisting this relationally - that is, having distinct tables for Customer and Address. Data Pages would take responsibility for enabling the application to ask for a "Customer (and its Addresses)" to be retrieved as a single business object, despite the data being spread over multiple tables in the Pega System of Record.

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.