Database Architecture Introduction

When designing a modern application, chances are that you will need a database to store data. There are many ways to architect software solutions that use a database, depending on how your application will use this data. In this article, we will cover the different types of database architecture and describe in greater detail a three-tier application architecture, which is extensively used in modern web applications.

Table of contents

• What is database architecture?
• Types of database models
• Importance of keys in database architecture
• Client-server architecture in databases
• Managing relationships and normal forms
• Database design process: from concept to implementation
• Normalization and data integrity
• Evolution of database models
• The three levels of database architecture in MongoDB Atlas
• Database architecture: a summary
• FAQs

What is database architecture?

The term "database architecture" refers to the structural design and methodology of a database system, which forms the core of a Database Management System (DBMS). This architecture dictates how data is stored, organized, and retrieved, playing a crucial role in the efficiency and effectiveness of data management.

Database architecture describes how a database management system (DBMS) will be integrated with your application. When designing a database architecture, you will make decisions that will change how your applications are created.

First, you'll decide on the type of database you would like to use. The database could be centralized or decentralized. Centralized databases store all data in a single location, often managed by one entity; decentralized databases distribute data across multiple locations or nodes. Centralized databases are typically used for regular web applications and will be the focus of this article. Decentralized databases, such as blockchain databases, might require a different architecture.

Once you’ve decided the type of database you want to use, you can determine the type of architecture you want to use. Typically, these are categorized into single-tier or multi-tier applications, which we’ll explore in more detail below.

The architecture of a database is not a one-size-fits-all solution. It varies significantly based on the needs of the organization, the type of data being managed, and the specific applications that interact with the database. From simple structures that manage daily transactions in a small business to complex architectures that handle massive amounts of data in large enterprises, the spectrum of database architecture is broad and diverse.

At its core, a database system is an intricate set of software tools and mechanisms that store, manage, and retrieve data. A DBMS acts as an intermediary between the user and the database, ensuring that the data is easily accessible, consistently organized, and securely maintained. The effectiveness of a DBMS hinges on its underlying architecture, which must be robust, scalable, and capable of handling various data-related tasks with efficiency.

The primary functions of a DBMS include data storage, retrieval, updating, and management of database security. It should provide a convenient and efficient way to define, create, manage, and control access to the database. A well-designed DBMS architecture ensures that these functions are performed seamlessly, providing a stable and reliable platform for data management.

Types of database models

One of the fundamental aspects of database architecture is its tier architecture. This concept refers to the physical and logical separation of functionalities into different layers or tiers, such as data storage and data processing.

For instance, in a three-tier architecture, the first tier might be dedicated to raw data storage, the second tier to processing and managing data, and the third to presenting the data to users through a GUI or API.

The most common models include:

One-tier architecture

In one-tier architecture, the database, user interface, and application logic all reside on the same machine or server. It's typically used for small-scale applications where simplicity and cost-effectiveness are priorities. Because there are no network delays involved, this type of tier architecture is generally a fast way to access data.

An example of a one-tier architecture would be a mobile application that uses Realm, the open-source mobile database by MongoDB, as a local database. In that case, both the application and the database are running on the user’s mobile device.

Two-tier architecture

Two-tier architecture consists of multiple clients connecting directly to the database. This tier architecture is also known as client-server architecture.

This tier architecture used to be more common when a desktop application would connect to a single database hosted on an on-premise database server — for example, an in-house customer relationship management (CRM) that connects to an Access database.

Three-tier architecture

Most modern web applications use a three-tier architecture. In this architecture, the clients connect to a back end, which in turn connects to the database. Using this approach has many benefits:

• Security: Keeping the database connection open to a single back end reduces the risks of being hacked.

• Scalability: Because each layer operates independently, it is easier to scale parts of the application.

• Faster deployment: Having multiple tiers makes it easier to have a separation of concerns and to follow cloud-native best practices, including better continuous delivery processes.

An example of this type of architecture would be a React application that connects to a Node.js back end. The Node.js back end processes the requests and fetches the necessary information from a database such as MongoDB Atlas, using the native driver. This architecture is described in greater detail in the next section.

Importance of keys in database architecture

In database architecture, keys uniquely identify records within a table (primary keys) and create essential links between other tables (foreign keys); keys form the foundation for relational data organization. Keys are an integral part of database architecture, serving as the cornerstone for establishing relationships between tables and ensuring data uniqueness. The primary key of a table is a unique identifier for each record in that table. It is essential for establishing links between tables, especially in a relational database model.

Composite keys, which are formed by combining two or more columns in a single table, can also serve as primary keys, particularly when no single column uniquely identifies a record. A foreign key, on the other hand, is used to create a link between two related tables, ensuring referential integrity and enabling the establishment of relational connections.

An example of a composite key is a “MonthlySales” table. Neither the Month or the ProductID columns individually could uniquely identify a record. But combining these two columns into a composite key ensures each record, representing sales for a particular product in a specific month, is unique.

Client-server architecture in databases

A pivotal aspect of modern database architecture is the client-server model, particularly relevant in two-tier and three-tier architectures. In this model, the database server houses the DBMS and the actual database, handling data storage, query processing, and transaction management.

