Unit –I Concepts of Object –Oriented Databases:

___________________________________________________________________
Traditional data models and systems, such as relational, network, and hierarchical have been
quite successful in developing the database technology required for many traditional business
database applications. However, they have certain shortcomings when more complex database
applications must be designed and implemented.

For example, databases for engineering design and manufacturing (CAD/CAM), scientific
experiments, telecommunications, geographic information systems, and multimedia.
These newer applications have requirements and characteristics that differ from those of
traditional business applications, such as more complex structures for objects, longer duration
transactions, new data types for storing images or large textual items, and the need to define
nonstandard application-specific operations.

Object-oriented databases were proposed to meet the needs of these more complex applications.
The object-oriented approach offers the flexibility to handle some of these requirements without
being limited by the data types and query languages available in traditional database systems.

A key feature of object-oriented databases is the power they give the designer to
specify both the structure of complex objects and the operations that can be applied to
these objects.

Evolution
The term object-oriented-abbreviated by 00 or O-O-has its origins in 00 programming
languages, or OOPLs. Today 00 concepts are applied in the areas of databases, software
engineering, knowledge bases, artificial intelligence, and computer systems in general.

OOPLs have their roots in the SIMULA language, which was proposed in the late 1960s. In
SIMULA, the concept of a class groups together the internal data structure of an object in a class
declaration. Subsequently, researchers proposed the concept of abstract-data type, which hides
the internal data structures and specifies all possible external operations that can be applied to an
object, leading to the concept of encapsulation.

The programming language SMALLTALK, developed at Xerox PARC9 in the 1970s, was one
of the first languages to explicitly incorporate additional 00 concepts, such as message passing
and inheritance. It is known as a pure00 programming language, meaning that it was explicitly
designed to be object-oriented. This contrasts with hybrid 00 programming languages, which
incorporate 00 concepts into an already existing language. An example of the latter is C++,
which incorporates 00 concepts into the popular c programming language.

Object
An object typically has two components; state (value) and behavior (operations). Hence, it is
somewhat similar to a program variable in a programming language, except that it will typically
have a complex data structure as well as specific operations
One goal of 00 databases is to maintain a direct correspondence between real-world and
database objects so that objects do not lose their integrity and identity and can easily be
identified and operated upon. Hence, 00 databases provide a unique system-generated object
identifier (OID) for each object.
Another feature of 00 databases is that objects may have an object structure of arbitrary
complexity in order to contain all of the necessary information that describes the object. In
contrast, in traditional database systems, information about a complex object is often scattered
over many relations or records, leading to loss of direct correspondence between a real-world
object and its database representation.

The internal structure of an object in OOPLs includes the specification of instance variables,
which hold the values that define the internal state of the object. Hence, an instance variable is
similar to the concept of an attribute in the relational model, except that instance variables may
be encapsulated within the object and thus are not necessarily visible to external users. Instance
variables may also be of arbitrarily complex data types.

Object-oriented systems allow definition of the operations or functions (behavior) that can be
applied to objects of a particular type.

First, the database user often needs to know the attribute names so they can specify selection
conditions on the attributes to retrieve specific objects. Second, complete encapsulation implies
that any simple retrieval requires a predefined operation, thus making ad hoc queries difficult to
specify on the fly.

To encourage encapsulation, an operation is defined in two parts. The first part, called the
signature or interface of the operation, specifies the operation name and arguments (or
parameters). The second part, called the method or body, specifies the implementation of the
operation. Operations can be invoked by passing a message to an object, which includes the
operation name and the parameters. The object then executes the method for that operation. This
encapsulation permits modification of the internal structure of an object, as well as the
implementation of its operations, without the need to disturb the external programs that invoke
these operations. Hence, encapsulation provides a form of data and operation independence

Another key concept in 00 systems is that of type and class hierarchies and inheritance.
This permits specification of new types or classes that inherit much of their structure and/or
operations from previously defined types or classes. Hence, specification of object types can
proceed systematically. This makes it easier to develop the data types of a system
incrementally, and to reuse existing type definitions when creating new types of objects.

