An Overview of Common Database Architectures

by Bradley Morgan [Published on 14 March 2007 / Last Updated on 23 Jan. 2013]

Overview of three main categories of database architectures and their sub-categories.

Today's database professionals face several options when considering architectures in which to employ to address the various needs of their employers and/or clients. The following text will provide an overview of three main categories of database architectures and their sub-categories, as well as offer some insight into the benefits of each.

Application Logic

Database architectures can be distinguished by examining the way application logic is distributed throughout the system.  Application logic consists of three components:  Presentation Logic, Processing Logic, and Storage Logic. 

The presentation logic component is responsible for formatting and presenting data on the user's screen The processing logic component handles data processing logic, business rules logic, and data management logic.  Finally, the storage logic component is responsible for the storage and retrieval from actual devices such as a hard drive or RAM.

By determining which tier(s) these components are processed on we can get a good idea of what type of architecture and subtype we are dealing with.

One Tier Architectures

Imagine a person on a desktop computer who uses Microsoft Access to load up a list of personal addresses and phone numbers that he or she has saved in MS Windows' “My Documents” folder.  This is an example of a one-tier database architecture.  The program (Microsoft Access) runs on the user's local machine, and references a file that is stored on that machine's hard drive, thus using a single physical resource to access and process information.

Another example of a one-tier architecture is a file server architecture.  In this scenario, a workgroup database is stored in a shared location on a single machine. Workgroup members use a software package such as Microsoft Access to load the data and then process it on their local machine.  In this case, the data may be shared among different users, but all of the processing occurs on the local machine.  Essentially, the file-server is just an extra hard drive from which to retrieve files.

Yet another way one-tier architectures have appeared is in that of mainframe computing.  In this outdated system, large machines provide directly connected unintelligent terminals with the means necessary to access, view and manipulate data.  Even though this is considered a client-server system, since all of the processing power (for both data and applications) occurs on a single machine, we have a one-tier architecture.

One-tier architectures can be beneficial when we are dealing with data that is relevant to a single user (or small number of users) and we have a relatively small amount of data.  They are somewhat inexpensive to deploy and maintain.

Two Tier Client/Server Architectures

A two-tier architecture is one that is familiar to many of today's computer users.  A common implementation of this type of system is that of a Microsoft Windows based client program that accesses a server database such as Oracle or SQL Server.  Users interact through a GUI (Graphical User Interface) to communicate with the database server across a network via SQL (Structured Query Language).

In two-tier architectures it is important to note that two configurations exist.  A thin-client (fat-server) configuration exists when most of the processing occurs on the server tier.  Conversely, a fat-client (thin-server) configuration exists when most of the processing occurs on the client machine.

Another example of a two-tier architecture can be seen in web-based database applications.  In this case, users interact with the database through applications that are hosted on a web-server and displayed through a web-browser such as Internet Explorer. The web server processes the web application, which can be written in a language such as PHP or ASP.  The web app connects to a database server to pass along SQL statements which in turn are used to access, view, and modify data.  The DB server then passes back the requested data which is then formatted by the web server for the user.

Although this appears to be a three-tier system because of the number of machines required to complete the process, it is not.  The web-server does not normally house any of the business rules and therefore should be considered part of the client tier in partnership with the web-browser.

Two-tier architectures can prove to be beneficial when we have a relatively small number of users on the system (100-150) and we desire an increased level of scalability.


Two-Tier Client-Server Architecture


Web-Based, Two-Tier Client-Server Architecture

N-Tier Client/Server Architectures

Most n-tier database architectures exist in a three-tier configuration. In this architecture the client/server model expands to include a middle tier (business tier), which is an application server that houses the business logic.  This middle tier relieves the client application(s) and database server of some of their processing duties by translating client calls into database queries and translating data from the database into client data in return.  Consequently, the client and server never talk directly to one-another.

A variation of the n-tier architecture is the web-based n-tier application.  These systems combine the scalability benefits of n-tier client/server systems with the rich user interface of web-based systems.

Because the middle tier in a three-tier architecture contains the business logic, there is greatly increased scalability and isolation of the business logic, as well as added flexibility in the choice of database vendors.


Three-Tier Client-Server Architecture


Web-Based, Three-Tier Client Server Architecture

See Also

Featured Links