Re: A Topological Relational Algebra in Lisp

On Friday, January 23, 2015 at 12:32:12 PM UTC-8, Norbert_Paul wrote:  

 > >> Take the example space S (the "sketch"):
> ...
> >> Now the example space S may reference these detail aggregates (via a
> >> foreign key from S to I):
>
> Note "foreign key". I meant to extend both relations S and D by an additional
> attribute "detail". I know, I should have been clearer here. Mea culpa.
> The relational schemata of S an D are hence
>
> S(id, detail)
> D(id, detail)

You are joining S ("Sketches") with D ("Details"). The fact that both S and D have an attribute called "detail" is confusing.

Better names for attribute values would also help. For example, innerDoorMaterial could be glass, entranceDoorMaterial could be veneer.

Please note how intuitive for a lay person is a typical database query: "Find the names of all females who eat at least one pizza served by Straw Hat" (https://class.stanford.edu/c4x/Engineering/CS145/asset/opt-rel-algebra.html)  

> OOPS! I just realize that I have to rename the id-attributtes to get the
> natural join in the way I had it in mind:
>
> S(sid, detail)
> D(did, detail)

A well known approach here is to represent detail attribute as complex datatype (AKA spacial datatype). The challenge there is defining operators; most important the equality. In that respect your solution seems novel.  

> There is no need for a foreign key into another ("auxiliary") table, but I
> copied that setup from topological pullback. If this table is omitted, you
> get a natural join of relational representation of topological spaces. The
> "auxiliary" table already goes beyon join and was intended to illustrate
> an application I have in mind.

May I ask you to revisit the example?  

> >> object detail
> >> -----------------
> >> room1 -> int
> >> door -> xdoor
> >> outside -> ext .
> >
> > OK, now you are introducing something new -- aggregation. Are you implying
> > that topological extension of a join is not a dyadic operation anymore, and
> > requires auxiliary pair (I,RI)?
>
> No, it is a simple natural join on S and D (with the schemata corrected ;) ).

Perhaps with better naming and correct schema it would be simple. It is much harder to understand what is joining Sketches with Details.

> The point of table I is to demonstrate yet another feature: "/continuous/
> foreign keys" as a topological consistency rule for spatial data. The
> "aggregation" is an application I have in mind. Natural join also works without
> all that extra decoration.
>
> > I'm uncomfortable at this stage because, one can explain classic natural join
> > between Employees and Departments in a single paragraph and suggest that
> > perhaps a more succinct example is wanted. For example, can you amend either
> > (S,RS) or (D,RD) with (I,RI) and construct a pair of topologically enhanced
> > relations which natural join can be explained without the help of auxiliary
> > pair (I,RI)?
>
> Natural join on topological data represented as (S,RS) and (D,RD) works just
> that simple way on S and D to get, say, SD. But then in order to get a
> meaningful topology for SD you can compute a binary relation RSD from RS, RD,
> and SD that represents the initial topology of the two projection mappings
>
> pi_S : SD -> S and pi_D : SD -> D .
>
> Everything else was decoration to illustrate an application of
> topological natural join, which I consider interesting. In particular, the
> additional relation I (or, the space (I, RI)) is no prerequisite. Sorry for the
> errors in defining the schemta, which give intersection, and sorry for all
> other sloppiness in my post.

Please note that at this moment I'm confused on the meaning of both

S join D

together with

RS join RD

This is because you have introduced common attribute "detail" into both S and D while omitting the example. I can make guesses interpreting the id as identification of parent object in the aggregation, and detail being child. Then, join S with D is finding objects with common set of children. Again, a fixed example would be nice.

> > Yes, natural join is ubiquitous because there are 3 special cases:
> > 1. ...
> > 2.
> > Selection is a join where the first operand set of attributes is a subset of
> > the second operand attributes. (One have to allow relations/predicate of
> > infinite content in order to express something like "select * from employees
> > where salary> 1000" via natural join)
> > 3. ...
>
> I consider your "selection" argument overly formal. You must then use the
> trivial topology for your infinite infinite relation to get selection work this
> way. Usualy I consider the discrete topology the default for "bare" tables
> without an explicitely given topology. But I found authors who consider the
> trivial topology a better default. But don't ask me who it was. That was more
> than ten years ago when I stumbled over that paper.

I moved this part towards the end of the discussion: assuming you helped to resolve my confusion over natural join, this is the second issue to clarify. Why do you endow the real line interval (1000 < x < infinity) with trivial topology? Isn't it standard metric space? http://en.wikipedia.org/wiki/Real_line#As_a_metric_space Received on Fri Jan 23 2015 - 23:38:01 CET