11.2: Three Components of Client/Server Systems

The client/server model is designed to manage data and facilitate the methods by which users can access it. In the client/server model, data is shared between one central server that houses and provides access to it and one or more clients that access the data through either a direct or remote feed. By calling requests to the server, clients can access any information they have access to, but clients cannot access information from other clients, as that would represent a peer-to-peer system, rather than a client/server model.

In client/server systems, there are three main components of logic. Presentation logic controls the inputs and outputs. It "presents" the data to the user in a readable format and also collects information that a user inputs using their system. Processing logic oversees everything around turning the client request into a request the server can use in the next step to find information. The final component is storage logic, which handles physical data storage and processes for retrieving it upon user request.

Figure \(\PageIndex{1}\): Client distribution models (made via Microsoft PowerPoint, Michael Nolan 2020)

The way that systems using this model delegate these logical applications defines individual databases further. Two-tier database architecture is divided into three groups named to specify what the client takes care of, as shown in Figure 1. In fat client distribution, presentation and processing are both handled by the client system, while the server exclusively handles the storage logic application. In thin client distribution, the client only handles presentation, while the server takes care of processing the request and dealing with storage. Finally, when a two-tier system is distributed in design, the client and server both handle parts of processing logic. In these sorts of systems, presentation logic is still handled by the client and storage is still handled by the server exclusively.

Further levels of tiered architecture in databases works similarly to the aforementioned design ideas, but splits processing logic applications further between multiple intermediate applications and web servers before the client's request reaches the database server.

a. Presentation

Presentation logic is the high-level interactive portion of the database. It is where the enduser can input requests and receive output on their host device.

Input in the presentation level of the client-server model can be many different things. GUI elements can be added to make it easier, such as text fields that users can modify, copy, or delete, buttons for submitting requests, menus, links, and more. Output is handled by the system to present the server response to user queries in a readable way that gives the user all the information they need without giving them information they did not request or information to which they are not allowed access.

Presentation logic is handled exclusively by client software on the host device. This can be managed by some language such as HTML to quickly take inputs and display outputs in a controlled location.

b. Processing 

The processing logic layer is an intermediary layer that translates information back and forth between user language coming from the client software and abstracted language used by the database's storage unit to quickly access the correct information. The processing layer also handles business rules, assuming they are not already built into the organizational DBMS.

Processing logic has many automated measures defined by business logic and business rules that are tailored to the specific company or organization the database is a part of. It is also where data integrity is insured whenever commands are sent to the storage database.

Applications for this are generally coded in Java or C, as those languages can be applied to many kinds of hardware with ease and offer some scalability without slowing down the system. Attention needs to be paid to these processes to make sure that this stage of data transfer does not bottleneck, as the processing logic may have to handle many requests per day.

Processing logic is also where the majority of differences in database architecture lie. Two-tier architecture can be split three ways: fat client, thin client, and distributed. Fat client distribution has all processing logic handled on the client's side, so the user host machine sends a request to the database having already translated the language from the user's input into whatever language that specific database uses for queries. Fat client distribution is the most commonly used organization of database access in the client-server system. Thin client distribution has all processing logic handled by the server system. The goal of this is to keep the user interface as light as possible. Distributed systems have processing logic handled by both the client and server in a way that boosts efficiency. It is more complex than the other two methods to set up.

Multi-tier organization splits processing logic in different ways. Three-tier systems may have processing logic all performed on a separate web server that clients and servers both access. Above that, processing can be handled by multiple web and application servers that each manage smaller parts of the translation. The goal of these larger systems is to be more modular and scalable while still being easy to maintain, since problems can be pinpointed easily.

c. Storage 

The storage logic represents the physical database and storage devices. It is where data storage and retrieval is handled in the system, and it is the part of the client-server system where the DBMS interacts with everything else.

Data in the database can be stored in many different ways. Data can be accessed using the information provided by the processing applications very quickly.