Re: database design method

Not so fast, Jan

> >On pages 137-138 there is a discussion of NEST and UNNEST
> >(in Tutorial-D the operations are called GROUP and UNGROUP).
>
> Wow!! Do you realize what this means? Chris Date has recanted! The
> relational model is dead, long live the nested relational model. We can
> finally kiss the 1NF good bye. Good riddance, I say. I think I'm beginning
> to like Tutorial-D. :-)

To quote further from TTM (pages 136-137):

<quote>

Note that we permit relations (and tuples) to include attributes whose values are relations. (However, we explicitly do not espouse "NF squared" relations as described in e.g. reference [121], because they involve major extensions to the classical relational algebra, extensions that we find unnecessary.)

[121] Mark A. Roth, Henry F. Korth, and Abraham Silberschatz: "Extended Algebra and Calculus for Nested Relational Databases," ACM TODS 13, No.4 (December 1988)

</quote>

And further in "An Introduction to Database Systems" (7ed) on page 143 there is more annotation on the mentioned reference which is too long to repeat here.

What I understand of this is that the attribute is seen by the relational operators as just an attribute. We have to separately "open up" that attribute to see what's inside it and further operate on it.

> So can I abuse you a little more as my tutorial-D tutor? :-) Can I have
> recursive types? For example (probably not the right syntax, but I think you
> will understand what I mean):
>
> TYPE Tree = TUPLE { NODE-VALUE STRING, SUBTREES RELATION { TREE Tree } }
>

I don't really know if what you suggest here is permissible - perhaps it is. However there are no relational operators that would "traverse" the tree. You would have to explicitely "open up" each tree-tuple separately.

What are you trying to achieve with this construct? Is it something that can't be done any other way? What would this be useful for?

regards,
Lauri Pietarinen Received on Sun Nov 10 2002 - 20:31:23 CET