Sometimes this may be hard. With internal Line-Of-Business (LOB) applications, the prevailing view of the business is often times that the DATA is the primary asset, where as the software is somewhat expendable. That is, for businesses, data is everything.
In my opinion, this is wrong.
In reality the asset is the company's ability to INTERACT with data. To view it, to manipulate it, and to make decisions based on it.
This means that even though they may place a high value on the data, what they are actually valuing is the software that you are writing. This means I would focus most of your effort on building an effective user experience, rather than on "designing the perfect database". The database is really just a tool that enables you to deliver on a user experience.
The key feature of relational data models is data and access path independance. You can add columns, change keys, introduce or remove indexes, etc, while having zero impact (or close to zero) on the applications that use it.
This makes the database structure extremely pliable. Easy to change.
Trying to design the database to "be flexible for the future" or to "optimize performance" is mostly a wasted effort. Changing the structure of the database will have a relatively small impact on your system.
You also can't predict how the database will scale until you run into the scenarios where you need it to scale. Your best bet is to wait until you hit performance issues. and then address them specifically.
Making changes to the user experience of your app, however, is usually more expensive. UI work is time consuming, and usually takes a while to get right.
So, my recommendation is :
- Just quickly produce a crappy DB design
- React to the actual performance scenarios you encounter
- Focus your efforts on user experience, not on the database
