Home > Articles > Data

Designing Database Applications

  • Print
  • + Share This
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.

  • Figure 1 Analytical applications. Users query a database that reconciles and accumulates operational extracts.

  • 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.

  • + Share This
  • 🔖 Save To Your Account