Re: Temporal operations

"Leandro Guimarães Faria Corsetti Dutra" <lgcdutra_at_terra.com.br> wrote in message news:pan.2003.09.06.21.51.18.272744_at_terra.com.br...
> On Sat, 06 Sep 2003 13:53:39 -0700, Paul G. Brown wrote:
>
> > No reference to user-defined types
>
> When the relational model says domains, user-defined types are implied.
>
> After all, you don't expect the DBMS to ship with all the domains you
> may ever need?

Perhaps, he expects users to make do with the only data type explicitly required by Codd, ie. boolean.

> > Bob: it would appear either that you are a little lacking in
> > 'intellectual honesty', or that you continue to struggle with basic
> > written comprehension.
>
> Beware, your description of Bob looks like you're projecting yourself.

There you go spoiling my blissful ignorance again. Oh well, half a bliss is better than no bliss at all.

> > BTW, D&D in the rest of their book promptly *extend* the model with
> > domain inheritance (not a concept from mathematical logic and, as D&D
> > themselves say, 'independent of' to the relational model)
>
> Again you are taking things out of context... the inheritance is
> orthogonal and optional, it has even been taken out of D4 v2 with D&D's
> blessing.

I don't know whether he takes things out of context so much as he demonstrates a profound incomprehension of "independent of" as in "orthogonal to", which seems ironic while citing mathematical logic. He says the equivalent to "extending the X-axis with the Y-axis". The Y-axis does not extend the X-axis. It adds a whole new dimension while leaving the original intact.

> > *correct*
> > the model by introducing a distinction between relations and and
> > entirely new thing called a relvar
>
> What is the problem in making clear a distinction that was already
> implicit? Or don't you think the distinction between value and variable
> is worth making?

I can understand an objection to proliferating jargon. Our industry has far too much of that already, but I find this specific jargon useful because the symbols "relation variable" and "relation value" look too similar. Relation and relvar are shorter, clearer symbols when written and when spoken.

> > But to broaden the theme: why is it illegitimate to 'extend' or
> > 'pervert'
> > the relational model with 3VL but OK to add 'domain inheritance' (OO
> > Prescriptions 2 & 3)?
>
> 3VL is easily the most contentious point in the relational field,
> I wouldn't spend much arguing this in the current loaded context.

It is perfectly legitimate for one to create a 3VL domain and provide explicit operations that evaluate to boolean: IsKnown, IsUnknown, IsKnownTrue, IsKnownFalse etc. It is not legitimate to pollute the logical data model with redundant structural elements like NULL or references.

> But, even assuming 3VL to be OK, you still have to acknowledge it
> is fundamental if the system uses 3 or 2VL; while domain inheritance is
> just an optional accretion.

Ultimately, 2VL is fundamental even for SQL. SQL just uses inconsistent implicit rules for converting 3VL to 2VL.

> How can you compare both, unless you're letting emotions take over
> your thinking?

Maybe, he just doesn't know any better. Sometimes, it is more effective to just answer the question.

> > Why does a description of a logical model include
> > two Prescriptions about transactions? (RP# 17 and OO # 5)?

I don't know. I suggest he contact the authors and ask them. If I had to speculate, I would guess they included RM Prescription #17 because data management requires managed concurrent update from all logical data models, and I would guess they included OO Prescription #5 as a requirement for good language design.

> Read carefully... you will see that TTM title's _Foundations for
> Future Database Systems_, that is, it is meant not only to set the record
> straight on the current state of the relational model but also to describe
> a possible implementation. Transactions, or an alternative way of dealing
> with concurrency, may not be part of the relational model but are
> essential to a database system... their inclusion, you may notice, is not
> about prescribing transactions per se but about preventing perversions of
> transactions that are frequently claimed for by naïve programmers.
>
>
> > And if (as
> > they may) D&D remove transactions from their view of the model does
> > this constitute a 'correction'? Using words like 'pervert' amps up
the
> > rhetoric but adds nothing of substance to the argument.
>
> Again, if a system will support transactions or simply simultaneous
> operations (D&D's new proposition) is hardly as essential as making the
> distinction between values and variables, domains and objects, and logical
> and physical...

It might constitute an evolutionary step in our understanding of the relational model. It might indicate a better understanding of how to meet the more fundamental requirement of managed concurrent update. Or they might just decide to keep it in. Aftera ll, it is one thing to discourage procedural specifications for complex data changes, and it is quite another thing to make it impossible to safely specify them.

> > Leaving aside for a moment the point that if the U_ operators are
> > shorthand for simpler operators why go to the trouble
>
> Ooops... I won't go into details now for lack of the book by my side
> now, but it seems you are misrepresenting stuff here.

Because the longhand is cumbersome and errorprone. I assume you cut out part of his nonsense.

[further partial excerpts snipped]

> > I would also do away with domain operators, domain
> > inheritanc (the whole ghastly edifice of the POSREP)
>
> Ops... again, POSREPs have little to do with domain inheritance...
> they certainly don't depend on inheritance, and are useful in its absence.
> What do you have against them?

I wonder what Brown wants to do with data types if they have no operations. Obviously, Brown does not value data independence, but he is a mindless vendor after all so I don't really expect much.

> > [1] Codd, E. F. "The Relational Model for Database Management: Version
> > 2"
> > Addison-Wesley. 1990.
> >
> > (Note that this work pre-dates the publication of the Manifesto by a
> > whole
> > four years, pre-empts many of TTM's novelties (though not all)
>
> Which ones?
>
> BTW, TTM is not about novelties. It is about reaffirming the RM
> as a solid foundation against the OO Newspeak, and applying it to the
> needs that supposedly gave birth to OODBs.

Well said. Their whole exercise started as an exploration of the features of object orientation that might improve the relational model and ended by observing that object orientation had nothing to offer. Received on Sun Sep 07 2003 - 02:54:26 CEST