Multiple-Attribute Keys and 1NF

#41

On Aug 30, 12:50 am, mAsterdam <mAster... (AT) vrijdag (DOT) org> wrote:

Quote:

JOG schreef:

mAsterdam wrote:
JOG wrote:
I am still fighting with the theoretical underpinning for 1NF.
My answer won't help you in that quest, sorry.
I like the example, but I don't think it illustrates a NF problem.
Yet I like it because I think it illustrates a much more basic,
non-formal issue.

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.
This is dictionary of a little language.
left of the '->' is the code, to the right of it is the explanation.
The code is expressed with colors as symbols,
just as in our phonographic latin the words are expressed
with soundsymbols. A color-alphabet. The codes are not colors as such.
Your information need is the code explanation, not
anything about the colors.

Confuscious, he say mAsterdam, he wise

I wholly agree that any encoding is biased to a certain expected
information need. However I have always worked on the principle that
in a theoretical model I want to minimize this query bias as much as
feasibly possible (and therein lies the strength of the RM over other
approaches). Consequently In this instance I see what one can gain by
encoding "Green" and "Yellow" separately in terms of flexibility, but
not what one would lose. Either way, I am willing for the example to
be interpreted in terms of such an information need.

The example has an existence of its own, though.

Your preferred interpretation requires a leap of
faith many mediocre math-inclined formalists show
willing to take over and over again to no avail.

Whenever modeling, one should keep focus as to what is being
modeled and what the purpose of the model is.

Ok, well the wire example was just that - a contrived example, and as
it turns out not a particularly good one given that I can hardly argue
against the fact that wire patterns are codes, and I can't really
imagine why anyone would be interested in splitting them up into
constituent colours (perhaps for an investigation of colour-blindness?
Tenous).

Another example that occured to me in the past were the propositions:
Some cows have black fur and white fur.
Some cows have brown fur.
Some cows have red fur.

Its exactly the same example in structure, but it is a lot harder (for
me) to be comfortable with a 'code' view of the repeating roles. (and
yup, again in RM I would use two relations and a surrogate for this,
as opposed to an rva). Is everyone else still comfortable with a code
interpretation? Dank je wel, J.

Quote:

The purpose here is: don't get electrocuted because of
not knowing which wire is live. I am not kidding :-)

When I first did any electrics I both managed to put a floorboard nail
through the main circuit, and within an hour take a circular saw
through the lighting circuit. I've been infinitely more careful since.

Quote:

The issue with encoding these propositions is that the candidate key
for each proposition may consist of one _or_ two colours.
This is similar to asking how many characters can make up a
word or how many words a sentence.

I was intending to describe of an item that is identified by two
attributes which play the same role. Just knowing this might be
desirable /I think/ validates the example.

Mostly, yes, agreed. However colors simply do not have a role, here.
Symbols are /not/ roles (ok, ok, except for the trivial/desubstanced
role of /being/ a symbol).

What I am really struggling with is whether requirement of a surrogate
key to achieve the information need (as a result of enforcing 1NF) has
a theoretical basis. Is 1NF just there to provide a structure that
fits a relation, or does it have a deeper purpose that I haven't yet
grokked.

The need is a intersubjective topic /ergo/ not formal.

Now I have a couple of options, none of which seem satisfactory.

[snip]

This is because you desire from form(alisms) that which it by its
nature cannot provide: substance.

#42

On Aug 30, 1:41 am, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote:

Quote:

"JOG" <j... (AT) cs (DOT) nott.ac.uk> wrote in message

news:1188422471.161668.86550 (AT) r29g2000hsg (DOT) googlegroups.com...

On Aug 29, 7:03 pm, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote:
"JOG" <j... (AT) cs (DOT) nott.ac.uk> wrote in message

news:1188393382.112445.286350 (AT) 19g2000hsx (DOT) googlegroups.com...

On Aug 29, 12:49 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:
JOG wrote:
On Aug 29, 6:10 am, "David Cressey" <cresse... (AT) verizon (DOT) net> wrote:

"JOG" <j... (AT) cs (DOT) nott.ac.uk> wrote in message

news:1188327226.729673.127810 (AT) r34g2000hsd (DOT) googlegroups.com...

