I'd forget about mocking an entire database. If you adopt the Data Access Object (DAO) to abstract and encapsulate access to the database, such an object would be a convenient candidate for a
test double (possibly using EasyMock). Eventually you'll want to unit test the DAO itself, and then it would make sense to utilize some sort of ligthweight in-memory database, instead of the heavyweight (network accessed) production database server, and employ a library like DbUnit. That's as far as I'd take it for the purpose of unit testing. Eventually, though, you'll want to integrate every system component and test against the real thing, but that's well beyond the scope of unit testing.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