The client, usually a front-end application, interacts with the server, requesting data and presenting it to the end user. This separation enhances data integrity, security, and management efficiency, allowing for a more robust and scalable system.

Managing relationships and normal forms

Effective database design involves not just structuring data but also managing how different pieces of data relate to each other. This is where concepts like one-to-one, one-to-many, and many-to-many relationships come into play.

These relationships dictate how data in one table links to data in another, influencing how queries are constructed and how data integrity is maintained.

In database design, normal forms are sets of guidelines that reduce redundancy and improve data integrity by ensuring each table is structured properly. They include rules like each field should contain only atomic values in the first normal form, the requirement for non-key attributes to be functionally dependent on the primary keys in the second normal form, and the need for every non-key attribute to be directly dependent on the primary key in the third normal form.

These forms progressively refine table structure. Moreover, adherence to normal forms — such as the first normal form, second normal form, and third normal form — is crucial in reducing redundancy and dependency in database tables. Each normal form addresses specific types of anomalies and dependencies, contributing to a more streamlined and efficient database.

Database design process: from concept to implementation

The process of designing a database is meticulous and requires careful consideration of various factors. It begins with understanding the data needs and ends with a fully functional database system. Key steps in the database design process include:

• Requirement analysis: Understanding what data needs to be stored and how it will be used.

• Conceptual design: Creating a high-level visual representation of the database, often using entity-relationship diagrams.

• Logical design: Defining the database tables, keys, and relationships in more detail.

• Physical design: Deciding on the actual storage of data on disk, considering factors like disk space, performance, and scalability.

Database tables are fundamental components of a database structure, serving as the primary means of storing and organizing data. Each table in a database is uniquely identified by its table's primary key, which ensures that each record within the table is distinct. The primary key's role becomes even more crucial when dealing with multiple tables, as it facilitates the linking of related tables through foreign key relationships.

The database design process often begins with ensuring that tables adhere to the first normal form (1NF). This normal form stipulates that each field within a table should contain only one value, and each record must be unique. This initial step in normalization helps eliminate duplicate data, thereby improving data integrity and reducing disk space usage.

Normalization and data integrity

Normalization plays a significant role in the database design process. It is a systematic approach to organizing data that involves dividing databases into tables and defining relationships between them to minimize redundancy and dependency.

By applying normalization rules, designers can ensure that the database structure is efficient and that data is stored without unnecessary redundancy. This not only improves performance but also enhances data integrity, making the database easier to maintain and update.

Evolution of database models

The evolution of database models has been significant, from flat-file systems to hierarchical, network, and the widely used relational database models. Each model has its unique architecture, advantages, and limitations. The choice of a database model is often influenced by the specific requirements of the application, the nature of the data, and the desired performance characteristics.

Efficient data management and scalability

A core objective of any database architecture is efficient data management. This encompasses not just the speed and efficiency of data retrieval and storage but also aspects like scalability and adaptability to changing data needs. As databases grow and evolve, the architecture must be capable of scaling up or down to meet the demands of the users and the application.

Addressing redundant data and ensuring consistency

One of the challenges in database design is managing redundant data. Redundancy can lead to inconsistencies and increased storage requirements. Through techniques like normalization and proper database design, redundancy can be minimized, ensuring that data remains consistent across the database.

Database architecture in the context of emerging technologies

As technology advances, database architecture continues to evolve. The integration of cloud computing, big data analytics, and artificial intelligence in database systems is transforming how data is managed and accessed. These technologies bring new dimensions to database architecture, such as distributed data storage, real-time analytics, and predictive modeling, which require innovative architectural approaches.

The three levels of database architecture in MongoDB Atlas

The most common DBMS architecture used in modern application development is the three-tier model. Since it’s so popular, let’s look at what this architecture looks like with MongoDB Atlas.

As you can see in this diagram, the three-tier architecture comprises the data, application, and presentation levels.

Data (database) layer

As the name suggests, the data layer is where the data resides. In the scenario above, the data is stored in a MongoDB Atlas database hosted on any public cloud — or across multiple clouds, if needed. The only responsibility of this layer is to keep the data accessible for the application layer and run the queries efficiently.

Application (middle) layer

The application tier is in charge of communicating with the database. To ensure secure access to the data, requests are initiated from this tier. In a modern web application, this would be your API. A back-end application built with Node.js (or any other programming language with a native driver) makes requests to the database and relays the information back to the clients.

Presentation (user) layer

The final layer is the presentation layer. This is usually the UI of the application with which the users will interact. In the case of a MERN or MEAN stack application, this would be the JavaScript front end built with React or Angular.

Database architecture: a summary

In this article, you’ve learned about the different types of database architecture. A three-tier architecture is your go-to solution for most modern web applications. However, there are other topologies that you might want to explore. For example, the type of database you use could be a dedicated or a serverless instance, depending on your predicted usage model. You could also supplement your database with data lakes or even online archiving to make the best use of your hardware resources. If you are ready to concretize your database architecture, why not try MongoDB Atlas, the database-as-a-service solution from MongoDB? Using the realm-web SDK, you can even host all three tiers of your web application on MongoDB Atlas.