Relational databases weren't the first way anyone tried to organize shared data — they were a specific, deliberate improvement over two earlier approaches that came before them. Understanding what came before explains why the relational model was considered such a breakthrough when it arrived.
Why This Matters
Every rule in this course can look like it was just handed down as "best practice" — but almost none of it was arbitrary. The relational model was invented specifically to fix real, painful problems with how data was organized before it existed, and knowing that history makes the rules ahead feel like solved problems, not arbitrary constraints.
Real World Story
Before the relational model existed, if you wanted to find a piece of data, you often had to know exactly where it lived and follow a fixed path of pointers to get there — like navigating a building where every room only connects to specific other rooms, and finding anything meant knowing the exact route by heart. If the person who designed the building changed a hallway, every set of directions that used it broke. That fragility — where questions had to be planned in advance and any structural change broke existing code — is exactly what the relational model was built to escape.
Core Concept
The earliest widely used database systems, in the 1960s, organized data using two designs: the Hierarchical Model (data arranged as a strict tree, like folders inside folders, where each item has exactly one parent) and the Network Model (similar, but an item could have multiple parents, forming a web of pointers). Both required a program to navigate data by following a specific, pre-planned path of links — there was no way to just ask a direct question. In 1970, a different approach was proposed: represent data as simple, independent tables, and let questions be asked directly against them, without needing to know or follow any particular path at all. That proposal became the relational model.
Deep Dive
- The hierarchical model (used in early systems like IBM's IMS, still running in some mainframes today) organized data like a strict family tree — great for data that's naturally hierarchical, like an organization chart, but rigid the moment a piece of data needed more than one "parent".
- The network model relaxed that restriction, allowing an item to connect to multiple others — but the cost was complexity: navigating the data still meant a program following a specific chain of pointers, decided in advance, and every one of those pointer paths had to be maintained by hand as the structure evolved.
- The relational model's breakthrough wasn't a cleverer way to build pointers — it was proposing that data didn't need explicit pointers between records at all. Instead, relationships could be represented using plain shared values (you'll see exactly how, using keys, later in this course), and a program could ask a direct question about the data without needing to know how it was physically stored or connected. That single idea — separating what the data means from how it's physically laid out — is why the relational model spread as fast as it did.
Visual Diagram
THREE MODELS, THREE WAYS TO FIND DATA
Hierarchical
1960s — strict tree, one parent per item
Network
late 1960s — a web of pointers, multiple parents allowed
Relational
1970 — tables + direct questions, no fixed path required
Example
FINDING THE SAME FACT, THREE WAYS
| Model | How You'd Ask This Question | What Could Go Wrong |
|---|---|---|
| Hierarchical | Follow the fixed path from Customer down to Orders | Breaks if the tree structure changes |
| Network | Follow a pre-planned chain of pointers | Every path must be maintained by hand as data grows |
| Relational | Ask directly: match rows where customer = Rahul | No fixed path to maintain at all |
Production Perspective
This history is not just trivia — it's why relational databases still describe themselves as being about "declarative" queries: you say what you want, not how to get it. Every time you write a query later in this course and the database figures out the fastest way to answer it, you're relying directly on the idea proposed in 1970: that a person asking a question shouldn't need to know how the data is physically organized underneath.
Common Mistakes
Assuming older database models (hierarchical, network) were simply "worse" and disappeared entirely.
Why: Hierarchical-style systems are still in active use for data that's genuinely tree-shaped, like some legacy banking and telecom systems — the relational model won broadly, not universally.
Fix: Judge a data model by whether it fits the shape of the actual problem, the same lesson from the DBMS-family comparison in the last chapter.
Thinking the relational model's ideas are "obvious" now, so the history doesn't matter.
Why: It's easy to underrate how disruptive an idea was once every part of it has become standard practice — understanding why it was hard reveals which of its rules protect something real, and which are just convention.
Fix: Read foundational rules, like the ones ahead in this course, as solutions to specific historical problems, not as arbitrary tradition.
Interview Questions
What were the two main database models that came before the relational model?
The hierarchical model (data as a strict tree, one parent per item) and the network model (data as a web of pointers, allowing multiple parents).
What was the core idea that made the relational model different from what came before it?
Instead of requiring a program to navigate data by following pre-planned pointer paths, the relational model represented relationships using shared values in simple tables, letting questions be asked directly without needing to know the data's physical layout.
Hierarchical and network-style ideas still exist in some modern systems — why do you think they came back, given that relational databases 'won' historically?
The original problems with hierarchical and network models — rigid, pre-planned navigation — matter less for certain modern workloads where the data is naturally tree- or graph-shaped and doesn't need the relational model's cross-cutting query flexibility. Their return is less a rejection of relational databases and more a recognition that the right model still depends on the shape of the actual data.
Best Practices
Do
✓Understand why a rule exists historically before treating it as an arbitrary constraint.
✓Recognize that "declarative querying" — asking what you want, not how to get it — is the direct legacy of the relational model's original idea.
✓Judge older and newer data models by fit to the problem, not by age or popularity.
Don't
✗Don't assume the relational model "solved" data modeling permanently — it solved specific, real problems, and different problems can still call for different models.
✗Don't treat historical context as optional trivia — it's often the fastest way to understand why a rule exists at all.
✗Don't assume every pre-relational idea is obsolete — some genuinely fit certain problems better even today.
Chapter Summary
Before the relational model, data was organized as trees or webs of pointers, and finding anything meant following a pre-planned path that broke easily as the data changed. In 1970, a new idea proposed representing data as simple tables and letting questions be asked directly, without needing to know how the data was physically laid out. That idea is the relational model this entire course is about — and the next chapter looks specifically at the person who proposed it, and exactly what he got right.