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
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.