The motivating idea behind Codd's relational model wasn't data storage at all. Shared data storage was, to him, merely a means to an end: efficient, easily developed and debugged, applications.
Basically the problem he was responding to was the clumsiness of COBOL, the single user orientation of the batch mentality, and the combinatorial complexity of application and interface debugging as business computing moved from after the fact data processing to real time operational support.
Thus the "future System" his work contributed to was envisaged as an interactive database machine with a combined data management interface and report generator.
That's why, when IBM finally released it as the System 38, it completely lacked any traditional development environment and did not support COBOL - in fact, it explicitly did not support most of the things the data processing profession knew to be absolutely essential.
As a result the professionals refused to touch it, but a few developers, whether enterprenuerial or just uninformed isn't clear, did buy in and started to carve out specific niches for it. In particular the model quickly proved a nearly perfect fit for truly interactive tasks like warehouse and supply management -where neither order processing nor receiving functions follow a predictable schedule and there's competitive value in getting them done in near real time.
The underlying applications model making this possible was that of the database as the roots and trunk of an applications tree with hundreds of different branches and leaves, all independent, but all inter-dependent too.
Thus one user could be querying the database for order detail prior to marking items as received, while somebody else could be viewing the same records for availability and in fact sell arriving product before it was even marked as moved to storage.
The key to this was RPG - a report generator language with some minor extensions enabling it to handle CRUD calls to the microcode System/R database underlying the Operating System facility the System 38 shipped with. Basically RPG implemented the idea that applications are just views on data - I may want the data barbecued while you want it parboiled, but it's the same data and we're both just borrowing it from the same data store to look at.
Codd's rules were intended to protect both systems and data integrity in this type of multi-access environment. Thus concepts like referential integrity make sense within the database - because allowing something like the deletion of the name row for a current subscriber in a magazine application would violate data integrity constraints.
Codd doesn't go beyond that. The two other ideas closely tied to database functions today, stored procedures and triggers, have unrelated origins and really have nothing to do with data storage or applications models.
In particular stored procedures are a solution to the serialisation problem that arises from Microsoft's client-server architecture. In client server, the client does the processing, the server hosts the data - meaning that there's no good way to resolve serialisation issues when the time between reading and writing records differs between PCs accessing the data. Stored procedures avoid this by moving the application to the server -thereby violating client-server, but letting people deploying desktop PCs pretend otherwise.
RPG, however, had been developed in the late sixties and briefly tried (along with System/R) on the System 370 but had never picked up much market support. As a result it reflected, when released with the System 38, hardware assumptions and applications ideas that were, by then, ten years out of date.
One of the more interesting applications oriented papers published during that period was Moshé Zloof's "Query-by-Example: A Data Base Language" (IBM Systems Journal 16(4): 324-343, 1977). This was "not widely understood" at the time, but a few years later led the future founders of Unify corporation to envisage a forms based application design for a Red Cross application.That project eventually led to Accell/SQL, Vision, and the co-operative processing model in which the client handles display, and the server does everything else.
When the forms based model first became available from Unify, hardly anyone in its markets understood it. Other applications toolset designers, however, did; and so competitors like Ingres, Informix, and Oracle all produced forms based development environments during the mid eighties -and today even Microsoft uses some of the same ideas in Access.
In general, however, the interaction between the forms based model as a kind of second generation RPG and relational database theory has not yet been assimilated in either the data processing or the science based computing communities. With the exception of Oracle Financials, which are still more or less forms based, relatively little of the progress made during the 1970s and 80s has survived the emergence of the PC as the reigning business desktop.
Good ideas, however, don't go away permanently - instead they rebound after whatever suppresses them the goes away, whether that's IBM's decision to postpone its Future Systems product by what turned out to be nine years or the PC's current desktop dominance. Expect, therefore, forms based applications conceptualised as just windows into the database, to make a come-back.
Eventually.