Back about 30 years ago, Nicklaus Wirth (then a MAJOR figure in programming circles) ascribed some 90% of all programming problems to poor data analysis and/or layout.
The most important part of a database is that its data supports its purpose and functionality.
The interfaces are important but if the underlying structure is crud, the DB will be crud. Pretty crud, but crud.
For simple databases, the functionality mapping is easy. When you get to complex situations, you run into the problem of data analysis and mapping.
What do I mean by mapping? Simply this: A modern business database can be looked at as a MODEL of the real business processes it supports. If your business model and your database model do not closely correspond, you are in a world of hurt before you build the first form.
I.e. if your company sells product to customers and generates a lot of repeat business, plus needs to know what your customers have tended to purchase in the past, you need both a customer table and an inventory or product table. Plus a history table that records the combination of purchases per customer.
If your company is a real-estate company, your issues will be sales leads, properties, offers, pending sales, etc. Again, you will need tables corresponding to these entities.
If you are tracking students in a small school, you need student tables, classes, teachers, rooms, etc. - and tables to match them all. Because it is all about the data model.
