The truth is that, for most development teams, there is only one instance of the development database, and every build is an "integrated" deployment, wether is should be or not.

I typically have a local instance of the database just to confirm my latest scripts "compile", and at the end of the day I'll then deploy to a tream accessible version of the database with an alternate name. For example, the mainline database may be BILLING and the unit test database is BILLING02. The app developers can simply change their database context to perform their own integrated unit test, and then they'll let me know when I can sync changes into the mainline database.

At least for me, table schemas and reference data typically doesn't change that much after the first couple of weeks, so continuous integration for those is not much of an issue. Things like stored procedures, views, and indexes change more frequently, perhaps daily, but they can be easily dropped or rolled back to prior version, just like application modules.