References & Restatement

James
Jan

> On Thursday, 29 January 2015 13:09:08 UTC+11, James K. Lowden wrote:
> On Wed, 28 Jan 2015 01:52:59 -0800 (PST)
> Derek Asirvadem <derek.asirvadem_at_gmail.com> wrote:

> > A. ____the Hierarchical Model rests on a theoretical void____

> > B. ____the HM is dead, it has no relevance wrt the Relational Model___

> > F. The implication here, and in many other places, is that you know the Relational Model, and you know it well.

> > I declare, the Relational Model is not a replacement for, or a
> > substitution for the Hierarchical Model; it is a progression of it.
>
> Evidence, please. I can think of no way in which the hierarchical
> model informs the relational model except as antithesis. Codd
> contrasted the RM with "noninferential systems", which hardly
> sounds like a source of inspiration.

(Not avoiding this point, tomorrow, please.)

Tomorrow is here, after some delay.

I would like to make sure that we do not waste time with silly arguments, I have more respect for you than that. Last year, someone here got into such an argument with me, after I stated that SQL was the manifest language of the data sub-language that Codd defined in the RM. He had a mathematical proof that it was not (same as your demand for truth tables in the Null problem thread one year ago), and of course that was in denial of the historical facts. The issue on my side was simple: unless one is in a pathological state of denial, the father can be recognised, easily, by virtue of the unique characteristics of the father, in the son. Whether the son carries the father's name, or disowns the father, or the certificate of birth is lost, etc does not matter.

Codd is unarguably the father of the one-and-only data sub-language, from which SQL is directly derived. Separately, by route of the sequence of historical facts (System/R, SEQUEL, SQL), Codd is the grandfather of SQL itself. To deny this, separate to denying Codd his due, is to deny historical facts, and to deny the unique characteristics of the father that are evident in the son.

