Pattern: Physical Views

 

Abstract

Physical Views is a pattern that shows how to encapsulate a physical database so that it can be easily accessed and optimized without affecting upper layers of software.

Context

You have decided to use the Relational Database Access Layer. You use Hierarchical Views as interface to the application kernel and you have chosen, not to incorporate database access into the ConreteViews.

Problem

How do you provide an easy-to-use interface to your physical database tables?

Forces

Solution

Encapsulate every table and every view with a ConcretePhysicalView. Use these classes to encapsulate Overflow Tables and other database optimization techniques. To provide a uniform interface derive ConcretePhysicalViews from PhysicalViews.

ConcretePhysicalView use SQL-statements to store their instance data. The main difference compared to Hierarchical Views (alias ConcreteViews) is that they shield a single physical table or view instead of multiple physical structures.

Structure

Example Resolved

Figure 7 shows the DAG-definitions of two Physical Views that we need for our invoice example. They correspond to the physical database structure but resolve the Overflow Table (see Figure 2). To simplify the OrderPhysicalView, it should grant update access only to the Order and OrderItem data, but not to the article information. There are other Physical Views to change the Article table.

Figure 7 :           DAG definitions for two ConcretePhysicalViews. Note that the OrderPhysicalView encapsulates the Order table with its overflow table OrderItemOverflow, while CustomerPhysicalView encapsulates the Customer table alone. See Figure 2 for the physical table structure.

Consequences

Implementation

Variants

If you have a hard-wired connection between ConcreteViews and ConcretePhysicalViews, you may implement ConcretePhysicalViews as methods of the ConcreteViews. However, this solution is less flexible since you are not able to use the same ConcretePhysicalView twice.

You may also use Physical Views to encapsulate non-SQL databases and file systems such as ADABAS, IMS-DB, CODASYL, and VSAM. As we have mentioned before, you may use this variant to build relational applications on top of legacy databases.

Related Patterns

For a further discussion of database optimization see: The Overflow Table pattern describes in detail, how to partially merge tables. Controlled Redundancy contains a discussion on when to grant write access. Narrow View gives hints on Physical Views to select data.