Advance Database Management Systems -Object Oriented Principles In Database

Advance Database Management Systems -Object Oriented Principles In Database

• 1.
  Object Oriented PrincipalsIn Database Abstract: An OODBMS is the result of combining object oriented programming principles with database management principles. Object oriented programming concepts such as encapsulation, polymorphism and inheritance are enforced as well as database management concepts such as the ACID properties (Atomicity, Consistency, Isolation and Durability) which lead to system integrity, support for an ad hoc query language and secondary storage management systems which allow for managing very large amounts of data. The Object Oriented Database Manifesto specifically lists the following features as mandatory for a system to support before it can be called an OODBMS; Complex objects, Object identity, Encapsulation , Types and Classes , Class or Type Hierarchies, Overriding, overloading and late binding, Computationalcompleteness , Extensibility,P ersistence , Secondary storage management, Concurrency, Recovery and an Ad Hoc Query Facility. Keywords: Object oriented model, database, DBMS, OODB, object oriented system, RDBMS, class types. I.INTRODUCTION An OODBMS should be able to store objects that are nearly indistinguishable from the kind of objects supported by the target programming language with as little limitation as possible. Persistent objects should belong to a class and can have one or more atomic types or other objects as attributes. The normal rules of inheritance should apply with all their benefits including polymorphism, overridding inherited methods and dynamic binding. Each object has an object identifier (OID) which used as a way of uniquely identifying a particular object. OIDs are permanent, system generated and not based on any of the member data within the object. OIDs make storing references to other objects in the database simpler but may cause referential integrity problems if an object is deleted while other objects still have references to its OID. An OODBMS is thus a full scale object oriented development environment as well as a database management system. Features that are common in the RDBMS world such as transactions, the ability to handle large amounts of data, indexes, deadlock detection, backup and restoration features and data recovery mechanisms also exist in the OODBMS world. A primary feature of an OODBMS is that accessing objects in the database is done in a transparent manner such that interaction with persistent objects is no different from interacting with in-memory objects. This is very different from using an RDBMSs in that there is no need to interact via a query sub-language like SQL nor is there a reason to use a Call Level Interface such as ODBC, ADO or JDBC. Database operations typically involve obtaining a database root from the the OODBMS which is usually a data structure like a graph, vector, hash table, or set and traversing it to obtain objects to create, update or delete from the database. When a client requests an object from the database, the object is transferred from the database into the application's cache where it can be used either as a transient value that is disconnected from its representation in the database (updates to the cached object do not affect the object in the database) or it can be used as a mirror of the version in the database in that updates to the object are reflected in the database and changes to object in the database require that the object is refetched from the OODBMS Fig 1: OODB II. Comparisons Of OODBMSs To RDBMSs There are concepts in the relational database model that are similar to those in the object database model. A relation or table in a relational database can be considered to be analogous to a class in an object database. A tuple is similar to an instance of a class but is different in that it has attributes but no behaviours. A column in a tuple is similar to a class attribute except that a column can hold only primitive data types while a class attribute can hold data of any type. Finally classes have methods which are computationally complete (meaning that general purpose control and computational structures are provided) while relational databases typically do not have computationally complete programming capabilities although some stored procedure languages come close.
