Objectoriented Database Management Systems

Object-Oriented Database Management Systems The construction of Object-Oriented Database Management Systems started in the middle 80s, at a prototype building level, and at the beginning of the 90s the first commercial systems appeared. The interest for the development of such systems stems from the need to cover the modeling deficiencies of their predecessors, that is the relational database management systems.

They were intended to be used by applications that have to handle big and complex data such as Computer Aided Engineering, Computer Aided Design, and Office Information Systems. The area of the OODBMSs is characterized by three things. First, it 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 of 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, we can understand that the differences between the various systems with different data models can be big and 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 really a need for applications to handle very complex data and that is why the interest of people in building such systems is so strong.

Although there is no consensus on what an OODBMS is and which are the features that differentiate it from other systems, there has been a lot of effort for an agreement on defining the formal characteristics that can stand as the set of specification requirements for the construction of such a system. These should also be used as the set of features that one has to check in order to find out if a system is really an OODBMS. The features of the OODBMS can be divided as follows: * mandatory features: these are the features that one system should have in order 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.

* 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 oriented 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 world objects), list (to represent ordered collections of real world objects), 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. 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 full encapsulation, 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 part). 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 by the other objects, we can assign to methods with the same functionality 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 out if the message sent is applicable 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 of the 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 but there are some models that do not allow classes to have more than one.

These are called single inheritance models and the rest multiple inheritance models. According to the concept of inheritance, the subclasses ca! n 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 the 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 with any 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, for applications that are written in the same language, there is no need of transformation 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. In order 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 shou ...