relation types

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:eTI5b.351259$o%2.160496_at_sccrnsc02...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
news:TpH5b.479$rt5.47174800_at_mantis.golden.net...
> > "Marshall Spight" <mspight_at_dnai.com> wrote in message
> > news:bqz5b.263499$Oz4.69861_at_rwcrnsc54...
> > >
> > > The question being discussed is whether relation values have
constraints,
> > > and in particular whether they have key constraints. I can see how the
> > above
> > > explanation works if I have already accepted the idea that relation
> > > values have keys, but I do not see how it leads me to accept that
> > > idea if I haven't already.
> >
> > Are you suggesting you reject the information principle and logical
> > identity?
>
> Of course not, and I have no idea why you even brought it up.

The information principle and logical identity imply (or state outright) that all relations have at least one candidate key.

> > > You also now seem to be including the idea that constraints
> > > are part of the type. This also strikes me as unusual.
> >
> > Specialization by Constraint seems unusual to you? As soon as you take
one
> > type and constraint it, you have created a new type.
>
> We were speaking of constraints in general, and key constraints
> in particular. Now you are saying that type constraints and
> key constraints are the same thing? That is the only way I
> can make sense out of your response.

I am saying that key constraints are one kind of type constraint. Not all type constraints are key constraints, but all key constraints are type constraints.

> TTM draws the distinction among type constraints, attribute
> constraints, relvar constraints, and database constraints.
>
> Type constraints are constraints on types, (not relational values.)

All values have a most specific type. Assuming type inheritence, one would observe a relation value has the most specific type of applying all allowable constraints for that value. Thus each relation value really has all incidental irreducible keys as candidate keys. This seems to pose a couple of problems though; not least of which is the dense DAG of types. Also, TTM appears to define the relational operations in terms of declared types and not in terms of most specific types. Thus, unless a relation value includes a valid predicate or "declared type", how does the dbms handle relational operations on values?

> Attribute constraints are constraints on the legal values of a given
> attribute within a relvar.

They are type constraints on the attribute.

> Relvar constraints are constraints on relvars, not relations.
> Database constraints are constraints on two or more specific relvars.
>
> Your have been saying that relation values have key constraints.
> Which of the above kinds of constraints is a key constraint on
> a relation value?

The type constraint.

> Or do you have a different taxonomy you
> could tell us about?

Nope. Key constraints are type constraints.

> > I don't see that. If all relations have logical identity, they all have
at
> > least one irreducible key. If all relations have one irreducible key,
they
> > all have logical identity. Values, variables, expressions and literals
do
> > not come into consideration.
>
> Okay. You're saying that the uniqueness property is the same thing
> as a key constraint. I can see that, although I'm not sure I agree.
> The definition of "key" now becomes relevant.
>
> [Checking TTM...]
>
> TTM's definition of candidate key specifies that it applies
> only to relvars. (See RM Prescription 15.)
>
> Perhaps you have a different definition of key that you could
> tell us about?

I disagree with TTM. They make an explicit exclusion for relations from type constraints, and I see no reason for this. A relvar constraint is simply a type constraint that describes the type of the relvar.

> > > Also, I can see how:
> > >
> > > every relation has a key -> unique tuples
> > >
> > > but I don't see how
> > >
> > > unique tuples -> every relation has a key.
> >
> > The latter implies that the set of all attributes is a (possibly
> > irreducible) superkey, which implies that the relation has at least one
key.
>
> Again, this depends on the definition of "key."

I suppose. I define candidate key as an irreducible set of attributes sufficing to uniquely identify a tuple in a relation.

> > > Foldoc gives this definition for constraint: "A Boolean relation,
> > > often an equality or ineqality relation, between the values of
> > > one or more mathematical variables (often two)."
> > >
> > > Also, I checked a few places in TTM, but could only find references
> > > to constraints on variables (database or relation variables) and
> > > constraints on types. (Admittedly, this is just appeal to authority,
> > > and not definitive.)
> >
> > You found no reference to specialization by constraint or to
generalization
> > by constraint?
>
> Note I said "and constraints on types."

How exactly do candidate key constraints differ from other type constraints?

> > You found no suggestion that values have types?
>
> I don't see how you get from what I said to that.

You have clarified some things for me. Hopefully, I have for you too. Received on Thu Sep 04 2003 - 23:24:05 CEST