OBJECT ORIENTATION AND DATABASES

What is object orientation?

Object orientation is a programming paradigm where the world is seen as a collection of objects that exhibit both state and behaviour. The state of an object at any one time is the aggregation of the values of the object’s attributes. The behaviour is the set of messages to which the object can respond. Objects respond to messages by executing methods, short pieces of program code.

Objects are grouped into classes. So, for example, within an object oriented program to manage human resources there could be an Employee class with attributes of payroll Number, title, surname, other Names, birth Date, salary, etc. One of the instances of this class, an object, for our human resources department has the state ‘CX137, Mrs, Rogers, Jennifer Alyson, 10 January 1970, 27750’. This object also has an object identifier that is used by the system to uniquely identify the object. The object identifier is totally independent of the values of its attributes, is system generated, and is hidden from the user. This means that object orientation has no equivalent of the primary key concept of the relational model of data.

Examples of the sort of messages that instances of the Employee class may respond to are:

• ‘What is your surname?’, where the answer is generated by a method that reads the value of the surname attribute;

• ‘What is your full name?’, where the answer is generated by a method that concatenates the values of the title, other Names and surname attributes;

• ‘What is your age?’, where the answer is generated by a method that calculates the difference between the current date and the value of the birth Date attribute;

• ‘Change surname to (new surname)’;

• ‘Change salary to (new salary)’.

The fundamental concepts of object orientation

There are four fundamental concepts underlying the object orientation programming paradigm. These are:

• encapsulation (or data hiding);

• inheritance;

• polymorphism;

• aggregation.

Encapsulation is the hiding of the implementation of an object’s data structure and methods from the user. The only way that an object can interact with other objects is through the passing of messages. It is not possible to directly query the attributes of an object to find their value. We cannot, for instance, query the salary attribute of the ‘Jenny Rogers’ object of the Employee class and get the result ‘27750’, but we can send the message ‘What is your salary?’ to that object. On receipt of that message the appropriate method is executed and a message is returned which says ‘My salary is 27750’. The principle of encapsulation goes further in that we should not even need to know that objects of the Employee class have a salary attribute. The encapsulation principle can best be explained by considering an object of the Cube class within a system to handle geometric shapes. This object may respond to the message ‘What is the length of one of your edges?’ with the answer ‘3m’ and to the message ‘What is your volume?’ with the answer ‘27m³’, but we do not know whether objects of the Cube class have an edgeLength attribute and respond to the ‘What is your volume?’ message by calculating the cube of the value of that edgeLength attribute or if they have a volume attribute and respond to the ‘What is the length of one of your edges?’ messages by calculating the cube root of the value of the volume attribute. Furthermore, we should not care. Provided we know the messages that an object responds to, we know all that we need to know to be able to use that object in a program.

Inheritance is the ability of one object class to reuse the data structures and methods of another class without reimplementing them. For example, the Cube class can inherit the properties of the RectangularSolid class which, in turn, can inherit the properties of the RegularSolid class. Objects of the Sphere class can also inherit the properties of the RegularSolid class. All objects of the RegularSolid class can respond to the ‘What is your volume?’ message. This means that all objects of the RectangularSolid class (which includes all objects of the Cube class)and of the Sphere class can also respond to that same message.

Polymorphism is where different objects in different classes respond to the same message by executing different methods. For example, objects of the Cube class can respond to the ‘What is your volume?’ message by cubing the value of the edgeLength attribute, objects of the RectangularSolid class can respond to the ‘What is your volume?’ message by multiplying the values of the length, breadth and height attributes, whilst objects of the Sphere class can respond to the ‘What is your volume?’ message by cubing the value of the radius attribute, then multiplying the result by the constant 4π/3.

Aggregation, which is sometimes also known as containment, is the ability to group objects to make more complex or composite objects. For example, an object of the Department class may hold a reference (the object identifier) to an object of the Set class, where each element of that set is itself a reference to an object of the Employee class; a department contains all of its employees.

Object oriented databases

It is important that persistent storage of objects is available in any information system that hosts object oriented application programs. Some object oriented programming environments do provide persistent storage, but it is then closely coupled to the application programs themselves. There are, however, some object oriented database management systems available on the market, but they tend to be used in fairly specialised environments, such as computer-aided design and manufacturing (CAD/CAM) and geographic information systems (GIS). Those products that are available, although following generally accepted object oriented principles, have been developed using different approaches, such as the extension of an existing object oriented programming language or the development of class libraries using an object oriented programming language, and use different syntaxes for the data definition and data manipulation languages. There are no commonly accepted standards (yet) for object oriented databases.

The Object Data Management Group (ODMG) has, however, developed a formal specification for object oriented databases. This specification includes a data definition language called Object Definition Language (ODL) and a query language called Object Query Language (OQL). There is not a single manipulation language; the manipulation of the objects needs to be programmed in an object oriented programming language such as C++ or Java. Figure 12.6 shows a simple conceptual data model and Figure 12.7 shows the ODL schema definitions to implement it.

The extent is a name that is given to all the instances of this class within the particular database. This name is used by the OQL in its queries. The keys are not keys in the relational sense but are in fact uniqueness constraints. Remember that the equivalent in the object oriented paradigm of the relational model’s primary key is the system-generated object identifier, which is hidden from the user. Note that the ODL key declarations can include relationships as well as attributes – held_by is part of the key of Employee_Qualification.

