Regardless of whether it's a web application, mobile app, or internal BI reporting system - don't let the front-end application interface with the database directly. Don't even let them have a database login. All data access should be abstracted through a service-oriented architecture. Not having functional dependencies between the front-end and back-end means the database engineers can refactor the data model or even migrate to a different database platform with minimal effort and conflict.
I don't understand why you need the service-oriented architecture - it only seems to add complexity.
If you have a mechanism for analysing application code to discover database dependencies then any changes to the database will be immediately apparent.
If you have the SOA then you have to analyse both the dependencies between the application and the SOA and between the SOA and the database. This just looks like a lot of extra complexity, extra effort and a much greater possibility of error.
By introducing an SOA you throw away the flexibility of access which is the whole point of having a SQL-DBMS rather than a set of subroutines (which is what an SOA is).
If ever the database has to change or it is replaced with a different data storage of some kind, that necessitates bringing the application down for long periods of time.
There is no reason why changing the database structure should lead to downtime if you are doing change and version control properly. Changing the data storage certainly won't - the whole point of an RDBMS is that you only interact with the logical layer. The vendor of the DBMS could completely change the storage mechanism of their RDBMS without any impact on existing applications. That's one of the many reasons that SQL-DBMSs have become dominant and will continue so for the long foreseeable future.