What's A Database Layer Good For?

I've spent the past couple of days refactoring my database schema. Nothing really major, just removing a categorization layer to make it less complex. It was determined that the extra layer would not be needed. I would have just left it but it wasn't my call. We also modified some table and field names to keep things consistent.
My manager seemed rather shocked that this change would entail changes in the database layer all the way to the UI. He seemed to think that having a database code layer would protect you from these changes and isolate the code that needs to be modified.
But in fact a database layer does not necessarily do this. If there is a new field, for example, that a user needs to supply data for, or in this case an entire table that does not need to be supported. The field needs to be added to the UI and then it needs to be processed and passed to the database layer. Therefore all aspects of the code that deal with this data need to be modified.
A database layer IS very useful and should be used when dealing with anything but very simple database table structures. It gives you the ability to isolate database functionality by hiding the database specific stuff from the rest of your code. These include things like connecting to the database, transaction handling, mapping object data to table fields, and other functions that deal directly with the database. Most of these changes can be easily modified without impacting other sections of your code.
Just make sure that everyone on your team, especially managers and project planners understand what you mean when you say you are implementing a Database Layer and that they know how certain changes to the database will impact the code.