3. System Architecture

In this chapter we will discuss the architecture of the two different models of DBMaker in detail. We will first talk about the DBMaker process and the Database Communication and Control Area (DCCA), which stores all necessary information for each started database, and then go through the architectures both models.

3.1 The DBMaker Process

A DBMaker process is a process that handles storage and retrieval of data according to user commands and other database functions. A DBMaker process consists of several layers as shown in Figure 3-1.

In this figure, we can see that the user applications communicate with DBMaker through an Application Program Interface (API). The API will pass user commands (SQL commands) or function calls to the SQL Engine, which is responsible for analyzing the SQL commands and translating them into sequences of function calls that are acceptable to the Database Engine. The SQL Engine passes these calls to the Database Engine, which executes these function calls to store data in tables or retrieve data from tables.

Figure 3-1: A DBMaker Process

Note that the roles of the SQL Engine and the Database Engine are different. Basically, the SQL Engine handles SQL parsing and query optimization, while the Database Engine handles space/buffer management, concurrency control, crash recovery, and so on. All modules cooperate to maintain the data consistency of the entire database. Most of the performance tuning parameters are related to the lower layer of the Database Engine.

The API and SQL Engines are the same in the single-user and client/server models. However, the Database Engines in the single-user and client/server models are different. The single-user model can handle only one user while the client/server model can handle multiple users. In the client/server model the application and API are tied together and run on client machines while the SQL Engine and the Database Engine are tied together and run on server machines. In this manner the API can communicate with the SQL engine via network protocols.

3.2 Database Communication and Control Area (DCCA)

When started, DBMaker will first allocate a large block of memory to store database related information such as buffer pools and various types of control information. This memory block is called the Database Communication and Control Area(DCCA). It contains three types of data: page buffers, journal buffers, and the System Control Area (SCA).

The DCCA is very important to the operation of DBMaker, especially when run in client/server mode. In Microsoft Windows and UNIX single-user environments, the DCCA is allocated from the private heap. However, in a UNIX client/server environment, the DCCA must be shared among all DBMaker processes that access the same database, so it cannot be allocated from the private heap. Instead, a shared memory mechanism, which is a standard function in UNIX, is used to allocate the DCCA. All DBMaker processes that run in client/server mode communicate with each other via the DCCA.

The size and the usage of the DCCA is easy to tune in DBMaker. This will affect the overall performance of DBMaker greatly. We will talk about this in the chapter "Performance Tuning".

3.3 Architecture of the Single-User Model

The DBMaker single-user model is a DBMS that supports only one user. It is smaller and faster than other models because it doesn't need to handle concurrency control. If a database is owned by only one person, the single-user DBMaker is a good choice to manage that database. Figure 3-2 shows the system architecture of the DBMaker single-user model.

Since only one user can connect to a single-user DBMaker database, the DCCA is obtained from the private heap so it is not sharable. Note that there is no locking mechanism in the DBMaker single-user model. For the sake of performance, the DBMaker engine maintains all database data in memory while running, and writes the modified pages back to disk files (including data files and journal files) at the proper points in time. The dmconfig.ini configuration file is a text file that defines many parameters required for DBMaker to configure itself.

Figure 3-2: System architecture of the DBMaker single-user model

3.4 Architecture of the Client/Server Model

A DBMaker application may also run in the client/server model. In this model there are two processes involved in an application program: the client application process and the database server process. In general the client process resides in a front-end PC or workstation and uses API library routines provided by DBMaker to communicate with the server process across a local area network. Note that in a client/server system, all involved machines including servers and clients can be of different platform types.

In the client/server version of DBMaker, a network management module is necessary both in the client and server ends. The network managers are responsible for sending data between the clients and the database servers. The network protocol is an important issue in the client/server model. Currently DBMaker supports only one network protocol-TCP/IP (Transmission Control Protocol/Internet Protocol). If the client/server version of DBMaker is to be run on a system that does not normally support the TCP/IP protocol, it is necessary to install TCP/IP network software before running the DBMaker programs. If you run your client applications on UNIX, Windows 95, or Windows NT, you don't need to install additional TCP/IP software since all these operating systems have built-in support for TCP/IP. (In Windows 95 and Windows NT you must explicitly specify TCP/IP as one of the network protocols and install it into the system.) Figure 3-3 shows the system architecture of the DBMaker client/server model.

On UNIX systems, when a client process connects to a database server, the DBMaker network server will fork another server process to handle subsequent queries. The original network server process will continue to wait for connections from other clients. In Windows NT, the scenario is a little bit different. Because NT is a multithreaded system, the NT version of the DBMaker network server (dmserver.exe) is also a multithreaded program. Therefore when a client process connects to a server running on NT, the DBMaker server process will create another thread in its process space to handle the subsequent queries. In this case the DCCA is allocated from local memory, not shared memory. There is always only one DBMaker server process for a database in Windows NT. Because there are more and more operating systems that support multithreading, DBMaker will use multithreading over process forking when possible, because current research indicates that multithreaded programs are more efficient than multi-process programs.

There are three components in the client/server model of DBMaker. These components are: the server program, the client program, and the client library. The purpose of each of these components is given below.

Server Program

The name of the DBMaker server program is dmserver. This program includes a network manager which deals with the network communication, and a database engine which handles the data access. This program must be started first so that client programs can connect to the database server.

Client Program

The name of the DBMaker SQL client program is dmsqlc. You can use this program to connect to a database and issue SQL commands for data processing.

Figure 3-3: System architecture of the DBMaker client/server model

Client Library

The name of the DBMaker client library is libdmapic.a in UNIX, or dmapi35.lib on Microsoft Windows systems. Users who intend to develop their own client programs must link their programs with this library. For example, users can use various development tools from many vendors to write their front-end applications. When building the applications, they must link those programs with this library so that their custom applications can communicate with the server program.