Network Model

Overview

The network model generalizes the hierarchical model by letting a record have multiple parents, turning the strict tree into a more flexible graph of records. It was standardized by CODASYL (Conference on Data Systems Languages) in the late 1960s, so it's often called the CODASYL model. Products like IDMS (Integrated Database Management System) implemented it and were widely used in enterprise mainframe systems.

How it works — sets and owners/members

The core building block is the set: a named relationship between one owner record type and one or more member record types (a 1:N relationship). Crucially, a member record can belong to multiple sets, meaning it can have multiple owners — this is exactly what a tree can't do.

Worked example — a parts/suppliers system:

Supplier ──(supplies set)──> Part
Warehouse ──(stocks set)───> Part

Here, Part is a member of both the supplies set (owned by Supplier) and the stocks set (owned by Warehouse). In the hierarchical model this would force duplicating Part under each parent; in the network model, Part genuinely has two owners connected via distinct pointer chains.

Access is still navigational, using a language like CODASYL's DML: you FIND an owner record, then FIND NEXT WITHIN <set-name> to walk member records — the application programmer must know the set structure and write explicit traversal code, there's no declarative query language.

Edge cases and trade-offs

• Solves the many-to-many problem the hierarchical model struggled with, by allowing multiple owner pointers per record — a genuine structural advance.
• Still navigational and schema-rigid: every possible traversal path (every "set") must be designed into the schema up front. An unanticipated query (walk from Part to Supplier when no set was defined that way) may require a full schema/program redesign.
• High programming complexity: application code is tightly coupled to the physical set structure; changing the schema often means rewriting application logic that walked those pointers — this brittleness is precisely what Codd's relational model (1970) was invented to fix.
• Performance: like the hierarchical model, pointer-chasing is very fast because there's no query optimizer overhead — but that speed comes at the cost of flexibility and higher development cost.

How this differs from a modern graph database (Section 3.9)

Don't confuse the network model with modern graph databases like Neo4j. Both use "nodes and connections," but the network model's sets are rigid, schema-defined, application-navigated pointer structures from the 1970s with no declarative query language, whereas modern graph databases expose a flexible property graph with a declarative traversal language (e.g., Cypher) and can add new relationship types at runtime without a schema redesign.

Key takeaways / interview Q&A

Q: What is the key structural advantage of the network model over the hierarchical model? A: A member record can participate in multiple sets, i.e., have multiple owners — natively representing many-to-many relationships that hierarchical trees can only fake via duplication.

Q: Why did the network model still get replaced by the relational model? A: Because it required all access paths to be predefined as sets and navigated procedurally in application code, making schema evolution and ad-hoc queries costly — problems the relational model solved with declarative query languages and physical data independence.