On Oct 1, 10:09 am, Rob <rmpsf... (AT) gmail (DOT) com> wrote:
On Oct 2, 10:58 am, Rob <rmpsf... (AT) gmail (DOT) com> wrote:
Rob,

I will enter this thread as I do most: you really don't understand the
relational model.

1.
(I quote Erwin for his versions of things I am saying.)
On Oct 3, 4:27 am, Erwin <e.sm... (AT) myonline (DOT) be> wrote:
Codd 1970: "The meaning of [predicate logic predicate expression]
COMPONENT(X, Y, Z) [given ordered-tuple set mathematics 'relation'
COMPONENT] is that part X is an immediate component (or subassembly)
of part Y, and Z units of part X are needed to assemble one unit of
part Y". Such a parameterized statement is a 'predicate'. Codd meant
that for modern relation (his "relationship") COMPONENT with
attributes (from that paper) SUB.PART, SUPER.PART and QUANTITY,
predicate expression "COMPONENT(X, Y, Z)" denotes "<SUB-PART X, SUPER-
PART Y, QUANTITY Z> IN COMPONENT". Relationally we would say
"predicate logic predicate expression 'COMPONENT(X, Y, Z)' denotes
"<SUB-PART X, SUPER-PART Y, QUANTITY Z> IN COMPONENT". And we would
say "the predicate for COMPONENT is that part SUB-PART is an immediate
component (or subassembly) of part SUPER-PART, and QUANTITY units of
part SUB-PART are needed to assemble one unit of part SUPER-PART'.

When you give values for X, Y and Z or SUB.PART, SUPER.PART and
QUANTITY you get a 'proposition', which is a statement that either
holds or does not hold in a given world situation. ('Has truth value'
'TRUE' or 'FALSE'.)

The (relational) extension of a predicate is the relation whose body
is the set of tuples that make it into a proposition that holds in a
given world situation. So we say (informally) that a relation is the
extension of a predicate. A relation's attributes are the parameters
of its predicate.

2.
Each query relation expression has a predicate as follows. (This
correspondence is typically described as "informal" (and spoken of
vaguely if at all) but that is incorrect.)

On Oct 3, 4:27 am, Erwin <e.sm... (AT) myonline (DOT) be> wrote:
The predicate of a relation expression that is a name of a relation
variable or constant is its predicate. The predicate of a relation
expression that is a JOIN is the AND of the predicates its operands;
of a UNION is the OR; of a MINUS is the AND NOT; of a RESTRICT X=Y or
of an ADD X AS Y is the AND X=Y; and of a PROJECTALLBUT X is the
EXISTS X.

The value of a query relation expression that is a relation name is
its named relation's predicate's extension. Each relation operator is
defined so that if its operand values are the extensions of their
predicates then its result is the extension of its predicate. (As can
be shown. Codd and (ADD) Hall et all defined them so this would be the
case.) So by induction every query relation expression value is the
extension of its predicate.

So the predicate and result value of a query relation expression is
independent of whether any normalization has been done or constraints
have been defined.

3.
Given the named relations' predicates and possible world situations,
of the syntactically typed database values certain ('valid') values
could arise and other ('invalid') ones definitely do not.
The DBMS evaluates a dba-given overall database constraint expression
and allows an assignment if and only if a proposed database value is
valid. (This involves further relation operators for equality and
nesting/aggregation.) So for values that the user got from (correctly)
evaluating the predicates on every tuple for the world situation (all
valid by definition), by this policy none is excluded and all are
included.

