Evolution Towards Object Oriented Paradigm
Relational Database System proves to be a powerful tool for maintaining and storing data. But there are certain complex applications which involve highly interrelated and complex data such as audio, video, digital signatures, product specifications,bills, excel sheets etc. OODBMS is used to provide support to such kind of applications and to deal with complexities produced by these applications.
Consider ‘ emp-dept’ relationship as discussed previously. Now, also, suppose the company wants to store information regarding employees, departments and their projects along with the image and digital signature of each employee. Beside this company also wants to store clips of undertaken projects which describe the features of concerned project so that it’s easy for the ‘sales’ department of the company to sale the project to the clients according to their requirements. Besides the requirement of having such complex objects, this database also require certain features like :-
1. Inheritance-: It is the process by which an object acquires the properties of some existing or higher level objects. It reduces the need of defining an object each time when a new but similar object is created.
In other words we can say that the Inheritance allows us to reuse the behaviour of a class in the definition of new classes. Sub-classes of a class inherit the operations of their parent class and may add new operations and new instance variables.
2. Object Identity-: It helps in referring the complex objects rather than storing the object every time. For example, above mentioned schema contain video clips showing project demonstration. It is not an easy task to store copies of these video clips at different places thus a unique identity or a reference to the video is created which refer to the original copy of that object, wherever required.
We could store these images and videos as Binary Large Objects (BLOB) in RDBMS. A binary large object is just a long stream of bytes. BLOB consists of several pages unlike traditional attributes but most of the relational data bases restrict the size of record to simplify buffer management and free space management since the problems in managing large objects are due to buffer pages. Certain applications which require OODBMS approach rather than traditional model are discussed below :-
1. Embedded DBMS Applications-: It involve database on partially connected mobile devices or applications that demands very fast response time. This requires a self contained & easy to deploy persistent solution for client side or in the middleware.
For such applications, RDBMS requires object relational mapping, which result in increasing demand of resources. OODBMS model creates the data as objects and provide support for classes of objects and inheritance of class properties which does not consumes much resources.
2. Complex Data Relationships -:In such applications, classes have multiple cross references among themselves. Applications that involve network data structure fall into this category.
Complex cross referencing can be difficult and error prone in RDBMS. In RDBMS relationship among objects ideal with foreign keys. So fetching an object and then fetching the object it refers results in complicated and difficult code maintenance. OODBMS engine handles the details of maintaining the references when objects are stored and satisfying them when objects are referred.
3. Deep Object Structure-: In such applications, all the data cannot be easily organized into tabular form of RDBMS. RDBMS cannot easily translate highly connected object structure like a deep tree structure, having a lengthy parent child relationship, grand child relationship etc.
4. Changing Data Structures-: In such applications, there is good probability of adding new data members or new object relationships. In RDBMS, if schema is changed then we have to alter the query code to handle the changes whereas, OODBMS allows us to change structure ‘on fly’. If a new object has some additional field then it is simple to read an old object into new application with additional fields having default values. If the new object has fewer fields then the non existent fields are skipped while reading.