Re: Multiple-Attribute Keys and 1NF

From: Brian Selzer <brian_at_selzer-software.com>
Date: Tue, 28 Aug 2007 16:33:04 GMT
Message-ID: <47YAi.21726$eY.10792_at_newssvr13.news.prodigy.net>


"JOG" <jog_at_cs.nott.ac.uk> wrote in message news:1188303981.637381.32500_at_r29g2000hsg.googlegroups.com...
>I am still fighting with the theoretical underpinning for 1NF. As
> such, any comments would be greatfully accepted. The reason for my
> concern is that there /seems/ instances where 1NF is insufficient. An
> example occurred to me while I was wiring up a dimmer switch (at the
> behest of mrs. JOG, to whom there may only be obeyance). Now I don't
> know the situation in the US, but in the UK a while back the colour
> codes for domestic main circuit wiring changed. Naturally the two
> schemes exist in tandem, as exhibited in every house I've had the joy
> of doing some DIY in:
>
> Brown -> live.
> Red -> live
> Blue -> neutral.
> Black -> neutral.
> Green and yellow -> earth.
>
> The issue with encoding these propositions is that the candidate key
> for each proposition may consist of one _or_ two colours. Now I have a
> couple of options, none of which seem satisfactory. I could leave
> green & yellow as some sort of set-value composite, but obviously this
> would affect my querying capabilities, so thats out straight off the
> bat. Similarly adding attributes Colour1 and a nullable Colour2 is
> simply so hideous it isn't worth consideration. So, I could ungroup to
> give me:
>
> Colour Type
> -----------------
> Brown live
> Red live
> Black neutral
> Blue neutral
> Green earth
> Yellow earth
> -----------------
>
> But again this is unsatisfactory as I have lost the information that
> one wire is green and yellow, but none is brown /and/ red.
>
> I could introduce a surrogate to give me:
>
> Id Colour Type
> -----------------
> 1 Brown live
> 2 Red live
> 3 Black neutral
> 4 Blue neutral
> 5 Green earth
> 5 Yellow earth
> -----------------
>
> But this seems wholly artificial given that all the information I
> required for identification was available in the original
> propositions, and that did not require some artificial id.

It may seem artificial, but it isn't. A wire is not identified by an element of the Colour domain, but rather by a subset of the Colour domain. Even if a wire has only one colour, a wire is not identified by that colour, but by the set of colours which just happens to consist of the single colour. If you want to avoid a second-order predicate (one that ranges over subsets of the Colour domain), you can assign a name to each colour combination. (That's all that a surrogate is: a name.) In this way all of the domains remain simple, and the queries remain simple, but at the same time all of the relationships amongst Wires and Colours and Types are retained.

> A [shudder]
> non 1NF variation such as:
>
> Id Colour Type
> -----------------
> 1 Brown live
> 2 Red live
> 3 Black neutral
> 4 Blue neutral
> 5 Green, earth
> Yellow
> -----------------
>
> is clearly hideous as it denies the fundamental mathematical principle
> that that one attribute should take one value from one domain,
> nevermind the fact that it introduces query bias.
>
> I could of course introduce nested relations, but I am uncertain as to
> the theoretical consequences of having nested relation as a key (I
> guess it would be fine, if adding seemingly unnessecary complexity to
> subsequent queries). But moreover it again seems unintuitive, given
> that in this case it would indicating that the original propositions
> contained, as a value for one of their attributes, a further
> proposition, and this was not the case.
>
> I am having a crisis of faith with the way 1NF is currently viewed.
> Any ideas to solve my dilemma? Am I on my own in being perturbed?
>
> Regards, Jim.
>
Received on Tue Aug 28 2007 - 18:33:04 CEST

Original text of this message