Re: Concurrency in an RDB - another question about recursive definitions

Bob Badour wrote:
> ...
> What I am saying is: When you project onto A, the data type of B is
> mostly** irrelevant. Likewise, when you project onto B, the data type of
> A is mostly irrelevant.
>
> The fact that you have a recursive data type definition has no effect on
> project or join or restrict or union or intersect or difference etc. The
> values identified as B are simply values.
>
> Assuming:
>
> A = { a1, a2, a3, a4, a5 }
> B = { {a,b} | a in A and b in B }
>
> Given relation R{a in A,b in B}: /* Using C-style comments */
>
> R = { { a1, { a2, { a3, {} } } } /* a=a1, b={ a2, { a3, {} } */
> , { a4, { a3, {} } } /* a=a4, b={ a3, {} } */
> , { a5, { a2, { a3, {} } } } /* a=a5, b={ a2, { a3, {} } */
> }
> ...

Bob, now I remember a parallel question that struck me about your subtle definition of B, B = { {a,b} | a in A and b in B }. I take it that you meant B to be a type that is used by the R relation. But is it somehow plausible to see B as a relation?

If so, I would think that a value for relation B that has one tuple:

B = { { a1, {a2, {a3, {} } } } } /* a=a1, b={ a2, { a3, {} } */

is not possible because by definition (B "referencing" itself), there would need to be two additional tuples to make it stick to the definition, namely

{ a2, { a3, {} }

and

{ a3, {} }.

Thanks for any comments,
p Received on Sat Jan 13 2007 - 10:33:47 CST