1.6 Database Architectures

The way in which the three main components of the database approach are combined, along with the role of the network and location of the user, lead to fundamentally different database architectures. Each of these architectures has advantages and disadvantages, which may be more or less important for a given information system.

Mainframe Architecture

The earliest implementations of the database approach to system development used what we now call the mainframe architecture. Shown in Figure 1.3, it is characterized by the DBMS, data, and application all being located on a single computing device with access provided to users through terminals. These terminals are sometimes referred to as “dumb terminals” because they have no processing power. They only provide a display of the application and the keyboard input to the application; the application is stored in memory and is processed entirely on the central computer. A more capable personal computer can fill the role of a terminal in this architecture if it runs a terminal emulation program. In this case, the mainframe interacts with the personal computer as if it were a regular terminal. The same mainframe runs the DBMS with the data stored in such a way that the mainframe has fast, direct access to it.

The network is only involved to connect the terminals to the mainframe. Keyboard input is sent from the terminal to the application software running on the mainframe. Displayed results are then sent from the application software across the network to the terminals. The nature of this architecture allows for hundreds, or even thousands, of concurrent users. Because a minimum of data is transferred across the network, it is suitable for environments where fast, inexpensive network connections remain unavailable.

If the user requests information that requires the DBMS to examine hundreds of thousands—or even millions—of records of data, but results in a small answer set, very little data is sent across the network. Even if the result comprises a large amount of data, the application software will not send more across the network than can be displayed on the screen until the user requests more. So, the data transfer is limited by the relatively meager capacity of humans to consume the data. The result is that limitations in system performance are generally a result of either the processing power of the mainframe or disk access speed. Although it is not necessarily a characteristic of this architecture, the application software typically uses a character-based user interface rather than a graphical user interface. 

Desktop Architecture

Desktop architecture is similar to mainframe architecture in that the application, DBMS, and data all reside on a single computer. The primary difference is that desktop architecture is limited to a single user and therefore requires no network. Figure 1.4 shows this architecture. Popular database products that operate in this architecture are Microsoft Access, FileMaker Pro, OpenOffice Base, and Paradox. Let’s consider the three components of the database approach in the context of the most popular of the desktop databases—Microsoft Access. Access currently stores the data in a single file with an “.accdb” extension. So, creating a database and naming it “sales” would result in a file being named “sales.accdb” in the file system. Everything that you see when you work with Access is its application software. This application software is extended as a developer creates forms and then reports and augments them with customized code in the form of macros or code modules. The DBMS in the case of Access is a program called the Microsoft JET Engine. It is installed as a part of Access and is non-visual. It is possible to use the Access application tools with other database engines. Typically, when this is done it results in a different architecture.

Desktop architectures work well in situations where individuals do their own work without the need to be connected to other computer users. On individual home computers, people often have an address book application or a budget on a spreadsheet. Office applications, such as spreadsheets and word processors are popular desktop applications, although they do not use database technology. Simple information systems using database technology include such things as customer lists or inventory records.

File Server Architecture

File server architecture is a common outgrowth of a database system that begins by using desktop architecture and then expanded to accommodate multiple concurrent users. Shown graphically in Figure 1.5, it is characterized by separating the DBMS from the data by the network. Making the transition from desktop architecture to file server architecture is generally very simple and requires no specialized database knowledge. However, it introduces a substantial performance limitation.

Recall that the DBMS is responsible for managing every aspect of the data. In this architecture, the DBMS now must manipulate the data across the network. Because network data transfer speeds are substantially lower than local disk data transfer speeds, the separation of the DBMS from the data introduces a substantial bottleneck. Consider what happens when the DBMS needs to respond to an information request that requires it to examine each entry in a list of customers. Suppose there are one million customer records to examine and only 100 of those meet the criteria specified in the information request. In mainframe architecture, where the DBMS has direct access to the data, it can quickly read all the records and send only the 100 relevant records across the network. However, in file server architecture, all one million records must be sent across the network to be evaluated by the DBMS. The DBMS examines the data as it is received and then retains only the relevant data for display to the user.

The reduced performance is not limited to just the user of the database application. Because the network becomes the bottleneck in the process, all users who share segments of the network with the user of the database application will experience network delays as well. Moreover, if other users who share network segments with the user of the database application are engaged in heavy network usage activities, the performance of the database application will be slower still.