Some 00 systems provide capabilities for dealing with multiple versions of the same
object-a feature that is essential in design and engineering applications. For example, an
old version of an object that represents a tested and verified design should be retained
until the new version is tested and verified. A new version of a complex object may
include only a few new versions of its component objects, whereas other components
remain unchanged.
Object Identity
An 00 database system provides a unique identity to each independent object stored in the
database. This unique identity is typically implemented via a unique, system-generated object
identifier, or OID. The value of an OID is not visible to the external user, but it is used internally
by the system to identify each object uniquely and to create and manage interobject references.
The OlD can be assigned to program variables of the appropriate type
when needed.

Object Structure

In 00 databases, the state (current value) of a complex object may be constructed from
other objects (or other values) by using certain type constructors. One formal way of
representing such objects is
to view each object as a triple (i, c, v),
where i is a unique object identifier (the OlD),
c is a type constructor (that is, an indication of how the object state is constructed), and v
is the object state (or current value).

The data model will typically include several type constructors. The three most basic
constructors are atom, tuple, and set. Other commonly used constructors include list, bag, and
array.
The atom constructor is used to represent all basic atomic values, such as integers, real numbers,
character strings, Booleans, and any other basic data types that the system supports directly.
The object state v of an object (i, c, v) is interpreted based on the constructor c.

If c = atom, the state (value) v is an atomic value from the domain of basic values supported by
the system.

