Re: References & Restatement

James

> On Wednesday, 4 February 2015 16:45:27 UTC+11, James K. Lowden wrote:
> On Tue, 3 Feb 2015 06:42:11 -0800 (PST) Derek Asirvadem <derek.asirvadem_at_gmail.com> wrote:

Thank you for your response.

I was preparing one for you, but I ran out of time, Fri is chockers for me, the weekend dawns, your post will be left unanswered for a long time ... so I am going to take a different approach, taking into account that you may have a bit of time on the weekend as well.

The bottom line re my perception of your position is this. You have moved from "there is nothing from the hierarchies/HM in the RM" to "holy cow, there is something of hierarchies/HM in the RM". If it need be said, I am not trying to convert you (eg. to "the hierarchies/HM lives in the RM"), but given that I happen to be the one who has the pleasure of introducing this subject to your (and it is a big subject, with many ramifications and consequences), then it is my job to transmit the subject and to transmit it intact, not in pieces. Intact, over the next year, (a) you will not lose it, and (b) you will perceive more, and get more out of it. If all you have is one big chunk, over the next year, it will go back to zero.

It took me two projects, probably three years, to get the full quid, all the ramifications and consequences, to obtain the full Integrity, Power, and Speed from the RM. I had to read the RM probably four times, and each time, I got more out of it, and implemented one more increment of it. I have the experience of decades. For you, you are fighting (mentally) what has been drummed into you, what you believe from your teachers, ala HM is hopeless, no value; there is nothing hierarchical about the RM. So it is a huge step that you have crossed the line (but you have not accepted the full core), and I acknowledge you for that.

Yes, terms are very important, and private definitions, or thinking the other person means something other than the word he is using, damages communication.

- When I say "Hierarchy" I mean the English word, to its full meaning, and its additional meaning in the computer software industry.
- When I say "Hierarchical Model" I mean the very real thing that existed 1960 to 1984, as implemented by IBM/IMS, philosophically; theoretically; logically; physically.  Logically and physically means the storage and Access Path are Dependent.
- Of course when I compare "Hierarchical Model" to something else, eg. the RM, or apply the concept to a set of tables implemented in an RDBMS, the physical part does not apply, the physical part that does apply is the RM (logically, first) and the particular storage methods available in the particular RDBMS.

To wit, when I said "Hierarchy", up to now (including your last post) you have taken that to mean "Hierarchical storage", and that is not correct, I meant "Hierarchy".

1. Therefore, you may wish to re-read my last couple of posts on the subject, with that in mind, if you do, you will get more meaning out of them, and I won't have to post detailed explanations. I am identifying this as an option, not necessarily a recommendation.
2. Therefore, if you have times before Mon, when I next expect to post, I recommend that you read those same sections of the RM again, (1.4) plus preceding, with the following in mind. And with the the following notes, side by side.
3. Are you clear that Codd's "non-simple" means a Repeating Group. What you might call a nested set or nested relation. What would be implemented Relationally as a child table ?
4. Are you aware that Codd uses the word "Domain", beyond the way it is currently understood. Ie. it applies, each and every time (he uses it in many contexts), to each context, and fully ?
5. There is no Fig (3). There are two figures, Fig 3(a) and 3(b). Fig 3(a) has a top and bottom half.
6. When you get to [1.4 Normal Form, para 2], please see if this diagram explains Codd's Fig 3(a). They could not insert diagrams that were created outside the publishing house in publications in 1970, ie. the author's. This is my understanding of what Codd wishes to communicate. http://www.softwaregems.com.au/Documents/Article/Normalisation/RM%20Foo%203_A_Top.pdf
7. When you read anything and everything that Codd has to say about the limitations of the HM, please see if this diagram helps. It is an overview, depicting the salient aspects that Codd raises. Note that it is not detailed enough to show the storage issue (which I believe you understand) to the full extent of its agony. Please ask, if you want that. http://www.softwaregems.com.au/Documents/Article/Normalisation/RM%20Foo%203_A.pdf
8. Then read and understand all of Codd's material in [1.4] plus surrounds.
9. IFF you are happy with all the above [a] through [f], AND you have gotten more out of reading the RM with these in mind, THEN and only then, please examine this doc. It is the tables that anyone who accepts the RM, without hindrances such as a blind spot re Hierarchies, would have created, directly from Codd's [1.4 Normal Form] METHOD, from para 1, to the words "R(g).r.d". Nothing more, nothing less. No contemporaneous understanding required. I would call that which he has given __Relational_Normal_Form__

Codd gives the Keys in Fig 3(b), they are in italics, the non-key attributes are not in italics.

http://www.softwaregems.com.au/Documents/Article/Normalisation/RM%20Foo%203_B.pdf

It is given in response to your:
> If that kind of access is possible, in what sense do the four tables
> form a hierarchy? Are we to say they have "hierarchical keys" simply
> because employee->jobhistory->salaryhistory are related through their
> foreign keys?

The solid vs dashed lines; the square vs round corners, have (a) specific meaning, and (b) a slew of ramifications. If you are not familiar, really familiar with what that means, please check: http://www.softwaregems.com.au/Documents/Documentary%20Examples/IDEF1X%20Introduction.pdf

I am not plugging "Hierarchical Key". I accept that "Relational Key" is the correct and widely-understood term. I was saying, they could as well have been called "Hierarchical Key", because the components in the Key reflect the Hierarchy of the tables, the hierarchy of the Domain, the hierarchy of the information. Regardless of storage.

Further, I would say that any configuration of the tables from Codd's example, that is NOT in the rendition that I have given in Relational form, is missing something serious from the RM (Integrity, Power, Speed, any combination of that), to the extent that it is different.

> And I
> want to thank you, because in preparing this reply I gained a new
> appreciation for the meaning of "data independence".

Data Independence is a large subject, with several dependencies, the hierarchical understanding of the implementer being just one component of it, so I will leave that out for now, and resume it after you have confirmed a better understanding of Codd's ideas re Hierarchies.

Ok, it wasn't short after all!

Cheers
Derek Received on Fri Feb 06 2015 - 00:13:59 CET