An Overview of Object-Oriented Database Management Systems

Object-Oriented Database Management Systems by: Chuck

The construction of Object-Oriented Database Management Systems began in the mid-1980s, as a prototype building level. At the beginning of the 1990s, the first commercial systems appeared. The interest in the development of these systems was pipiquedfrom the need to accommodate the modeling deficiencies of their predecessors.

Three characteristics are present. Initially, the object-oriented model lacks a common data model. There is no common data model although, many proposals can be found in the literature.

This is a more general problem in all the object-oriented systems not only the database management systems. Since the data model determines the database language of the system, which in turn, determines the implementation of the system, it is understandable that the differences between the various systems with different data models can be substantial.

Second, is the common theoretical framework. Although there is no standard object-oriented model, most object-oriented database systems that are operational or under development today share a set of fundamental object-oriented concepts.

Therefore the implementation issues in OODBMSs that arise due to these concepts are universal. The third characteristic is that of experimental activity. Plenty of prototypes have been implemented and some of them became commercial products. There is a need for applications to handle very complex data and that is why the interest of people in building such systems is so strong.

mid-1980s

• mandatory features: these are the features that one system should have to deserve the title OODBMS.
• optional features: these are the features that if one system has, should be considered better than another that does not have them, provided that both have all the mandatory features.
  Get quality help now

  

  Dr. Karlyna PhD

  Verified

  Proficient in: Database Management System

  4.7 (235)

  “ Amazing writer! I am really satisfied with her work. An excellent price as well. ”

  

  +84 relevant experts are online

  Hire writer

• open choices: these are features that a designer of a system can choose if and how to implement. They represent the degrees of freedom left to the system designers.

An OODBMS should be a database management system and at the same time an object-orientedreal-world system. The first characteristic is translated to the following features: persistence, concurrency, recovery, secondary storage management, and ad hoc query mechanisms. The second characteristic is translated to the following: composite objects, object-identity, encapsulation, inheritance overriding and late binding, extensibility, and computational completeness of the database language used.

Composite objects can be built recursively from simpler ones by applying constructors to them. These simpler objects can be integers, characters, strings, booleans, and in general objects of types that all the programming languages possess. There are various constructors such as list, set, bag, array, tuple, etc. The minimal set of constructors that a system must have is: set (to represent unordered collections of real worldreal-world objects), list (to represent ordered collections of real-world objects), and tuple (to represent properties of real-world objects). A system that supports composite objects and therefore constructors for their building should also support operators for the retrieval, insertion, and deletion of their component objects. That means that the database language should be extended in a way that these operators will be included.

The identity of an object is what makes it different from all the other objects. This allows the objects to be independent of their values. Therefore the notion of identical objects is introduced: two objects are equal if they have the same values, but are identical if they have the same object identity. The fact that each object possesses an identity facilitates the handling of composite objects since it makes the common use of objects possible and it protects the consistency of the database. If a component object is changed, this change affects all the composite objects that reference it. Due to the object identity, there is no need for replicates, and that is how the consistency of the database is protected. parts

The mechanism of encapsulation allows the hiding of the internal state of the objects. The internal state of an object is not liable to direct access. It can only be accessed by its methods. Objects that have this ability are called encapsulated objects. There are many types of encapsulation including: full, write, and partial. Using fullencapsulation, all the operations on objects are done via message sending and method execution. In write encapsulation, the internal state of the objects is visible only for reading operations.

Partial encapsulation involves allowing direct access for reading and writing for only a part of the internal state (private and public parts). The use of the same message for different methods that belong to different classes can facilitate the design of the database as well as of the applications that access it.

In general, since the internal structure of an object is not visible to the other objects, we can assign methods with the same functionality and the same message even if their implementation is different. This is called overloading of the message. Since a message can correspond to more than one method, the code of the method that has to be executed can only be found at run time. That means that while an application is executed, it can be found if the message sent applies to the object. If not the application ends up with a run-time error. The fact that the piece of code that should be executed is bound at run-time is called late binding.

The hierarchies of the classes are based on the principle of inheritance which is considered one of the most basic object-oriented systems. Inheritance is an antisymmetric, transitive, binary relationship that can exist between two classes A and B from which the A is called a subclass of B and B is called a superclass of A. The relationship has many common characteristics with the ancestor/descendant relationship since a class has direct and indirect subclasses as an ancestor has direct and indirect descendants. In general, a superclass can have one or more direct subclasses, although the number of direct superclasses that a subclass can have is not the same for all the models. In fact, in all the models, all the classes have at least one superclass butsome models doo not allow classes to have more than one. These are called single inheritance models and the rest mulare tiple inheritance models. According to the concept of inheritance, the subclasses can inherit methods and attributes from their superclasses. That means that inheritance is the mechanism that allows the generation of new software modules from existing software modules. There are four kinds of inheritances that have slightly different semantics:

