Please note that this story is over 18 months old. It may be outdated.

I have been rather busy of late, doing a bit of reading and a lot of research regarding the NF² or The Nested Relational Model.

While browsing my old Universities library last year, I discovered an old text-book on the subject of Object-Oriented Database Management by Kemper & Moerkotte. What is of real interest is that “Chapter 6 – Extensions of Relational DBMSs” has a rather good coverage of the “6.6 – The Nested Relational Model NF2” with a bunch of references or citations to papers all written around about 1986.

So, what happen within the database academic world in the mid 1980’s that NF² was all the rage?

Now, the text-book is analyzing the NF² model as an extension to the relational SQL database model and comparing all relational database models to an object-oriented model. So, as object-oriented anything is all so much better than anything else (good-bye and farewell Forth), it is a bit biased.

The mathematics for the set-theory around the “6.6.2 – Formal Definition of NF² Relations” section is good; for those of you whom like maths. The theory eventually gives way to a section on the query language to support NF²; all of which is in a modified/extended form of SQL. That is OK, but it is easy to forget that the multi-value data model that was implemented within the PICK model is  single file based; a data selection can only be performed or centered around one table or file at a time, with the use of translations to other files is within virtual fields. SQL has the ability to dynamically link tables together within the selection process; hence the relational side of a RDBMS. It’s really all good stuff…

The summary of the chapter leads to the conclusion that the NF² data model is “…really a hybrid of the relational and the hierarchical data model.” and there are problems with data redundancy, ownership of objects, and sharing of objects due to the nesting. The NF² model provides an extremely concise data structure, but the side-effect is that the extended SQL query becomes non-trivial and just as complex as for a pure relational model schema. OK!

The annotated bibliography at the end of the chapter lists an interesting selection of papers and presentations regarding NF² data structuring concepts. They are all based approximately around 1986 to 1987.  There are references to the AIM-P and DASDBS database prototypes, and the HDBL language. And then there is R²D² – a relational database system; not the inverted-rubbish-bin-on-wheels robot. There is NO references to the PICK data model. Rather sad.

So, I am currently attempting to beg, borrow, and steal the text of these references and citations, in an attempt to follow through and see that all the excitement is all about. Why? Well, this is the first time that I have come across some form of academic analysis of the NF² model. There is nothing contemporary  happening on the subject – shame on the multi-value database vendors (remember, a white-paper is a SALES tool – like a brochure; a biased scientific/academic paper).

So, if you have any information regarding the above NF² systems, leave a comment please.

And I will be writing more when I  found out more. It would be nice to sit across the boardroom table and throw out some academic references on the multi-value model when the selling gets tough.

All good stuff really…