Path: news.easynews.com!newsfeed1.easynews.com!easynews.com!easynews!c02.atl3!news.webusenet.com!news-hog.berkeley.edu!ucberkeley!newsfeed.stanford.edu!postnews1.google.com!not-for-mail From: lauri.pietarinen@atbusiness.com (Lauri Pietarinen) Newsgroups: comp.databases.theory Subject: Re: database design method Date: 11 Nov 2002 01:42:02 -0800 Organization: http://groups.google.com/ Lines: 58 Message-ID: References: <3dcda833$1@news.uia.ac.be> <3dcedab1$1@news.uia.ac.be> NNTP-Posting-Host: 213.243.149.151 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1037007723 5946 127.0.0.1 (11 Nov 2002 09:42:03 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 11 Nov 2002 09:42:03 GMT Xref: newsfeed1.easynews.com comp.databases.theory:23528 X-Received-Date: Mon, 11 Nov 2002 02:41:49 MST (news.easynews.com) Jan, > > > >To quote further from TTM (pages 136-137): > > > > > > > >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) > > > > > > These "major extensions" they talk about are the NEST and UNNEST operators. > You have just yourself told me that these can be done in Tutorial-D. The > inescapable conclusion then is that it is therefore a superset of the nested > relational algebra. So it walks like a duck, it talks like duck, and it > swims like a duck. Why Date and Darwen want to deny that it is is a duck is > a complete mystery to me. OK, I am no expert on this subject - you could be correct. > > > >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? > > Recursive types are used in lots of programming languages. For a concrete > example think of parsing trees or XML documents. Of course you can simulate > those with unnested tables and non-recursive types but then you have to > introduce artificial node identifiers. OK, I get the picture. But to me it looks like you are trying to undermind the original power of the RM by somehow introducing new kinds of data dependencies, i.e. entities not identified by value but by "position". What use are my powerfull relational operators if I have to write a program to navigate the structure? Anyway, whats so frightening about artificial node identifiers? Granted current SQL-products (except for DB2) do not have decent recursive operators, but there are other ways (e.g. nested set-representation). The beauty of RM relies in the fact that we can use very powerfull operators on the data. Why do we want to throw that away by using nested relations (excessively)? regards, Lauri Pietarinen