MZUMBE UNIVERSITY

FACULTY OF SCIENCE AND TECHNOLOGY

SUBJECT CODE: ICT 321

INDIVIDUAL ASSIGNMENT
PROGRAM ITS III
DATE: 21/06/2017.

NAME REGISTRATION NUMBER

HAMIS ALLY 1302158/T.14

Question one:Answer:
mysql> select columnA, columnB, CASE when right (columnA,1)<=3 then 1 when right
(columnA,1)<=6 then 2 else 3 END as column c from leo
+---------+---------+---------+
| columnA | columnB | column |
+---------+---------+---------+
| Ro1 |A | 1|
| Ro1 |A | 1|
| Ro7 |A | 3|
| Ro2 |C | 1|
| Ro3 |B | 1|
| Ro3 |B | 1|
| Ro6 |B | 2|
| Ro4 |C | 2|
| Ro5 |A | 2|
+---------+---------+---------+9 rows in set (0.03 sec)
Question two:
DOMC_01
Distributed Object Computing with CORBA
Introduction
The OMG does not produce software or implementation guidelines, only the specifications to
which OMG members respond to in Request for Information (RFI) and Requests for Proposals
(RFP). By managing these specifications, the OMG supports the adoption process for the member
companies interested in advancing the uses and applications of distributed object-oriented
computing. Many OMG member companies have either started shipping or have announced plans
to ship products based on the CORBA specification.
The OMG is a non-profit consortium created in 1989 to promote the theory and practice of object
technology for the development for distributed operating systems. The goal is to provide a common
architectural framework for object-oriented applications based on widely available interface
specifications. With a membership of over 800 members, representing large and small companies
within the computer industry, OMG leads the specification development efforts of CORBA, OMG
IDL, IIOP, OMA, UML, MOF, and CWM specifications.
The CORBA is composed of five major components:
 ORB Core
 Interface Definition Language
 Dynamic Invocation Interface
 Interface Repository
 Object Adapters
The next few sections describe each of these components and show how they provide the flexibility
required to support a variety of distributed OO systems, emphasizing those developed in C++.
C++ and Distributed OO Computing
As all C++ programmer who has written a distributed application has run into the same problem:
How does one ship a C++ object across a network from one process to another? Systems like the
Distributed Computing Environment (DCE) from the OSF provide remote procedure call (RPC)
mechanisms that can ship complicated data structures across a network, but they do not provide
explicit support for C++ objects. Unfortunately, shipping C++ objects across a network typically
requires a violation of object encapsulation.
ORB Core
This includes the distributed computing responsibilities of location, referencing and 'marshalling'
of parameters and results. In the OMA object model, objects provide services, and clients issue
requests for those services to be performed on their behalf. The ORB services necessary to
accomplish this are completely transparent to the client. Clients do not need to know where on the
network objects reside, how they communicate, how they are implemented, how they are stored,
nor how they execute.
The CORBA specifies two different ways in which clients can issue requests to objects:
• Static invocations via interface-specific stubs
• Dynamic invocations via the ORB Dynamic Invocation Interface (DII)
Interface Definition Language (IDL)
A cornerstone of the CORBA standards is the Interface Definition Language. IDL is the OMG
standard for defining language-neutral APIs and provides the platform-independent delineation of
the interfaces of distributed objects.
IDL defines the modules, interfaces and operations for the applications and is not considered a
programming language. The various programming languages, such as Ada, C++, or Java, supply
the implementation of the interface via standardized IDL mappings. Although an object reference
identifies a particular object, it does not necessarily describe anything about the object’s interface.
IDL provides interface inheritance in which derived interfaces inherit the operations and types
defined in their base interfaces. In C++ terms, IDL interface inheritance exhibits the following
characteristics:
 all base interfaces are effectively public virtual
 all operations are effectively virtual
 operations cannot be declared in derived interfaces
 there is no notion of implementation inheritance
