Data Models and the Relational Choice

Jr Codex DBMS Notes

Level: Beginner Prerequisites: Chapter 1: Why Databases Exist Time to complete: ~15 minutes

What a Data Model Is
The Models That Came Before
Codd's Idea
Why Relational Won
What Relational Is Bad At
Summary & Next Steps

1. What a Data Model Is

A data model is the set of shapes you are allowed to store data in, plus the operations you are allowed to perform on those shapes.

Every Data Model Answers Three Questions
─────────────────────────────────────────
  STRUCTURE    what shapes can data take?
               (tables? trees? documents? graphs?)

  OPERATIONS   how do you query and modify it?

  CONSTRAINTS  what rules can you enforce about
               valid data?
─────────────────────────────────────────

The choice matters more than it looks. It decides which questions are cheap to ask and which are painful — and that shapes the applications you can build on top for years afterwards.

2. The Models That Came Before

THE HIERARCHICAL MODEL (1960s)
─────────────────────────────────────────
  Data is a TREE. Each record has one parent.

    Company
      └─ Department
           └─ Employee
                └─ Project

  GOOD:  fast when you traverse the tree the way
         it was built
  BAD:   an employee on TWO projects has no home.
         One parent only. Real data is not a tree.

THE NETWORK MODEL (1970s)
─────────────────────────────────────────
  A GRAPH — records may have many parents, joined
  by explicit pointers.

  GOOD:  models many-to-many relationships
  BAD:   queries are written as POINTER-CHASING
         code. To answer a new question you write a
         new traversal program, and if the pointer
         layout changes, every program breaks.
─────────────────────────────────────────

The Shared Flaw
─────────────────────────────────────────
  In both, the QUERY depends on the physical
  layout. You navigate the structure by hand.

  Change how data is stored, and every application
  that reads it must be rewritten. This is exactly
  Chapter 1's sixth failure, at industrial scale.
─────────────────────────────────────────

3. Codd's Idea

In 1970, Edgar Codd proposed something that sounds unremarkable now and was radical then: store everything as tables of rows, and query them with logic rather than navigation.

The Relational Model, in Three Points
─────────────────────────────────────────
  1. ALL data is in RELATIONS (tables). No
     pointers, no nesting, no privileged access
     path.

  2. Rows are related by MATCHING VALUES, not by
     stored pointers. An order references a
     customer by holding that customer's id.

  3. Queries describe the RESULT SET you want.
     The system decides how to compute it.
─────────────────────────────────────────

The Consequence That Changed Everything
─────────────────────────────────────────
  PHYSICAL DATA INDEPENDENCE.

  Because queries never mention how data is stored,
  the storage can change completely — add an index,
  reorder rows, repartition the table — and every
  existing query keeps working, and often gets
  faster without being touched.

  The hierarchical and network models could not
  offer this. It is the single reason relational
  won.
─────────────────────────────────────────

Chapter 3 develops this into the three-level schema architecture.

4. Why Relational Won

Five Reasons, in Order of Importance
─────────────────────────────────────────
  1. DATA INDEPENDENCE
     Storage changes do not break applications.

  2. A DECLARATIVE LANGUAGE
     SQL is learnable by non-programmers and lets
     the optimiser improve queries you already
     wrote (Module 6).

  3. A MATHEMATICAL FOUNDATION
     Relational algebra (Module 2) means query
     rewriting is PROVABLY correct — the optimiser
     can transform your query knowing the result
     is identical.

  4. ENFORCED INTEGRITY
     Keys and constraints are declared in the
     schema and hold for every writer.

  5. FLEXIBILITY OF QUESTIONS
     Any table can be joined to any other on any
     matching values. You are not limited to the
     paths someone anticipated.
─────────────────────────────────────────

Point 5 is worth dwelling on. In a hierarchical database, a question nobody planned for might be unanswerable without restructuring the data. In a relational one, it is a JOIN you write in the morning.

5. What Relational Is Bad At

Being fair about this now saves a lot of confusion in Module 9.

Genuine Weaknesses
─────────────────────────────────────────
  DEEP HIERARCHIES     "find all descendants" in a
                       tree of unknown depth needs
                       recursive queries and is
                       awkward.

  GRAPH TRAVERSAL      "shortest path between two
                       people" is many self-joins.
                       A graph database does this
                       natively.

  SCHEMA CHURN         if every record has different
                       fields, a fixed schema
                       fights you.

  HORIZONTAL SCALE     joins across machines are
                       expensive, which is why
                       distributed systems often
                       give up joins (Module 9).

  OBJECT MISMATCH      application objects nest;
                       tables do not. This is the
                       "object-relational impedance
                       mismatch" that ORMs exist to
                       paper over.
─────────────────────────────────────────

The Honest Position
─────────────────────────────────────────
  Relational is the right DEFAULT, not the right
  answer to everything.

  It is the default because most data really is
  tabular, most applications really do need
  integrity and transactions, and the cost of
  being wrong about that later is high.

  Module 9 covers the alternatives and when they
  genuinely win — after you understand what you
  would be giving up.
─────────────────────────────────────────

6. Summary & Next Steps

Key Takeaways

A data model defines the allowed shapes, the allowed operations, and the enforceable constraints — and that choice determines which questions stay cheap for years.
Hierarchical and network models forced queries to navigate the physical layout, so any storage change broke every application.
Codd's contribution was relating rows by matching values rather than stored pointers, and describing results rather than navigation — which delivers physical data independence.
Relational is the right default rather than a universal answer; it is genuinely weak on deep hierarchies, graph traversal, schema churn, and horizontal scale.

Concept Check

In the network model, why did changing the physical layout break existing programs?
What does "physical data independence" mean concretely, and which of the three points of Codd's model produces it?
Name a data shape where a relational database is a poor fit, and say why.

Next Chapter

→ Chapter 3: DBMS Architecture

Jr Codex — 1-on-1 Personalized Coaching | Back to Module Index | Back to DBMS Index