Hierarchical Model

Overview

The hierarchical data model organizes data as a tree of records: every record (called a node or segment) has exactly one parent, except a single root segment which has none. A parent can have many children, but a child can have only one parent — this is a strict 1:N relationship enforced by the structure itself, not by a constraint you declare.

This was the dominant model of the 1960s-70s, most famously implemented in IBM's Information Management System (IMS), which is still in production today for large mainframe banking and airline systems because it is extremely fast for the access patterns it was designed for.

How it works — a worked example

Think of a university's structure as a tree:

University
 └── College of Engineering
      ├── Dept: Computer Science
      │     ├── Course: DBMS
      │     └── Course: Operating Systems
      └── Dept: Electrical Engineering
            └── Course: Circuits

To fetch "all courses in Computer Science," you start at the root and navigate down parent→child pointers: University → College → Dept("CS") → Courses. This is called navigational access — there is no independent query language like SQL; the application program walks the tree using calls like GET UNIQUE / GET NEXT WITHIN PARENT (IMS's DL/I language).

A filesystem (directories containing files, each file in exactly one directory) is a hierarchical model you use every day.

Edge cases and trade-offs

• Many-to-many is the real killer. A course like "DBMS" might logically belong to both CS and Information Systems departments, but a tree cannot have one child under two parents. The classic workaround is duplicating the segment under each parent, which causes update anomalies (fix the course description in one place, forget the copy).
• Deletion is destructive by structure: deleting a parent record conventionally deletes its entire subtree (deleting a department deletes all its courses), so applications must be written carefully.
• Blazing fast for hierarchy-shaped, read-heavy workloads (e.g., an insurance policy → its claims → each claim's line items) because a child is physically stored near its parent on disk — no join is ever needed.
• Rigid: adding a new kind of relationship after the fact usually requires restructuring the tree and rewriting navigational code, not just adding a table.

Key takeaways / interview Q&A

Q: Why can't the hierarchical model natively represent an employee who reports to two managers (a matrix org)? A: Because every non-root node must have exactly one parent; a second reporting line would require a second parent pointer, which the tree structure disallows. You'd have to duplicate the employee record under each manager.

Q: What replaced the hierarchical model, and why? A: The relational model (Section 3.3), because it decouples logical queries from physical navigation and handles many-to-many relationships cleanly through join tables — at some cost in raw navigational speed.