Before I get to the gist of your question, let me point out that the structure you provided has certain problems (which you have noticed, but let me elaborate a bit):
This design uses dependency inversion to make the client (Application) and a concrete service (a DB gateway - SQL, Test) independent of each other, by making each depend on the IDatabase interface. However, the fact that Application creates the concrete service makes it dependent on the concrete type, which to some extent messes up the whole setup. The degree to which this is actually a problem depends on thinks like: what the client code does, developer discipline (in terms of isolating the coupling to a well defined piece of the Application class), techniques used (e.g. the picture changes a bit if the concrete service is instantiated through reflection), how you want to organize your code into libraries, etc.
Relying just on the traditional OO techniques, the way to make sure that client code has no knowledge of the concrete types that implement IDatabase is to introduce a third piece of code that knows about all of these types, and is therefore able to hook them up (and this, in turn, enables these types to stay decoupled). In approaches that use dependency injection, this third piece of code will usually be the composition root (more or less, the entry point of the application).
One way to change the original class diagram you posted so that it follows this structure is to split the Application class into two parts. One part will be the composition root (the ting that does creating and hooking up, and runs the other part, or otherwise enables it to run). The other part will be the client code that uses IDatabase.
This enables you to test this other part (the actual business logic contained in the client code) in isolation (e.g., unit testing) by supplying a concrete database instance in the test code via constructor injection.
The way I described it so far, when it comes to creating concrete instances, the composition root essentially uses "code as configuration", but if you want to (or need to), you can make it truly configurable by having it read a config file and make its decisions based on that data, or you can rely on a DI container to manage the configuration, dependency injection and object lifecycle for you.