Data is the raw, unprocessed facts you record — numbers, words, dates, yes/no answers — with no meaning of their own until someone attaches context to them. This entire course is really about the different ways a database keeps that context attached, so data never turns back into a meaningless bare value.
Why This Matters
You don't need to know a single database term yet to understand the one idea this whole course is built on: data by itself never means anything — it only means something once it's given context. Almost every rule you'll meet later in this course, however technical it looks, is really just a more rigorous way of protecting that one idea. Get comfortable with this distinction now, in plain language, and the more technical chapters ahead will feel like details — not new ideas.
Real World Story
Imagine a friend texts you a single word: "42". Is that their age? The temperature outside? How many unread messages they have? There's no way to know — the number 42 just sits there, meaning nothing on its own. Now imagine the text instead says: "I turned 42 today." Nothing about the number changed — it's still 42 — but now it means something, because it arrived with context. That gap between a bare "42" and "I turned 42 today" is the entire difference between data and information, and it's the exact gap every database in this course exists to close.
Core Concept
Data is a raw, standalone value — a number, a word, a date, a yes/no answer — with no meaning attached on its own. Information is data that has been given context — a label, an explanation, a relationship to something else — so a person can correctly understand it. The number 42 is data. "You are 42 years old" is information. Every idea in this course, from the simplest to the most advanced, is ultimately about one thing: keeping data attached to enough context that it stays information, reliably, for as long as it's stored.
Deep Dive
- Data shows up in three broad shapes. Structured data follows a strict, repeating pattern every time — think of a paper form where every copy has the exact same blanks: name, date, signature. Semi-structured data has some organization but no fixed pattern — an email always has a sender and a subject, but its body can contain absolutely anything. Unstructured data has no built-in organization at all — a photograph, a voice note, a page of free writing.
- The kind of database you'll learn in this course — a relational database — is built specifically for the first kind: structured data, where every entry follows the same repeating pattern. You'll meet the actual vocabulary for this soon — words like table, column, and schema — but for now, just hold on to the idea underneath them: structure is simply a promise that every entry will carry its context the same way, every single time.
- That promise is also why structured data feels more rigid than, say, a folder of random notes — the rigidity is the point. It forces every piece of data to declare its own meaning once, up front, instead of leaving every future reader to guess it.
Visual Diagram
FROM RAW VALUE TO MEANING
42
raw data — no context
42, labeled: age
data + a label
"You are 42 years old"
information — ready to use
Example
SAME VALUE, BEFORE AND AFTER CONTEXT
| Raw Data | With a Label Attached | Now Means |
|---|---|---|
| 42 | age: 42 | A person's age in years |
| "2026-08-05" | signup_date: "2026-08-05" | The date an account was created |
| true | is_active: true | Whether an account is currently active |
Production Perspective
This is why well-built apps and APIs always send labeled information — {"age": 42} instead of a bare 42 — because an unlabeled number is a liability the moment anyone forgets what it meant. Every remaining chapter in this course is really just teaching increasingly rigorous ways to attach that label permanently, so it can never be lost, guessed at, or misread — you'll soon see this formalized as a database schema.
Common Mistakes
Storing a formatted value instead of the raw data.
Why: A price stored as the text "$42.00" can't be summed or sorted numerically without first being converted back — the formatting has contaminated the data.
Fix: Store the raw number (42.00), and add the "$" and decimal formatting only when displaying it to a user.
Treating a calculated value as if it were original data.
Why: A stored "full name" built by joining a first and last name can silently go out of date the moment either part changes.
Fix: Store the original parts, and calculate the combined value only when it's actually needed.
Interview Questions
What's the difference between data and information?
Data is a raw value with no attached meaning — a bare number, word, or date. Information is data plus context (a label, an explanation, a relationship) that lets it be correctly understood. A database stores data; the rest of this course is about how it keeps that data attached to its context.
Why does it matter whether a piece of data has clear, enforced context, instead of just trusting whoever reads it to interpret it correctly?
Trusting every reader to guess a value's meaning correctly doesn't scale — that meaning has to survive being read by a machine, a different engineer, or the same engineer six months later. Making the context part of how the data is stored, rather than a shared assumption, is what keeps the meaning intact automatically.
When would you choose to store a calculated value directly, despite the risk of it going stale, described in this chapter?
When recalculating it every time it's needed would be expensive enough — say, a total computed across millions of records — that the performance cost outweighs the staleness risk. Even then, it's safer to keep it somewhere clearly separate and deliberately refreshed, rather than mixing it in with the original data as if it were equally trustworthy.
Best Practices
Do
✓Store the raw value — keep formatting and display as a separate concern.
✓Attach a clear label to every value you record, even informally — don't rely on memory to know what it means.
✓Get comfortable asking "is this data, or is this something calculated from other data?" before you store anything.
Don't
✗Don't store a value already formatted for display when you'll also need to calculate or sort it.
✗Don't duplicate a value that can be worked out from other values you already have, unless you have a real, measured reason to.
✗Don't assume a bare value's meaning is obvious — if you'd need to explain it out loud, it's missing context it should carry with it.
Chapter Summary
Data is a raw value with no meaning of its own; information is data plus the context that makes it understandable. Every idea in the rest of this course — however technical the vocabulary gets — is really just a more rigorous way of keeping that context attached to data permanently. You don't need to remember any database terms from this chapter yet. You only need one instinct: whenever you see a bare value, ask what context it's missing — because finding the answer to that, formally, is what the rest of this course is about.