Re: constraints in algebra instead of calculus

From: paul c <toledobythesea_at_oohay.ac>
Date: Tue, 19 Jun 2007 00:48:10 GMT
Message-ID: <eJFdi.38587$1i1.24974@pd7urf3no>

Vadim Tropashko wrote:
> On Jun 18, 12:15 am, Jon Heggland <jon.heggl..._at_idi.ntnu.no> wrote:
>

>>I think all this indicates that GROUP is such a difficult operator that
>>using it to express constraints is a bad idea. :)

>
>
> Grouping is has much in common with set equality join, and set joins
> were are known to be difficult operators:
> http://fie.engrng.pitt.edu/fie2003/papers/1057.pdf
>
> More important, however, is that the attempt to express such a
> fundamental constraint as functional dependency via some obscure
> operator doesn't seem right to begin with.
>

I presume by not 'right' you mean not very much to the point or not opportune or maybe even not in the best of taste and I'd agree with those.

These are the ways I can think of to express the constraint:

1. COUNT(R{A}) = COUNT(R)
2. ( R <AND> (R RENAME A as a, B as b) ) WHERE A = a & B != b IS EMPTY (using a grab-bag syntax, possibly inviting correction umpteen + 3)
3. the elaborate one using GROUP that Jon H corrected
4. something like R GROUP {ALL BUT} as c <AND> constraint{c} IS TRUE/NOT EMPTY (where constraint has one tuple for each legal R value and c is an rva)

I'd be interested to hear of others as these all seem to rely on various devices such a COUNT, RENAME or attribute introductions ala GROUP that don't seem very fundamental, but maybe that's just a narrow view on my part. Unless there is a more to-the-point way, I suppose a "KEY" keyword device isn't any more obscure than the above!

p Received on Mon Jun 18 2007 - 19:48:10 CDT