Object oriented databases

Software solutions are developed to fill in business process, they  apply or represent (for companies) how business or part of the business is being done, they have interface throw which the users interact with systems, business logic that applies rules and best practices and finally data.
Data is one of the most important parts of software-applications, it represents the entities and information that the software deals with. This information is important and sensitive and might be persistent, so creating objects and maintaining them within the application context (in memory) is not feasible; this is why thinking about the best and appropriate method to store software data and information in a permanent support is required.

In the earliest ages of computing, disk space was a critical resources and very expensive and the only available methods of storing data were on system files in binary or flat format. This method has been used for long time and is still being adopted for small needs and simple requirements of storing and/or retrieving small amount of unstructured data.

In the last decent we have noticed an important jump in term of processors speed and storage size, we can say that actually we don’t really care about disk as in the past. This coincided with the new trend of software programming; the OOP which both allowed the development of complex solutions with different entities representing real software context (ex, CRM systems where the software deals with products, customer, orders… etc.) and storing such data in a flat files in unacceptable.

The best and appropriate method for storing software objects and data is in a database, it allows an easier manipulation of data with certain level of security, in addition to the isolation of the data access logic from the software business one. But even with databases, we should make a decision on what type of DBMS should we adopt for the software. In fact, different types of data base management systems Relational, Hierarchical or OO DBMS.

OODB
In the mid 1980s, a new form of databases emerged and a lot of discussions about differences between OODB and Relational databases rose. Object oriented data bases is a DBMS where data is represented as objects (Ling.et.al, 1995)

As defined by (Prabhu, 2005), OODB defines the database schema structure with strict tree architecture. Here is a simple example of an OODB

Differences between OODB and Relational DBs
In relational databases, data is stored as attributes in tables linked with keys (primary and foreign keys), data is identified with unique keys assigned at their creation and remains during the whole lifetime regardless their states.
One of the issues or questions about OODB is whether code should be stored in the database this question divided the community of OODB; many developers thought that using this approach affects significantly performances, while others argued that if code was not stored in DB a well-known semantic anomalies might happen (Norrie.et.al, 2009).
I personally have never used OODBs, and took part of development projects where objects and their data were stored in relational database. The weakness of this implementation, is that data access layer is closely developed based on the OO design. i.e. if the objects definitions change, the database schema and access methods have to be altered too. Whereas, if we opt for storing data as objects in OODBs, it seems to hide or bypass this level of complexity.

References:

– Tok W. Ling, Alberto O. Mendelzon, Laurent Vieille (1995). Deductive and Object-Oriented Databases. Fourth International Conference DOOD 1995. ISBN: 3-540-60608-4.

– Moira C. Norrie, Michael Grossniklaus (2009). Object Databases. Second International Conference, ICOODB 2009, Zurich. ISBN:978-3-642-14680-0.

– C.S.R. Prabhu (2005). Object-Oriented Database Systems: Approaches and Architectures. ISBN: 978-0-12041-9