www.btinternet.com/~adrian.larner/review/dogac
Advances in Object-Oriented Database Systems
Asuman Dogac, M Tamer Özsu, Alexandros Biliris, & Timos Sellis (Eds)
Springer-Verlag, 1994, 515pp, hardbound
ISBN 0 387 57825 0
A Review by Adrian Larner for the Computer Journal
A DATABASE BOOK REVIEW
This book comprises the papers presented at the NATO Advanced Study Institute, Kusadesi, Turkey, in August 1993. There are in it 17 substantial papers: far too much material for your reviewer to do his usual justice to. Some of the implementation researches look promising, such as Özsu's on Transaction Management, a topic quite orthogonal to our choice of data model, whether relational or object-oriented (OO), or even to our choice of whether to use a database at all, rather than a mere data store (some files, say). You will recall the distinction: a database is a data store shared between applications and providing program/data independence (not in the index). Zdonik states, correctly, that in the OO paradigm “data and programs are not ... separate.... they are designed, implemented, and used together.” Yes: and maintained together, any change to shared data requiring modification of all the programs that use it, however irrelevant to them the data change might be. We were originally driven to use databases to avoid the costs of this unproductive maintenance.
On the face of it, therefore, OO and database are incompatible, and one would expect to see this stark problem addressed. Instead, the contributors choose to dance on one leg or on the other. Dittrich, for example, on the OO leg, thinks that in a relational database management system (DBMS), “complexly structured information has to be ... reconstructed from ... flat records during retrieval.” But it has only to be specified as “flat records”; the relational model permits it to be implemented in a way that avoids such reconstruction. In a paper that shows notable sensitivity to the problem of query language complexity, Beeri, on the database leg, shows how easily user-defined encapsulated atomic data types fit the relational model (not surprising, as they are domains ). Oddly, the editors’ preface shows no appreciation of this point, stating baldly that “the attributes of a relation may come only from ... fixed data type domains (numeric, character, and ... date types).”
Beeri, of course, is not interested in objects (which are variables), and cavalierly redefines “object” to mean value (making things a lot simpler). Contrast Alhajj and Arkun, who know that objects are variables, with value and identity, so that two non-identical objects can be equal in value. They want a query language with closure (good for them!) so a query should return objects, indeed new objects, with new identities (which, admittedly, is a pretty strange thing to ask of a query ). Gardarin mentions that, in IQL and LOGRES, “a new object is created only if no [current] object [has] ... the ... values [of the query result].” Hmm. In all the papers on OODBMS queries it is noteworthy how they all require lots of unnesting of data buried in objects. One wonders whether it would not be better to specify all this unnestable data as already unnested (but keep it nested in implementation, of course). Then the query language could be really simple: first order, perhaps; as if on flat records.
In both Gardarin’s paper and that of Mitchell, Zdonik, and Dayal, we find optimisation requiring permutation of manipulations (like moving restricts across joins). The latter explains that name(comp(s)), although apparently specified as applying the method, name, to the object resulting from applying the method, comp, to s, might be performed in some other sequence. This sounds as if “the system” might, as they say, “take responsibility” for the functions, comp and name, rather than their belonging to, or “being the responsibility of”, the objects s and comp(s). Another feature that optimisers seem to need is, if you will excuse a new coinage, disencapsulation of structure (digging out the structure, other than mere implementation, unwisely encapsulated in an object).
All this music-to-our-ears of queries and optimisation is dancing on the database leg with a vengeance. Any more of this and OODBMS will have suffered the death of a thousand cuts. But hush: what is left at the end can still be called “OO”. No-one will notice if the bandwagon has been hitched to another star. Perhaps a reader knows of such a star, not yet quite a red dwarf.
Copyright © 1996, 2001 Adrian Larner. The author asserts all moral rights.
The decorative image of a key (cc004239.gif) used on this page was obtained from IMSI's MasterClips/MasterPhotos© Collection, 1895 Francisco Blvd East, San Rafael, CA 94901-5506, USA.