Free Newsletters :

Database mind meld

Instead of using either an object or a relational database, the best strategic plan may be to merge the two. And then add a dash of Java.


In this article:
Lessons learned
Objects and the future of database management systems
Vendors that help solve the data dilemma
For more information from other Cahners resources
MDS Laboratory Services had a problem. This division of MDS Inc., an international healthcare and scientific company based in Toronto was trying to build a database for scheduling home-care visits, tracking patients' medications, and storing test results. The system, for use by eight people, had to integrate data from the lab's MUMPS laboratory information system and from Oracle and Sybase databases.


Illustration by Daniel Guidera
"We approached the vendor of a major relational database management system [RDBMS] with a clearly written spec," says James Bourette, a programmer/analyst at the lab. "The company told us it would take nine to 12 months and cost $150,000." That was more than the company wanted to spend.

So MDS turned to Caché, a self-styled "post-relational" DBMS from software vendor InterSystems of Cambridge, Mass. "Two people, entirely in-house, have spent one month getting us halfway finished, at a total cost of $2,000," Bourette says. "We're delighted."

Caché, introduced in September 1997, is one of several products exemplifying a trend in the DBMS market away from purely relational DBMSs toward greater use of hybrid DBMSs that are both relational and object-oriented. For example, when data is defined in Caché, a relational table and an object class are formed simultaneously, says Paul Grabscheid, InterSystems' vice president of strategic planning. That means objects can be manipulated using SQL, the lingua franca of the relational world. So RDBMS users like MDS get some of the benefits of object technology--such as the ability to handle very complex relationships among data--without committing to a DBMS that's purely object-oriented.

Most purely object-oriented DBMSs already have done as much for relational users as possible--that is, making objects available through SQL native interfaces or class libraries. The larger opportunity is on the other side of the street: All the major relational DBMSs are incorporating object-oriented features. On top of that, a new crop of forward-looking object/relational DBMSs (ORDBMSs), built with Java, is springing up to challenge both relational and established object-oriented DBMSs.


The worldwide revenue for object databases is expected to exceed $200 million by 1999.

Objects alone

Object database management systems (ODBMSs) are unfamiliar to many RDBMS users because they have very different architectures and programming languages. Object databases are usually written in C++ and lack the table structure of RDBMS software using SQL.

At MDS, the company's application relates each patient to multiple physicians, visits, and prescriptions, just the sort of application at which ODBMSs excel. It would have been difficult and time consuming to model those multiple relationships within an RDBMS. Yet because of its SQL interface, using Caché didn't require extensive retraining.

The speed with which MDS was able to get its application up and running was equaled by its performance, which is often a critical concern for users thinking about moving to object databases. "We didn't know what sort of performance we might see," Bourette says. "I thought that extra layering--object plus relational--might slow things down. But when I saw it run, I said, 'Wow!'"

But objects aren't going to take over the data world as we know it. "I'd say only 15% of Oracle8 users are taking advantage of its object features at this point," says Jim Steiner, a senior director of product marketing at Oracle, the Redwood City, Calif., market-leading RDBMS vendor.

Support for object-oriented applications remains, however. Just ask Natalie Shaheen, president of Netroscope, a Santa Clara, Calif.-based market-research firm specializing in Java. "The combination of increasing numbers of remote workers and increasingly complex data means object technology will become steadily more important," she says.

And ODBMSs will continue to be the technology of choice for some applications. "We see objects as ideal for operational processing--that is, handling the day-to-day operations of a company, especially a process-oriented company like a telephone company," says Dave Nahmias, manager of product marketing for Template Software in Dulles, Va. Template embeds Jasmine, a purely object-oriented DBMS from Computer Associates of Islandia, N.Y., within its Template object-oriented development framework. "The relational model breaks down very quickly as you deal with operational matters across departments, throughout an entire enterprise," he says.

Nahmias's stance is probably still a minority view. Many major end users depend heavily, if not exclusively, on RDBMSs for operational processing. But few users or vendors disagree on the increasing importance of being able to deal with complex data and relationships as objects.


