Re: Multiple-Attribute Keys and 1NF

From: Bob Badour <>
Date: Thu, 30 Aug 2007 16:14:43 -0300
Message-ID: <46d716d6$0$4050$>

JOG wrote:

> On Aug 30, 6:41 pm, "Brian Selzer" <> wrote:

>>"JOG" <> wrote in message
>>>On Aug 30, 1:41 am, "Brian Selzer" <> wrote:
>>>>"JOG" <> wrote in message
>>>>>On Aug 29, 7:03 pm, "Brian Selzer" <> wrote:
>>>>>>"JOG" <> wrote in message
>>>>>>>On Aug 29, 12:49 pm, Bob Badour <> wrote:
>>>>>>>>JOG wrote:
>>>>>>>>>On Aug 29, 6:10 am, "David Cressey" <>
>>>>>>>>>>"JOG" <> wrote in message
>>>>>>>>>>>Okay, sure. But then to be able to query for green and yellow
>>>>>>>>>>>individually one must employ a further relation encoding two
>>>>>>>>>>>propositions that state "'Green and yellow' contains 'Green'"
>>>>>>>>>>>"'Green and yellow' contains 'Yellow'" respectively. One then
>>>>>>>>>>>has a
>>>>>>>>>>>schema with two domains - one for the composites and one for
>>>>>>>>>>>individual colours (which is what I was inferring when I
>>>>>>>>>>>said a new one was being added).
>>>>>>>>>>It took me a while to realize that what you meant from your
>>>>>>>>>>description was that
>>>>>>>>>>"a green and yellow wire means earth". I had thought you meant
>>>>>>>>>>wire means earth" and "a yellow wire means earth". Pardon me
>>>>>>>>>>Clearly what we have here is not a domain of colors, but a
>>>>>>>>>>codes, where a color code contains one or more colors, and
>>>>>>>>>>maybe a
>>>>>>>>>>or thin" qualifier on each color.
>>>>>>>>>>It's not clear to me why you need to able to query on simple
>>>>>>>>>>you need to decompose the color coding scheme into its
>>>>>>>>>>parts for
>>>>>>>>>>some reason.
>>>>>>>>>>There are lot of code domains where each code is made up of a set
>>>>>>>>>>primitive elements.
>>>>>>>>>>Perhaps a very relevant one might be "character code". If I have
>>>>>>>>>>following primitive elements:
>>>>>>>>>>B1, B2, B4, B8, B16, B32, B64, B128
>>>>>>>>>>(which might be an odd way of labelling bits 0 through 7 of a
>>>>>>>>>>think of the character code for 'A' as being B64+B1. Now I could
>>>>>>>>>>all the character codes without necessarily having an operator
>>>>>>>>>>yield "all the codes that include B1".
>>>>>>>>>>I think that the colors, as constituents of color codes, play
>>>>>>>>>>as bits, as constituents of character codes. Do you agree?
>>>>>>>>>Yes. I mean no. No, yes. Gnngh ;)
>>>>>>>>>Ok, of course I understand your point - a wire can be viewed as
>>>>>>>>>a colour code, which itself has constituent parts. But its just
>>>>>>>>>interpretation right. I am still seeing a difference between the
>>>>>>>>>* There is a colour-code "yellow and green" that denotes "earth".
>>>>>>>>>* The casing of an earth wire features the colour yellow and the
>>>>>>>>>colour green.
>>>>>>>>>Its just like the difference between the propositions:
>>>>>>>>>* My office is B42
>>>>>>>>>* My office is on floor B, room 42.
>>>>>>>>>There are instances where I may well want to encode as the second
>>>>>>>>>proposition forms. And /if/ that were the case (iff), well 1NF is
>>>>>>>>>precluding me from doing this in terms of the wire example.
>>>>>>>>I disagree. You have already noted that 1NF allows this with
>>>>>>>>exactly 2
>>>>>>>>relations (or with 1 relation and one or more operations on the
>>>>>>>>code domain.)
>>>>>>>True, I do see that, but it does so by requiring the invention of a
>>>>>>>colour-code concept which isn't in the proposition "The casing of an
>>>>>>>earth wire features the colour yellow and the colour green".
>>>>>>You have to consider the entire relation value: what about the
>>>>>>(treating or exclusively, of course):
>>>>>>"The casing of a live wire features the colour brown or the colour
>>>>>>"The casing of a neutral wire features the colour blue or the colour
>>>>>>Write a predicate for the relation schema that when extentially
>>>>>>and extended yields a set of atomic formulae that implies all three of
>>>>>>propositions above. I think you'll find that the colour-code concept
>>>>>>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.
>>>>I'm not sure I understand what you are driving at. In the example you
>>>>provided, it is the combinations of values from a simple domain that have
>>>>significance, regardless of whether they're wrapped in a single attribute
>>>>not. To me it doesn't make sense to have multiple attributes with the
>>>>name--the attribute names correspond to free variables in a predicate:
>>>>could you assign multiple values to the same variable?
>>>Well consider it this way. If I have the propositions:
>>>The person named Jim speaks the language English
>>>The person named Jim speaks the language German
>>>The person named Brian speaks the language English
>>>I have three propositions, and hopefully we'd agree there are two
>>>roles in these propositions: name and speaks_language. So in FOL I
>>>could write these propositions as:
>>>[P1] Name(x, Jim) -> speaks_language(x, English)
>>>[P2] Name(x, Jim) -> speaks_language(x, English)
>>>[P3] Name(x, Brian) -> speaks_language(x, English)
>>>Are we agreed up to there?
>>Not exactly. What you have are the roles Name and Language which appear as
>>free variables in the predicate Speaks. A sentence in FOL is a closed
>>formula, for example,
>>exists Name exists Language Speaks(Name,Language)
> Well that is certainly one possibility, and of course I realise that
> it is how Codd prescribed encoding a proposition in his 1969 paper. I
> am suggesting that:
> Ex has_Name(x, persons_name) -> speaks_language(x, language)
> is an equally valid, if not better option. Why? Because we can
> explicitly incorporate attribute names (which remember Codd just
> bolted on, redefining a mathematical relation in the process), and
> secondly the key is clearly expressed (all attributes to the left of
> the ->) - there is no need for a magic header.

How does it express multiple candidate keys? Received on Thu Aug 30 2007 - 21:14:43 CEST

Original text of this message