Difference between designing a relational database and an object database

  What are the main difference between designing a relational database and an object database?
Ans:

The main difference between designing a relational database and an object database are given below

• Object database have better performance than relational database.
• A relational databases relies on the relational model, on the other hand a object database             relies on the OOP.
• The relational model organizes information in a set of tables each are composed of rows             and columns. Each column represents a property and each row represents an entity.
• In a object oriented database each element resembles a object from the object oriented               paradigm.
• It is reasonable easy to map object into relational databases.
• In an object oriented database we will directly store the object into a DB, by using this              method we can store the images, videos, audio into a DB. But in Relational DB we will             store the data in the form of a relation.

What is the difference between structured and unstructured complex object? 

Unstructured Complex Objects

An unstructured complex object facility provided by a DBMS permits the storage and retrieval of large objects that are needed by the database application. Typical examples of such objects are bitmap images and long text strings (such as documents); they are also known as binary large objects, or BLOBs for short. These objects are unstructured in the sense that the DBMS does not know what their structure is—only the application that uses them can interpret their meaning. For example, the application may have functions to display an image or to search for certain keywords in a long text string. The objects are considered complex because they require a large area of storage and are not part of the standard data types provided by traditional DBMSs. Because the object size is quite large, a DBMS may retrieve a portion of the object and provide it to the application program before the whole object is retrieved. The DBMS may also use buffering and caching techniques to prefetch portions of the object before the application program needs to access them. 

The DBMS software does not have the capability to directly process selection conditions and other operations based on values of these objects, unless the application provides the code to do the comparison operations needed for the selection. In an OODBMS, this can be accomplished by defining a new abstract data type for the uninterpreted objects and by providing the methods for selecting, comparing, and displaying such objects. For example, consider objects that are two-dimensional bitmap images. Suppose that the application needs to select from a collection of such objects only those that include a certain pattern. In this case, the user must provide the pattern recognition program as a method on objects of the bitmap type. The OODBMS then retrieves an object from the database and runs the method for pattern recognition on it to determine whether the object includes the required

pattern.

Structured Complex Objects

A structured complex object differs from an unstructured complex object in that the object’s structure is defined by repeated application of the type constructors provided by the OODBMS. Hence, the object structure is defined and known to the OODBMS. As an example, consider the DEPARTMENT object shown in Figure 11.01. At the first level, the object has a tuple structure with six attributes: DNAME, DNUMBER, MGR, LOCATIONS, EMPLOYEES, and PROJECTS. However, only two of these attributes—namely, DNAME and DNUMBER—have basic values; the other four have complex values and hence build the second level of the complex object structure. One of these four (MGR) has a tuple structure, and the other three (LOCATIONS, EMPLOYEES, PROJECTS) have set structures. At the third level, for a MGR tuple value, we have one basic attribute (MANAGERSTARTDATE) and one attribute

(MANAGER) that refers to an employee object, which has a tuple structure. For a LOCATIONS set, we have a set of basic values, but for both the EMPLOYEES and the PROJECTS sets, we have sets of tuple-structured objects.