The fact that CORBA IDL is a declarative language heightens the separation of interface and
implementation that is emphasized in OO systems development. An object of a derived C++ class
always contains all the data members of its bases classes, and for the purposes of polymorphism,
a derived class can only redefine those base class member functions explicitly declared virtual.
Since IDL is not an implementation language, it does not confuse these two types of inheritance.
If an operation invoked on the narrowed surrogate is not supported by the object implementation
it refers to, a BAD_OPERATION exception is returned to the caller. C++ programmers may
question why CORBA specifies an entirely new language for describing object interfaces rather
than using a declarative subset of C++. There are several good reasons for this choice:
 the CORBA specification is intended to be language-independent; using a subset of C++
for IDL
 lessens the chances of CORBA being widely accepted in the distributed OO programming
community
 C++ is known to be difficult to parse [7]; using a subset of C++ might ultimately limit the
number of IDL compiler implementations available
 some features of C++, notably pointers, make marshaling and unmarshaling of data
difficult
 any declarative subset of C++ chosen would most likely be different enough from normal
C++ so as to be confusing to experienced C++ users
As it is, CORBA IDL strongly resembles C++, and in our experience most C++ programmers find
it easy to understand and use effectively.
Interface Repository (IR)
The Interface Repository is a service that provides persistent objects that represent the IDL
information in a form available at runtime. The Interface Repository information may be used by
the ORB to perform requests. Moreover, using the information in the Interface Repository, it is
possible for a program to encounter an object whose interface was not known when the program
was compiled, yet, be able to determine what operations are valid on the object and make an
invocation on it.
Dynamic Invocation Interface (DII)
This interface allows for the specification of requests at runtime. This is necessary when object
interface is not known at run-time. Dynamic Invocation works in conjunction with the interface
repository. The compilation of IDL declarations into C++ or C stubs allows clients to invoke
operations on known objects, but some applications must be able to make calls on objects without
having compile-time knowledge of their interfaces.
The flexibility provided by the DII can be costly, however. A remote request made through a
compiler-generated stub/skeleton pair can be achieved in a single RPC, but the same call made
through the DII requires calls to:
 Object: get interface to obtain an Interface Def object
  Interface Def: describe interface to obtain information about the operations supported by
the object
 Object: create request to create a Request object for the desired operation
 Request: add_arg for each request argument
 Request: invoke to actually make the request
Object Adapters (OA)
Object Adapters (OA) are the primary ORB service providers to object implementations. OA have
a public interface which is used by the object implementation and a private interface that is used
by the IDL skeleton. Example services provided by OA's are:
 Method invocation ( in conjunction with skeleton),
 Object implementation activation and deactivation,
 Mapping of object reference to object implementations,
 Generation of object references, and
 Registering object implementations, used in locating object implementations when a
request comes in.
An object adapter (OA) provides the means by which various types of object implementations
utilize ORB services, such as:
 object reference generation
 object method invocation
 security
 activation and deactivation of objects and implementations

Conclusion
With the weight of over three hundred OMG member companies behind it, the CORBA
Specification is well on its way to becoming the standard base for distributed OO applications.
Together, its flexible components allow legacy systems to work seamlessly with new pplications,
independent of the systems they run on and the languages used to implement them. C++ users can
rely on CORBA-compliant ORBs to help them develop portable distributed OO applications using
C++ in a natural fashion.
DOMC_02
CORBA: A Platform for Distributed Object Computing

Introduction
Object Management Group (OMG) designed to facilitate the communication of systems that are
deployed on diverse platforms. CORBA enables collaboration between systems on different
operating systems, programming languages, and computing hardware. CORBA uses an object-
oriented model although the systems that use the CORBA do not have to be object-oriented.
CORBA is an example of the distributed object paradigm.
The OMG is a non-profit consortium created in 1989 to promote the theory and practice of object
technology for the development for distributed operating systems. The goal is to provide a common
architectural framework for object-oriented applications based on widely available interface
specifications. With a membership of over 800 members, representing large and small companies
within the computer industry, OMG leads the specification development efforts of CORBA, OMG
IDL, IIOP, OMA, UML, MOF, and CWM specifications.
Overview of OMG OMA
The OMG offered its vision and approach to distributed computing:
To adopt interface and protocol specifications that define an object management architecture
supporting interoperable applications based on distributed interoperable objects. The
specifications are to be based on existing technology that can be demonstrated to satisfy OMG's
Technical Objectives.
The OMG has developed a conceptual model, known as the core object model, and a reference
architecture, called the Object Management Architecture (OMA) upon which applications can be
constructed. The OMG OMA attempts to define, at a high level of abstraction, the various facilities
necessary for distributed object-oriented computing. The OMG OMA partitions the OMG problem
space into practical, high-level architectural components that can be addressed by technology
proposers. It consists of four components:
 Object Request Broker (ORB),
 Object Services (OS),
 Common facilities (CF), and
 Application Objects (AO)
