Date: Thu, 7 Jul 2005 12:05:50 +0200
In article <wLVye.138749$to.7294014_at_phobos.telenet-ops.be>,
> > The quote didn't mention nested relations, it is about sets. Do you make
> > that assumption about sets as well? Why?
> These sets are very similar to unary relations. Treating them
> differently would make not much sense because there are simple
> operations that transform one into the other.
> > Why not about strings?
> They are not very similar to relations. :-)
> Besides, most nested
> relational algebras I know are not equipped with an operation for
> unnesting strings.
> > Given the above definition, do you think that a relation with relation-
> > valued attributes in the presence of nest/unnest should be "normalised"
> > to reach 1NF? Why?
> It ensures that the operations at relation level are essentially those
> of the flat relational algebra and that they all work, in some sense, at
> the same level.
> The theory of query optimization for these operation is
> reasonably well understood, which is far less the case for operations
> that mix the levels of computation such as the nest and unnest do. In
> some sense we are forcing here the user to keep things simple so that
> the job of the query optimizer becomes easier.
I think your objection here is to the existence and complexity of nested version of the standard relational algebra operators. Date does, too--- that's why he discards them. He writes:
"Now, this idea has been extensively researched [...] under such names as 'nested relations' or 'NFNF relations' (NFNF stands for 'non first normal form' [...]). However, I do not take the approach of references [Jaeschke; Roth, Korth and Silberschatz], which add many new operators to the relational algebra and calculus to handle 'nested relations', and thus definitely do breach first normal form (as the term 'non first normal form' suggests). Rather, I propose a simple generalisation of the relational algebra extend operator to permit (among other things) the use of relation-valued expressions to define attribute values. In this way, I stay within the spirit of the classical relational model, while still obtaining some of the benefits, such as they may be, of 'nested relations.'"
Thus, I ask you if we can agree that generalising extend to support nest/unnest functionality in the way Date suggests is also okay, since it does not imply adding nested versions of the classical operators; and that it does not affect normalisation.
> > (Btw, I'm not sure what you mean by "nested relational algebra"---Date's
> > GROUP and UNGROUP don't affect the other operators in any way.)
> I use the term as it is commonly used by database researchers and that
> is the one you find if you google for "nested relational algebra".
> I'm not sure what you mean by "affect the other operators" here.
I mean that "the operations at relation level are essentially those of the flat relational algebra and that they all work, in some sense, at the same level." Join, project, select/restrict, union, difference and so on remain exactly the same. You have to be able to compare two relation values for equality, but that is trivial.
-- JonReceived on Thu Jul 07 2005 - 12:05:50 CEST