RDBMS versus ODBMS
DBM 380: Database Concepts
Mark Stone
September 22, 2002
A
Contrast in Style
The relational database management system (RDBMS) and the object database management system (ODBMS) are both ways of managing databases. In the new world of high speed Internet access, there needs to be more than data in databases. Now we have objects to catalog, file, secure and manage.
First and foremost, object and relational databases are different beasts. Relational databases (RDBMs), first designed in the early 1970s, were originally meant to provide an incredible amount of flexibility in the way simple data is processed and made available to users. Object databases (ODBMs), first designed in the 1980s, were meant to handle the complexity of data and relationships required by the object model of development. Object databases initially took hold as repositories for CASE and CAD applications. Today, they are widely used in network-management systems across industries, in publishing systems, in advanced financial systems, and in other application areas not well served by relational-database technology.
Beyond the technical issues surrounding which DBMS is better for the job is the rather important issues of staffing and training. RDBMSs have become so pervasive that finding qualified personnel to work with them is not a serious challenge. Locating sources of education and training on the most popular RDBMSs is also not a problem. The same cannot be said for ODBMSs. You will have difficulty finding an ODBMS expert for your staff if you choose to use one. If you're doing anything complex, there are only a few in the world. It is true that in order to gain a surface level understanding of an ODBMS, you simply need to know C++ or Java. But the leap from having a good, solid, working knowledge of how to use it optimally, is another story. While you'll read many stories of poor developers who developed poor applications with an ODBMS, you'll also find many stories of good developers who simply didn't have the knowledge or foresight to get it right with an ODBMS.
The chart below compares RDBMS to ODBMS. As you can see ODBMS is for the programmer, where RDBMS is more suitable for the end-user. On the other hand, RDBMS is not extensible and takes careful attention to detail to handle complex relationships.
Criteria |
RDBMS |
ODBMS |
Defining
standard |
SQL2
(ANSI X3H2) |
ODMG-V2.0 |
Support
for object-oriented programming |
Poor; programmers spend 25% of coding time
mapping the program object to the database |
Direct
and extensive |
Simplicity
of use |
Table
structures easy to
understand; many end-user tools available |
OK
for programmers; some SQL access for end users |
Simplicity
of development |
Provides
independence of data from application, good for simple relationships |
Objects
are a natural way to model; can accommodate a wide variety of types and
relationships |
Extensibility
and content |
None |
Can
handle arbitrary complexity; users can
write methods and on any structure |
Complex
data relationships |
Difficult
to model |
Can
handle arbitrary complexity; users can write methods and on any structure |
Performance
versus interoperability |
Level
of safety varies with vendor, must be traded off; achieving both requires
extensive testing |
Level
of safety varies with vendor; most ODBMSs allow programmers to extend DBMS
functionality by defining new classes |
Distribution,
replication, and federated databases |
Extensive |
Varies
with vendor; a few provide extensive support |
Product
maturity |
Very
mature |
Relatively
mature |
Legacy
people and the universality of SQL |
Extensive
supply of tools and trained developers |
SQL
accommodated, but intended for object-oriented programmers |
Software
ecosystems |
Provided
by major RDBMS companies |
ODBMS
vendors beginning to emulate RDBMS vendors, but none offers large markets to
other ISVs |
Source: International Data Corporation, 1997
RDBMs and ODBMs are truly complementary technologies: If an application has relatively simple data, simple data relationships, and a static schema, a relational database engine is usually a good choice; if an application has relatively complex, interrelated data, or if the database schema may evolve rapidly over time, an object database is a more likely fit. Obviously, many shades of gray affect these positions. For example, relational databases are being given object front ends and being extended to handle complex data types, while object databases are providing standard interfaces to access stored objects. In addition, ODBMs tend to be more intimately tied to a given application, given their direct linkage to the object programs.
The problem with using newer object-oriented databases to handle traditional data isn't that the ODBMS can't handle the alphanumeric data, but rather that SQL-based RDMBS are more mature and easier to use. However, with the alphanumeric stuff RDBMS is better. The table structures with RDBMS are easier to understand. Not only that, but there's a lot more end-user tools to draw information out of a relational database, as opposed to an object-oriented model, where there's really nothing so far.
Conclusion
Databases of all types are critical to Internet computing. Since much existing corporate data is already stored within relational databases, they have an important role in providing content for Web-based applications and sites. However, object databases are highly appropriate and can supplement the computing infrastructure. In fact, since the Web is nothing if not dynamic, filled with complex relationships and multimedia content, and open from anywhere, an object database can easily provide a flexible front end for the enterprise.
Okowire (2002, September 23) Object and Relational Databases
[Online]. Available:
http://www.okowire.com/Articles/Simplification/ODBvsRDB.htm
Mellman J (1996, September) Object
Database on the Web
[Online]. Available:
http://www.newarchitectmag.com/archives/1996/09/mellman/
(2002, September 23) Architecture
Differences Between RDB and ODB
[Online]. Available:
http://cclab.ocit.edu.tw/dim41/oodb/main/ZL4J3P4.htm
Cummer L. (1998, January 25). IT
world getting excited about object databases.
[Online]. Available: http://cma.zdnet.com/texis/techinfobase/techinfobase/display.html?docid=20303453