Re: Relation-valued attributes (again)

Hello,

x y wrote:
> Basic relational theory is independent of the types of attributes, so
> there is nothing wrong with rvas, and disallowing them is to
introduce
> an unneccesary restriction.
> But it's restricting your overall notation, not the basic relational
> model.
Firstly, I am not advocating removal of RVAs. I am questioning the impact of including them. I know the oft-repeated phrase 'support for relations is orthogonal to support for types', I am calling it into question with this example.

> > because anything that can be represented with a
> > relation with RVAs can also be represented using an equivalent
> > "unnested" form.
>
> This is not a reasonable argument to disallow nested relations.
> A relation with rvas in general needs multiple non-rva relations
> and/or complex expressions to represent and manipulate.
Again, I am not advocating disallowing RVAs. Indeed, I think this example shows that they are actually *required*, given support for abitrarily typed user-defined operators (relational-valued ones in particular).

> Interpreting Op as a relation mapping argument aid to (relation
> valued) result, perhaps you mean
> select T join ("Op" rename aid as id)
> But this would have an (unnamed) rva so perhaps you mean
> select (T join ("Op" rename aid as id)) unnest {all but oid}
> This now looks like your rva add (extend) formulation below
> but it doesn't help you get what you want without rvas.
The latter, that is why I quoted the "join". It's only a join conceptually in that I'm combining the results from two relation-valued expressions. It's not a true join because I can't invoke an operator "foreach" tuple in the left operand.

> > Clearly this formulation is invalid because the right operand must
be
> > evaluated in the context of a tuple of the left operand.
>
> Not exactly; Op just needs an integer as its parameter.
No, exactly. Try actually running this query as a true join, it can't be done, precisely because the right operand must be evaluated for every tuple in the left operand. Joins don't work this way, you evaluate each operand, and then evaluate the join.

> > The query with
> > RVAs is simply:
> >
> > select T add { Op(ID) RVA } unnest by { RVA };
>
> This only contains the same info as a join of T and Op if Op never
> returns an empty relation.
That may be (I'd have to think about that for a long time) but it is not relevant to the underlying idea.

> In your case you allow functions returning relation values but you
> don't allow relational values to be put inside relations;
> then you complain that you can't express some queries.
> Well, the queries you allowed just aren't the ones you wish you had.
> The fault is not relational theory but in restricting expressions.
> You allow an operator to return a value but you do not let those
> values go where other values may go.
You're proceeding from false assumptions here. My entire example requires RVAs. The point is that if we have RVAs we apparently need to introduce at least one new operator (unnest) to the relational algebra to deal with them.

> *Because* relations are orthogonal to types, you *don't need* to
> extend the relational model.
> Nested relations are not an extension to the relational model;
> they are independent of the relational model!
> But with them things are more powerful and simpler.
Asserting that relations are orthogonal to types does not make it so. If this is indeed the case, express the query without using unnest. In other words, what is the longhand for the unnest operator? In the absence of this longhand, it's hard to argue that a relational algebra with a greater number of primitive operators is simpler. It's also hard to argue that adding an operator to deal with what was supposed to be orthogonal to the model in the first place is not an extension to that model.

The whole point is that if we need an unnest operator, then perhaps the set of primitive operators that constitute the "complete" relational algebra is actually not complete at all. Perhaps there is a more general set of primitives that could be used to express unnest, as well as all the other traditional primitives. Then we would have a "simpler" algebra.

Regards,
Bryn Received on Fri Feb 04 2005 - 09:37:27 CET