Pattern: Relational Database Access Layer 


The Relational Database Access Layer Pattern Language provides a uniform mechanism for efficient database accesses and encapsulation of database system aspects. The pattern applies as a persistence mechanism for data abstraction modules and NOT as a full fledged object/relational access layer, but serves only as the Tuple Layer part of it


You are writing a business information system like the preceding order processing system. The relational calculus is an appropriate representation of the domain logic. The resulting data model is simple and uses inheritance sparingly. The effort of mapping the relational model to an object-oriented representation is high compared to the gains.


How do you access the relational database?


The forces influencing the design of a Relational Database Access Layer have been described above in more detail. They are:


Use a layered architecture consisting of two layers. The Logical Access Layer provides the stable application kernel’s interface, while the Physical Access Layer accesses the database system. The latter may adapt to changing performance needs. Use a Query Broker to decouple both layers.


Figure 4 shows the classes of the Relational Database Access Layer. The Logical Access Layer provides classes for caching and transaction management. The Physical Access Layer represents the interface to the database system. The latter splits into the physical views, representing data access, and the Database class, which encapsulates administrative calls. Hardwired logic or - even better - a Query Broker mediates between the logical and the physical access layer.




Figure 4 :           The structure of the Relational Database Access Layer framework. The Client accesses only classes of the Logical Access Layer, which, in turn, use the Physical Access Layer to connect to the database.







Dynamic Behavior

We shall discuss dynamic behavior with the patterns that implement the different aspects of the framework.


When using the pattern you will come across the consequences listed in the „General Consequences“ Section on page 7.



Related Patterns

The pattern is an application of Layers [Bus+96, pp. 31]. The View Factory is an application of the Abstract Constructor [Lan96]

[Bro+96] and [Col+96] describe how to extend the pattern to offer an object-oriented view of a relational database to the application kernel. Brown and Whitenack [Bro+96] use a broker to decouple the layers while [Col+96] describes a hard-wired approach.

Known Uses

The VAA Data Manager specification uses this pattern together with editors for meta data and complex mappings for hierarchical database systems [VAA95]. The VAA Data Manger is derived from the Data Manager Architecture of Württembergische Versicherung [Würt96].

Denert sketches some basic ideas of the pattern language in [Den91, pp. 230-239]. Many projects at sd&m used the patterns in various variants including Thyssen, Deutsche Bahn, and HYPO Bank [Kel+96a].

The CORBA Persistent Object Services (POS) [Ses96] specify persistent objects that use a Broker (Persistent Object Manager) to write their data to arbitrary data stores (Persistent Data Services).

[1]    Application data types are often used instead of raw database data types at application kernel level. They have additional methods to check their contents, reformat it, or format it for output. [Den91, chapter 5.2]

[2]    Most database errors are not meaningful on application level. Therefore it is a good idea to translate them. Additionally you may have to translate the error mechanism when the database uses return codes to signal errors and your application uses exceptions.