DATABASES - NOWHERE ROAD T

Object oriented databases were set to take over the database world. But the spoiling tactics of some large vendors, combined with the technology's infancy, means the promised land is still some way off.

Relational databases were destined to become a thing of the past onceut the spoiling tactics of some large vendors, combined with the technology's infancy, means the promised land is still some way off. users had grasped the significance of object database management systems (ODBMS) - just as in their day, relational databases were supposed to supplant hierarchical, flat-file and sequential databases. But, in fact, it is believed that 80 per cent of corporate data is still held on non-relational databases and vendors still have a very long way to go in migrating users to relational databases, never mind ODBMS.

Despite the low take-up, relational database developers such as Informix, Sybase, IBM and Oracle, have enjoyed considerable success by leading many customers down the relational path. This success is one that ODBMS hoped, but have so far failed, to replicate.

Five years ago, UK consultants Bloor Research - then trading under the name Butler Bloor - published a report entitled, Object Databases: An Evaluation and Comparison. It covered 13 products, most of which came from small niche companies.

Many of the products emerged from the academic world in the 80s, such as Empress from Empress Software, whose roots lay in the University of Toronto. Others, such as Interbase, were the work of brilliant individuals.

Interbase was the invention of James Starkey, who had worked at Digital on database design. It first saw the light of day in 1984 in the Unix environment. Interbase was later sold as an OEM product in the Digital, Data General and Hewlett Packard world. Elsewhere, ObjectStore from Object Design drew together developers from the artificial intelligence community, the relational database and object technology sectors.

Only one of the products reviewed by Bloor Research - Open Ingres - seems to have emerged from the established database supplier fold and even that was late onto the market, only being unveiled in 1993. Of the hardware suppliers, only HP exhibited any interest at the time in object databases, with OpenODB.

The different and differing origins of the various companies from which ODBMS products emerged reflected the confusion in the market which is, in turn, mirrored in the different products evaluated by Bloor.

Many of them did not even set out to be object databases in the first place but just to incorporate aspects of object technology into a relational database management system (RDBMS) product. In the case of Ingres, it was find a way out of the deepening crisis in which it found itself in the early 90s.

It is perhaps worth recalling that the attempt to use ODBMS or any other technology failed to save Ingres. The vendor was purchased by the ASK Group in 1990, which was itself swallowed up by Computer Associates in 1993.

However, Ingres was perhaps luckier than many of its contempories listed in the Bloor report. Many have disappeared altogether, others have also succumbed to takeover bids from larger organisations, while a very few have soldiered on.

One of the more successful ODBMS companies still alive and kicking today is Object Design. There are a number of reasons for its survival while others have fallen by the wayside or been taken over, but a couple of interrelated reasons predominate.

The first is that, in its early days, the company employed one-third of its staff in R&D. What made this possible was the investment in the business by venture capitalists and other sectors of the IT industry.

IBM, for example, invested a total of $27 million in Object Design in 1993 and revealed that it would incorporate ObjectStore into its Information Warehouse - an early data warehousing application which was designed to allow users with the necessary authority to access information on diverse databases and machines ranging from DB2 on the mainframe, Oracle on the Digital Vax, or other databases residing on Unix, OS/2 or Windows and DOS machines.

Other IT companies that put cash into Object Design included Sun Microsystems, HP, Digital and AT&T. As the Bloor report stated: 'This industry confidence, coupled with the fact that ObjectStore is the market leader, suggests that Object Design is a company with a relatively secure future'.

But Robin Bloor, chairman and chief executive of Bloor Research, admits he was one of those who thought ODBMS would have a far greater impact than they have, in fact, had.

'It is one of the occasions where, as a consultant, I was wrong,' he says. 'I expected them to have a far greater impact on the database market.

But they are not dead - they are a niche product. Where they are dead is in terms of competing with RDBMS.'

Bloor believes there are certain market sectors where object oriented databases are superior to the relational model, such as in database repositories where they can be used to manipulate data in a way that RDBMS systems can't. But as for shaking the stranglehold of the RDBMS suppliers on the general market, Bloor says the ODBMS suppliers do not stand a chance.