Lessons learned

  • Using an ODBMS is the fastest, easiest, least intrusive path when the data you're dealing with is most logically expressed as objects.

  • With an ODBMS, programmers can use a single language both for procedures and for data access and manipulation. With an RDBMS, programmers must use embedded SQL plus a programming language.

  • It's easiest and most effective to keep relational and object data separate, in most cases, accessing each with a DBMS made for that purpose.

  • Relational technology is usually superior for analysis and transaction processing.

  • With enough discipline, reusing code can be achieved when programming RDBMSs as well as with ODBMSs.

  • Administrative features aren't as evolved in most ODBMSs as they are in most RDBMSs.
  • Incorporating objects

    Indeed, the once-large schism between object and relational DBMSs is narrowing as new suppliers as well as the mainstream RDBMS vendors mesh the two technologies. The main object vendors include Ardent Software, Computer Associates, Object Design, Objectivity, and Versant. Informix, Oracle, and Sybase are the major object/relational vendors.

    At the moment, the Big Three RDBMSs (Informix, Oracle, and Sybase) can store objects, although they do so by breaking them down into rows and tables. Then the objects have to be reassembled before they can be accessed, which adds overhead. This object/relational mapping, an inescapable reality, has been likened to disassembling a car after each use, then reassembling it for the next ride. But in Oracle8, at least, the assembled objects can be cached as objects for quicker access. Thus, with enough memory, an RDBMS can replicate an ODBMS's performance.

    For instance, Robert Rubin, chief software developer for Lexington, Mass.-based Standard & Poor's DRI, says he'll move to Oracle8 from Oracle7 to store and manipulate databases containing 30 years worth of observations on North American equities, commodities, and economic indicators. It's all time-series formatted data. That is, each observation is linked to the date and time it was made, and the data reveal meaningful patterns only when ordered by time.

    Handling time-series data isn't something RDBMSs have traditionally done. So with Oracle7, Rubin had to write applications containing time-series logic, which applied that logic to data in the server. That imposed a significant performance penalty. But Oracle8 uses add-on modules, which Oracle calls cartridges, to process nontraditional data like time-series data. It is the first version of the DBMS to do so. Now in beta testing at Standard & Poor's, Oracle8 "does pretty much everything we need it to," Rubin says.

    The blending of object and relational DBMSs seems to support the consensus among users, analysts, and vendors that all RDBMSs will transform themselves into object/relational DBMSs (ORDBMSs) within the next five years. (See sidebar, Objects and the future of database management systems.)

    Some object DBMS vendors will fold, experts say, as the object/relational DBMS vendors take up the object market for all applications except those that are strictly or traditionally purely object-oriented, like telephony, financial applications, Web development, and multimedia production. Those applications call for pure ODBMSs because of the extreme complexity of their data and the relationships among the data, says Philip Sutherland, a senior analyst with the Aberdeen Group in Boston.

    "Pure object DBMSs make up under 5% of the DBMS marketplace, which totals between $5 and $6 billion a year in sales," Sutherland says. "Object/relational DBMSs make up about 33% of the total. The ODBMS segment is growing the fastest--about 100% per year--but that's mainly because that segment is so small." He goes on to say, "One new entry into the marketplace, like Computer Associates' Jasmine, can double the segment's growth rate. The object/relational segment will grow at about 30% per year over the next few years, while the pure relational segment grows at about the same pace, largely thanks to increasing sales of Microsoft's SQL server RDBMS."

    In fact, some signs point to pure ODBMSs becoming less important, despite endorsements from Nahmias and Shaheen, while RDBMSs gain object features and become more significant. Most importantly, ODBMSs "are way behind in what really counts in the corporate world: administrative capabilities," says Ken Rudin, CEO at Emergent, a San Mateo, Calif., systems integrator that has incorporated both object-oriented and relational DBMSs into systems it builds.

    Object/relational challenges

    But Oracle8 hasn't become an object DBMS. Inheritance--the quality of objects to spawn sub-objects that vary in certain ways from their ancestors--isn't built into the database. And, as noted, data is still stored in rows and columns, not in objects as in ODBMSs, which is inefficient. Nonetheless, "it is very fast. And don't kid yourself, ODBMSs require a lot of object reassembly, too," Rubin notes.

    Another company using the object/relational approach is Toronto-based The Bulldog Group, a software vendor that resells an RDBMS along with its application. Bulldog chose object/relational technology from Oracle and Informix to underlie its Bulldog 2.0 Media Asset Management, an application that allows storing, searching for, and retrieving digital audio, visual, text, 3-D images, and other complex data.

    "We turned away from the purely object-oriented DBMSs because most of our customers, which include entertainment and broadcasting companies, already had massive SQL installations," says Peter DeVries, Bulldog's chief technology officer. ORDBMSs interact more easily with traditional SQL data than do purely object DBMSs.

    DeVries predicts that within five years, the most vexing problem with linking object and relational technology--the inability to store most objects in a row-and-column framework, often called "the impedance barrier"--will be solved. These databases "will provide the construction and deconstruction for you. It won't be something you even have to think about," he says.

    Vendors that help solve the data dilemma

    Ardent Software:
    http://ardentsoftware.com

    The Bulldog Group:
    http://www.bulldog.ca/bd/

    Cloudscape:
    http://www.cloudscape.com

    Computer Associates:
    http://www.cai.com

    DataBean:
    http://www.databean.com

    Emergent:
    http://www.emergent.com

    Informix:
    http://www.informix.com

    InterSystems:
    http://www.intersys.com/

    Netroscope:
    http://www.netroscope.com

    Object Design:
    http://www.objectdesign.com

    Objective Insight:
    http://www.objectiveinsight.com

    Oracle:
    http://www.oracle.com

    Sybase:
    http://www.sybase.com

    Template Software:
    http://www.template.com

    Right now, the layer mediating between objects and row-and-column storage represents about 30% of the volume, maintenance, and development effort of an application, estimates Scot Powell, vice president of advanced architecture for Objective Insight, an object frameworks vendor in El Campo, Texas. If the application logic changes, the mapping layer must change, too. That means such changes are time consuming and labor intensive.

    Another challenge RDBMS vendors must meet is extending their indexing schemes from unidimensional--like hash tables and B-trees--to multidimensional, the type of indexes used in ODBMSs, Powell points out. Oracle handles true multidimensional indexing only through a separate product, although Oracle8 supports the star schema, a limited form of multidimensional indexing.

    Java and DBMSs

    Both RDBMS vendors and established ODBMS vendors had better watch out for an entirely new form of DBMS: those built with Java. This wildly popular programming language is being used to create small-footprint DBMSs that store Java-based objects natively. One of these DBMSs--JBMS, from Cloudscape, an Oakland, Calif.-based company--is poised to displace ODBMSs in several vendors' embedded applications, claims Malcolm Colton, Cloudscape's vice president of marketing.

    JBMS requires less than one megabyte of disk storage space. It's written entirely in Java, including the graphical user interface, application server, engine, stored procedures, and extensions. Although the same can be said of most ODBMSs with regard to C++, Java is emerging as far more popular, and simpler, than C++.

    One of Java's chief virtues is its portability. Java apps can run on any platform for which a Java virtual machine has been written. This platform independence was a key requirement for SoftCom, an Iselin, N.J., provider of Internet software and a user of Cloudscape. "We looked at Sybase and Oracle as possibilities to embed within LearningNet, which is a Java application for delivering training materials," says Ken Carson, the account manager at SoftCom. "They were too expensive, and they couldn't easily be moved from one platform to another. Using a Java DBMS, like Cloudscape, is far less expensive, and it gives us total portability."

    For more information from other Cahners resources

    Check out "What's All This About Object Technology?" from an August 1997 article in Control Engineering magazine: Object technology--embedded in the present--is a sign of the future. In 10 years, it may join the ranks of yesteryear's buzzwords, like integrated circuit. But today, object technology stands on the forefront of control system design.

    Java-enabled DBMSs are catching on, at least among vendors. Shortly, ODBMS vendor Object Design in Burlington, Mass., will announce a direct competitor to JBMS, a pure Java implementation of its ObjectStore ODBMS called Personal Storage Edition. DataBean, a software vendor in San Mateo, Calif., is also planning to release a JBMS competitor before the end of 1998. //

    Dan Richman is a Seattle-based freelance writer specializing in articles about high technology.

    Objects and the future of database management systems

    Short-term developments (one to two years out):

  • Most users learn what objects are and why they're useful.

  • All RDBMSs (relational database management systems) have become ORDBMSs (object/relational DBMSs).

  • Complex datatypes for Web creation and content become commonplace.

  • C++ begins yielding to Java as the ODBMS and ORDBMS language of choice.

  • Ability increases to manipulate, not just store, object data in ORDMSs.

  • ORDBMSs gain all the capabilities of RDBMSs, e.g., symmetric multiprocessing, replication, and distribution.


    Long-term developments (five years out):

  • Even hard-core mainframe and RDBMS users glom onto objects.

  • Microsoft enters the ODBMS market.

  • Most of the ODBMS vendors fold or move on.

  • Java-based ORDBMSs become mainstream.

  • Two versions of Java, one for Microsoft and one for everyone else, doesn't seem so bad.

  • As data becomes more complex, RDBMSs, still unable to support inheritance, are sometimes displaced by ODBMSs.

  • Standards make data more interchangeable among ODBMSs, DBMSs, and ORDBMSs.

  • RDBMSs can store procedures along with the data on which they operate (i.e., can encapsulate methods), probably through Java.

  • JDBC (Java Database Connectivity) spec is replaced by a combination of direct object-language bindings and object query language.

    Source: PlugIn Datamation






  • 0 Comments (click to add your comment)
    Comment and Contribute

     


    (Maximum characters: 1200). You have characters left.