Re: Plural or singular table names

From: Paul Vernon <paul.vernon_at_ukk.ibmm.comm>
Date: Thu, 4 Sep 2003 11:15:43 +0100
Message-ID: <bj73hq$133e$1@gazette.almaden.ibm.com>

"Bob Badour" <bbadour_at_golden.net> wrote in message news:M9s5b.436$iP3.44134429_at_mantis.golden.net...
> "Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
> news:bj59dh$13i2$1_at_gazette.almaden.ibm.com...
> > "Bob Badour" <bbadour_at_golden.net> wrote in message
> > news:Lwn5b.422$0G3.43916381_at_mantis.golden.net...
> > [snip]
> > > > > Consider the following relation:
> > > >
> > > > Relation variable or relation value?
> > >
> > > It doesn't matter. It is a relation with known constraints.
> >
> > Whether something is a value or a variable doesn't matter?
> >
> > > Values do have constraints; they have types.
> >
> > Nope, a type is part of the value.

> I agree. The type constraint is part of the value. Thus A and B might both
> be unary relations with a single integer attribute C. A and B might both
> have a single tuple with the integer value 1 in C. If the candidate key of A
> is {} while the candidate key of B is { C }, then the type of A and the type
> of B are different. Likewise comparing two relations with different
> constraints Z = A + B and Z = A ^ B. The constraints are part of the type
> specification and affect the resulting values of operations on the values.

Good paragraph Bob. We should be able to come to some (dis)agreement here.

Plainly I don't agree with you that constraints are part of the type specification. Nor do Date & Darwen. At least that is my reading, if yours is different then maybe we can ask them to try to make the point more explict in any new version. I'll quote some bits from the 2nd ed.

RM Prescription 7: Type Generator Relation

The generated type RELATION{H} is referred to as a relation type, and the name of that type is, precicely, RELATION{H}

RM Prescription 13: Relation Variables

A relvar of type RELATION{H} is a variable whose permitted values are relations that conform to a specified relation heading H. The declared type of that relvar is RELATION{H}. RM Prescription 10: Relations

A relation value r (relation for short) consists of a heading and a body, where:

The heading of r is a tuple heading H, as defined in RM Prescription 9;
The body of r is a set B of tuples, all having the same heading H;

RM Prescription 9: Tuples

A tuple value t (tuple for short) is a set of ordered triples of the form <A, T, v>, where

A is the name of an attribute of t. No two distinct triples in t shall have the same attribute name.
T is the name of the type of attribute A of T.
v is a value of type T, called the attribute value for attribute A of t.

So there is no inclusion of constraints (other than that attributes are of some type) in the definition of tuple and relation headings.

The unary relvars A and B you mention are equal (contain values that are of identical value and identical type) no mater what constraints might be declared against them. A database where equality of relation values was dependent on some declared 'value constraints' would not, in my opinion, be very useful or intuitive (assuming it would make much sense anyway, especially in the light of imperfect constraint inference).

> > Nope, a relation value has a heading and a body. The heading defines the
> type of the
> > value and is part of that value.

> I prefer to say that a relation has a predicate and that the heading is a
> required part of the predicate. The predicate defines the type of the value
> and is part of that value.

I think the term 'predicate' has been slighty ill used in TTM, and therin lies your confusion.

In RM prescription 10, they say no more than that

"the heading of [a relation] r can be regarded as a predicate".

But in RM prescription 24, which, may I say, I believe is driven to it's detriment by Date's view updating stance, they say that

"Basically, a relvar predicate is the logical AND of all the constraints that apply to the relvar in question"

So at the least, there is a quite a big difference between a relation predicate and a relvar predicate. That is not good for clear thinking on the matter.

> > It might satisfy A -> B, but
> > A -> B is not part of it's value - it would be redundant if it was because
> we could
> > derive the fact that A -> B from the actual value of the relation.

> There is an important difference between essential implication and
> incidental implication. We can only derive incidental implication from the
> value unless essential implication is also part of the value.

For example?

I think I would say that essential implication is declared against variables, while values only have incidental implication (disregarding that catalog values can record essential implication about variables).

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Thu Sep 04 2003 - 05:15:43 CDT