Each attribute is declared with a name and a literal type. The payroll_number attribute of the Employee class uses one of the built-in literal types, string, whereas the address attribute of the Employee class uses a user-defined structured literal type, Address.

Each relationship is declared with both a forward and an inverse traversal path in each class involved in the relationship. For example, the relationship that each EMPLOYEEmay beholder ofone or moreEMPLOYEE QUALIFICATIONS and each EMPLOYEE QUALIFICATIONmust beheld byone and only oneEMPLOYEE is represented by the following declaration in the Employee class:

relationshipset<Employee_Qualification>holder_of

inverseEmployee_Qualification::held_by

and also by the following declaration in the Employee_Qualification class:

relationshipEmployee held_by

inverseEmployee::holder_of

The first of these declarations says that there is a relationship between Employee and Employee_Qualification called holder_of such that each instance of the Employee class may reference a set literal type whose elements are references to the instances of the Employee_Qualification class that represent the qualifications held by that employee (the forward traversal path) and to see that relationship from the other way you need to look at the specification of the held_by relationship in the Employee_Qualification class (the inverse traversal path). There can be zero, one or many elements in a set, so there may be zero, one or many qualifications recorded for each employee.

The second of these declarations says that there is a relationship between Employee_Qualification and Employee called held_by such that each instance of the Employee_Qualification class may reference an instance of the Employee class that represents the holder of this qualification (the forward traversal path) and to see that relationship from the other way you need to look at the specification of the holder_of relationship in the Employee class (the inverse traversal path). There can be only one employee holding each employee qualification.

Although set is used in these declarations for the ‘many’ relationships, it is not the only collection literal type that can be used. A set has no duplicates. If duplicates are possible, a bag collection type can be used. The elements of sets and bags are unordered. If there is an implied order in the ‘many’, a list collection type may be used.

Methods, such as the method to calculate the monthly payment from the annual salary, can also be specified. Only the method signature is included in the ODL specification; the methods themselves have to be implemented in another object oriented programming language. In the case of the calculate_monthly_payment() method, the result that is returned is of the Payment user-defined structured literal type.

Note that there is no explicit specification for optionality (mandatory or optional) for relationships. If it is required, optionality has to be handled through the use of methods.

Object relational databases

In the latest versions of SQL, published in 1999 and 2003, the scope has been extended to include some object-like facilities. Databases using these extended facilities are often called object relational databases. These object relational facilities include user-defined structured types and collection types, such as MULTISETS(‘multiset’ is another name for a ‘bag’ – a set where duplicates are allowed) and ARRAYS.

Figure 12.8 shows two structured types, st_address and st_qualification. (The st_is not necessary; it is just used as a device to distinguish a structured type from other database items with similar names.)The st_address structured type has five attributes (name_or_number, street, area, town, post_code); the st_qualification structured type has three attributes (name, award_date, awarding_body).

Figure 12.9 shows the CREATE TABLE statements that are needed to implement the conceptual data model shown in Figure 12.6 using these structured types. The structured types are used in the declarations of two columns in the employee table. Theaddress column is declared with thest_address structured type as its datatype - complete addresses are held as values in a single column. The qualifications column is declared with a MULTISET as its datatype, with each element of the MULTISET being of the st_qualification structured type - the complete details of the employee’s qualifications (zero, one or many) are held as a single value and there is no longer any requirement for a separate employee_qualification table.

Structured types are objects and so may have methods and may exist in inheritance hierarchies. In Figure 12.9, we see structured types being used as the datatype for a column. Structured types may, however, also be used as the specification for a table and, where inheritance is involved, this ability can be used to directly implement entity subtypes, something not previously possible. Figure 12.10 shows a revised conceptual data model that now includes two subtypes of EMPLOYEE, PART-TIME EMPLOYEE and FULL-TIME EMPLOYEE.

Figure 12.11 shows the CREATE TYPE statements needed to implement this revised conceptual data model using tables based on the structured types. The st_address and st_qualification structured types are unchanged. The st_employee type is very similar to the previous employee table with two very important differences. First, there are no constraints ( NOT NULL, PRIMARY KEY, etc.); constraints are applied to tables, not to types. Secondly, the attribute that will become the column that provides the foreign key to the department table has a different name and is of a REF datatype. This is explained when we see how the tables are created. The fact that st_part_time_employee and st_full_time_employee are both subtypes of st_employee is shown by the declaration that they are both UNDER st_employee.

Figure 12.12 shows the CREATE TABLE statements that use these structured types. The employee table has eight columns, seven from the structured type (payroll_number, name, address, birth_date, salary, qualifications and assigned_to_department_ref) and an additional column called row_id. This additional column holds a system-generated value of the REF type – the object identifier. It is also declared as the primary key. The CREATE TABLE statement for the employee table also includes the NOT NULL and FOREIGN KEY constraints.

The part_time_employee and full_time_employee tables are declared as being UNDER employee, i.e. as subtables of the employee table. The part_time_employee table now has nine columns, the eight columns inherited from the employee table and the additional weekly_hours column. All details of employees are automatically stored in the appropriate table, in the part_time_employee table for part-time employees and in the full_time_employee table for full-time employees. A query seeking the name and address of all the full-time employees reads the full_time_employee table. A query seeking the name and address of all employees reads the full_time_employee table for the names and addresses of all the full-time employees, the part_time_employee table for the

names and addresses of all the part-time employees, and the employee table for those employees who are neither full-time employees nor part-time employees (there should not be any of these). Thus, inheritance is managed under the covers’ by the database management system.