Re: Multiple-Attribute Keys and 1NF
Date: Thu, 30 Aug 2007 22:13:58 -0400
Message-ID: <HPKBi.1667$z_5.262_at_nlpi069.nbdc.sbc.com>
"JOG" <jog_at_cs.nott.ac.uk> wrote in message news:1188496817.753575.79660_at_y42g2000hsy.googlegroups.com...
> On Aug 30, 6:33 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>> JOG wrote:
>> > On Aug 30, 5:00 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>>
>> >>JOG wrote:
>>
>> >>>On Aug 30, 2:55 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>>
>> >>>>JOG wrote:
>>
>> >>>>>On Aug 30, 1:44 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>>
>> >>>>>>JOG wrote:
>>
>> >>>>>>>On Aug 30, 1:42 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>>
>> >>>>>>>>JOG wrote:
>>
>> >>>>>>>>>>Write a predicate for the relation schema that when extentially
>> >>>>>>>>>>quantified
>> >>>>>>>>>>and extended yields a set of atomic formulae that implies all
>> >>>>>>>>>>three of the
>> >>>>>>>>>>propositions above. I think you'll find that the colour-code
>> >>>>>>>>>>concept is in
>> >>>>>>>>>>that predicate.
>>
>> >>>>>>>>>I agree. I hold little stock with set based values so in RM I
>> >>>>>>>>>would go
>> >>>>>>>>>for the addition of colour-code foreign key.
>>
>> >>>>>>>>>But what if we weren't tied to a traditional relational schema
>> >>>>>>>>>and
>> >>>>>>>>>tweaked the system so it could allow propositions with more than
>> >>>>>>>>>one
>> >>>>>>>>>role of the same name without decomposing them. As Jan pointed
>> >>>>>>>>>out
>> >>>>>>>>>'tuples' are no longer functions - they would be unrestricted
>> >>>>>>>>>binary
>> >>>>>>>>>relations (subsets of attribute x values). We could produce a
>> >>>>>>>>>comparatively simpler and less cluttered schema, predicate in a
>> >>>>>>>>>very
>> >>>>>>>>>similar manner as before, and with a few simple alterations
>> >>>>>>>>>could have
>> >>>>>>>>>an equally effective WHERE mechanism. My concern however would
>> >>>>>>>>>be the
>> >>>>>>>>>consequences to JOIN.
>>
>> >>>>>>>>What would you offer in place of the RM's logical identity.
>>
>> >>>>>>>Nothing. I am utterly convinced by Date et al's arguments in
>> >>>>>>>favour of
>> >>>>>>>logical identity. (Why would I need to replace it?) I just wanna
>> >>>>>>>model
>> >>>>>>>propositions, and they are always identified by their contents.
>>
>> >>>>>>In: {{(Color: green), (Color: yellow), (Type: earth)}}
>>
>> >>>>>>What provides logical identity?
>>
>> >>>>>I may be misunderstanding you, but let me take a stab. The identity
>> >>>>>of
>> >>>>>any set of course lies in its elements (i.e. in this of a single
>> >>>>>propositions, the ordered pairs). Given we know Colors are the
>> >>>>>antecedents in the proposition we are modelling, this has to be been
>> >>>>>defined in the collectivizing predicate for the whole collection of
>> >>>>>rows. We also know therefore there may not exist another set of
>> >>>>>pairs
>> >>>>>containing the same Colors, so we can identify the whole proposition
>> >>>>>through examination of just those roles. All works just as per
>> >>>>>normal
>> >>>>>in RM. Is this what you meant?
>>
>> >>>>I haven't got a clue what you said.
>>
>> >>>I just regurgitated leibniz identity.
>>
>> >>>>In the RM, every value is uniquely
>> >>>>identifiable by the combination of relation name, attribute name and
>> >>>>any
>> >>>>candidate key value. That's logical identity as it was originally
>> >>>>spelled out.
>>
>> >>>>Two values above have the same attribute name.
>>
>> >>>Now you've lost me. A "value" is not identifiable by its relation name
>> >>>and attribute name. This makes no sense to me. Where in predicate
>> >>>logic does that come from? A value is just a value. It is identifiable
>> >>>in its own right as being an individual from a domain.
>>
>> >>I mispoke. "Any value represented in a relvar"
>>
>> > Well it is still just a value whether its in a relvar or not - it
>> > needs no extra identity. A database table is just a set of
>> > propositions. A proposition is encoded as a set of attribute-value
>> > pairs. That's it surely?
>>
>> > Any notion of identity is as defined by set theory.
>>
>> >>>An individual piece of /data/ however (which is perhaps what you mean
>> >>>by a value) has an identity made up of a combination of an attribute
>> >>>name and a corresponding value. One needs both to identify the data
>> >>>item. A proposition in turn is identifiable by its contents, which is
>> >>>a set of those data items. Regards, J.
>>
>> >>I repeat: two pieces of data have the same name, Color.
>>
>> > Well no - a piece of data doesn't have a 'name' does it? It's just a
>> > combination of attribute and value. The number-7. name-Fred. color-
>> > red. A datum's identity is defined by the /combination/ of these two
>> > parts, and that alone - not by a label, or an alias, or an OID (as I'm
>> > sure you'd agree).
>>
>> No, I don't agree. I suggest you see the definition of Logical Identity
>> in Codd's 12 rules.
> > 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:
"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."
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.
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 - 04:13:58 CEST