The relational model and data independence

The relational model is usually introduced as a way of storing data in tables. That description puts the emphasis in the wrong place. Codd (1970) set out to protect users of large data banks from having to know how the data is organised inside the machine. What he committed to was data independence. The questions a user can ask must survive a change in how the data is kept.

Read that way, the model's subject is which facts can be named and which can be combined. This first unit settles the promise the other nine inherit.

Independence is a claim about change

Codd's own summary states the target. Activities of users, at a terminal, on a shared device or through a screen reader, and most application programs, must remain unaffected when the internal representation of data changes. The same holds for some aspects of the external representation (Codd, 1970). He adds why the question matters. Changes in data representation will often be needed, as a result of changes in query, update and report traffic and of natural growth in the types of stored information.

Bachman (1973), arguing from the navigational, network position, treats the programmer as a navigator. The navigator traverses explicit pointers and helps to design the structure being traversed. On that account the access path is written into the program, so a change in storage is a change in the program. Codd (1982) later gave his own account of the origin of the model, and of the productivity argument that independence was meant to serve.

A worked illustration makes the claim concrete. A report is written against a view that joins an orders table to a customers table. The team then adds an index, moves a rarely used column into a side table and changes the storage engine. None of that changes the external representation, so the report keeps running untouched. The illustration shows the intended property rather than a general immunity: Codd protected only some aspects of the external representation, and removing a column from the view does break the programs that read it.

Independence had to be engineered, not declared

The relational model was proved buildable at production quality rather than merely proposed. The System R authors describe a database management system offering a high-level relational interface. That interface isolates the end user from underlying storage structures, with multiple relational views, authorisation, integrity assertions, triggered transactions, and a logging and recovery subsystem (Astrahan et al., 1976). They are careful to call the system a research vehicle rather than a product.

Chamberlin and colleagues (1981) then record what the project cost. System R was constructed to demonstrate that the usability advantages of the relational model were realisable in a system with the complete function and high performance needed for everyday production use. Views, integrity assertions and recovery are not decoration on independence. They are what makes a promise of independence safe to make.

Where a fact cannot be named, design stops being systematic

The model's sharpest critic was its author. Codd (1979) reports that several investigators had been exploring semantic models. The intent was to capture more of the meaning of the data, so that database design can become more systematic and the database system itself can behave more intelligently. His response was to extend the relational model to support atomic and molecular semantics, adding rules for insertion, update and deletion and new algebraic operators.

Hammer and McLeod (1981) present SDM, which describes a database in terms of the kinds of entities present, their classifications and groupings, and the structural interconnections among them. It accommodates derived information in the structural specification, so that the same information can be viewed in several ways. Hull and King (1987) survey the field and explain the pressure. Most common systems represent information in a simple record-based format, while semantic modelling provides richer constructs for the structurally complex interrelations typical of commercial applications.

A fact that cannot be named as a value cannot be constrained by the model. The constraint then moves into application code, which is exactly where the independence claim does not reach.

Combining facts is where the model earns its keep, and where it bites

Independence lets a question be expressed as a combination of relations rather than as a path through storage. Answering a query often requires the natural join of two or more relations. As Aho, Beeri and Ullman (1979) observe, the result of a join may not be what one expects. They give efficient algorithms to decide whether a join has the intuitively expected value and is lossless, and whether a set of relations has a subset with a lossy join. They treat this first under functional dependencies and then under multivalued dependencies.

That result turns decomposition into a proof obligation. Abiteboul, Hull and Vianu (1995) set out the mathematical ground beneath it at book length, covering relational algebra and calculus, dependencies, Datalog, complexity and expressive power. The commitment the theory describes is that the relations into which a schema is divided must be shown to recombine without inventing rows.

The obligation has a concrete shape. Take a table recording which employee is in which department and on which project, with each employee in exactly one department: employee, department, project. Split it into one relation for the departments of employees and one for the projects run in each department. Join them back, and the join does not recover the original rows. An employee in Sales pairs with a Sales project that never involved them, so the answer carries combinations nobody entered. The example is constructed to exhibit the mechanism rather than drawn from a failed system. Aho, Beeri and Ullman (1979) give the algorithm that decides when such a split is safe.

The extensions grew out of the model rather than replacing it

Two later systems tested the model's limits and stayed inside it. Stonebraker and Rowe (1986) present the preliminary design of POSTGRES, the successor to INGRES. Its main design goals included richer data types, rules and inference that the relational systems of the time did not provide. Kim (1990) defines the object-oriented database on a small set of central concepts, discusses common misconceptions about what makes such a system object-oriented, and outlines research directions. His critique is that the type system was too weak for complex objects, which is a reason to add object identity and encapsulation.

Neither response proposed giving up the declarative question, and the standards have since moved. SQL/PGQ (ISO 9075-16, 2023) brought property-graph pattern matching inside SQL, while GQL (ISO 39075, 2024) was ratified as the first separate graph query standard. Gheerbrant and colleagues (2025) build core models of both and locate the expressiveness gaps their next versions must close.

Contested question: absorbed, or still bounded by what can be named?

The literature disagrees about what the extensions demonstrate.

The first position holds that the model absorbs its challengers. Revisiting their earlier essay, Stonebraker and Pavlo (2024) argue that repeated efforts to replace the relational model or SQL have not displaced either. SQL has been extended to capture the good ideas of the alternatives, and the major advances in database management have come in relational systems.

The second position holds that the boundary is real, and that it is about nameability. Codd (1979) conceded that the bare model did not capture all meaning and added semantics to it. Hammer and McLeod (1981) built a model whose stated purpose was to capture more of an application environment than contemporary models can. Kim (1990) found the type system too weak for complex objects. Bachman (1973) had taken the opposite commitment altogether, that the access path belongs in the program. On this reading a fix that moves a fact outside the relational core marks a limit rather than an absorption.

