Object Oriented Database Learning Center

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

Download a PDF version of this Article

Table of contents:

Object Oriented Database vs Relational Database

• Introduction
• The Wall: Where an RDBMS breaks down
• Programming Time and Cost
• Integrity Loss
• Performance
• Information Model Issues
• Architecture Issues
• Benchmark
• Benchmark Parameters
• Benchmark Execution
• Parts Creation
• Updates
• Deletes
• Selects
• Summary
• Examples
• Cimskil (Manufacturing)
• Exxon (Configuration and FEA)
• CERN (Data Gathering and Analysis)
• Decision•ism (Decision Supportware)
• QUALCOMM (Telecommunications)
• COM21 (Cable Modem)
• Nortel, Sprint (Cell Phone Base Station Management)
• Nousoft (Library Document Management, Web)
• Iridium (Telecommunications)
• BBN (Military Logistics and Control)
• Intraspect (Knowledge Management)
• Fisher-Rosemount (Manufacturing, Process Control)
• A Brief Overview of Our Development
• ODB Selection
• Introduction
• Performance
• Scalability
• Productivity
• Fault Tolerance
• Additional Features and Benefits
• Summary
• Kintetsu (Transportation, Logistics)
• Siemens (Process Control)
• SEH (Semiconductor Manufacturing)
• NEC (Semiconductor Manufacturing)
• American Meter (Process Control)
• Sloan Digital Sky Survey (Geographic Information System)
• LMS (Healthcare, Fetal Monitoring)
• Synthesis (Healthcare, Record Management)
• Daikin (Multi-Media CD-I Authoring)
• How to Avoid the Wall

Object Oriented Database vs Relational Database

Integrity Loss

Since the mapping from flat RDBMS data to the application data is done within the application, by application programmers, there is the danger (even assuming all programmers program perfectly) that one programmer will do this mapping differently from other another programmer, resulting in a mismatch in their work and integrity violations. Such integrity issues can be subtle and difficult to locate, requiring detailed examination and comparison of many application programs. The problem is not only that the RDBMS works only at a primitive (tabular) data level, forcing the application to do the mapping, but also that this mapping remains part of the application. Instead, in an ODBMS, there is no mapping required. The DBMS understands and directly operates on high-level structures (such as the automobile, the engine, etc.) as well as low -level structures (such as piston, bolt). Queries may be performed at any level. The DBMS understands the structures (as defined in the object model, directly from the object model) and supports direct access at any level. The application programmers are then freed from the responsibility of doing the mapping. Instead, that complexity of structure and relationship is captured in the DBMS itself, and hence is shared among all users. Therefore, they all share the some structures and relationships and are guaranteed to be compatible at all levels, avoiding this integrity risk.

This risk of integrity loss extends all the way to end users via front-end GUI tools (PowerBuilder, Microsoft Access, Visual Basic, etc.). Such tools communicate to the RDBMS at the only level the RDBMS understands; i.e., at the primitive, flat level. Any application structures above that are lost. It is up to the end user to know those higher level structures and to reassemble them out of the primitives. Any error in such reassembly, of course, leads to integrity violation. An ODBMS avoids that risk while supporting the same tools. Since the ODBMS understands the higher level structures, as well as their operations and relationships, and makes these directly accessible to the tools, the result is that the end user can work directly at this higher level. In fact, by using grant and revoke (access permissions), certain users and groups may be limited to access only certain structures, and only certain attributes or operations on those structures. This guarantees that integrity will be maintained.