• 2.
  Fig 2: ComparisonsOf OODBMSs To RDBMSs III. Advantages a. Composite Objects and Relationships: Objects in an OODBMS can store an arbitrary number of atomic types as well as other objects. It is thus possible to have a large class which holds many medium sized classes which themselves hold many smaller classes, ad infinitum. In a relational database this has to be done either by having one huge table with lots of null fields or via a number of smaller, normalized tables which are linked via foreign keys. Having lots of smaller tables is still a problem since a join has to be performed every time one wants to query data based on the "Has-a" relationship between the entities. Also an object is a better model of the real world entity than the relational tuples with regards to complex objects. The fact that an OODBMS is better suited to handling complex, interrelated data than an RDBMS means that an OODBMS can outperform an RDBMS by ten to a thousand times depending on the complexity of the data being handled. b. Class Hierarchy: Data in the real world is usually has hierarchical characteristics. The ever popular Employee example used in most RDBMS texts is easier to describe in an OODBMS than in an RDBMS. An Employee can be a Manager or not, this is usually done in an RDBMS by having a type identifier field or creating another table which uses foreign keys to indicate the relationship between Managers and Employees. In an OODBMS, the Employee class is simply a parent class of the Manager class. c. Circumventing the Need for a Query Language: A query language is not necessary for accessing data from an OODBMS unlike an RDBMS since interaction with the database is done by transparently accessing objects. It is still possible to use queries in an OODBMS however. d. No Impedance Mismatch: In a typical application that uses an object oriented programming language and an RDBMS, a significant amount of time is usually spent mapping tables to objects and back. There are also various problems that can occur when the atomic types in the database do not map cleanly to the atomic types in the programming language and vice versa. This "impedance mismatch" is completely avoided when using an OODBMS. e. No Primary Keys: The user of an RDBMS has to worry about uniquely identifying tuples by their values and making sure that no two tuples have the same primary key values to avoid error conditions. In an OODBMS, the unique identification of objects is done behind the scenes via OIDs and is completely invisible to the user. Thus there is no limitation on the values that can be stored in an object. f. One Data Model: A data model typically should model entities and their relationships, constraints and operations that change the states of the data in the system. With an RDBMS it is not possible to model the dynamic operations or rules that change the state of the data in the system because this is beyond the scope of the database. Thus applications that use RDBMS systems usually have an Entity Relationship diagram to model the static parts of the system and a separate model for the operations and behaviours of entities in the application. With an OODBMS there is no disconnect between the database model and the application model because the entities are just other objects in the system. An entire application can thus be comprehensively modelled in one UML diagram IV. Disadvantages a. Schema Changes: In an RDBMS modifying the database schema either by creating, updating or deleting tables is typically independent of the actual application. In an OODBMS based application modifying the schema by creating, updating or modifying a persistent class typically means that changes have to be made to the other classes in the application that interact with instances of that class. This typically means that all schema changes in an OODBMS will involve a system wide recompile. Also updating all the instance objects within the database can take an extended period of time depending on the size of the database. b. Language Dependence: An OODBMS is typically tied to a specific language via a specific API. This means that data in
• 3.
  an OODBMS istypically only accessible from a specific language using a specific API, which is typically not the case with an RDBMS. c. Lack of Ad-Hoc Queries: In an RDBMS, the relational nature of the data allows one to construct ad-hoc queries where new tables are created from joining existing tables then querying them. Since it is currently not possible to duplicate the semantics of joining two tables by "joining" two classes then there is a loss of flexibility with an OODBMS. Thus the queries that can be performed on the data in an OODBMS is highly dependent on the design of the system. V. List Of Object Oriented Database Management Systems a. Proprietary  Object Store  O2  Gemstone  Versant  Ontos  DB/Explorer ODBMS  Ontos  Poet  Objectivity/DB  EyeDB b. Open Source  Ozone  Zope  FramerD  XL2 VI. OODBS Features To have an idea about OODBS, the table shows the correspondence between object oriented and relational database systems: Fig 3: OODBS Features VI. Mandatory features of object-oriented systems a. Support for complex objects A complex object mechanism allows an object to contain attributes that can themselves be objects. In other words, the schema of an object is not in first - normal-form. Examples of attributes that can comprise a complex object include lists, bags, and embedded objects. b. Object identity Every instance in the database has a unique identifier (OID), which is a property of an object that distinguishes it from all other objects and remains for the lifetime of the object. In object - oriented systems, an object has an existence (identity) independent of its value. c. Encapsulation Object-oriented models enforce encapsulation and information hiding. This means, the state of objects can be manipulated and read only by invoking operations that are specified within the type definition and made visible through the public clause. In an object-oriented database system encapsulation is achieved if only the operations are visible to the programmer and both the data and the implementation are hidden. d. Support for types or classes  Type: in an object-oriented system, summarizes the common features of a set of objects with the same characteristics. In programming languages types can be used at compilation time to check the correctness of programs.  Class: The concept is similar to type but associated with run-time execution. The term class refers to a collection of all objects with the same internal structure (attributes) and methods. These objects are called instances of the class. Both of these two features can be used to group similar objects together, but it is normal for a system to support either classes or types and not both. e. Class or type hierarchies Any subclass or subtype will inherit attributes and methods from its superclass or super type.
