Re: Plural or singular table names

"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message news:bj7e03$132s$1_at_gazette.almaden.ibm.com...
> "Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
> news:bj73hq$133e$1_at_gazette.almaden.ibm.com...
> > Plainly I don't agree with you that constraints are part of the type
specification.
>
> I guess I should clarify that (obviously?) I mean that constraints are not
part of
> the type specification of tuple and relation types.
>
> Also, I'm obviously aware that sub types are specified by a constraint on
a super
> type. With type inheritance, the rule that values must be of the same to
possibly be
> equal is replaced by the rule that as long as one type is a subtype of the
other then
> their values can possibly be equal.
>
> TTM formulates type inheritance directly only for scalar types. Tuple and
relation
> type inheritance follows from any subtyping of their attributes, not by
any (other)
> constraints that they might have.
>
> So if you have two relvarsA and B. Both with type
> RELATION{ H }
> where
> H = {<X, INTEGER>, <Y, INTEGER>, <Z INTEGER>}
>
> and A has the key {X, Y, Z} but B has the key {X, Y}, then *even if* you
considered A
> to be of a different type of B (I and D&D don't), then you might consider
that type
> of B would be a subtype of A, and so the value of A will equal the value
of B if they
> contain the same set of tuples of type TUPLE{H}.

True.

> But as I said, I don't believe that type inheritance needs to be defined
separately
> for relations. See IM Prescription 25: Tuple/relation Variables with
Inheritance for
> more details.
>
> Constaints are not part of the type specficition of relations and tuples.

Obviously, I think they are regardless of any artificial distinction. Do you have a reason for thinking the distinction is necessary? Received on Thu Sep 04 2003 - 23:32:42 CEST