What would settle it is a task class in which nameability is the measured bottleneck, with the cost of a schema change counted, including code outside the database. The 2024 essay argues from the history of adoption. The critiques argue from expressiveness. Neither measures the maintenance cost that the model's own founding paper made the objective. That comparison is the study the sources here do not contain.

Rate each side by its evidence. Stonebraker and Pavlo (2024) rest on the history of adoption, a retrospective reading rather than a measurement. Codd (1979), Hammer and McLeod (1981) and Kim (1990) rest on expressiveness, each offering a constructed formalism rather than a case. The strongest objection is that the model's own promise was productivity, so a critique that cannot price the maintenance it claims to save leaves the founding argument standing. While the dispute is open, a designer counts the code a schema change forces outside the database before calling the boundary a limit or an absorption.

Where the argument is heading

Stonebraker and Pavlo (2024) expect continued evolution rather than replacement, and locate recent progress inside relational systems. Codd (1979) and Hull and King (1987) name the durable agenda behind that progress: capture more of the meaning of the data without abandoning the declarative question. Kim (1990) shows what happens when the type system cannot carry the meaning. The question to carry forward is whether widening what can be named keeps the independence claim intact, or quietly returns the constraint to application code.

The sources this unit rests on

• Abiteboul, S., Hull, R. and Vianu, V. (1995). The standard mathematical treatment of relational and logic-based foundations: relational algebra and calculus, dependencies, Datalog, complexity and expressive power. Only the bibliographic metadata and the book's description were read, so it is cited for the shape of the formal ground rather than a result.
• Aho, A. V., Beeri, C. and Ullman, J. D. (1979). Aho, Beeri and Ullman give algorithms that decide whether the natural join of several relations is lossless, and whether a set of relations has a subset with a lossy join, first under functional dependencies and then under multivalued dependencies. That result is why a badly decomposed schema can return more rows than the facts justify.
• Astrahan, M. M., Blasgen, M. W., Chamberlin, D. D. et al. (1976). The System R authors describe a database management system with a high-level relational interface that isolates the end user from underlying storage structures, with views, authorisation, integrity assertions, triggered transactions and a logging and recovery subsystem. It reports a design being implemented, so it shows independence as machinery rather than a promise.
• Bachman, C. W. (1973). Bachman's Turing Award lecture argues from the navigational, network-model position that the programmer traverses explicit pointers and helps to design the structure being traversed. The indexed record carries the award citation rather than a research abstract, so it is cited for the position, on which the access path belongs in the program.
• Chamberlin, D. D., Astrahan, M. M., Blasgen, M. W. et al. (1981). Chamberlin and colleagues describe the three principal phases of the System R project, which was built to show that the relational model's usability advantages were realisable with the complete function and high performance needed for production use. It records what had to be engineered before the model displaced the navigational systems, so independence is bought rather than declared.
• Codd, E. F. (1970). Codd argues that users of large data banks must be protected from having to know how the data is organised in the machine, and that most application programs must remain unaffected when the internal representation, and some aspects of the external representation, change. He models the data bank as relations and defines a normal form for them. This is the unit's central claim.
• Codd, E. F. (1979). Codd reports the exploration of semantic models whose intent was to capture more of the meaning of data so that database design can become more systematic and the system can behave more intelligently, and he extends the relational model to support atomic and molecular semantics with new rules for insertion, update and deletion. It is the model's own author conceding that the bare model does not name every fact.
• Codd, E. F. (1982). Codd's 1981 Turing Award lecture, recounting the origin of the relational model, relational algebra, relational calculus and normalisation, and arguing for the model as a practical foundation for productivity. The journal abstract is the award citation, not a research abstract.
• Gheerbrant, A., Libkin, L., Peterfreund, L. and Rogova, A. (2025). Core models of the SQL/PGQ and GQL property-graph standards, locating the expressiveness gaps their first versions leave. It shows the SQL standard absorbing graph query while a separate graph standard was ratified. It is a formal study, not an adoption measure.
• Hammer, M. and McLeod, D. (1981). Hammer and McLeod present SDM, a semantics-based description and structuring formalism that describes a database in terms of the kinds of entities present, their classifications and groupings, and their structural interconnections, and accommodates derived information. It concretises what capturing more meaning looked like in a working formalism.
• Hull, R. and King, R. (1987). Hull and King survey semantic data modelling, which added richer structuring constructs to record-based models, and situate it beside knowledge representation and the emerging object-oriented paradigm, cataloguing constructs for the structurally complex interrelations typical of commercial applications. It supplies the vocabulary of entities, relationships and constraints the unit uses.
• Kim, W. (1990). Kim defines the object-oriented database on a small set of central concepts, discusses common misconceptions about what makes such a system object-oriented, and outlines research directions. The critique that motivates the model is that the relational type system was too weak for complex objects, so it stayed inside the model's vocabulary.
• Stonebraker, M. and Pavlo, A. (2024). Revisiting their earlier essay, the authors argue that repeated efforts to replace the relational model or SQL have not displaced either, that SQL absorbed the best ideas of the alternatives, and that the major advances have come in relational systems. It is the strongest pro-relational position the unit holds, and it names where the field says it is going.
• Stonebraker, M. and Rowe, L. A. (1986). Stonebraker and Rowe present the preliminary design of POSTGRES, the successor to INGRES, whose main design goals were richer data types, rules and inference that the relational systems of the time did not provide. It shows the extension argument being made from inside the relational tradition, which is why the model absorbed it.