Re: Hierarchical Model and its Relevance in the Relational Model

Op zondag 1 februari 2015 06:33:40 UTC+1 schreef Derek Asirvadem:
> Jan
>
> > On Sunday, 1 February 2015 05:07:34 UTC+11, Jan Hidders wrote:
>
> No worries. Take your time. I am happy to wait for the long, considered response. I would like the thread to progress to completion, with considered responses all the way through.
>
> > 1. You don't need my permission to discuss one of my papers here, but if you would like my explicit permission, then you have it now.
>
> I know that. It was a matter of courtesy. Some people may not appreciate having their papers discussed in open forum.

Ok. The courtesy is appreciated.

> > I would btw. be very curious to know what conclusions your client would think he or she could draw from them.
>
> Since I have already given you a synopsis, a short chronology, I am not sure what you mean. Would you like a more complete one ?

More detail, as in where the devil lives. Because I suspect more is concluded from the paper then is actually warranted and meant by the author. But if we get to that later, that's fine.

> I suspect you and I are not on the same page on this one. So let me clarify, and ask for a clarification.
>
> Now in this thread you have stated:
>
> > > But most /now/ understand the relevance of data independence.
>
> (My emphasis.)
>
> To which I replied:
>
> > I suppose I have to trust that you mean that in the fullness of the data integrity as prescribed in the RM.
>
> Which you have not confirmed or denied. Which means, I still do not know the /extent/ to which you understand "data independence", and how it is administered.

Administered? That seems a strange word to use here. I'm also not sure what you meant by "in the fullness of" here, so that makes it a bit hard to answer. Am I aware how current DBMSs realise (to some extent) data independence? Yes, I am. Am I aware of the available techniques that are not yet implemented? Yes. I Am. Am I aware that under certain approaches there is a trade-off between the extent of data independence and complexity of integrity checking? Yes, I am. Not sure if that answered your question, but that's the best I can come up with at the moment.

> So the clarification begs. The paper is Database Programming Languages, 1995. Are you aware:

Yikes! My very first paper that I wrote as a beginning PhD student! :-) Ok. This is going to be interesting.

> 1. That, on the face of it, your statement above, contradicts, or let's say unofficially retracts, the main thrust, the solution given, in your 1995 paper ?
> __ (which is why I stated "... the papers have not been retracted, all we have is a statement from the author in an unrelated post on c_d_t stating that "most /now/ understand the relevance of data independence.")
>
> Or, do you stand, on that paper, now ?

I'm not sure which statement you mean, but I don't think I've said anything that strongly contradicts the results and assumptions in this paper. I'm also not sure what you mean by "presenting a solution" here. The paper does not introduce a new model, it studies an existing one and focuses on reasoning over union types within that model. But the results actually carry over into other data models.

You might mean that by studying that data model the paper implicitly gives a vote of approval to it. Do I still stand by that vote? Mostly yes, but these days I tend to think that simpeler graph-based models (but with mechanisms to model nested values) would be more useful and effective.

> 2. Of the Architectural Principle, established as science in our field, that Data must be separated from Process ?
> __ (And it follows that there are separate and different methods for Analysing & Designing the two, etc, etc.)
> __ It is clearly established in the industry, that implementers are specialists in either the /Data Space/ xor the /Program Space/ (those who cover both are few, and exceptional).

I am aware of that, but not sure why you think this is relevant for the paper.

Btw. when you say "science" I have the impression you actually mean "engineering".

> 3. That [2] existed, as science, before Codd, 1970, the RM ?
> __ (That it has been furthered ever since then, and rendered for whatever context one uses (eg. a RDB; an awk script). That it (as with everything in science) has only gotten stronger as an Architectural Principle, and applicable in more contexts.

That engineering principle has a long and venerable tradition, yes.

> 4. That in his paper, the RM, in 1970, Codd gave specific /further/ prescriptions and prohibitions re "data independence", without having to explain what "data independence" meant, because it was well-known ?
> __ Which resulted in implementation of those concepts in the commercial RDBMS platforms, as well as in the implementations of RBDs.

To some extent. From my colleagues who were around at the time I know that the concept already existed, but not everybody understood it in the same way.

> 5. The result being, that 100% of all controls upon data should be deployed in the RDB ?
> __ (As I am sure you know, DKNF alludes to this. We implement a much fuller form, as standard practice.)

Not sure why you drag poor little DKNF into this, since that only deals with a very small part of this, but, yes.

 > 6. The corollary being, that controls on the data should not be deployed in the /Program Space/. Eg. OO Objects or classifiers ?
> __ And if it is deployed there, (a) it will never be adequate, or (b) as complete, as a deployement in the /Data Space/. Something that has been painfully proved in millions of OO-centric implementations.

Definitely, yes.

[... big snip ..]

> > To be honest, although I have opinions on these issues, I find such discussions unscientific and without any merit, even if it is about how Codd himself meant his model to be understood. It is akin to the argument by authority, which is a very weak type of argument.
>
> Per details above, I do not expect that type of argument.
>
> We do need to take Codd as the authority. Otherwise we can pack our bags and go home.

Quite the contrary. Codd's contributions were fantastic, some of them anyway, but it is by no means the last word on these matters, if only because technology and insight has progressed since then.

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

> Yes, all very good points. But I think even that /could/ be avoided, or let's say, easily stated and closed: the /commercial/ vendors have already done that work; the high-end implementers implement it. Something that the theoreticians do not seem to be able to comprehend. they are about thirty years behind the industry that they theorise for. You will of course, have to accept evidenced reality as scientific evidence, not papers by theoreticians who have already established themselves as un-scientific. Mathematical proofs alone are pure garbage.

Mathematical proofs can only proof mathematical facts, not whether a certain model is practical or not, although certain results can give some support. There the proof is really in the eating of the pudding. Any other position would be unscientific.

> Actually, if you excised the mathematical proofs from your papers, it would increase their credibility. Because the mathematical proofs have been proven false in the course of time, or were false from the beginning due to their contradicting other sciences.

Mathematical proofs can only be proven false by mathematics. But perhaps you mean that the underlying assumptions about how the models and assumptions are relevant in the real world might be shown to be incorrect by other sciences. Yes, that can happen. Has this happened in this case? I don't think so. The different OO data models have mostly fallen out of favour for non-technical reasons.

• Jan Hidders