On Oct 3, 4:27 am, Erwin <e.sm... (AT) myonline (DOT) be> wrote:
The constraint expressions tell the user something if and only if the
user doesn't know all the possible world situations. But a query
predicate only ever depends on its relation expression and the named
relations' predicates and its result value only further on the named
relations' values. Neither depend on constraint expressions. (Of
course, they are correlated with them.) Constraint expressions
constrain updates. They do not constrain valid database values or
affect query predicates or result values. If the user never made a
mistake (incorrectly including/excluding tuples contrary to their
named relations' predicates and the world situation) they would not
need constraint expressions.

Of course, the constraint expressions are also telling or confirming
to the user important truths about the possible world situations in
terms of the named relations' predicates; and can help the user
understand those predicates and the world; and can help the user to
rephrase queries and the DBMS to optimize queries. A constraint
expression just expresses a truth.

4.
Modern normalization/dependency theory says that there is a foreign
key on attribute set K from a target D into a target F (domestic/
foreign) in a database when in all possible world situations ie in all
valid database states K forms a key in F and all the subtuple values
for K in D are also in F. (We can also speak of it being a foreign key
in a given situation.)

So there is a foreign key constraint on K from D to F if and only if
certain expressions express certain things that hold in every world
situation. This could happen for any two database named relations;
it's just a relationship that happens to always hold for pairs of
values of D and F in that database. And just like every constraint
expression's proposition, the only way in which this has anything to
do with a query predicate or result value is that the possible world
situations and the named relations' predicates collectively determine
them all.

5.
The "relationship" with predicate "there is a foreign key on attribute
set {...} from named relation R and T to named relation S" is a fact
that either holds or does not hold. As a predicate, it is a
proposition. It is a relationship on nothing. Its extension ie
relation is DEE. In practice we don't mean a fact when we say
"relationship". (Historically, TRUE and FALSE aren't even wffs.)

You seem interested in the constraint-oriented "relationship" FK on K,
D and F (in that order in wffs) with predicate "there is a foreign key
on attribute set K from named relation D to named relation F". Note
that D and F denote the names of named relations, not relation values.
Note also that a foreign key relationship holds on a K, D and F when a
certain thing is the case for all valid database values. You seem
interested in constraint propositions on expression "S JOIN T" that
can be inferred from certain constraint propositions on S and T when
EXISTS X, SR, ST: FK(X, R, SR) AND FK(X, T, ST). Ie when the
proposition "there is set X such that a foreign key on attribute set X
from named relations R and T to named relations SR and ST
respectively" holds.

We can have foreign keys on arbitrary expressions. So we can have FKe
with predicate "there is a foreign key on attribute set K from
expression D to expression F". It happens to be the case that that
FKe(k, "R", "SR") AND FKe(k, "T", "ST") implies FKe(k, "R JOIN T",
"SR"). Also that FKe(k, "R JOIN T", "ST") . Also that R{K} SUBSETOF (R
JOIN T){K}, and T{K} SUBSETOF (R JOIN T){K}. And lots of other things.
(But not "relationships".) Though I suspect you are interested in the
first two. (Do you care whether both foreign keys are to be to the
same target? They needn't.) Note that FKe is the relationship; FKe(k,
"R JOIN T", "S") is a fact that holds when Fe(k, "R", "S") AND Fe(k,
"T", "S") holds.

But a JOIN does not "reveal" any of this. Evaluating S JOIN T for a
particular world situation just tells you certain things are true of
that world situation per the predicates of S and T. The predicates and
facts above don't even involve the same world as the JOIN and named
relation predicates. It is the properties of FK and JOIN that have
relevant consequences.

Nothing "reveals" a relationship. It is meaningless to talk about
"the" relationship between some attributes/parameters. A predicate or
an extension/relation each tell you something about a relationship
independent of a world situation. You are not talking about a
particular relationship unless you have both its predicate and a world
situation or its predicate and its extension. Do not confuse
relationships, predicates, extensions/relations and propositions.
Don't even use the word 'relationship'.)

6.
So every JOIN just says that you want the tuples that make two other
predicates true at the same time. Regardless of constraint
expressions. Every relation expression is "meaningful". And you are
probably actually interested in constraint (proposition) inference.

So most of the sentences in your posts don't make sense. You are not
clear and you don't seem to have the relational understanding or
habits of thinking and writing to characterize your problem.

Working through any example you choose might help make this clear to
you. You might be interested in message
http://groups.google.com/group/comp....0d2a603a?hl=en
.. Also give up Codd, especially 40 years ago. (Which you misread,
although you're right about a certain unnecessary restriction.) Read
recent Date and Darwen.

7.
On Oct 3, 11:05 am, Rob <rmpsf... (AT) gmail (DOT) com> wrote:
Your reply to Erwin basically totally misunderstands him. And his post
was entirely on-topic.

On Oct 2, 9:07 am, paul c <toledobythe... (AT) gmail (DOT) com> wrote:
I believe Paul's point was not about gut reactions but that of course
such JOINs are meaningful.

On Oct 1, 2:07 pm, Rob <rmpsf... (AT) gmail (DOT) com> wrote:
I believe you mean this, but I don't believe you know what it means.
Read and reread carefully. Think and write and rethink and rewrite
carefully. Don't disagree. Ask people to clarify what they mean. Every
time you disagreed you were wrong, and every time you agreed you
misunderstood. When world views collide, resolve contradictions, doubt
confirmations.

Thank you for the opportunity to clarify my thoughts and their
expression. (Ten minutes well spent.) (Joke.) (The ten minutes.)

philip

On Oct 1, 10:09 am, Rob <rmpsf... (AT) gmail (DOT) com> wrote:
On Oct 2, 10:58 am, Rob <rmpsf... (AT) gmail (DOT) com> wrote:
Rob,

I will enter this thread as I do most: you really don't understand the
relational model.

1.
(I quote Erwin for his versions of things I am saying.)
On Oct 3, 4:27 am, Erwin <e.sm... (AT) myonline (DOT) be> wrote:
Codd 1970: "The meaning of [predicate logic predicate expression]
COMPONENT(X, Y, Z) [given ordered-tuple set mathematics 'relation'
COMPONENT] is that part X is an immediate component (or subassembly)
of part Y, and Z units of part X are needed to assemble one unit of
part Y". Such a parameterized statement is a 'predicate'. Codd meant
that for modern relation (his "relationship") COMPONENT with
attributes (from that paper) SUB.PART, SUPER.PART and QUANTITY,
predicate expression "COMPONENT(X, Y, Z)" denotes "<SUB-PART X, SUPER-
PART Y, QUANTITY Z> IN COMPONENT". Relationally we would say
"predicate logic predicate expression 'COMPONENT(X, Y, Z)' denotes
"<SUB-PART X, SUPER-PART Y, QUANTITY Z> IN COMPONENT". And we would
say "the predicate for COMPONENT is that part SUB-PART is an immediate
component (or subassembly) of part SUPER-PART, and QUANTITY units of
part SUB-PART are needed to assemble one unit of part SUPER-PART'.

When you give values for X, Y and Z or SUB.PART, SUPER.PART and
QUANTITY you get a 'proposition', which is a statement that either
holds or does not hold in a given world situation. ('Has truth value'
'TRUE' or 'FALSE'.)

The (relational) extension of a predicate is the relation whose body
is the set of tuples that make it into a proposition that holds in a
given world situation. So we say (informally) that a relation is the
extension of a predicate. A relation's attributes are the parameters
of its predicate.

2.
Each query relation expression has a predicate as follows. (This
correspondence is typically described as "informal" (and spoken of
vaguely if at all) but that is incorrect.)

On Oct 3, 4:27 am, Erwin <e.sm... (AT) myonline (DOT) be> wrote:
The predicate of a relation expression that is a name of a relation
variable or constant is its predicate. The predicate of a relation
expression that is a JOIN is the AND of the predicates its operands;
of a UNION is the OR; of a MINUS is the AND NOT; of a RESTRICT X=Y or
of an ADD X AS Y is the AND X=Y; and of a PROJECTALLBUT X is the
EXISTS X.

The value of a query relation expression that is a relation name is
its named relation's predicate's extension. Each relation operator is
defined so that if its operand values are the extensions of their
predicates then its result is the extension of its predicate. (As can
be shown. Codd and (ADD) Hall et all defined them so this would be the
case.) So by induction every query relation expression value is the
extension of its predicate.

So the predicate and result value of a query relation expression is
independent of whether any normalization has been done or constraints
have been defined.

3.
Given the named relations' predicates and possible world situations,
of the syntactically typed database values certain ('valid') values
could arise and other ('invalid') ones definitely do not.
The DBMS evaluates a dba-given overall database constraint expression
and allows an assignment if and only if a proposed database value is
valid. (This involves further relation operators for equality and
nesting/aggregation.) So for values that the user got from (correctly)
evaluating the predicates on every tuple for the world situation (all
valid by definition), by this policy none is excluded and all are
included.

On Oct 3, 4:27 am, Erwin <e.sm... (AT) myonline (DOT) be> wrote:
The constraint expressions tell the user something if and only if the
user doesn't know all the possible world situations. But a query
predicate only ever depends on its relation expression and the named
relations' predicates and its result value only further on the named
relations' values. Neither depend on constraint expressions. (Of
course, they are correlated with them.) Constraint expressions
constrain updates. They do not constrain valid database values or
affect query predicates or result values. If the user never made a
mistake (incorrectly including/excluding tuples contrary to their
named relations' predicates and the world situation) they would not
need constraint expressions.

Of course, the constraint expressions are also telling or confirming
to the user important truths about the possible world situations in
terms of the named relations' predicates; and can help the user
understand those predicates and the world; and can help the user to
rephrase queries and the DBMS to optimize queries. A constraint
expression just expresses a truth.

4.
Modern normalization/dependency theory says that there is a foreign
key on attribute set K from a target D into a target F (domestic/
foreign) in a database when in all possible world situations ie in all
valid database states K forms a key in F and all the subtuple values
for K in D are also in F. (We can also speak of it being a foreign key
in a given situation.)

So there is a foreign key constraint on K from D to F if and only if
certain expressions express certain things that hold in every world
situation. This could happen for any two database named relations;
it's just a relationship that happens to always hold for pairs of
values of D and F in that database. And just like every constraint
expression's proposition, the only way in which this has anything to
do with a query predicate or result value is that the possible world
situations and the named relations' predicates collectively determine
them all.

5.
The "relationship" with predicate "there is a foreign key on attribute
set {...} from named relation R and T to named relation S" is a fact
that either holds or does not hold. As a predicate, it is a
proposition. It is a relationship on nothing. Its extension ie
relation is DEE. In practice we don't mean a fact when we say
"relationship". (Historically, TRUE and FALSE aren't even wffs.)

You seem interested in the constraint-oriented "relationship" FK on K,
D and F (in that order in wffs) with predicate "there is a foreign key
on attribute set K from named relation D to named relation F". Note
that D and F denote the names of named relations, not relation values.
Note also that a foreign key relationship holds on a K, D and F when a
certain thing is the case for all valid database values. You seem
interested in constraint propositions on expression "S JOIN T" that
can be inferred from certain constraint propositions on S and T when
EXISTS X, SR, ST: FK(X, R, SR) AND FK(X, T, ST). Ie when the
proposition "there is set X such that a foreign key on attribute set X
from named relations R and T to named relations SR and ST
respectively" holds.

We can have foreign keys on arbitrary expressions. So we can have FKe
with predicate "there is a foreign key on attribute set K from
expression D to expression F". It happens to be the case that that
FKe(k, "R", "SR") AND FKe(k, "T", "ST") implies FKe(k, "R JOIN T",
"SR"). Also that FKe(k, "R JOIN T", "ST") . Also that R{K} SUBSETOF (R
JOIN T){K}, and T{K} SUBSETOF (R JOIN T){K}. And lots of other things.
(But not "relationships".) Though I suspect you are interested in the
first two. (Do you care whether both foreign keys are to be to the
same target? They needn't.) Note that FKe is the relationship; FKe(k,
"R JOIN T", "S") is a fact that holds when Fe(k, "R", "S") AND Fe(k,
"T", "S") holds.

But a JOIN does not "reveal" any of this. Evaluating S JOIN T for a
particular world situation just tells you certain things are true of
that world situation per the predicates of S and T. The predicates and
facts above don't even involve the same world as the JOIN and named
relation predicates. It is the properties of FK and JOIN that have
relevant consequences.

Nothing "reveals" a relationship. It is meaningless to talk about
"the" relationship between some attributes/parameters. A predicate or
an extension/relation each tell you something about a relationship
independent of a world situation. You are not talking about a
particular relationship unless you have both its predicate and a world
situation or its predicate and its extension. Do not confuse
relationships, predicates, extensions/relations and propositions.
Don't even use the word 'relationship'.)

6.
So every JOIN just says that you want the tuples that make two other
predicates true at the same time. Regardless of constraint
expressions. Every relation expression is "meaningful". And you are
probably actually interested in constraint (proposition) inference.

So most of the sentences in your posts don't make sense. You are not
clear and you don't seem to have the relational understanding or
habits of thinking and writing to characterize your problem.

Working through any example you choose might help make this clear to
you. You might be interested in message
http://groups.google.com/group/comp....0d2a603a?hl=en
.. Also give up Codd, especially 40 years ago. (Which you misread,
although you're right about a certain unnecessary restriction.) Read
recent Date and Darwen.

7.
On Oct 3, 11:05 am, Rob <rmpsf... (AT) gmail (DOT) com> wrote:
Your reply to Erwin basically totally misunderstands him. And his post
was entirely on-topic.

On Oct 2, 9:07 am, paul c <toledobythe... (AT) gmail (DOT) com> wrote:
I believe Paul's point was not about gut reactions but that of course
such JOINs are meaningful.

On Oct 1, 2:07 pm, Rob <rmpsf... (AT) gmail (DOT) com> wrote:
I believe you mean this, but I don't believe you know what it means.
Read and reread carefully. Think and write and rethink and rewrite
carefully. Don't disagree. Ask people to clarify what they mean. Every
time you disagreed you were wrong, and every time you agreed you
misunderstood. When world views collide, resolve contradictions, doubt
confirmations.

Thank you for the opportunity to clarify my thoughts and their
expression. (Ten minutes well spent.) (Joke.) (The ten minutes.)

philip

On Oct 1, 10:09 am, Rob <rmpsf... (AT) gmail (DOT) com> wrote:
On Oct 2, 10:58 am, Rob <rmpsf... (AT) gmail (DOT) com> wrote:
Rob,

I will enter this thread as I do most: you really don't understand the
relational model.

1.
(I quote Erwin for his versions of things I am saying.)
On Oct 3, 4:27 am, Erwin <e.sm... (AT) myonline (DOT) be> wrote:
Codd 1970: "The meaning of [predicate logic predicate expression]
COMPONENT(X, Y, Z) [given ordered-tuple set mathematics 'relation'
COMPONENT] is that part X is an immediate component (or subassembly)
of part Y, and Z units of part X are needed to assemble one unit of
part Y". Such a parameterized statement is a 'predicate'. Codd meant
that for modern relation (his "relationship") "the predicate for
COMPONENT is that part SUB-PART is an immediate component (or
subassembly) of part SUPER-PART, and QUANTITY units of part SUB-PART
are needed to assemble one unit of part SUPER-PART". And that we might
want to write "COMPONENT(X, Y, Z)" for "<SUB-PART X, SUPER-PART Y,
QUANTITY Z> IN COMPONENT".

When you give values for X, Y and Z or SUB.PART, SUPER.PART and
QUANTITY you get a 'proposition', which is a statement that either
holds or does not hold in a given world situation. ('Has truth value'
'TRUE' or 'FALSE'.)

The (relational) extension of a predicate is the relation whose body
is the set of tuples that make it into a proposition that holds in a
given world situation. So we say (informally) that a relation is the
extension of a predicate. A relation's attributes are the parameters
of its predicate.

2.
Each query relation expression has a predicate as follows. (This
correspondence is typically described as "informal" (and spoken of
vaguely if at all) but that is incorrect.)

On Oct 3, 4:27 am, Erwin <e.sm... (AT) myonline (DOT) be> wrote:
The predicate of a relation expression that is a name of a relation
variable or constant is its predicate. The predicate of a relation
expression that is a JOIN is the AND of the predicates its operands;
of a UNION is the OR; of a MINUS is the AND NOT; of a RESTRICT X=Y or
of an ADD X AS Y is the AND X=Y; and of a PROJECTALLBUT X is the
EXISTS X.

The value of a query relation expression that is a relation name is
its named relation's predicate's extension. Each relation operator is
defined so that if its operand values are the extensions of their
predicates then its result is the extension of its predicate. (As can
be shown. Codd and (ADD) Hall et all defined them so this would be the
case.) So by induction every query relation expression value is the
extension of its predicate.

So the predicate and result value of a query relation expression is
independent of whether any normalization has been done or constraints
have been defined.

3.
Given the named relations' predicates and possible world situations,
of the syntactically typed database values certain ('valid') values
could arise and other ('invalid') ones definitely do not.
The DBMS evaluates a dba-given overall database constraint expression
and allows an assignment if and only if a proposed database value is
valid. (This involves further relation operators for equality and
nesting/aggregation.) So for values that the user got from (correctly)
evaluating the predicates on every tuple for the world situation (all
valid by definition), by this policy none is excluded and all are
included.

On Oct 3, 4:27 am, Erwin <e.sm... (AT) myonline (DOT) be> wrote:
The constraint expressions tell the user something if and only if the
user doesn't know all the possible world situations. But a query
predicate only ever depends on its relation expression and the named
relations' predicates and its result value only further on the named
relations' values. Neither depend on constraint expressions. (Of
course, they are correlated with them.) Constraint expressions
constrain updates. They do not constrain valid database values or
affect query predicates or result values. If the user never made a
mistake (incorrectly including/excluding tuples contrary to their
named relations' predicates and the world situation) they would not
need constraint expressions.

Of course, the constraint expressions are also telling or confirming
to the user important truths about the possible world situations in
terms of the named relations' predicates; and can help the user
understand those predicates and the world; and can help the user to
rephrase queries and the DBMS to optimize queries. A constraint
expression just expresses a truth.

4.
Modern normalization/dependency theory says that there is a foreign
key on attribute set K from a target D into a target F (domestic/
foreign) in a database when in all possible world situations ie in all
valid database states K forms a key in F and all the subtuple values
for K in D are also in F. (We can also speak of it being a foreign key
in a given situation.)

So there is a foreign key constraint on K from D to F if and only if
certain expressions express certain things that hold in every world
situation. This could happen for any two database named relations;
it's just a relationship that happens to always hold for pairs of
values of D and F in that database. And just like every constraint
expression's proposition, the only way in which this has anything to
do with a query predicate or result value is that the possible world
situations and the named relations' predicates collectively determine
them all.

5.
The "relationship" with predicate "there is a foreign key on attribute
set {...} from named relation R and T to named relation S" is a fact
that either holds or does not hold. As a predicate, it is a
proposition. It is a relationship on nothing. Its extension ie
relation is DEE. In practice we don't mean a fact when we say
"relationship". (Historically, TRUE and FALSE aren't even wffs.)

You seem interested in the constraint-oriented "relationship" FK on K,
D and F (in that order in wffs) with predicate "there is a foreign key
on attribute set K from named relation D to named relation F". Note
that D and F denote the names of named relations, not relation values.
Note also that a foreign key relationship holds on a K, D and F when a
certain thing is the case for all valid database values. You seem
interested in constraint propositions on expression "S JOIN T" that
can be inferred from certain constraint propositions on S and T when
EXISTS X, SR, ST: FK(X, R, SR) AND FK(X, T, ST). Ie when the
proposition "there is set X such that a foreign key on attribute set X
from named relations R and T to named relations SR and ST
respectively" holds.

We can have foreign keys on arbitrary expressions. So we can have FKe
with predicate "there is a foreign key on attribute set K from
expression D to expression F". It happens to be the case that that
FKe(k, "R", "SR") AND FKe(k, "T", "ST") implies FKe(k, "R JOIN T",
"SR"). Also that FKe(k, "R JOIN T", "ST") . Also that R{K} SUBSETOF (R
JOIN T){K}, and T{K} SUBSETOF (R JOIN T){K}. And lots of other things.
(But not "relationships".) Though I suspect you are interested in the
first two. (Do you care whether both foreign keys are to be to the
same target? They needn't.) Note that FKe is the relationship; FKe(k,
"R JOIN T", "S") is a fact that holds when Fe(k, "R", "S") AND Fe(k,
"T", "S") holds.

But a JOIN does not "reveal" any of this. Evaluating S JOIN T for a
particular world situation just tells you certain things are true of
that world situation per the predicates of S and T. The predicates and
facts above don't even involve the same world as the JOIN and named
relation predicates. It is the properties of FK and JOIN that have
relevant consequences.

Nothing "reveals" a relationship. It is meaningless to talk about
"the" relationship between some attributes/parameters. A predicate or
an extension/relation each tell you something about a relationship
independent of a world situation. You are not talking about a
particular relationship unless you have both its predicate and a world
situation or its predicate and its extension. Do not confuse
relationships, predicates, extensions/relations and propositions.
Don't even use the word 'relationship'.)

6.
So every JOIN just says that you want the tuples that make two other
predicates true at the same time. Regardless of constraint
expressions. Every relation expression is "meaningful". And you are
probably actually interested in constraint (proposition) inference.

So most of the sentences in your posts don't make sense. You are not
clear and you don't seem to have the relational understanding or
habits of thinking and writing to characterize your problem.

Working through any example you choose might help make this clear to
you. You might be interested in message
http://groups.google.com/group/comp....0d2a603a?hl=en
.. Also give up Codd, especially 40 years ago. (Which you misread,
although you're right about a certain unnecessary restriction.) Read
recent Date and Darwen.

7.
On Oct 3, 11:05 am, Rob <rmpsf... (AT) gmail (DOT) com> wrote:
Your reply to Erwin basically totally misunderstands him. And his post
was entirely on-topic.

On Oct 2, 9:07 am, paul c <toledobythe... (AT) gmail (DOT) com> wrote:
I believe Paul's point was not about gut reactions but that of course
such JOINs are meaningful.

On Oct 1, 2:07 pm, Rob <rmpsf... (AT) gmail (DOT) com> wrote:
I believe you mean this, but I don't believe you know what it means.
Read and reread carefully. Think and write and rethink and rewrite
carefully. Don't disagree. Ask people to clarify what they mean. Every
time you disagreed you were wrong, and every time you agreed you
misunderstood. When world views collide, resolve contradictions, doubt
confirmations.

Thank you for the opportunity to clarify my thoughts and their
expression. (Ten minutes well spent.) (Joke.) (The ten minutes.)

philip

On 6 stu 2011, 01:07, com... (AT) hotmail (DOT) com wrote:

In contrast to your conclusion, Rob's posts are good; on the other
hand I'm not sure that you are clear enough in your statements.

I think that we can generalize Rob's remarks. Therefore I would like
to ask you the following question: What does mean the pair (foreign-
key, primary-key) in terms of database design? What do you design with
this pair?
For the above-mentioned pair, it may happen that data from
"referencing table" or from "referenced table" is incorrect. The
attributes in each relation can be changed over time. Many things can
happen in real life.

You also commonly used undefined terms that are of fundamental
importance for db theory as well as for some others important science.

Could you give a definition (or description) of the following terms:
the world, the situation and the possible. For example, in several
places you use the term: "possible world situation"?
Note that the terms "world", "situation" and "possible" does not exist
in the RM.

It seems to me that you are not clear about predicates and that you
don’t seem to have understanding about a nature of the predicates.
It would be good if you can give us a definition of a predicate. Also
give us a definition of the extensionality (of predicate). Do you mean
here on the extensionality of atomic predicates? Do you use some
"interpretation" here or do you use a definition of truth? Do you use
second-order logic? (For example, the Leibniz's Law)

Note that the predicate is a linguistic construct. So, once again,
please give us a definition of a predicate.

Also could you give us a definition of the attributes in RM. (and
especially of the attributes in the structures determined with the
pair (foreign-key, primary-key)).

When you write about the meaning you are actually writing about the
truth value of the
corresponding proposition. Note that the truth is related just to
sentences. This, however, does not apply to the meaning also.
We can also notice that interrogative (query) sentence has no truth-
value.

Since you're trying ”to translate” a formal language for Predicate
Logic into English language, I have the following two questions:

1. What are the differences between formal languages and natural
languages?
2. Can semantics for formal languages be useful for natural languages?

Rob was asked questions related to time-varying nature of relations.
He also asked some questions related to semantics. In your response to
Rob you are advising him to "Read recent Date and Darwen". You also
give him examples of Codd’s work that are related to the semantics and
meaning.
Codd's work related to the database is very important. But his work on
semantics and time-varying relations is of no importance.
Date and Darwen in "Third Manifesto" have done great and good work.
But their work on semantics and time-varying relations is of no
importance.
Therefore, your recommendation to Rob that he should read Date, Darwen
and Codd has no sense.
--

(To Erwin) On October 3, in this thread, Erwin wrote: “Take any set of
6NF relvars. For example, CUST {CUST_ID}, CUST_DOB {CUST_ID, DOB},
…”

I would like to say that the identifier (ID) is poorly constructed. In
my opinion, in today’s existing software, these identifiers are
wrongly constructed. In fact for their construction there are no
rules. I am not talking about their industry standards but about db
design related to these identifiers. I explained on my website how to
construct this identifier.
See http://www.dbdesign11.com

Vladimir Odrljin

Vladimir,

1.
I just mean certain usual notions for logic and for states. A database
changes state as it keeps describing some changing "world". A
particular database state value describes a particular "situation".
(So predicate logic uses a single situation; a dbms uses a sequence of
them.) By "possible" situation I just mean a situation that could
arise as the world changes.

I just mean the usual unordered-attributes notion. A tuple is a set of
attribute name-and-something pairs with a given name only appearing
once. A relation has a heading and a body. A heading is a tuple of
name-and-type pairs. A body is a set of tuples of name-and-value
pairs. The heading and body tuples all have the same names. For each
name every body value paired with it is of the heading type paired
with it. I usually shorten "attribute name" to "attribute".

2.
My last message already answers, contradicts, or obviates your other
comments. Rather than me cutting and pasting the answers could you try
finding them? Though I'll do a few:

"Predicate" gets used in lots of ways. I am using it as a mapping from
a tuple to a proposition, with a proposition a mapping from a
situation to a truth value reflecting whether the situation is a
certain way. In other words a certain usual predicate logic notion. (A
wff predicate symbol's interpretation/extension set (ordered-relation)
is determined by a predicate/function/mapping which maps a tuple to a
statement/proposition/function/mapping which maps a situation to a
truth value.)

No, I am clearly not:
The source of my translation is a relation expression. The target of
my translation is a predicate. I don't care how you write the
predicate.

The concepts do:
You cannot set the relation variables without observing the world and
knowing what their predicates (parametrically) say about the the
world. You cannot understand a query or its value without knowing the
named relation predicates and what they (parametrically) say about the
world. (Same for predicate symbols and wffs in predicate logic.) And
the named relation predicates plus all possible situations determine
possible states and so constraints.

No, I am not:
"Meaning" gets used in lots of ways. I am giving a
"predicate" ("parameterized proposition") as "meaning" of a "relation
expression" in the relational model. (In the everyday sense a sentence/
proposition is itself a "meaning"; it merely "has" a truth value. In
predicate logic a predicate symbol has a "meaning" (in a different
sense) that is an interpretation/extension set. And a sentential wff
has a "meaning" (in a different sense) that is a truth value.) I would
agree that the "meaning" (in yet another sense) of a 0-tuple query
result is a truth value. And I would agree that the "meaning" (in yet
another sense) of a query value is the (necessarily true) proposition
that is the conjunction of its present-tuple propositions and its
negated absent-tuple propositions.

Your comment is specious. A query is a relation expression is a
predicate, is a relation value, is (for 0-tuples) a truth value, is a
(true) proposition (via substituting body tuples into its predicate),
is a request for a relation value, is a request for a truth value, is
a request for a (true) proposition. How we use terms colloquial terms
is irrelevant.

3.
If you wrote out named relation predicates then you would see that SQL
"subtables" and ER "subtyping" involve propositions that are facts/
truths in all states. Like that is_a_s_thing(k1, ...) IMPLIES
is_a_r_thing(k1, ...); ie that (s PROJECT {k1, ...}) SUBSETOF (r
PROJECT {k1, ...}); ie that there is an inclusion dependency on
{k1, ...} from "s" to "r". And that if also {k1, ...} is a key in r
then also there is a foreign key on {k1, ...} from "s" to "r".

Rob confused (changing) parent-child edges in the graph of a variable/
query relation value with those in the graph(s) of the (simultaneously
meta, constant, redundant and operator-irrelevant) foreign key
relation and/or subtable/subtype relation(s). And whether such facts/
truths hold has no bearing on what a query "means". You need to
understand query predicates to understand the details and the
explanation of this.

4.
I expect to not necessarily be clear in a terse post. But you don't
seem to have read closely enough to understand me. You misread me or
you see a homonym and assume a meaning. Instead of trying to
understand the (precise) system I tried to described. I hope things
are clearer now.

philip

Typos.

On Jan 9, 10:29*pm, com... (AT) hotmail (DOT) com wrote:
A query is a relation expression, is a
predicate, is a relation value, is (for 0-attribute values) a truth
value, is a
(true) proposition (via substituting present and absent tuples into
its predicate),
is a request for a relation value, is a request for a truth value, is
a request for a (true) proposition. But how we use colloquial terms
is irrelevant.
philip

On 10 sij, 07:29, com... (AT) hotmail (DOT) com wrote:

I was busy with other things so that is the reason for this delayed
replay. I don’t think your responses to my questions were precise
enough.

1.
My first question was: What does mean the pair (foreign-key, primary-
key) in terms of database design? What do you design with this pair?
The database design is a very important step in constructing a
database. Therefore, the database theory should include the part that
relates to the database design. So in my opinion, a description of
foreign keys in the terms of relations and predicates is not a theory
about constructing, building and designing. Note that foreign key is
not exclusively term from RM. As far as I know the foreign key is the
construction which comes from COBOL’s applications.

2.
I would like to say that this whole story about "predicates-relations-
statements”, has already been done by Gottlob Frege, 120 years ago.
Frege’s theory is very powerful and complex, so I will explain it here
in the simplest form. According to G. Frege, predicates are applied to
objects and he defines the predicates as follows:

A predicate is any incomplete phrase with specified gaps such that
when the gaps are filled with names of things the phrase becomes a
proposition.

Note that here we have “things” i.e. individuals or entities. That is
why I cannot accept your opinion about entities.

3.
The example that you posted:

Codd 1970: "The meaning of [predicate logic predicate expression]
COMPONENT(X, Y, Z) [given ordered-tuple set mathematics 'relation'
COMPONENT] is that part X is an immediate component (or subassembly)
of part Y, and Z units of part X are needed to assemble one unit of
part Y".

is confusing, because it is not clear what are the attributes here and
what is the corresponding entity. (The example seems like it is about
Mereolgy.)
If this is not seeking the meaning of an entity, then it should be
given a definition of meaning. The meaning of a name can be very
complex. (this is related to the names of the attributes)

4.
The following terms are undefined: the world, the situation of the
world, the state of the world, the state of a database, and the states
of affairs. It is widely known that the term “the world” is not
defined in philosophy.
In my papers I defined the state of an entity and relationship as
subject's knowledge.
--

In your sentence: "A body is a set of tuples of name-and-value pairs"
instead of
name-and-value pairs you can put name-and-name pairs, because the
value is in fact name (for this value). So when we assign a value to a
variable, then we can say (semantically) that we "bind" the name of
the value with the name of the variable.

I think that the following paragraph should be revised:
Vladimir Odrljin

On Monday, March 5, 2012 6:51:50 PM UTC-8, vldm10 wrote:
Vladimir,

To understand the answer to your question you have to learn a bunch of
things and unlearn a bunch of things.

All primary keys are (candidate) keys. Picking one as primary has no
more formal meaning than picking the name of an attribute or variable.

The dba gives a predicate for each relation variable. The user puts
into a relation variable the tuples that turn the predicate into a
true statement.

The (natural) join of two relations is always on common attributes.
The result body holds the tuples that make <<the predicate of one> AND
<the predicate of the other>> into a true statement.

Predicates:
COMPONENT(X, Y, Z)
a X is an immediate component (or subassembly) of aY,
and Z units of a X are needed to assemble one unit of a Y
WANT(Y) I want a Y

Variables:
COMPONENT <X part, Y part, Z part> {<leg, pony, 4>, <torso, pony,
1>}
WANT <Y part> {<pony>, <ball>}

What the database says:
a leg is an immediate component (or subassembly) of a pony, and 4
units of a leg are needed to assemble one unit of a pony
AND a torso is an immediate component (or subassembly) of a pony, and
1 unit of a torso is needed to assemble one unit of a pony
AND it is not the case that <a leg is an immediate component (or
subassembly) of a pony, and 7 units of a head is needed to assemble
one unit of a pony>
AND it is not the case that <a wheel is an immediate component (or
subassembly) of a pony, and 18 units of a wheel are needed to assemble
one unit of a pony>
AND it is not the case that ... per any other absent COMPONENT tuple
either
AND I want a pony AND I want a ball AND I don't want a wheel AND I
don't want a leg
AND it is not the case that ... per any other absent WANT tuple either

Query: WANT JOIN COMPONENT
By the definition of JOIN this returns X, Y and Z such that I want a Y
AND a X is an immediate component (or subassembly) of a Y, and Z units
of a X are needed to assemble one unit of a Y.
Result: <X part, Y part, Z part> {<leg, pony, 4>, <torso, pony, 1>
What the query says:
I want a pony AND a leg is an immediate component (or subassembly) of
a pony, and 4 units of a leg are needed to assemble one unit of a pony
AND
I want a pony AND a torso is an immediate component (or subassembly)
of a pony, and 1 unit of a torso is needed to assemble one unit of a
pony
AND
it is not the case that <I want a pony AND a leg is an immediate
component (or subassembly) of a pony, and 3 units of a leg are needed
to assemble one unit of a pony>
AND it is not the case that ... per any other absent query tuple
either

If the relation variable predicates happen to be such that you could
(and did or didn't) declare a foreign key from an attribute set in one
relation variable to another then the tuples in the result will be
limited in a certain unchanging way describable independently of what
tuples are in them at any particular time; the limitation that we call
a foreign key constraint. Nevertheless, the result will still be the
tuples that make <<the predicate of one> AND <the predicate of the
other>> into a true statement. Just declare the keys and foreign keys
and other constraints to avoid update errors.

I have tried to inform you. Try:
http://bookboon.com/en/textbooks/it-...atabase-theory
http://www.fecundity.com/logic/download.html

Several of us have told you that ER is at best a heuristic to
determine predicates.

One can characterize a rational number (a kind of value) as having two
parts, a numerator and a denominator, each an integer (a kind of
value) (not numeral). I characterized a relation, not a relation
variable. A tuple (a kind value) in the body part of a relation (a
kind of value) has name and value pairs (a kind of value) as attribute
parts.

If you want to become informed, I suggest you read the links and try
to understand what I wrote instead of balking.

good luck,
philip

On Thursday, 15 March 2012 14:40:15 UTC-7, com... (AT) hotmail (DOT) com wrote:
Of course this should be:
COMPONENT <X part, Y part, Z int> {<leg, pony, 4>, <torso, pony, 1>}
WANT <Y part> {<pony> , <ball>}

If you want to associate a relation variable with some entities, give an appropriate predicate. Clearly the predicates I gave involve wanted parts, composed/assembled parts, component parts, component/assembly counts, ponies,legs, torsos, balls, units, the number 1, etc.

Regarding foreign keys:

Suppose {K} is a key of WANT.

Suppose that in detail COMPONENT is the breakdown of certain toys, wanted or not, and can sometimes contain Y values not in WANT. Then there is not a foreign key from COMPONENT{Y} to WANT{Y}. (Because COMPONENT{Y} subtuples are not always WANT{Y} subtuples.)

But suppose that in detail COMPONENT is the breakdown of wanted toys. Then there is a foreign key from COMPONENT {Y} to WANT {Y}. (Because COMPONENT{Y} subtuples are always WANT{Y} subtuples.)

Either way, WANT JOIN COMPONENT always means the same thing in terms of WANT and COMPONENT: those X-Y-Z tuples for which WANT(Y) AND COMPONENT(X, Y, Z).

All that there being or not being a foreign key from COMPONENT to WANT on {K} tells you is whether a certain thing is true that FOLLOWS FROM THE PREDICATES anyway. Namely the "foreign key" situation, namely whether the first variable projected on the subtuples is always a subset of the second variable projected on the subtuples and the subtuples form a key of the second variable. You don't need to know this to use the database, you just determinewhether the predicates are true or false of every possible tuple for each situation as it arises. (But if you understand in detail what world situations can arise then you can determine this.)

So a join always has a meaning: a statement from the tuples that do and don't make its arguments' predicates simultaneously true. And this meaning is otherwise independent of any constraints. (Foreign key or otherwise.) (The only correlation is that the constraints are always true.)

(For implementation optimization, it is helpful to know the constraints.)

again, good luck,
philip

On 15 ožu, 23:40, com... (AT) hotmail (DOT) com wrote:

We do not understand one another regarding some important issues. I'll
try to explain it using the following simplified scheme:


The Real World (Data) Model


Regarding above schema we can ask the following questions:
1. What stands in this space that is between the real world and Model?
2. How to make a mathematical theory that connects all these pieces?

I think in the future, (new) mathematics will deal extensively with
these two issues.
I also think that you pay attention only to the model. However db also
works with real word objects.
In my model, I connected the real world, with a data model, using the
concepts (and still with many other things).




If Y is name of an attribute, then X cannot be its part, because the
attributes are atomic.


I appreciate the work of Date & Darwen. Relational model that they
built and implemented is well done.
I also think that your technique in logic is very good. However, there
are some parts of the theory of databases, which in my opinion are not
resolved in the relational model.



Characterization of an object is very different from giving the names
of the object. For example, characterization of an object can give a
wrong meaning for that object.


A tuple (a kind value) in the body part of a relation (a
Today I released a new paper, which I think resolves some problems in
the theory of databases. If you want to become informed, I suggest you
read the paper at http://www.dbdesign11.com called Semantic databases
and semantic machines.


Vladimir Odrljin