Okay, sure. But then to be able to query for green and yellow
individually one must employ a further relation encoding two more
propositions that state "'Green and yellow' contains 'Green'" and
that
"'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 initially
said a new one was being added).

It took me a while to realize that what you meant from your original
description was that
"a green and yellow wire means earth". I had thought you meant "a
green
wire means earth" and "a yellow wire means earth". Pardon me for
being
dense.

Clearly what we have here is not a domain of colors, but a domain
of
color
codes, where a color code contains one or more colors, and maybe a
"thick
or thin" qualifier on each color.

It's not clear to me why you need to able to query on simple colors,
unless
you need to decompose the color coding scheme into its constituent
parts for
some reason.

There are lot of code domains where each code is made up of a set of
more
primitive elements.
Perhaps a very relevant one might be "character code". If I have
the
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 byte),
I
can
think of the character code for 'A' as being B64+B1. Now I could
query
on
all the character codes without necessarily having an operator that
would
yield "all the codes that include B1".

I think that the colors, as constituents of color codes, play the
same
role
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
having
a colour code, which itself has constituent parts. But its just one
interpretation right. I am still seeing a difference between the
propositions:
* 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 color
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
propositions
(treating or exclusively, of course):

"The casing of a live wire features the colour brown or the colour red."

"The casing of a neutral wire features the colour blue or the colour
black."

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.

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 or
not. To me it doesn't make sense to have multiple attributes with the same
name--the attribute names correspond to free variables in a predicate: how
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? If so then [P1] ^ [P2] gives us (via
composition):
Name(x, Jim) -> speaks_language(x, English) ^ speaks_language(x,
English)

and we are left with a sentence that has two distinct roles, one of
which appears twice. All of this sort of thinking has been driven by a
distaste us having to add a magic 'header' component to a relation
(probably as a consequence of reading pascal's work), and the desire
to bring roles back into the equation.

Quote:

But you can
certainly assign a set of values to a variable that expects a set of values,
since a set is a value! And you can certainly have a predicate with free
variables that range over relations and free variables that range over
individuals--it's just that the predicate is no longer first order.

#43

On Aug 30, 1:42 am, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:

Quote:

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.

#44

JOG wrote:

Quote:

On Aug 30, 1:42 am, Bob Badour <bbad... (AT) pei (DOT) 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?

#45

JOG wrote:

Quote:

On Aug 30, 1:41 am, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote:

"JOG" <j... (AT) cs (DOT) nott.ac.uk> wrote in message

news:1188422471.161668.86550 (AT) r29g2000hsg (DOT) googlegroups.com...

On Aug 29, 7:03 pm, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote:

"JOG" <j... (AT) cs (DOT) nott.ac.uk> wrote in message

news:1188393382.112445.286350 (AT) 19g2000hsx (DOT) googlegroups.com...

On Aug 29, 12:49 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:

JOG wrote:

On Aug 29, 6:10 am, "David Cressey" <cresse... (AT) verizon (DOT) net> wrote:

"JOG" <j... (AT) cs (DOT) nott.ac.uk> wrote in message

news:1188327226.729673.127810 (AT) r34g2000hsd (DOT) googlegroups.com...

Okay, sure. But then to be able to query for green and yellow
individually one must employ a further relation encoding two more
propositions that state "'Green and yellow' contains 'Green'" and
that
"'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 initially
said a new one was being added).

It took me a while to realize that what you meant from your original
description was that
"a green and yellow wire means earth". I had thought you meant "a
green
wire means earth" and "a yellow wire means earth". Pardon me for
being
dense.

Clearly what we have here is not a domain of colors, but a domain
of
color
codes, where a color code contains one or more colors, and maybe a
"thick
or thin" qualifier on each color.

It's not clear to me why you need to able to query on simple colors,
unless
you need to decompose the color coding scheme into its constituent
parts for
some reason.

There are lot of code domains where each code is made up of a set of
more
primitive elements.
Perhaps a very relevant one might be "character code". If I have
the
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 byte),
I
can
think of the character code for 'A' as being B64+B1. Now I could
query
on
all the character codes without necessarily having an operator that
would
yield "all the codes that include B1".

