Relational Model [Codd] vs Anti-Relational Muddle [Date/Darwen/Fagin/et al] • Dishonest Use of 1971 Paper, RM/T

Hi Derek,
not a full reply, just a request for clarification.

Post by Derek Ignatius Asirvadem
LINK

Did you mean to post a link?

Post by Derek Ignatius Asirvadem
=========
- Codd's 1971 paper
- aka RM/Tasmania

Codd's "RM/T" paper is from 1979 ("Extending the Relational Model to
Capture More Meaning"), if that is the paper you meant to cite—which is
what I will assume.

Post by Derek Ignatius Asirvadem
-----------
Argument
- the difference between the RM and the (1971 paper, RM/T)

If one reads Codd's papers carefully, I'd say that the differences are
pretty obvious.

Post by Derek Ignatius Asirvadem
- whether the (1971 paper, RM/T) applies to the RM or not.

Not sure I understand in what sense "apply" is used here.

Post by Derek Ignatius Asirvadem
- whether the (1971 paper, RM/T) is part of the RM or not.

It's not, it's clearly an extension. Specific support is needed in
a Relational DBMS to properly support RM/T.

Post by Derek Ignatius Asirvadem
========
Antagonist
In this topic is a particular: the person (devoid of soul and
personhood, I use the term loosely) launching the attacks is one
"philipxy".

Some context missing here (the link above?). What's the antagonist's
issue you want us to discuss?

Post by Derek Ignatius Asirvadem
Therefore, while I would like to say: the Relational Model consists of
anything written by Codd I cannot, because many of his papers and
articles have a specific purpose that is beyond the Relational
paradigm, or to assist non-relational or anti-relational suppliers in
understanding the RM.

Sure. AFAICS, RM/T's purpose was to demonstrate that many ideas emerging
in the semantic or conceptual modeling community in those years could be
supported within a Relational framework. Several papers were criticizing
the RM as not being sufficiently "abstract" or "high level" (the
"logical" vs "conceptual" modeling debate). The (second part of the)
paper was his answer to such concerns.

I suspect, though, that you citing such paper has something to do with
"surrogates" specifically. But I may be wrong. More context?

Nicola

Derek Ignatius Asirvadem

2019-12-24 10:02:13 UTC

LINK

Did you mean to post a link?

Yes. Thanks.

https://groups.google.com/d/msg/comp.databases.theory/pfWKz74u3Sw/eQvBXTzXAwAJ

Derek Ignatius Asirvadem

2019-12-24 10:50:24 UTC

Post by Nicola
Hi Derek,

Long time. Good to see you are active here.

Happy Christmas, and God bless you and yours.

Post by Derek Ignatius Asirvadem
=========
- Codd's 1971 paper
- aka RM/Tasmania

Codd's "RM/T" paper is from 1979 ("Extending the Relational Model to
Capture More Meaning"), if that is the paper you meant to cite—which is
what I will assume.

Yes and no. Thanks for pointing out that clarification was needed.

As detailed in the post that I failed to link

https://groups.google.com/d/msg/comp.databases.theory/pfWKz74u3Sw/eQvBXTzXAwAJ

Which you would not have read until now ...

I am aware that the 1971; 1974; 1979 papers (and his presentations & articles in Australia) are each different in that they are published on different dates, etc. What I mean is, all those papers are actually anti-relational in that they contradict the RM directly, and propose devices (eg. surrogates) that are prohibited in the RM. Those papers together, are the "Codd Papers" that the anti-relational mob (Date; Darwen; Fagin; et al) use to give a bit of credibility to the
--------------------------------------------------
Anti-Relational 1960's Record Filing System (RFS)
--------------------------------------------------
that they fraudulently market at "relational".

