The Dawn of Data Management: From Punch Cards to the Relational Model

<!-- 标签：#数据架构史 #关系模型 #IMS #CODASYL #ACID #数据库演化 --> The hum of IBM 1403 line printers filled the air of the data processing center at First National Bank of New York on a crisp October morning in 1967. In the corner, a stack of punch cards—each the size of a vintage postcard, perforated with 80 columns of holes, each hole representing a binary 0 or 1—towered nearly to the ceiling, holding the纸质 records of 2.3 million customer accounts. Clerks in starched white shirts moved between the card readers and the printers, their fingers stained with the ink of the punch machines, processing an average of 12,000 transactions a day: deposits, withdrawals, loan payments, each one a physical card that had to be located, updated, and filed back in its exact slot. A single misplaced card could mean a customer’s life savings vanished into the ether, or a fraudulent withdrawal went unnoticed for weeks. This was the state of data management in the mid-20th century: a labor-intensive, error-prone process that scaled poorly even as the volume of business data exploded. The 1960 U.S. Census alone required 10 billion punch cards, processed over 7 months with a 3% error rate that delayed congressional reapportionment for months. A 1962 flood in Chicago destroyed 2 million punch cards held by Citibank, erasing the account records of 300,000 customers and costing the bank $4 million (over $38 million in 2024 dollars) in recovery and lost business. For large enterprises, the limitations of manual data management were no longer an operational nuisance—they were an existential threat to growth.

The First Attempts at Automation: Hierarchical and Network Databases

The first response to this crisis was not a fundamental rethinking of data storage, but an effort to mechanize the existing manual workflow. In 1966, IBM released the Information Management System (IMS) for NASA’s Apollo program, designed to manage the 200,000 individual components of the Saturn V rocket: every bolt, seal, and circuit board had to be tracked across suppliers, test batches, and assembly lines, a task impossible to do with punch cards alone. IMS was built around a strict hierarchical data model: data was organized as a tree of records, with a single root record (the Saturn V rocket) branching down into subsystems (navigation, life support, engines), then into individual components. Each child record could have only one parent, a design that mirrored the physical structure of the rocket and made queries for component lineage extremely fast: to find the test record for a seal used in the lunar module’s engine, an engineer only needed to traverse the fixed path from root to engine to seal. But this rigidity came at a steep cost. If a component

<!-- 标签：#数据架构史 #关系模型 #IMS #CODASYL #ACID #数据库演化 #技术演化 --> The hum of IBM 1403 line printers filled the air of the data processing center at First National Bank of New York on a crisp October morning in 1967. In the corner, a stack of punch cards—each the size of a vintage postcard, perforated with 80 columns of holes, each hole representing a binary 0 or 1—towered nearly to the ceiling, holding the纸质 records of 2.3 million customer accounts. Clerks in starched white shirts moved between the card readers and the printers, their fingers stained with the ink of the punch machines, processing an average of 12,000 transactions a day: deposits, withdrawals, loan payments, each one a physical card that had to be located, updated, and filed back in its exact slot. A single misplaced card could mean a customer’s life savings vanished into the ether, or a fraudulent withdrawal went unnoticed for weeks. This was the state of data management in the mid-20th century: a labor-intensive, error-prone process that scaled poorly even as the volume of business data exploded. The 1960 U.S. Census alone required 10 billion punch cards, processed over 7 months with a 3% error rate that delayed congressional reapportionment for months. A 1962 flood in Chicago destroyed 2 million punch cards held by Citibank, erasing the account records of 300,000 customers and costing the bank $4 million (over $38 million in 2024 dollars) in recovery and lost business. For large enterprises, the limitations of manual data management were no longer an operational nuisance—they were an existential threat to growth.

The First Attempts at Automation: Hierarchical and Network Databases

The first response to this crisis was not a fundamental rethinking of data storage, but an effort to mechanize the existing manual workflow. In 1966, IBM released the Information Management System (IMS) for NASA’s Apollo program, designed to manage the 200,000 individual components of the Saturn V rocket: every bolt, seal, and circuit board had to be tracked across suppliers, test batches, and assembly lines, a task impossible to do with punch cards alone. IMS was built around a strict hierarchical data model: data was organized as a tree of records, with a single root record (the Saturn V rocket) branching down into subsystems (navigation, life support, engines), then into individual components. Each child record could have only one parent, a design that mirrored the physical structure of the rocket and made queries for component lineage extremely fast: to find the test record for a seal used in the lunar module’s engine, an engineer only needed to traverse the fixed path from root to engine to seal. But this rigidity came at a steep cost. If a component was used in multiple subsystems, it had to be duplicated across multiple branches of the tree, with no guarantee that updates would be applied consistently. In 1969, during pre-launch testing of the Boeing 747 (which also used an IMS-derived system for component tracking), a faulty seal used in both the left and right engine nacelles was found to have only one updated test record in the system: the right nacelle’s seal was never flagged as defective, a near-catastrophe that was only caught by a manual inspection days before the first commercial flight. For business use cases, the limitation was even more severe: a single product sold in 100 retail locations would need 100 separate copies in the database, and updating the product price would require 100 separate write operations, with no built-in mechanism to ensure all copies were updated correctly. IMS found commercial success far beyond aerospace: by 1975, it was the backbone of the SABRE airline reservation system developed by IBM and American Airlines, managing 100,000 daily flight bookings across 2,000 routes with 99.98% uptime. But its architectural constraints meant it could only be used for use cases with strictly hierarchical relationships, leaving a massive gap for applications with more complex, interconnected data.

The solution came from an unexpected quarter: the Conference on Data Systems Languages (CODASYL), a consortium of government, academic, and industry stakeholders formed in 1959 to standardize programming languages. In 1967, CODASYL formed the Database Task Group (DBTG) to design a database standard that could support the complex, many-to-many relationships required by business applications like inventory management, payroll, and customer relationship management. In 1969, the DBTG published its first report, defining the CODASYL network model—an extension of the hierarchical model that allowed a single child record to have multiple parent records, linked via explicit pointers called *sets*. Unlike the rigid tree structure of IMS, the network model represented data as a graph: records were nodes, and sets were directed edges connecting owner records to member records. A single product record, for example, could be a member of a "store-inventory" set (linked to 100 store records) and a "supplier-product" set (linked to 5 supplier records) simultaneously, eliminating the need for redundant storage. Sears, Roebuck and Co. adopted the CODASYL-based IDMS database in 1971 to manage its national