Re: Paper: Database Programming Languages

Jan

> On Wednesday, 4 February 2015 23:27:57 UTC+11, Jan Hidders wrote:
> Op woensdag 4 februari 2015 06:44:36 UTC+1 schreef Derek Asirvadem:

Thank you for your response.

> It's end of my lunch break, and I really need to get back my grading work, so I am going to very aggressively zoom in what I think are the main points. I will also not try to fully explain and answer everything, just on trying to make my position clear.

No problem.

> > ...Context...
 

> Very interesting. Many thanks for that.
>
> > Proper Use of Paper
>
> Hard to be completely certain, but I think the answer is a very strong: No. Unless his project was to write a programming or query language for a similar data model and implementing the type inference mechanism in there. That seems unlikely from your description.

Oh come on. I think I have explained it well enough. And you have not argued with the fact that it, and many papers like it, get used in the theoretical world that uses that model, and that model is implemented classically, in the OO/ORM world. I never said that it was a proper use technically it isn't, but the fact it in the physical universe (a) it if used for the model and (b) the model is implemented. Therefore there is a direct responsibility between the theoreticians who write those papers and the implementation of OO/ORM, the madness that we have to deal with. And (c) they don't give up that madness, because the theoreticians are writing more papers.

If you are saying, you invented a small fold-up camping axe; someone used that axe to commit murder, yes, of course I agree. But it isn't that simple. You have written a paper on how to use that axe to circumvent forensics, the result being that many people are murdering many people, and the murder weapon cannot be found. Therefore, beyond inventing greatly-needed camping axes, to the extent that you subvert the [finding the] truth, you enable murderers. That is what I want to deal with.

I have also tried to make it clear that this is not an attack on you personally. It is an attack on all such papers that support a model that is unscientific, breaks well-known principles, etc. You are just the single one who is courageous enough to (a) deal with it in the physical implementation universe, and (b) have one of you papers used as an example.

> > From reading your paper, I cannot say that he (or the OO/ORM crowd) is using it improperly
>
> "Improperly" does not even come close. :-)

Agreed. Within the context explained previously, and above.

But he already has, it is a done deal. I have to deal with that, because his use of the paper was not questioned. And in the context, I could not identify any improper use. (You have identified it to me now, but even that, does not deny the context.)

> > > > > What matters is, which objective arguments were put forward to support that interpretation and what the evidence for its merit was. Which interpretation leads to the most effective DBMSs [, RDBs] and what scientific evidence is there for this.
> > > >
> > > > Note my insertion.
> > >
> > > Yes, noted. But I disagree with the R there.
> >
> > What, in this day and age, you give assent to a database that is not Relational ?
>
> I don't exclude the future possibility. That is not the same thing.

Ok. I don't think you are splitting hairs. You are saying that you support, the model supports any database, not nec Relational. Even though all the theories and and the implementations post-relational-paradigm have been total failures. Is that correct ?

Note my insertion. I did not remove yours, I added mine, and noted it.

So this might be a great opportunity for you to entire absolve yourself of responsibility. In such papers, you should clearly state two things: a. the model used, that any "database" or data store will do, they are implementation details (which you have done, but not to a clear degree) b. that the paper, the model, is written in ignorance of the RM, of RDBMS, of RDBs.

