www.btinternet.com/~adrian.larner/review/paton
Database Programming Languages
Norman Paton, Richard Cooper, Howard Williams, & Philip Trinder
Prentice Hall, 1996, 289pp, softbound, £22.95
ISBN0-13-101825-6
A Review by Adrian Larner for the Computer Journal
A DATABASE BOOK REVIEW
Since we started putting data in databases, it has largely parted company with processing: this book is about how to get them back together again. Between its Introduction, which tells us that the relational model keeps them apart, and its Conclusions and future directions, which tells us that the authors do not know which way the cat will jump, we find quite competent expositions of four saltatory alternatives: Deductive database systems, Persistent programming languages, Functional data languages, and (inescapably) Object-oriented (OO) databases. The book is intended for database practitioners, senior undergraduates, postgraduates, and researchers: it is best for the last. Beginning at the end, if you want to find an area to research, the final chapter is full of interesting ideas, including combinations of the topics discussed in the previous chapters.
The OO chapter suffers, as ever, from lack of theory. There is the usual confusion about encapsulation, viz that abstract data types hide structure: they exhibit specified structure, and hide implementation. Indeed we get plenty of OO confusions and vaguenesses. Thus, of the "is_a" relationship: What this ... means is a matter for specific implementations, but it is likely to suggest ... Or, on aggregation: the existence of a component often depends on the continuing existence of the composite object. Often! But what are the invariable semantics that characterise aggregation? And even: it is less than clear what [these operations] mean.... the databases [shown] model different real-world situations despite [being] derived using the same operations from databases which represent equivalent real-world situations. Neatly summarising: In some ways OO databases are the antithesis of everything the relational model represents. Quite so.
The chapter on the functional approach is quite stimulating. It may confuse traditional programmers: a variable must always have the same value ... Hardly a variable, is it? It would have been wiser to say that mathematicians and functional programmers use “x”, “y”, and so on as pronouns (there not being enough “it”s to go round), and, for mysterious reasons, they call these pronouns, “variables”. Surprisingly, having observed a problem with updates (impossible unless there is something variable), the authors do not suggest cutting the Gordian knot and proposing databases without updates and deletes (insert and read only: “WORM specification”, to coin a phrase).
The main interest in the persistent programming chapter is a neat Algol-like language, Napier88: its variables are persistent (i.e. saved between activations) if a certain (root) variable points to them, perhaps indirectly through other variables. This language has a powerful but horribly opaque facility, reflection: the generation and compilation of source code within a program (compiler CALLs, “Execute” in the APL or MUMPS languages). The deductive databases chapter is interesting: but read a good logic textbook first. Then you will be able to guess, for example, the implicit quantifiers to apply to the variables (pronouns!) in the examples of clausal forms, and their implicit scope.
Mostly, the authors appear non-judgmental, to the point of blandness. Thus we find that here are lauded simplicity, conceptual economy, and transparency; there power, richness, and consequent opacity. But this stance is abandoned when the relational model is discussed, almost any stick being good enough to beat it with, even when (as so often) specification and implementation have been confused. Read again the old myth of multiple joins leading to poor performance: the mere specification of joins can have no effect on performance, and the model says nothing of implementation. But, of course, the relational model really is the villain of the piece: it enabled us to have effective databases, i.e. data stores with data independence, deliberately segregating data from processing by means of views. “Data independence” (in the index) and “view” (not) make their leisurely appearance on p184 (as what we do not get in OO systems). Is it just possible, do you think, that the term “database” is beginning to be used in the sense of a mere (permanent) data store, ignoring data independence? If so, we can forget the relational model, but what then is the mismatch between data and processing? The programs would each own their data (as an object’s method set does). However, perhaps all those stick-in-the-muds with their relational systems really do value data independence. Perish the thought: could Codd have been right? Are there places that this cat must not jump?
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.