In this thread (as opposed to the header thread (now linked!), I am attempting to deal with the 1971 paper, because it is that one that philipxy quoted from when he was sniping from under a rock.

Now that we have clarified the scope for this thread, I am happy to deal with any one or more of Codd's papers that are used by the TTM slaves to misrepresent them. Particularly the 1971 paper (or any other Codd paper that contradicts the RM) "is the RM".

Post by Derek Ignatius Asirvadem
-----------
Argument
- the difference between the RM and the (1971 paper, RM/T)

If one reads Codd's papers carefully, I'd say that the differences are
pretty obvious.

Absolutely.
Except for humans whose brains are fried.
Except for "theoreticians" who suppress the RM.

Post by Derek Ignatius Asirvadem
- whether the (1971 paper, RM/T) applies to the RM or not.

Not sure I understand in what sense "apply" is used here.

The freaks applying the 1971; 1974; 1979 papers TO the RM, and making representations that is is part of the RM.

Of course, they do not apply to the RM at all, the propaganda is false.

Post by Derek Ignatius Asirvadem
- whether the (1971 paper, RM/T) is part of the RM or not.

It's not, it's clearly an extension.
It's not,

Agreed.
Thanks for being one of the few theoreticians who state that.

Post by Nicola
it's clearly an extension.

I disagree. It is a violent contradiction. A Contradiction cannot be an extension.

Applying the Laws of Thought.
Applying the Law of the Excluded Middle, a logical person cannot sit with the RM and Anti-RM, and not resolve it,
Applying the Law of Non-Contradiction, anything that contradicts the RM, is dismissed.

Post by Nicola
Specific support is needed in a Relational DBMS to properly support RM/T.

I am not sure what support you mean, precisely. There is nothing in the 1971 paper that has any value re the RM, that can be construed as an extension. The RM does not need extension. Logically, I would say, I cannot be extended. (Progress, by faithful disciples of Codd & the RM is possible, but even there, it is not an extension.)

Therefore, other than reading them and shredding it for cat litter, I forgot about it. Until now, when freaks are declaring that it (1971; 1974; 1979 papers, and particularly the 1971 paper, because it was quoted) that it is the RM.

Post by Derek Ignatius Asirvadem
========
Antagonist
In this topic is a particular: the person (devoid of soul and
personhood, I use the term loosely) launching the attacks is one
"philipxy".

Some context missing here (the link above?). What's the antagonist's
issue you want us to discuss?

Specifically that philipxy declared that the 1971 paper IS them RM; that it "extends" the RM. Which is possible only for seriously damaged people.

Sure. But to me that part is irrelevant. The whole debate was irrelevant. I was a Lead S/W Engineer at Cincom, our Network DBMS was very successful. I was, and still am, an applied theoretician. I, along with many other Cincom Engineers (now at Sybase) scoffed at the debate

Even the notion that the RM was not abstract enough, is ridiculous.

That is exactly the kind of insanity that is common in "academia" these days. They are insanely envious that Codd did what he did, and they do anything and everything to undermine and suppress his work. They have come up with 17 Relational Algebras, all in competition with the one and only Codd RA.

But let's not get side-tracked. The first part of the paper(s) provide methods for using surrogates as "keys". And then the:
- "transitive FDs"
- restated "3NF"
- all manner of idiocy for supporting surrogates as "keys"

What the propagandists suppress is this. Codd wrote that in order to elevate the then well-established and very resistant reference-by-pointer DBMS of the time. That is why he did not point out the contradiction. It is for a specific purpose, to assist reference-by-pointer DBAs to obtain a little bit of Relational capability in their backward systems. It is not for applying to the RM, or for mixing wit the RM, because it can't: it is in violent contradiction of the RM.

Post by Nicola
I suspect, though, that you citing such paper has something to do with
"surrogates" specifically. But I may be wrong. More context?

Yes.
That is the central issue.
Plus all the madcap tinfoil bells and whistles to support it, which are peripheral.
The RM prohibits surrogates, and demands Relational Keys.
The 1971 paper promotes surrogates (because that is all the pre-relational DBMSs could do.

There cannot be a union or melange or scrambled eggs.
There can be only one (RM) xor the other (RFS)

Cheers
Derek

Lifepillar

2019-12-28 12:46:53 UTC

Post by Nicola
Hi Derek,

Long time. Good to see you are active here.

As you probably recall, we had a private exchange several months ago,
which was abruptly interrupted when (from my point of view) you stopped
replying to my messages. I have since tried to contact you privately
a couple of times, but either you ignored my messages or they didn't
reach you (spam filters?).

Post by Derek Ignatius Asirvadem
Happy Christmas, and God bless you and yours.

Happy Christmas to you!

Post by Derek Ignatius Asirvadem
In this thread (as opposed to the header thread (now linked!), I am
attempting to deal with the 1971 paper, because it is that one that
philipxy quoted from when he was sniping from under a rock.

Can we please cite papers by title? I am not sure yet which one you are
referring to. Also, I have no idea who philipxy is and I have found no
reference to anything he quoted in the post you linked to.

As for surrogates, before arguing about their idiocy or foxiness, we
should agree on the meaning of the term. For me, Codd's definition from
his 1979's paper (Extending the Relational Model to Capture More
Meaning) is good. In summary:

A domain S is a *surrogate domain* for an entity set E iff:

1. there is a (time-independent) bijection between S and E;
2. the values of S are generated by the system;
3. the users may cause the system to generate or delete a surrogate, but
they have no control over its value (in particular, they cannot
update it);
4. two surrogates *across the entire database* are equal iff they denote
the same entity in the perceived world of entities.

Property 4 is the most important, and what distinguishes a surrogate
from a pure record id. Incidentally, I seldom, if ever, see it mentioned
in any discussion about surrogates.

Since surrogates bear no meaning other than being "permanent unique
identifiers" for entities, Codd suggests that a "coalescing command"
must be introduced to enable a user to assert that two entities that are
considered distinct by the system (because they have distinct
surrogates) are, in fact, one and the same. This is one of the
difficulties in dealing with surrogates. Codd also correctly points out
that the introduction of surrogates "does not make user-controlled keys
obsolete". Whether surrogates should be introduced as primary keys (as
Codd proposes) or as additional keys may be debated.

My position is:

- "record IDs", as found in many open-source databases out there where
each table has an 'id' field with unique values within the table, make
no sense in the Relational Model or in any database implementation and
they don't need to be discussed further.

- Surrogates, as defined above, should never be necessary in any logical
model (but see my next post). They are useful in some cases to optimize
a physical design. For example, the primary key of an Address in
Italy, simplifying a bit, is (Region, Province, Town, Species,
Toponym, Number, Exponent) , e.g., ('Lombardia', 'Milano', 'Segrate',
'piazza', 'Garibaldi', '23', 'A'). In this case, it may be convenient
(although not necessary from a logical point of view) to introduce an
artificial AddressID attribute and use that for foreign keys referring
to the Address table.

- In SQL, I usually introduce surrogates as attributes under
a `unique()` constraint, not as `primary key()`. So, my definition of
Address would be something like this:

create table Address (
Region dom_region not null,
Province dom_province not null,
Town dom_town not null,
Species dom_species not null,
Toponym dom_toponym not null,
Number dom_number not null,
Exponent dom_exponent not null,
AddressID dom_entity_id not null, -- System-generated

primary key (Region, Province, Town, Species, Toponym, Number, Exponent),
unique (AddressID)
);

Nicola

Derek Ignatius Asirvadem

2019-12-29 14:14:40 UTC

Post by Lifepillar

Post by Nicola
Hi Derek,

Long time. Good to see you are active here.

If you do not mind, let's keep private comms private.

I promise to get back to you on that channel in the first week of January.

Post by Lifepillar

Can we please cite papers by title? I am not sure yet which one you are
referring to.

philipxy's quote:
//
Codd's 1971 [paper] "Further normalization of the data base relational model"
//

Let's call that, and nothing else, the //1971 paper//.

Post by Lifepillar
Also, I have no idea who philipxy is and I have found no
reference to anything he quoted in the post you linked to.

I have not given that yet. I was hoping for some introductory discussion (such as yours) before we launch into the specifics of his quote. I will give it in the next few days.

Post by Lifepillar
As for surrogates, before arguing about their idiocy or foxiness, we
should agree on the meaning of the term. For me, Codd's definition from
his 1979's paper (Extending the Relational Model to Capture More
1. there is a (time-independent) bijection between S and E;
2. the values of S are generated by the system;
3. the users may cause the system to generate or delete a surrogate, but
they have no control over its value (in particular, they cannot
update it);
4. two surrogates *across the entire database* are equal iff they denote
the same entity in the perceived world of entities.
Property 4 is the most important, and what distinguishes a surrogate
from a pure record id. Incidentally, I seldom, if ever, see it mentioned
in any discussion about surrogates.
Since surrogates bear no meaning other than being "permanent unique
identifiers" for entities, Codd suggests that a "coalescing command"
must be introduced to enable a user to assert that two entities that are
considered distinct by the system (because they have distinct
surrogates) are, in fact, one and the same. This is one of the
difficulties in dealing with surrogates. Codd also correctly points out
that the introduction of surrogates "does not make user-controlled keys
obsolete". Whether surrogates should be introduced as primary keys (as
Codd proposes) or as additional keys may be debated.

