Re: Informal Survey #1 -- joins on foreign keys

Vladimir,

1.
> On Monday, January 2, 2012 5:20:48 AM UTC-8, vldm10 wrote:
> Could you give a definition (or description) of the following terms:
> the world, the situation and the possible.

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.

> Also could you give us a definition of the attributes in RM.

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:

> It would be good if you can give us a definition of a predicate.

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

> Note that the predicate is a linguistic construct.

> > When you give values for [...] 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'.)

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

> Also
> give us a definition of the extensionality (of predicate).

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

> Since you're trying ”to translate” a formal language for Predicate
> Logic into English language

No, I am clearly not:
> > Each query relation expression has a predicate as follows.

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.

> Note that the terms "world", "situation" and "possible" does not exist
> in the RM.

The concepts do:
> > (This
> > correspondence is typically described as "informal" (and spoken of
> > vaguely if at all) but that is incorrect.)

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.

> When you write about the meaning you are actually writing about the
> truth value of the
> corresponding proposition.

No, I am not:
> > Each query relation expression has a predicate as follows.

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

> We can also notice that interrogative (query) sentence has no truth-
> value.

> > So by induction every query relation expression value is the
> > extension of its predicate

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

> > A relation's attributes are the parameters
> > of its predicate.

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.
> What does mean the pair (foreign-
> key, primary-key) in terms of database design? What do you design with
> this pair?

> > Constraint expressions
> > constrain updates. They do not constrain valid database values or
> > affect query predicates or result values.

> > Modern normalization/dependency theory says that there is a foreign
> > key on attribute set K from a [source] 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.

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

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 Received on Tue Jan 10 2012 - 07:29:14 CET