Objects modelling

• Authors: Sylvia Osborn
• Venue: OODS '86 Proceedings on the 1986 international workshop on Object-oriented database systems
• Year: 1986

The points raised here are based on experience with RAD [Os86], an experimental relational database system which allows the definition of arbitrary abstract data types and arbitrary operations, for domains. The comments below fall into two categories: the appropriateness of the data model and the level at which programming is done.Data Model: For the applications motivating the object-oriented database discussion, one could enhance a programming language environment rich in abstract data type support, like Smalltalk, with the required database functionality as in GemStone [Co84], or one could enhance a database system by adding object semantics. RAD is about the simplest possible approach in the latter category. There are a great many applications for which commercial database systems do not have enough domain types, where the RAD approach seems to be adequate. However, there are other applications where the RAD approach is too simple. These applications have highly nested structures in which the root object consists of an aggregation of other objects, which are aggregations of other objects, etc. The choices in RAD, or any system based closely on the relational model are: (1) defining an abstract data type domain for the whole structure, (2) flattening the whole structure into first normal form relations with fairly atomic domains, or (3) some compromise between 1 and 2.RAD has two general classes of objects, domains and relations, each with very different operations. Choice 1 above means that the components of a complex object can never be accessed by the relational algebra operators. One must also avoid the temptation to re-implement a relational query language on a single domain. Choice 2 is also not a good idea. The data for a single object will be scattered so far and wide that an inordinate amount of work will be needed to retrieve it, update it, etc. With the third choice, somewhere between the two extremes, the point of compromise will be very difficult to decide on and one will still suffer from the drawbacks of the two extreme solutions.The problem here is not so much with the extensible database approach but with extending a relational database. The relational model is too simple to capture the structure of the complex objects at an appropriate level. An extensible database system whose underlying data model is semantically richer than the bare bones relational model, like Smith and Smith's [Sm77a, Sm77b] or SAM* [Su86], would do a much better job.Object modelling usually requires some form of inheritance or ISA hierarchies. Systems which support inheritance do so by defining it with respect to classes of objects. Relational database systems only allow one to define relation instances, not relation classes. Thus the relational model cannot properly handle inheritance.Current semantic data models make a sharp distinction between the structured objects they allow and atomic objects (in relational terms, between relations and domains) in the operations allowed on objects from these two broad classes. We are currently investigating an object oriented data model in which this distinction is not so sharp. Programming level: With RAD, the assumption is that new domain types are designed and implemented by application programmers. The end users of the object oriented databases are engineers, librarians, office workers — professionals in their own field but not professional programmers. In RAD, complex operations must be written by experienced programmers, not end users. If the objects in the application are indeed the complex, highly nested ones mentioned above, it may be very difficult to anticipate all the operations a user will want to perform on them. Users seem to be able to express their own queries in SQL or other database query languages. The challenge now is to devise a way for them to easily express complex operations on complex objects. This comment is also valid for GemStone. Smalltalk programmers are rare enough, but users capable of adding their own Smalltalk methods are even rarer.This type of comment also applies to the mechanism provided for defining new object types. In contrast to the operations, the structure of the complex types can probably be determined in advance. Thus defining the structure of a type is not likely to be a task for a user, but one which can be done in advance by the application programmer. This application programmer should not, however, have to be an implementor of the database management system in question. RAD has been successful in showing how a domain type can be introduced without the programmer actually knowing how the DBMS is implemented.