If c = set, the state v is a set of objectidentifiers {iI' iz, ..., in}, which are the OIDs
for a set of objects that are typically of the same type.

If c = tuple, the state v is a tuple of the form <al:il, az:iz, ..., an:in>, where each aj is an attribute
namel' and each ij is an OID.

If c = list, the value v is an ordered list [iI' iz, ..., in] of OIDs of objects of the same type. A
list is similar to a set except that the OIDs in a list are ordered, and hence we can refer to
the first, second, or lh object in a list.
For c = array, the state of the object is a single dimensional array of object identifiers. The main
difference between array and list is that a list can have an arbitrary number of elements whereas
an array typically has a maximum size. The difference between set and bag is that all elements in
a set must be distinct whereas a bag can have duplicate elements.
The type constructors can be used to define the data structures for an 00 database schema. In
Figure 20.2 shows how we may declare Employee and Department types corresponding to the
object instances shown in Figure. In Figure 20.2, the Date type is defined as a tuple rather than
an atomic value as in Figure. We use the keywords tuple, set, and list for the type constructors,
and the available standard data types (integer, string, float, and so on) for atomic types.
ENCAPSULATION OF OPERATIONS, METHODS, AND PERSISTENCE
The concept of encapsulation is one of the main characteristics of 00 languages and systems.
It is also related to the concepts of abstract data types and information hiding in programming
languages. In traditional database models and systems, this concept was not applied, since it is
customary to make the structure of database objects visible to users and external programs.

Specifying Object Behavior via Class Operations

The concepts of information hiding and encapsulation can be applied to database objects.
The main idea is to define the behavior of a type of object based on the operations that can be
externally applied to objects of that type. The internal structure of the object is hidden, and the
object is accessible only through a number of predefined operations.
Some operations may be used to create (insert) or destroy (delete) objects; other operations may
update the object state; and others may be used to retrieve parts of the object state or to apply
some calculations.

The external users of the object are only made aware of the interface of the object type, which
defines the name and arguments (parameters) of each operation. The implementation is hidden
from the external users; it includes the definition of the internal data structures of the object and
the implementation of the operations that access these structures. In 00 terminology, the interface
part of each operation is called the signature, and the operation implementation is called a
method.
The term class is often used to refer to an object type definition, along with the definitions of the
operations for that type. A number of operations are declared for each class, and the signature
(interface) of each operation is included in the class definition. A method (implementation) for
each operation must be defined elsewhere, using a programming language. Typical operations
include the object constructor operation, which is used to create a new object, and the destructor
operation, which is used to destroy an object. A number of object modifier operations can also be
declared to modify the states (values) of various attributes of an object. Additional operations
can retrieve information about the object.

TYPE AND CLASS HIERARCHIES AND INHERITANCE

Another main characteristic of 00 database systems is that they allow type hierarchies
and inheritance. Type hierarchies in databases usually imply a constraint on the extents
corresponding to the types in the hierarchy.
In most database applications, there are numerous objects of the same type or class.
Hence, 00 databases must provide a capability for classifying objects based on their type,
as do other database systems. But in 00 databases, a further requirement is that the system
permit the definition of new types based on other predefined types, leading to a type (or
class) hierarchy.

TYPE_NAME: funct i on, func t i on, ... , funct i on

For example, a type that describes characteristics of a PERSON may be defined as follows:

PERSON: Name, Address, B;rthdate, Age, SSN

In the PERSON type, the Name, Address, SSN, and Birthdate functions can be implemented
as stored attributes, whereas the Age function can be implemented as a method that calculates
the Age from the value of the Birthdate attribute and the current date.

The concept of subtype is useful when the designer or user must create a new type that is similar
but not identical to an already defined type. The subtype then inherits all the functions of the
predefined type, which we shall call the supertype. For example, suppose that we want to define
two new types EMPLOYEE and STUDENT as follows:

EMPLOYEE: Name, Address, Birthdate, Age, SSN, Salary, HireDate, Seniority

STUDENT: Name, Address, Birthdate, Age, SSN, Major, GPA

Since both STUDENT and EMPLOYEE include all the functions defined for PERSON plus
some
additional functions of their own, we can declare them to be subtypes of PERSON. Each will
inherit the previously defined functions of PERsoN-namely, Name, Address, Birthdate,
Age, and SSN.

For STUDENT, it is only necessary to define the new (local) functions Major and CPA, which
are not inherited. Presumably, Major can be defined as a stored attribute, whereas GPA may be
implemented as a method that calculates the student's grade point average by accessing the Grade
values that are internally stored (hidden) within each STUDENT object as private attributes. For
EMPLOYEE, the Salary and HireDate functions may be stored attributes, whereas Seniority may
be a method that calculates Seniority from the value of HireDate.

GEOMETRY_OBJECT: Shape, Area, ReferencePoint

For the GEOMETRY_OBJECT type, Shape is implemented as an attribute (its domain can be
an enumerated type with values 'triangle', 'rectangle', 'circle', and so on), and Area is a
method that is applied to calculate the area. ReferencePoint specifies the coordinates of a
point that determines the object location. Now suppose that we want to define a number
ofsubtypes for the GEOMETRY_OBJECT type, as follows:
RECTANGLE subtype-of GEOMETRY_OBJECT: Width, Height
TRIANGLE subtype-of GEOMETRY_OBJECT: Sidel, Side2, Angle
CIRCLE subtype-of GEOMETRY_OBJECT: Radius

Notice that the Area operation may be implemented by a different method for each subtype,
since the procedure for area calculation is different for rectangles, triangles, and circles.
Similarly, the attribute ReferencePoint may have a different meaning for each subtype; it might
be the center point for RECTANGLE and CIRCLE objects, and the vertex point between the two
given sides for a TRIANGLE object. Some 00 database systems allow the renaming of inherited
functions in different subtypes to reflect the meaning more closely.

An alternative way of declaring these three subtypes is to specify the value of the Shape attribute
as a condition that must be satisfied for objects of each subtype:
RECTANGLE subtype-of GEOMETRY_OBJECT (Shape='rectangle'): Width, Height
TRIANGLE subtype-of GEOMETRY_OBJECT (Shape='triangle'): Sidel, Side2, Angle
CIRCLE subtype-of GEOMETRY_OBJECT (Shape='circle'): Radius

Here, only GEOMETRY_OBJECT objects whose Shape='rectangle' are of the subtype

RECTANGLE, and similarly for the other two subtypes. In this case, all functions of the
GEOMETRY_OBJECT supertype are inherited by each of the three subtypes, but the value of
the Shape attribute is restricted to a specific value for each.