Network Databases - A 
Case Study 
Database Management Systems (MC-302) 
30​th​ April 2020 
─ 

 
 
 
 
Anish Sachdeva 
DTU/2K16/MC/13 
Delhi Technological University 

 
 1 
 

Index 

Network Databases 2 

Examples of Network Databases 4 

Integrated Data Store 4 
Integrated Database Management System (IDMS) 4 
Raima Database Manager 4 
TurboIMAGE 4 
Unisys OS 2200 Databases 5 

Advantages of Network Databases 6 

Conceptual Simplicity 6 
Capability to Handle Multiple Relationship Types 6 
Ease of Data Access 6 
Data Integrity 7 
Data Independence 7 
Database Standards 8 

Disadvantages of Network Databases 9 

System Complexity 9 
Operational Anomalies 9 
Absence of Structural Independence 9 

Bibliography 11 

 
 
 2 
 

Network Databases 
The ​network model​ is a database model conceived as a flexible way of representing 
objects and their relationships. Its distinguishing feature is that the schema, viewed as a 
graph in which object types are nodes and relationship types are arcs, is not restricted to 
being a hierarchy or ​lattice​. 
While the hierarchical database model structures data as a t​ ree​ of records, with each 
record having one parent record and many children, the network model allows each record 
to have multiple parent and child records, forming a generalized graph structure. This 
property applies at two levels: the schema is a generalized graph of record types connected 
by relationship types (called "set types" in CODASYL), and the database itself is a 
generalized graph of record occurrences connected by relationships (CODASYL "sets"). 
Cycles are permitted at both levels.  
The chief argument in favour of the network model, in comparison to the hierarchical 
model, was that it allowed a more natural modeling of relationships between entities. 
Although the model was widely implemented and used, it failed to become dominant for 
two main reasons which are: 
1. IBM chose to stick to the hierarchical model with s​ emi-network​ extensions in their 
established products such as I​ MS​ and DL/I.  
2. It was eventually displaced by the r​ elational model​, which offered a higher-level, 
more declarative interface.  
Until the early 1980s the performance benefits of the low-level navigational interfaces 
offered by hierarchical and network databases were persuasive for many large-scale 
applications, but as hardware became faster, the extra productivity and flexibility of the 
relational model led to the gradual obsolescence of the network model in corporate 
enterprise usage. 
The network model's original inventor was ​Charles Bachman​, 
and it was developed into a standard specification published in 
1969 by the Conference on Data Systems Languages (​CODASYL​) 
Consortium. This was followed by a second publication in 1971, 
which became the basis for most implementations. Subsequent 
work continued into the early 1980s, culminating in an ​ISO 
specification, but this had little influence on products. 
Bachman's influence is recognized in the term B
​ achman 
diagram​, a diagrammatic notation that represents a database 
schema expressed using the network model. In a Bachman 
diagram, named rectangles represent record types, and arrows 
 3 
 

represent one-to-many relationship types between records (CODASYL set types). 

 
Bachman Diagrams where the rectangular boxes represent entities and arrows represent 
one-to-many relationships 

 
 4 
 

Examples of Network Databases 

Some well-known database systems that use the network model include: 

1. Integrated Data Store 

Integrated Data Store​ (​IDS​) was an early n
​ etwork​ ​database management system​ largely 
used by industry, known for its high performance. IDS became the basis for the C​ ODASYL 
DataBase Task Group standards. 
IDS was designed in the 1960s at the computer division 
of General Electric (which later became H
​ oneywell 
Information Systems​) by ​Charles Bachman​, who 
received the ​Turing Award​ from the Association for 
Computing Machinery for its creation, in 1973. The 
software was released in 1964 for the ​GE 235​ computer. By 1965, a network version for the 
customer ​Weyerhaeuser Lumber​ was in operation. 

 
2. Integrated Database Management System (IDMS) 
CA IDMS​ (Integrated Database Management System) is primarily a n ​ etwork model 
(​CODASYL​) ​database management system​ for ​mainframes​. It was first developed at B ​ .F. 
Goodrich​ and later marketed by Cullinane Database Systems (renamed C ​ ullinet​ in 1983). 
Since 1989 the product has been owned by ​Computer Associates​ (now CA Technologies), 
who renamed it Advantage CA-IDMS and later simply to ​CA-IDMS​. 

3. Raima Database Manager 

