The Network Data Model, formalized by the CODASYL (Conference on Data Systems Languages) consortium in the late 1960s, was designed as a successor to the Hierarchical Model to represent more complex data relationships. Its core concept is the schema, which is composed of record types (similar to entity types) and set types. Unlike the Hierarchical Model’s strict tree structure, the Network Model allows a record to have multiple parents. This is achieved through “owner-coupled sets,” where a set type defines a one-to-many relationship between an owner record and member records. This structure directly models many-to-many relationships by allowing a record to be a member in multiple sets. Data is navigated via these sets using pointers, making it very flexible and efficient for complex queries but also complex for programmers to use and maintain
Structure of a Network Model:
-
Records (The Nodes)
The fundamental unit of data storage in the Network Model is the Record. Similar to an “entity” in ER modeling or a “row” in a relational table, a record represents a real-world object, such as a specific Student, Course, or Book. Each record is a collection of Data Items (fields or attributes), like Student_ID, Name, and Major. Records are grouped into Record Types, which define the structure for all records of that kind (e.g., all students share the same record type). The actual instances of these records form the tangible data within the database.
-
Sets (The Relationships)
The core structural element that defines relationships is the Set. A set represents a one-to-many relationship between two record types: an Owner record type and a Member record type. For instance, a COURSE-ENROLLMENT set could have the COURSE record type as the owner and the STUDENT record type as a member. This signifies that one course can have many enrolled students. Crucially, a single record type can be an owner in one set and a member in several others, creating the complex “network” of relationships that gives the model its name.
-
Pointers (The Physical Links)
The relationships defined by sets are physically implemented in the database using Pointers. These are actual memory addresses stored within the records that create a chain linking them together. A typical implementation uses a linked list: the owner record points to the first member record, and each member record points to the next member in the set and back to the owner. This pointer-based architecture is what makes data navigation in the Network Model extremely fast, as moving from an owner to its members or traversing a set requires following these direct physical links.
-
Schema and Data Manipulation Language (DML)
The overall structure—all record types and set types—is defined in the Schema, which is the database’s blueprint. To interact with the data, a procedural Data Manipulation Language (DML) is used. Unlike the declarative SQL of relational databases, where you ask “what” you want, a programmer using a Network DML must specify “how” to get it. This involves navigating through the database one record at a time by finding a starting record (e.g., a specific course) and then using FIND NEXT, FIND OWNER, and GET commands to traverse the sets and retrieve related data.
Uses of Network Data Models:
-
Complex Manufacturing and Bill of Materials
The Network Model excelled at managing complex product structures, such as a Bill of Materials (BOM). A single assembly, like a car, is composed of many sub-assemblies (engine, chassis), which themselves are made of smaller parts. This creates a many-to-many relationship: a part is used in many assemblies, and an assembly contains many parts. The Network Model’s ability to have a record be a member of multiple sets directly represented this complexity, allowing efficient navigation from a finished product all the way down to its most basic raw materials, which was crucial for Manufacturing Resource Planning (MRP) systems.
-
Telecommunications and Network Management
The model was naturally suited for managing physical networks, such as telephone systems or computer networks. A network is composed of nodes (switches, routers) and connections (lines, circuits) between them. The Network Model could represent switches as owner records and the circuits emanating from them as member records. A single circuit record could also be a member in a set owned by another switch, perfectly mapping the interconnected web. This allowed engineers to efficiently trace communication paths, manage capacity, and diagnose connection failures by navigating the direct pointer-based links between network components.
-
Early Banking and Financial Transaction Systems
High-volume transaction processing in sectors like banking was a key use case. A customer’s account, as an owner record, could be linked to thousands of transaction records (deposits, withdrawals) as members. The direct pointer chains allowed for extremely fast retrieval of all transactions for a specific account in chronological order. Furthermore, the model’s inherent integrity ensured that every transaction was permanently linked to its account, preventing orphaned records. This performance and reliability were essential for batch processing end-of-day statements and for providing quick account history lookups in early online banking systems.
-
Scientific and Research Databases
In scientific domains like biology or chemistry, data relationships are often intricate and non-hierarchical. For instance, a chemical compound can be involved in multiple reactions, and a reaction involves multiple compounds. The Network Model allowed researchers to structure these complex interrelationships without redundancy. A “Compound” record could be an owner in one set (for its properties) and a member in multiple other sets (for each reaction it participates in). This flexibility provided a more natural and efficient way to store and navigate interconnected scientific data than the rigid hierarchical model that preceded it.
Limitations of Network Data Models:
-
High Complexity and Lack of Structural Independence
The Network Model’s main strength is also its primary weakness: complexity. The intricate web of pointers and sets makes the database structure exceedingly complex to design and implement. Furthermore, this leads to a lack of structural independence. Any change to the database schema—such as adding a new record type or relationship—requires modifying all the application programs that navigate that part of the network. This is because the application code is written with a specific access path in mind, making the system rigid, difficult to maintain, and expensive to evolve as business requirements change.
-
Navigational and Procedural Data Access
Unlike the declarative SQL used in relational databases, where a user specifies what data they want, the Network Model requires a navigational approach. Programmers must write procedural code that specifies how to get the data by manually navigating from record to record using commands like FIND NEXT and FIND OWNER. This makes application development time-consuming, error-prone, and dependent on a deep understanding of the physical database structure. The resulting programs are long, complex, and difficult to modify if query requirements change, placing a heavy burden on programmers.
-
Lack of Ad-hoc Query Capability
The model is ill-suited for unplanned, ad-hoc queries. Since every data access requires a pre-defined navigation path written into an application program, business users or analysts cannot directly ask spontaneous questions of the data. Answering a new query often requires a programmer to write and test a new program, which is a slow and costly process. This severely limits the flexibility and decision-support capability of the database, locking data away from end-users and making it impractical for business intelligence or dynamic reporting environments where query needs are constantly changing.
-
System Dependency and Maintenance Overhead
The Network Model creates a heavy dependency between the application programs and the underlying physical storage structure. The programmer is aware of and must manage the access paths via pointers. This low-level management leads to high maintenance overhead. As the database grows and evolves, tuning performance or reorganizing data can be a monumental task, often requiring changes across numerous application programs. This tight coupling makes the entire system fragile and difficult to port to new hardware or software platforms, resulting in vendor lock-in and high total cost of ownership.
