Re: Multiple-Attribute Keys and 1NF

On Aug 31, 2:28 pm, "Brian Selzer" <br...@xxxxxxxxxxxxxxxxxxx> wrote:
"JOG" <j...@xxxxxxxxxxxxx> wrote in message

news:1188556656.192653.305160@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx



On Aug 31, 3:13 am, "Brian Selzer" <br...@xxxxxxxxxxxxxxxxxxx> wrote:
[snip]
"JOG" <j...@xxxxxxxxxxxxx> 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 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.


.

Relevant Pages

  • Re: Multiple-Attribute Keys and 1NF
    ... accessible by resorting to a combination of table name, primary key ... access rule either way you look at it. ... multiple roles does break the guaranteed access ... provides logical addressibality?" ...
    (comp.databases.theory)
  • Re: Multiple-Attribute Keys and 1NF
    ... accessible by resorting to a combination of table name, primary key value ... access rule either way you look at it. ... multiple roles does break the guaranteed access ... provides logical addressibality?" ...
    (comp.databases.theory)
  • Re: Multiple-Attribute Keys and 1NF
    ... accessible by resorting to a combination of table name, primary key value ... access rule either way you look at it. ... multiple roles does break the guaranteed access ... provides logical addressibality?" ...
    (comp.databases.theory)
  • Re: Multiple-Attribute Keys and 1NF
    ... accessible by resorting to a combination of table name, primary key value ... access rule either way you look at it. ... multiple roles does break the guaranteed access ... provides logical addressibality?" ...
    (comp.databases.theory)
  • Re: Multiple-Attribute Keys and 1NF
    ... accessible by resorting to a combination of table name, primary key ... access rule either way you look at it. ... multiple roles does break the guaranteed access ... provides logical addressibality?" ...
    (comp.databases.theory)