It depends what is the database used for.
In many applications (web apps or not), the database is intimately tied to that application because it serves as the persistent store for it. Then the database is conceptually part of the application so is designed together (and you presume that no other program would significantly access or update that database). BTW, persistence could be achieved by other means than a database, e.g. plain textual files, binary files (notably indexed files à la GDBM), git (or other VCS) repositories, directories or file trees, raw disk partitions, dedicated hardware (e.g. flash), remote file systems, checkpointing techniques. For databases designed for and with one application, you should care about common retrieval & update patterns and design the database schema (and indexing!) with them in mind.
In some situations the database is by itself a major and independent asset, and is designed a priori to be used by several different applications (and even future ones). Then it should be designed independently (and much more carefully).
In particular some web apps are just web interfaces to existing databases.
In many cases (think of some wiki as an example), the data is more important and more valuable than the application(s) using it. You may care about how to make it future proof and be able to evolve it easily (e.g. by using or defining textual & versatile -preferably standardized and documented- formats to backup and restore it).
I've realized that the (PROPER) design of a database is no small task...
Read also about NoSQL, document-oriented databases, key-value databases, knowledge management, knowledge representation and reasoning, ontologies, expert systems, business rules approach, ERP, CMS. Perhaps consider using REDIS, MongoDB, etc..