Designing Database Applications
- Architectural Principals
- Data Management
- Database Management
- Data Interaction
- Other Design Issues
- Conclusions
- References
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.
Figure 1 Analytical applications. Users query a database that reconciles and accumulates operational extracts.
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.