Re: Relation Schemata vs. Relation Variables

"Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message news:hIhIg.2199$9u.39081_at_ursa-nb00s0.nbnet.nb.ca...
> David Cressey wrote:
>
>> "Brian Selzer" <brian_at_selzer-software.com> wrote in message
>> news:rn1Ig.12260$1f6.6985_at_newssvr27.news.prodigy.net...
>>
>>>"David Cressey" <dcressey_at_verizon.net> wrote in message
>>>news:c8YHg.45$8Q6.5_at_trndny01...
>>>
>>>>"Brian Selzer" <brian_at_selzer-software.com> wrote in message
>>>>news:vYJHg.17542$gY6.10049_at_newssvr11.news.prodigy.com...
>>>>
>>>>>>>>A small digression: all this reminds me of the (in)famous SQL
>>>>>>
>>>>>>construct:
>>>>>>
>>>>>>>>UPDATE .... WHERE CURRENT of <cursor>
>>>>>>>
>>>>>>>That's probably because it hasn't clicked yet that a transition is a
>>>>>>>*set*
>>>>>>>of triples, where each element represents only a distinct component
>>
>> of
>>
>>>>>>>the
>>>>>>>overall difference between the current database state and a
>>
>> /possible
>>
>>>>>>>state/. The above construct involves something that passes over a
>>>>
>>>>result
>>>>
>>>>>>>set in a particular sequence. That's a totally different thing
>>>>>>
>>>>>>altogether.
>>>>>>
>>>>>>I'm well aware that you are talking about a set of transitions. Your
>>>>>>professional history of dealing with bozos has conditioned you into a
>>>>>>habit
>>>>>>of condescension that is out of place in this newsgroup.
>>>>>>
>>>>>
>>>>>I ASS-U-MEd that you were confusing triples with transitions because of
>>>>
>>>>the
>>>>
>>>>>digression below. I was wrong, and I apologize. I did not intend to
>>
>> be
>>
>>>>>condescending.
>>>>>
>>>>
>>>>OK. No harm done. The subject of UPDATE ... WHERE CURRENT is worth a
>>>>side
>>>>discussion here, because
>>>>it blurs the distinction between content based addressing and location
>>>>based
>>>>addressing. The CURRENT row of a result table is like "the can of
>>>>Campbell's chicken noodle soup that I have in my left hand", although
>>
>> at
>>
>>>>a
>>>>different level of abstraction.
>>>
>>>I see your point. On the other hand, since the set of triples in a
>>>transition describes the entire difference between two successive
>>>database
>>>states, it is not exactly the same thing.
>
> The set of triples does that in the hypothetical implementation of 'on
> update cascade' that Selzer made up.
>
>
>> Does the set of triples describe the entire difference or does it
>> prescribe
>> the entire difference?
>
> The question to ask oneself is: "What relevance do these implementation
> details have to any theory?"
>

What implementation details? This is not about implementation. It is about the limitations of relational and multiple assignment. This is about how having variables as part of the definition of a datbase is illogical. When you're talking about changes of state, you must be talking about database values, not just relation values, because a proposed state for one relation may depend on the current state of another. For that matter, the entire concept of multiple assignment is just a kludge to work around problems that were introduced when D&D decided to wrap variables around relations instead of databases. Yes, multiple assignment solves some symptoms of the problem, but it doesn't address the root cause, nor does it allow for the definition of enforcible transition constraints. There are other problems with using variables to define databases. Date's translation of Heath's theorem in terms of relvars instead of relations is a huge leap. The statement that a relvar is equal to the join of its projections is patently false: because a relvar is a variable, there is an infinite number of values for each projection (also variables) that when joined are equal to any one value for the original relvar. Hence, a relvar is equal to the join of its projections only in the presence of a circular inclusion dependency or mutual foreign keys. Using variables in the definition of a database causes a huge amount of confusion and limits the expressiveness of the model because assignment involves only one kind of transition: replacement. One set of tuples is discarded in favor of another set. There is no correlation between the tuples in each set. Tuples may appear identical, that is, their component attribute values may be identical, but because assignment replaces the current relation value or values and because no information is provided about how tuples correlate, all of the new tuples are logically distinct because they belong to a different database state. In a closed world, if you can't prove that they mean the same thing, then they don't.

>
>>>The idea of location based
>>>addressing doesn't have any place in the conceptual or logical models.
>>
>> Agreed.
>
> True, which is why another implementation might use physical location
> internally and represent it differently to the user. For example, consider
> an implementation that represents the update to the triggered procedure as
> a single relvar with two attributes 'new' and 'old' where each attribute
> is a relation valued attribute with a type that is a sub-type of R's
> constrained to at most one tuple. Such an implementation can associate
> individual tuples in the initial state with individual tuples in the final
> state using physical location but the user always interacts with relvars
> and relations.
>
>
>>>What
>>>I'm trying to point out is that how tuples correlate during an update is
>>>something that either the database designer must specify, or that the
>>>user
>>>must specify, or both.
>>
>> Here's where you're losing me. What does this "correlation" signify?
>
> He isn't losing me. He is just flat-out plain old wrong. The dbms can
> correlate tuples during an update by physical location. After all, the
> dbms has access to and manages the internal physical representation of the
> data.
>
>
> Does
>> it mean that the old tuple and the new tuple
>> both refer to the same item in the universe of discourse (subject
>> matter)?
>> Does it mean that the old tuple and the new tuple are both stored in the
>> same row of the same table (implementation)? Or does it means that the
>> new
>> one "replaces" the old one in the sense of overwriting the old one in
>> some
>> (part of) a variable? Or something else?
>
> Who cares? He is a self-aggrandizing ignorant who demonstrably talks
> gibberish. Even if he accidently manages to reply with something that
> sounds cogent, how will you know whether he understands what he says the
> same way a normal educated person would understand it?
>
>
>>>The database designer specifies it with a
>>>system-generated surrogate.
>>
>> would you explain this a little more clearly?
>
> Why do you keep inviting him to waste more of everyone's time?
>
>
> [yet another idiotic straw man snipped]
>
>
>> In the five updates above, you are updating one or both of the candidate
>> keys. Earlier, you said, IIRC, that keys should be immutable. Why
>> isn't
>> this a contradiction?
>
> If you are going to pretend to engage the self-aggrandizing ignorants,
> please do a better job of calling them on their bullshit. What is the
> point of asking him about the details of a straw man? It's a straw man.
> 'Nuff said.
Received on Sun Aug 27 2006 - 23:21:47 CEST