The Problem With Separate Files
Early business computers stored information in files, often on magnetic tape or punched cards. A company might have one file of customers, another of orders and another of invoices, each written for a particular program. Reading a file meant going through it in order, which was fine for jobs such as printing every invoice but awkward for questions that crossed files.
Files also tended to duplicate data. If a customer’s address appeared in three files, a change had to be made in all three or the records would disagree. And because each program knew exactly how its file was laid out, changing a layout could mean rewriting every program that touched it. As business computing grew in the 1950s and 1960s, these problems became expensive.
Early Database Systems
During the 1960s, vendors and committees developed database management systems to separate the data from the programs that used it. Two designs were common.
In a hierarchical system, data is organized like a tree. Records have “parent” and “child” relationships, so a customer record might contain its orders beneath it. This works well when the data really is tree-shaped, but is awkward when a record belongs under more than one parent.
In a network system, records are linked by pointers into a more general graph. A group associated with the COBOL community produced influential specifications along these lines. Network systems were more flexible, but programmers had to navigate the links step by step, stating exactly which path to follow. The program was tied closely to the structure.
Codd’s Proposal
In 1970, Edgar F. Codd, a researcher at IBM, published a paper proposing a different way of thinking, usually called the relational model. His central idea was to describe data in terms of its meaning, not its storage layout or navigation paths.
In the relational model, data is arranged in tables, which Codd called relations. Each row is one record, and each column is one attribute. A table of customers might have columns for a customer number, a name and a city. A separate table of orders might have an order number, a date and the customer number of whoever placed it.
The shared customer number links the tables. Instead of copying a customer’s name into every order, the order stores only the number, and the name can be looked up when needed. A column used this way is called a key. If the customer moves, the address changes in one place.
Asking Questions Without Following Pointers
A second major benefit was in how users could query the data. With relational thinking, a person describes what they want, such as “all orders placed by customers in a given city,” and the system works out how to find it. The programmer does not have to specify the path through the storage.
Codd’s paper was mathematical and drew on set theory and logic. IBM researchers developed prototype systems in the 1970s, and a query language that became known as SQL grew out of that work. It was originally called SEQUEL, and it eventually became a widely adopted standard language for relational databases. Several other groups and companies also built relational systems, and multiple projects were active in this period.
Why It Took Time to Catch On
It is easy to think a good idea wins immediately, but that did not happen here. Early relational prototypes were often judged slower than hand-tuned older systems, since the software had to decide how to execute each request. Skeptics doubted whether the approach could be efficient enough for serious work.
Over time, advances in query optimization, in which the system chooses an efficient plan for each question, together with faster processors and hard disk drives, narrowed that gap. By the 1980s, relational products were being sold commercially in large numbers, and the model became the default for much business data.
How Tables Are Kept Tidy
Designers developed guidelines, often called normalization, for deciding how to split data into tables so facts are stored once. The aim is to avoid contradictions and wasted effort. Databases also gained transactions: a group of changes treated as a unit that either completes in full or not at all. This matters in settings like banking and reservations, where a partly finished update could leave records inconsistent.
Limits and Alternatives
Relational databases are not the answer to everything. Some kinds of data, such as large collections of documents, networks of connections or rapidly arriving streams of measurements, fit awkwardly into tables, and other designs have been developed for them, often grouped under the label “NoSQL.” These alternatives involve their own trade-offs, and which approach suits a project depends on the details. Relational systems have remained widely used alongside them.
Where You Meet Them
Relational ideas run in the background of much everyday software: stock control, school records, reservation systems and many websites. Hospitals and clinics rely on them for electronic health records, among other uses. The common thread is the original appeal of the model: store each fact once, link tables by shared keys, and let people ask questions without needing to know how the data is physically arranged.