Data and information aren't two different kinds of things — they're two stages the same value can pass through. The exact same number can be data in one context and information in another, and most of what a database does is move a value between those two stages cleanly, without losing anything along the way.
Why This Matters
The previous chapter defined data and information as two separate ideas. This chapter is about the part that trips people up: the same value can be data one moment and information the next, depending only on who's looking at it and why — nothing about the value itself has to change. Once you see that data and information aren't fixed labels but temporary roles a value plays, a lot of database design stops being about "is this data or information" and starts being about "which role does this value need to play right now, and for whom."
Real World Story
Say an online store's database records that a customer has placed 12 orders. To that customer, opening their account page, "You've placed 12 orders" is information — it tells them something about their own history. But zoom out: to the store's business team, that same 12 is just one raw number among millions of customers' order counts — data, waiting to be averaged, compared, and turned into a new sentence: "Average customers place 9 orders; your top 10% place 40+." That sentence is information again — but for a completely different audience, built from data that was information a moment ago, for someone else.
Core Concept
Whether a value counts as Data or Information isn't a fixed property of the value — it depends on who's looking at it and why. The same 12 can be a meaningless raw number to one system and a meaningful fact to a person reading it, in the very same second. This matters because turning data into information isn't a one-time event a database performs once and forgets — it's a role a value plays for as long as someone needs it to, and the same value can slide back into being "just data" the moment it becomes an input to something else.
Deep Dive
- This idea has a name in information science: the DIKW hierarchy — Data, Information, Knowledge, Wisdom. Data is the raw fact. Information is data with context. Knowledge is information connected to other information ("customers who order this often tend to also buy X"). Wisdom is knowing what to actually do about it. This course lives almost entirely at the first two rungs — teaching you how databases store data and help turn it into information reliably — but it's worth knowing the ladder continues past where this course stops.
- The practical consequence for anyone building software: a database's job is almost never to produce knowledge, let alone wisdom. It's to store data faithfully and make it fast and reliable to turn back into information whenever it's asked for. Everything past that — deciding what the information means, what to do about it — happens in a person's head, or in a different layer of the system entirely.
Visual Diagram
DATA AND INFORMATION KEEP TRADING PLACES
Raw order counts
data
"You've placed 12 orders"
information
12 (one input among millions)
data again
"Average customer orders 9 times"
information again
Example
THE SAME VALUE, TWO AUDIENCES
| Value | As Data (input to something else) | As Information (meaningful to someone) |
|---|---|---|
| 12 | One row in a table of order counts | "You've placed 12 orders" (to the customer) |
| 150 | One input into a monthly average | "150 orders this month" (to a store manager) |
| 4.7 | One number fed into a ranking algorithm | "4.7-star average rating" (to a shopper) |
Production Perspective
This back-and-forth is exactly what real analytics systems do on purpose: a nightly job reads raw order rows (data), computes a daily summary like total revenue or average order size (information for a manager reading a dashboard) — and then stores that summary back into its own table, where it becomes data again for tomorrow's report, or for a chart comparing this month to last month. You'll meet the formal version of "pre-computing information and storing it as data for reuse" later in this course, but the underlying idea is exactly what's happening here.
Common Mistakes
Trusting a number just because it looks like meaningful information.
Why: Formatting a value nicely — adding a label, a currency symbol, a chart — doesn't fix bad data underneath it. A wrong raw count still produces a wrong, but convincing-looking, sentence.
Fix: Validate and question data at the point it's collected, not just at the point it's displayed — polish can't repair a wrong fact.
Storing a computed piece of information without recording how it was derived.
Why: A stored "average rating: 4.7" with no record of which ratings and how many went into it can't be recalculated, checked, or trusted later, especially once individual ratings change.
Fix: Keep the original data a calculation came from, even after you've stored the computed result — a computed value should always be reproducible from something more raw.
Interview Questions
Can the same value be both data and information?
Yes — whether a value counts as data or information depends on who's using it and why, not on the value itself. The number 12 is data when it's an input to a calculation, and information when it's shown to someone as a meaningful fact.
What's the practical difference between a database's job and "turning data into wisdom"?
A database is responsible for storing data faithfully and returning it reliably as information when asked. Deciding what that information means, or what action to take because of it, is a separate concern — usually handled by a person or a different part of the system, not the database itself.
Why might a system deliberately store computed information back as raw data, rather than recomputing it every time it's needed?
When recomputing is expensive or slow enough that doing it on every request would hurt performance, systems store the computed result so it can be reused as an input elsewhere — accepting the cost of keeping that stored result in sync with the original data it was derived from.
Best Practices
Do
✓Ask "who is this value for, right now" before deciding whether to treat it as data or information.
✓Keep the original data a computed value came from, so the computation can be checked or redone later.
✓Design storage around data, and let information be generated from it on demand wherever that's cheap enough to do.
Don't
✗Don't assume a nicely formatted value is automatically correct — formatting is not validation.
✗Don't throw away the raw data once you've computed information from it, unless you're certain you'll never need to recompute or audit it.
✗Don't treat "data" and "information" as permanent labels on a value — the same value can be either, depending on context.
Chapter Summary
Data and information aren't two different kinds of value — they're two roles the same value can play, depending on who's using it and why. The same number can be a meaningless input one moment and a meaningful fact the next, and back again. A database's job is narrower than it sounds: store data faithfully, and make it reliably possible to turn into information whenever someone needs it — deciding what that information means is a job for something else entirely.