Re: Multiple-Attribute Keys and 1NF

On Aug 31, 7:42 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> "JOG" <j..._at_cs.nott.ac.uk> wrote in message
>
> news:1188568287.595590.272990_at_50g2000hsm.googlegroups.com...
>
>
>
> > 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.
>
> But there aren't any groups. I probably should have formatted R differently
> for clarity,

You're right - ungrouping is the wrong term given its use with rva's. I'm imagining an operator that would translate: { { (Colour, Green), (Colour, Yellow), (Type, Earth) } } into:
{ { (Colour, Green), (Type, Earth) } , { (Colour, Yellow), (Type, Earth) } }

Anyone ideas for a name? A SEPERATE perhaps. Always good to use a word that people have trouble spelling ;)

>
> R {{A:4,A:5},
> {A:5},
> {A:5,A:6}}
>
> Correct me if I'm wrong, but it seems to me that you're suggesting that
> multiple values for the same attribute can appear in the same "tuple." In
> that case it wouldn't matter if you renamed one of the operands of the join.
> The result would be the same.

R JOIN R = {{RA:4, RA:5}, {RA:5}, {RA:5, RA:6}, {RA:4, RA:5, RA:6}} R JOIN (R AS S) =
{

 {RA:4, RA:5, SA:4, SA:5},
 {RA:5, SA:4, SA:5},
 {RA:5, RA:6, SA:4, SA:5} ,
 {RA:4, RA:5, SA:5},
 {RA:5, SA:5},
 {RA:5, RA:6, SA:5} ,
 {RA:4, RA:5, SA:5, SA:6},
 {RA:5, SA:5, SA:6},
 {RA:5,RA:6, SA:5, SA:6}

Phew. That was a beer powered enumeration brought to you by Guinness.

> R {{A:4,A:5},
> {A:5},
> {A:5,A:6}}

>
>
>
> >> >> But you're right that accessibility has nothing to do with identity.
> >> >> A
> >> >> value can appear many times in many different tuples and in many
> >> >> different
> >> >> relations. Logical identity ensures that no matter how many times a
> >> >> value
> >> >> appears in a database, it always maps to the same individual in the
> >> >> universe
> >> >> of discourse.
>
> >> >> > Logically "addressable" - that's a very different kettle of fish to
> >> >> > identity. In your original question did you mean to ask then: "What
> >> >> > provides logical addressibality?" if one has two attributes playing
> >> >> > the same role? I won't respond to that in advance, because I don't
> >> >> > want to put words into your mouth. Regards, J.
Received on Sat Sep 01 2007 - 02:56:24 CEST