Re: a union is always a join!

From: Brian Selzer <>
Date: Fri, 13 Mar 2009 19:34:27 -0400
Message-ID: <84Cul.18639$>

"paul c" <> wrote in message news:ZXlul.17783$PH1.16918_at_edtnps82...

> Brian Selzer wrote:

>> "Walter Mitty" <> wrote in message
>> news:apltl.2309$
>>> "Brian Selzer" <> wrote in message 
>>> news:eY2tl.9205$
>>>> "paul c" <> wrote in message 
>>>> news:beZsl.15959$Db2.2243_at_edtnps83...
>>>>> Walter Mitty wrote:
>>>>>> ...  I'm also going to suggest that what
>>>>>> Brain S. calls "oversimplification" is almost exactly what others 
>>>>>> call
>>>>>> "abstraction".  I'm also going to suggest that without abstraction 
>>>>>> you don't
>>>>>> get any independence, and without independence, you don't get much of 
>>>>>> any
>>>>>> bang for the buck.  That may be of zero theoretical importance, but 
>>>>>> it's of
>>>>>> interest to me.
>>>>>> ...
>>>>> Walter, I'm with the many people who think phyaical and logical 
>>>>> independence are of high importance, both theoretically and 
>>>>> practically. But I'd say many of the nuances and implications of those 
>>>>> haven't been explored much in print.  Brain S as you call him 
>>>>> regularly enters the realm of mysticism.  I point this out not to 
>>>>> correct him, but to warn newcomers here that he is not exactly 
>>>>> swimming in the main stream of relational theory (to be fair, not many 
>>>>> are, because the theory is often confused with past practice).  I have 
>>>>> a number of mystic acquaintances and I like them all, partly because 
>>>>> they don't involve themselves in db theory and there is much in life 
>>>>> for which mysticism offers the only comfortable clues.
>>>> Mysticism.  If accepting that the universe of discourse contains things 
>>>> and that at different times a thing can differ in appearance yet still 
>>>> be the same thing means that I'm a mystic, then I'm guilty as charged.
>>> What difference does it make whether it's the same thing or a different 
>>> thing?

>> If an employee worked 50 hours on a project and his labor rate is $20 per
>> hour, then it cost $1000 to have him work on the project, right? WRONG!
>> The employee's labor rate /is/ $20 per hour, but that doesn't mean that
>> it /had been/ $20 per hour during the time that he worked on the project.
>> At that time his labor rate might have been $18 per hour or may even have
>> changed part way through the project. So the record of cost must not
>> contain just which project, which employee and how many hours, but also
>> at which labor rate or rates the work was performed. But the employee is
>> still the same employee even though his labor rate changed from $18 to
>> $20. Other cost records may exist for projects that he worked on after
>> the rate increase, and one should expect that a query of which projects
>> he worked on would return all of the projects, regardless of the labor
>> rate.

>> So something can appear different at different times yet still be the
>> same thing.

>> This poses a problem because keys are not necessarily permanent
>> identifiers. (I'm having trouble articulating my thought here because
>> there is more than one usage of the term, "key." I'm disinclined from
>> using "key value" because under an interpretation, a key value is a
>> mapping to a particular thing in the universe, that thing being the
>> output of the valuation function for the set of symbols for the
>> components in a tuple of the set of attributes that is the candidate key,
>> and it's possible for that same set of symbols to map to different things
>> at different times, or for different sets of symbols to map to the same
>> thing at different times. But it's unwieldy to say "sets of symbols for
>> the components in a tuple of the set of attributes that is the candidate
>> key" instead of just "keys.") The problem stems from how things in the
>> universe of discourse are identified, and that the scope of the
>> definition of a candidate key is any database and not all databases.
>> While a key may uniquely identify something in the context of its
>> containing database, that doesn't necessarily mean that that same key
>> uniquely identifies that same something at all databases in which it
>> appears.
> I wish, at least once, you would give an answer that was shorter than the 
> question.

Ask me a question that has a simple answer, and I'll simply answer it. Received on Sat Mar 14 2009 - 00:34:27 CET

Original text of this message