Rationale of OMG Technology
OMG offers a single view of distributed Computing and develops the reference architecture
(OMA) based on existing object technology. Underlying the OMA is a classical object model. In
this section, we explore OMG technology with reference to a number of issues like object model,
object granularity, multiple interface objects, interaction models, legacy systems etc.
Object models
The core object model is the highest level of object model. It defines a set of concepts commonly
needed to define other object models. The OMG core object model was first designed in 1992, and
called Core 92 model. An extension, as the name implies, is an extension to the core object model
and introduces a further set of concepts.
A profile is some combination of the core model, with one or more extensions, and provides a
useful set of concepts for specifying applications. For example, ORB profile (CORBA), ODBMS
profile, Object Analysis and Design Model. This can be summarized as follows
Core + Extension(s) = Profile.
The Core 92 model defines the concepts within its scope at three different levels.
Core 95
Core 92 model has an extension called Core 95 which identifies the concepts required to improve
the portability and interoperability of systems by describing the behaviour of objects. Most of the
components of the extension are still under discussion. The concepts expected to be part of a
complete Core 95 are:
 Object identity.
 Multiple interfaces per object and type conformance.
 Improvements in the definition of interfaces and their dynamic behavior.
 Stream interfaces.
 Binding.
 Services.
Object Reference and Interoperable Object Reference (IOR)
Objects in OMG model are identified by object references- an implementation defined type
guaranteed to identify the same object each time the reference is used in a request.
It is visible through operations defined by an interface and invoked using an object The object
reference itself is an abstraction, and is available to clients only as an The interface determines the
operations that a client may perform using the object reference The only way a client can observe
or affect the object is through operations defined
Single vs. multiple interface(s) objects
If a multiple interface object is needed, interface inheritance can be used to provide the
composition mechanism for permitting an object to support multiple interface, 3.6 Static and
dynamic invocation interfaces Operation invocations can be through either static or dynamic
interfaces.
Legacy systems
Many large institutions are held back by existing information systems developed some years ago.
These systems are mission-critical and must remain operational at all times. A fundamental
requirement for new platforms is to support legacy system migration such that the migrated target
system remains fully operational in new environments. CORBA provides a distributed object-
oriented approach to integrating legacy applications and enables the developers to write an object
wrapper to encapsulate the legacy system.
Interface Definition Language (IDL)
The Interface Definition Language (IDL) defines the types of objects by specifying their interfaces.
It is required that all OMG services be specified using a declarative language emphasising the
separation of interface and implementation. OMG IDL is used to statically define the interfaces to
objects, to allow invocation of operations on objects with differing underlying implementations.
From the IDL definitions, it is possible to map CORBA objects into particular programming
languages or object systems
CORBA interface architecture
The COI~BA specification defines an architecture of interfaces consisting of three specific
components: client-side interface, object implementation side interfaces, and ORB Core. The
client-side architecture provides clients with the following interfaces to the ORB and to server
objects:
a) IDL stubs.
The IDL stub presents interfaces comprised of functions generated from IDL interface definitions
and linked into the client program.
b) Dynamic Invocation Interface (DII).
While most clients in the CORBA world probably use stubs to invoke object services, the ORB
provides a dynamic invocation interface mechanism for specifying and building a request at run
time, rather than calling linked-in stubs. It is the client's responsibility to specify the types of the
parameters and expected results. The operations that support the DII include: create_request,
invoke, send, get response. Requests made by static and dynamic invocation are indistinguishable
by the server object. Using the DII, the interaction between client and server object can be RPC-
like synchronous as well as Deferred Synchronous. This allows asynchronous interaction between
caller and callee.
a) IDL skeleton.
This is the server-side counterpart of the IDL stub interface.
b) Dynamic skeleton Interface (DSI).
When a client on one ORB calls a server on another
ORB, the DSI transmits the request to the target ORB, and then the bridge uses the dynamic
invocation interface to invoke the target object on that ORB. The answer to all these questions is
the Object Adapter. The Object Adapter sits on top of the ORB Core communication services,
accepting requests for service on behalf of the server's objects. The Object Adapter is the means
by which object implementations access most ORB services, including generation and
interpretation of object references, method invocation, activation of an object, mapping references
to implementations, etc.
The object adapter has three different interfaces:
 A private interface to the IDL skeleton.
 A private interface to the ORB Core.
 A public interface for use by the object implementations.