Raima Database Manager​ (or R ​ DM​) is an ​ACID​-compliant embedded database 
management system designed for use in embedded systems applications. RDM has been 
designed to utilize multi-core computers, networking (local or wide area), and on-disk or 
in-memory​ storage management. RDM provides support for multiple application 
programming interfaces (APIs): low-level C API, C++, and S ​ QL​(native, ​ODBC​, ​JDBC​, ​ADO.NET​, 
and L​ abView​). RDM is highly portable and is available on ​Windows​, ​Linux​, ​Unix​ and several 
real-time or embedded operating systems. A source-code license is also available. 

4. TurboIMAGE 
TurboIMAGE​ is one of several names used to refer to a d ​ atabase​ developed by ​Hewlett 
Packard​ and included with the H
​ P3000​ ​minicomputer​. TurboIMAGE was also available on 
the HP250 ​minicomputer​. Originally released under the name IMAGE/3000 in 1972, it was 
later known as TurboIMAGE, IMAGE/SQL, and TurboIMAGE/XL. 
 5 
 

5. Unisys OS 2200 Databases 

The ​OS 2200​ database managers are all part of the Universal Data System (UDS). UDS 
provides a common control structure for multiple different data models. Flat files 
(sequential, multi-keyed indexed sequential – MSAM, and fixed-block), ​network​ (DMS), and 
relational​ (RDMS) data models all share a common locking, recovery, and clustering 
mechanism. OS 2200 applications can use any mixtures of these data models along with 
the high-volume transaction file system within the same program while retaining a single 
common recovery mechanism. 

 
 6 
 

Advantages of Network Databases 

The major advantages of a Network model are: 

1. Conceptual Simplicity 
Just like the hierarchical model, the network model is also conceptually simple and easy to 
design. We can easily imagine one-to-one or or many-to-one functional and relational 
dependencies and model it using the Bachman diagram. 
With the help of the Bachman diagram, we can see visually how our entities correlate to 
each other and as our bachman diagrams and also any other relationship diagrams are 
graph based. Implementing the graph based relationships in a graph based network style 
database is feasible and easy to achieve. 

2. Capability to Handle Multiple Relationship Types 

The network model can handle the one to many and many to many relationships which 
makes it highly robust in modelling real life relationships. In the real world the relationships 
that we observe and wish to model are highly complex and multi-faceted. 
They contain several attributes that can either be required or not. These attributes can 
then also be associated with other attributes of different relationships. The entities 
themselves present in the relationship can be modelled using various relationship types 
and these relationships can be easily represented by the Network Database Model which 
makes it highly robust and usable. 

3. Ease of Data Access 

Data in the network model is stored as a graph with nodes having multiple parents and 
multiple children. In a hierarchical database model a node can have multiple children which 
each store data, but a node can’t have multiple parents which limits its functionality and 
data searching and extraction capabilities. 
In the Network Database model the data for a particular entity is all stored together in one 
node and hence if we reach to our desired node, we can retrieve all relevant information 
for a particular node. In the Relational database we store data in multiple tables called 
relationships which are related to each other by primary keys and foreign keys (attributes 
of the entities). 
These relationships are then joined together using the common attributes to create 
relationships of higher dimensionality and then the data is extracted from these joined 
relationships. In the Network database model, we can extract data without creating joins as 
data can be stored as chunks in nodes. 
 7 
 

4. Data Integrity 
In the Network Database model a node or a data element can only be added once to a 
parent, that is a data can be added only if it is associated with some item. E.g. an order 
entry node can be added for a customer only if the customer exists in the database and the 
order will not be created without the existence of the customer. 
In the relational database model, we have seperate relationship tables and if we don’t 
specify constraints on attributes between correlated relationships, we can add, modify and 
delete tuples in correlated relationships and lead to a loss of data integrity as we might 
accidentally delete a customer without removing all her orders.  
Such integrity anomalies are not possible in a network model database as nodes must be 
created on other nodes on which they depend and deleting a parent node implies deleting 
all it’s child nodes. 

In a network model, no member can exist without an owner. A user must therefore first 
define the owner record and then the member record. This ensures the data integrity. 

5. Data Independence 
Data Independence is something that is highly desirable and required in modern 
databases. System architects do not wish to know or meddle with how the data is being 
stored physically or how the data will be represented in the available data servers. 
These days, building a data system is a very complex task as databases for large 
organizations can span multiple physical servers over multiple geographic locations and 
provide many inbuilt functionalities for data sharding, data storage and security. 

