|The object-oriented label is in common use.
It is applied to programming. analysis and design methodologies
as well as databases. Thus, there is a certain amount of confusion
concerning this term. To make matters worse from our point of
view, there is no standard object-oriented database model. At
the present time, there is no universally accepted, abstract,
formally developed object data model which can be used as the
basis of a database. Hence. you will find OODBs treated in different
ways in different books although there is general agreement on
the basic ideas. This chapter will cover the main principles behind
the object-oriented idea and give some examples of how an 00 database
may be implemented.
The basic idea behind the concept is that
users should not have to bother too much about the records and
fields which are a large part of the relational DB mode] but should
be able to deal with objects and operations on those objects.
It is claimed that this approach more closely resembles the real
world. In addition, the relational model has a number of shortcomings,
particularly when attempts are made to extend it beyond the type
of scenario with which you are now familiar such as that involving
customers, suppliers and parts.
As an example of the OO approach, consider
the EMP and DEPT tables that you know so well from your work with
Oracle. In the relational model you have a DEPT tuple plus a collection
of corresponding EMP tuples and all the paraphernalia of primary
keys. foreign keys and so on. If you want to insert a new employee,
you have to insert a new tuple into the EMP relation, making sure
that you have a unique primary key value, the correct foreign
key value etc. in order to attach him to a particular department.
In an equivalent 00 system, the user should be able to think directly
of a Department object that actually contains a corresponding
set of Employee objects. The user should be able to hire a new
employee directly into the relevant Department object. This seems
a more natural thing to do and, as you will see, there are a number
of other differences as well.
Factors influencing the development
of OO Databases.
- Relational DBs were conceived at a time
when commercial database applications used data with simple structures.
such as integers, character strings etc and based on atomic values.
New applications, such as CAD/CAM and multimedia. need more complex
data structures to handle images. sounds, graphics, video, the
maintenance of many versions of a design etc.
- As an example. consider multimedia data.
In general, such data is much larger than records used in a traditional
relational DB. For example. a video clip may be a gigabyte long.
Not only does this require suitable storage but it also poses
special retrieval problems. A client may want only part of the
clip but does not know which part without seeing the initial
few seconds. If he wants the whole clip, it has to be transferred
at a fixed rate over a period of time. not delivered as a whole.
Clearly, these requirements are not met by a relational DB where
the response to a query is a set of tuples delivered as a whole
to the client by the DB server.
- The normalisation process often results
in a proliferation of tables so that the data's semantics are
split between numerous tables. Several joins may be necessary
in order to extract meaningful data. These are costly in terms
of processing which, in the case of a CAD application where accessing
an object may require many joins. mar become a major problem.
- For some applications, relational data
manipulation languages (DML) may need to be augmented by procedural
versions eg PL/SQL. Alternatively, the DML may need to be incorporated
into a programming language such as C or Pascal. These languages
do not use relational "set at a time" operators but
tuple by tuple processing, using cursors.
- This encapsulation of SQL within a programming
language can cause problems.
Significant hardware developments have taken place since the
birth of relational DBs - decentralisation of computing power
onto powerful workstations, client server, parallel processing
- Emphasis on human-computer interfaces
- graphical. user-friendly interfaces are now important but the
amount of code needed to generate these is massive. It is said
that about 60% of an application's code is dedicated to user
interface dialogue. Relational systems were not designed to mange
graphical data orcomplex interfaces.
Object-oriented principles and terminology
Established approaches to systems modelling
abstract aspects from the real world in terms of data, process
and structure. However, humans perceive the world not in terms
of entities or activities but in terms of objects exhibiting both
state and behaviour. Hence, 00 is seen as a real-world modelling
paradigm, much closer to the way in which humans see the world.
There are two approaches to creating an
00DB - we can add the concepts of 00 to existing DB languages
(i.e. an extended relational database) or we can extend existing
00 languages to deal with DBs by adding concepts such as persistence
collections (eg persistent extension to C++). We shall look at
both of these
approaches but first we will consider the some basic principles
This corresponds to a 'thing' eg a person or vehicle. It could
also be an abstraction or a concept. It should have clearly defined
boundaries and be meaningful within its problem domain.
Objects have a unique identity. Unlike in a relation, where usually
the identifier (primary key) is given by the user, the object
identifier may be generated automatically by the system. If this
is the case the id is not directly visible to the user. This id
is associated with the object for its entire lifetime and, again
unlike the situation in relational systems, it is possible for
two or more objects to have the same property values and still
be distinct. (In the relational system this cannot happen because
the primary key is part of the properties of the entity).
All objects contain both data and code defining
what functions the object can
perform. In general, an object has associated with it:
- a set of variables
- a set of methods
- a set of messages which invoke a method
(these are not part of the object but are essentially function
Objects which have the same kind of properties and can be manipulated
using similar operations are classified to form distinct classes.
Each instance of a class has a unique identity, but has the same
set of data properties and responds to the same set of operators.
For example, all customers of a bank would be grouped into one
class and all accounts at the bank would be grouped into another
There are four essential principles of object
Abstraction is the selection of aspects of the real world for
examination in an effort to emphasise the important and ignore
the irrelevant. An object class contains attributes that illustrate
features of interest and methods the object carries out in order
to manipulate its data (procedural and data abstraction).
An object's internal details (attributes and methods) are known
only to itself and cannot be accessed from outside.
Inheritance allows classes to be refined into more specific classes
(subclasses). The subclass inherits the properties of its superclass
and also has unique properties of its own.
Polymorphism defines the principle by which a particular object
that receives a message knows how to process it in the appropriate
manner using its own methods.
Some of these principles will now be considered
in more detail.
Objects are described by their attributes (often referred to as
instance variables). For example. a particular student may have
the attributes shown below:
23. High street Slough
MIS, Databases. CSO. ISD etc.
Note that the traditional datatypes of real
numbers, integers, strings etc are used. In addition, object attributes
may reference other objects - the attribute 'Course_enrol' refers
to a Course object. The 'Modules_taken' attribute contains the
OID of an object that contains a list of module objects - this
is known as a collection object.
Methods and Messages
It has already been mentioned that
objects contain not only attributes but methods that enable it
to respond to particular messages. Methods are used to change
an object's values or to return the value of a selected attribute.
For the student object, for example, there is likely to be a method
called 'get-name which returns the student's name.
Methods represent real-world actions such as displaying the student's
name, adding a new student to a module and so on. Each method
will be identified by a name and will consist of a set of instructions
written in some programming language. Methods are invoked by messages
sent by the user or another object. The message has to specify
the name of the receiving object, the name of the method to be
invoked and any parameters that might be necessary. For example,
if you sent a message 'change address' to the student object it
would need a parameter 'new_address' which specifies the value
of the new address.
The polymorphism mentioned above means that the same message
may be sent to
different objects and these objects respond in different ways.
Each object has a
method which enables it to respond to a message in an appropriate
was. For example. the message 'unload' may be sent to various
objects but how the object responds depends on whether it is a
bus or a lorry. A bus will respond by stopping, opening its doors
and allowing the passengers to leave. A lorry will respond by
stopping and tipping their load.
It has already been mentioned that an object's structure is known
only to itself This means that a message is sent to an object
the sender object does not know how the action will be carried
out. This allows the method attached to a particular object to
be changed without affecting the rest of the system.
This restriction also means that the object can not be changed
in ways that were not anticipated by the person who defined it
since only the methods defined for it can modify it
Objects that share common characteristics are grouped into classes.
When a class is defined it contains a description of the data
structure and the methods applicable to the objects in the class.
So all the objects in the class share the same structure and respond
in the same way to the same messages. Each instance of the class
is an object with a unique OlD.
Definition of class
This could be represented in a similar way
to the object definition shown above with the addition of the
messages to which the members of the class can respond. As a further
example, here is a definition of a class employee
string get address;
string set_address(string new_address);
integer employment length;
Note that each object in the class will
respond to the 5 messages shown. The type name before the message
name indicates the type of response to the message. The code for
the methods which will respond to the messages is not shown.
This collection of messages defined with
the class is sometimes known as the class protocol and represents
the public face of the class since it is known to other objects
and to end users. The implementation of the object's structure
and methods form the private aspects of the class and will not
be known to others.
It is possible to declare one class to be a subclass of another
so that the subclass inherits all the properties of its superclass.
This is best illustrated by an example.
Clearly, there will be variables associated only with employee
(such as salary) and only with customer (such as credit rating).
The methods associated with each class can
be inherited in the same way as variables. This is useful because
the code is effectively re-used since the methods and functions
for one class (eg person) do not have to be written again for
objects of the subclasses employee and customer.
eg method get_name()
How objects associated with classes?
For leaf classes such as customer it is not a problem since we
associate with the customer class the set of all the customers
of the bank.
In the previous diagram, variables and methods for full-time emplo~es
are defined twice - for full-time tellers and for full-time secretaries.
This leads to redundancy and therefore to possible inconsistency.
Also, of course, it is not exploiting potential code re-use.
There are other problems. What should we do about part-time/full-time
employees who are neither tellers not secretaries?
These problems can be solved by multiple
One of the problems with multiple inheritance
is that there is potential ambiguity if the same variables or
method can be inherited from more than one superclass. For example.
a method for calculating pay may be defined one way for the full-time
class and in slightly different way for the secretary class. Which
one shall we use for the class full-time secretary??
The containment hierarchy mar be established when one object contains
other objects - that is, when the relationship is_part_of is applicable
rather relationship is_a.
Abstract Data Types
In setting up a relational database the relationships between
entities are not formally defined. We can represent simple relationships
by means of the foreign key/primary key system.
In the OO system we can specify precisely how an object connects
to other objects in the same or another class. This is done by
adding an appropriate line of code to the definition of the class.
Exactly how this is done will depend on the language used for
implementing the system.