Object Oriented Database Learning Center

Objectivity Home - Government - Objectivity/DB - Webinars - Download Software

Table of contents:

Object Oriented Database vs Relational Database

Iridium
(Telecommunications)

Iridium, a $7B consortium headed by Motorola, is a satellite-based, wireless personal communication network designed to permit any type of telephone transmission—voice, data, fax, paging, to reach its destination anywhere on earth, at anytime. Although the full system will not be operational until 1999, several applications are now in production. The system includes over 66 low -earth-orbit (LEO) satellites, in order to work at low power with small (antennae and devices). This means, though, that satellites orbit the earth in less than 90 minutes, so during a typical telephone conversation, messages must be dynamically rerouted from one satellite to another. The developers describe the Iridium switching problem as equivalent to re-configuring an ATM switch every 4 minutes. Objectivity/DB is used in the base stations, for satellite routing and rerouting, and message routing and rerouting, as well as network management.

Iridium Handheld Wireless Communication Anywhere and Anytime

One application involves storing Mission Plans, a hierarchical description of the state of the satellite, from antenna to modem. The plans are for long periods of time (8 hours), with time-series like arrays of data for each time, giving state information for various times. The plan is updated every few hours and constantly referenced other times. Such dynamically varying sized structures are well supported by ODBMS, but not by RDBMS.

They have three facilities, each with ~50 Sparc20 servers and workstations. These facilities, in Phoenix, Washington DC, and Rome, are linked internally and among each other and 20 gateways as one distributed system. The distributed ODBMS single logical view was critical for this. They expect to generate 10 Gigabytes of data/day and will need to keep ~5 days of data online, requiring scalability. Other database problems include network management (node management, fault management), satellite control (commanding, telemetry, orbit management), and mission planning (resource scheduling).

For resource scheduling, modeling issues require complex, multi-versioned objects so they can create plans and alternate plans for satellites, communication paths, etc. This is compute intensive, generating 10-30GB/day, with 100 concurrent clients.

Another, related application chose to use an RDBMS. They experienced first hand the difficulties of attempting to use an RDB with a complex data model. The bottom line was that they found it impossible to keep an RDB schema mapped to an OO design. The schema was always 2 weeks behind. Eventually they abandoned the approach and went to file based persistence in order to make the first release. A decision to use Objectivity/DB in the second release was later made, in order to regain the DBMS facilities of recovery, concurrency, scalability, and distribution.

According to the lead database architect for Iridium:

"We had chosen to go with OO technology early in the program for good reasons that I will not go into. Sybase was chosen as the defacto database. Several of us in the architecture/analysis team felt that for a complex database problem, the benefits of going OO would be negated if the database backend was an RDB.

Management here was already suffering from technology -panic. Consequently we had to explicitly examine every single alternative before making the OODB/Objectivity decision. We looked at Hybrids (UniSQL, OpenODB, Matisse), object gateways (Persistence), glorified C++ DMLs (DBTools.h++) etc. We talked to at least 20 customers, and did about 4 separate benchmarks. Our conclusions were that you either go with RDBs or OODBs. The other choices were neither here nor there.

During the evaluation process, it became clear to me that there seems to be a gross oversimplification on how easy it is to translate OO data models into relations. Having written a developer's guide to do this, having seen how much code is generated by the "Persistence" tool to automatically translate OO schemas to RDB application code, having used DBTools.h++ to write code that views the RDB from C++, I for one have no illusions about this.

I must point out that OODBs are not a panacea. Applications such as billing are fairly relational. However, in things like satellite mission planning, network management and satellite control, one has to explicitly represent mission plan objects, managed objects in the network and their relationships etc. Most of the time, there are a fair number of associations between these objects, and obviously considerable use of inheritance in the model. Translating all this to tables is very cumbersome. Not to mention that large designs tend to change, often quite a bit. Having an RDB is like sticking a magnifying glass on your OO design. If a change looks scary in your OMT model, watch out for its effect on the RDB schema. Anytime you try to isolate your RDB from schema changes (say by using foreign keys for every association), you pay serious performance penalties.

Going with OODBs for purely performance reasons is probably misguided. However, if you have a non-trivial OO application, your engineering risk in terms of coding and maintaining the application are much greater with RDBs than with OODBs. Out of curiosity, I asked the DBTools.h++ people if they saw a groundswell of OO applications using their product. I was told that most of their customer bas e is and remains people who are reverse engineering the database to be readable by C++ applications. To me that is the market speaking."