Re: Multiple-Attribute Keys and 1NF

From: Bob Badour <>
Date: Fri, 31 Aug 2007 11:01:38 -0300
Message-ID: <46d81ef4$0$4033$>

JOG wrote:

> On Aug 31, 2:28 pm, "Brian Selzer" <> wrote:

>>"JOG" <> wrote in message
>>>On Aug 31, 3:13 am, "Brian Selzer" <> wrote:
>>>>"JOG" <> wrote in message
>>>>>Well, I have to contest again - you are no doubt referring to "rule
>>>>>2:The guaranteed access rule", and that makes no reference to the term
>>>>>identity (...and that is what you asked me about.) Rule 2 is stating :
>>>>>"every individual value in the database must be logically addressable
>>>>>by specifying the name of the table, the name of the column and the
>>>>>primary key value of the containing row."
>>>>Pardon me for being a stickler about this. I got this from dbdebunk:
>>>no worries - stickling is fine.
>>>>"Each and every datum (atomic value) is guaranteed to be logically
>>>>accessible by resorting to a combination of table name, primary key value
>>>>and column name."
>>>Coupla things - Date and Darwen argue against the idea of atomicity,
>>>and they also complain about the use of 'primary key'. I also think
>>>Codds use of the term datum is incorrect. Throughout history data has
>>>required an attribute-value pair. The word is derived from the latin
>>>for 'statement of fact', its use in science always requires that the
>>>value is described. Its common sense really - if we don't know what a
>>>value means, well its just noise. Imagine the binary value 1000001.
>>>Ascii(1000001) makes it an A, Number1000001) makes it 65, etc.
>>>Either way, this doesn't matter as long as we know what each other
>>>>A datum is an /atomic/ value, not an individual value. Atomic--implying
>>>>that it cannot be separated into components.
>>>>So having more than one value for a particular role violates the
>>>>access rule either way you look at it. If the column names aren't
>>>>then you can't access a particular datum by a column name. If a value is
>>>>collection of component values, then you can't access a particular datum
>>>>(component value), but only the collection in which it is contained.
>>>Well I've never suggested multiple values contained in a collection.
>>>But yes as I said, multiple roles does break the guaranteed access
>>>rule. My question is now (in the continuuing hunt for the theory
>>>behind 1NF) is why on earth would that be a problem? I don't see any
>>>affect on the relational algebra.
>>How do you deal with join:
> Just wanna emphasize the point that I'm not trying to sell anything
> here! I'm just exploring the idea (outloud).

>>R {{A:4,A:5},{A:5},{A:5,A:6}}
>>Wouldn't R JOIN R =
>>{{A:4,A:5},{A:5},{A:5,A:6}, {A:4,A:5,A:6}}?
> Yup I guess a natural join would work exactly like that. Unless you of
> course you used RENAME so:
> (R AS r1) JOIN (R AS r2) = {not got the energy to enumerate the 9
> propositions, entailing 30 pairs}
> However I'd imagine that before joins one would often be UNGROUPing
> first.

I disagree. If one uses an RVA to describe the Green+Yellow wire, one will want to use the entire relation value in join comparisons. Received on Fri Aug 31 2007 - 16:01:38 CEST

Original text of this message