Re: Translating constraints to RM Terms

Marshall Spight wrote:

>> For instance, A is actually a domain, as is B, but the constraint A < B
>> must in fact be part of the very definition of the domain A, and here we
>> are
>> defining one domain in terms of another.  I realized I have not seen this
>> disccussed in the year or so I have been a regular here.

Jonathan gave a pretty clear answer on type <> domain, so I am with you so far. Most importantly, the restatement of the question as relationship twixt types and constraints is on the money. In my own mind I am also asking if the constraint is a property of the column or the table.

>
> And I in fact have a tentative answer, which is that they are,
> respectively, the compile time and run time behavior of the
> variables. (Alternatively, the static and dynamic behavior
> of the variables.)

I didn't know where you were going with this at first, but it is quite neat.

But when you say compile time, are you speaking allegorically of the CREATE TABLE command?

>
> Consider: the types of the columns of a table are statically
> identifiable, and for any typed tuple variable whatsoever, we can
> determine at compile time whether the variable is, say,
> insert-compatible with the table. (Or whatever other analyses
> we care to run.)

OK.
>
> But what of constraints? Let us consider a foreign key constraint.
> What can we say at compile time about whether a given insert
> will be compatible with a foreign key constaint? Exactly nothing,
> because the success or failure depends on the value of the variables
> at the time the insert is attempted. We can't know until it's time
> to try it.

Right.

>
> I believe the same thing applies to your a<b constraint. It is not
> in fact a part of the type at all; it is a constraint on the table
> variable, which is a distinct thing. If we have a tuple variable
> and we wish to insert its value into the table, we have to check
> that a<b at the time of insert. It cannot be done statically. But
> wait! you say. You could put such a constraint on the tuple
> variable, and then you could verify it statically. Right!
> The problem, though, is that you've just pushed back the
> question one level. Can you push it back all the way? No,
> because you might be getting values from an external source.
> If you wanted to read two integers from standard input, you
> couldn't statically tell that the first was less than the second,
> so *there has to be a runtime check somewhere.* You might
> as well put it right where it matters and not try to back-propogate
> it through the code, as this will only complicate things unnecessarily.
>

What's really bugging me though is the question of how the constraint is defined.

In our db-builder system, our first-pass constraint system did no more than allow you a list of expressions to be evaluated at the table level. When we refined it, we defined the constraints in terms of allowed values for individual columns, which was far easier to deal with. In other words, the dictionary table holding constraints had as its foreign key a table and column, not a table. This was much easier to work with.

When things get much easier and work much better, it is usually a clue you have found the "true nature" of something. This is what got me wondering if the RM has anything to say about stating the allowed values of one column in terms of another, since that seems the most natural way to do it in practice.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)