Re: database design method

In article <aqqnee$kua$1_at_sp15at20.hursley.ibm.com>, Paul Vernon <paul.vernon_at_ukk.ibmm.comm> wrote:
>"Jan Hidders" <hidders_at_REMOVE.THIS.uia.ua.ac.be> wrote in message
>news:3dd03741$1_at_news.uia.ac.be...
>>
>> 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}.

No problem, I just noticed that I switched my use of brackets between the type and the instance to the usual mathematical convention ( () for tuples, {} for sets), so the confusion is my fault.

>So by {} you mean a RELATION of type {TREE Tree} with no rows.

Yes.

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

If that's what makes you happy. :-) If I had done it properly then I would have written with every relation the relation type it belongs to.

>>>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.

It is very difficult to judge in advance if such a choice is always and everywhere under all circumstances arbitrary or not. There is no data structure so weird or somewhere on the world there is somebody who has good reasons to model their data that way. And simulating it with surrogate identifiers means that you have to add a set of not so trivial constraints that guarantee that is a tree and that there are no duplicats in the sets, and you burden the user with computing explicitly the deep equality. The bottom-line is that you cannot make the complexity go away by modelling your data in a simpeler data model.

• Jan Hidders