Re: Nested Sets vs. Nested Intervals

From: VC <boston103_at_hotmail.com>
Date: Thu, 10 Nov 2005 23:13:20 -0500
Message-ID: <AJSdnce0kOjHh-nenZ2dnUVZ_tqdnZ2d_at_comcast.com>


<amado.alves_at_netcabo.pt> wrote in message news:1131674470.239615.88020_at_g43g2000cwa.googlegroups.com...
> Mneson is not Codasyl nor OQL based on the descriptions I have of
> those.

I asked to explain in what specific ways the graph structure is different from the network model. So far I do not see any.

>
> I believe the Mneson Calculus is an algebra.
>I'm still working on it.
> Example laws:
>
> T ({x1, x2, ...}) = T({x1}) U T({x2}) U ...
> T ({}) = {}
> T (XUY) = T(X) U T(Y)
> T (X^Y) = T(X) ^ T(Y)
> Etc.

Let's assume your algebraic set consists of vertices. The T/S operators create sets of vertices that are not elements of the algebraic set (or if you say they are, the intersection or union operator clearly cannot be applied to vertices). It's obvious that the graph structure is not an algebra (cf. the relational algebra).

>
> Conditions on values are made possible by introducing value ranges, set
> of values expressed in a compact way, typically as an interval or a
> bound. Querying for employees earning less than 40,000:
>
> T (Employees) ^ S (S (T (T (Salary)) ^ RangeForLessThan (40'000)))
>

So instead of using a trivial condition like 'salary < 40,000', would one need to add a special entity (node) 'RangeForLessThan(constant) to the data model for every imaginable constant ? I do not think it can be called an improvement over what we have now. If you think it can, please show how it can be an improvement.

> Of course query optimization would kick in here, and that's the main
> purpose of having the algebra.
>
Received on Fri Nov 11 2005 - 05:13:20 CET

Original text of this message