• Substitution inheritance: if class A is a subclass of class B, then any object of class B can be substituted by an object of class A. That means that the set of messages that constitute the interface of class A is a superset of the set of messages of class B.
• Inclusion inheritance: if class A is a subclass of class B, then objects of A and B have the same internal structure although they may share the same methods and messages.

This kind of inheritance corresponds to the notion of classification.

Constrain inheritance: if class A is a subclass of class B, then any object of class A has the same internal structure as an object of class B but also satisfies a certain condition e.g. if “child” is a subclass of the class “person” and they share the attribute “age”, then any instance of the class “child” must satisfy the condition its age to be less than 10.

Specialization inheritance: if class A is a subclass of class B, then the set of instances of A is a subset of the set of instances of B. One of the necessary constituents of a DBMS is the data definition and manipulation language (DDML), also called database language. The use of this language allows persistent data to be created, updated, deleted, or retrieved. The database languages that were used by the RDBMSs were based on the relational calculus or the relational algebra and hence were not computationally complete although mathematically founded.

An OODBMS should have a computationally complete database language because it can be used for the methods of the classes, fand or applications that are written in the same language, there is no need for ofortransformation of the data structures or mapping of the data (impedance mismatch), and programmers do not need to learn another language if they choose to write their applications using this language.

The designers of the OODBMSs that currently exist preferred to use as database languages some of the most popular programming languages (C++, Smalltalk, Common Lisp, etc.) than creating their own. To do this, however, they had to expand the semantics of the language they chose in certain ways so that persistent data could be handled. Besides, if the language chosen was not an object-oriented one, its semantics should be further expanded in a way that the object-oriented concepts could be included.

Each database system comes with a set of predefined types (integer, real, char, string). This set should be extensible i.e. the user should be able to define his/her types and treat them in the same way he/she treats the predefined ones. In other words, user types and system types should have the same status although perhaps they are differently supported by the system itself.

Persistence is one of the most basic features of a DBMS (at least the most evident one) and hence of an OODBMS. The programmer can have his/her data survive the execution of a process so that he/she can eventually reuse it in another process. For an object-oriented system, there is an additional requirement, which stems from the extensibility requirement, that any object must be able to become persistent independently of its type. The secondary storagSecondaryis one of the most important DBMS features. It should include a set of mechanisms that improve the performance of the system like indexing, clustering, access path selection, data buffering, or caching. The designer of the databases should be able to choose if he/she will activate these mechanisms or not, although for application programmers the use of these mechanisms should be transparent and not require special effort for their maintenance.

The database management system should be able to support many users. That means that they must provide special mechanisms for the concurrency of the accesses of the data, and the arbitration in case of conflicts. Such mechanisms have already been provided by the RDBMSs and hence should also be provided by the DBMSs. A basic requirement for a database system is that in case of a hardware or software failure, the system should be able to bring itself back to the most recent coherent state of the data.

This feature has to do with the concurrency control and the transaction management, but also requires extra mechanisms that have already been explored and studied for the RDBMSs.

A DBMS should provide its users with a simple interactive way of making ad-hoc queries and receiving answers. For this purpose, the OODBMS can provide a special query language as the RDBMSs did, a specially extended programming language, or some graphical tools (browsers, forms, etc.). Whatever they do provide should satisfy the following: it should be high-level so that the queries will be simple and easily understood by humans, it should be efficient, and it should be application independent application-independent,

In this section, I will analyze the optional features that an OODBMS should have. Some of them have to do with the object-oriented nature of the system, and some others with the handling of persistent data.

Multiple inheritances allowsallow, the creation of a new class from one or more other classes.

There is no general agreement if a system must support multipleinheritancese or not. It is true, however, that the systems that support this feature make the application design easier since multiple inheritareces is a more powerful tool than single inheritance. On the other hand, many problems arise from the support of multiple inheritances that has to do with conflicts among the attributes and methods inherited by more than one arbitrary class. The degree of type checking performed at compile-time should be as great as possible. The optimal situation is where a program that was accepted by the compiler cannot produce any run-time errors.

A system should be distributed although that is independent of the fact that it is an object-oriented system. Concurrency control is one of the mandatory features of a DBMS, but the current systems are intended to be used for handling very long data like images, sound, text, etc. and consequently, they should provide special transaction mechanisms to allow the efficient handling of such kinds of data.

The RDBMSs do not support such handling and therefore the object-oriented technology had to enhance the classical transaction framework with long and nested transactions. Most applications evolve and they do not acquire a stable state until a long time after their initial implementation. For this reason, it should be possible to do the following: the old data should not be overridden by new ones but should be kept and coexist as older versions of the same object and not as independent objects; and in case of schema changes, the data that correspond to previous schemas should not be thrown away but should evolve following the schema evolution.

There is a set of features, finally, for which the designers can choose among different implementations that are not equivalent but have certain advantages and disadvantages. There are plenty of programming models (C++, Lisp, Smalltalk, etc.), but none of them should be considered better than the others. The designers choose the programming model of their system according to the kind of applications that the system is going to serve. The choice of the programming style is open as well. The one that better suits the applications should be chosen. The representation system is the set of the types or classes provided by the system as well as the set of constructors that can be applied to these classes. As long as the system provides support for extensibility and composite objects, there is no restriction on which member the representation should contain. Some systems support the highest degree of uniformity, which means that everything in the system including classes, methods, messages, etc. is treated as an object. Uniformity has consequences at the level of the implementation of the system and the level of the application programming and the user interface as well. Although uniformity is a nice feature and simplifies the implementation of the system, it can sometimes confuse the users since in reality there is no absolute uniformity.

The design of the relational database system and the mechanisms that they use have been mathematically founded. Most of them are the result of long research periods that lead to the successful solving of the most important problems that occurred in these systems. The object-oriented database systems, since they are fairly new, do not have a very sound theoretical solution for many of the issues that arise from their implementations. Here are some of the problems introduced by the new approach: The object-oriented model contains some concepts whose semantics are still under discussion. There is no standard data model and consequently, there is no standard methodology for designing an object-oriented scheme. For the relation systems, on the contrary, the ER diagram is acceptable.

The query language of the relational systems was based on the mathematical theory of relational algebra and relational calculus. There is not something similar for the OODBMS. A lot of effort has been done into the definition of an object-oriented algebra since it is clear that relational algebra is inadequate the support the object-oriented model.

The traditional indexing and locking techniques should be extended to be used for object-oriented databases. The composite objects cause a lot of trouble and are still an open research issue.

The complexity of the hierarchies of classes created can be so big that the schemas can be handled with difficulty. The object-oriented systems are very much successful in areas where their predecessors failed: The design of the schema can be done in a very direct way since the object-oriented model is very close to the real-world model. On the contrary, the relational design which is based on canonical forms of the relational system is much more awkward.

The maintenance of the database is much easier due to the schema evolution facilities and the modular design allowed by the object-oriented model.

The identity concept that gives one internal pointer to each object throughout its life protects the consistency of the database and helps model similar reared-world titles In the relational systems, this identification number was inevitably user provided.

The database is not only used for storing data but also for pieces of code (methods) that run on the data. Consequently, a whole application can be stored and executed with the help of the OODBMS which also supports its maintenance.

The inheritance concept makes code easily reusable.

The expensive join operations of the relational systems have been substituted by the composite object notion, which combined with the clustering mechanism can improve the performance of the composite object retrieval.

Many applications have been using the relational systems very successfully now for many years and they do not need to change. However, there are a couple of other applications especially in, the engineering fields that don’t do much with relational systems, mainly from the modeling aspect. For these kinds of applications, the object-oriented approach seems quite appropriate despite the problems that still have to be solved.

Bibliography

1. Brown, A.W. Object-Oriented Databases: Applications in Software Engineering. McGraw-Hill, 1991.
2. Burleson, D.K. Practical Application of Object-Oriented Techniques to Relational Databases. Wiley/QED, 1994.
3. Chorafas, D.N. and H. Steinmann. Object-Oriented Databases. Prentice-Hall, 1993.
4. Delobel, C., C. Lecluse, and P. Richard. Databases: From Relational to Object-Oriented Systems. ITP, 1995.
5. Gray, P.M.D., K.G. Kulkarni, and N.W. Paton. Object-Oriented Databases: A Semantic Data Model Approach. Prentice-Hall, 1992.
6. Hughes, J.G. Object-Oriented Databases. Prentice-Hall, 1991
7. Kim, W. Introduction to Object-Oriented Databases. MIT Press, 1990.
8. Loomis, M.E.S. Object Databases: The Essentials. Addison-Wesley, 1995.
9. Rao, B.R. Object-Oriented Databases: Technology, Applications, and Products. McGraw-Hill, 1994.