This is one of the greatest limitations of this technology. A second major disadvantage of RDBMS-based systems is their lack of support for image- and spatial-based databases that include Computer-Aided Design (CAD) drawings, 3D rendering and model-based data. Their table-based structure is inefficient in defining the attributes of these data types and lacks the necessary data tagging and data types to manage imaging and CAD-based design files and data sets. Object-Oriented Database Management Systems (OODBMS) are more adept at managing graphical data elements and indexing them for future use (Lungu, Velicanu, Botha, 2009). A third limitation of RDBMS architectures is the lack of support for defining complex interrelationships of data, which is often required for data mining and the intensive analysis used for sentiment and content analysis of social networks for example (Seng, 2003). The emerging areas of latent semantic indexing (LSI) and linguistic analysis, two critical technologies the Google search engine and PageRank algorithm is based on, requires more advanced data structures than RDBMS systems provide. As the need for interpreting and managing extensive amounts of data generated from social networks and content management systems continues to expand, the need for database architectures that can scale to analyze, interpret and define complex relationships within these data sets continues to push database technology forward. As a result, RDBMS is finding its greatest value in transaction systems where there are many smaller transactions and the frequency increases over time. This is one area where the next database technology, Object-Oriented Database Management Systems (OODBMS) is showing potential in intensive data mining and linguistic modeling applications (Lungu, Velicanu, Botha, 2009). Fundamentals of Object-Oriented Database Management Systems

The foundation of the object-oriented database management system (OODBMS) are the architectural definitions used for defining entities, their attributes, and the definition of how they integrate to other objects within linked databases. The RDBMS database architecture has more shared attributes than the OODBMS database architecture has. As a result, RDBMS has become a market standard and continues to be one today. While every enterprise software vendor interprets and creates a variation of the RDBMS architecture, there is enough shared technology to ensure integration and interoperability. This is one of the fundamental differences between RDBMS and OODBMS. On the OODBMS architecture, there is less commonality in how software vendors have implemented this architecture between their individual products. This lack of standardization has slowed the adoption of OODBMS throughout enterprises and has also led to instances where one OODBMS-based database cannot integrate to another (Subramoniam, Tounsi, 2009).

Despite this significant architectural differences, all OODBMS systems share common attributes however. The first is the definition of the data element as an object. In the context of an OODBMS, an object is defined as a set of attributes or attribute-related data that is used for defining the role, structure and integration of an object throughout the database. OODBMS encapsulates both the data and the actions to be performed on it, the integration points through the database, and the data attributes. Data and the actions, workflows and processes to be taken with it are contained in the same object. Second, OODBMS application suites vary significantly by vendor yet all also share the concepts of inheritance, where the attributes of the upper class objects are passed on to the lower-class objects as functions are called within the application. A third common factor across all OODBMS architectures is reuse of components and objects that are part of the programming structure of this database. Reuse of objects has led to the broader adoption of OODBMS-based systems through scientific and engineering application area yet has not led to a breakthrough into mainstream enterprise system development and deployment. These three common characteristics of OODBMS architectures unify this area of database design yet also lead to its being used in more specialized applications, which are defined in the next section of this analysis.

Purpose of Development and Functions

The basis of the OODBMS architecture is the definition of data as objects and classes. Classes of data can be defined through the use of taxonomies, data modeling and data classes, all dependent on the preferences of the database architects and programmers creating the application. The data objects within an OODBMS are also defined by the inheritance of attributes, data definitions and data rights. The inheritance model of the OODBMS architecture is predicated on the primary level or upper class levels of objects propagating attributes, data definitions...

This inheritance aspect of the OODBMS architecture is critical for ensuring consistency and compatibility throughout the network of objects that comprise the data structures. The OODBMS architecture is designed to provide for data persistence, in addition to data and process-related concurrency. These functions within the OODBMS architecture enable higher levels of fault tolerance as data persistence ensures applications will continue functioning even when errors are encountered in applications, and concurrency provides for parallel processing. Despite the limitations of OODBMS relative to RDBMS, it continues to be used in many image-intensive applications. Object-oriented languages including Ruby on Rails, Python, the programming language of Google, Perl, Java, C# and Cincom Smalltalk all have contributed to the growth of OODBMS.
Advantages and Disadvantages

The following is an analysis of the advantages and disadvantages of OODBMS. The advantages of this database technology include support for composite objects and relationships, support for a class hierarchy that can easily be used to match the taxonomies of information and data extraction organizations need, reliance on one data model and no need for a complex query language. In addition, there is no need for key-based definitions as an OODBMS relies on Object Identifiers (OID).

The disadvantages of OODBMS include the difficulty in changing schema definitions and structures, a high degree of language dependence to the API level, and lack of support for ad hoc queries. There is also the limitation of a rigid definition of object and action workflows that has slowed the adoption of this specific type of database over time.

Comparing Object-Oriented vs. Relational Database Management Systems

In analyzing the differences between RDBMS and OODBMS, it's clear that a series of strengths and weaknesses apply to each depending on what the need is within an organization or business. For transaction-intensive applications that involve hundreds to thousands a day, an RDBMS is ideal. The table structure, support for arrays and use of pointers all make the creation of complex data structures possible. The use of relational indexing and file structures also transform multiple data records into a single system of record in larger, more complex processing environments. The series of technologies that comprise OODBMS make this database architecture ideally suited for more graphical data analysis, indexing and workflow development. Applications created on top of the OODBMS are ideally suited for use in CAD, image analysis and image indexing applications. The fact that the OODBMS architecture integrates data and workflow or activity into the same object is highly efficient yet limiting for managing transaction-intensive data analysis.

Conclusion

Each of these technologies has a unique set of benefits that must be aligned to specific needs in organizations and enterprise over time to be effective. For the majority of business uses, the RDBMS architecture and its ability to manage thousands or millions of transactions a day make it ideally suited for business and commercial applications. The OODBMS architecture on the other hand is more suited to those application areas where graphical data and workflows matter most, which include the areas of scientific and engineering research.

References

Antoniotti, M., Carreras, M., Antonella, F., Mauri, G., Merico, D., & Zoppis, I.. (2010). An application of kernel methods to gene cluster temporal meta-analysis. Computers & Operations Research, 37(8), 1361.

Thomas M. Connolly, & Carolyn E. Begg. (2006). A Constructivist-Based Approach to Teaching Database Analysis and Design. Journal of Information Systems Education, 17(1), 43-53.

Evermann, J., & Wand, Y.. (2009). Ontology-Based Object-Oriented Domain Modeling: Representing Behavior. Journal of Database Management, 20(1), 48-77.

Zhen He, & Jerome Darmont. (2005). Evaluating the Dynamic Behavior of Database Applications. Journal of Database Management, 16(2), 21-45.

Hyun-Joo Lee, Sang-Won Lee, & Hyoung-Joo Kim. (2005). Design and implementation of an extended relationship semantics in an ODMG-compliant OODBMS. The Journal of Systems and Software, 76(2), 171-180.

Lungu, I., Velicanu, M., & Botha, I.. (2009). Database Systems - Present and Future. Informatica Economica, 13(1), 84-99.

Jia-Lang Seng. (2003). A study on industry and synthetic standard benchmarks in relational and object databases. Industrial Management + Data Systems, 103(7), 516-532.

Suresh Subramoniam, & Mohamed Tounsi. (2009). An object oriented intelligent environment for ERP systems. Business Process Management Journal, 15(1), 109-118.