The idea of unit testing is to enable completely modular code development. You probably already know that modular code is the way to go, as it encourages reusable and clearly focused designs.
If you attempt to test an entire system as a whole, then many different parts have a possibility of failing. In any reasonably sized system, it would be nearly impossible to account for every possible problem. Also, when problems are found, it may be difficult (or nearly impossible) to locate the responsible code.
However, if different portions of your code are completely separated from other portions (i.e. they don't rely on each other), then you can use unit testing to test a subset of your larger system. It is much easier to detect bugs in a small amount of code, as opposed to a large amount.
In the example you presented, there are two super-portions of your code: the part that retrieves data from a database; and the part that processes that data. If you attempted to test the two together, your test could become riddled with failures because of the attempted database access. There are numerous networking and other I/O issues that could come up when reading the database. Especially in extreme cases, this can make it very difficult to test the processing portion of your code. Similarly, there could be bugs in the processing code which, for some reason, are not clearly located within that part of the code.
The solution is to use unit testing. Rather than test the retrieval and processing together, you separate them. You can feed any data you want to the processing portion to see if it functions correctly. If something does go wrong, you know that the problem is a processing issue, and not related to reading the database. Similarly, you can make simple tests to ensure that you are attempting to access that database in a correct manner. Any problems that arise this time are sure to be related to the database reading.
So unit testing is really invaluable in testing code for robustness. Also, it encourages a design pattern which is greatly encourage. Specifically, developers wising to use unit tests must design in such a way that their code can be separated into modular units. For example, a function that relies heavily on global mutable state is inherently less unit-testable than a function which only relies on it arguments to produce a result.
One thing I forgot to mention is that unit tests are not an afterthought. They are intended to be an integral part of the development process, so that small pieces of code are guaranteed to be robust. This increases the robustness of the code throughout development. As each new portion is written, it can be immediately unit tested to discover potential flaws. Thus, robust foundation is laid upon which layers of robust code may be written. The end result is a final product is more likely to have a much higher level of correctedness than an equivalent product which is tested after the development process. Also, the time spent testing is generally reduced.