I think that the colors, as constituents of color codes, play the
same
role
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
having
a colour code, which itself has constituent parts. But its just one
interpretation right. I am still seeing a difference between the
propositions:
* 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 color
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
propositions
(treating or exclusively, of course):

"The casing of a live wire features the colour brown or the colour red."

"The casing of a neutral wire features the colour blue or the colour
black."

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.

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 or
not. To me it doesn't make sense to have multiple attributes with the same
name--the attribute names correspond to free variables in a predicate: how
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? If so then [P1] ^ [P2] gives us (via
composition):
Name(x, Jim) -> speaks_language(x, English) ^ speaks_language(x,
English)

and we are left with a sentence that has two distinct roles, one of
which appears twice. All of this sort of thinking has been driven by a
distaste us having to add a magic 'header' component to a relation
(probably as a consequence of reading pascal's work), and the desire
to bring roles back into the equation.

But you can
certainly assign a set of values to a variable that expects a set of values,
since a set is a value! And you can certainly have a predicate with free
variables that range over relations and free variables that range over
individuals--it's just that the predicate is no longer first order.

Where did Germany go?

#46

On Aug 30, 1:44 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:

Quote:

JOG wrote:
On Aug 30, 1:42 am, Bob Badour <bbad... (AT) pei (DOT) 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?

#47

On Aug 30, 1:46 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:

Quote:

JOG wrote:
On Aug 30, 1:41 am, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote:

"JOG" <j... (AT) cs (DOT) nott.ac.uk> wrote in message

news:1188422471.161668.86550 (AT) r29g2000hsg (DOT) googlegroups.com...

On Aug 29, 7:03 pm, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote:

"JOG" <j... (AT) cs (DOT) nott.ac.uk> wrote in message

news:1188393382.112445.286350 (AT) 19g2000hsx (DOT) googlegroups.com...

On Aug 29, 12:49 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:

JOG wrote:

On Aug 29, 6:10 am, "David Cressey" <cresse... (AT) verizon (DOT) net> wrote:

"JOG" <j... (AT) cs (DOT) nott.ac.uk> wrote in message

news:1188327226.729673.127810 (AT) r34g2000hsd (DOT) googlegroups.com...

Okay, sure. But then to be able to query for green and yellow
individually one must employ a further relation encoding two more
propositions that state "'Green and yellow' contains 'Green'" and
that
"'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 initially
said a new one was being added).

It took me a while to realize that what you meant from your original
description was that
"a green and yellow wire means earth". I had thought you meant "a
green
wire means earth" and "a yellow wire means earth". Pardon me for
being
dense.

Clearly what we have here is not a domain of colors, but a domain
of
color
codes, where a color code contains one or more colors, and maybe a
"thick
or thin" qualifier on each color.

It's not clear to me why you need to able to query on simple colors,
unless
you need to decompose the color coding scheme into its constituent
parts for
some reason.

There are lot of code domains where each code is made up of a set of
more
primitive elements.
Perhaps a very relevant one might be "character code". If I have
the
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 byte),
I
can
think of the character code for 'A' as being B64+B1. Now I could
query
on
all the character codes without necessarily having an operator that
would
yield "all the codes that include B1".

I think that the colors, as constituents of color codes, play the
same
role
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
having
a colour code, which itself has constituent parts. But its just one
interpretation right. I am still seeing a difference between the
propositions:
* 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 color
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
propositions
(treating or exclusively, of course):

"The casing of a live wire features the colour brown or the colour red."

"The casing of a neutral wire features the colour blue or the colour
black."

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.

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 or
not. To me it doesn't make sense to have multiple attributes with the same
name--the attribute names correspond to free variables in a predicate: how
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? If so then [P1] ^ [P2] gives us (via
composition):
Name(x, Jim) -> speaks_language(x, English) ^ speaks_language(x,
English)

