What you described is exactly the architecture of the application I am working on now. There are pros and cons to this approach.
The Pros:
It's good to keep your data access outside your web app. That's just good design. Doing it this way enforces that, your web app doesn't have any database code in it.
The web service doesn't need to run on the same machine as the web application. This is good from both a performance and security standpoint. If you web server is busy, you can move the web services to a different machine to spread the work around. If you don't need other external customers to use your web service, you can run it on a machine that isn't directly connected to the internet, so there is no way an outsider can call your web services directly.
The Cons:
There is some overhead involved in calling a web service, particularly if you are returning large datasets from the database. You can return DataSets from a web service (some people claim that you shouldn't, because DataSet is a Microsoft specific data type. It's difficult to work with a DataSet as return type from a language such as Java). But if you do return a DataSet (we do in our app), they are serialized into XML data to send across the web service boundary, then deserialized back into a dataset on the other end. The XML overhead can get expensive, both in terms of memory and CPU for large datasets.
Security: if you do run the web service on the same machine as the web application, then you do need to worry about security. You don't want random strangers discovering your web service and calling it directly, so you need a way to do authentication. (Web services do have good support for that).
One approach that might be worth considering is to put all your database logic in a DLL rather than a web service. Then you write the web service as a very skinny wrapper around this DLL. For most web service calls, you would just do something like: return DataProvider.SomeFunction(param1, param2, etc).
The advantage of that is that the DLL can be used in any project. You could even construct your web app in such a way that it could use the web service or the DLL, based on a single configuration setting (it would take a fairly small amount of work to do this.)
Also, FYI, in our app there is no SQL in our web service. All the SQL is in packages in the oracle DB. The web service is really just a big wrapper around the database stored sprocs.
HTH.