Third, there is one, and only one son (SQL), and one, and only one, definition of a data sub-language (Codd's), that the son can lay claim to being the manifestation of.

That is not to say that Codd was happy with his grandson, or that he agreed with the way he had turned ou (IBM and the teams had their politics). Any negative comments from Codd (such as you posted) have to be viewed with the eyes wide open.

Likewise re Hierarchies. Much as you hate them. The HM exists in the RM, by virtue of the unique characteristics of the father in the son.

Now the thread has progressed, and you have split the HM /as I first stated/ into two pieces: hierarchies in general as they may exist in the data; and the HM as a model. Personally, I think the difference is trivial, not material to the thread, but as stated previously, I am willing to allow the split since it is important to you. In which case, I need to restate my declaration.

I think we all agree that the HM, as an implementation, died in 1984, when the RM became available as an implementation platform. So we are not talking about the HM living in the RM as an implementation method, or a data storage method. Whatever form it lives as, in the RM, the implementation method is RM.

I think we have cleared up the issue that it does or does not have a paper supporting it (and that it is silly to expect one), before accepting it as a model, because in those days everything was proprietary, the HM was the only kid on the block, and it was widely known and well-understood as a model. Even today it is well-understood, but very few will remember the [much simpler] modelling methods or the symbols.

Note that in the RM, more than half of Codd's references are to products and product manuals. There were not too many theoretical papers in the field.

So we are talking about its spirit, its philosophy, its design elements. In the logical sense, since the RM is mostly logical, and in the resultant physical sense, because that is not denied (the physical is a result of the logical, not isolated from the logical). Ie. Codd does give logical implementation prescriptions and prohibitions, and concerns himself with the physical, without giving prescriptions. Eg. Access Path Dependence is prohibited, we all know what that means, it is primarily logical, and of course, when implemented it is physical. Therefore I think we should not argue that the HM lives in the RM in a physical form or not, or that since we cannot see the physical HM in the RM, it means that it doesn't esixt in the RM.

Last, in attempting to answer your request, I started typing up a justification, but that will be nothing short of a full exposition of the specific parts of the RM that relate to the HM. Very long. Open to argument. So I think the best thing to do is you give you the specific references to the HM in the RM, and have you confirm or deny that. Then I can respond to just those points. And I am quite aware, that due to the blind spot you have, denial of the HM, and the HM in the RM, the discussion might be quite short and sweet.

References. So the first preference I would say, is to read chapter one of the RM, with this thread, what I have said in mind, and come to your own NEW conclusions. Specifically

- [1.4] Normal Form
- You need to understand the manner he uses to construct keys, "simple" and "non-simple domain", so the preceding sections
- special attention to the pre-requisites

There are many terms that Codd uses in the RM, which have gone out of fashion. I don't know which ones you know or don't know. Please feel free to ask me, and I will explain. There seems to be a bit of confusion over a couple of terms, so I will give them first. deductive question-answering system = Decision Support System; Online Analytical Processing Inferential system = DSS/OLAP
non-deductive system = Online Transaction Processing non-inferential system = OLTP
graph = tree
tree = Hierarchy (graph) [13]
graph model = Hierarchical Model

Tree/Hierarchy
As you know, Normalisation was well and truly established, although we did not have titled "normal forms" until Codd declared them, first in the RM, and later with 1NF, 2NF, and 3NF. Therefore, when he gives the pre-requisties to his __Relational Normal Form__ [1.4](1)(2), and in (1) states "collections of trees", we take that to mean:

- trees with integrity
- normalised to the extent that we did prior to the RM
- no circular references
- what I am calling, in retrospect __Hierarchical Normal Form__

In the alternative, trees without integrity, with circular references, would fail the requirements and directions given on that entire page. That is further evidence that he meant trees with integrity. I am sure you will understand the ramifications of circular references, it is the same with recursion: an infinite loop. Deadly, and career suicide.

Note that he emphasises the relevance of the pre-requisites and the implied integrity with "The writer knows of no application which would require any relaxation of these conditions." The conditions are onerous, otherwise relaxation need not be mentioned.

Restatement

Given the content of previous discussions, a short restatement of my position re the HM and its relevance to the RM is in order. I am saying the HM lives in the RM:

- as a concept
- a previously well-known model, method, of organising data
- that is explicitly referenced, and used by Codd in the RM,  throughout the paper
- if one implements data according to the _Relational Normal Form_ given, for which explicit steps are given, this leads to Relational Keys, which are compound keys ("non-simple")
- such keys, in the context of the series of tables in which each and all of those components ("simple" as well as all subsets of the "non-simple") are used, will form an hierarchy
- the set of such table form an hierarchy
- such keys may well be called Hierarchical Keys

The corollary is:
- where one fails to implement Relational Keys as they naturally occur in the data, the value, speed, and Relational power (independent join power) that exists in the Hierarchy (whence they came) is lost

Unfortunately, during the intervening forty five years, while the theoreticians have invented all sorts of "normal forms" to suit non-relational purposes, they have been staggeringly unable to define the two Normal Forms that are /informally/ defined in the RM, /formally/.

In the middle of section [1.4] Normal Form, Codd gives an example of a tree (hierarchy) in fig 3(a). In case you are interested, I have a page that shows the HM, the hierarchical file structure, and the transformation according to Codd's instructions. Please ask.

> I think you will recognize this, from the abstract:
>
> "Existing noninferential, formatted data systems provide users
> with tree-structured files or slightly more general network models of
> the data. In Section 1, inadequacies of these models are discussed."

Accepted, that the RM succeeded the HM, that it was inadequate.

That says precisely nothing about whether the hierarchy is a valid structure for data. The big difference between pre-relational and relational, as you well know, it reference-by-key over reference-by-pointer. We had references and cross-references in those pre-relational days, we just did not have keys as pointers.

Further At no point does Codd state that the hierarchy of the data itself (ie. other than the pointer-based storage and access path dependence) is in adequate or should be replaced.

And finally, the method he gives for the __Relational Normal Form__ uses a data hierarchy, and he transforms that hierarchy of data into Relational form (array, matrix, table), keeping that hierarchy of data intact.

> I can think of no way in which the hierarchical
> model informs the relational model except as antithesis.

I didn't say "informs". I said the RM is a progression of the HM. The evidence is in the paper, just that one page. To the degree that one understands Codd's numerous references to the hierarchy ("tree"), one can ascertain how much it "informed" Codd.

To the extent that any hierarchy that exists in the data, is maintained as an hierarchy, after transformation to the Relational Model, the hierarchy lives, exists, breathes (normally, not zombie-like), in the RM, and therefore to this day.

Antithesis. Proved false.

Thesis. Proved.

No one said thesis = 100%. Life is not a simplistic black-or-white issue. If I was asked, just how much the HM influenced the RM, I would take the time to enumerate the RM, and notice its features, I wouldn't put a number to it right now. That the HM is in the RM, as detailed in my restatement, in unarguable, irrefutable.

Cheers
Derek Received on Tue Feb 03 2015 - 10:22:25 CET