Another rule (number 2) in its 1990 version. This one hadn't changed much from the 1985 version.

RM-1 Guaranteed Access

Each and every datum (atomic value) stored in a relational database is guaranteed to be logically accessible by resorting to a combination of R-table name, primary-key value, and column name. (This feature is Rule 2 in the 1985 set.)

_______________________________________________________

He follows this definition of the rule with some explanatory text:-

The access path supporting this feature cannot be canceled. Most other access paths, however, are purely performance-oriented, and can be both introduced and canceled. Both Feature RM-1 and Feature RM-3 are needed in order to support ad hoc query without pre-defined access paths.

Clearly, each datum in a relational database can be accessed in a rich variety (possibly thousands) of logically distinct ways. It is important, however, to have at least one means of access, independent of the specific relational database, that is guaranteed~because most computer-oriented concepts (such as scanning successive addresses) have been deliberately omitted from the relational model.

Note that the guaranteed-access feature represents an associative-addressing scheme that is unique to the relational model. It does not depend at all on the usual computer-oriented addressing. Moreover, like the original relational model, it does not require any associative-addressing hardware, even though the need for such hardware was once frequently claimed by opponents of the relational model.

The primary-key concept, however, is an essential part of Feature RM-1. Feature RS-8 requires each base relation to have a declared primary key (see Chapter 2). Feature RM-1 is one more reason why the primary key of each base relation should be supported by every relational DBMS, and why its declaration by the DBA should be mandatory for every base relation.

_____________________________________________________

(Feature RM-3 is support of the full power of a 4-valued predicate calculus; obviously you can't usefully do ad hoc queries without some sort of logic support, so the reference here isn't anything odd.)

It's interesting that Codd says that a need for associative-addressing hardware was claimed to exist by oponents of the relational model. Associative addressing disc hardware was originally proposed in the 1960s, several years before Codd proposed the relational model, and the justification for it was nothing to do with the relational model: it was that no-one had any CPUs (or reasonably priced arrays of CPUs) that could handle search at the data rates that could be provided by "modern" (1960-s vintage) discs. The first customer deliveries of Content Addressable FileStore (CAFs) occurred before any relational database was delivered, and were made to BT and several other ICL customers in the 1970s; the software transformed queries into instructions for search logic incorporated into the drive mechanism. This early version was built as a series of one-offs for each customer that wanted one, not as a standard product - the standard product came later when controller technology had improve suffieiently to permit the search logic (which was a bit advanced for its time - for example it included weighted quorum logic) to be moved from the drive mechanism to the disc controller. CAFS was included in all ICL Series 39 mainframes and most 2900 series mainframes from 1982 onwards. At this point it was used mainly for IDMS (which is certainly not not relational) and for IDMS-X, but later it was incorporated into the ICL port of Ingres to the VME operating system and it was also used and for searching databases (again not relational) of unstructured text (eg at Oxford and Southampton Universities) . Another version (SCAFS for "Son of CAFS": ICL in those days had no qualms about product naming standards) was based on firmware in a standard microprocessor. As well as IDMS-X, all of Informix, Oracle and Unix provided an interface for the incorporation of/interfacing to the CAFs support software (a standard library provided by ICL with the hardware) and IBM licensed the SCAFS technology from ICL for use with DB2; but I don't recall anyone claiming it was essential for relational database support. Certainly no-one in ICL made or believed any such claims - CAFS and SCAFS were about getting past the then existing hardware limitations on search capability (effectively limitations on scan,filter, and join speeds) and nothing to do with what the database model was - and as processor speeds improved and the cost of multi-processor systems came down associative-addressing disc hardware would cease to be commercially viable (if the performance estimates produced by Leung and Choo http://www.vldb.org/conf/1985/P282.PDF were correct, a relative improvement factor of 2.5 between processor and disc bang per buck would do that; I don't think any modern systems use it - it would be fairly pointless if the CAFS hardware used the same industry standard components as the server). As far as I know no-one but ICL (and IBM under license from ICL) ever produced any associatively addressed disc systems as a large-volume product. I guess that IBM (specifically the DB2 team) must be where the claims that associative addressing hardware was neccessary for support of the relational model came from - after all, they were the opponents of RM best known to Codd.