Charles Bachman and IDS: Navigational Databases Before the Relational Model
Charles Bachman's Integrated Data Store turned database management into a reusable systems layer, organizing records as explicit networks that programs navigated through named relationships.
Database management emerged from a manufacturing information problem
In the early 1960s, General Electric wanted a reusable way to support manufacturing information systems instead of having every department invent its own file-handling conventions. Charles W. Bachman led work that produced the Integrated Data Store, or IDS, alongside GE’s Manufacturing Information and Control System. Bachman’s later historical account describes IDS as a direct-access database management system assembled from techniques such as data descriptions, list processing, recovery, restart and transaction-oriented processing.[1]
Computer History Museum accounts place the first production IDS lineage in this same GE effort and emphasize that it made database management a distinct software layer rather than a one-off collection of application files.[2]
IDS represented relationships as explicit paths through records
IDS organized records into networks connected by relationships that application programs could follow. This style later became known as the navigational or network database model because a program typically reached data by moving from one record to related records through predefined paths.[2]
The design matched many business processes naturally: a part could belong to an assembly, an order could connect to line items, and a customer could connect to transactions. But the program had to understand the route it should take through those relationships.
Navigation made access efficient but exposed structure to programs
The strength of the model was also a constraint. A programmer could exploit known access paths efficiently, yet application logic became coupled to the database’s structure. Later relational work would attack exactly this dependence by asking whether users could state what data they wanted without specifying how to traverse to it.
Bachman’s diagrams made data structures visible
Bachman also introduced data-structure diagrams that visually represented record types and their links. Computer History Museum describes these diagrams as a way to map the novel network structures clearly enough for designers and programmers to reason about how records were connected.[2]
The diagrams mattered because database design was becoming an architectural activity. The structure of information could be discussed separately from the COBOL procedures that consumed it.
A database schema became something teams could inspect
Once relationships were represented explicitly, teams could review a database as a model rather than only as scattered file layouts and pointer-manipulation code. That shift helped establish data modeling as a distinct part of software design.
IDS joined database operations to existing programming languages
The IEEE Computer Society’s biography of Bachman notes that IDS integrated database facilities into COBOL and provided a logical framework for large online collections of interrelated data.[4]
This host-language approach was pragmatic. Business applications did not stop being procedural programs; instead, database operations became specialized statements embedded in the languages organizations were already using.
The database system began to mediate between applications and storage
That mediation was a major conceptual step. Rather than every program owning its private file format, a DBMS could provide shared description, access and recovery services to many applications.
CODASYL generalized the network database approach
The CODASYL Data Base Task Group standardized a database approach built around separate data-description and data-manipulation facilities that could be used from host languages. The 1971 report formalized ideas that had grown out of systems such as IDS and helped spread the network model across multiple vendors.[5]
Bachman’s participation in this standardization meant that the concepts moved beyond one GE product family. Network database systems became an important commercial model for mainframe data processing.
Standardization multiplied the model’s practical reach
A common vocabulary for schemas, sets and manipulation operations made it possible for vendors and users to treat database management as a product category rather than a custom application technique.
The model assumed that structure and access path were closely related
In navigational systems, the route through the data was part of the programmer’s mental model. Charles Bachman’s famous description of the programmer as a navigator captured this world: useful performance came from understanding the graph of records and choosing paths through it.[4]
This was not an accidental flaw in an immature system. It reflected the hardware economics and engineering priorities of the period, when storage was expensive and predictable access paths could be valuable.
Relational databases challenged the need for navigation
Edgar Codd’s relational model later argued that users and application programs should be insulated from the physical organization of data. That proposal did not erase IDS’s historical importance; it defined a different abstraction boundary. The contrast between navigation and declarative access became one of the central debates in database history.
Bachman’s work therefore belongs beside Codd’s rather than beneath it: IDS demonstrated that a general DBMS could manage shared business data at scale, while relational systems later changed how programmers described what they wanted from that database.
Why IDS belongs in coding history
IDS helped turn data management into reusable systems software. It supplied explicit schemas, shared access services, recovery ideas and a network model that influenced CODASYL and commercial database products for years.[1][3]
Its legacy is also conceptual. The limitations of navigational programming made the value of later data independence easier to see. Database history is not a straight line from a wrong model to a right one; it is a sequence of changing abstractions shaped by hardware, applications and the cost of complexity.
Works Cited
- 01
- 02Computer History Museum — Charles W. Bachman profile computerhistory.org
- 03Computer History Museum — Assembling the Integrated Data Store (IDS) computerhistory.org
- 04IEEE Computer Society — Computer Pioneer: Charles Bachman history.computer.org
- 05CODASYL Data Base Task Group — 1971 Report bibliographic record books.google.com
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead