Relational Database Access Layers
A Pattern Language


[ sd&m Home | ARCUS Home | What's New | Contact ]

ARCUS-LOGO

Abstract

This Pattern Language about Relational Database Access Layers helps you design applications that use relational databases and also reflect the relational calculus at a business object level. Such applications are known as data driven or representational [Mar95]. The systems need not be object-oriented, you may also use a 3GL. Hence, the pattern language passes over mapping inheritance and polymorphism.

Note: The research underlying these pages has been continued. You will find  improved pages at our new site on Object/Relational Patterns


From the Introduction

When designing an application that uses a relational database as its persistent data store, you come across an array of typical challenges. How do you provide a system with "good enough" performance? How and where in your system do you write your SQL-code accessing the database? How do you deal with later performance optimizations like denormalization of the data model that might cause a partial rewrite of your SQL code? What is the interface an application kernel object uses to access the data stores?

In a three-layer-architecture it is proven tradition to encapsulate aspects of database access in a database access layer. This paper presents a framework and a set of design patterns that help you design such database access layers for relational databases.


Download Paper

We have prepared several formats to download. For the sake of the internet community (and your telephone bill), please choose the smallest file you're able to read:


Related Work on Database Access Layers

The framework provides a database view interface for applications that use their database in a relational fashion. Such systems are pretty common. They have a simple data model compared to full blown object oriented models. Though they may have thirty entities or more, you rarely find much inheritance or complex associations. Yet there are complex use cases. You usually encapsulate these in an application kernel. It is a good idea, to use the relational calculus for modeling these systems. The three-layer-architecture as presented in [Den91] is tailored for such systems.

Other persistence frameworks and pattern languages deal with full object persistence. These are Object to Relational Access Layers, using a relational database and Object Access Layers using an object database. Figure 1 illustrates the relationship between the different access layers. Note that the architectural framework presented in this paper is not suited for such applications.



ARCUS Copyright © 1996 sd&m GmbH & Co KG,
arcus@sdm.de
Wolfgang Keller 28.11.96

Last modified Mon Sep 8 16:04:18 1997
by Jens Coldewey