Re: Hierarchical Model and its Relevance in the Relational Model

James

> On Monday, 2 February 2015 22:46:19 UTC+11, Derek Asirvadem wrote:
>
> > Yes, which you very much needed, as I'm sure you also remember,
> > both because of the lack of data independence, and because navigating
> > the hierarchy required having a clear picture in mind of the database's
> > structure.
>
> That is two separate points.
>
> Clear picture in mind. Well that is my point, not yours. You need a "clear picture in mind" if you are going to implement ANYTHING, if we are going to navigate ANYTHING. A database today, a pre-relational file system or database. A network topology. That is why we have IDEF1X, a standard. Instead of funny pictures in Visio and UML. In those pre-relational [days] we had different diagrams to provide us with a "clear picture in mind", and a standard for the symbols, which were available as stencils at the newsagent. It proves once again, we had a MODEL.

Point being we need a "clear picture in mind" to navigate any topology, today's IDEF1X Relational data models or yesterdays Hierarchical Topology Navigation Map (since you deny the word "model" for the diagram). No less, no more.

Of course we had relationships, and they were maintained by the platform, but, and this is the great difference between pre-relational vs relational, the chains or links or pointers were record numbers, not keys. COdd details this in the RM.

> > the distinguishing
> > feature of the relational model that it's an inferential system.
>
> Yes. Agreed. As long as you do not mean ONLY inferential. It is perfect for OLTP as well as DSS/OLAP, in the same database.

And, importantly, the inferential capability of the system would be limited to the knowledge and capability of the modeller. If he did not implement the data hierarchies that occurred "naturally" in the data, into the database, as hierarchies, then the database would be severely hindered, in terms of DSS/OLAP.

Based on many projects completed with this issue being a key implementation point, I would go as far as saying, most of the replicated databases that you see these days, the purpose of which is to offer a data mart or data warehouse or report-only capability, can be eliminated if only people were aware of the relevance of hierarchies, and implemented them properly: the one Relational Database would support both OLTP and DSS/OLAP. There is an awful lot of wasted resources, hardware and manpower in the replicated dbs.

Same vein, another example, one I am sure you do understand, because you quoted the Rule. The typical "database" that people implement these days consist of "tables" with RecordIDs. That breaks Data Independence, specifically, Codd's Data Access Path Independence requirement. Every "table" is in fact a separate FILE, with an access path dependence. Further, the level of integrity that such schemes can implement is a tiny fraction of the integrity that is effortlessly afforded, if one were to Normalise that same data into HNF and RNF.

> You seem to misunderstand, conveniently, I suppose, despite the details I have given, that I agreed there is no published theoretical basis for the HM, silly to expect, etc. Given my details, "set notation" above means set of notations, symbols, not notation of sets, which concept did not exist prior to Codd, and therefore is silly to expect, blah blah blah.

Another analogy for the issue you raise. Some years ago, most Western contries implemented Occupational Health & Safety, as law. That means a standard, that was understood and accepted by everyone. All new buildings were required to comply from the start of the project. All existing building were given one year to comply, or be demolished.

Now at that time it would be silly if someone trooped up and said, re one of the old buildings "hey that building over there is unsafe, it has no safety whatsoever, it is build on a safety theoretical void." Er, we have OHS for decades before. Every build had some form of it, depending on the integrity of the company. We just did not have a publicly available syllabus against which to measure the exact extent of safety. There was not a requirement to publish the safety aspects for every building.

Such is your position re the "HM was built on a theoretical void".

> > I have not read a theoretical treatment of SQL's recursion.
> > It seems like a good job to me, a minimal extension.
>
> No idea what you mean. The recursion is in the server, not the SQL code. Same as for an awk script: the recursion is in Unix, not in the awk script. There is no recursion "in" SQL. Of course, both the awk script, and the SQL function, must be written with the awareness THAT it will be executed recursively, but that is not recursion IN SQL or the awk script. We have had it since 1984.
>
> > But it also seems harder to use
> > than necessary.
>
> How would you know ?
>
> Or, are you talking about some freeware/shareware/vapourware NonsSql that has recursion IN the NonSql ? Such as those that have "deferred constraints checking", etc. Hilarious. They have read the same book, lapped up the same poison, ignored the same scientific Architectural Principle, and written puke into their program.

The full extent of the horror of the freeware/shareware/vapourware purveyors writing recursion =IN= SQL, instead of providing recursion in the execution engine (server or bunch-of-communicating-programs or whatever they have), sunk it overnight. My colleagues and I have difficulty discussing anything else today. Is this for real ? Is the shareware crowd /that/ stupid ? I mean, I know they are stupid from various items in the past, but I did not know they were /that/ stupid.

Of course it would be hard, very hard to use. The essence of the simplicity of relations would be lost.

And even harder to implement. So let me get this right: 10,000 PostGresNonSql (and other NonSql variant) developers across the planet are working on implementing recursion =IN= SQL. Have I got that right ?

My colleagues are eager to obtain a confirmation, please, because the news is unbelievable.

And whose idea is this, Darwen's ? Abiteboul's ? Of course it is ready evidence that he, too, does not know the Architectural Principle of separating data (relations) from program. Who is this guy that is lining himself up for the Darwin Award. We have to recognise him and give him credit for his efforts.

Cheers
Derek Received on Wed Feb 04 2015 - 06:43:31 CET