Re: Nested Sets vs. Nested Intervals

From: vc <boston103_at_hotmail.com>
Date: 11 Nov 2005 05:46:40 -0800
Message-ID: <1131716800.792657.135870_at_z14g2000cwz.googlegroups.com>


amado.alves_at_netcabo.pt wrote:
> "Let's assume your algebraic set consists of vertices."
>
> Let's not. The algebraic *type* is the set of vertices. That means the
> algebraic set is the set of sets of vertices. The notation T(k) where k
> is a constant is just an abreviation for T({k}). I've said all this

Ok, so you have sort of graph vertices algebra if you present each node as a one element set. However, it does not qualify for being called a graph algebra since you have no operations defined for graphs themselves, you have them only for vertices.

To clarify, your database schema can be seen as one large graph. Clearly, the real world entity is modelled as a subgraph. So what operations do you define to manipulate/query such subgraphs ? How does one construct a new entity (a subgraph in your model) as easily as can be done in the RA with its joins/projections/etc. ?

An analogy might help. Let's say you have a model with the classical database relations but no relational operators like joins and such defined for the relations. Can you seriously claim that you have a sort of algebra just by virtue of the relation attributes belonging to the domains with closed operations (like set of integers closed under multiplication/addition) ?

I am not trying find faults in your system, but what I see is a graph model virtually indistinguishable from the Codasyl network model with all the usual problems, like application dependency, navigational quering, lack of query algebra, etc. (as are XML "model", RDF and other proposals of the kind).

> before.
>
> /*
> Maybe the abbreviation T{k} would be better. Actually I have
> considered: T<string> for T({"string"}), T[number] for T({number}).
> */
Received on Fri Nov 11 2005 - 14:46:40 CET

Original text of this message