From these three kinds of interfaces it can be seen that the adapter is intended to isolate object
implementations from the ORB Core as much as possible. The OMG prefers not to see a
proliferation of object adapters, so CORBA specifies a standard adapter called the Basic Object
Adapter (BOA). authentication). ORB interface. This interface is shared by the object
implementations and the object clients (see Client-side interface above). 4.3 ORB Core The ORB
What is CORBA2?
CORBA2 is used to denote the family of component specifications that together represent the next
major revision of CORBA 1.x. CORBA2 was adopted by OMG at the end of 1994. Additional
specifications will be added to this family in the future, for example, the IDL/Ada95 mapping.
The CORBA2 family of component specifications consists of:
• CORBA2/Core Common Object Request Environment.
• CORBA2/Interoperable.
• CORBA2 IDL language mappings.
The CORBA2/Core Common Object Request Environment consists of: • CORBA 1.2 minus IDL
C mapping. IDL C mapping is moved to CORBA IDL language mappings (see below).
• Extensions required to support RFP2 Object Services.
• Interface Repository extensions resulting from the ORB 2.0 Interface Repository RFP.
• ORB Initialisation resulting from the ORB 2.0 Interface Repository RFP.
• Inter-ORB Bridge Support.
An Overview of OMA Object Services
Objects in OMG's OMA are divided into Object Services, Common Facilities, and Application
Objects. The only purpose of this categorisation is to reflect the standardisation strategy for OMG.
Object Services are defined by OMG as those "interfaces and sequencing semantics that are widely
available and are mostly commonly used to support building well-formed applications in a
distributed object environment built on a CORBA-compliant ORB. Operations provided by Object
Services are expected to serve as building blocks for OMG Common Facilities or Application
Objects.
 The OMG Object Services API is modular, and objects may use few or many Object
Services.
 The Operations provided by Object Services are specified in IDL.
Adopted Object Services
The OMG Object Services Task Force (OSTF) has so far issued five RFPs (Request For Proposal).
RFP1 and RFP2 led to the adoption by the OMG of a set of specifications known as Common
Object Services Specification, Volumes 1 and 2 (COSS 1 and COSS 2). COSS 1 and COSS 2
include services for Object Naming, Object Events, Object Lifecycle, Persistent Object, Object
Relationships, Object Externalization, Object Transactions and Object Concurrency Control [20].
Submissions to P~FP3 and RFP4 which cover services for Object Licensing, Object Properties,
Object Query, Object Time, and OMA Security, are currently being reviewed by the OSTF
COSS 1
This service supports a name-to-object association called a name binding. A name binding is
always defined relative to a naming context. Different names can be bound to an object in the same
or different contexts at the same time. There is no requirement that all objects must be named. A
naming context is an object that contains a set of name bindings in which each name is unique.
19 This service addresses many design points identified for a name service: Naming standards.
It allows encapsulation of existing naming standards using a naming context.
COSS 1
The Object Relationship Service defines three levels of service:
The services in this section are part of COSS 2
a) Concurrency Control Service.
b) Externalization Service
c) Object Relationship Service.
d) Object Transaction Service.
Overview of OMA Common Facilities
Common Facilities is the third and final area of the OMA to be defined. They provide standardized
interfaces to common application services. So far, the OMG Common Facility Task Force (CFTF)
has issued RFP 1 and RFP 2. No specification has been adopted by the OMG for the Common
Facilities at this stage. In this section, we give a brief technical overview of those common facilities
requested. The OMG has defined a Common Facilities Architecture which identifies the high-level
service interfaces. There are two categories of Common Facilities: horizontal and vertical facility
sets.
Horizontal Common Facilities
The horizontal set of Common Facilities includes functions covering many or most systems,
regardless of application content. The OMA has considered almost sixty (60) candidate areas for
standardization of horizontal Common Facilities and they are divided into four groups:
a) User Interface.
b) Information Management.
c) System Management.
 d) Task Management.
