Re: database design method

"Jan Hidders" <hidders_at_REMOVE.THIS.uia.ua.ac.be> wrote in message news:3dd03741$1_at_news.uia.ac.be...
> >> If you want to be precise it should be for example:
> >>
> >> ( node-value : "book",
> >> subtrees : { ( node-value : "chapter1", subtrees : {} ),
> >> ( node-value : "chapter2", subtrees : {} ) } )
> >>
> >> and in this value the following nested values would also belong to the
type:
> >>
> >> ( node-value : "chapter1", subtrees: {} )
> >>
> >> ( node-value : "chapter2", subtrees: {} )
> >>
> >> Note that his example is a bit artificial because the chapters are more
> >> likely to be list then a set, but that is besides the point.
> >
> > So {} is a valid value for this tuple type. Excuse my ignorance, but what
is
> >it? A tuple with two attributes but no 'rows'?!

>
> Look in the type definition. The type of 'subtrees' is a RELATION type. The
> {} denotes the empty set, i.e., an empty relation.

Yes, sorry. Attribute Subtrees is a RELATION of type {TREE Tree}. So by {} you mean a RELATION of type {TREE Tree} with no rows.

And to hummer me, {} = {} iff they are empty sets of the same relation type. Yes?

Ealier, I said
>>True, but would your tree tuple example be the best way of implementing a >>tree data-structure anyway?

>Implementing? This is the logical level we are talking about, so a better
>word would be "modelling" or "representing" and it should IMO be up to the
>user if this is how he or she wants to represent that data that way or not

OK, wrong usage of that word. IMO the fewer arbitrary options a user has the better.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Tue Nov 12 2002 - 12:07:08 CET