Object-Relational Database - Essay Example

Running head: OBJECT RELATIONAL DATABASE Object Relational Database Vs. Relational database By _______________ ORDB Overview An ORDB (Object relational database) is solely based on Object oriented concepts. As in object oriented programming, a program is a collection of objects. An object represents a real life model encapsulating both data and operations within itself. But before creating such an object, the type/class for that object should have to be declared, depending on its details, the object is instantiated. The same theme is followed in ORDB, means before creating an object table, a type or class, which represents a real life model is declared. That type describes the attributes (data) and operations (methods) of an object record. Depending on this type, an object table is created, which is going to hold record objects of that type. In ORDB, reusability is achieved by using the techniques of inheritance of types and polymorphism. Every record has unique identity within the object table. Here every record is termed to be active, persistent objects encapsulating both data and methods. The only way to access any data, is through the object methods. In contrast with this advance database system, the traditional database system like RDBMS (Relational database management system) maps the real world models in the form of entities containing tuples/rows. Each tuple in an entity contains the common set of attributes/columns. Here both entity and its tuples are said to passive, as in order to mutate or access these tuples, data manipulation language or external stored procedures are used. A tuple only contains the data and does not contain any methods. A tuple is not identified by an object id but uniquely identified within an entity, by using data of a column, which is called as the primary key column. In RDBMS, there is no concept of reusability, because there are not any concepts of inheritance and polymorphism. Theory Object Orientation This technique is based upon various underlying concepts, which are discussed as follows: Abstraction and Encapsulation Encapsulation is achieved through abstract data types (ADTs). In this concept, the object has an interface part and an implementation part. The interface provides specifications of the operations that can be performed on the object; the implementation part consists of the data structure for the ADT and the functions that realise the interface. Only the interface part is visible to other object or users. In ORDB, proper encapsulation is achieved by ensuring that programmers have access only to the interface part. In this way encapsulation provides the form of logical data independence. We can change the internal implementation of an ADT without changing any of the application programs using that ADT. (Connolly & Begg, p. 686). Object and Attributes A uniquely identifiable entity contains both the attributes that describe the state of the real world object and the actions that are associated with the real world objects. A key part of the definition of an object is unique identity. In an ORDBMS, each object has a unique system-wide identifier that is independent of the values of its attributes (that is its state), and is invisible to the user. Two objects could have the same state but would have different identities. When an object is created, it is assigned and Object Identifier (OID) that is unique and invariant, in the sense that it cannot be altered during its lifetime. The OID distinguishes the object from every other object in the system. Once the object is created, this OID will not be reused for any other object, even after the object has been deleted. OID automatically provides entity integrity. Object Methods Object methods define the behaviour of the object. They can be used to change the object's state by modifying its attribute values, or to query the value of selected attributes. Class, Inheritance and Polymorphism A class is said to be a blue print of an object. Remember in any ORDBMS, we cannot start creating objects without defining the class/type. Systematically, in order to model a real life object, its properties/attributes and action/methods are written in the form a class/type and stored in the database. After that depending on that class, the objects are created which are automatically of persistent nature. For any database development cycle, reusability comes into play in two respects. Firstly, all the required classes are made to generalize by taking out the common attributes and functionalities of these different classes, and creating a super-class, so that all these different classes would automatically become sub-classes. Thus easing the way for polymorphism approach. Secondly, in a designed ORDB, if an additional or advance type/class is required whose most features are already defined in an existing class stored in the system, then this new class is going to be the sub-class of the existing super-class, hence reusing the existing features. Object Data Model Kim (1991:21-29) defines: Object Database Model (ODM): A data model that captures the semantics of objects supported in object-oriented programming. Object Database (ODB): A persistent and shareable collection of objects defined by an ODM. Object Database Management System (ODBMS): The manager of ODB. This technology is not yet standardised; every ODBMS implementation has its own specifications and models. But every ODBMS model must satisfy: Provision for database functionality Support for object identity Provision of encapsulation Support for objects with complex state High-level query language with query optimization capabilities in the underlying system Support for persistence and atomic transactions, concurrency and recovery control Support for complex object storage, indexes and access methods for fast and efficient retrieval. Support for types and classes Support for types and classes to inherit from their ancestor Support for dynamic binding (Connolly, 698,707) Relationships and Referential Integrity Relationships are represented in an object data model using reference attributes, typically implemented using OIDs. The binary relationships according to their cardinality are: 1:1 Relationships A 1:1 relationship between objects A and B is represented by adding a reference attribute to object A and, to maintain referential integrity, a reference attribute to object B. 1:M Relationships In 1:M relationships the objects between A and B are represented by adding a reference attribute to object B and an attribute containing a set of references to A. M: N Relationships An M: N relationship between object A and B, is represented by adding an attribute containing a set of references to each object. Referential Integrity In order to implement referential integrity, following measures should have to be taken: Do not allow the user to explicitly delete objects. In this case the system is responsible for garbage collection; in other words, the system automatically deletes objects when they are no longer accessible by the user. Allow the user to delete objects when they are no longer required. In this case, the system may detect invalid references automatically and set the reference to null (the NULL pointer) or disallow the deletion. Allow the user to modify and delete objects and relationships when they are no longer required. In this case, the system automatically maintains, the integrity of objects. Inverse attributes can be used to maintain referential integrity. Object Relational Database Management System Object Relational data models or extended relational data models are based on enhancement of the relational data model to incorporate procedures, objects, versions and other new capabilities. There is no single extended relational model; rather there are a variety of these models whose characteristics depend on the way and the degree to which extensions were made. However, all the models do share the same basic relational tables and query language, all incorporate some concept of object, and some have the ability to store procedures as well as data in the database. (Connolly & Begg, p. 711) Data model ORDBMS employs a data model that adds Object orientation to tables and uses SQL3 standard. All persistent (database) information is still in tables, but some of the tabular entries can have richer data structure, termed abstract data types (ADTs). An ADT is a data type that is constructed by combining basic data types. The support for abstract data types are attractive because the operations and functions associated with the new data type can be used to index, store, and retrieve records based on the content of the new (e.g., multimedia) data type. An ORDBMS should be a superset of an RDBMS, and default to SQL2 (or its successors) if no object capabilities are used. This approach, though it provides more structures for modeling more complex data and freestanding functions, lacks the fundamental object requirement of encapsulation and operations with data. It also has limited support for relationships, identity, inheritance, polymorphism, composition, extensibility or creating user-defined persistent classes, and integration with host object languages like Java. Query language An ORDBMS supports an extended form of SQL, sometimes referred to as an Object SQL. The point of the extensions is to support the object model (e.g., queries involving object attributes). Typical extensions include queries involving nested objects, set-valued attributes, inclusion of methods/functions in search predicates, and queries involving abstract data types. The ORDBMS is still relational because the data is stored in tables of rows and columns, and SQL, with the extensions mentioned, is the language for data definition, manipulation, and query. The target and result of a query are still tables or tuples, although SQL4 will generalize this to collections of objects, incorporating OQL, or close to it, for its read-only ad hoc query. The key here is searchable content. Computational model The SQL language, with extensions for accessing ADTs, is still the primary interface to the database. The direct support of host object languages and their objects is missing, forcing programmers to continue to translate between objects and tables. (Steve McClure IDC Bulletin #14821E - August 1997) The ORDBMS technology has decisively reduced the gap between RDBMSs and OOPLs. Although object-relational DBMSs (ORDBMSs) are able to (internally) manage object-oriented structures, the required seamless coupling of OOPLs and ORDBMSs is not yet possible, because (as in SQL92) results of SQL: 1999 queries are rather (sets of data) tuples than (desired sets of) objects. In summary, the gap between OOPLs and ORDBMSs can be traced back to a whole bunch of modelling and operational aspects, as we will detail in the following sections. Furthermore, the SQL: 1999 standard and the commercially available ORDBMSs differ very much in their object-oriented features. Thus, it is by no means clear, how a given object-oriented design can be mapped to a given ORDBMS (most) efficiently, or which features should be offered by ORDBMSs in general in order to enable an efficient mapping of object-oriented structures, respectively. Our long-term objective is to influence the further development of ORDBMSs towards a better support of object-oriented software development (minimal mapping overhead). (Zhang Weiping & Norbert Ritter) Advantages of ORDBMS ORDBMS provides the following benefits in database design: Object Reuse: Objects can be reused multiple times to form other objects or can be embedded into different tables. Discipline Database design: Objects can be embedded into table columns or made to exist as row objects. Each object can be designed and tested independently. Disadvantages Following are the disadvantages: Increase in complexity: A small transition is required for developer or DBAs to migrate from relational mind set to a more Object oriented approach. Objects can appear as black boxes if proper documentation is not available to support their existence and use. Object Portability: If a database is created and makes full use of its object oriented features, migrating the database to another vendor's database requires a complete recreation of the database as there is no standardized model. Structural Comparison of Object Table and Object Relational Table In both different kinds of tables, the type should have to create first. An object table can be purely mapped by any OOPL but an object relational table cannot be directly mapped by any OOPL. Object Table Every record in an object table is an object of a particular type/class with a unique object ID. There is no relational field with in the record. Since a record is an object so it has attributes and methods. Before creating an object table, the type would be defined as: Create type emp_type as object (empno number(2), ename varchar(10), sal number(5,2), deptno number(2)) The type would be compiled and stored physically by the ODBMS. After this by using this type, the object table would be created. Create table emp of emp_type Object Relational Table Such a table is a relational table, which can have fields of simple data types (like, number, varchar, date) and can also have fields of abstract data types/user defined types/classes. Before creating such a table, the abstract type must be stored in the database system. Create type address_type as object (Streeet varchar(50), City varchar(25), State char(2), Zip number) Now a table can be created which can have a field of the above stated type. Create table customer (Custid number(4) primary key, Custname varchar(20), Address address_type) The above example clearly shows that customer table is an object relational table, because each record in that is going to have two relational fields and one user-defined field that is an object of address_type. Over here the record is not object but it contains an object. Each record is uniquely identified by the primary key, which is a relational field. (Koch, 2002:552) Standards SQL 3 SQL3 has refined the relational model into an object model offering enhanced characteristics as abstract data types, multiple inheritance, and dynamic polymorphism. SQL 3 is the advanced version of the SQL standard with new object oriented features and functionalities. SQL 3 allows the definition of an abstract data type that specifies the behaviour of similar objects, called instances of the ADT. Abstract Data Types The ADT definition contains the following features in SQL 3: Attribute Specifications Function Specifications Enforced Encapsulation in order to define attributes and functions SQL 3 defines three types of functions that can be used in an ADT. Constructors, used to initialize new instances of an ADT. Destructors, used to release that initialized instance resources. Actors, used as functions to perform all other operations on instances of an ADT. (Conolly, 717) There is no support for recursive queries in SQL 2, so embedded SQL or PL/SQL is used to do the job. While in SQL 3, there is support for recursive queries by using 'with' operator. Products Oracle Oracle 8.x Informix Universal Server IBM Universal Database (DB/2 Extenders) UniSQL UniSQL/X Unisys OSMOS (McClure, 1997) Oracle Database The primary difference between Oracle database and Informix server is user authentication. Oracle users are maintained by the database and can use several methods of authentication, usually through the database. The server supports access to the database, which is restricted by the sysuser table. The sysuser is maintained by each database and the database administrator. An Oracle database server consists of a shared memory area, several processes that access the database and maintain data integrity and consistency, the Oracle Instance, and a database that stores the data. An Oracle database consists of one or more tablespaces. Tablespaces provide logical storage space that link a database to the physical disks that hold the data. A tablespace is created from one or more data files. Data files are files in the file system or an area of disk space specified by a raw device. A tablespace can be enlarged by adding more data files. An Oracle database consists of least a SYSTEM tablespace, where the Oracle tables are stored. It can also consist of user-defined tablespaces. A tablespace is the logical storage location for database objects. For example, you can specify where a particular table or index gets created in the tablespace. (Accessed from Server, 2006a) Informix Server Informix Dynamic Server users are maintained and authenticated by the host operating system. A user can connect to an Informix Dynamic Server database server through the operating system login information. An Informix Dynamic Server database server also consists of a shared memory area, several process to access the data and maintain data integrity and consistency, however a single Informix Dynamic Server database server can support several separate databases. (Accessed from Server, 2006a) IBM Architecture IBM DB2/400 V4R5 is an integrated database management system for OS/400, the AS/400 operating system. It is a database system used for storing and manipulating large volumes of data and it forms the basis for most of the business applications that run on the AS/400. The Distributed Data Management (DDM) architecture provides a basis for distributed file access. Only native data access is allowed for DDM files. IBM created the Distributed Relational Database Architecture (DRDA) layer on top of DDM, and this provides the protocol that a SQL application can use to access distributed tables and data. Oracle supports the DRDA standard and the Oracle Transparent Gateway for IBM DB2/400 V4R5 provides the capability to transparently access and update data stored in distributed locations in IBM DB2/400 V4R5 databases. (Accessed from Server, 2006b) References Connolly Thomas & Begg Carolyn, "Database Systems": Addison-Wesley, 1996, Addison-Wesley Publishers Ltd. Koch George, "Oracle 9i: The Complete Reference" Kim W. (1991). Object-oriented database systems: strengths and weaknesses, J., Object-Oriented Programming. Server 2006a accessed from Server 2006b accessed from Steve McClure IDC Bulletin #14821E - August 1997: "Object Database Vs. Object Relational Databases" accessed from Zhang Weiping & Norbert Ritter, "British National Conference on Databases" accessed from Read More