Chapter 1: The Basic Concept of a Database — Why Keep Data Organized
What you'll learn in this chapter
- Explain what a database is in your own words
- List three typical problems that arise without a database
- Explain, with a concrete example, why uniqueness (IDs) matters
None in particular. Basic programming knowledge (variables, functions) and some experience managing a contact list or sales data in a spreadsheet (like Excel) is enough.
What is a database?
In a word, a database is "an organized collection of data." You could also describe it as a mechanism for storing data in a form that's easy to search, add to, update, and delete later.
Familiar examples that all qualify as databases include:
| Familiar example | What's "organized" about it |
|---|---|
| A paper phone book | Sorted alphabetically, so you can look up a number from a name |
| A library's catalog search | Searchable by title, author, or category |
| An online store's product pages | Filterable by product name, price, stock, or category |
| A bank's account management | Lets you trace balances and transaction history from an account number |
The key point here is that "organized" means the data you need is easy to retrieve. Papers scattered on a desk still hold information, but we wouldn't call that a "database."
What goes wrong without a database?
The value of a database becomes clear once you imagine life without one. Consider, for example, managing 1,000 customers' worth of information in an Excel file.
A database resolves these problems in one stroke.
| Problem | How a database solves it |
|---|---|
| Searching takes too long | An index lets you retrieve matching data instantly |
| Can't be edited concurrently | Multiple users can access it safely at the same time |
| Duplicate or inconsistent data | Prevented by a design ("normalization") that holds each piece of information in exactly one place |
| Lost files | Backup, replication, and disaster recovery are built in |
| No record of who changed what | Operation logs and update timestamps can be recorded |
Index: A structure for searching data quickly. It plays the same role as an index at the back of a book — you can jump straight from a value to the location of the data. Covered in more detail in Chapter 6, DBMS and SQL.
Normalization: A design technique for eliminating duplication and inconsistency in data. Covered in more detail in Chapter 11, Normalization.
Thinking through a contacts database example
To get a feel for this, let's look at the simplest kind of database — a contact list.
| ID | Name | Phone | Registered | |
|---|---|---|---|---|
| 1 | Taro Yamada | yamada@example.com | 090-1234-5678 | 2026-01-01 |
| 2 | Hanako Suzuki | suzuki@example.com | 080-2345-6789 | 2026-01-05 |
| 3 | Jiro Sato | sato@example.com | 070-3456-7890 | 2026-01-10 |
| 4 | Misaki Tanaka | tanaka@example.com | 090-4567-8901 | 2026-01-15 |
| 5 | Kenichi Takahashi | takahashi@example.com | 080-5678-9012 | 2026-01-20 |
This table (we call it a table) has one row per contact (a record) and one column per item (a column).
The formal definitions and naming conventions for table, record, and column are covered in detail in Chapter 7, Basic Terminology and Naming Conventions.
Why do you need an ID?
Look at the leftmost "ID" column in the table above. This is a "unique number" — an identifier that distinguishes each record from every other one.
What goes wrong without an ID? Consider a situation like this:
Name: Taro Yamada
Email: yamada@example.com
Phone: 090-1234-5678
Name: Taro Yamada
Email: yamada2@example.com
Phone: 080-9999-0000
If two people share the same name, the name alone can't distinguish them. If someone asks to "update Taro Yamada's phone number," there's no way to tell which Taro Yamada they mean.
Assign each person a single mechanical ID number, and an instruction like update the phone number for the person with ID = 1 becomes unambiguous. This is the idea behind uniqueness.
Being able to "uniquely identify a row" using a unique value like an ID is a premise that underlies all relational database design. The next chapter, Chapter 7 (Basic Terminology), covers this in detail under the name primary key.
What do you gain from using a database?
To summarize everything so far, a database's benefits boil down to five main points.
The concrete mechanisms behind these benefits are covered one by one in later chapters of this guide.
| Benefit | Covered in detail in |
|---|---|
| Centralized management / normalization | Chapter 11, Normalization |
| Concurrent access / transactions | Chapter 4, CRUD and ACID |
| Data validation / constraints | Chapter 4, CRUD and ACID |
| Fast search / indexes | Chapter 6, DBMS and SQL |
| Backup / disaster recovery | Chapter 4, CRUD and ACID |
Exercise: design a contacts database
Let's work through a short design exercise to check what you've learned.
Suppose you're building a database to manage your friends' contact information. The example above had "ID, name, email, phone, registration date" — what other columns would be useful in addition to these? Try to come up with at least three.
Sample answer
Some possible columns include:
| Example column | What it's for |
|---|---|
| Birthday | To send a birthday message |
| Address | For mailing a gift |
| Relationship (friend, coworker, family, etc.) | To adjust how often and what kind of message you send |
| Last contacted | To find people you haven't been in touch with in a while |
| Notes | Free-form notes on hobbies, favorite foods, and so on |
A common mistake: storing "age." Age changes over time, so it's more accurate to store the birthday and compute the age each time. "Don't store a value that changes directly — derive it by computing from data that doesn't change" is an important perspective to keep in mind when thinking about design.
Alternative approach: if you have a lot of contacts, you might also consider something like "tags" (labels you can select multiple of), but that doesn't fit into a single column — it needs a separate table. This is covered in detail in Chapter 14, Many-to-Many.
If you removed the ID column, in what situation would you get stuck handling a request to "change Suzuki's phone number"? Try to come up with one concrete example.
Sample answer
For example, when there are two people named "Hanako Suzuki" (same name). Even if you're told to "change Suzuki," you'd have to ask back, "which Suzuki do you mean," using the email address or phone number.
With a mechanical number like an ID, specifying the person with ID = 2 resolves it completely unambiguously.
Taking it further: even if you assume "there are no duplicate names," names can still change (through marriage, for example). If you use a name as an identifier, you'll need to rewrite every reference to it whenever a name changes. The principle is: don't use information that might change as an identifier.
Summary
Here's a recap of what this chapter covered.
- A database is "an organized collection of data" — a mechanism for storing data in a form that's easy to search, add to, update, and delete later
- With a database, you get faster search, concurrent editing, data validation, and disaster recovery
- The ID (uniqueness) that distinguishes each record is where design begins
- Two key ideas: "don't use information that might change as an identifier" and "don't store a value that changes directly — derive it by computation"
The next chapter looks at the mechanism that makes these capabilities possible: the relationship between a system and its database.