What is data, and what is a database, really?

A box of toys

Imagine you have a big box of toys thrown in without any order. If someone asks "how many red cars do you have?", you'd have to dump the whole box out and check every single toy. That's slow, and if the box gets bigger every birthday, it becomes impossible.

Now imagine you instead keep your toys on labeled shelves: one shelf for cars, one for red things, a little tag on each toy saying its color and type. Suddenly, "how many red cars do you have?" takes seconds — you walk to the car shelf and count the red ones.

That labeled shelf is exactly what a database is for information instead of toys. This course is about how we build labeled shelves for data, how we ask questions about what's on them, and how we make sure nothing falls off the shelf and breaks.

What "data" actually means

Data is just recorded facts — anything you can write down. A student's name, a temperature reading, the price of a phone, a photo, the time you woke up today. On its own, one fact is nearly useless: "42" means nothing until you know it's "the age of a customer" or "the number of items in stock."

Once you attach meaning to data, it becomes information. "Age: 42" is information. A pile of related information, organized so a computer can store, search, and update it reliably, is a database.

Data:          42
Information:   Customer age = 42
Database:      A structured, searchable collection of many such facts,
               about many customers, kept consistent over time

Why not just use a text file or a spreadsheet?

You could absolutely write everyone's data into a plain text file, one line per person. For ten people, that's fine. For ten million people, several problems show up immediately:

• Finding one record means scanning the whole file, line by line, top to bottom.
• Two people editing at once can overwrite each other's changes.
• A crash halfway through a save can leave the file half-written and unreadable.
• Keeping related files in sync (like "orders" and "customers") is entirely on you — nothing stops you from deleting a customer while their orders still point at them.

A Database Management System (DBMS) is software built specifically to solve these problems: fast lookups, safe concurrent edits, crash protection, and rules that keep related data consistent. The next lesson digs into these file-based problems one by one, because understanding exactly what breaks is what makes the DBMS's solutions make sense.

The math behind "just scanning a file"

Say you keep $n$ customer records in a plain unsorted file, and you want to find one specific customer by ID. In the worst case, you check every record before finding it (or discovering it doesn't exist):

$\text{comparisons in the worst case} = n$

This is called linear time, written $O(n)$ — the work grows directly in proportion to how much data you have. If your company grows from 1,000 customers to 1,000,000, a search that took a fraction of a second could take a thousand times longer.

A well-built database, using structures called indexes (which we'll build up to in Module 6), can often answer the same question in:

$\text{comparisons} \approx \log_2(n)$

For $n = 1{,}000{,}000$, that's $\log_2(1{,}000{,}000) \approx 20$ comparisons instead of up to a million. That gap — a million versus twenty — is the entire reason databases exist as a serious engineering discipline rather than "just files."

Common mistakes

1. Confusing "data" with "information." Data is raw facts; information is data with context and meaning attached. A database's whole job is to attach and preserve that meaning.
2. Thinking a spreadsheet is a database. A spreadsheet is a fine tool for small, single-user, occasionally-edited data. It has no built-in protection against two people overwriting each other's changes, and no way to enforce rules like "this column must always be a positive number."
3. Assuming more data automatically means more useful information. Unorganized data at scale is often less useful than a small, well-structured dataset, because you can't reliably ask questions of it.

Summary

Data is raw recorded facts; information is data with meaning; a database is a structured, reliable collection of information a computer can search and update safely, no matter how large it grows. Plain files fall apart at scale because searching them is slow and nothing protects against crashes or simultaneous edits. The next lesson takes a step back and looks at how data has actually been modeled and stored throughout computing history, before we dig into exactly how file-based systems fail in practice.