Object Oriented Database Learning Center

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

Table of contents:

Object Oriented Database vs Relational Database

The Wall: Where an RDBMS breaks down

The generation of Relational Database Management Systems (RDBMSs) has brought many benefits to users, including ad hoc query, independence of data from logical application, and a large variety of front-end graphical user interface (GUI) tools. It has served a large number of business applications, and the industry has grown to over $4B annually, including tools. Why, then, should we look beyond RDBMSs? We should do so only when necessary to s upport new kinds of applications, new media data types, relationships, distribution, and scalability. In fact, most applications have never used RDBMSs, and many that have are now looking for a better solution, such as ODBMSs.

Now three decades old, relational technology is showing signs of age. Although it works quite well when supporting simple, tabular data models, with short, simple operations, and centralized data storage and access, as in online transaction processing, or OLTP, anything beyond that encounters the "Relational Wall." This phenomenon is the result of applying the wrong tool (in this case, RDBMS). One might, for example, try to use a screwdriver to pound nails into a wall, and some nails might actually go in, but in the process many nails would likely break, along with screwdrivers and walls. Instead, using the right tool, a hammer makes the job much easier.

The relational wall is exactly the same; i.e., it is the result of using a table-based DBMS for non-tabular data, or a central server DBMS for distributed applications, or a centralized (and hence non-scalable) DBMS for large, enterprise scalable applications. The term "wall," though common in the literature, is a bit misleading, in that there is not a specific point where good turns to bad. Rather, as the complexity of the application increases, the mismatch between the RDBMS and the application grows. The same happens as data model complexity increases, as more relationships are managed, and as more distributed, scalable access is needed. The result is an explosion of tables, with slow joins between them, complexity difficult to manage, integrity loss, performance loss by orders of magnitude, all increasing. The user is left trying to squeeze his applications into tables, much like squeezing round pegs into square holes.

This wall is specifically a rapid rise exec ution time (slower performance), measured as complexity of the application increases. However, as we'll see below, it is also a rapid rise in the difficulty to change (loss of flexibility) the application and database. Also, a similar effect occurs in terms of extensibility; i.e., as complexity rises, the ability to extend applications, data models, and existing databases rapidly decreases. All these are aspects of "the relational wall."

Detailed measurement of the wall, and visual illustration is in the benchmark section, below. First, however, we'll review the concepts at a higher level, starting with a simple, but quite illustrative, example. Suppose you wish to store your car in the garage at the end of the day. In an Object DBMS (ODBMS), this is modeled with an object for the car, another for the garage, one operation "store," and you're finished. In a relational system, on the other hand, all data needs to be normalized; i.e., it must be flattened to primitives and sorted by type. In this example, it means that the car must be disassembled, down to its primitive elements, which must each be stored in separate tables. So, the screws go in one table, and the nuts in another, and the wheels, and side panels, and pistons, etc. In the morning, when you wish to drive to work, you must first reassemble the automobile, and then you can drive off.

This may, perhaps, sound exaggerated. However, it is not very different from many applications we've seen. Whenever the application has complex (non-tabular, varying sized, interrelated) data structures, the application programmer must write code to translate from those data structures down to flat tables. This translation code has three problems: