relation types
Date: Thu, 4 Sep 2003 17:47:03 -0400
Message-ID: <cAP5b.507$Jc6.48843821_at_mantis.golden.net>
"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
news:bj73hq$133e$1_at_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.
I agree that D&D disagree with my position.
[RM prescriptions snipped]
> 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.
I agree that the most specific type of both values is equal; however, D&D do not seem to define the relational operations in terms of most specific type.
> 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).
Fair enough. MST takes care of this.
> > > 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.
The statement in RM Prescription 10 is really just a subset of the statement in RM Prescription 24. I think we both see a flaw, but take different approaches to resolving the flaw. If the relational operations operate on values, how can they infer constraints unless constraints apply to values? I resolve this by noting that these generic operations operate on declared types rather than most specific types; thus, a constraint declared for a relation affects the type of the result of an operation. You resolve this by tossing constraint inference.
> > > 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?
It really boils down to the difference between declared types and most specific types. It seems to me that we cannot apply the relational operations to values unless they have some declared type including declared constraints.
> 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).
I agree that it involves the difference between declared type and most specific type, but I am not certain we should limit declared type to relvars. Received on Thu Sep 04 2003 - 23:47:03 CEST