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. 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.

On Aug 28, 7:26 am, JOG <j... (AT) cs (DOT) nott.ac.uk> wrote:
Sounds like there are not "wire colors" with a meaning so much as
"wire patterns", with a meaning:

Wire Pattern | Meaning
Brown | live
Red | live
Black | neutral
Blue | neutral
Green and Yellow | earth
Rainbow | telephone

Wire Pattern | color
Brown | Brown
Red | Red
Black | Black
Blue | Blue
Green and Yellow | Green
Green and Yellow | Yellow
Rainbow | Red
Rainbow | Yellow
Rainbow | Blue
Rainbow | Green

Would this clear up the issue?

"JOG" <jog (AT) cs (DOT) nott.ac.uk> wrote

Insufficient for what? I wasn't able to infer this from your example.

In the US, house current is typically at a nominal 120V, except for a few
circuits, like stoves that are driven at a nominal 240V. Nominal 120V can
vary all the way down to 110V. At some point below that, "brown out"
begins.

Where the coded meaning of the wires gets to be "interesting" is where you
have an overhead light controlled by a wall switch. If there are two double
pole switches controlling the same light it gets more interesting.

In general, the meaning is:

Black -- live
Red -- live (out of phase with black)
White -- neutral
Green -- ground
bare -- ground.


However, in many homes, the wire from the appliance to the controlling
switch has been
The stove in my house has a clock/timer on it that is driven by 120V is
wired with the standard 3 connector wire consisting of a white wire, a black
wire, and a bare wire.

In this case, the black wire is used to carry (unswitched) power from the
overhead junction box to the switch. The companion white wire is used to
carry (switched) power from the switch to the power side of the light
circuit, which is a black wire.

The above results in a white wire being connected to a black wire. This
looks "wrong" to a DIY neophyte. The official code uses bits of colored
tape to indicate such things as "white coded as black", but that's over my
head.

The electrical wiring in some homes dates back about a century, before the
wires had colors. Things get really interesting then.

All of this is a digression from 1NF. Again, 1NF is insufficient for
what?

On Aug 28, 2:35 pm, "David Cressey" <cresse... (AT) verizon (DOT) net> wrote:
Ah, when men were real men, and wired electrics up with their teeth

Insufficient is probably the wrong word. I'm having trouble finding a
direct 1NF encoding of propositions such as:

Brown -> live.
Red -> live
Blue -> neutral.
Black -> neutral.
Green ^ yellow -> earth.

that doesn't require the addition of a surrogate identifier or the use
of nested relations, neither of which seem to exist in the original
propositions.

Its perhaps a symptom concern with propositions where there are two
components that play the same role - such as a friendship relation:
E.g. if Fred and Barney are friends we have to encode them under
different attribute names in RM, whereas they are actually playing
exactly the same role (of "friend"). Using "Friend1" and "Friend2"
don't seem wholly elegant. If I took Kevin's approach (which I am
still chewing over) for this latter example I'd end up with:

Id Friend
--------------
1 Fred
1 Barney
2 Wilma
2 Betty

again with the use of some sort of surrogate identifier, to assuage
the fact that a friendship (just like a pattern) is identified by more
than one attribute playing equal roles. This addition seems to be
adding complexity where it did not originally exist. (The caveat to
all this being that historically any misgivings with RM I've had have
turned out to be down to a weakness in my grasp of it). J.

JOG wrote:

There is one obvious way to represent that in 1NF:

Create a color domain where a single value represents green and yellow,
another value represents green, and a third represents yellow etc. The
domain could even represent thick green/thin yellow as a separate value
from thick yellow/thin green if one chooses.

Regardless whether one creates only the domain or also uses it as a
candidate key for some sort of lookup table, the resulting relation is
simply:

Colour Type
======= -------
....

Your ID above is one example of such a domain. However, the domain need
not be numeric or have any external numeric representations. It need
only exist with a distinct value for green and yellow.

On Aug 28, 5:05 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:
Well, practically, the surrogate key is the way that I would go. My
question is rather whether this corresponds naturally to the original
propositions, which don't require a new domain in order to be
manipulated in FOL. I seem to remember a while back there was a
discussion involving Marshall and a few others considering situations
where a nested relation was /necessary/ (I need to have a dig for it),
and it didn't sit comfortably then.

"JOG" <jog (AT) cs (DOT) nott.ac.uk> wrote

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.

JOG wrote:

You assume a color domain so imagining a different color domain changes
the design without adding anything new.


I seem to remember a while back there was a
I would argue that nested relations are never necessary; although, they
are certainly handy at times. I would choose the discipline of base
relations having no nested relations. In fact, the princicple of
cautious design suggests--as tools evolve toward nested relations--to
allow them only in derived relations.

On Aug 28, 5:33 pm, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote:
Yup, I see where your coming from there, but I'm still unconvinced (as
of yet) that it isn't a bit of a fudge. The reason I'm still uneasy is
that when I refer to a green and yellow wire I _don't_ name it
collectively ("Grellow" perhaps). Rather I just state that it
hasColour(Yellow) and hasColour(Green), as distinct separate values,
and this allows (without any deconstruction) me to quickly answer the
question does it have "Green" in it. Given:

[P1] hasColour(green) ^ hasColour(yellow) <-> isType(earth)

I can immediately deduce:

isType(earth) -> hasColour(green)

However if I had:

[P2] hasColour( {green, yellow} ) <-> isType(earth)

I am unclear as to the logical process that allows me to make that
jump.

Similarly if I use a surrogate, then I am stating two propositions:
[P3] hasPattern(grellow) <-> isType(earth)
[P4] contains(grellow, green) ^ contains(grellow, yellow)

I then have to make a double hop skip and jump to answer my question,
and also must be armed with the extra knowledge that a pattern
contains individual colours itself. This seems more convoluted
compared to representing the information as P1.

On Aug 28, 5:27 pm, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
And I guess that's why colour-blind people don't become bike
mechanics