The Legend of Data Persistence - Part 2
In Part 1 of this article, I have discussed about the Object-Relational (O-R) impedance mismatch, the problem it causes as well as the pitfalls of some O-R/M tools. In this part, I will examine Object Database Management System (ODBMS) and compare it with Relational Database Management System (RDBMS).
1. What is ODBMS
Basically, an ODBMS is a DBMS which stores objects as opposed to rows or tuples in respectively a SQL or a RDBMS [Wikipedia, Object Database] and bornt out of the need for transparent and non-intrusive persistence of complex object model, tasks which could not easily be addressed by RDBMS because of the O-R impedance mismatch. As a DBMS, besides being a data respository for storing object graphs (together with their identities, attributes, associations, and inheritance information), an ODBMS would, at the very least, include a query engine, a concurrency management system, and a data recovery mechanism. (The very first effort to define the features of ODBMS was the ODBMS Manifesto first published in 1989 by Malcolm Atkinson et al.)
Standardization
Before examing the types of ODBMS, it’s worth to learn about the ODMG (Object Data Management Group), which is a standardization committee established in 1991 with the goal of promoting the adoption of ODBMS via the creation of standardized ODBMS specifications. In 1999, the latest version of the ODMG specification (3.0) was released with the four major components:
- Object Model: defines the common data model (which is a common denominator for OO database systems and programming languages) to be supported by all ODMG-compliant ODBMSs. With this common data model, object definitions within object databases can be portable among different applications, programming languages, and platforms
- Object Specification Languages: include Object Defition Language (ODL) and Object Interchange Format (OIF). ODL is used to define the database’ object schema and is equivalent to the Data Definition Language (DDL) in the relational world. On the other hand, OIF is a means to dump and load the object databases’ state to and from files (e.g. XML files) (e.g. to support the exchanging of objects between different object databases)
- Object Query Language: is a query language based on SQL 92 and is equivalent to SQL in the relational world. OQL supports the querying of complex objects, polymorphism and late-binding calls, and is interoperable with specific language bindings
- Language Bindings: written for C++, Smalltalk, and Java and expose a persistence API so that these languages can interact with ODMG-compliant object databases
Despites this standardization effort, as of 2001, there was no ODBMS fully compliant to all ODMG standards [Barry, 2001]. In this same year, the ODMG disbanded as the member companies decided to concentrate their effort on the Java Data Objects specification, which was resulted from the ODMG Java Language Binding submitted to the Java Community Process. In 2006, the Object Management Group (OMG) announced that they would develop a new specifications on the ODMG 3.0 specification and has yet to release any specification since then. As a result, while many standards (including SQL and the mathematics-based relational model) have been consistently adopted by virtually all RDBMS vendors, widely adopted ODBMS standards simply do not exist yet.
[...] Part 1, I will discuss about the object-relational (O-R) impedance mismatch, its consequences, and ORM [...]
[...] Part 1 and Part 2 of the article entitled The Legend of Data Persistence, I have introduced you to the O-R impedance [...]
Your entries about OODB are very nice. I am a novice of OODB. And they are useful to me. Thank you.
@New Age: You are welcome! I’m glad it’s helpful to you.
Hi. I’m wondering what happen when the source code of the application is lost and you need to move data to a new application.
@tibbs: I’m not exactly sure what you mean. If you’re talking about a “new application” here then what is the deal with the old app (whose source code is lost)?