CORBA vs. DCE
1. Implementation vs. specification.
OSF provides a reference implementation of DCE, and most vendors' products use this code. Thus,
the interoperability between different vendors' products is straightforward and there is no reference
implementation of CORBA. Interoperability used to be impossible until CORBA2 specifically
addressed this problem. Now portability is possible, but not trivial.
2. Infrastructure vs. Interface to an infrastructure.
DCE provides an infrastructure including a comprehensive set of services to support distributed
applications. CORBA defines interfaces to an infrastructure.
3. Procedural Model vs. Object-Oriented Model.
DCE is based on the Remote Procedure Call (RPC) paradigm. CORBA is object-oriented
technology, and there is an underlying object model defined for it.
4. Static vs. dynamic invocation interfaces.
DCE only supports static interfaces. CORBA supports a variety of invocation mechanisms:
5. Blocking vs. non-blocking Operation semantics.
DCE provides a variety of RPC semantics (at-most-once, idempotent, broadcast, and maybe), and
an application always sees a blocking RPC. Two styles of execution semantics are defined by
CORBA's object model:
• At-most-once (default)
If an operation request returns successfully, it was performed exactly once; if it returns an
exception indication, it was performed at-most-once.
• Best-effort (one-way).
This is a request-only operation, i.e. it does not return any result and the requester
never synchronizes with the completion (if any) of the request.
Question Three:

QPOD_01
QUERY PROCESSINGN IN OBJECT-ORIENTED DATABASE SYSTEM

Abstract
One of the basic functionalities of database management systems (DBMSs) is to be able to process
declarative user queries. However, the last decade has seen significant research in defining query
models (including calculi, algebra and user languages) and in techniques for processing and
optimizing them. Our particular emphasis is on extensible query processing architectures and
techniques. The other chapters in this book on query languages and optimization techniques
complement this chapter.
Introduction
Despite this close relationship, in this chapter we do not consider issues related to the design of
object models, query models, or query languages in any detail. The interrelationship between
object and query models is discussed in [Blakeley 1991; Yu and Osborn 1991]. Almost all object
query processors proposed to date use optimization techniques developed for relational systems.
However, there are a number of issues that make query processing more difficult in OODBMSs.
Relational query languages operate on a simple type system consisting of a single aggregate type:
relation. Relational query optimization depends on knowledge of the physical storage of data
(access paths) which is readily available to the query optimizer. Second, encapsulation raises issues
related to the accessibility of storage information by the query optimizer. Some systems overcome
this difficulty by treating the query optimizer as a special application that can break encapsulation
and access information directly. The optimization of path expressions is a difficult and central
issue in object query languages.
Query Processing Architecture
In this section we focus on two architectural issues: the query processing methodology and the
query optimizer architecture.
Query Processing Methodology
A query processing methodology similar to relational DBMSs, but modified to deal with the
difficulties discussed in the previous section, can be followed in OODBMSs. Queries are expressed
in a declarative language which requires no user knowledge of object implementations, access
paths or processing strategies. The calculus expression is first reduced to a normalized form by
eliminating duplicate predicates, applying identities and rewriting. The next step in query
processing is the application of equivalence-preserving rewrite rules [Freytag 1987] to the type
consistent algebra expression. Query rewrite is a high-level process where general-purpose
heuristics drive the application of transformation rules. Plan optimization, on the other hand, is a
lower level process which transforms a query into the most cost effective access plan, based on a
specific cost model and knowledge of access paths and database statistics.
The Open OODB query processor includes a query execution engine containing efficient
implementations of scan, indexed scan, hybrid-hash join, and complex object assembly is another
approach to query optimization extensibility, where the search space is divided into regions. The
regions are not necessarily mutually exclusive and differ in the queries that they manipulate,
control (search) strategy that they use, query transformation rules that they incorporate, and
optimization objectives they achieve. For example, one region may cover transformation rules that
deal with simple select queries, while another region may deal with transformations for nested
queries. Similarly, one region may have the objective of minimizing a cost function, while another
region may attempt to transform queries in some desirable form. Since the regions do not represent
equivalence classes, there is a need for a global control strategy to determine how the query
optimizer moves from one region to another.
Optimizer Architecture
Query optimization can be modeled as an optimization problem whose solution is the choice of
the “optimum” state in a state space (also called search space). In query optimization, each state
corresponds to an algebraic query indicating an execution schedule and represented as a processing
tree. The state space is a family of equivalent algebraic queries. Query optimizers generate and
search a state space using a search strategy applying a cost function to each state and finding one
with minimal cost.
Thus, to characterize a query optimizer three things need to be specified:
 the search space and the transformation rules that generate the alternative query
expressions which constitute the search space
 a search algorithm that allows one to move from one state to another in the search space
 The cost function that is applied to each state.
Many existing OODBMS optimizers are either implemented as part of the object manager on top
of a storage system, or they are implemented as client modules in a client-server architecture
3 Optimization Techniques
3.1 Algebraic Optimization
The components of algebraic optimizer include;
a. Search Space and Transformation Rules
A major advantage of algebraic optimization is that an algebraic query expression can be
transformed using well-defined algebraic properties. Each query has a number of
equivalent expressions, which make up the search space. These expressions are equivalent
in terms of the results that they generate, but may be widely different in terms of their costs.
b. Search Algorithm
Exhaustive search, whereby the entire search space is enumerated, is the most straight-
forward search strategy that can be used. A cost function can be applied to each equivalent
Typical cost functions used in query optimization take into account the various costs that
are incurred in processing the query. In non-distributed systems, this is typically the I/O
and CPU cost, while in distributed systems, the communication cost is also added
Parameterization
Path Expressions
Most query languages allow queries whose predicates involve conditions on object access along
reference chain. These reference chains are often called path expressions. They allow a succinct,
high-level notation for expressing navigation through the object composition graph. Path
expressions may be single-valued or set-valued, and may appear in a query as part of a predicate,
as a target to a query or as part of a projection list. The problem of optimizing path expressions
spans the entire query-compilation process. That is in user query, after rewriting, after parsing and
after optimization.
Query Execution
A query-execution engine requires three basic classes of algorithms on collections of objects:
(collection) scan, indexed scan, and collection matching. Collection scan is a straightforward
algorithm that sequentially accesses all objects in a collection. We do not discuss this algorithm
further. Indexed scan allows efficient access to selected objects in a collection through an index.
Set-matching algorithms take multiple collections of objects as input and produce aggregate
objects related by some criteria.
Path Indexes
Indexes enable fast computation of queries involving highly selective predicates and are useful
access paths to accelerate the computation of set-matching operations. Many indexing techniques
designed to accelerate the computation of path expressions have been proposed.
Set Matching
In the subsequent discussion we assume that we have two sets of objects R and S that stand in a
many-to-one relationship from R to S. We assume that R and S are stored as separate disk files,
and that the objects in R contain an OID to their related object in S.
HYBRID-HASH JOIN
The hybrid-hash algorithm applies the divide-and-conquer principle to the problem of computing
a join. The hybrid-hash join method takes advantage of the main memory available by performing
the first sub-join while building the sub files for subsequent
manipulation.
Pointer-Based Hybrid-Hash Join
The pointer-based hybrid-hash algorithm is used in cases when each object in contains a pointer
(PID, physical identifier) to an object. The algorithm uses the following three steps. First, is
partitioned in the same way as in the hybrid hash algorithm, except that it is partitioned by PID
values rather than by join attribute. Second, each partition of is joined with by taking and
building a hash table for it in memory.
CONCLUSIONS
This chapter reviewed some of the main contributions to object-database query processing. The
refinement, design, and better understanding of internal interfaces among the modules that
constitute a query-processing system will continue to be important research challenges. Building
query processors under highly modular and extensible architectural frameworks will accelerates
the technology transfer process of this rapidly evolving technology into working systems. Given
that query optimizers are fairly complex software systems to build, we expect to see an increase in
the use of optimizer generators to help build new query optimizers.
QPOD_02
OBJECT-ORIENTED QUERY OPTIMIZATION: What’s the Problem?
An object-oriented database model can support features such as abstract data types, methods,
encapsulation, subtyping (or inheritance), complex structures, and object identity. The processing
of queries in such a model also entails support for these features. Query optimization will require
new techniques for supporting the object-oriented features. Although many of the problems that
must be solved by an object-oriented query optimizer are similar to problems solved by relational
and extensible optimizers, there are also many problems that are unique to the object-oriented
model. However, we are more concerned with efficient processing queries in an object-oriented
database.
Object-oriented databases are extensible systems which support (among other features) abstract
data types, type inheritance (subtyping), methods and late-binding, and object identity. The
extensibility of object-oriented databases is founded on the ability to extend the data model through
abstract data types and the inheritance structure. In particular, the ability to define new abstract
data types provides extensibility in the database modelled by the types and places a requirement
on the database system to support the new models.
We discuss each problem in the context of the particular feature with which it is associated. This
approach provides important information for designers of database models and languages. It is
also important to understand how existing optimization approaches can be applied to object-
oriented query optimization and where new approaches are required. We believe that a better
understanding of the problems encountered can lead to the development of new (and better)
techniques for optimizing object-oriented queries.

