When you first encountered the idea of a Relational Database, you may have been told by some presenter that “the Relational Model of data is based on Mathematics.” That was true. Ted Codd, the father of the Relational Model, wrote a paper entitled “A relational model of data for large shared data banks.”

This introduced a number of good ideas, including:

1. Information systems should enjoy data independence: In effect, the storage of the data and how the data store worked should not influence the building of systems (i.e. the coding of programs).
2. That data could be viewed in terms of mathematical sets.
3. That distinct data entities (customer, product, order, etc.) should have unique keys.
4. A standard query language that could implement the data independence described in 1. above.

Down in the weeds of the Relational model there was an awful lot more than that, of course and some of it may have been mathematically respectable. However, it was well known from the outset that the relational model did not and could not model some kinds of data. One common data structure that the Relational Model didn’t accommodate, for example, was a hierarchy. You could implement laborious get-arounds to accommodate such data within a relational database, but the simple reality was that the Relational Model never got round to defining hierarchies properly. Insofar as Relational database included a mathematical model of data, it was incomplete.

The Advent of Objects

With the development of Object Oriented programming languages in the early 1990s, the limits of the Relational Model began to become awkwardly visible. What quickly became clear was that the view of data that an OO program had was not compatible with the way an RDBMS stored data. For that reason a new software product was invented to even out the incompatibilities between the two views of data.

An easy way to explain this problem is this:

Think of a car. When you have finished using it, you park it in your garage and leave it. When you park it you do not take out the seats, take off the tires, remove the doors, pull the steering wheel off, take out the engine, etc. However RDBMS with their “normalization” processes would often insist in storing a car in exactly that way and then reassembling it for you when you next needed to use it.

So software that carried out Object-to-Relational mapping evolved – the most popular product in this category being the widely used Hibernate (from Red Hat).

There was, of course, a brief attempt to do away with the Relational model and replace it with Object databases. Then there was a counter idea from the RDBMS side which proposed an Object-Relational model for database, which attempted to compensate for RDBMS limitations by violating the Relational Model at the data item level and allowing users to take advantage of:

• Extensibility – By defining new data types.
• Complex types – By defining data types that combine other existing data types.
• Inheritance – By defining objects or types and tables that procure the properties of other objects.
• Items as Objects – Allowing an item to contain an object with both attributes and operations.

From a mathematical standpoint, this was “neither fish nor fowl” – in fact it was a kludge, but technically it was a viable one. And the Object databases, with one or two exceptions (e.g. Caché from Intersystems) never established themselves as competitors to RDBMS products. The limitations of RDBMS became even more obvious with the advent of the Internet. RDBMS had no way of representing web pages which were, by and large, collections of data and mark-up tags. So web pages were stored as character strings by RDBMS and their inner structure was buried.

« 1 2 or View All »