Constructing Database Systems in a Persistent Environment

The goal of the Persistent Programming Research Group is the provision of an environment which incorporates the principle of orthogonal persistence in order to facilitate the production of large and complex software. A database management system constitutes such software and in this paper we show how a persistent store assists in the construction of such a system. We show that a small number of features in a simple persistent programming language enable efficient implementations of various data models to be built quickly. The paper surveys three attempts to provide database programs using PS-algol. In the first, the implementation of a single interface system is greatly aided by persistence. The second shows how it is possible to provide software which includes a multiplicity of interfaces and a multiplicity of underlying data models. Finally we present a novel approach which makes use of runtime compilation to create efficient storage structures tailored to the application. These experiments represent the early development of a methodology for choosing an appropriate mixture of static and dynamic binding when using persistent programming languages. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the VLDB copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Very Large Data Base Endowment. To copy otherwise, or to republish, requires a fee and/or special Permission from the Endowment. Introduction. When producing database systems in conventional programming environments, the programmer faces many kinds of problem. Some of these, such as organising data on backing store and linking to library modules, should not be the main concern. Instead, effort should be concentrated on ensuring that the most efficient storage structure is used and providing the interface best suited to the task in hand. It is also difficult in conventional environments to provide a flexible system. It is well known that different applications require different storage methods, while different interfaces suit different users’ needs. However, providing more than one storage method or user interface will usually create a considerable increase in the complexity of the system. The provision of a persistent environment [ATKI86a, ATKI86bl allows the programmer to concentrate on important issues and to ignore problems which should be handled automatically. Persistence is defined as the length of time for which an object exists. This may vary from shortlived local variables, which are created and deleted within a block, to data which are stored and intended to outlast, the computer system on which they are created. We believe that the way in which the programmer refers to a data object within a program should not be related to its persistence. Essentially, this means that the programmer will not have to refer to any mechanisms extraneous to the programming language (such as file managers) to handle the storage of data. It should be possible to use the structure used by the program to organise the data in the backing store. For instance, if the data is relational, to store all of the data in a relation the program only needs to enter a pointer to the 117 Proceedings of the 13th VLDB Conference, Brighton 1987 relations’s header into the backing store and all of the associated data (tuples, column names, etc.) will be stored automatically. This paper describes three database systems which have been implemented using the persistent language, PS-algol: a version of the Functional Data Model; a relational system, supporting a number of user interfaces; and a relational system utilising a run-time compile facility to create structures of greater efficiency. We will describe the benefits accrued from using PS-algol, although this is not an attempt to sell the language PSalgol, but rather to apprise the database and programming language researchers and practioners of the value of certain constructs which could be present in other languages. Features of PS-algol. PS-algol [ATKI83, ATK185, PSAL861 is a blockstructured persistent programming language. It incorporates the following features: Orthogonal Persistence. All PS-algol data objects are manipulated in the same way, irrespective of their persistence. The PS-algol environment includes a Persistent Object Management System [CQCK84, CAMP861, which handles all the details of data storage. Data to be stored is organised into ‘databases’ and any object reachable from the top level of a database will be dragged into backing store as part of that database, when a commit command is given. Data are copied to active memory incrementally as references to data objects are dereferenced. The Universal Pointer Type. The PS-algol type system contains a constructor for record-like objjts. These may contain any number of fields, each of which may have any PS-algol type. The references to the union of objects that may be constructed in this way have a common type, pntr. This allows the programmer a degree of polymorphism, in that values of type pntr may be tokens for instances of any existing structure class and therefore objects of different types can be passed along the same route, or referenced from the same location. Type checking is still rigorous, although it does not occur until a pntr is dereferenced, prior to performing some operation on the referend. All other type checking is performed at compile time. First-class procedures. Procedures are first-class objects, in that they may be manipulated like any other object. They may be: assigned to variables; used as the arguments or produced as the result of another procedure; and, most importantly, stored in a database just like any other data value [ATKI86b]. The implication of the latter is that, having been designed in a modular fashion, a program can be developed incrementally. Each module can be coded and tested separately and, as will be seen, different versions of a module can be simultaneously available. Experiments can be run which determine the most effective version and more than one version can be left in the system. This leads to flexibility. It also permits the development of system libraries of procedures and allows the access to data to be limited to a set of procedures, forming an abstract data type (ADTI and allows active data to be modelled [COOP87]. A Callable Compiler. I?+algol contains, as a library function, a call to the compiler. This means that a program, during its run, can construct a procedure as a string and then compile that string and apply the resulting procedure. This is extremely useful as, while the type system of PS algol is strict (allowing early detection of data misuse), the callable compiler enables a procedure which is truly polymorphic to be written. The structure of such a procedure is given an object of any type, examine its type, build a procedure which handles such a type, compile it and run it against the input object. The cost of compilation can be recovered if the procedure is stored and often re-used when objects of the same type are encountered. Indexed Objects. There exists in I%algol a data structure in the form of a table a set of pairs of keys and associated structures, accessed through a universal pointer. This provides instances of adaptive index structures. Graphics Facilities. The language has bit map, multifont text and line drawing graphics facilities. The implications of this for the production of good user interfaces will not be discussed in this paper, but machine independence is derived from having good tools for producing interfaces within the language. Furthermore, graphical data can be modelled with the same ease as textual and numerical data. [MORR86] describes the graphics facilities in more detail. A Uniform Portable System. PS-algol aims to provide a uniform environment within a number of systems. At present, implementations exist for the UNIX systems on VAX, ICL PERQ and SUN 118 Proceedings of the 13th VLDB Conference, Brighton 1987 computers, as well as for the Apple Macintosh and within VME on the ICL 3900 series machines. In each of these implementations, the program developer needs only to know PS-algol and has no need to understand the details of the underlying system.