He adds that a clever marketing campaign by Oracle helped to ease database companies and customers away from object orientation. 'At the time, Informix was good at building very large databases, as well as object technology.

It had acquired an ODBMS company and was already winning market share from Oracle.

'But at the same time, Informix was running into financial difficulties and senior figures were leaving the company,' Bloor states. 'Oracle went to the press and claimed that the main reason for Informix's troubles was that it had invested too heavily in object databases. This had the effect of frightening away a number of companies that might have moved into the ODBMS market. It was a brilliant piece of marketing by Oracle.'

Roopinder Singh, director of marketing at Ardent Software, believes full blown object databases are still in their infancy and that the first wave of enthusiasm for the technology was misplaced.

'It's still very early days and the market will not really take off until next year or the year after,' he predicts. 'It is a very technical sale, usually to the database administrator or the systems programmer. Organisations are extremely nervous about the technology and we find it difficult to sell directly into an account.'

Ardent entered the object database business when it acquired O2 Technology in 1998, one of the pioneers of ODBMS. Like most of the other pure ODBMS companies, O2 did not arise from a purely database background. It emerged from a French government research project which was backed by private organisations, such as Bull and Siemens Nixdorf, as well as academic institutions including the University of Paris.

But despite this backing, O2 never managed to survive as a viable organisation.

In 1994, it was claiming that it had attracted 170 customers who had bought 900 licences, a pitifully small amount for a firm in the software market.

Singh believes the only future for pure ODBMS is as an embedded product in a specific application. 'Our point of view is that it has to be sold through specialist partners and resellers,' he adds. But these resellers tend to be specialists in fields that require a defined set of skills, such as geographic information systems (GIS), specialised visual work or Web-based text retrieval systems.

According to Singh, corporate customers are cautious about buying a technology that they're not certain they will be able to support with their existing staff and skill sets and where they are uncertain that there are an adequate set of tools available to support the product. But above all, they are concerned about whether they can afford to risk their businesses with the change from a stable, if limited, database to an untried and untested technology.

But, at the time, the RDBMS companies could not afford to ignore the threat from object databases in its entirety. As a result, they adopted some of the best aspects of object orientation and incorporated them into their own products, which they went on to designate object relational databases.

'It extends the relational model,' believes Terry Lawlor, UK marketing manager at Informix. 'For example, you can define staff as a class, then as temporary or permanent, hourly, weekly or monthly paid and so on.'

He concedes that the early promise of ODBMS did not live up to expectations but argues that some of the technology is valuable in certain environments.

But object databases by themselves, for all their powerful benefits, cannot operate in isolation, Lawlor believes. 'The majority of corporate data is held on non-object databases and you need to be able to relate to that,' he says.

By way of example, Lawlor points out that digitally delivered video-on-demand via the television, PC or Web could make valuable use of objects in splicing together various pieces of film, but that it would not help solve some of the problems this would create.

'You could have a video that showed all of the matches between Arsenal and Chelsea in the past 10 years, or one that showed how many times so-and-so kissed so-and-so in a soap and in what location. The object capabilities of the database would be excellent for this, but what it could not do is access the contractual detail of the artist involved, which would be held on an RDBMS,' he says.

To the object purists, object relational databases may appear to be a halfway house which does not meet the full potential of a full ODBMS.

But there is little evidence that the early pioneers of the technology proved their case.

Whatever the impact of the alleged dirty tricks campaign by Oracle, the early players in ODBMS failed to convince users that their technology was a sound investment. Just as it took the RDBMS companies time to set themselves up against the established non-relational suppliers, so it will take the ODBMS vendors a similar period.

According to Bloor, the true ODBMS suppliers may yet get a second bite of the cherry. What might give the ODBMS boat a push away from the shore is extensible mark-up language (XML), the successor to hyper text mark-up language (HTML).

'In my opinion, there is going to be a rebirth of this technology with XML,' he says. 'But what will happen is that a new generation of companies will come along.'

But Bloor adds: 'Having said that, I have not heard of any such companies actually appearing at the present time.'

Ardent's Singh agrees that XML may give object databases a boost, but Lawlor is less certain: 'The ODBMS vendors are keen to jump on the XML bandwagon,' he says.

