• At the time Codd introduced the RDM the three levels of representation had not yet emerged and he focused almost entirely on where the RDM belongs - the logical level. But RDM is applied theory -- simple set theory expressible in first order logic (SST/FOPL) adapted to database management -- adaptation which would have not been possible and useful without a real world interpretation (semantics). Database relations are semantically constrainted such that they represent entity groups with properties and relationships within- and among groups: 

• Kimball's "dimensional systems" are, essentially, application-biased database designs that have nothing to do with the semantics and logic of the RDM.

“If a table is not a relation, then what is it? This is just avoiding the issue. If 5NF were such a basic thing, there wouldn't even be a need to worry about 1234NF. 5NF does not achieve what Codd hoped for, there's not really any rigorous way to measure semantic consistency like he assumed. That is why for the most part 3NF is sufficient, and not even pure 3NF because shortcuts like identity columns are too useful to exclude, and "fact tables" that are purposely not in 3NF are important aspects of many apps.”

--Joshua Stern

• A table is a table; a R-table is a table that visualizes a relation on a physical medium (in fact, only the body of a R-table, as the header is metadata) -- the tabular arrangement of rows and columns plays no role in the RDM;

• RDM's grounding in simple set theory means that relations are simple sets (i.e., no nested sets that would require second-order logic  and lose relational advantages), which is another way of saying that they are in 1NF (simple domains with values treated as atomic by the data sublanguage);

• Codd changed the initial version of the relational algebra (RA), including the join operator, to the current one we are familiar with (well, those who are!) The details are beyond the scope of a post, suffice it to say that the old join was to 1NF what the current join is to 5NF. In other words, given the current RA, system-guaranteeable logical validity and by-design semantic consistency require 5NF databases (which is why we now contend that relations are by definition in 5NF, otherwise they are not relations and all bets are off);

• McGoveran's early argument that RDM' grounding in SST/FOPL required adherence to three principles of database design was never understood. Though it has not yet been proved, he believes that joint adherence produces 5NF databases. The 2-3-4NF were an historic accident (due in part to the pedagogical use of tables that induced the confusion with relations). As we explained more than once, explicit further normalization from 1NF to 5NF arises only as repair of poor designs that did not adhere to the principles.

Algebras do not have "anomalies", so database relations are in 5NF by definition (as well as in 1NF).

Several attempts were made to disabuse Stern of misconceptions (which, given my five decades of experience, I knew was futile) and, of course, he met them with his following "interpretation" of Codd's work:

“You can't quote Codd at me as a counter when I'm saying Codd was wrong. You're just preaching the gospel and I'm telling you it's wrong. I know what I'm saying, but I suspect you're not listening ... The point of Codd's work was to give us something useful, which requires a physical realization. His error was to hold that there was some logic that could move around physical data without worrying about semantics, once it was in 3NF/5NF. But he ignored the *cost* which is determined by the physical implementation. So much of actual database administration is correlating physical form with semantics, in schema and in queries. I don't blame Codd for not solving all these issues, but every working DBA has to know things that Codd never worried about.  

• Codd did not "ignore" physical implementation (how could he, particularly given IBM's pressure?). The RDM rendered logical design -- and, thus applications -- independent of it, such that they are unimpaired by physical changes for performance optimization purposes. Stern has it upside down and backwards: physical independence reduces, not increases the "cost" of implementation, by giving the DBA much more flexibility.
• RDM -- the adaptation and application of SST/FOPL to database management -- would have been neither possible, nor useful without a real world interpretation: Why else would integrity -- semantic constraints -- be a component of the RDM? Upside down and backwards again: conceptual models (semantics) are formalized using the RDM as logical models for database representations precisely so that they can be computerized.

“Codd made a *huge* assumption that some sort of unique ID was NOT an essential, necessary aspect of his model, and to a large degree he was wrong. The misunderstanding was Codd's. The identity key is two things, first it is a numbering or ordering of the rows, not required of Codd's relational model because he based it on set theory where sets are generally not ordered, order is something that is done externally. He thought that since each row has a unique primary key, that would be sufficient, but a PK can be changed without changing the real-world entity, it is all more complex than he allowed. Second it is something to preserve that real-world identity across such changes. It is also a handy surrogate key since the unique PK in many cases is long enough to demand one for reasons of efficiency. Codd never thought about efficiency, but just that surrogacy can deliver 100:1 improvement in many common cases.”