Re: Foreign superkey support

erk wrote:
> Marshall wrote:
> > erk wrote:
> > >
> > > Some database constraints restrict only the domain of tuples allowed in
> > > a specific relvar, so are relation constraints (i.e. they are
> > > expressions over only the attributes of a single relvar). Other more
> > > specific constraints are type constraints and attribute constraints
> > > (expressions over a single attribute or attribute type).
> >
> > I have read various classification systems for constraints, and they
> > all seem unnecessary to me. They don't really buy me much if
> > anything.
>
> Just to clarify: I was really just playing some mental games with
> typing, and "how far up it goes": types of attributes, types of tuples,
> types of relations, types of databases. With respect to that, the
> "scope" of a constraint does determine whether it's part of the type of
> a relation or a database.
>
> For example, let's say you have a database D1 with relations A1 {x:X,
> y:Y} and B1 {x:X, w:W}, with no constraints (the x attribute in A1 and
> B1 just coincidentally the same, by the way). That database (a
> variable) has a type/domain, defined by the set of relvars it contains.
>
> If I define D2 like D1 but with a constraint ("all B2.x in A2.x"), then
> the type/domain of D2 is a subtype of D1. It would also seem that the
> type of B2 is a subtype of B1, despite the fact that the constraint is
> a database constraint. I'm not sure about that, and am somewhat worried
> that I'm stumbling into a variant of one of the Great Blunders here.

I'm quite suspicious of subtyping these days. It doesn't seem worth the complexity costs to me any more.

Also, subtyping is only useful to consider in light of substitutibility.
Is there a use case for substituting a D2 for a D1? (Actual question.)

> > While on the one hand it is quite tempting to consider
> > a constraint as having some particular scope, especially if it can
> > be pinned on a particular relvar, it doesn't really hold up. For any
> > constraint, we have a set of relations that it is quantified over.
> > If that set is cardinality one, that is just particular to that
> > constraint; it doesn't classify it per se.
>
> But a cardinality 1 constraint definitely defines a relation subtype,
> whereas cardinality > 1 doesn't (necessarily).

I'm not sure you understood me; I was referring to the cardinality of the relations involved in a constraint. In other words, how many. Not a cardinality constraint on a relation per se.

> > In other words, there is a many-to-many relationship between
> > constraints and relvars. (Or relations, if we are thinking in
> > descriptive rather than prescriptive terms.)
>
> It depends. To what extent are the cardinality-1 constraints part of
> the "type" of the relvar? That's the only notion I'm playing with.

I tend to take the type theory viewpoint, which is that "type" is limited to things that can be checked statically. (There are certainly other persectives, though.) In general, constraints are not statically checkable; they check *necessarily* must be performed at runtime. In constrast, type checks can occur statically, without any knowlege of the current value of any relvar.

> > For example,
> > we often speak of a foreign key constraint as belonging to
> > one particular table, but it is equally a constraint on two tables.
> > On one table it restricts inserts and on another table it restricts
> > deletes.
>
> Good point - so in the above case, is A2 a subtype of A1 and B2 a
> subtype of B1?

You would have to check substitutibility.

Marshall Received on Wed Aug 09 2006 - 16:49:23 CEST