Re: Multiple-Attribute Keys and 1NF
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Fri, 31 Aug 2007 12:19:20 -0300
Message-ID: <46d8312b$0$4060$9a566e8b_at_news.aliant.net>
>>JOG wrote:
>>
>>>On Aug 31, 2:28 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>>
>>>>"JOG" <j..._at_cs.nott.ac.uk> wrote in message
>>
>>>>news:1188556656.192653.305160_at_r23g2000prd.googlegroups.com...
>>
>>>>>On Aug 31, 3:13 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>>
>>>>>>[snip]
>>>>>>"JOG" <j..._at_cs.nott.ac.uk> 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
>>>>>mean.
>>
>>>>>>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
>>>>>>guaranteed
>>>>>>access rule either way you look at it. If the column names aren't
>>>>>>unique,
>>>>>>then you can't access a particular datum by a column name. If a value is
>>>>>>a
>>>>>>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.
Date: Fri, 31 Aug 2007 12:19:20 -0300
Message-ID: <46d8312b$0$4060$9a566e8b_at_news.aliant.net>
JOG wrote:
> On Aug 31, 3:01 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote: >
>>JOG wrote:
>>
>>>On Aug 31, 2:28 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>>
>>>>"JOG" <j..._at_cs.nott.ac.uk> wrote in message
>>
>>>>news:1188556656.192653.305160_at_r23g2000prd.googlegroups.com...
>>
>>>>>On Aug 31, 3:13 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>>
>>>>>>[snip]
>>>>>>"JOG" <j..._at_cs.nott.ac.uk> 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
>>>>>mean.
>>
>>>>>>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
>>>>>>guaranteed
>>>>>>access rule either way you look at it. If the column names aren't
>>>>>>unique,
>>>>>>then you can't access a particular datum by a column name. If a value is
>>>>>>a
>>>>>>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.
> > Hadn't got on to join comparisons yet myself (just been considering > cross joins) but I imagine this is a valid point. Is it fair to say > that a join comparison can consistently be considered as a cross join > followed by a restrict?
If one assumes something like SQL, I suppose one could. I think of cross joins as natural joins with no common attributes. Received on Fri Aug 31 2007 - 17:19:20 CEST