I think I can offer a slightly different opinion.
I think a database setup should always be data driven. Identify all the data/attributes your system needs to manage. (your knowledge of the business processes and concepts of the forms should guide you here, but it isn't at all about the forms per se. (IMO)). The hard bit is knowing everything you need, and not taking things for granted. Do not let the concept of the way the user thinks it should work deflect you from this analysis. It really isn't (or shouldn't be) about the presentation of the data at all. The presentation can be achieved by manipulating the data, rather than the other way round.
Often though the user will take things for granted that the developer needs to know. The data analysis really has to manage every possible nuance. Even if something occurs once a year, you need to be able to handle it.
Think about price management. You can have generic price lists, quantity breaks, special rates for certain customers, limited special offers, clearance deals, special rates for "sets" of products. You may have complicated discounts applied at order level, or some other level.The data structure needs to be able to deal with all the eventualities that might arise.
next analyse the data/attributes into normalised tables. (again, the same thoughts in respect of the processes and forms, but not so much, as you know which data you need to process)
now you should be able to develop the forms, reports and other database objects that you need to manage the data. The correct data analyse will ensure this development takes place in a harmonious way.
As you begin to develop, it may be become clear that your data analysis was incomplete, or could be improved. It is better to fix this, and rework, then continue with a sub-optimal data analysis.
That's my thoughts, anyway.