Contents10 sections
A database sounds technical. It is not. A database is a tidy way to keep facts so you can find them again.
This is part 1 of a two-part starter. Here you will learn what a database is, what its parts are called, and how the parts fit together. In part 2, you will plan your own first database on paper, before you touch any software.
What a database is
A database is an organized collection of data. The word “organized” does the heavy lifting. A pile of notes is data. A database is data put in a structure, so each fact has a fixed home.
Most databases you will meet are relational databases. That word sounds grand. It means the data lives in tables, and the tables connect to each other through shared values. You will see exactly how that works in the example below.
One distinction matters from the start. A database is not the software. The software that creates and looks after a database is called a database management system, or DBMS for short. A relational DBMS is called an RDBMS. Common examples are SQLite, MySQL, PostgreSQL, and Microsoft SQL Server. They all share the same core ideas in this article.
A table holds one kind of thing
A table is a collection of related data, laid out in rows and columns, like a spreadsheet grid. Each table holds facts about one subject. One kind of thing per table. That is the whole rule, and it is the most important rule in this series.
A shop might have a table for products, a table for orders, and a table for customers. A film collection might have a table for films and a table for directors. If a table starts holding two kinds of things at once, it gets confusing fast. Part 2 shows how to split things up cleanly.
A table can be empty and still be a table. With no rows at all, its columns still say what it is for.
A row is one thing
A row is one complete entry in a table. It is also called a record. Each row holds one thing: one product, one customer, one film.
Each row holds one value in each column. A row is also the smallest unit you can add to or remove from a table. You add one film at a time. You remove one film at a time.
A column is one kind of fact
A column runs down the table. It holds one kind of information about the table’s subject. Every row has an entry in it. Each column has a name, and all the values in a column are the same kind of data: names, numbers, or dates, for example.
You will also see the word field. Some writers use “field” to mean a column. Others use it to mean a single value where one row meets one column. This series avoids the confusion: it says “column” for the vertical list and “row” for the entry. When you see “field” elsewhere, check which meaning that writer is using.
One value per cell
Here is a rule with no exceptions at this level. Every place where a row meets a column holds exactly one single value. Not a list. Not a group of values.
A cell that says “Shirt, Pants, Shoes” breaks the rule. Three values are hiding in one cell, and you cannot sort them, count them, or search them properly. The fix is always the same: give each value its own row, in its own table if needed. Part 2 works through this in full.
Keys: the unique identifier
Every row needs a way to tell it apart from every other row. That is the job of a key.
A primary key is the column, or columns, whose values uniquely identify each row. No two rows share the same primary-key value, and it is never empty. A product table might use a product ID. An orders table might use an order ID. Often the key is simply a running number you invent: 1, 2, 3.
A primary key can also be several columns together, if their combination is what makes a row unique. For beginners, one column is the normal case.
A foreign key is simpler than it sounds. It is a column in one table that holds the primary-key values of another table. It is the link between the two tables. You will see one in the example below: the Films table holds a director ID, and that ID points at a row in the Directors table.
A worked example: a film collection
Here is a small film collection kept as three tables. Each table has one subject. Nothing is repeated. Each director’s facts appear once. Each film’s facts appear once.
Films
| film_id | title | year_released | director_id | runtime_minutes |
|---|---|---|---|---|
| 1 | Jaws | 1975 | 1 | 124 |
| 2 | Alien | 1979 | 2 | 117 |
| 3 | The Thing | 1982 | 3 | 109 |
| 4 | Get Out | 2017 | 4 | 104 |
film_id is the primary key. It uniquely identifies each film. director_id is a foreign key. It points at the Directors table.
Directors
| director_id | first_name | last_name | birth_year |
|---|---|---|---|
| 1 | Steven | Spielberg | 1946 |
| 2 | Ridley | Scott | 1937 |
| 3 | John | Carpenter | 1948 |
| 4 | Jordan | Peele | 1979 |
First name and last name are stored separately. That follows a rule you will meet in part 2: break information into its smallest useful parts. Stored separately, the collection can be sorted or searched by last name.
Viewings
| viewing_id | film_id | date_watched | rating_out_of_5 | watched_with |
|---|---|---|---|---|
| 1 | 1 | 2026-01-10 | 5 | Alone |
| 2 | 1 | 2026-07-04 | 5 | Sam and Jo |
| 3 | 3 | 2026-03-22 | 4 | Sam |
| 4 | 4 | 2026-10-11 | 5 | Alone |
Three things to notice:
- One row is one thing. One film. One director. One viewing.
- One value per cell. No cell holds a list.
- Repeat viewings are separate rows. Jaws was watched twice, so it has two viewing rows. The film’s own facts are not repeated. And Alien has no viewing row at all. That is allowed. A viewing is optional.
This is the whole idea of a relational database in miniature. Facts live once, in the table they belong to. Shared IDs connect the tables. When you want an answer, you combine the tables on demand, instead of copying facts everywhere.
Why not just a spreadsheet?
A spreadsheet can hold the same grid. A database adds enforced structure. Each column has a defined data type. Tables link through shared values, so facts are stored once and combined when needed. A database also enforces rules on what counts as valid data as it is entered.
Use a spreadsheet for quick, one-off lists. Use a database when the facts matter, when they connect, and when they will grow.
SQL, in one line
SQL stands for Structured Query Language. It is the standard language used to ask questions of a relational database, and to add, change, or remove data. You do not need it for this series. It is here so the letters mean something when you meet them.
Keep going
You now know the parts: database, table, row, column, key. In part 2, you will plan your own first database on paper, step by step, before you touch any software. And when your first site is ready, run through the before-you-launch checklist before it goes live.