Object-Oriented vs. Relational

Today, when relational databases absolutely dominate in the market, it is hard to find an example of an alternative approach. What is it all for, if there is no such thing as an object oriented database? Well, probably for that it would come to existence some day.

On the other hand, there is no such thing as a relational databases neither. None of the commercial DBMS is relational in the exact meaning of the word, they all incorporate numerous non-relational features, and it is this inconsistency that makes them usable and competitive. These are rather SQL databases than relational databases.

What do we have? Oracle, DB2, SQL Server, a few quasi-relational systems like MS Access and FoxPro. Mainframes as a sort of software dinosaurs. Various OLAP systems are entirely based on the same principle, with the only difference in the number of dimensions. The only non-SQL system that can be compared with the SQL giants is Lotus Notes, which, however, is already going to abandon its native structure in favor of DB2.

And Jasmine, the only example of an object-oriented DBMS that at least tried to compete with SQL based products. Unfortunately, it has been abandoned by the authors and re-profiled to serve as an integration platform rather than a database management system.

However, there is some hope. The roots of the domination of the relational approach are in the very concept of database, as it has practically formed. A database was, and generally is considered as a kind of warehouse, to store essentially static data. The predominant usage of such a data store was to extract data and combine them in a table, the only form of report that the majority of computer users understand. It is quite logical that the structure of the database would reflect this common need and tuned to maximum performance in table generation. All the other processing occurred outside the DBMS, and did not influence its functionality. Ray Ozzie's Lotus Notes was the first breach in the wall. It was an instance of groupware system, workflow rather than data oriented. Stress on collaborative work, parallel data processing, individualization and secure transactions demanded an entirely different paradigm, since lack of support for multiple synchronized data update threads was the weak place of relational databases. The focus was shifted to from a database to an application, combining diverse data in a manner transparent for the user.

Today, when all the commercial DBMS are enhanced with collaborative tools and the means of workflow automation, the dilution of the strictly relational paradigm is evident. It will take time, however, to become aware of the necessity of a quite different organization of data storage and retrieval. As soon as plain table reports will give way to dynamic multiaspect representations allowing folding and unfolding in a different dimension, tables on disk will become too restrictive.

A number of prejudices will have to be overcome in this development.

Prejudice 1. Object-oriented organization is entirely different from table representation.
This is not true. Primarily, a table is an object too, with its specific properties and methods, and any combination of tables can be expressed in the object-oriented (dynamic) language no worse than in (essentially static) SQL. On the other hand, any object can be treated as a table, with one row for each data item and many columns for item properties. This can be easily observable in the current Lotus Notes API, where each data item in a database record (a document object) has such properties as name, value, creation/update data, encryption key etc. Considering methods as a variety of properties, one obtains a quite relational structure.

Prejudice 2. Object-oriented organization is not fit for flexible reporting.
This opinion is based on the experience of Lotus Notes and Jasmine, but these two examples do not exhaust all the possibilities. Of course, if tables are considered as the only acceptable report format, object-oriented databases should be enhanced with additional tools for quick data extraction along a specific slice, just like relational databases have to be extended by workflow support tools. However, with the development of data mining techniques, knowledge management, multiaspect analysis and semantic modeling, the benefits of the object-oriented approach will become obvious. Instead of browsing through a huge table in a vain hope to encounter some regularities, the user will observe a few global features, unfolding them to get more details, if necessary. Hierarchical databases that can be unfolded from any element are much better fit for such reporting than rigid tables.

It should be noticed that relational databases are not as user-friendly as they claim to be. It takes a qualified user and hard work to construct a correct SQL query to produce a non-standard report combining many tables. Similarly, in Lotus Notes one can easily produce standard reports, with a skilled programmer needed for non-trivial cases. An object-oriented database is much more comprehensible, since the user only deals with the natural properties of the objects, rather than with abstract data fields. It is a requirement to the implementation, to efficiently extract data according to such hierarchical queries.

Prejudice 3. Object-oriented databases are huge.
Once again, the sad experience of Lotus Notes and Jasmine is the only basis for such a statement. This is like judging about the normal size of an SQL database by the DBASE format, which gives files much larger than Lotus Notes NSFs. In general, the file size is a function of data to store and compression techniques used. For instance, a static datum does not require any additional space to what is needed to store its value; on the contrary, a workflow datum requires information about modification date/time, versioning, encryption, digital signatures etc. A better object-oriented system would give more control over the parameters to store and thus allow space saving solutions.

In an object-oriented database, one may have an overhead of the object structure data to store with each item, in addition to the item value. More flexibility demands more links between objects, and additional storage. However, this difficulty can be easily circumvented, if item structure becomes yet another object and is stored separately from the item itself. One would simply create a database of available classes and use class references. Even more scarcity could be achieved with class lists in the headers of databases, generalizing the DBF header format. That is, the huge size of a database is mainly due to lack of object-oriented techniques, rather than their implementation.

Prejudice 4. Object-oriented databases are too complex to efficiently manage.
This depends. Of course, a relational database allows simple processors with minimum operations. An object-oriented database demands drivers for specific object classes. However, modern software is all based on extensibility, with the core implementing a few basic classes and other functionality added through third-party drivers, plugins, skins etc. Properly organized object-oriented database would be much more manageable than relational databases with the number of records increased, since, in object-oriented databases, processing time is not as strongly dependent on the complexity of query.

Object-oriented databases are much better than relational databases, when it comes to change in data structures. It is well known how painful such a change is in an SQL-based system, where all the queries have to be modified, and the users have to learn where the data they need is located in the new infrastructure. A trivial change like allowing more positions in a key string sometimes would raise insurmountable difficulties. In an object-oriented approach, any change is transparent for the user, since data locations are separated from data links, and the same fore-end organization can correspond to any back-end representation.

Prejudice 5. Object-oriented databases are still far away, while relational databases are here at now.
This is a serious argument. Race for quick profit prevents software companies from serious research in innovative directions. However, the pressure of objective necessity drives the market to more modularity, uniformity and flexibility, and modern SQL systems are already far from mere relationality. Small companies and individual programmers continue experimenting with new techniques of data processing, workflow automation and knowledge management; it is quite possible, that the breakthrough is near at hand, and it will soon be pushed into the market by one of the big players trying to seize the promising niche.