Internet Archaeol 15. Nick Ryan. Object-oriented models

2.2 Object-oriented models

The previous discussion of relational systems concentrated almost exclusively on the modelling of data. In practice, the complete design of a relational system will also involve an examination of how the data are to be used, the frequencies with which particular queries will be used, and many other aspects of the system's behaviour and performance. Much of this information will be fundamental for designing application programs that use the database for storage. Nevertheless, the traditional approaches to relational design maintain a clear separation between the stored data and the applications that use and maintain it. The object-oriented approach is intentionally more holistic in that it does not recognise this separation.

The basic element of an OO model is the object. Superficially, objects resemble entities. They represent instances of a class of physical or conceptual abstractions in the model. As with an entity, an object in this paradigm has a number of attributes. However, it also has a number of methods or functions that may be invoked to perform operations on the object. Thus an object has both a state, represented by its attributes, and behaviour, provided by its methods. This representation is shared by all members of the class.

Ideally, an object hides all of its state attributes behind accessor and mutator methods used respectively to retrieve and change the internal values.² Thus, the definition of a class of objects representing some type of artefact might include accessor methods such as getType, getDescription and so on. Corresponding mutator methods setType(String) and setDescription(String) would allow the values to be set or changed to the value supplied as the string parameter.

One of the motives of this information hiding or encapsulation is to make it possible to change the internal implementation of a class without needing to change its interface with the outside world. For example, the class might be initially designed with dimension attributes in which the values are stored in metres as real numbers. The accessor method getLength might then be defined which returns this value, and perhaps also a second method getLengthInMillimetres that multiplies the attribute value by one thousand and rounds the result to the nearest integer. Later, it may be realised that, as the data is mostly collected and used in integer millimetres, so it would be more appropriate to store this value as an integer. The first method can then be modified to convert this integer value to a real number and divide by one thousand, and the second to return the stored value. To any user or program relying on one or other of these methods, the behaviour of the objects remains unchanged despite the internal modifications.

Another important feature of the OO paradigm is inheritance. This is a mechanism by which a class may take on (inherit) the attributes and methods of a parent class, and perhaps extend or replace (override) them in order to provide similar but, usually, more specialised behaviour. For example, given a class Point representing a point in two-dimensional space with attributes x and y holding co-ordinate values, a three-dimensional class Point3D might be defined as inheriting all aspect of the 2D class and adding its own z co-ordinate value. Figure 5 shows this in a simple class diagram using the notation of the Unified Modelling Language or UML (Alhir 1998).

Figure 5 also illustrates a further OO concept, that of polymorphism. Both classes in the diagram have methods called distance which are intended to return the Euclidean distance between the point represented by the object and that supplied as a parameter to the method. If this method were only defined for the parent Point class, it would be inherited by its child Point3D, but any attempt to apply the method to a pair of three-dimensional points would then only return the two-dimensional distance in the x-y plane. Overriding this method in Point3D to return a three-dimensional distance achieves polymorphism in which each object exhibits behaviour appropriate to its type.

The distance method also illustrates how information that is not explicitly stored in an object can be derived from stored values simply by using a method that is part of the object, rather than needing to perform the operation in an external program.

Figure 5: a simple UML class diagram illustrating inheritance.

Figure 5: A simple UML class diagram illustrating inheritance

Whereas the relational model centres on decomposing complexity into its simplest components, the OO approach encourages the designer to think in terms of complete objects. The attributes of a typical entity are normally of simple or 'primitive' data types such as numbers or character strings. In contrast, objects may also be composed of other objects. For example, an Artefact class might use a Dimension class instead of explicit length, width and height attributes. The designer might then choose only to provide a getDimension method in Artefact, and to implement methods for getting and setting the dimensions in the Dimension class. The benefit of this approach is that the definition of the Dimension class could be re-used in a Context class, an Artefact class, or any other class where dimensions were needed. Each of these classes would then exhibit identical behaviour to any application that needed access to their dimensions.

This difference in approaches to complexity does not absolve the OO designer from a rigorous analysis of the data. It comes about through a consideration of the behaviour of objects and of where the responsibility lies for implementing behaviour. In a relational system, the query language is always used to re-assemble information from its components. In an OO system, it is the objects themselves that perform this task through their defined methods.

Much of this description of the OO approach has necessarily been written using the vocabulary of computer programming. As mentioned earlier, object orientation arose as an approach to the design and implementation of software programs rather than databases. For this reason, much of the demand for OO database systems has come from a need to provide persistent storage as an adjunct to programming languages. Few such systems have so far emerged, and most OO programmers have found adequate solutions using modern relational DBMS, many of which have evolved to address these demands.