Re: A Topological Relational Algebra in Lisp

From: Derek Asirvadem <derek.asirvadem_at_gmail.com>
Date: Tue, 27 Jan 2015 17:48:31 -0800 (PST)
Message-ID: <6badb573-1abb-48ab-9801-f2999ed20e4f_at_googlegroups.com>

Norbert

Following Tegiri's hint, I went back and re-read your previous posts. I have deleted my previous post, this is the revised version.

> On Saturday, 24 January 2015 09:38:03 UTC+11, Tegiri Nenashi wrote:

(Tegiri: I am getting value from your posts, so please do not take my comments as subtracting from that.)

> 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.

Definitely.

> Please note how intuitive for a lay person

Lay person ??? Is mathematics a religious affair ? Maybe that is why they think they are different from the rest of us ! Maybe that is why there is a chasm between mathematicians and the real world !!

Well, God already has me, and I am Commanded against idolatry, I am happy to be a "lay person" in the context of the god of mathematics. You guys can spend your time inventing mathematical poofs to lay at his feet or hooves or whatever !

> 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)

Agreed. That was the point of Codd's work, to make the database accessible to users.

Considering:
> > On Wednesday, 21 January 2015 00:06:46 UTC+11, Derek Asirvadem wrote:
> > Claim
> > ii. Until 1985, the marks defining the "relations" were ASCII characters, and the statements were SQL DDL. That engages 4% of ones brain. Determination of whether such "relations" are Relational or not, and indeed whether the database as a whole is Relational or not, can now be made. Engaging the same 4% of the brain. Time-consuming and prone to error.
>
> The claim can now (at [ii] ) be confirmed, with some difficulty.

Stanford's claim that the relations in the example are Relational, can be determined, and confirmed, easily:

a. They use names, not letters, for their relations and attributes
b. They give the keys
c. The keys are not IDs 

(which means record numbers, not rows, and the RM demands that "keys are made up from the data", which means IDs are prohibited. Further, the main different between Relational data and Record filing systems, is that they are related by Key vs related by record ID.) d. One parent relation is missing, but it is easily identified: ____Pizzeria(pizzeria) (pizzeria) is a key While that is fine for a classroom exercise, outside a class, it is not. e. Not only are the given relations Relational, they are all base relations. Therefore the class can progress without hindrance. (In the great majority of papers written by mathematicians, they confuse base relations and derived relations. Sometimes without realising it, and other times, in order to erect a Straw Man argument.)

> I hope this exhaustive exapmple helps to understand my approach.

No, it did not.

Many mathematicians make this mistake.

At this moment, I have two papers on my desk that are awaiting approval/rejection from a customer, written by well-established mathematicians (one who is a correspondent here), and they are both raised by an OO development team leader, to support his notion that the data & referential integrity problems that plague the customer's app plus record filing system can be corrected by further definitions, typing, classifiers, etc. Obviously that is false, and it is simply a continuation of the same promises that have been made for three years, none of which have been delivered. Except that this time, he has a few academic papers to support his promises. His credibility is long gone, and the app+RFS is going to be replaced by an RDB + app, which is why I was hired.

The papers are not science, therefore pointing out the errors and dismissing them is not difficult, but it is time-consuming, since I have to address the construction of the argument before stitching up in the proposal.

Back to you. The common mistake in such papers, and in your long post, is this. You focus on the data content, one the different "relations". Instead of on the relation definitions.

I am not sure, but I have a good idea that mathematicians, especially the ones who provide partial UML diagrams, think of the relations through the lens of the objects (classes, classifiers, inheritance) that they have coded or planned. And that causes your perception of the data, as data, minus the objects, to be severely limited. The perception is data-the-way-it-looks (note the content of your post), as opposed to the definition of relations; what relations each relation is related to; dependent on; etc.

So please, do not type so much examples, it does not increase the understanding of the data in people who do not know the data. Give us definitions. Standard-compliant definitions (iii) are preferred, but simple text defns (ii) will be quite acceptable.

--

Stanford definitions.  I realise that at this stage, all your relations are in fact records, not relations (they fail on (a) and (b)).  Which has to be corrected in your next rendition of the paper, before you can make the claim.

But we can set that aside, on the basis that you have backed off from the claim, and try to understand the relations-as-intended, so that we can understand your papers, your topological spaces and the topological queries that you have constructed.  Only if you give us relation definitions.

Your descriptions fail massively on (e).  But that is the gap that has to be worked out before you can realise any implementation.  What you and Tegiri have stated is "a lot of work to be done" is a small effort for me to do.  Once I understand you.

<Retracted>

If I have a somewhat correct understanding of [1] and [2] ...


> for (D,T(RD)). The labels "interior" and "boundary" denote, how a tuple in D


> references two tuples in D.


No.

a. The labels are RoleNames, as defined in the RM.

b. The RoleNames give meaning to the left and right side of the two FK references in the record, and differentiate each from the other.

c.  Since each RD record is, well, one RD record, they do not denote how one tuple references two tuples.  
- In each record, there are two references.
- Each reference is one fact, one discrete relationship, to one parent record
- A relationship definition is a two-way street (two derived facts) but a single definition (if Fred is Sally's father, then I know that Sally is Fred's daughter, I don't need a second relationship to tell me that the first relationship backwards is a fact)
- If you are talking about the record in Detail, then there are two separate relationships, *each* to *way more* than one record in R(Detail). ("Two" is incorrect)
--- If you mean that for any given Detail, one particular relationship (Interior or Boundary) there are at most 2 records in R(Detail), then you must state that, as a constraint.  If it is not stated, then the cardinality is 1:0-n.
- If you are talking about the record in R(Detail), then one record in R(Detail) (not Detail) relates to one record in Detail (via Interior) and relates to one record in Detail (via Boundary), which may or may not be the same Detail-record.

In OO/UML terms, sure, Detail (or Sketch) is an aggregator.  So what.  In your intended-relational terms, Detail is the parent relation, R(Detail) is the child relation.  In a Relational Database, aggregation can occur at *any* level in the data hierarchy, for *any* descendent, it is pedestrian.  The great-grand-father can aggregate the children; the grand-children; the great-grand-children. Effortlessly.

6.
I don't need the data content for natural joins or projections (but don't allow me stop you).  I am pretty sure I know what a projection is.  I need the projection and its purpose, what it means (hopefully in terms of spaces; boundaries; interiors; exteriors), to be explained, in one or two English sentences.

For continuations and topology generation, I think the data content is relevant, but only if the above is resolved and understood first.

Cheers
Derek

Received on Wed Jan 28 2015 - 02:48:31 CET