Re: Relation-valued attributes (again)

Bryn,

The issues you raise don't really have anything to do with relational theory, though they have to do with expressive power.

jingleheimerschmitt_at_hotmail.com wrote:
> It has been suggested in this newsgroup that relation-valued attributes
> are unnecessary

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.
I say 'basic' because we can have useful 'relational' systems with or without rvas;
but relations with rvas are more powerful yet simpler, because we don't restrict what values can go where.

> 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. For example for a relation with a non-key rva needs something like one relation to record which tuples have empty rva values and another to record rva info for tuples with non-empty rva values; or something like a surrogate in place of the rva and reference into a table of tuples holding the rva info; or a special value (and types extended by special values) to indicate an empty rva, which is effectively outer-joining two conceptual relations that you must restrict and project apart to further manipulate.
Any expression that would have involved the rva relation corresponds to a more complex one involving the multiple relations. All this because you want to introduce an unnecessary restriction.

> Op(AID : Integer) : table { Data : String };
> T { ID : Integer };

> I cannot formulate a query (without using RVAs) that would provide the
> "join" of the two:
>
> select T "join" Op(ID);

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.

> 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.

> 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.

> Obviously, the argument could be made that the information content
> provided by Op should have been exposed as a relation in the first
> place, thereby allowing a join in the usual way. But the point is, if
> the relational algebra is "complete" in some sense, shouldn't I be able
> to express this seemingly simple query?

Our available queries depend on our available expressions-- the latter including, among other things, relational operators. Consider an algebra like Codd's original having only theta-restrict and no rvas:
this gives us certain queries.
We get different queries if we allow arbitrary boolean restrict and/or rvas and/or arbitrary operators returning various values in various places where our expressions allow values. 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.

> Or does the introduction of
> relation-valued operators somehow change the landscape? If relations
> are orthogonal to types, then why do I need to extend the relational
> algebra to provide support for this type of query?

*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. Received on Fri Feb 04 2005 - 03:53:39 CET