1. I find this article problematic because it uses terminology and ideas that are not going to be universally understood in the same way by all readers. In particular it uses the term "NULL" without explaining it. Are we really talking about SQL-style nulls here? Relational database theory doesn't include anything like SQL's kind of null. It certainly is not part of Codd's original relational model or even his later revisions of it. There are several contradictory definitions of nulls and Tom hasn't explained which one he is talking about.

2. The suggestion that domain theory means that relations can support nulls appears to be speculation on Tom's part. At least that's how it seems, because he hasn't referenced any other source for that claim. I don't recall ever seeing that from any other source.

3. Tom says that "every row [sic] has a primary key". I guess this means every relation has a primary key. Keys are usually understood to be a subset of the attributes of a relation or relation variable rather than a property that tuples have.

4. He goes on to say: "a relation in relational database theory is required to conform to 1NF". This is true of Codd's original relational model but then Codd's original relational model did not support nulls whereas Tom appears to be discussing some other system which does have nulls. Codd's RM2 on the other hand does NOT require every relation to conform to 1NF. Codd's RM2 specifically allows derived relations which do not have primary keys at all. Again, to give readers a chance of understanding his explanations Tom needs to explain what definitions he is referring to.

5. The claim that relations require "primary" keys is a bit ambiguous. What Codd referred to as a "primary key" in his 1970 paper is more usually today called a Candidate Key. A "primary" key is nowadays usually understood to be just one of the candidate keys which is somehow designated to be a "primary" one. Depending on the implementation that designation of a primary key may be part of the logical data model in the database or it may not be. There is nothing in the relational model that absolutely requires a key to be so designated. Candidate keys are fundamental but the concept of having a "primary" key or not having one is unimportant.