The network model draws a clear line of demarcation between the programs and the 
complex physical storage details. The application programs work independently of the 
data. Any changes made in the data characteristics do not affect the application program. 
The Network database model abstracts out how the database is stored on physical devices 
and provides the user with logical database charts that she can use to design the database. 
The Bachman diagrams can be used to easily design for the application and then the 
developer communicates with the database assuming it is a graph and is not bothered by 
the physical storage. 
The hierarchical database model does not encapsulate the physical storage mechanism as 
well, which makes the Network Database model a considerably better alternative. 
Note: ​The Relational Database model abstracts the physical layer very well and provides an 
excellent logical view for the developer to build the database for the application. 
 8 
 

6. Database Standards 
The network model was created to represent complex data relationships more effectively 
than the hierarchical model, to improve database performance, and to impose a database 
standard. 
The previous database model - the Hierarchical database model did not have any formal 
standard and when Charles Bachman was creating the Network Database model he 
explicitly expressed the need for a standardized database model so that multiple 
implementations by different vendors and people leads to a cohesive product that is 
similar experience and design process for developers. 
If developers learn and develop on a similar API across various vendors they will not have 
to worry about syntax or specific design API as they move from vendor to vendor or 
product to product, but will rather only have to worry about the Database model which 
they are using - the Network Database model. 
And this in turn would lead to them focussing more on the design aspect rather than 
syntax and peculiar vendor specification. 
The standards devised by the DBTG (Database Task Group of CODASYL Committee) 
form the basis of the network model. These standards were further enhanced by 
ANSI/SPARC (American National Standards Institute/Standards Planning and Requirements 
Committee) in the 1970s. All the network database management systems adhere to these 
standards. These standards comprise of a DDL and a DML that augments the database 
administration and portability. 
 

 
 9 
 

Disadvantages of Network Databases 

1. System Complexity 
The records in the Network Database model are stored as nodes on a parent node and/or 
are associated with some other node and as more and more records are added. This graph 
of entities representing both data and relationships grows further and further. 
The records in a Network Database model are stored as objects in a heap and only pointers 
are stored to all these objects which are then used to navigate to the desired location. This 
makes navigation and searching very cumbersome and also adds to system complexity as 
more and more entities are added and the graph grows exponentially with multiple 
children. 
Navigating to a particular node is not possible straight away as no pointer address is 
hashed and we will have to start from the root and then move on to the entities using the 
help of pointers which slows down the application and also makes the navigation process 
complex.  

2. Operational Anomalies 
As we have just seen above in the first disadvantage that navigating to a particular node is 
a cumbersome task. Similarly, performing an operation on a node such as Insertion, 
Deletion or Modification is also time consuming and complex. 
We first need to accurately find the node we should to perform our operation on using 
multiple pointers chained together. After arriving at the correct destination we need to 
perform our operation and also make sure that our operation on the node doesn’t affect 
it’s connected nodes in any manner. Deleting a node that had children we required can be 
catastrophic as deleting a node in the Network Database model also deletes all it’s pointers 
that it has to it’s child nodes which will make them unreachable and will be soon collected 
by the garbage collector (whenever it is run) 
We can also not add constraints like we do on Relational Databases that make relationships 
and tuples safe from certain operations and guarantee Data Integrity.  

3. Absence of Structural Independence 

Since the data access method in the network database model is a navigational system, 
making structural changes to the database is very difficult in most cases and impossible in 
some cases. If changes are made to the database structure then all the application 
programs need to be modified before they can access data. Thus, even though the network 
database model succeeds in achieving data independence, it still fails to achieve structural 
independence. 
 10 
 

Because of the disadvantages mentioned and the implementation and administration 

complexities, the relational database model replaced both the hierarchical and network 
database models in the 1980s. The evolution of the relational database model is 
considered as one of the greatest events-a major breakthrough in the history of database 
management. 
 11 
 

Bibliography 
1. Network Models​ [Wikipedia] 
2. Network Database​ [Techopedia] 
3. Database System Concepts​ by Silberschatz 
4. Network Models and their Advantages and Disadvantages​ [Data Models] 
5. Advantages and Disadvantages of Network Databases​ [Techwalla] 
6. Charles Bachman​ [Wikipedia] 
7. Integrated Data Store​ [Wikipedia] 
8. IDMS​ [Wikipedia] 
9. Raima Database Manager​ [Wikipedia] 
10. TurboIMAGE​ [Wikipedia] 
11. Unisys OS 2200 Database​ [Wikipedia]