Re: relative complement?

On 18/03/2011 2:44 PM, paul c wrote:
> On 18/03/2011 9:15 AM, Erwin wrote:
> ...
>> I looked up "idiosyncracy" in order to understand what is precisely
>> meant by that term and found that it seems to refer to "a way of
>> thinking (or a way of seeing things, or a way of looking at the world -
>> or certain aspects of that world-) that is "peculiar" and "eccentric"
>> and "pertains quite individually to the person holding those
>> isiosyncratic ideas/points of view/...
>> ...
>
> Yes, I meant it that way - most of what I've seen to do with rdbms
> theory and implementation seems burdened with all kinds of unnecessary
> baggage which I do find peculiar.
> ...

For example, when I see (not very often, I'll admit, hope I've got the syntax more or less right) an SQL statement such as "INSERT INTO R VALUES ( A '1', B '2');, I remember this paragraph from McGoveran:

3. A DBMS that supports the relational model cannot be "magic." It cannot compensate for ambiguity, intuit withheld information or assumptions, or correct expressions that violate the designer's or user's intent. If the designer fails to capture information in database design, if information is hidden from the user, or if the user incompetently fails to express their intent [Ed. Note: Or if the data language is not sufficiently expressive], it will certainly produce seemingly anomalous or "surprising" results when faced with these problems.

At the time I first saw it and still now, I thought the note from the editor, who I assume was Fabien Pascal, about 'sufficiently expressive' language was the statement in that paragraph that was most pertinent to implementation.

My reason is the assumption that at any all times, all the relations recorded by an rdbms must have predicates and implications of those predicates that aren't contradictory. When I fooled around with this stuff for a living, a guy I worked for used to dispense with customer complaints about crashed or hung db engines with "well, would you rather have a dbms that starts up and gives wrong answers?".

I mention this because personally I agree with the TTM definition of 'Insert B to A' as producing a relation that is the result of A <OR> B. The reason for that is that the A-algebra seems much more formal, ie. precise, to me than the verbose SQL definitions I can barely remember.

However, if the "VALUES ( A '1', B '2')" clause of the INSERT statement stands for a relation, in other words 'B' above, I would say there is no way B could possibly have the same predicate as A, unless A and B have the same tuples. Since most of the time any useful INSERT statement is not likely to satisfy this requirement, I would think a language designer must recognize that A and B must have different predicates.

Personally, if I were designing a language, I think I would have to state that B's predicate is indeterminate. It is only partly determinate in the sense that the predicate can't be the same as A's predicate. Therefore any desire to make it determinate must be suppressed. My preference would be for the language to include the assumption that B has no more meaning than that the VALUES clause represents an assertion of the truth of a relation that contains only the described tuple.

Given that preference, I think join deletes and union inserts become mechanical problems. For me, in the end it amounts simply to a user stating that the tuples of the literal B relation are (all) true and that B's predicate is immaterial. With those two assertions, the A-algebra is sufficient to describe what results a language should produce without ambiguity.

The only reason I'm a little hesitant about the above is that some of the deep thinkers go into a lot more detail, for example McGoveran talks about relative complement and logical independence and Date talks about symmetry and multiple assignment, et cetera. There's lots more that I won't belabour, anyway I still can't see what symmetry has to do with all of this, makes me wonder if I'm missing something deep (always possible I admit!) that has nothing to do with language design. Received on Sat Mar 19 2011 - 00:47:42 CET