Re: Multiple-Attribute Keys and 1NF

From: Brian Selzer <>
Date: Fri, 31 Aug 2007 07:34:56 -0400
Message-ID: <A1TBi.1708$>

"Brian Selzer" <> wrote in message news:BQSBi.1702$
> "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
>> 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.
> What about restriction?
> R {{A:4, A:5, B:3},
> {A:3,A:4,B:4}}
> R WHERE A = 3?
> Do you return an empty relation, or {{A:3,A:4,B:4}}?
> If A = 3 is true, then A = 4 is also true, but shouldn't that be
> impossible?
> If A were a set, then you could write,
> R WHERE A = 4 AND A = 5?
> Shouldn't A = 4 AND A = 5 always return false?

How would you deal with this:

R {{A:3, B:3},


UPDATE R WHERE A = 4 (A:=3) Supposing that A is the key,

Do you allow {A:3,A:3,B:4}?

Do you reject the update since {A:3, B:3} and {A:3, B:4}?
Do you combine the B elements, {A:3, B:3, B:4}?
Or does {A:3,B:4} supplant {A:3,B:3}?

>>> 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 Fri Aug 31 2007 - 13:34:56 CEST

Original text of this message