The Legend of Data Persistence - Part 2

2. Types of ODBMS

Depending on how an ODBMS implementation chooses to persist objects, there are two types of ODBMS: non-native and native.

a. Non-native ODBMS 

In a non-native object database, there are two separate object models, one of the application and the other of the database itself.  ODMG-compliant ODBMSs are examples of non-native ODBMSs since they require a separate data schema to be defined, regardless of the existance of the application object model.  In order to query or persist objects from and to non-native object databases, the mapping between these two distinct models must be performed.  For ODMG-compliant databases, the schema is defined by the ODL and the application object model can either be generated from that schema or manually written by developers and then modified by a source-code or bytecode/CIL enhancers (as part of the persistent API, such as JDO, for that particular database implementation) to add persistent behaviors (e.g. to make the class an Active Record) and information (e.g. mapping information). 

While the separation between the application object model from the database object model gives non-native ODBMS the advantage of having its databases portable across applications, programming languages, and platforms, it is also the source of problems because application developers have to maintain both of these models as the application evolves.

b. Native ODBMS

In native object databases, objects are stored exactly as they are, without the need to map them into a different object model supported by the databases and vice versa.  In other words, in the world of native object databases, there is just one single object model: the application object model and thus, unlike non-native ODBMS, no ODL and common object model are necessary.  (Note that while no new object model is required, it does not mean that a native ODBMS cannot have its proprietary data format to represent the application object models in the data store.) 

The interesting thing is that one can easily implement a simple non-native ODBMS in Java, Ruby or a .NET language using the built-in serialization mechanism which can serialize objects into byte-stream, which can then be stored into a file or sent over the network, and deserialize objects from the same byte-stream.  With the serialization infrastructure, no extra work is necessary for storing objects’ attributes, associations, and inheritance information, and thus one will only need to add an object identification mechanism (e.g. assign an OID field to each object, either hand-coding or, more sophisticated, using bytecode/CIL enhancement [no need in Ruby thanks to its "open-class" feature]), a query API (e.g. query-by-example) and a simple concurrency system (assume the database is shared by just one application at a time, the built-in thread locking mechanism is sufficient) in order to have an ODBMS implementation ².

In contrast with its non-native counterpart, native ODMBS while simplifies the querying and persistence of application object model to the minimum, its databases are not easily portable across applications, programming languages and platforms.  In fact, for two or more applications to make use of the same database, they must have the exact same persistence classes bundled with them (same name, same package/namespace, and attributes with their types).  It is even harder for applications written in different languages to share the same database file because of the differences in naming conventions and base types (framework classes) ³.

Pages: 1 2 3 4

February 19th, 2007 in OOAD, Software Engineering, Technologies

Share this entry: