Also, what makes you say that database as an integration layer should always be avoided?
15 years of writing software. Every time I've had to deal with a shared database it has caused problems, and every time I've built a system avoiding that antipattern it has worked much better.
But it's not just me, here's some references:
Enterprise Integration Anti-Patterns # - The Shared Database: http://ianfnelson.com/archives/2010/11/08/shared-database/
Database as an IPC Antipattern (which is a subset of the broader shared database antipattern): http://en.wikipedia.org/wiki/Database-as-IPC
There is a good reason why SOA was created, and why exposing applications' data via defined interfaces is very popular.
Ian F Nelson's blog post is about a DB that is tightly-coupled to the app: “my” application is using NHibernate as an ORM layer, so until this invasion we have been able to perform database schema refactorings with relative impunity.
Conventionally, RDB schemas are designed in terms of the data itself, not a particular app. In the Enterprise (where RDB are most used), data typically outlives different applications for the same task over decades, often written in different languages. Typically, the data needs also to be accessed by several different applications.
But here I'm talking about logical back-compatibility (surviving version changes) - the blog makes good points about "caching and application-level security". Where those vary with the application, it makes sense to separate them from the DB. But like Database-as-IPC, they are closer to the transport layer than to logical structure.
(I should have included this link in my other reply on problems with updating aggregated queries).