Chapter 2: The Relationship Between a System and Its Database — The DBMS as Interpreter
What you'll learn in this chapter
- Explain the three-tier structure of a web system (user / application / data) with a diagram
- List three benefits of separating a system from its database
- List at least three responsibilities of a DBMS (Database Management System)
You should understand Chapter 1: The Basic Concept of a Database. Some experience using a web application (operating a site through a browser) is enough.
A web system is built from three layers
A modern web system is broadly made up of the following three layers.
| Layer | Role | Concrete examples |
|---|---|---|
| User layer | The screen the user directly touches | Chrome / Safari / an iOS app |
| Application layer | Runs the business logic | A server written in Laravel / Next.js / Django |
| Data layer | Stores and retrieves data | A DBMS such as PostgreSQL / MySQL, and the data behind it |
When a user presses an "order" button on screen, the request goes to the application layer, and the application records the order to the database via the DBMS.
DBMS (Database Management System): Software that manages a database. PostgreSQL, MySQL, Oracle Database, and Microsoft SQL Server are well-known examples. The word "database" is often used to mean both the data itself (the set of tables and records) and the whole mechanism including the DBMS, but this guide, in principle, distinguishes "database = the collection of data" from "DBMS = the software that manages it."
Why separate the system from the database?
Separating the application from the database gives you three modern-day benefits.
| Benefit | Why it matters |
|---|---|
| Independence | You can switch the app's framework and keep the data. You can upgrade the DB version without rewriting the app |
| Maintainability | It's easier to tell app bugs and DB bugs apart (you can trace their logs separately) |
| Scalability | You can scale the app servers from 1 to 10 while the DB stays a single shared instance, or vice versa — improve the DB's performance without touching the app |
Multiple systems sharing the same database
Once a database is decoupled, multiple systems can share the same data. Let's look at an e-commerce example.
For example, when the inventory management tool updates stock to "0," the customer-facing site's product page immediately reflects "out of stock." Keeping data in one place makes inconsistencies between systems less likely.
Having multiple systems access the same database directly is simple, but it comes with a downside: it tightly couples the systems together. Changing a table definition affects every system that uses it. In large systems, you'll sometimes see a microservices-style approach instead, where systems don't share a database directly but exchange data through APIs. This guide assumes small-to-medium systems and proceeds on the premise of a shared database.
The DBMS acts as an "interpreter"
The DBMS (Database Management System) sits between the application and the database, mediating their exchange through the common language of SQL.
Without a DBMS, developers would have to open files themselves, search row by row, lock them, and write them back — writing all of that logic by hand. The DBMS is the "data professional" that takes this off your hands.
The concrete capabilities of a DBMS and the major products are covered in detail in Chapter 6: DBMS and SQL.
Exercises
Pick one web service you used today (an SNS, a video site, a news site, etc.) and write out what corresponds to each of the three layers.
Sample answer
For YouTube, for example:
| Layer | Concrete example in YouTube |
|---|---|
| User layer | Chrome / Safari browsers, iOS / Android apps, smart TV apps |
| Application layer | Many servers: video delivery, recommendations, ad serving, comment API, and more |
| Data layer | The video files themselves / metadata DB / watch history DB / comments DB / users DB, and more |
Something to notice: in large services, the "application layer" and "data layer" each split into multiple pieces — one app can use several DBs, and one DB can be shared by several apps.
A common mistake: assuming "data layer = just the data." The data layer includes both the data itself and the DBMS that manages it.
Think of one concrete situation where "it's nice that the system and database are separated." Feel free to consider this from the standpoint of a developer, an operator, or a business owner.
Sample answer
For example, situations like these:
- When rewriting the app: switching a web framework from Rails to Next.js can be done without touching the database. Accumulated customer data can carry over as-is to the new system
- When upgrading the DB: upgrading a major PostgreSQL version doesn't require rewriting the app's code (within the range of compatibility)
- When adding app servers: when traffic grows, you can scale app servers alone from 1 to 10. The database can stay as a single shared instance
- When responding to an incident: if there's an issue like "the screen won't display," you can often resolve it by looking at the app's logs without touching the DB side at all
Alternative approach (from a business owner's perspective): development can be split into "frontend," "backend," and "database" specialists, which makes it easier to hire specialized talent and work in parallel.
Summary
Here's a recap of what this chapter covered.
- A modern web system has a three-tier structure: "user layer / application layer / data layer"
- Separating the app from the database gives you independence, maintainability, and scalability
- The DBMS is the "interpreter" that mediates between the app and the DB through the common language of SQL
- Multiple systems sharing the same DB keeps data consistent (at the cost of tighter coupling)
The next chapter looks at why database design matters so much, from the perspective of the cost structure of system development.