Unanswered: db model vs application data model (using JPA)
I'm not sure if this forum is considered appropriate for the following matter. Let me know if it isn't.
I'm working on an application which gets its data partially form a db (Derby in combination with JPA) and partially from manual input. Lets call the application a scenario editor. The application has to produce an XML file which is used for loading the created scenario into the application and saving the created scenario for future alterations (so basically the application file format). The XML file is also used to generate (by the same application using XSLT) a set of files which can be used by a different application.
To give you an impression of the required XML stucture:
From an application data model perspective I was thinking about creating a class for each element. Besides the fact that it seems the logical thing to do (to me), it would also allow me to use XStream to easily produce the XML.
Each 'mode', 'state' and 'schedule' element has a specific set of child elements, implemented as class properties in Java. These properties is where the problem lies.
The db will contain an amount of devices to select from in the application. The user can change the device properties after one is selected from the db. Example:
WEAPON(weapon_id, name, max_range, rounds, ...)
In this case, 'name' should be a property of the 'device' class, 'max_range' a property of the 'mode' class and 'rounds' a property of the 'state' class.
With JPA, however, you would normally create a class for a complete table (and with helper classes when dealing with compound keys). When sticking to this, it won't be possible to get the initial application data model in terms of a 'device' class containing a 'mode' class, etc. You would just get one 'device' class containing all the properties available as columns in the db.
Because I'm new to using JPA I don't quite grasp the possibillities and difficulties that might occur when not going for the 'one class for one table' structure.
One option would be to change the db model and split the WEAPON table up into a WEAPON table with 1-1 relations to a separate MODE, STATE and SCHEDULE tables. This, however, completely goes against the whole relational principle (and mine).
The questions are:
Is it possible to split up the classes instead of using one class for one table?
Is it recommended to do so?
For those who have experience with this: what can I expect in terms of implementation problems?