Re: A Topological Relational Algebra in Lisp
Date: Sun, 25 Jan 2015 12:14:33 -0800 (PST)
Message-ID: <9303cf10-66e0-4a64-a3a3-9dc5bf3c1844_at_googlegroups.com>
Norbert
> 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 has is why they think they are different from the rest of us ! Maybe that is why there is a gap or chasm between mathematicians and the real world !
> 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 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.)
> May I ask you to revisit the example?
Me too.
>
> On Sunday, 25 January 2015 21:30:29 UTC+11, Norbert_Paul wrote:
>
<snip>
> 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. 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.
-- I realise that at this stage, all your relations are in fact records, not relations (they fail on (c) ). 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. -- There is more confusion, for me, in your latest post. 1.Received on Sun Jan 25 2015 - 21:14:33 CET
> Assume that there are two topological spaces (S,T(RS)) and (D,T(RD)) represented
> by the four relations
>
> S = sid detail
> ---------------
> int1 interior
> door xdoor
> garden exterior
I take that to mean that you have a relation: ____Space( sid, detail ) and from the attribute names: ____Space( sid{int}, detail{str} ) or ____Space( sid: int, detail: str ) Is that correct ? If so, how can sid = { intl, door, garden } ? Now, if I stretch, if I try something counter-intuitive, I can see that maybe sid could mean a Space Identifier that is str, not int. Which means "sid" is an unacceptable attribute name, because xxxxID is used by virtually everyone to means xxxx record ID. That (and it happens in every record) interferes with understanding the rest of the exhaustive post. As well, my counter-intuitive assumption may be incorrect, which means something else is wrong. If I revert to your papers that are in German, from memory, it is possible you mean: ____Space( Designator{str}, Description{str} ) Is that correct ? 2. Assuming that my understanding of [1] is slightly correct, that I have the direction, although not the definition.
> <---interior--->|<----boudary--->
> RS = isid idetail - bdsid bddetail
Is this what you are trying to say: record RS (or intended relation RS) is a child of Space() ? With two relationships from Space() ? One for Interior and a second for Boundary ? Two FKs in RS referencing the PK in Space() ? If that is correct ... Ok, so we overlook the terse attribute names, as discussed in [1]. ____isid is probably [Space]Designator_Interior ____bdsid is probably [Space]Designator_Boundary Is that correct ? If so, then what the !$&%$ hell is attribute idetail and attribute bddetail doing in that record (relation) ??? They are duplicated, they already exist in Space() !!! a. if they are duplicated, then they fail as relations of a separate reason: they are not Normalised. We cannot be expected to understand relations that are not Normalised. b. if they are *not* duplicated, then you must be trying to show us your notion of the RS record (relation). Which means you are making the *second* most common error that mathematicians make in their papers: they confuse base relations and derived relations. In this case the record is: ____RS( Designator_Interior(FK) , Designator_Boundary(FK) ) and the relationships cannot be reasonably shown (or modelled, or understood) without a diagram: http://www.softwaregems.com.au/Documents/Student%20Resolutions/Norbert%20Paul/TDAS%20Note%20p3.pdf Does that make sense to you ? Ok, that leads to: c. Is Space the Topological Space, a complex thing ? Eg. "intl" ? d. Is Element the simple things that Space is made up of, defined by, defined in terms of ? Eg. "intl, interior" ? e. Elements have Boundaries ? f. Spaces do not have Boundaries (Elements do) ? g. An Element-Boundary is also an Element ? h. An Element cannot have a Boundary that is itself ? i. Spaces have Boundaries (Elements do not) ? j. Some Elements are Boundary Elements (others are not) ? 3. 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 definition 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 D, then there are two separate relationships, *each* to *way more* than one record in RD. ("Two" is incorrect) --- If you mean that for any given D, one one particular relationship (Interior or Boundary) there are at most 2 records in RD, 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 RD, then one record in RD (not D) relates to one record in D (via Interior) and relates to one record in D (via Boundary), which may or may not be the same D-record. In OO/UML terms, sure, D is an aggregator. So what. In intended-relational terms, D is the parent relation, RD 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. 4. In English, in one or two words, what exactly is the designator for: ____D ____RS ____RD ? Not at all sure, but it is possible RS might be SpaceBoundary. If that is correct, then __the Interior Space( "intl" ) has SpaceBoundary( "door" ) makes sense but the second record (your "two tuples") is missing from the example data and __the Interior Space( "garden" ) has SpaceBoundary( "door" ) does not make sesne Please explain. Notice, in the predicates above, I have used all the elements that have been ascertained thus far, and strung them together as per the RM, as articulated in IDEF1X. That, is one of its explicit purposes: to make sense of the model. 5. S appears to be identical in definition to D RS appears to be identical in definition to RD Why are S & D not the same Space ? Why are RS & RD not the same Thing (SpaceBoundary) ? 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. -- Other I realise there *is* a gap between content of my posts, and where you sit. I do not know the size of that gap. I can fill it in, except that I don't know *what* the gap is. It would help me, if you asked a question. Cheers Derek