I've had the luxury of designing several medium-complexity databases, all used in businesses, with various front ends including web, Access, and C#.
Usually, I have sat down and worked out the database schema in advance. This always made the most sense to me. However, there has not been a single case where I did not end up making changes, adding new tables, or living with aspects that bothered me and were basically too late to fix.
I don't think the cure is to write the code first. And I don't think the problem is "insufficient business requirements" or at least, not one that could have been fully solved. The users don't know what they need and I don't have the power to make them think harder or be smarter or more aware or answer my questions better. Or they argue and I get ordered to do something a certain way.
The systems I build are usually in new areas that no one has gone into before. I don't have the buy-in from the organization, the resources, or the tools to do the kind of job a development team of top-flight design professionals could who got paid as a team ten times what I make to build things in twice the time.
I'm GOOD at what I do. But there's only one of me doing it in an environment that "doesn't do development."
All that said, I'm getting better at discovering business rules. And I know of a kind of third option (which I learned from an Agile Development Practices conference):
Before you design the database, and before writing any code, draw crude screens showing how the application will work. They must be hand drawn to prevent anyone from commenting on font or size or dimensions--you want function only.
With transparencies and paper pieces you can swap in and out, have one person be the computer, two be non-technical subject-matter-expert users (two so they talk out loud) and one person there as a facilitator who takes notes and draws out the users about their thought processes and confusions. The users "click" and drag and write in boxes, the "computer" updates the screen, and everyone gets to experience the design. You will learn things you could not have otherwise learned until far into the development process.
Perhaps I am contradicting myself--maybe it IS better requirements discovery. But the idea is to design the application first, without writing any code. I have started doing this in small scale, and it's working! Despite the problems in my environment, it's helping me get the database designed better from the start. I learn that a column must move into a new parent table because there are multiple types. I learn that the worklist has to have standing orders that don't come from the integrated order system. I learn all sorts of things!
In my opinion, this is a huge win.