When a big database is shared between many applications, it's sometimes hard to understand which of them is using which schema objects, 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 change, new features get developed, and refactoring the database itself for the sake of normalization is quite normal.
In that case, it makes sense to build the whole system using a layered architecture. The physical data structure is located in the first layer. Applications do not access it directly.
Moving upward from the bottom, the second layer contains components that abstract logical entities from their physical implementation. These structures play the role of data-abstraction interfaces. There are several ways to implement...
