I agree with Pat, but also want to point out Forms and reports and graphs aren't the place to start. The first part of any database is properly structuring the tables. That's what you need to work on, then you start on your forms.
If you need help with that, post in the Tables section of this forum.
Table design is definitely the right place to spend a lot of time thinking and planning and failure to properly normalize your table structure is the biggest problem for database design.
But I also think that table design can be informed by expected outputs, such as reports and graphs and such.
If a client wants to produce a chart showing sales, then that tells me I need to store sales data. If a client wants to report average fish length with 95% confidence limits, by date or by month or by year, then that tells me I need to store fish lengths and dates for individual fishes rather than just summary group fish length data so that the appropriate statistics can later be calculated for whatever interval is required. The expected level of reporting detail can help inform you how detailed your data model/table structure needs to be.
The worst thing would be to create a wonderful functional database, only to have a client later wonder why they can't produce a report breaking down their product sales by color, when you don't even store product color in your sales data tables.
form.jpg
report..jpg