AN OBJECT-ORIENTED DATA MODEL AND ALGEBRA

We use the ENCORE data model and query algebra as the foundation for our discussion of
problems in object-oriented query processing. The model incorporates data modelling features
found in other object-oriented systems such as abstract data types, subtyping (inheritance),
encapsulation, complex structures, object identity, and late-binding of methods. Thus, problems in
dealing with optimization in other models also arise in this model.
The implementation describes a physical representation for instances of the type and includes
implementations for methods described by the interface. Abstract data types and encapsulation are
synonymous in this model. Objects are encapsulated since all access is through the interface, and
the representation of the data and implementation of the methods is hidden. A query is concerned
with the interface of a type. However, processing of a query may need to consider the
implementation.
CURRENT RESEARCH
Query optimizers and optimization techniques are based on a particular data model and language
for that model. Query optimization was important to the success of the relational model, and
much of the current work in query optimization for extensible and object-oriented systems is
based on relational optimization results

3 problems in object oriented query Optimization

Object oriented database is expected to incorporate the following
 Abstract data type
 Subtyping
 Methods
 Late binding
 Encapsulation
The problems are organized by object oriented modelling features which generated them

Abstract Data Types

In an object-oriented model we need to incorporate optimizations for a changing variety of types.
An object-oriented query optimizer must be able to apply optimizations specific to the types, and
optimizations that look at relationships between objects of different types.
Complex Structures
The complex structure of objects (physical or logical) means that languages to query
the objects must have mechanisms for exploring their structure. In addition, languages which
allow the creation of objects need mechanisms for building new structures. The exploration and
creation of such structures can lead to the regular use of path expressions to navigate through a
structure.
Methods and Encapsulation
The applicability of algebraic transformations to object-oriented queries is complicated by the
object model. In general we have found that there are no universally applicable transformations,
and that type and storage information about objects is necessary in order to decide the utility of
an algebraic transformation.

Object-Identity
The identity of objects involves modelling and language decisions that can affect the optimization
of queries. The creation of new objects can lead to new definitions for equivalence of queries that
affect the transformations available to an optimizer. An optimizer for object-oriented models must
be able to deal with the creation of new objects and with alternative definitions for equivalence.
Equality of objects in a query can refer to any definition of equality for type Object

CURRENT RESEARCH
Query optimizers and optimization techniques are based on a particular data model and language
for that model. Much of the work in query optimization in extensible and object-oriented systems
is based on such rules about algebraic transformations in the query language. A need for
extensibility in data modelling and access led to the development of databases in which such
aspects as the data types, operators, and access methods can be extended. Extensible database
systems often use algebraic rules about query operations to provide transformations that can be
applied to queries to generate expressions.

SUMMARY
The optimization of queries in an object-oriented database entails support for the features of the
object-oriented data model. These problems discussed above need to be considered by designers
of database models and languages. Solutions to some of the problems identified will also require
optimization techniques that go beyond current relational optimization technology. An object-
oriented query optimizer must be able to incorporate techniques for solving the different problems.