Re: Nested Sets vs. Nested Intervals

<amado.alves_at_netcabo.pt> wrote in message news:1131667676.280790.90400_at_g47g2000cwa.googlegroups.com...
> Each single concept is represented by a vertex. The properties of the
> concept are represented by topologies involving the vertex. The fact
> that employee x10 works in the accounting department may be modelled as
>
> Employees => x10
> x10 => x11
> WorksIn => x11
> x11 => Accounting
>
> where x => y means connected from x to y. Note that this model makes
> similarly possible and simple to query for where does x10 work
>
> T (T (x10) ^ T (WorksIn))
>
> and for all workers in accounting
>
> T (Employees) ^ S [S (Accounting) ^ T (WorksIn)]

Ok, I see. Now, please explain the following:

1. How is the graph model navigation different from the old Codasyl network model pointer chasing, as what you apparently do is:
2. go one step down from the Employee node and collect all its children
3. go one step up from the Accounting node and collect all its "parents"
4. go one step down from WorkIn and collect all its children
5. find the intersection of sets from step (b) and (c)
6. go one step up for each element in the set constructed at step (d)
7. find the intersection of sets constructed at step (a) and (e)

The only novelty in comparison to the old network model appears to be the ability to use sets of nodes and set operations on them (which is not quite a novelty since as far as I remember OMG's OQL could do the same).

2. The structure you've described is not an algebra because it's not closed over the operations you've defined (compare to the relational algebra).

3. It's unclear how you handle attributes like age or salary (find all the employees in accounts whose age is between 30 and 40 and salary is less than 40,000).

>
> (A more demanding schema would require a department be also a pivot, so
> it could have attributes attached, and be a member of a Departments
> like employee x10 is a member of Employees.)
>
Received on Fri Nov 11 2005 - 02:21:21 CET