(The Impaler is going to love that. That Codd plagiarised his idea forty years before he hatched it.)

First, that is an uncommon definition for surrogates. Second, Codd's definition in the 1971 is the common understanding of the term: table-scope.

To avoid confusion, let's call this one Universal Surrogate. And note that it is rarely implemented.

To differentiate, since the common surrogate (Record ID) is table-scope, which does not work for many reasons (separate to the fact that it is not Relational), and is forever being "enhanced" and fixed" and "oooh this'll do it-ed" , and such fix-ups have included UUIDs; GUIDs; druids; etc, such implementations (provided as platform level), are not Codd's Universal Surrogate, because it does not have that intent. Nor the knowledge upon which to have that intent.

Second, because the intent of the common surrogate it to provide a container for a record (not a logical row, made up of domains)

Third, because the Universal Surrogate (implied but direct) is not intended for the common intent, it maintains relational access to the domains, and thus the logical rows.

Nevertheless, it remains a Relational Breach, because, per the /RM/, it:
- is not of the Normal Form in /RM § 1. Normal Form, Fig 3(b) Normalised Set/
(the obvious name for which is Relational Normal Form)
- breaks the Access Path Independence Rule
- consequently all tables below the breach (descendant rows) are logically cut off from all tables above the breach (ancestor rows).

