BlueAdmiral.com

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 etc.
  
• 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 and
collections (eg persistent extension to C++). We shall look at both of these
approaches but first we will consider the some basic principles and terminology.

Object
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 calls).

Example

Object classes
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 class.

There are four essential principles of object orientation:

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

Encapsulation
An object's internal details (attributes and methods) are known only to itself and cannot be accessed from outside.

Inheritance
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
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
Objects are described by their attributes (often referred to as instance variables). For example. a particular student may have the attributes shown below:

enrolment_no	3145
first_name	Fred
last_name	Murray
Date_of_birth	lS-AUG-1975
Address	23. High street Slough
Course_enrol	HND COMPUTING
Modules_taken	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.

Encapsulation
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
Classes
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

class employee
/*variables*/
string name;
string address;
date start_date;
int salary;
/*messages*/
integer annual_salary;
string get-name;
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.

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

Multiple Inheritance
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 inheritance.

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

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

Example:

Abstract Data Types

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