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

148 views
Skip to first unread message

Derek Ignatius Asirvadem

unread,
Dec 22, 2019, 5:31:46 AM12/22/19
to
The prefix and context is:
LINK

========
The main Subject and context (restated for convenience) is:
---------------------------------------------------
the original Relational Model by Dr E F Codd
---------------------------------------------------
vs
---------------------------------
1960's Record Filing System
(easily proved as such)
by post-Codd "theoreticians"
supported by a mountain of ever-changing abnormal "normal forms"
sometimes supported by "math"
heavily promoted and marketed as:
THE "relational model"
---------------------------------

In short,
the RM
vs
the RFS, fraudulently promoted as "relational"

------------
The protagonist is:
--------------------
The Relational Model
--------------------
Dr E F Codd
Supported by [apparently] the lone figure of Derek Ignatius Asirvadem

The antagonists are:
--------------------
1960's Record Filing System labelled as "relational"
--------------------
C J Date; Hugh Darwen; Ronald Fagin; et al
Promoters thereof, known to participate at c.d.t.

=========
The Topic is:
- Codd's 1971 paper
- aka RM/Tasmania
because that was the label by which it was known, to people who were database applied-theoreticians and implementors, due to Codd's various articles and presentations at the time, including his famous trip to Australia.

-----------
Argument
My starting position is, there is no issue in understanding:
- the difference between the RM and the (1971 paper, RM/T)
- whether the (1971 paper, RM/T) applies to the RM or not.
- whether the (1971 paper, RM/T) is part of the RM or not.
At least not for a human being who has a scientific approach to scientific issues, who has not lost his intellect and memory.

However, evidently, there are some folks out there who suffer this confusion.

Whereas this is an issue that is totally resolved; a total non-issue, for undamaged humans, it is purposely maintained as an unresolved confusion by the antagonists. It is a device (dishonest, anti-science), to give a paper written by Codd for a specific and unrelated purpose, an ostensibly valid "foundation" for their anti-Relational Record Filing Systems fraudulently labelled as "relational".

As per the prefix and context, such confusion, or in the case of the perpetrators such sabotage, can be easily examined; diagnosed; resolved; and closed. So let us have it out, in a free and open forum.

========
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".
As I understand it, it is one from the TTM Gulag, the continuing source and centre for the promotion and protection of anti-relational 1960's Record Filing Systems, fraudulently labelled as "relational". I would be pleased if anyone who knows him would alert him to this thread.

Currently, it is sniping from a foxhole in the ground, protected, such that I cannot respond. So let us have it out here, in a free and open forum. Where one does not enjoy the familiarity; warmth; comfort; and protection of a mother's skirts, in which to collapse and give up responsibility, a Safe Zone from which to launch attacks that are protected from response, one that enforces a false "reality". Although a late starter, it might be a Good Time to go beyond the confines of a skirt.

Initially, I thought it was one of:
The Slaves that Teach Slavery
But given (a) the fact that the target forum is public, (b) his consistent sniping from mummy's skirt, and (c) his known attendance at TTM, he is confirmed as one of:
The Slaves that Teach Pig Poop Cuisine.

------------
Open
However, this is an open argument, not limited to one person. I invite any of the "theoreticians" here, who argue for the Date; Darwen; Fagin Gulag, for the 1960's Record Filing System labelled as "relational", to engage. We can canvas the materials, and resolve the issue completely, in absentia of the causative antagonist.

It would be very surprising, if, after the forty years since the advent of the RM, there are no theoreticians or "theoreticians" here, who have not suffered the propaganda; the indoctrination; the confusion; the tension of RM vs RFS as "RM". And shirk from resolving it.

As detailed in the protocol, failure to engage means that my argument is conceded, by all those who receive this.

------------
Literature
This will enter into argument about the "literature", thus a word on that subject is necessary to maintain scope. Since the RFS directly contradicts the RM, and includes the suppression of the RM, it is, therefore anti-Relational. Thus the subject could also be stated as:
The Relational Model
vs
The Anti-Relational RFS fraudulently labelled as "relational"