File server architecture introduces another problem compared to either desktop or mainframe architectures. In both of these architectures, there is a single DBMS that controls the data store. However, in file server architecture, each additional user adds another instance of the DBMS to control the data. For this to work, the DBMS in each computer must coordinate with each other to maintain the integrity and security of the data. For example, if one user is currently editing information about a particular product, the instance of the DBMS that the user is using must alert the other instances to not allow that same information to be edited by another user until the first user has finished. This process generally works well enough; however, problems arise when an instance of the DBMS is unable to alert other instances that its user has finished with a particular data resource because of either network connectivity issues or other operating system problems.

The benefit to this architecture is that with very little database knowledge, a user can set up a database application for simultaneous use by a few users. The main function of a file server is to enable multiple users to access the stored files and free storage space for the file repository. These servers are especially popular as a central storage place for internal company files that are relevant for individual users or that can be shared by multiple users, for example, an engineering firm where the applications run on the desktops but the engineering drawings are shared by multiple engineers. Engineers may share drawings, descriptions, images, or even videos.

The second major application of file servers is data backups. Storing backup copies on a file server is an easy and inexpensive method to cover the necessary backup storage requirements for all individual users in an organization.

Client/Server Architecture

In many respects, client/server architecture brings together the best characteristics of the prior architectures. Shown in Figure 1.6, client/server architecture is characterized by running the DBMS on a machine with direct access to the data. This computer is referred to as the database server. Multiple copies of the application are run on separate personal computers—one for each simultaneous user.

The main drawbacks in file server architecture stem from having multiple instances of the DBMS separated from the data by the network. Client/server architecture avoids these problems by deploying a single instance of the DBMS with direct access to the data. Consider again the situation where information requested by a user requires the DBMS to search across one million records to identify the 100 relevant records. Under client/server architecture, the DBMS quickly reads all one million records and identifies the 100 of interest. It then sends only those 100 across the network to the application software for display to the user.

This positioning of the components of the database approach takes advantage of the inexpensive processing power available on the desktop to run the application software and separates the application from the DBMS with the network. Because the communication between these two components is relatively lean, the low data transfer rates of networks does not create a major bottleneck. The most resource-intensive part of this approach is the database server. However, as this is a single machine, it can be built with appropriate specifications to meet the needs of a particular system. Moreover, some providers of DBMS software have versions of their DBMS that allow the database server to be implemented as a cluster of physical machines, allowing the deployment of systems that might otherwise be too demanding for a single computer to run the DBMS.

Client/server computing architecture is especially effective when clients and the server each have distinct tasks that they routinely perform. In hospital data processing, for example, a client computer can be running an application program for entering patient information while the server computer is running another program that manages the database in which the information is permanently stored. The server computer may also have applications that process and manipulate patient data, illness data, and prescription drug data. Because both client and server computers are considered intelligent devices, client-server model is different from a simple file-server architecture. 

Web Architecture

Web database architecture is an extension of client/server database architecture. It is the most current architecture and the most widely used in today’s connected, online world. As shown in Figure 1.7, the application software is run mainly on a web server that connects to the DBMS through a network connection, although it is possible for the database server and web server to be the same physical machine. What is distinctive about this architecture is that while the description of what will be shown to the user is generated on a web server, the information is sent across the internet in the appropriate format for the receiving application. In Figure 1.7, we have shown three types of clients: a personal computer, a smartphone, and a tablet computer. These devices can have Apple, Android, or Microsoft applications. Thus, in this architecture, the application software is distributed across computing devices.

In the personal computer device, the figure illustrates a direct link to the internet, but a wireless link is also possible. In this example, we are showing a web browser as the client application. In the early implementations of this method, a web server typically generated a simple static web page for display, leaving very little for the browser to do. However, as client-side scripting approaches in web browsers continue to gain popularity, more of the functionality of the application is being implemented on the desktop with dynamic and asynchronous web pages, and less is done on web server. A personal computer may also run an online app, which operates as explained in the next paragraph.

The other two configurations, smartphones and tablets, work almost the same. Either a browser or an online app is running on either of these two devices. The online app will request data through an online link, either with a Wi-Fi connection or a cell tower connection. In either case, the request is eventually sent via the internet to the appropriate web server and database server. The requested data is returned in the appropriate format as requested by the client application.

Various techniques for load balancing can be used to allow the application to run on several web servers that are connected to the database server. This provides a way to prevent a single web server from becoming a bottleneck in the process. Finally, the portion of the application that runs in the browser is delivered to the user’s machine each time the user refreshes the page, or more often depending on the server configuration. This can have the effect of making application version control more manageable than with traditional client/server implementations.