Your contact list is a database
So is the sticky note where you jot down your shopping list. So is a shoebox full of receipts, if you're organized enough to sort them.
Database engineers might wince at that. But strip away the jargon, and a database is just this: an organized place to store data so it can be found again later. Scale it up, add rules, and hand control of it to specialized software, and you get what companies call a "real" database. That software is called a DBMS (Database Management System).
There are two broad families of databases:
Relational databases - data lives in neat tables with rows and columns, like a set of connected spreadsheets. Think MySQL, PostgreSQL. Data here follows strict rules about structure.
Non-relational databases - data doesn't have to follow a fixed table structure. It might be stored as flexible documents, key-value pairs, or graphs. Think MongoDB. Good for messier, less predictable data.
Neither is "better." They're tools for different jobs, and most companies use both, depending on what they're storing.
OLTP vs OLAP: same business, two different jobs
Databases don't just differ in structure. They differ in purpose.
OLTP (Online Transaction Processing) handles things happening right now, one at a time, fast.
Withdraw cash from an ATM and the system checks your balance, subtracts the amount, and confirms it instantly, correctly, every time. That's OLTP: small, frequent, real-time operations.
OLAP (Online Analytical Processing) handles looking back, scanning huge amounts of history to find a pattern.
"What was our average withdrawal across all branches last quarter?" isn't a question about one transaction. It's a question about millions of them. OLAP systems are built to chew through that kind of load, even if the answer takes a few seconds or minutes to arrive.
Picture a bank branch: OLTP is the cashier at the counter, serving one customer at a time. OLAP is the analyst upstairs, going through a year of receipts to spot a trend. Same building, same business, entirely different jobs which is why they need entirely different tools.
Normalization: fixing the copy-paste problem
Normalization lives on the OLTP side. It's a set of rules for organizing a relational database so a fact only lives in one place, and updating it doesn't turn into a scavenger hunt.
Take a messy table storing student enrollments:
Mr. Doe's email shows up twice. Change it tomorrow, and you have to find and update every row he appears in. Miss one, and now two different emails exist for the same person, and there will be the question of "which one is correct"?
Normalization fixes this by splitting the data into separate, linked tables:
Now Mr. Doe's email exists in exactly one place. Change it once, and every course linked to him is correct automatically. That's normalization: store each fact once, and link related facts instead of repeating them.
Why this matters more than it sounds
This is the invisible layer under every app you use. Your bank app shows the right balance because OLTP and normalization are quietly doing their job. A company's leadership sees an accurate quarterly report instead of five contradictory spreadsheets because OLAP is running on properly-structured data underneath.
Get this layer wrong, and every dashboard, report, and model built on top of it inherits the mess.
One-line takeaway: OLTP keeps the present accurate. OLAP makes sense of the past. Normalization is what keeps OLTP trustworthy enough for OLAP to rely on.
Top comments (0)