When you first start learning SQL, one of the most confusing concepts can be understanding why information is divided across several tables instead of being stored in one large table.
At first glance, putting everything into a single table might seem easier. For example, you could store a customer's name, address, and all of their orders in the same place. However, relational databases are designed differently for some very important reasons.
One of the key concepts behind this structure is database normalization.
What Is Database Normalization?
Database normalization is the process of organizing data in a database so that information is stored efficiently, logically, and with as little unnecessary duplication as possible.
A well-designed database generally aims to achieve three important goals:
Keep logically related information together.
Allow information to be updated in one place whenever possible.
Make it easier and more efficient to retrieve and manipulate data.
These principles help databases remain accurate, consistent, and efficient as the amount of data grows.
Why Use Multiple Tables?
Imagine a company such as Parch & Posey that needs to store information about its customers and their orders.
It might have an Accounts table containing information about each customer:
Account name
Street address
City
State
ZIP code
Country
It could then have a separate Orders table containing information about individual purchases.
Why not simply put all of this information into one table?
There are several reasons.
Different Types of Information
The first reason is that accounts and orders represent fundamentally different types of objects.
An account represents a customer or company. Usually, there is one account record for each customer, and the information associated with that account can change over time.
Orders are different. A customer can place many orders, and each order represents a specific transaction.
Once an order has been completed, its information generally should not change. If the customer places another order, the database can simply create another order record.
This difference in how the information behaves makes it logical to store accounts and orders in separate tables.
Avoiding Duplicate Data
Another major advantage of normalization is reducing unnecessary duplication.
Suppose the customer's name and complete address were stored in every order record.
If a customer had placed 100 orders, their address might appear 100 times in the database.
Now imagine that the customer moves to a new address.
Without a normalized structure, the database would potentially need to update the address on all 100 orders.
That means changing the same information repeatedly.
With a separate Accounts table, the customer's address only needs to be changed once.
The Orders table can simply reference the appropriate account.
This becomes increasingly important as databases grow. A company with thousands or millions of orders could otherwise have an enormous amount of duplicated information.
Why Database Structure Can Affect Performance
Database design can also influence query performance.
When a database executes a query, it needs to read data and perform whatever calculations are necessary to produce the requested result.
If the same information is unnecessarily repeated across a huge table, queries and updates can become more expensive.
By separating information into logical tables, a database can avoid storing the same data repeatedly and can work with more manageable sets of information.
Good database design therefore isn't only about keeping information organized. It can also contribute to efficient data retrieval and maintenance.
How Are Tables Connected?
If account information and order information are stored in different tables, how can we combine them when we need to analyze the data?
This is where one of the most important concepts in SQL comes into play:
JOINs.
A JOIN allows us to combine related information from two or more tables.
For example, an Orders table might contain an account identifier that tells us which customer placed each order. The Accounts table contains the corresponding customer information.
Using a JOIN, we can bring these pieces of information together in a query.
Conceptually, the database might contain something like this:
Accounts
| Account ID | Account Name | City | Country |
|---|---|---|---|
| 101 | Parch & Posey | New York | USA |
| 102 | Example Company | London | UK |
Orders
| Order ID | Account ID | Order Amount |
|---|---|---|
| 5001 | 101 | $1,200 |
| 5002 | 101 | $850 |
| 5003 | 102 | $2,100 |
The Account ID connects the two tables.
A SQL JOIN can then be used to answer questions such as:
Which company placed each order?
How much has each customer ordered?
How many orders has each account made?
What is the total revenue generated by each customer?
Why Normalization Matters
Normalization is an important part of database design because it helps prevent common problems caused by duplicated or poorly organized information.
A poorly designed database can create several issues:
Data redundancy: The same information is stored multiple times.
Update problems: A change may need to be made in many places.
Inconsistent data: Different records may contain different versions of the same information.
Storage inefficiency: Repeated information consumes unnecessary space.
Maintenance difficulties: The larger the database becomes, the harder it is to manage duplicated data.
A normalized database helps reduce these problems by placing information where it logically belongs.
Do Data Analysts Need to Design Databases?
If you are learning SQL as a data analyst, you may be wondering whether you need to become an expert in database normalization.
Usually, you don't need to design the database yourself.
In many analytical roles, the database has already been created by database administrators, data engineers, or developers. Your job is generally to understand how the tables are structured and use SQL to retrieve the information you need.
However, understanding normalization is still valuable.
It helps you understand why data is divided into multiple tables and, more importantly, how those tables are related.
Once you understand this structure, concepts such as primary keys, foreign keys, and JOINs become much easier to understand.
Relational databases are divided into multiple tables for good reasons.
Accounts and orders represent different types of information and often behave differently. Separating them reduces unnecessary duplication, makes updates easier, and can help databases operate more efficiently.
The key idea is not simply that databases contain multiple tables. The important point is that each table should have a logical purpose, and related tables can be connected when necessary.
For anyone learning SQL, this leads to one of the most important skills you can develop: understanding how tables relate to one another and using JOINs to bring the right information together.
Once you understand this concept, working with relational databases becomes much more intuitive—and writing useful SQL queries becomes significantly easier.