Re: 4 the FAQ: Are Commercial DBMS Truly Relational?

Centuries ago, Nostradamus foresaw when Kenneth Downs <firstinit.lastname_at_lastnameplusfam.net> would write:
> Marshall Spight wrote:
>
>> "Kenneth Downs" <firstinit.lastname_at_lastnameplusfam.net> wrote in message
>> news:hqd6kc.4go.ln_at_mercury.downsfam.net...
>>>
>>> The objection to this seems to be that the
>>> RDM requires an implied unique constraint on all columns of all tables.
>>> Because such a constraint is not present, they are not truly relational.
>>>
>>> Is that right?
>>
>> Yeah. I'm not sure about "implied" though.
>>
>> I've never seen a relation in a math textbook where the uniqueness
>> constraint wasn't on all attributes, but as we all know, there's lots
>> of uses for keys with fewer than the maximum number of columns,
>> and even for multiple keys. These are necessarily explicit.
>>
>> Anyway, the definition of "relation" certainly includes a uniqueness
>> requirement, no matter how you slice it.

> Let's say that your DB architect has decreed that all tables must
> contain a last-modified timestamp, enforced by trigger during all
> insert/updates. This creates, by convention, a truly relational
> system, no? Because the timestamp is actually useful (as opposed to
> say some kind of IDENTITY column that is never used), it seems that
> one could use commercial products to produce truly relational
> systems?

No, this doesn't create a "truly relational system."

Suppose you start with two otherwise-identical rows that were disambiguated by the timestamp.

Suppose you then update those two rows, in some identical way, changing some other field. Say:

 update some_table set field1 = 2 where field1 = 3;

Both were modified at the same time, therefore they will wind up with the same timestamp, and therefore no longer be unique, and you'll lose that briefly-present "truly relational" property.

And supposing you improved the "hack" to make it work more successfully, it still doesn't fundamentally help.

The problem is that if there are tuples that are identical save for that artificially constructed difference, they still aren't unique as far as your _application_ is concerned.

If you have two employee 'base' records that are entirely identical save for some 'sequence' ID, you've got an _application_ problem, because those "two employees" are clones of one another:

• These two employees have the same employee ID
• They have the same SSN/SIN number
• They share references to the same spouse, the same children, the same manager, the same set of employee benefits.

The fact that these "clones" have two different "updated on" timestamps does nothing to help the "application problems" that fall out of non-uniqueness.

-- 
wm(X,Y):-write(X),write('_at_'),write(Y). wm('cbbrowne','gmail.com').
http://www.ntlug.org/~cbbrowne/linuxxian.html
"Robot: Your plastic pal who's fun to be with."
-- Marketing Division, Sirius Cybernetics Corp.