It is clear that, at present, the ODBMS vendors do not have the power to challenge the established and entrenched database suppliers. As Singh points out, the sale of ODBMS is a technical one and the technology is little understood inside the industry, never mind outside of it.

When companies such as Ardent, which have an object database, decide that selling directly to their customers is too difficult and that such sales are better left to partners, then clearly the technology is immature to say the least. That is not to say resellers can't make a profit out of ODBMS, but there is a heavy price to be paid.

Any Var that is planning to enter the ODBMS market must be prepared to recruit staff who can not only sell the technology, but support it as well. If Singh's view is correct - that the object database is better embedded in an application than sold as a database system - then it will be the sale and support of the application that matters and not any underlying technology.

It is possible, of course, that the advent of XML, video-on-demand or even that other forgotten technology, virtual reality, may yet rescue ODBMS from the doldrums. However, in the opinion of most industry observers - both partisan and independent alike - it is likely to be at least two more years before the second coming of true object databases.

DATABASE DEBATE: WHAT'S ON TOP?

Databases, like computer languages, have been the subject of fierce debate, especially when they emerge from the cross-fertilisation of ideas from the commercial sector, government, the military and academia.

Cobol, the standard business language of the corporate world, was the brainchild of Grace Hopper and developed on behalf of the US Navy in which she was an officer. Relational databases are supposed to follow the 10 rules laid down by Ted Codd, the inventor of the technology in 1970, then working for IBM.

ADA, a programming language which first saw the light of day in the late 70s, arose from a competition sponsored by the US Department of Defense (DoD). The DoD was looking for a language that could be embedded in weapons systems, such as guided missiles, and invited consortia of companies to submit specifications. After a series of tests, a winner was selected and ADA was born.

But those companies that had worked on the losing projects attempted to turn the language into a commercial proposition.

ADA was superior to all other languages, they claimed, and would sweep Cobol away as a commercial language. This was patent whistling in the wind - there are billions of lines of Cobol code in the world while ADA is confined to a very small segment of the market, mainly embedded software.

The pioneers of ODBMS borrowed from Codd's original submission nearly 20 years earlier when, in 1989, they produced a paper entitled, The Object Oriented Database System Manifesto. The paper attempted to lay down a similar set of rules for ODBMS to those that Codd had laid down for relational databases.

The paper attracted the attention of other database developers who produced a counter document, The Third Generation Database Manifesto. Essentially this was the response of the existing RDBMS suppliers to the perceived threat from ODBMS developers. One of the key differences between the two groups was the question of structured query language (SQL) which the relational vendors saw as a standard and the ODBMS developers viewed as being restrictive.

Inevitably, there has to be a winner and, 10 years after that debate, it is clear that it is the relational lobby. ODBMS vendors may have lost for now but not without their competitors in the relational world borrowing some of their technology to build object relational databases.

DEFINING OBJECTS

Object orientation is not new but only in the past few years has it entered the domain of the wider world of IT users.

Definitions of what constitutes an object are far reaching and range from the most cynical to the most purist of interpretations. The Handbook of IBM Terminology, an invaluable guide to the peculiar - in the sense of both the strange and of unique - produced by consultants Xephon, gives the following definition of an object: 'An abstract entity within a data processing system, sometimes known as a "case". Unlike entities such as paragraphs, charts and files, an "object" is independent of any particular implementation, which makes the user's life much easier when it comes to changing hardware. Object oriented programs are very modular and their components highly reusable.' The book adds that: 'IBM is terribly enthusiastic about objects at present so we can expect everything to be "object oriented" at the moment in much the same way that everything became virtual in the 70s.'

The Bloor Research report on object databases is scarcely less helpful in definitive terms. It defines an object as: 'The instance of a class of objects, or object type. Within the OMG's (the Object Management Group, which is seeking to define a standard for object orientation) definition, an object is a combination of a state and a set of methods.'

The report helpfully adds that: 'Objects can be thought of simply as records with the functions that might apply to them (eg updating a customer balance in a customer record).'

Clearly those who wrote these definitions have never had to sell to a sceptical customer. Any reseller attempting to use this type of terminology to a purchaser without a degree in systems programming could find himself without a sale.