Otherwise, in this day and age, where there is only one database model (Relational) has exists in terms of any significance (again, HM and NM don't), you run the risk of people (your side as well as implementers) thinking that the model applies to the Relational paradigm. And to let them go on thinking that, if it were not true, is disingenuous. Again, I am attacking the causes, the people who suggest such a model is valid, even if only for contemplation on the dark side of the moon.

> > Meanwhile, back at the farm, you are on record (above) as agreeing with specific scientific and architectural principles that the model breaks.
>
> It doesn't. The paper is talking about a certain data model as a logical data model, not as a physical data model. It has nothing to say about how the data is to be stored or even in what type of database.

(Separate to my notes above, which should be repeated here.)

So it is good for people who don't know the architectural principle, and who use ISAM. Not otherwise. Ok, fine.

So let us limit the issue discussed in your paper as it regards the model, only. It supports the model. The model is bankrupt. All my comments still apply (I went over them):

- you SHOULD know that the model breaks the architectural principle
- you SHOULD know that supporting such a model is anti-science
- you propose yet another fix-up within the model, you give a method
- you SHOULD know that the method breaks the architectural principle
- you SHOULD know that giving such a method is anti-science

What the OO/ORM crowd do with model; how they implement it (RFS, not RDB); in no concern of yours. Fine. They are imbeciles, and they implement that model, your method included. Fine. Billions of dollars wasted, none of those systems work; millions of people waste millions of manhours fixing; improving; up-grading; elevating; inflating such systems, and still none of them work.

But the high end of the market, the 5%, we know that the architectural principle is broken; that the model violates science; and oh, btw we have had RDBs that have no such problems since 1984.

So why do theoreticians in this field exist ? What do they do ? They contribute noything to science; nothing to the Relational paradigm, and any contributions that they do make, is to support the vertical column of pig poop. And even that, they deny responsibility for.

> > Ok, to summarise your paper. In the context of this thread.
> >
> > - it acknowledges and supports the OO/ORM+data store model
>
> No. Only as a logical data model.

Yes. Agreed. And as you know, some people implement that, physically. They rely on the fact that their physical implementation is sound, supported by theories (that are naturally limited to the logical). Only Codd dealt with the physical.

There is a huge danger in reductionism (abstraction). That has been established by greater minds than mine. Maslow and others.

> > - it acknowledges that there are myriad errors in the model
> > ___ that data integrity (the tiny bit that you do understand) is broken
>
> No. It looks at how to reason over types and find inconsistencies in schema specifications. Something that happens in any reasonably expressive data modelling language where you can specify integrity constraints. That does not mean that such a language is broken.

The opposite could be claimed: if your constraint language is so weak that it cannot express inconsistenties as studied here, it is probably too weak.

Hang on. That is correct. My language (IDEF1X plus SQL, which exists, for over thirty years, and can be used for implementation), which you may consider primitive, compared to yours (which does not exist) - expresses all those things: consistencies; inconsistencies __ the capable modeller perceives the missing bits as well, the novice does not

- expresses types; classifications, in a manner, and to greater detail than yours
- ELIMINATES the problem that you have, that you propose a solution for
- a swag of other constraints on data that you people know nothing about (I am mentioning that but not elaborating, in order to avoid exceeding the scope)

Thus our primitive language is far superior to what you are theorising about.

Whatever you guys are theorising about, you should first find out about what the RM, RDBs, SQL actually do, and then theorise about something better. It is extremely moronic to theorise about something than is far less than what we have, what we have had, since 1985.

This is like Darwen's (TweedleDee) Toy Language. He suggests that it "will be" better than SQL, while demonstrating that he is clueless about SQL. He suggests that it is better than the RM, that the RM is "incomplete", while demonstrating that he is clueless about the RM. Oh, wait, he has a 43rd private definition of what the RM is.

> > - fails to mention RDBs; the principle of separating Data vs Program, and then dealing with each separately
>
> It doesn't since those are not relevant for the results presented in the paper.
> It doesn't since RDBs are not relevant for the results presented in the paper.

Accepted. With notation per above.

> It doesn't since [the principle of separating Data vs Program is] not relevant for the results presented in the paper.

Rejected, as detailed above.
Rejected, in the new restricted scope that I have accepted.

> > - the author makes three cardinal errors
>
> The reviewer only one.

Whoa. I am not a reviewer. I have neither the qualification, nor the coverage of that theoretical space. I did not at any time suggest that my comments were a review of any kind, formal or informal. I apologise for any lack of clarity in this regard.

I did take the time to explain the context; you know who I am, a practitioner with a high regard for theory (not camel poop), and a good coverage of the implementation space for that logical model: OO/ORM with out without an RDB; and a reasonably good implementer of the RM, RDBs. That do not break. Due to reliance on science in our field and related sciences.

So, please take all my comments (including my dismissal of such papers) from that position.

Note also that my Response is in two parts. Ch 1 is for managers and auditors. Once the principle is broke, is is unscientific, all else is lost

Ch 2 is for the implementers who needs the whole thing spelled out, and the solution as well.

> He completely misunderstands what the paper is about and its relevance within its scientific context.
>
> I would say normally at this point something like "feel free to ask for more clarification" but I'm not sure if I will find the time to answer. :-(

We are way past that point. It is implemented in the fact that the model is used as is (no significant change) in the OO/ORM world; that they have implemented it, making it physical. That he has implemented a well-known and understood model, correctly. But it is broken.

So, if what you say is correct, then hundreds of OO/ORM proponents; millions of OO/ORM implementers, have done the same thing.

I do not accept the word "scientific" in your sentence. All such papers are un-scientific, for reasons already detailed.

He is not using such papers within the theoretical exploration context, yes. But you cannot deny that such papers are used to validate and justify the classic OO/ORM model, and their implementations. All your mentors, Abiteboul, Hull, Vianu, et al, support the OO/ORM crowd, and do so openly. Just look at this pig poop in ch 3 "Relational Model" and ch 11/Translating to RM in the Alice book: those are serious attacks against the RM, and constructed on a fraudulent basis.

> > I can't give you the whole Response, but I can obtain permission and provide a couple of the key pages from it, particularly those with the diagrams that explain the Solution.
>
> I don't think that's necessary. I'm guessing something like a rewrite of the schema where all class combinations are made explicit.

Definitely not. That would make the same mistake of using the broken model to fix the broken model. That would also validate the fiction that it is a class combination issue, as well as create masses of rows to make the combinations explicit.

> > But first, I hope you don't mind me asking, please confirm that you can /read/ standard IDEF1X data models that we have been using since 1985, and UML classifiers. I am shocked to find out, as evidenced in the Normalisation thread, that many (all ?) theoreticians cannot do that, eg. they cannot read the predicates or the constraints that are in diagrammatic notation, and ask for them to be spelled out in text form.
>
> I don't think that's what they were doing,

Well, they said the words:
> > dependencies haven't been stated
> > Assuming certain external predicates [ie. implying they have not been given]
> > your drawing of boxes and lines

Maybe the English in Belgium has been redefined.

> > unskilled people present a drawing of boxes

Clearly the beast has not recognised an IDEF1X model, despite the fact that that is expressly stated in the OP. Despite the fact that any donkey can google and get a bit of understanding re the boxes and squiggles. Despite the fact that my 6-page Introduction comes up in the top five.

Anyway, I must acknowledge the powers you have to know what people who state they can't read the notation were doing, because it is certainly beyond me.

> but yes, I can read IDEF11X and UML Class diagrams. Even taught them for a while to

So you are clear on _not only_ the visual difference between: - solid and dashed lines
- square and round corners
but on the consequences, the ramifications, the consequences ? Ala the "expressiveness" in the non-existent theoretical languages, that exist in the primitive languages ?

And you will *not* /read/ anything in the model that is not in the model ? In the Address A model which does not have "candidate keys", you perceived such. Indeed, your intuition correctly picked up one of the *missing* constraints, due specifically to the *expressiveness*.

While I cover the OO side quite nicely (I dictate standards) and I lead teams (but we use 4GLs that generate objects, we do not actually write objects, same as we do not actually write SQL), I do not profess to be a specialist in UML notation. As you will know, since you are teaching it, it is not a standard by any stretch of the imagination, it cannot be used for verification of the completeness of the model, let alone verification of the model (both of which we can do in IDEF1X). Everyone adds and drops whatever they want. There is one symbol and it is used, misused, and abused, for everything. Most of the other symbols and notation is lost. Therefore, while I do draw UML diagrams (as distinct from erecting IDEF1X models), I am not a UML Notation specialist, I would ask that you forgive my mistakes.

> give my student some feeling of how the different notations work and what their differences are.

Ugh!

The OO/ORM crowd make many mistakes. But if you ask me to name one, the most serious mistake, that has the most negative consequences, I would say, failure to observe the scientific and architectural principle of separation of Data vs Program. Sure, we are naming that on this thread, but we are dealing with only one of the consequences, and there are many. Here is another. The consequence of NOT observing that principle means they view Data and Program together, they make mashed potatoes with minced meat, instead or french fries and roast beef. And then they have all sorts of problems separating the bits of meat from the mash, because half the time, they need EITHER meat XOR potatoes. And their controls on their mince-and-mash objects start to fail after two level of inheritance, therefore that model too, is broken.

Here you have hit another consequence. The OO/ORM crowd, due to NOT observing said principle, PERCEIVE data and program as the same. Thus their Analysis, Design, Modelling, and Implementation of Data is severely limited. They perceive data through the lens of OO. So at the minimum, their A, D, M, I of data is severely handicapped. The dotted vs solid lines; the square vs round corners, not only have meaning, they have serious ramifications. Further, UML is nowhere near as rich as IDEF1X in terms of expressiveness or precision, so whatever is drawn in UML re Data, is even less classified. Those are Crimes of commission.

Separately, they commit crimes of Omission. Eg. NOT perceiving Data as Data, and treating it with the separate A, D, M, I methods that pertain to Data.

Absence of an understanding of, an appreciation of, the Relational Model (not a pick-and-choose list, not the "rm" of the theoreticians) means that one will not, can not understand the relevance of many of the _concepts_ in IDEF1X. And thus one cannot A, D, M, I according to the RM. Thus any A, D, M, I that they do is devoid of the Relational Integrity, Power, Speed that is given in the RM.

Therefore, UML-for-data-objects and IDEF1X for Data are not comparable, they are worlds apart. I don't see how one can teach them together or compare them for differences. Especially not, if the RM is not taught first. Or stated otherwise, the only place where such a comparison can be had, is in the invalid place of denial of the principle *and* denial of the RM.

Think about i. Half the problems that manifest in every UML-only implementation are wiped out if they use an RDB. As this sub-thread is going to demonstrate.

So you ask me, ok, Derek, what the frog would you teach. 1 The principle re Data vs Process, its relevance, danger of ignoring it. 2 For Data, the RM, the whole RM, and nothing but the RM 2.1 IDEF1X as the standard for modelling Relational databases 3 For Program components, the principles of programming; process flow; data flow; decomposition as a modelling method 3.1 SSADM for simple projects or IDEF0 for complex projects 3.2 UML for program objects, classifiers, etc

Importantly, [3.1] addresses decomposition; genuine modelling and progression; both data and process flows, something UML does not cover; doesn't have the methods or the notation for.

I have four tools in my tool kit. Not one Hammer.

And if we do go down this path, it is NOT on the basis of proving your paper wrong, etc.

As per this thread, as stated in this sub-thread, it IS on the basis of proving that in any logical or physical context (the paper is simply one example of hundreds):

• ignorance of or rebellion against the architectural principle of separation of /Data/ and /Process/, will kill your model, project, system, career
• any proposals based on such absence can be dismissed, such as our TeamLeader's; the classic OO/ORM model
• re the modelling of a database of any kind, ignorance of or rebellion against the Relational Model and the Standard for Modelling Relational Databases (IDEF1X) will place such a database at the theoretical, logical, and physical level of pre-1970 theory (ISAM, HM, NM) and pre-1985 modelling methods
• re the implementation of a database of any kind, ignorance of or rebellion against the Relational Model (and secondly, in its fullness as implemented by the commercial vendors, but we will exclude that on c_d_t, because we are still getting to the unexpurgated RM), will place such a database at the theoretical, logical, and physical level of pre-1960 Record Filing Systems (ie. ISAM. HM in the 60's, and HM and NM in the 70's and 80's were far more advanced)

(
___ only because the self-importance of theoreticians in this space need to be acknowledged, since they have developed nothing useable or implemented (in successful systems) since 1970, whatever they are theorising about, can be safely ignored. I won't belabour the fact that that content is actually damaging to standards, science, success, that is been exposed, slowly, in these threads.

___ and the corollary, since the only things the theoreticians have produced have been used by naïve implementers, who themselves ignore or rebel against science, and since all such systems are failures, disasters, train wrecks, the theoreticians can only produce train wrecks. )

Do feel free to change that pathetic state of affairs.

Cheers
Derek Received on Thu Feb 05 2015 - 09:05:25 CET