Re: constraints in algebra instead of calculus

From: paul c <toledobythesea_at_oohay.ac>
Date: Mon, 18 Jun 2007 10:46:21 GMT
Message-ID: <1otdi.36463$xq1.2671@pd7urf1no>

Jon Heggland wrote:
> paul c wrote:
>

>>It's looking to me now that you are right about WRAP and that I too was
>>confusing it with GROUP, so maybe the constraint should look like:
>>
>>R{B} WRAP {B} as gB = R{B} GROUP {B} as gB,

>
>
> No. On the left, gB is a tuple, while on the right, it is a relation. If
> you disregard that difference (I wouldn't), your constraint will hold
> iff R{B} has at most one tuple---not very interesting.
>
> (WRAP is like EXTEND--it doesn't change the cardinality---while GROUP is
> like SUMMARIZE or project---reducing the cardinality based on the
> projection on a set of attributes. Loosely speaking. :)
>
> R{B} WRAP {B} AS gB = (R GROUP {B} AS gB) {gB}
>
> or better (as Jan Hidders writes, avoiding the tuple/relation mismatch):
>
> (R EXTEND ( RELATION { TUPLE { B B } } AS gB )) {gB} = (R GROUP {B} AS
> gB) {gB}
>
> makes more sense. Afaict, this is a superkey constraint, but imo not a
> particularly elegant, intuitive or efficient one. :)
> ...

Right, thanks, I read WRAP too quickly, what you wrote is a variation on GROUP without the compose, which is what I was guessing at.

>

>>also that as far as TTM/Tutorial D is concerned, Bob B was right about
>>
>>R{B} GROUP {B} as gB = (R GROUP {B} as gB) {gB} being a tautology.
>>
>>p (waiting to be corrected for the umpteenth time!)

>
>
> Here ya go:
>
> R = { (A:1, B:2), (A:3, B:4) }
>
> R{B} GROUP {B} AS gB = { (gB:{ (B:2), (B:4) }) }
>
> (R GROUP {B} AS gB) {gB} = { (gB:{ (B:2) }), (gB:{ (B:4) }) }
>
> I think all this indicates that GROUP is such a difficult operator that
> using it to express constraints is a bad idea. :)

Thanks again and yes, as I've seen, it's not an easy definition to reconcile with my intuition. It does seem that it would be cumbersome in practice, but from an implementation point of view, the other approaches I know of would need optimization too, eg., the COUNT and product/RENAME approaches.

(Another way I sometimes wonder about is to try to express constraints as relations, so that inserting/union in TTM-style might read like

r3 = (r2 <or> r1) <and> constraint, where constraint would need to have rva's.)

p Received on Mon Jun 18 2007 - 05:46:21 CDT