Introduction to Object-Oriented Database

objrct-oriented databases

objrct-oriented databases

With the fast growing need to serve the demands of an ever-growing population with an even faster rate of growth of their requirements, client-server applications that use database to store data prove their viability. Conventionally, relational databases were used-almost in all the cases, even the ones involving manipulation of large complex data- for storing data and object oriented programming languages were used for building the application. This generates the need to keep changing the objects (not the facts and figures, just the way of storing them) in order to accommodate them into the rows and columns of the tables and vice versa. Object database or object oriented database management system(OODBMS) came up in the 1970s to tackle this problem, allowing the data to be stored in the form of objects, hence rooting out the need to bring about any change in objects just for accommodating them in tables, and making the entire process a lot simpler. Object databases are like the part of the human brain from where the stored information can be taken out easily and conveniently. An object is an identifiable entity with some characteristics and behaviour which are maintained and implemented through variables and methods. The concept of OODBMS came up out of the need to store, manage, manipulate and retrieve complex data conveniently and efficiently. 

Object databases are capable of working in integration with object orientated programming languages like C++, Java etc, which makes them extremely efficient in handling complex data, that otherwise requires long codes and time-consuming methods when handled using the conventional relational database management systems(RDBMS). This property also means that they carry some of the same features as the concerned application does, including encapsulation (packaging of data and functions into single component using classes), inheritance (the capability of one class to derive properties from another class) and the ACID properties (Atomicity, Consistency, Isolation, Durability); which are some of the useful features offered by object oriented programming environments. Unlike relational databases which use table joins to connect tables and to store, relate and retrieve data, in OODBMS objects carry a many-to-many relationship and are retrieved using pointers. 

These databases use a unique object identifier (OID) for each object. The OIDs, permanent and system generated, are used for reference to objects. This essentially means that the user does not have to worry about uniquely identifying the columns using primary keys and by inputting different values. However, this can become a bit problematic in case the object having a particular OID is deleted and the other objects that contain reference to that object still exist. When a particular entry is fetched from a database, it’s cache is created in the application, after which it can be modified in two ways: the first one “disconnects” the cache from the database and hence any change in the object’s cache won’t be reflected in the database, while the second one allows the changes to be mirrored in the database and any change in the object in database requires it to be re-fetched from the OODBMS. It can contain objects with large number of classes and subclasses and yet perform the required tasks efficiently, no matter how complex or interrelated the data is. This is the case where relational databases may fail miserably as it requires creation of numerous tables with many columns and appropriate interlinking of the tuples. The probability of errors is quite significant and so is the unnecessary time-consumption. 

Although OODBMS has certain advantages over RDBMS, it makes things a bit difficult when user enters an Ad-hoc query – since data cannot be just “added” to it because it would require changing the object and hence the longer the code is, the more time-taking the process would be – whereas with the RDBMS, user can simply create more tuples and then join the tables using foreign keys.
All in all, the concept of OODBMS has proved its viability in managing complex data efficiently, especially in the cases where each object contains many fields within itself. Thus, the consistency of database with the application makes the entire process simpler, time-saving, more efficient and better related to the real world as objects are better representatives of real world entities than relational tables.

Leave a Reply

Your email address will not be published. Required fields are marked *