Codd wrote many papers, and even more articles. In that first decade 1970 to 1980 he was responding to the wall of resistance from the well-established pre-Relational DBMS suppliers, attempting to gain acceptance. (IBM, who commissioned Codd's work, and who set specific goals for the project, all of which Codd met, embraced the RM, and produced System/R, followed by proprietary SQL. But that is not commonly known.)

Codd was both a pure theoretician and an applied theoretician, as evidenced in his RM. But his fights were mostly with suppliers (applied theoreticians). Not a single theoretician of the day came to his aid, or countered him.

(Those who made a grand presentation of assisting him, turned out to be, by virtue of the evidence, actually sabotaging him.)

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.

Therefore
the Relational Model consists of the (i) Codd's 1970 paper, and (ii) Codd's Twelve Rules,
only.

Whereas, after reading close to 100 pieces of "literature" over the decades, that is purported to be "expansion" or "interpretation" of the Relational Model, I declare that
all literature purported to be "relational", written by anyone other than Codd, is Anti-Relational RFS fraudulently labelled as "relational"

That includes books, and books that are used as "textbooks" in the indoctrination of souls, in what passes for "education".

The corollary is relevant: whereas there are close to 100 "academic" papers written for the RFS fraudulently labelled "relational", which are therefore supportive of the great fraud, either wittingly or unwittingly, there is not a single academic or "academic" paper written to support the RM, or to progress it.

(There are many internal papers written by the suppliers of genuine SQL platforms, which are platform-level implementations of the RM, and a few commercial ones written by the likes of me, genuine practitioners of the RM, which are database-level implementation of the RM, over the forty years that have elapsed. Those of us who either never read the filth from the RFS sewer, or read it and dismissed as pig poop. But that is out of scope.)

Nicola

unread,
Dec 22, 2019, 1:10:14 PM12/22/19
to
Hi Derek,
not a full reply, just a request for clarification.

On 2019-12-22, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
> The prefix and context is:
> LINK

Did you mean to post a link?

>=========
> The Topic is:
> - 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.

> -----------
> Argument
> My starting position is, there is no issue in understanding:
> - 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.

> - whether the (1971 paper, RM/T) applies to the RM or not.

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

> - 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.

>========
> 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?

> 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

unread,
Dec 24, 2019, 5:02:16 AM12/24/19
to
> On Monday, 23 December 2019 05:10:14 UTC+11, Nicola wrote:
> On 2019-12-22, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
> > The prefix and context is:
> > LINK
>
> Did you mean to post a link?

Yes. Thanks.

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

Derek Ignatius Asirvadem

unread,
Dec 24, 2019, 5:50:26 AM12/24/19
to
On Monday, 23 December 2019 05:10:14 UTC+11, Nicola wrote:
> Hi Derek,

Long time. Good to see you are active here.

Happy Christmas, and God bless you and yours.

> On 2019-12-22, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
>
> >=========
> > The Topic is:
> > - 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".

> > -----------
> > Argument
> > My starting position is, there is no issue in understanding:
> > - 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.

> > - 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.

> > - 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.

> 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.

> 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.

> >========
> > 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.

> > 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.

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.

> 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

unread,
Dec 28, 2019, 7:46:56 AM12/28/19
to
On 2019-12-24, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
> On Monday, 23 December 2019 05:10:14 UTC+11, Nicola wrote:
>> 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?).

> Happy Christmas, and God bless you and yours.

Happy Christmas to you!

> 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

unread,
Dec 29, 2019, 9:14:42 AM12/29/19
to
On Saturday, 28 December 2019 23:46:56 UTC+11, Lifepillar wrote:
> On 2019-12-24, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:
> > On Monday, 23 December 2019 05:10:14 UTC+11, Nicola wrote:
> >> 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?).

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.

> > 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.

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//.

> 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.

> 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.

(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).

> 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.

Agreed. 100%.

> - 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.

> - 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)
> );

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

unread,
Dec 29, 2019, 6:13:11 PM12/29/19
to
On 2019-12-29, Derek Ignatius Asirvadem <derek.a...@gmail.com> wrote:

> 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//.

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.

>> 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.
>
> First, that is an uncommon definition for surrogates.

Definitely.

>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)?

>> - In SQL, I usually introduce surrogates as attributes under
>> a `unique()` constraint, not as `primary key()`.

> You might have gotten an idea from something that has been floating
> around in the cesspool for a couple of decades ;p

I know that you like addresses :) But, actually, since a few years in
Italy there has been an ongoing project to build a national database of
standardized addresses, which has resulted in some detailed technical
documents that define how an address should be structured.

> Why the UNIQUE instead of PK ?

In fact, the arguments you put forward (especially about clustered
indexes) are good. I use mostly PostgreSQL these days, where clustering
is a manual operation and there is essentially no difference between
primary key() and unique() (plus not null).

From a logical modeling perspective, I think that one may find examples
where migrating an alternate key becomes necessary. As for my specific
example, I have looked at my notes and in fact I was wrong: after
introducing AddressID, I make it the primary key in my model (btw, there
was a proposal in Italy a few years ago to introduce a standard
alphanumeric encoding of each address—so AddressID might not even need
to be a surrogate).

> Why system generated ?

That was in Codd's definition of surrogates, the rationale being that
it's not the value itself that counts, but the fact that it's a unique
value denoting the same entity across the whole database. The main
reason for a system generated surrogate is that the system is in charge
to guarantee such uniqueness (not that it simplifies insertions,
though).

> 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'll take your advice.

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

Just a domain for surrogate values.

Nicola

Reply all
Reply to author
Forward
0 new messages