Data models through history — hierarchical, network, relational, and NoSQL

Different family trees for the same problem

Before settling into tables, database designers tried several different shapes for organizing data. Understanding these older shapes isn't just trivia — it explains why the relational model (the subject of nearly this entire course) was considered such a breakthrough, and it explains why some modern "NoSQL" systems have deliberately gone back to shapes that look surprisingly similar to these older ones.

The hierarchical model: everything is a tree

The hierarchical model (used by IBM's IMS, still running in some legacy banking/airline systems today) organizes data as a strict tree — every record has exactly one parent, and children hang off a single path back to the root.

        Department
        /        \
   Employee     Employee
   /      \
 Project  Project

This works cleanly for data that's genuinely tree-shaped, but breaks down the moment a real-world fact doesn't fit a single-parent shape. If an Employee needs to belong to two departments, or a Project has multiple Employees from different departments, the strict one-parent-per-record rule has no clean way to express it — you're forced into awkward duplication or workaround pointers.

The network model: relaxing to a graph

The network model (CODASYL, standardized in the late 1960s) relaxed the hierarchical model's single-parent restriction, allowing a record to have multiple parents, represented as a general graph rather than a strict tree.

Employee ──┬── Department A
           └── Department B

This fixed the multi-parent problem, but at a real cost: querying a network database meant manually navigating pointers, one link at a time, written by a programmer who had to know the exact physical path to follow — there was no declarative "just tell me what you want" query language. This procedural, pointer-chasing style is exactly the kind of "difficulty accessing data" problem the next lesson names formally.

The relational model: Codd's breakthrough

In 1970, Edgar F. Codd proposed representing everything as simple, flat tables — relations — queried through a small set of mathematical operations, with no explicit pointers or predetermined access paths at all. This is the model the rest of this course builds on in full mathematical depth (Module 3 onward).

The relational model's genuinely new idea wasn't tables themselves — it was physical data independence (Module 1, three lessons from now): because queries reference relations declaratively by content, not by navigating physical pointers, the DBMS is free to reorganize storage however it wants underneath, without breaking a single application. Network and hierarchical databases, by contrast, baked physical navigation paths directly into how queries were written, so any storage reorganization risked breaking every application built on top.

$\text{Hierarchical/Network: query} = \text{explicit physical navigation path}$ $\text{Relational: query} = \text{declarative description of desired data, path chosen by the DBMS}$

The object-oriented and object-relational models

As object-oriented programming became dominant in the 1990s, object-oriented databases tried storing objects (with their methods and inheritance) directly, to avoid the "impedance mismatch" of translating between OOP objects and flat relational rows. They saw limited adoption — mostly because the relational model's simplicity, maturity, and tooling ecosystem were hard to beat for typical business data. Object-relational databases (like PostgreSQL) compromised, adding object-like features (custom types, inheritance between tables, arrays) on top of a fundamentally still-relational core — the version of this idea that actually succeeded widely.

NoSQL: a deliberate return to flexibility, and its trade-offs

Starting in the mid-2000s, "NoSQL" databases emerged to handle a mix of massive scale and less rigidly-structured data than the relational model comfortably fits. Four broad categories:

• Key-value stores (Redis, DynamoDB) — the simplest possible model, a giant hash map of keys to values, extremely fast for exact-key lookups.
• Document stores (MongoDB) — store semi-structured, nested JSON-like documents, letting each document have a somewhat different shape, avoiding rigid up-front schema design.
• Column-family stores (Cassandra, HBase) — optimized for very wide tables with sparse columns, built for massive write throughput across distributed clusters.
• Graph databases (Neo4j) — store nodes and relationships directly and natively, actually somewhat reminiscent of the old network model, but with a modern declarative query language layered on top.

NoSQL systems generally trade away some of the relational model's strong consistency and ACID guarantees (Module 7) for horizontal scalability and flexible schemas — a trade-off formalized by the CAP theorem: a distributed system can only guarantee two of Consistency, Availability, and Partition tolerance at once, a topic this course's final module covers in the context of distributed databases specifically.

Why this course is a relational-model-only course, deliberately

Despite NoSQL's rise, the relational model — and SQL specifically — remains the dominant choice for the vast majority of applications requiring correctness guarantees for genuinely relational, structured data: financial records, inventory, orders, anything where integrity constraints (Module 5) and ACID transactions (Module 7) actually matter more than raw horizontal write throughput. Understanding the relational model deeply, as this course does, is also what makes NoSQL trade-offs actually meaningful to evaluate later — you can't judge what a document store gives up without knowing what a properly normalized relational schema (Module 5) would have guaranteed instead.

The math behind why tree/graph navigation doesn't scale with query variety

For a hierarchical or network database, each distinct query pattern generally needs its own hand-written navigation path through the data. If an application needs $q$ different query patterns over its lifetime, and schema/storage changes happen $c$ times:

$\text{navigation code needing rewrite (hierarchical/network)} = O(q \times c)$

since a storage reorganization can invalidate any or all of those $q$ hand-written paths. The relational model's declarative queries, protected by physical data independence, keep this at:

$\text{navigation code needing rewrite (relational)} = O(0) \text{ for purely physical changes}$

This is the same physical-data-independence math from three lessons ahead, applied specifically to explain why the relational model displaced its tree/graph-shaped predecessors so completely.

Common mistakes

1. Assuming NoSQL databases are simply "newer and better" than relational databases. They solve a different problem (horizontal scale, flexible schema) at the cost of weaker consistency guarantees — the right choice depends entirely on the workload's actual requirements.
2. Thinking the network model and graph databases are the same thing. They share a graph-like shape, but graph databases have modern declarative query languages and are used deliberately for relationship-heavy data, not as a general-purpose model with manual pointer navigation.
3. Believing the relational model's "big idea" was just using tables. Its real breakthrough was decoupling queries from physical storage paths entirely — tables were the vehicle, not the destination.

Summary

Data has been modeled as strict trees (hierarchical), general graphs (network), flat tables (relational), and a range of flexible NoSQL shapes (key-value, document, column-family, graph), each generation trading off structure, query flexibility, and consistency differently. The relational model's real breakthrough was decoupling declarative queries from physical storage navigation, delivering the physical data independence the next module-and-a-half will keep returning to. With this historical context established, the next lesson returns to the specific, concrete failures of file-based (and, by extension, pre-relational) systems — data redundancy, inconsistency, and the other problems that motivated everything the rest of this course builds up to fixing.