Post by Lifepillar
- "record IDs", as found in many open-source databases out there where
each table has an 'id' field with unique values within the table, make
no sense in the Relational Model or in any database implementation and
they don't need to be discussed further.

Agreed. 100%.

Post by Lifepillar
- Surrogates, as defined above, should never be necessary in any logical
model (but see my next post). They are useful in some cases to optimize
a physical design. For example, the primary key of an Address in
Italy, simplifying a bit, is (Region, Province, Town, Species,
Toponym, Number, Exponent) , e.g., ('Lombardia', 'Milano', 'Segrate',
'piazza', 'Garibaldi', '23', 'A'). In this case, it may be convenient
(although not necessary from a logical point of view) to introduce an
artificial AddressID attribute and use that for foreign keys referring
to the Address table.

Agreed.

But that act is a logical one. Intended for the physical. (Theory must have an implementation intent, otherwise it has not value, it is fantasy, the realm of the Date; Darwen; Fagin; et al Gulag). To say, as our darling "theoreticians do, that theory should have no concerns about the physical implementation is the tattoo of the asylum dweller.

Logical means "with a physical intent", anyting else if not logical. Pig poop.

As evidenced, Codd is both a pure theoretician and an applied theoretician. The motivation (intent) for him to come up with the Universal Surrogate was implementation concerns.

Post by Lifepillar
- In SQL, I usually introduce surrogates as attributes under
a `unique()` constraint, not as `primary key()`. So, my definition of
create table Address (
Region dom_region not null,
Province dom_province not null,
Town dom_town not null,
Species dom_species not null,
Toponym dom_toponym not null,
Number dom_number not null,
Exponent dom_exponent not null,
AddressID dom_entity_id not null, -- System-generated
primary key (Region, Province, Town, Species, Toponym, Number, Exponent),
unique (AddressID)
);

