sometimes the database design can fall naturally from the things you want to model.
For example, if starting to design a form, the fields that show up on the form, would be indicative of the fields the table might have. a select picker or drop down list might refer to a list of things looked up from a second table.
So in that sense, starting from the application to define the 'model' and moving downwards to create the database objects and structure becomes more clear.
Sometimes I like to design a UML kind of diagram to articulate the relationships, and this design usually directly serves as the schematic for building the SQL for creating the database objects and the Java beans to model the object in the application, and then the details of plumbing these together with what ever mapping framework and API of the day usually follow.
But usually, I find in all these cases I need something to do, a problem to solve. Practical experience that comes with using a system you built over a period of time and realizing that some patterns are not as performance optimal when large amounts of data are used is also invaluable.
Error: Keyboard not attached. Press F1 to continue.