Integrated Data Store — Charles Bachman Builds the First DBMS at General Electric

In 1963 a small team inside General Electric had a program running that sat between application programs and the disk, and that would not let those programs touch the disk files themselves. Every request to store, retrieve, modify or delete a record went through it. It was called the Integrated Data Store, IDS, and its designer was Charles W. Bachman.

Nobody at the time called it a database management system. The phrase did not yet exist as a category. The historian Thomas Haigh, who has written the most careful account of it, is wary of "firsts" and says plainly that IDS built on earlier file management and report generation software. His conclusion is still unambiguous: "if any system deserves the title of 'first database management system' then it is clearly IDS."

Why General Electric Needed IDS

Bachman came to GE in 1960 after ten years at Dow Chemical, where he had ended up running corporate data processing. GE put him in a production control services group in New York whose job was to try new methods—operations research, simulation, automation—that might be applied across the company's many businesses.

The goal of the moment was the "totally integrated management information system": one system tying together sales, accounting, inventory and production, so managers could see current figures instead of last week's batch run. Almost every attempt failed. Each application kept its own files on magnetic tape, in a layout fixed by its own code. Integrating two applications meant one program's output tape became another's input, and every change to a field rippled through every program that read the file.

Bachman's group was building such a system anyway. It was called MIACS, the Manufacturing Information and Control System, and its testbed was a GE factory in Philadelphia; Haigh's 2016 account places the prototype in the firm's Low Voltage Switch Gear department. MIACS had to handle scheduling, order dispatching, receiving, inventory and parts explosion on one machine, a GE 225 with roughly the equivalent of 40 Kbytes of memory. Disk drives had arrived, but the operating software of the era gave programmers almost no help in using them. Finding where on a disk a given record lived was the hard part, and only elite programmers could do it efficiently.

IDS was Bachman's answer: build the disk-handling once, put it in one place, and make every application go through it.

What IDS Actually Did

The timeline Haigh reconstructs from GE's archives is specific. Detailed functional specifications were complete by January 1962, and Bachman was presenting the planned system to the in-house customers by May of that year. An initial prototype was operational in early 1963, called from GE's own GECOM language. Bachman told Haigh that a prototype installation was tested with real data in the summer of 1963 and ran twice as fast as a custom-built manufacturing control system doing the same work. A higher-performance version, with the application code moved to assembly language for speed and memory, followed in 1964.

Three features are what make historians call it a DBMS rather than a clever file library:

• Programs never touched the files. Applications called IDS, and IDS performed the operation on their behalf.
• The metadata lived outside the programs. IDS kept its own description of record types and the relationships between them—customers to their orders, for instance. In the first version this metadata was punched onto specially formatted cards rather than written in a data description language, but new elements could be added without deleting existing records.
• Relationships were part of the stored structure. Records were linked in chains, so a program could move from an owner record to its members and back. This is what was later called the network data model, and Bachman drew it with a diagramming technique of his own—the data structure diagram, which the ACM biography calls the direct ancestor of the diagrams database designers still use to show tables and the connections between them.

IDS also ran with a small transaction-oriented controller of Bachman's design, the Problem Controller. Together they occupied about 4,000 words of memory in a machine that might have only 8,000, and took over the computer almost entirely. Users queued "problems"; the controller loaded the right application program for each one in priority order.

What IDS lacked is equally instructive. The first version had no backup and recovery; that was added in 1964 by the International General Electric team that ran the first production installation, using a tape that logged each transaction and the database pages before and after it changed them. The first packaged versions had no access control and no way to run an ad hoc query without writing a program.

From GE Product to Weyerhaeuser and IDMS

GE publicly announced IDS as a supported package for its computer customers in October 1964. As was normal for manufacturer software then, it came with the hardware at no extra charge. (Wikipedia gives the GE 235 as the release platform; Haigh's work names the GE 225. Both belong to GE's 200 series.)

The first large outside application followed quickly. For Weyerhaeuser, GE built WEYCOS, which Haigh describes as fully operational by 1965: the Problem Controller and IDS on a computer linked to Teletype terminals across the country, so remote offices could update records and ask for information directly. Weyerhaeuser credited it with cutting order processing from weeks to days.

The longest-lived descendant came by a side door. B.F. Goodrich Chemical, a GE computer user, received the GE 225 version's source code; when Goodrich management standardised on IBM, its Dick Schubert converted IDS to run on the IBM System/360, Bachman recalled. That conversion became IDMS, sold by Cullinane. Haigh notes IDMS was still being supported by Computer Associates, with a release in 2014.

Commercially IDS was handicapped by its platform. Haigh judges it more flexible than IBM's IMS and several years earlier, but GE held less than a tenth of IBM's share of the computer market, and software then ran only on its maker's machines.

How IDS Shaped Every Database Since

IDS spread through a standards committee rather than through sales. Bachman joined the CODASYL group that became the Data Base Task Group, and its reports turned his IDS design into the network data model and the CODASYL database standard proposal. That committee, more than any product, popularised the idea of a "data base management system" with separate languages for defining and manipulating data.

In 1973 Bachman received the ACM Turing Award. The ACM's biography notes he was the first laureate without a Ph.D., the first trained in engineering, and the first to win for a specific piece of software. His Turing lecture, "The Programmer as Navigator," described programs steering through a web of linked records—the network model's view of the world.

That view was already under challenge. Edgar Codd's relational model of 1970 proposed that applications should state what data they want, not which pointers to follow. The two sides met in a debate at an ACM workshop in 1974, remembered as a milestone of the field; by the end of the 1990s relational systems had eclipsed the CODASYL ones.

Even so, the shape Bachman gave the DBMS outlived his data model: one piece of software that owns the stored data, keeps its own description of it, mediates every program's access, and enforces the relationships between records. Relational databases kept that template and moved the relationships into queries and referential integrity constraints. The diagrams that database designers draw of tables joined by lines descend from the ones Bachman drew for MIACS.