• 4.
  f. Overriding, Overloadingand Late Binding  Overloading: A class modifies an existing method, by using the same name, but with a different list, or type, of parameters.  Overriding: The implementation of the operation will depend on the type of the object it is applied to.  Late binding: The implementation code cannot be referenced until run-time. g. Computational Completeness SQL does not have the full power of a conventional programming language. Languages such as Pascal or C are said to be computationally complete because they can exploit the full capabilities of a computer. SQL is only relationally complete, that is, it has the full power of relational algebra. Whilst any SQL code could be rewritten as a C++ program, not all C++ programs could be rewritten in SQL. For this reason most relational database applications involve the use of SQL embedded within a conventional programming language. The problem with this approach is that whilst SQL deals with sets of records, programming languages tend to work on a record at a time basis. This difficulty is known as the impedance mismatch. Object-oriented databases attempt to provide a seamless join between program and database and hence overcome the impedance mismatch. To make this possible the data manipulation language of an object-oriented database should be computationally complete. VII. Mandatory features of database systems A database is a collection of data that is organized so that its contents can easily be accessed, managed, and updated. Thus, a database system contains the five following features: a. Persistence As in a conventional database, data must remain after the process that created it has terminated. For this purpose data has to be stored permanently on secondary storage. b. Secondary Storage Management Traditional databases employ techniques, which manage secondary storage in order to improve the performance of the system. These are usually invisible to the user of the system. c. Concurrency The system should provide a concurrency mechanism, which is similar to the concurrency mechanisms in conventional databases. d. Recovery The system should provide a recovery mechanism similar to recovery mechanisms in conventional databases. e. Ad hoc query facility The database should provide a high-level, efficient, application independent query facility. This needs not necessarily be a query language but could instead, be some type of graphical interface. The above criteria are perhaps the most complete attempt so far to define the features of an object-oriented database in 1989. Further attempts to define an OODBS standard were made variables of researchers. One of them is a group called Object Data Management Group (ODMG). They have worked on an OODBS standard for the industry. VIII. Object model a. Classes An object is an instance of exactly one class. Objects with the same internal structure and methods are grouped together into a class and are called instances if the class. b. Objects An object is a chunk of private memory with a public interface. Internally, most objects are divided into fields called instance variables. Each instance variable can hold a value, which is another object. Objects communicate with other objects by passing messages. Object is the root of all super/subclass hierarchy. c. Messages Messages are requests for the receiving object to change its state or return a result. The set of messages an object responds to is called protocol (its .public interface.). An object may be inspected or changed only through its protocol. The basic form of all message expressions is <receiver> <message>. The <receiver> part is an identifier or expression denoting an object that receives and interprets the message. The <message> part gives the selector of the message and possible arguments to the message d. Methods The methods are the concrete implementations that can be invoked by a message sent to an instance. An object can only responds to a message if it contains a method with a selector that matches the
• 5.
  message format. Methodsare provided to query and manipulate the internal structure. Fig 4: Message Passing in gem stone. e. Collection classes A class defines the structure of its instances, but rarely keeps track of all the instances. Instead, collection objects . Arrays, Bags, sets . can store groups of instances . not necessarily of the same type . in indexable or anonymous storage slots. GemStone provides built-in support for managing collections of objects by the pre-defined Collection class and its subclasses.  Array: like String, is a subclass of Collection.s subclass SequenceableColletion.  Bags and Sets: are non-sequenceable Collections, in which instance variables are anonymous. They do not maintain any order on their elements. The difference between a Bag and a Set is that the ins tances of Bag may contain the same object several times, whereas a Set contains an element just once . even though it might have been inserted several times Fig 5: Classes hierarchy of collection classes Conclusion The OODBMS contains extensive concepts, which makes it a lot more complicated comparing with the RDBS. This paper gives an introduction of OODBMS concepts and its principles. The gains from using an OODBMS while developing an application using an OO programming language are many. The savings in development time by not having to worry about separate data models as well as the fact that there is less code to write due to the lack of impedance mismatch is very attractive. In my opinion, there is little reason to pick an RDBMS over an OODBMS system for new application development unless there are legacy issues that have to be dealt with. Acknowledgement: I will like to thank our Prof. for giving the chance to explore oneself. References: [1]. http://www.dacs.dtic.mil/techs/oodbms2 [2].http://www.25hoursaday.com/WhyArentYouUs ingAnOODBMS.html [3]. http://www.scribd.com/doc/42099675/Paper- Object-Oriented-Database-Theory [4].ieor.berkeley.edu/~goldberg/courses/F04/215/2 15-OODB.ppt [5].http://dusk.geo.orst.edu/buffgis/PPT/geo580_6_ oo10.ppt