Re: Comments on Norbert's topological extension of relational algebra

On Saturday, December 19, 2015 at 5:05:29 AM UTC-8, Nicola wrote:
> On 2015-12-19 11:14:52 +0000, Norbert_Paul said:
>
> > R1
> > object id1 id2
> > --------------
> > cube n 1
> > cube n 2
> > ...
> > sausage m 1
> > sausage m 2
> > ...
> > ball k 1
> > ball k 2
> > ..
> >
> > Then consider R1 a binary relation on PART:
> > FOREIGN KEY(object id1) REFERENCES PART
> > FOREIGN KEY(object id2) REFERENCES PART
>
> The term "relation" is used to denote
>
> A. a mathematical relation (the subset of a Cartesian product);
> B. a named relation (a set of tuples);
> C. an association defined by foreign keys.
>
> Although it is clear from the context what you mean, calling R1
> a "binary relation" (in the sense C) is a bit confusing because
> R1 is a relation of degree 3 (in the sense B). On the other hand,
> R1 represents a specialization preorder, which is a binary relation
> (in the sense A). In this specific example "binary relationship" or
> "binary association" might be a better term.
>
> In general, I wish that we could use a less ambiguous terminology,
> especially to distinguish between A and B (but I am not fond of
> "relvar"...).

Agree: "Relvar" is just awful.

1. Mathematical relations are indeed binary relations (with "anonymous" attributes).
2. Relational database theory studies relations with named attributes. Although there is named vs. unnamed perspective described in very beginning of the Alice book, it is the named perspective that reigns supreme in database practice. Please also note that "unnamed" perspective is not really "unnamed" -- it is better called "indexed", where attribute names are natural numbers.

The proper name for a relation with named attributes is "multivariate relation". As our discussion have already touched semi-algebraic sets, this motivation for that name https://vadimtropashko.wordpress.com/2014/01/02/relations-as-finite-varieties would be not entirely out of place.

3. Association defined by foreign key is not a relation. It is a "relationship", at best. Formally, it is a constraint, which is quite easy to formulate algebraically. It can even be expressed as equality, e.g. https://www8.cs.fau.de/_media/litak:rellat-jlamp-final.pdf (page 2)

Getting back to discussion of topology, I agree that fibre product corresponds to natural join. Spivak is saying the same thing in his "Categorical databases". And if you know what join operation is, then you have nailed half of relational algebra (cartesian product, selection, set intersection).

I still don't get the idea that topology can be viewed as [multivariate] relation. Your example shows a database schema that formally describes topology via CW-complexes. This is "implementation" (also known in religious database community as "physical level"). As you and Norbert have already explained, this topology is considered to be topological datatype on logical level. Then, I don't see how Norbert's topolology - relational algebra dictionary is relevant. For example, to compute natural join of relation FavoriteShapes(person, topology) with ShapeCosts(topology, price) the only thing we care about is identity of topologies. It seems to me that in order to leverage Norbert's topolology - relational algebra dictionary one needs to declare that topological object (topological space) is more general than relation. For example, ordinary [multivariate] relations are some trivial topologies. Next, if we have mixed information in a relation (like in FavoriteShapes), then just by examining the topology we can reconstruct:

1. How many attributes are there
2. What are non-topological attributes
3. What are the values of non-topological attributes