When a big database is shared between many applications, it is sometimes hard to understand who is using what and what would happen if the database schema changes. On the other hand, when a database is big and complex, changing the data structure is a constant process: business requirements do change, new features got developed, and refactoring of the database itself for the sake of normalization is quite usual.

In that case, it makes sense to build the whole system using layered architecture. The physical data structure is located at the first layer. Applications do not access it directly.

Moving upward from the bottom, the second layer contains structures that abstract logical entities from their physical implementation. These structures play the role of data abstraction interfaces. There are several ways to implement them. They can be created in the database as functions. In that case, applications will work with the data by invoking them. Another approach is using updatable views. In that case, applications can access the logical entities with conventional SQL statements.
Additionally, this interface can be implemented outside the database as a lightweight service processing the requests of high-level systems, performing queries, and making changes to the database. Each approach has its own benefits and drawbacks, for example:

• Database functions keep the database abstraction logic in the database and are easy to test, but they hide the logical model and could be difficult to be integrated with high level applications;
• Updatable views expose the relational model (although they do not have foreign keys) but implementation of logic that goes beyond simple INSERT, UPDATE or DELETE functions can be very complex and counter-intuitive;
• Micro-services working outside of the database are more difficult to implement and test, but could provide additional functionally, like providing access to the using HTTP REST API.

At the top layer are the applications that implement business logic. They do not care about the physical structure of the data and interact with the database through the data abstraction interfaces.

This approach reduces the number of agents that access the physical data structures. It makes it easier to see how the database is used or can be used. The database documentation should contain the specification of these interfaces. So the database developer, when working on refactoring the database schema, should only make sure that the interfaces follow the specification, and until they do, the rest of the database is free to change.

The existence of these interfaces makes its easier to develop unit tests: it is clear what to test and how, as the specification is given. With test-driven development, the tests themselves will play the role of the interface specification.