Re: Multiple-Attribute Keys and 1NF

From: paul c <toledobythesea_at_oohay.ac>
Date: Wed, 29 Aug 2007 16:23:50 GMT
Message-ID: <q4hBi.103807$fJ5.67360_at_pd7urf1no>

JOG wrote:
> On Aug 29, 6:39 am, Jan Hidders <hidd..._at_gmail.com> wrote:

>> On 29 aug, 02:05, JOG <j..._at_cs.nott.ac.uk> wrote:
>>
>>
>>
>>> On Aug 29, 12:42 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>>>> JOG wrote:

...

>>>> That is not a tuple. A tuple would be:
>>>> {(Color, {Yellow, Green}), (Type, earth)}
>>> Yes, I realize it is not a db-tuple, because if one relaxes 1NF then
>>> one doesn't have a db-relation at all.
>> That is irrelevant. In a NFNF setting tuples are still defined as a
>> certain kind of function, and what you gave is not a function.

>
> Aye, I am aware I have dropped the correspondence between a tuple and
> a finite partial function, and left a unrestricted mathematical
> relation in its place. What I really wanted to explore were the
> connotations of doing this.
>

>>> That set-valued element still
>>> represents a proposition however, and is in fact a relation in the
>>> true mathematical sense. I find this representation interesting
>>> because a JOIN becomes a union of these elements, and a natural join
>>> is generated by default as one would expect.
>> That depends a little on what one would expect. ;-) One elegant
>> definition of the natural join of two relations R and S is for example
>> { t1 + t2 | t1 in R, t2 in S, t1 + t2 is a tuple }. If you change the
>> definiton of tuple as you propose this doesn't work anymore.

>
> Well hey, the definition of a tuple in terms of RM is a bit quirky
> anyhow (nevermind cross-product). Why let Codd have all the fun ;)
>
>> Of course it is not hard to come up with a definition that does generalize the >> natural join correctly.

I too am interested in seeing it explored even though it might require discarding some conventional ideas. How "natural join" might work does seem a basic question since inferencing is a main attraction of Codd's model that most people understand fairly readily, just as they dig his table presentation idea. Maybe a different kind of group/ungroup and it would be important to define "insert" as well. I'm not pre-supposing that if it is feasible that it wouldn't end up being a way to implement a physical layer rather than the logical view a user sees.

p Received on Wed Aug 29 2007 - 18:23:50 CEST