Break the application into two parts in your mind:
1) Part that talks to database
2) Everything else

To test 1, write tests that call the functions that deal directly with
the database.  If there's any complex logic in generating the query or
anything like that, test it.  These tests will also let you know
immediately if something changes in the database (e.g., someone else's
project requires a database refactoring).

To test 2, use mock objects.  Basically, your code does something that
expects a database call with parameters x and y returning z.  The mock
object asserts that the parameters are x and y, and returns z, without
talking to the actual database.

Where these unit tests come in really handy is you can get at the
low-level stuff a lot easier than having to start up your whole
application and run it.

At my last company, we also implemented "database consistency check"
unit tests - basically these would run a series of queries with
expected results and confirm.  Things that were more complicated than
could be conveniently put into triggers or elsewhere in the database.
This gave us a 'trip wire' that let us know if some process was
entering subtly wrong data, and we'd catch it soon enough to fix it.

Michael