Re: database design method

In article <e9d83568.0211112344.1d0c5ccf_at_posting.google.com>, Lauri Pietarinen <lauri.pietarinen_at_atbusiness.com> wrote:
>> >They are - in your approach - in fact identified by their parents
>> >values.
>>
>> Have you been reading my PhD thesis?
>
>Sorry to say - no I haven't. Can you give me a
>pointer?

It's not really that relevant except that the question came up whether nested values are identified by just their components are also by their containing values. Just look in Google on my name, and you will find it.

>> But seriously, they are not. Two trees are the same if they have the same
>> attributes and set of children, just like two tupels are the same if they
>> have the same attributes. Period. The parent doesn't come into that.
>
>But we are looking at the tree from two (or more?) viewpoints:
>
>- the nodes themselves
>- the nodes in relation to other nodes
>
>Say I have I file structure with files and
>folders (or just folders to simplify the picture).
>
>Now the folders them selves are interesting on their
>own right, but what is also interesting is their
>relation to one another. But these two aspects
>are distinct.
>
>In the "nested relation" approach we would emphasize
>the structural aspect only.
>
>And what if these folders have files in them?
>Do we just nest the files inside the folders?
>
>And if the files have access rights - we
>just nest them inside the files?
>
>And the nodes _are_ identified via their parents.
>If you dont know their parents, how do you get
>a hold on them?

You are speaking about a specific kind of trees; those where the nodes have identifiers. In the example I gave this is not the case.

>> By using recursion:
>>
>> Then you can do (I hope you will forgive me if I use the conventional nested
>> relational algebra):
>
>Sure.
>
>>
>> R1 := Trees UNION (UNNEST[Subtrees](PROJECT[Subtrees](R1)))
>> R2 := PROJECT[Name,Attr](R1)
>> R3 := SELECT[Attr="Lauri"](R2)
>>
>
>OK - no do-while loops. But how on earth does the optimiser handle this
>query besides materialising the whole tree?

By pushing the selection into the recursion and using a query optimization technique called "magic sets".

>Can it use a traditional B-tree index to find Attr="Lauri"?

Yes.

>I think we are loosing so much for so little gain.

What loss? Everything that could be done can still be done. Loss of optimizability? Not true; in the physical model the data might be represented in the same way as when the user had used surrogate identifiers? Loss of simplicity? That is up to the user, if he or she wants to represent their data that way then it is probably the simpelest for them.

>> You are inventing a nodeID that was not in the original data model of the
>> user. Don't forget that we are talking about a *logical* data model here.
>> There's nothing wrong with using surrogate identifiers but that is an
>> implementation issue and the user shouldn't have to be aware of that.
>
>Well, speaking of XML specifically - the nodes are identified
>by their parents and their position relative to the other siblings,
>and that causes lot's of problems. So you either identify
>the nodes by position or by some surrogate. My vote goes
>for surrogates.

There is actually in this case a natural key: the position in the document.

>> >This requires recursive support (available
>> >in DB2, and partly Oracle)
>> >
>> >(Needless to say: Dataphor has it)
>>
>> Good. So everything we need is already there.
>
>Sorry.
>Not the recursive definitions, but an explode-operator.

Then the claim that it has recursion is incorrect. The explode operator is ony a very limited form of recursion. Why does it not have recursion?

>> You can. But I don't think you should be using algebra operators for that
>> but a more declarative type of language. I assume Dataphor has that?
>
>What on earth could be more declarative than relational operators???

The relational calculus.

• Jan Hidders