Re: database design method

Jan,

Date indeed admits and even explains his recantation in "An Introduction to Databases, 7th Edition" in Chapter 5 under the subsection entitled "Relation-Valued Attributes". I am somewhat surprised by your surprise. His 7th edition has been out for some time now.

I hate to dampen any glee concerning Date's apparent abandonment of 1NF and the classical relational model, but he does also write the following in reference to what Ms. Pietarinen's commented on in Date's "Introduction...." annotation:

"Some writer's would reject this definition and define an 'NF^2 relation' to be any relation with at least one attribute that is relation-valued. We have our own reasons for arguing that such a relation in fact is in first normal form."

My thoughts on the foregoing are that Date interpreted Roth, et. al's definition of a NF^2 relation to be a relation that held non-relational structures (i.e. quasi-relations holding repeating groups). He seems to maintain that true relations with true relation-valued attributes still meet the criteria to be categorized as both 1NF, and even more importantly also as true relations based on their classical definition. I interpret his rationale for this as being that since each relation is a kind of value, or type, it is considered a single "value" for each intersection of tuple and attribute (as opposed to repeating values), much along the lines of Ms. Pietarinen's assessment where each "value" needs to be opened up independently for a further breakdown of composite scalar values.

So please don't kiss 1NF good-bye yet. ;-)

Moreover, Mr. Date, in chapter 11, does go on to say that it seems prefereable to avoid relation-valued attributes, at least for base relation variables in most cases, because they are asymmetric and provide a degree of needless complexity.

Regards,

Dan Guntermann

"Lauri Pietarinen" <lauri.pietarinen_at_atbusiness.com> wrote in message news:e9d83568.0211101131.67450b30_at_posting.google.com...
> 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 Mon Nov 11 2002 - 06:09:07 CET