I'm mostly in line with moojjoo. I can't imagine even starting on designing a database without having a clear idea of what the user wants. Sure, figuring out user's needs starts with interviewing them, but the next step in designing an application is to show the users a prototype, not design a database. A prototype provides the users with enough information that they can buy-off on the project. The users can NOT buy off on a database design or a simple printed list of requirements. The beauty is that once you have a prototype, knowing the correct database to build should be a snap.

However, I also can't imagine being able to create a decent prototype without thoroughly understanding relational databases and seeing in your mind what the tables and databases would look like to support the screens included in the prototype. I often discard several prototype designs because I know they will not work well with relational tables.

In other words: I don't see application design as a complete either-or process. The person designing the application needs to understand both the business needs and good database design practices in order to come up with a good final product. They are intertwined, so why would you develop one completely independently of the other? That would be a mistake.

Then again, I do both functions. It's not a me-them situation at my agency. Maybe it is easier for me.