In the early 90s, the object database was hyped as the next big revolution in database technology. A handful of so-called OODBMS (object-oriented database management systems) products appeared on the market and a wave of enthusiasm led many to believe that the IT industry was on the verge of a technological breakthrough. The OODBMS, claimed industry pundits, would eventually replace the traditional RDBMS (relational database management systems) in the same way that the relational database had replaced the hierarchical model a decade before.
Like many predicted "new waves", the object database revolution failed to materialise. Some of the early products found themselves a small but stable niche market while others quietly disappeared.
However, the story did not end there. Last year, talk of "object databases" began again when all of the leading database vendors introduced object/relational technology into their existing products. Today, Informix, Oracle, IBM, Computer Associates and Sybase are all offering some form of object/relational functionality and promising more in the future.
Not everyone, however, is sold on the idea of object/relational capabilities in mainstream database products. Nigel Cooper, product marketing manager at Software AG, is certainly not convinced. "Object capabilities fulfil a specialist need in the market," he explained. "When the first object databases came out there was no general requirement in the market to pick them up, and that's why they failed."
Software AG, in conjunction with Heidelburg University, is working on an object/relational product which will be marketed separately from its existing database product ADABAS. "Our strategy will be to attack the niche market," said Cooper.
On the other side of the fence, mainstream vendors are telling us that data is becoming more complex, and that the popularity of the Internet has created a need for more complicated data models. According to database vendor Informix, there has been a fundamental paradigm shift. We have moved, the company claims, from a world of well-understood datatypes to a world full of complex and unexpected datatypes and these require a new kind of data management system.
Confusion in the business community is the result. To make matters worse, there is considerable disagreement between manufacturers about exactly what core features make up an object/relational database. According to Nick Gregory, server technologies marketing manager at Oracle, object/relational technology has been hampered by two false dawns.
The first was with the original OODBMS products. Vendors were unable to deliver on their promises because "they had no legacy, and therefore no data to barter with", Gregory explained. "The second one was the debacle which Informix got itself into in order to leap ahead of Oracle."
Gregory claims Informix came into the market artificially early, leap-frogging the new Oracle product and talking about its universal server and the extensibility of the database. "Informix didn't get the message right," he said. "The product wasn't ready and still isn't."
Oracle was the first manufacturer back in 1992 to talk about the inclusion of object extensions into its architecture. Several other manufacturers then followed suit, most notably Informix, which in 1996 brought the subject of object/relational technology back to the fore with the acquisition of object database vendor Illustra. Throughout that year, all of the leading database vendors declared their object relational strategies.
There is no doubt that object/relational databases have inherited a difficult history, but fighting between vendors has succeeded only in obscuring the exact nature and purpose of the technology. The failure of the original OODBMS to deliver on its promises still leaves a cloud hanging over the whole subject, and, not surprisingly, many IT specialists remain sceptical as regards the true business benefits of the technology. Why is it, after all, that the perfectly capable marketing departments of several large software vendors are suddenly unable to make clear the business benefits of a new technology? Is it perhaps because there are no business benefits?
Has the whole object/relational frenzy been nothing but a chimera conjured up by over-enthusiastic technologists?
In August 1997, research group Ovum produced a report evaluating object/relational technology. The report stated quite firmly that "the introduction of object/relational technology is the most important development in database technology in 10 years". It points out that since the original object databases appeared on the market, several crucial factors have changed.
First, the risks of adoption have been much reduced since object/relational technology has appeared in mainstream products. Most firms are reluctant to make changes to their business critical applications if it leaves them dependent on small suppliers. That question is no longer part of the equation, as large suppliers have got into the market.
Second, there is now a far more pressing need for IT departments to deliver better and more diverse applications. The pressure is on to produce these quickly and to be more responsive to changing business requirements.
Finally, gradual improvements in technology over the past decade have gone a long way to stabilise the architecture between the desktop and server, thus making the integration of conventional databases and new forms of data much easier.
The authors of the Ovum report are also keen to point out that the many criticisms levelled at the original OODBMS are quite inappropriate when applied to more recent object/relational offerings. Early OODBMSs were lacking, for example in basic transaction processing functions, query languages, backup and recovery facilities and database management tools.
They also tended to be difficult to use, unreliable, and incapable of scaling to cope with large transaction databases.
The union of Informix with OO database-maker Illustra is a case in point.
Illustra's inventor, Michael Stonebraker, has acknowledged that scalability and general robustness were two major gains made by merging his product with Informix's existing database architecture. And this is a key point, because whatever extra functions are added by new "object manipulating" features, the traditional support for transaction processing must remain intact, and in the end this is the only path which major database vendors can follow.
So what exactly is an ORDBMS? There is no official definition of an ORDBMS but its implementation within mainstream products has involved extending the relational model to include object-type features without jeopardising the existing core of the traditional database. From this standpoint, database vendors are attempting to introduce the new technology into the business community in a way which is risk-free and will involve little or no retraining.
Object/relational, or extended relational, technology has been implemented using a variety of different architectures, but there are certain core characteristics which typify an object relational database product. The concept of the "universal server" (despite a legal battle between Oracle and Informix over ownership of the term) has helped to clarify some aspects of the ORDBMS.
Unlike the traditional relational database server, which is restricted by the type of data it can store, the universal server is capable of storing any kind of information for any purpose. This does not just mean that it provides support for just storing video, image and audio file formats, but also that they can be queried and manipulated. In practice, this means it must also provide support for an extended form of SQL as an access mechanism to query stored objects such as images or video by their content.
SQL-3 is the next scheduled release of the SQL standard, and is expected to establish many aspects of object/relational functionality.
Several extensions are typically included in ORDBMS' which provide the means to store a greater variety of datatypes than the usual relational offerings.
- Geographical/Spatial. Obviously many relational databases store geographical information, but most of the time this consists of nothing more than a column label and a bunch of text strings. The whole idea of storing meaningful geographical information is that the database can be interrogated with spatial-type questions like "tell me how many hospitals there are within a 40-mile radius of this point". This is not impossible to implement in a relational database but it would involve a vast amount of programming overhead. The point of implementing geographical data as an object/relational function is that spatial queries are actually available within the database system's query language - that is, commands within the query language are tailored to refer to geographical attributes.
- Time Series. Another datatype commonly referred to in object/relational systems is time series in which a set of data is organised by time of occurrence. Again, the same points apply. It can, in theory, be implemented in a relational database, but performance and space management tend to become a problem. When such data is stored in a sequential fixed record format rather than a relational table it can be far more easily manipulated.
The datatype generally requires a customisable element so that it behaves correctly within the particular application context. For example, applications in the finance industry which track the movement of a share or bond price require a definition of trading days to take account of bank holidays and weekends in different countries. In this case, time becomes a far more complex datatype to the notion of time which is understood by the computer.
- Text Large. Chunks of text have always posed a problem for relational databases and over the past few years document handling has become a specialist application area of its own. Most document management systems are built with an application layer which maintains a document model while a traditional RDBMS keeps track of the contents of independent files. As a specialist application this can work well, but it does not have the general-purpose transaction capability of a standard RDBMS. The ORDBMS attempts to combine the strengths of each by allowing documents to be queried via an extension to the database's SQL. Such extensions include a variety of different search mechanisms including thesaurus-based searching, proximity, different flavours of wildcard and grammar.
- Images. The ability to store and retrieve images is probably one of the most talked about capabilities of the ORDBMS and one which has contributed to the general impression that the technology is suitable only for specialist applications. Like the other datatypes, image files can be both stored and queried within an ORDBMS by reference to their contents. The application of this capability may be wider than it seems if it is viewed alongside document handling, simply because modern documents tend to contain pictures.
Images stored in ORDBMS' can be queried by their contents using SQL extensions to respond accurately to such questions: "Show me all the red-haired men with blue ties." The technology is impressive but generally unhelpful to the mainstream.
- Web Pages. The Web page has become an increasingly important form of information over the past couple of years, and in this particular area, some ORDBMS' have already sold themselves as Web content managers. The ability to store and provide query tools for Web pages assumes that the ORDBMS "understands" images and text but also sound and video. Again the object/relational database provides query access to such datatypes through extensions to the SQL language.
- Content Management. The major new capability in an ORDBMS is not just that of storing different and more complex datatypes but rather the ability to query and manipulate new data forms by their content. In the case of Informix's Universal Data Option, complex programs which analyse the content of an object, such as an image, can be inserted into the database by third parties. These programs are referred to as "datablades", and they hold all of the capabilities for accessing and manipulating a particular object type. In fact, a datablade is nothing more than an SQL script containing the commands to create new data types and the methods which manipulate them.
Do you really need an ORDBMS to run your business? Object/relational technology is not a single concept but a whole host of features and capabilities, and there are numerous examples of its possible applications in different business areas. The time series function, for example, has a massive potential use in the finance industry where keeping track of real time transactions is central to the business. The geographical function can be used in practically any organisation which collects statistics, as well as having huge possibilities in the telecommunications and transport industries. Further possibilities exist in engineering and manufacturing where CAD is an important format, and in retail where the organisation of multiple file formats can be the cause of great inefficiency.
The examples are endless, but they tell us little about the status or future of the technology. Angus Falconer, technical marketing manager at Informix, said: "People in the market adopt new technology at different speeds. The early adopters are always those people who are enthusiastic about new technology and very often those who have a specialist need."
Falconer went on to point out that because of the nature of early adopters, most of the very first examples of ORDBMS' were specialist applications.
"Now we are beginning to see examples of more mainstream business applications," he added.
Gradually, the market is beginning to position itself in anticipation of major technological change, but the database market is very slow and painfully cautious. Microsoft is now adjusting its products and infrastructure to allow for the growth of object/relational technology. Its "Universal Access" vision, implemented via the OLE DB interface specification, provides access to data wherever it resides and in whatever format. OLE DB also allows database systems to be implemented as separate components rather than as huge monolithic programs and SQL Server (version 7.0) has now been rewritten in a way which is componentised. Richard Hamblen, marketing manager of middleware technologies at Microsoft, commented: "We haven't focused specifically on any object/relational products, but we are providing a framework which will allow access to any type of data."
He continued: "It's only going to be over time that we start to understand how object/relational technology can be applied to the masses."
The original OODBMS has found itself a stable but very small niche market.
It never lived up to its original promises, but that's no reflection on the technology itself or the ideas put forward by those early object database evangelists. The OODBMS vendors at the time were small start-up companies with no data legacy in the marketplace. The task was too large, and the idea simply too radical.
Now we are seeing a new breed of the technology: the object/relational database. It allows businesses to take advantage of object technology while still maintaining traditional database functionality. However, the major difference is that it is now being offered to the world by huge companies with massive entrenched marketing infrastructures. That alone does not, of course, guarantee success - which is why over the next few years it will be up to the ORDBMS to speak for itself.
THE OO VIRTUES OF A DATABLADE
Datablades were introduced into Informix's Universal Data Option to provide a method of extending the number of datatypes which the system can understand. Users are then able to create their own datablades as well as their own subsets of existing ones.
The environment provides all the classic OO virtues. Both tables and data subtypes can inherit properties from their data supertypes and supertables.
The management of a data type is supported by the definition of its internal format and external representation as well as the functions required to store, retrieve, display, modify and query the data.
Support is provided for the encapsulation of data types and the functions performed on them so that developers and end users are then able (in line with OO philosophy) to interact only with an object's publicly exposed functions. If the object's behaviour changes, it need be changed only in the database. Dynamic binding is supported, so that the system rather than the application can determine the appropriate function on a particular occasion. Polymorphism is also supported so that applications need not specify a version of a function. Hence, again, applications need not be modified when a function changes. The system provides the same security and integrity for user defined types as for its own.
Eleven 'normal' outer moons, and one described as 'oddball' found circling Jupiter
Scientific discovery has found a quadrillion tonnes of diamonds in the earth's mantle
Mobile payment app makes users' details public by default
2,400 signatures gathered against the development and production of lethal robots