On the face of it, there might be some unnecessary coupling. To add a new application, you (add a row to the database, and) then have to edit the code in multiple places: first, you have to add a new class that supports the interface, and then second, you have to edit the ApplicationFactory to link the application name string to the new class.
A more generic solution might require only adding (the db row and) the new class. This might rely on a naming convention and reflection to look up the appropriate class by name. Alternately, one could have an external configuration file or other entry in the database that associates application names with class names.
Under such schemes, the class could be moved into an externally loaded DLL, and new app-specific DLLs could be created without editing the main application containing the factory.
Still, to add a new app, one has to add to the database and also distribute the DLL. Distributing the DLL may offer nothing over distributing a new copy of the factory containing application. On the other hand, such looser coupling may allow different authors to contribute (develop, test, and distribute) code DLLs for new apps without editing the main source code.