You might have gotten an idea from something that has been floating around in the cesspool for a couple of decades ;p
http://www.softwaregems.com.au/Documents/Documentary%20Examples/Order%20DM%20Advanced.pdf

Agreed.

Why the UNIQUE instead of PK ?

If the surrogate is to be migrated to child tables as an FK, then it must be the PK in the parent. It is a gross lie (to one's own intellect, due to the marketed pig poop) to name one domain (or set of domains) a PK, and then proceed to use some other domain as the PK.

PK is a Relational concept. If your db is Relational, use the Relational terms, and use them correctly.

Note that if you use a surrogate for that purpose (in substitution for a wide Key), it is not the same as a Record ID (pointer to a record that contains a non-Relational arbitrary collection of fields [not domains, coz they ain't Relational und der normalisation ist kaputt] ). Whereas yours is thoughtfully chosen, over domains. And of course, the usage (in child tables below the breach) is different. The cannibals are unaware that they have breached the /RM/. They declare the surrogate as the PK out of total ignorance.

A horse that has had its tendon cut, so as not to roam too far afield, is not the same as an earthworm, that can't roam more than 10 metres.

The freaks' use of surrogates was so bad, that eventually the high-end SQL providers allowed an FK to be defined [in the child] referencing a UNIQUE key in the parent. Eventually that was included in the Standard.

Separately, and this is a physical concern. If your SQL platform provider has a Clustered Index feature, that MUST be on the Logical, not physical, key. Because the Clustered Index was conceived, invented, and implemented for the composite, multi-domain Relational Key. Major advantages for data distribution; high concurrency; etc.

Oracle (not SQL compliant; no Server Architecture; no ACID Transactions) has a pathetic version called Index Organised Table.

Why system generated ?

The only thing worse that a surrogate (at the implementation level) is a surrogate that is system generated. I have spent the last thirty years replacing mickey mouse databases, and I simply do not allow anything system generated in TEST or PRODUCTION environments. Allowed only in DEVELOPMENT, and there only to pander to lazy developers. Twenty years ago, one Aussie bank made that a rule for PRODUCTION environments across the whole bank, excepting third-party packages, which suffer all the usual problems.

I am sure that I am not the only disciple of Codd who has had a few alternatives for a system generated value in the context of a large table and with OLTP concurrency concerns in his toolkit, but I am not permitted to discuss that here,

Beautiful use of Datatypes. If I may say so, I would not advise using logical-only terms in teh physical implementation. No user (including developers) would understand what Domain means, and therefore what /dom_/ intends. Once you understand that, you will understand that the prefix /dom_/ is not necessary.

I don't know what you intend by /dom_entity/.

I advise a private Datatype for each Key, including every component of a Key, and a small set of generic Datatypes for attributes. I would use:
Region Region not null,
Province Province not null,
Town Town not null,
Species Species not null,
Toponym Toponym not null,
Number AddressNumber not null,
Exponent Exponent not null,
AddressID AddressID not null, -- System-generated or not

AddressNumber because there would be a generic _Number; _Int; _IntTiny; etc. Whereas _Number may be NUMERIC(10), AddressNumber may be NUMERIC(6).

Cheers
Derek

Nicola

2019-12-29 23:13:07 UTC

Post by Derek Ignatius Asirvadem
//
Codd's 1971 [paper] "Further normalization of the data base relational model"
//
Let's call that, and nothing else, the //1971 paper//.

I don't see that paper as something promoting or even proposing the use
of surrogates. What makes you think so? It certainly does not mention
the term explicitly.

As for transitive dependencies, I don't like them either (mainly because
their definition is a bit tricky), but 3NF may be defined without them,
so I don't see that as a big issue.

I do like functional dependencies, though, and I think that they are
nice and useful.

First, that is an uncommon definition for surrogates.

Definitely.

Post by Derek Ignatius Asirvadem
Second, Codd's definition in the 1971 is the common understanding of
the term: table-scope.

I have already expressed my opinion on such "table-scope" id's, which
you agreed with. So, the only thing for me to understand is how/where
that paper would define them: is it something you infer from his
admittedly contrived example (but purposely so, I'd add)?