Designing Database Applications

Once you have prepared a model and understand an application, the next step is to build it. This article looks at architecture and design issues for database applications. We provide guidelines for determining whether a database is appropriate for a particular application, and if so, the proper paradigm.

Michael Blaha has written numerous papers, has five patents, and is the author of several books, including A Manager's Guide to Database Technology (Prentice Hall PTR, 2001, ISBN 0-13-030418-2).

From the author of

Architectural Principles

The first task of design is to devise an architecture. The
architecture is the high-level plan or strategy for solving the
application problem. If you have a complex problem, you will have already
thought about architecture during preparation of a model. We recommend that an
architecture be guided by several fundamental principles:

Distinguish between operational and decision-support applications. Operational
applications, such as order entry systems, involve the routine and critical
operations of a business and must process data rapidly. Operational activities
tend to be simple, access few records, and have a response time within seconds.
Because the activities are fundamental to the business, the database must
be kept current, intact, and reliable. Most operational databases store
only the most recent data, and an update overwrites any prior value.

In contrast, analytical applications emphasize complex queries that read
large quantities of data and enable organizations to make strategic decisions.
Consider a supermarket that analyzes sales data to find products with correlated
sales. As Figure 1 shows, analytical
applications execute against a data warehouse, which combines data from
multiple sources. A data warehouse acquires its information from periodic
feeds from operational databases and external data sources. Most data warehouses
store data parameterized by time, so users can query past data and detect
temporal trends. Analytical applications tend to have few updates, other
than the periodic feeds.

Decompose large systems into layers and partitions. You can often realize
a simple and elegant structure by decomposing a system into layers and partitions.
A layer is a subsystem that builds on subsystems at a lower level
of abstraction. A partition is a subsystem that is in parallel to
other subsystems. You should end decomposition when subsystems have clear,
crisp themes that are straightforward to understand.

Separate application logic from the user interface. Normally, you should
decouple application logic from the user interface. Often, it is helpful
to organize application logic as a library of code (an application programming
interface, or API) and then invoke the code from a user interface, as appropriate.
There may be multiple user interfaces that access the application code;
the user interfaces may differ in presentation format and in the information
they present and suppress.

Consider reification. Sometimes, it is helpful to promote information such
as control, rules, or constraints to objects. You can then store information
declaratively as data, rather than write additional programming code.

Substitute database queries for programming code. You must strike a proper
balance between the role of the database manager and the role of a programming
language. A database manager can do more than merely store and retrieve
data; it is also a computation engine to which you can off-load work. This
off-loading can greatly improve performance, increase extensibility, reduce
development time, and reduce bugs.

Consider major interfaces to persons and other systems. Your architecture
is likely to be affected by the impositions of other systems. Ideally, you
should have small and well-defined interfaces. You should try to minimize
the amount of information that a person must enter.

We recommend that you use a formal process in devising an application
architecture. First, generate candidate architectures. Second, choose decision
criteria and assign weights to them. Next, rate the compliance of the
architectures against the criteria. And finally, compare scores for each
architecture candidate. You should consider the feasibility, cost, and risk of
alternative architectures.