I know that many shops don't work this way, but when I have designed from a "data driven" methodology (I know this is an old term, but I have been in the indust

I know that many shops don't work this way, but when I have designed from a "data driven" methodology (I know this is an old term, but I have been in the industry since 1984), I always started with the question - what are the things we are capturing data about? Usually by starting with the "objects" if you will, I would actually end up with a close to 3rd normal form data design, but still close to the object level as well. I have also been a big proponent of the developers having complete access to the database and for them along with the architect to design out the triggers/stored procedures - mainly to make sure the data maintained a certain amount of integrity - especially if the system was going to be designed to allow end users to update and add with tools such as Access or Excel. I have seen many issues - especially with large projects where there are more than a few developers, with the data integrity rules only being in code close to the client as you ultimately end up with two or more pieces of code handling the integrity differently and one or more of them being wrong.