and we are left with a sentence that has two distinct roles, one of
which appears twice. All of this sort of thinking has been driven by a
distaste us having to add a magic 'header' component to a relation
(probably as a consequence of reading pascal's work), and the desire
to bring roles back into the equation.

But you can
certainly assign a set of values to a variable that expects a set of values,
since a set is a value! And you can certainly have a predicate with free
variables that range over relations and free variables that range over
individuals--it's just that the predicate is no longer first order.

Where did Germany go?

Good grief, the perils of cut and paste. It should of course have
been:

-----------------
[P1] Name(x, Jim) -> speaks_language(x, English)
[P2] Name(x, Jim) -> speaks_language(x, German)
[P3] Name(x, Brian) -> speaks_language(x, English)

Are we agreed up to there? If so then [P1] ^ [P2] gives us (via
composition):
Name(x, Jim) -> speaks_language(x, English) ^ speaks_language(x,
German)
-----------------

Was fur ein dummkopf....

#48

JOG wrote:

Quote:

On Aug 30, 1:44 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:

JOG wrote:

On Aug 30, 1:42 am, Bob Badour <bbad... (AT) pei (DOT) 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. 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.

#49

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

Quote:

Ok, well the wire example was just that - a contrived example, and as
it turns out not a particularly good one given that I can hardly argue
against the fact that wire patterns are codes, and I can't really
imagine why anyone would be interested in splitting them up into
constituent colours (perhaps for an investigation of colour-blindness?
Tenous).

Another example that occured to me in the past were the propositions:
Some cows have black fur and white fur.
Some cows have brown fur.
Some cows have red fur.

Its exactly the same example in structure, but it is a lot harder (for
me) to be comfortable with a 'code' view of the repeating roles. (and
yup, again in RM I would use two relations and a surrogate for this,
as opposed to an rva). Is everyone else still comfortable with a code
interpretation? Dank je wel, J.

The big problem with contrived examples is that there is generally no answer
to the question, "what do you intend to do with the data". One could
contrive the answer, along with the rest of the contrived example, but most
people generally don't.

The example of the cows sounds contrived to me. What do you intend to do
with the data?

It seems to me that modeling as such cannot be meaningfully done in an
environment where you can't distinguish between the essential features of
the thing being modeled and the ignorable features of the same thing. That
applies to data modeling as well.

In the absence of some way of distinguishing the essential features of the
data, the data model has to either incorporate all the features of the
data, or it has to incur the risk that some essential features are omitted.
If some essential features of the data are omitted from the data model, the
data model is defective.

If no features of the data are omitted from the data model, the data model
is just as hard to understand and work with as the data itself. Hence the
data model will not add any value.

May I suggest that you come up with an example that is not contrived, so
that questions about what features are essential to the data model will have
an answer? (My apologies in advance if the cows example was not contrived.)

#50

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

Quote:

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? If so then [P1] ^ [P2] gives us (via
composition):
Name(x, Jim) -> speaks_language(x, English) ^ speaks_language(x,
English)

and we are left with a sentence that has two distinct roles, one of
which appears twice. All of this sort of thinking has been driven by a
distaste us having to add a magic 'header' component to a relation
(probably as a consequence of reading pascal's work), and the desire
to bring roles back into the equation.

Is the subject of speakers and languages contrived? (I'm at risk of
becoming obsessive on the subject of "contrived"). If it is, I'd like to
suggest that we return to a classic contrived example for this newsgroup:
the subject of pizzas and toppings.

You can, if you like extend the topic to pizzas toppings and cheeses. You
can then go to google groups and look up the history of the discussion of
the subject of pizzas, toppings, and cheeses in this newsgroup (c.d.t.).

You will find an extensive discussion of the questions that arise when an
attribute value can be a set, rather than just a single value. Some of
that discussion makes sense to me. Some of it is just pure blather. There
are plenty of inputs from the MV sect of the NFNF religion.

My apologies, JOG, if you were a participant in those discussions. My
memory fails me. If not, the principal value of recapitulating that
example, rather than covering speakers and languages, or cows and colors,
or wires and color codes, is that a lot of the responses are already neatly
collected in google groups. Those who do not learn from on line discussions
are condemned to repeat them. (Apologies to Santayana enthusiasts).

Quote:

But you can
certainly assign a set of values to a variable that expects a set of
values,
since a set is a value! And you can certainly have a predicate with
free
variables that range over relations and free variables that range over
individuals--it's just that the predicate is no longer first order.

See above.

Quote: