Re: Temporal operations

"Bob Badour" <bbadour_at_golden.net> wrote in message news:<rww6b.622$Lg2.56494215_at_mantis.golden.net>...

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

  Yes. As a matter of fact, he does.

   There is true. And there is false. (And there is unknown). For the purposes   of automating reason everything else is superflous. I don't know if what   you're storing in my DBMS is true or false, and I sure don't know what   isn't stored there. I can only try to ensure that the way you manage and   manipulate it is consistent with the laws of logic.  

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

   There are no axis in formal systems. There are axioms. Adding new axioms   extends the set of axioms. This is what the term mean.

   Do you have any argument here? Any refutation? Or are you obliged to   attribute to me things I did not say in order to support a position you   cannot articulate and are unable to defend?

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

   Jargon is language. We are talking axioms here. We are talking about   the logical model: the building blocks of reason. Your choice of notation   is entirely up to you. I only want consistency in the way you use your   terms.

   What is this distinction between 'relation', 'relation variable' and   'relation value'? It is not a part of mathematical logic (this is a   statement of fact, easily refuted if you can offer a *single* example from   the literature, which contradicts it). I further assert that it is a   confusing and unnecessary distinction in terms of implementing a   DBMS, and provided an example (the relation 'greaterthanorequal<>) which is   neither a value nor a variable. Do you have any logical argument or even   a coherent observation to make about the example?  

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

    Wow. From TRUE, FALSE, and UNKNOWN, you have multiplied entities to include   IsTrue, IsNotTrue, IsKnown, IsUnkown, IsKnownFaslse. You sound like   Donald Fumsfeld! Want to add 'IsKnownKnown', 'IsUnknownKnown', and   'IsUnknownUnknown'?

   But seriously, you're conceding the point. "The relational model needs   no blah blah . ." was the original D&D diktat! Well, apparently, it   does. But I take the argument seriously. The relational model is something   you extend at great hazard. TRUE, FALSE and UNKNOWN. All else   is incoherence.

 [ snip ]

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

     What, in one sentnce, was the question? If I'm supposed to be answering    one then at least I have a right to know what it is. In performing the    comparison I can see no distinction. It is up to the person making the    claim to justify it.

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

   "If you had to speculate." "Ask the authors."

   I don't speculate. I read the text. It says nothing about language in   RP # 17. In OP # 5 it says that the reason you want to do this is to avoid   certain SQL mistakes. *Then* they go on to point out that the "mistake" is   related to the way the SQL standard says "leave it up to the implementation",   implying that whatever practical difficulties arise are not SQL mistakes   at all!

   The DBMS products with which I am most familiar provide a SQL compliant and   a non-SQL compliant flavor. Is the transaction support in SQL a mistake?   Maybe. But it is apparently something the vendors got right. Are you gonna   say that? (And if you do I have a medium, rusty freighter loaded down with   really angry people who would beg to differ.)

   But once again, what is this doing in the logical model? That's the point.   Please address the question I raised, not the strawman you think D&D   were demolishing.  

 [ snip ]

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

   THE RELATIONAL MODEL NEEDS NO EXTENSION, CORRECTION, SUBSUMATION or   PERVERSION. (Their words!)

    Oh. But it does. It needs transactions.

    But wait! They're going! Why? Is it because they're an extension? Or   because they're a perversion? Or because they susbsume too much? I don't   care. Transactions define the quality of service guarantees DBMS might   make wrt changes. They don't matter squat to the logical model.

    "Discourage?" Formal systems are sets of axions. You don't "discourage"   an axiom. It's like discouraging the tide. Or gravity.

    Sloppy language, sloppy thinking. I am having fun.

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

   Nonsense? (Note: ad homenim, unsustained argumentation). Care to provide   a single piece of evidence or an argument to sustain that assertion?

   I gave specific citicisms and a chain of reasoning. I quoted from the   source material. And the best you can do is to say "nonsense"? Care to   contest any of the citations? See any problem with the logic? Can you   enlighten us as to any dodgy assumptions underlying the thinking? They   are there, Bob. All over the place.

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

   While there was no question mark there, Bob's sentence was a question,   so I'll take that as evidence of some kind of growth.

   Well, take away domain operators, and what is left? Domains, and relations.

   Consider Equals. Pretty unambiguous, huh? But I want you to note that we   call 'equal' a 'relation' in mathematical logic. The term 'operator' is   usually reserved for group manipulation.

   So, here is an example of what the alternative looks like:

   CREATE COMPUTED RELATION Equal ( Domain INTEGER, Range INTEGER );

   CREATE COMPUTED RELATION Equal ( Domain String, Range String );

   RANGE OF Identity ( Domain, Range ) OVER    RETRIEVE ( Domain, Range ) FROM Equal ( INTEGER, INTEGER );

   RANGE OF Identity ( Domain, Range ) OVER    RETRIEVE ( Domain, Range ) FROM Equal ( String, String );

   CREATE REAL RELATION Parts ( PartId INTEGER, Name String )

        Identity ( PartId );

   CREATE REAL RELATION Supplier ( SuppName String,...)

        Identity ( SuppName );

   CREATE REAL RELATION PS ( PartId INTEGER, Supplier String, Price Money )

        Identity ( PartId, Supplier ),
        Exists ( Supplier ( SuppName, ...), Equals ( SuppName, Supplier )),
        Exists ( Parts ( PartId, ...), Equals ( PartId, PS.PartId));

    This is a relation with a 'key' identity, being two elements for which    the 'identity attribute holds in a conjunction. Note the paired rules    which replace 'foreign keys'.    

    Let's see what happens with a slightly more involved example:

   CREATE COMPUTED RELATION Identity ( Domain INTERVAL, Range INTERVAL );

   CREATE COMPUTED RELATION Within ( Domain String, Range INTERVAL );

• NOTE: No Equal here. Although there might be:

   RANGE Overlap ( Domain, Range ) OVER
   RETRIEVE ( Domain, Range ) FROM Identity ( Domain INTERVAl, Range INTERVAL);

   ALTER RELATION PS ADD ATTRIBUTE ( When INTERVAL );

   ALTER RELATION PS DROP Identity,

                     ADD Identity ( PartId, Supplier, When ); 

    Q1: Show me who supplied part "5" at date "D"? (Values always being    their lives as a keystroke. This is not true, but it serves as an axiom    for now. )

    RETRIEVE ( SuppName )

        FROM PS      ( PartId INTEGER, Supplier String, Price Money, 
                       When INTERVAL),
             Equal   ( PartId, "5"),
             Overlap ( Domain, PS.When ) AS O1,
             Within  ( O1.Domain, "D" );

   What the, constitutes the behavior of a domain? Nothing more than the   set of relations within which its use is indicated. (For those of you   who know about the limits to Datalog, I do too, but the point here is   that we don't need 'domain operators', not about the problem raised by   quantifiers and negation in this class of language.)

    You can wrap all kinds of semantic sugar around this. I'm the   "mindless vendor" here (another ad hominem there). But it is liberating to   reason about the implementation using this model, as opposed to a model   where the domain's behavior is fixed and assumed.

     For example, properties of binary relations -- such as commutivity --   fall out of the definition of the relation. And with other properties   such as transitivity and reflexivity I can automate the exploration of a   plan space.

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

   I offered an argument. It has the form of the following syllogism.

  o Date & Darwen said "the relational model needs no . . ."

  o Data & Darwen promptly did " . . ."

  o Therefore, Date & Darwen are inconsistent.

   Having provided the syllogism I then provided the evidence. I showed where   they said what they said , and refuted your claim that the quotation was   out of context. I then showed examples of where they had apparently commited   the offenses they were banning. At every step I have acknowledged the   merits of their work, I have emphasized my respect for it, and I have   demonstrated my knowledge of it through extensive quotation and critical   thinking.

   Let me quote something you just said back to you:

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

   "Of course, we do believe that object technology has important contributions     to make to the database management field as well; indeed, our remarks     above on Object/Relational systems were meant to suggest as much".

    This is from page 1, paragraph 2 of the Manifesto. Once again, you are   either lying (knowingly uttering an untruth) or else you have a shaky grasp   of written comprehension.   

    Let us know which alternative you decide best fits the facts.

     KR

           Pb Received on Sun Sep 07 2003 - 09:59:20 CEST