Design for Flexible Access Using Views
You should design your applications to always access the data warehouse through views rather than directly accessing base tables. Administrators sometimes avoid application designs that access the database through views because of a perceived performance penalty. While this can be true for delete, insert, and update operations, it is rarely true for access operations, and then only in exceptionally rare cases. In fact, view projections of their underlying base tables can minimize the use of spool space by joins by reducing the number of columns that must be redistributed to make the join. Furthermore, you can more readily control locking for access through careful view design, and so minimize the complexity of applications that access the database through those views.
As a general rule, the best practice is to design applications to access the database only through views rather than accessing base tables directly.
Besides providing you with the ability to provide pseudo‑denormalized access for enhanced usability (see “Denormalized Views Versus Physical Denormalization of the Database Schema” on page 115), views also provide a degree of data independence that permits you to make changes either to your applications or to the physical database those applications access without having to worry about rewriting application software. Views can also provide a coarse level of schema versioning that is otherwise not available (see “Design For Decision Support and Tactical Analysis” on page 120).
The list of design advantages that views present for database access does not mean that it is generally advisable to perform delete, insert, or update operations through views. As a general rule, the best practice is to design applications that update the database to access base tables directly rather than through views.