This paper presents some experiences in the exploitation
of a databaseinterface development architecture in which the interface
is implementedusing the facilities of the database. It is shown
how novel interfaces,specifically a multi-paradigm query interface
and a debugger for an activerule system, can benefit from and
exploit the uniform representation ofinterface and database system
concepts as database objects.
It is clear that database interface research lags behind certain other aspects of database system development [24]. This is perhaps not surprising, as recent research in database systems has, ingeneral, extended the facilities which a database system is expected to support. This in turn leads to increasingly sophisticated systems,with more facilities which must be accessible through the interface todifferent categories of user. This trend presents twodistinct and complementary challenges to database interface developers:the identification of what facilities are required by users ofadvanced database systems, and the provision of tools which indicate such interfaces can be constructed. This paper addresses both ofthese issues, although the principal focus is upon the latter, namely the provision of facilities which assist in the process of implementingdatabase interfaces.There is no single architecture for the implementation of database interfaces;many approaches have been proposed, some of which emphasise a clear separationbetween different interface components. This paper, however, focuses upon theprovision of interface development tools which are fully integrated with theunderlying database. This enables a single representation to be used for themodelling of application, system and interface data, which it is argued is ofparticular value to database interface developers. The approach is illustratedusing two example interfaces which have been developed for the ADAMobject-oriented database (OODB) []. These example interfaces are both novel in terms of the functionalities they support, and thus indicate how the requirements of advanced database facilities can be supported within an integrated interface development environment.
The paper is structured as follows: section 2 presents
relatedwork, outlining both the increasingly demanding requirements
presented by database systems to their interfaces, and the range
of techniques which havebeen used to implement database interfaces;
section 3 gives an introduction to the project of which this work
is part, its motivation, thebasic interface development tools
supported, and some early work on theirapplication; sections 4
and 5 contain substantial examples of the exploitation of uniformity,
specifically a multi-paradigm query interface and an active rule
system debugger; conclusions are presented in section 6.
Commercial database systems invariably support a range of interfaces andinterface development tools. For example, commercial relational systemssupport database access and update using SQL, and allow form interfaces to be constructed interactively for well defined repetitive tasks likedata entry. Such interfaces are necessary and appropriate for a range oftasks and users, but are not sufficient to support effectively the wide spectrum of database activities associated with a complex site, and arerarely targeted towards emerging database technologies. Focusing upon the latter, it is clear that many new facilities and constructs are beingproposed for use with future database systems: the management of complexand composite objects, potentially with versions; support for advanceddata types for use in multimedia or spatial applications; the introductionof a temporal dimension to allow monitoring of change; the development ofactive facilities to support automatic and timely response to events ofrelevance to the database. Such extensions to database systems requirethat corresponding revisions be made to database interfaces. A significantchallenge for database researchers and developers is to increase thefunctionality of systems without reducing their accessibility ormaintainability, a challenge which will only be met if considerableattention is directed towards database interfaces.
Various researchers have proposed database interfaces
which are targetedat specific extensions to database functionality,
including compositeobjects and user-defined relationships [2],
versions[12], spatial data [15], persistent data types[6] and
programs [10]. It is clear from such work that there is an extensive
design space, with many alternativeways of representing different
concepts and operations applicable to them. This range of requirements,
combined with the variety of possible solutions,suggests a need
for effective tools to facilitate rapid constructionof database
interfaces, so that proposals can be evaluated effectively with
users [19].
As far as interface development architectures are concerned, there is a sense in which database interfaces are nothing special. The database can be seen as an application for which an interface is required, and conventional approaches to interface development used to institute a solution. From this perspective, database interfaces can be implemented using software such as user interface management systems or widget sets, and examples of the use of such systems with databases abound [25, 3, 14].
There is also an extent to which, however, database
interfaces can be held to be different from interfaces to other
software systems. Such a distinction can be drawn from the observation
that databases and interface management systems both include facilities
for the structuring and manipulation of data.In the case of the
interface management system, information must be stored which
describes (for example) windows, their contents, relationships,
properties and operations. As (some or all of) this information
could be stored and manipulated using the facilities of the database,
an obvious solution is to use the database to store information
on its interface, and to use the language(s) of the database to
manipulate such data. For this to be practical, the database must
support comprehensive mechanisms for the structuring and manipulation
of interface data, but a number of approaches have been reported
in the literature [17, 4, 13, 16]. The use of an integrated architecture
avoids impedance mismatches between the language used to store
and manipulate interface data and that associated with the database,
as discussed further in [21]. Some systems, as well as using database
constructs for modelling interface data also implement interface
development facilities within the database []. This paper presents
experience with an OODB which integrates database and interface
data, where the benefit of uniformity is combined with the recognised
strengths of the object-oriented paradigm for interface development.
The distinctive features of this paper are the description of
how database objects can be used beneath the surface of the interface,
and the exploitation of active database facilities in interface
development.
The work presented in this paper was initiated with
a view to providing an effective interface to the extensible OODB
ADAM. In ADAM, support for metaclasses as first class objects
enabled its core data model to be extended with a range of facilities,
including relationship objects[7], active rules [9] and composite
objects with versions [18]. Where the data model can be extended
with new constructs, it is necessary to be able to extend the
interface to the database with visualisations relevant to the
extensions, otherwise users are likely to be unaware of the semantics
of the objects to which they are exposed [20]. The approach taken
to the solution of this problem is presented in the following
subsections, along with a summary of initial results.
The use of metaclasses in ADAM to support extensibility has the important consequence that database objects are used to represent application data, data dictionary information and the system itself. This means that the same language and structuring mechanisms as were used to implement the ADAM system are used to construct applications for ADAM. This has the further consequence that an application programmer can become a system developer, extending the system with new facilities as required, using mechanisms which are familiar from the development of normal ADAM applications. By representing interface data using normal database objects, it becomes possible for graphical interfaces to be developed within this uniform context.
The representation of interface data as normal database
objects has been achieved in ADAM by providing a view of an existing
widget set using ADAM classes [19]. The effect of this process
is to make availableto ADAM programmers around 60 classes which
describe dialog boxes, menus, pictures, buttons, etc. Instances
of these classes are created and manipulated by message-sending,
in common with other database objects, but messages can have visible
consequences. For example, sending the message open to
an instance of the class picture will lead to a picture
window being opened on the screen.In this paper, code fragments
are not presented in ADAM notation (for which see [11, 20]), but
rather using a form which requires minimal introduction. All examples
presented in the paper represent functionality which is fully
implemented. To exemplify the creation of a toolkit object,the
class picture can be defined as follows:
class picture is_a window {
attributes {
name: string;
member_graphics: set of graphics;
...
}
}
Thus each picture object has a name
and a set of graphics objects (lines, circles, bitmaps,
etc) which have been drawn in the picture. When the message open
is sent to an instance of picture, a window is opened on
screen in which are drawn the objects from the member_graphics
attribute. As such, toolkit objects are standard database objects,
they can be directly related to application concepts (e.g. a road
object can have a reference to the line objects which represent
the road in a picture), and can be stored persistently
alongside the appropriate application data.
This subsection outlines some preliminary exploitation
of the representation of interface data as database objects, emphasising
the use of a common data model, the parallel evolution of interface
and database constructs, and support for additional interface
functionality. Each of these aspects is illustrated through an
example in the rest of this subsection. More detailed presentation
of more recent results is given in sections 4 and 5.
The first substantial program to be implemented using the toolkit mentioned above was a database browser which allowed the examination of schemas and their associated instances [20]. The browser was itself defined as an ADAM object, with reference to the various toolkit objects which were used to display information on screen. An example screen from this browser is presented in figure 1, where an instance object from the toolkit is being browsed - in effect the browser is being used to examine its own internal structure.
Figure 1: Layout of
database browser showing fragment of schema and a form browsing
an instance of the class tree.
A particular benefit which stems from the implementation of the
browser within the database environment is the ease with which
database information is made available to the browser. Whenever
the user selects information for display, the callback behaviour
of the browser, which is implemented as ADAM code, can directly
access database instances or metadata. This both simplifies the
implementation of the browser and speeds access to the database
from the interface.
As mentioned in section 3.1, extensible databases essentially require extensible interfaces, otherwise what is shown to the user will not reflect what is stored in the database. To enable experimentation with a range of alternative visualisations of advanced data modelling constructs, the browser described in the previous section was used as a testbed for prototyping a range of visual representations of modelling features[1]. The rapid implementation of these extensions to the browser was facilitated by the ease of access to the new modelling constructs which were also represented as database objects, and by the use of such object-oriented programming mechanisms as specialisation and overriding to tailor the default visualisations supported by the browser [19].
Revised visualisations were essentially implemented as follows:
Thus the development of enhanced visualisations exploited both
the uniform representation of database and interface data, and
the object-oriented nature of such data in the ADAM system.
Being objects, interfaces can benefit from all the functionality already available for standard objects such as persistence, concurrency control, integrity and security maintenance, and query languages. For instance, the query language can be used to retrieve all interface objects in which red circles appear. In ADAM, database objects can also be associated with active behaviour, i.e. behaviour which is not explicitly invoked but which is automatically executed as a result of a given situation being encountered. The definition of such behaviour involves the description of the situation to be monitored and the action to be taken when the situation occurs. How interface objects can profit from this feature is illustrated in what follows.
In a graphical interface which is used to display database objects, dynamic displays are updated automatically as modifications occur to the database objects being visualised. In this way, the consistency of a database object and its graphical representation(s) is maintained. This requires that changes to database objects be notified to all interfaces which are displaying them. For this mechanism to be efficient, such monitoring should be restricted to the objects being displayed, rather than affecting the whole database. This requires that an up-to-date record is kept of all displayed objects.
The point to notice is that the situations to be monitored involve both the interface on which objects are displayed and the objects which are being displayed. Since interfaces are objects, the same active mechanism can be used for both tasks. Thus whenever the display is updated by the user, the active mechanism can respond automatically to ensure that all displayed objects are monitored. The active behaviour which is used to monitor the displayed objects can then inform the interface of all changes to these objects, so that the display can be updated to reflect the revised state of the database [8]. In this database are used to allow monitoring of the specific objects that are on screen, rather than having events monitoring updates to all objects in the database.
If interfaces were supported separately from the DBMS, interface
tracking would have been implemented in an ad-hoc manner,
increasing the difficulty for the programmer of maintaining the
system - it would not have been possible to use a single mechanism
to monitor change at the database and at the interface, and each
monitoring mechanism would have been required to cross the database/interface
boundary whenever a relevant change was detected.
This section describes the implementation of a multi-paradigm query interface which provides three different query interfaces paradigms, namely textual (Daplex) [23], form-based and graph-based. Each query interface is a separate component, but the option is provided to translate between any of the above query paradigms. It has been perceived that different users or categories of user may prefer or be best suited to different query interface styles. A multi-paradigm interface provides system support for different categories of user by allowing users to select the interface with which they feel most at home. Therefore, a multi-paradigm interface can be used to enhance the accessibility of an object-oriented database.
The architecture of the multi-paradigm query interface is presented in figure 2. In this architecture, the interfaces, the internal form and the database are all described using database objects. The graphical interfaces share the same object-oriented structures to describe queries internally, which are constructed incrementally in response to user operations, and which can be mapped into the internal form of the optimiser, which is used to plan efficient evaluation strategies. A mapping has also been developed which allows Daplex queries to be described using the object-oriented structures, thereby facilitating the translation of Daplex queries into any of the graphical query paradigms, and supporting the translation of the object-oriented internal form into Daplex.
Figure: Architecture
of the multi-paradigm query interface.
The implementations of the interfaces are essentially built around the four ADAM classes depicted in figure 3, namely query_mixin, daplex_interface, graph_interface and form_interface. This class hierarchy allows the functionality common to all the paradigms to be stored in query_mixin and then inherited by the specific interfaces.
Figure: Overview
of classes used in the implementation of query interfaces.
The visual representations required by the three existing paradigms are very different - the Daplex interface requires an editor window into which the textual query can be typed; the form-based interface requires a class browser where all the classes of the database to be queried are displayed; the graph-based interface is based on two picture windows, one depicting graphically the database schema and the other the query graph. All the interfaces require an operation panel which consists of a number of buttons providing facilities for constructing, editing and executing the query. For example, Condition and Aggregate buttons in the form and graph-based interfaces are used to enter boolean conditions, and to express the aggregate operations for the query. In all the interfaces, a Run button is used to execute the query, and the --;SPMgt;Daplex, --;SPMgt;Graphand --;SPMgt;Form buttons are for translating the current query into other paradigms. Figure 4 is a screen dump of the top-level window of the graph-based interface.
Figure: Layout
of the form-based query interface.
Figure: Layout
of the graph-based query interface.
Information associated with the display of a particular
query interface is stored as properties of the class used to model
the corresponding paradigm. For example, in the case of the graph-based
interface depicted in figure 4, the class graph_interface
must reference the base windows which contains the interface,
the buttons which provide the operations, the figures which represent
the schema, and the figures which represent the query. This is
done by defining properties on graph_interface which reference
the widget objects which are displayed on screen. As the widget
objects are normal ADAM objects, their object identifiers can
be stored directly in the attributes of graph_interface.
For example, the following code fragment shows part of the definitions
of query_mixin and graph_interface:
class query_mixin {
attributes {
internal_form: internal_query_object;
...
}
...
}
class graph_interface is_a query_mixin {
attributes {
schema_window: picture;
query_window: picture;
operation_panel: dialog;
run_button: button;
...
}
}
In all the interfaces, queries are represented internally using an object-oriented form defined as an instance of internal_query_object accessed through the internal_form attribute of query_mixin. The internal_query_object has four attributes which are the components of a query, namely, main_query, subquery, boolean_expr and aggregate_expr. The main_query is an object-oriented canonical form that stores both scalar and non-scalar attributes of the objects whose values are being retrieved; the boolean_expr is the textual expression of the boolean conditions of the query; the aggregate_expr is used to store information on the aggregation operations over the main_query; the subquery is itself an internal_query_object. The structure of the internal_query_object is depicted in figure 5.
Figure: Structure
of the internal_query_object.
Since all the interfaces use a common internal form
to represent a query, the translation of the queries between different
interfaces simply involves the visualisation of the internal form
of the query being translated. This internal representation groups
together related concepts, which are in turn normally closely
associated in the graphical or textual languages. For example,
a node in a graph-based query interface is associated with a menu
which lists the attributes of the object and the relationships
in which it is involved. Exactly this information is stored in
the _store and scalar_slot_gen slots of the OO_Form
object in the internal representation of a query depicted in figure
5.This structuring of queries means that queries can be translated
between paradigms by a traversal of the object-oriented internal
form. Such an approach can in turn be implemented by defining
methods on each of the nodes within the internal form so that
they know how to translate themselves for use in each of the visual
interfaces, an organisational technique which has also been used
in object-oriented compiler construction[5].
One of the major problems in database application development is the impedance mismatch between the language used for the implementation of the application or interface and the language of the database itself. However, this problem is completely avoided in the multi-paradigm query interface, as the interface, the database and the internal form of a query are all represented as database objects.
In the context of query interfaces, database access
is performed at two levels: at the instance level when evaluating
a query, and at the metadata level when building a visualisation
of a database schema or a representation of some part of a schema
(e.g. a form). Both of these categories of access are carried
out regularly, and in an interactive context where efficient processing
is essential. By integrating the interface with the database,
it is possible to perform query construction, answer presentation,
visualisation presentation and inter-paradigm translation without
the need to perform any cumbersome mappings between different
languages or systems. This considerably eases the amount of effort
that is required both for programmers building such applications,
and for the system which is required to execute the resulting
functionality.
Figure: The
DEAR architecture.
Figure: Definitions
of objects participating in DEAR.
Database systems have traditionally striven to support the structural features of a domain, but considerable effort has recently been put into capturing behavioural characteristics as well. Object-oriented DBMS (OODMBS) and active DBMS illustrate this tendency. Database interfaces should evolve accordingly.
The previous section has focused on how to display structural data. However, displaying the dynamic side poses new challenges. Whereas database structure can be obtained by querying attributes, the dynamics of database behaviour requires obtaining relevant information on the fly as the flow of control proceeds. Here, event trapping rather than attribute querying is required, where an event stands for a happening of interest.In the context of an interface, this could be any occurrence that is relevant for tracing or explanation purposes.
Event trapping on external systems is a non-trivial task. Interaction with the interface to the external system commonly occurs by way of message-sending mechanisms, i.e. the observed system interacts with the normal interface to the database. By contrast, event detection is non-intrusive i.e., the observed system is unaware that it is being observed; observation, unlike interaction, does not disturb the monitored system. This requires that the graphical user interface (GUI) be able to place relevant event detectors in the observed system to keep track of the dynamics of the system. Such an architecture for an interface debugger is shown in figure 6.
The architecture closely follows the Model-View-Controller (MVC) framework [22]. The observed system is the model, the interface or way of presenting the information to a user, is the view, and finally, the debugger controller supports the interactive aspects of the problem. The controller interprets input events according to the current context of the application, and interacts with the model and the view component. It is worth noticing that here, input events can arise from either the user or the observed system. In most MVC implementations, the model keeps a list of its views so that the model can inform its views of any change. Instead, in this implementation, event detectors are placed on the model to inform the controller, which in turn, can undertake appropriate actions on the views.
DEAR, a DEbugger for Active Rules, investigates on how to display active DBMS dynamics, more concretely, active rule interactions. Active rules are being incorporated into database systems to provide automatic responses when given circumstances are reached, without user intervention. A common description of these rules is through an event which triggers the rule, a condition to be evaluated against the database, and an action to be performed if the condition is satisfied. Unlike passive databases, active systems can react autonomously to situations which require timely responses. Experience using active rules has shown that, while rules can be exploited beneficially in a range of applications (e.g. constraint maintenance, derived data support), it is not a straightforward task to implement, debug or maintain large rule bases. It is thus important for active rule systems to provide debugging tools. Of course, a paramount component of such a debugging tool is an adequate interface.
Since active rules do not have a fixed order of execution, but are fired once appropriate events occur, the dynamics correspond to the cycle of event detection and rule execution. Figure 7 shows such an event-rule cycle. The representation is a tree where the root is created artificially (the corresponding node is labeled root), and its direct descendents are the first events that have been raised. Such events can cause rules to be fired which, in turn, can raise further events when their actions are executed.
DEAR follows the architecture shown in figure 6. As the GUI is part of the OODB, the debugger controllers and debugger interfaces are all represented using the same object-oriented language. Moreover, communication between the observed system (i.e. the DBMS) and the debugger controller is achieved by using the active rule mechanism provided by the underlying DBMS. The definitions of one of these rules, a debugger controller and a debugger interface object are shown in figure 8.
A debugging session proceeds as follows:
Since all components are objects, unintrusive communication is easily achieved through the event mechanism available in the active DBMS.
From the interface point of view, our implementation of an active rule debugging tool has to address the following challenges:
Modern database systems are evolving to support an
increasing range of facilities for both structuring and manipulating
information in data intensive applications. These facilities introduce
requirements for additional interface functionality, but also
provide an increasingly supportive environment for the implementation
of database interfaces. This paper has demonstrated how object-oriented
and active constructs in database systems can be exploited in
the development of advanced database interfaces. These facilities
have been used not only to represent the layer of interaction
objects which are presented to the users directly, but also to
organise the internal structure of the interfaces and to coordinate
interactions between these structures.The resulting approach reduces
complexity for developers, as no cumbersome mappings are required
between different languages or systems, and thus eases modification
and extension of database interfaces, as required by iterative
development techniques.
Acknowledgements: This
work was carried out when the first two authors were at Heriot-Watt
University, where Khoa Doan was supported by the UK Engineering
and Physical Sciences Research Council. We are also pleased to
acknowledge the role of the EU Human Capital and Mobility network
ACT-NET in supporting interaction in the area of active databases
involving Oscar Diaz, Arturo Jaime and Norman Paton. The software
presented here sits on top of an interface toolkit implemented
by Ghassan al-Qaimari.
[1] G. Al-Qaimari and N.W. Paton. Design and Evaluation
of Visualisations for Advanced Data Modeling Constructs. In C.
Chrisment, editor, Basque International Workshop on IT (BIWIT),
pages 169-182. Cepadues Press, 1994.
[2] G. Al-Qaimari, N.W. Paton, and A.C. Kilgour.
Visualising Advanced Data Modeling Constructs. "Information
and Software Technology", 36(10):597-606, 1994.
[3] J. Almarode and T.L. Anderson. GemStone Visual
Interface Designer: A Tool for Object-Oriented Database Design.
In Object-Oriented Databases: Analysis, Design and Construction
(DS-4), pages 73-94. North-Holland, 1991. W. Meersman et al
(Eds).
[4] T. Lougeia Anderson, E.F. Ecklund, and D. Maier.
PROTEUS: The DBMS User Interface as an Object. In On Object-Oriented
DB Systems, pages 139-156. Springer-Verlag, 1991. K.R. Dittrich
and U. Dayal (Eds).
[5] M.L. Barja, N.W. Paton, and M.H. Williams. Semantics
Based Implementation of a Deductive Object-Oriented Database Programming
Language. J. Programming Languages, 2(2):93-108, 1994.
[6] A. Dearle, Q. Cutts, and G. Kirby. Browsing,
Grazing and Nibbling Persistent Data Structure. In Proc. 3rd
Int. Workshop on Persistent Object Systems, pages 56-69. Springer-Verlag,
1989.
[7] O. Diaz. The operational semantics of user-defined
relationships in object-oriented database systems. Data and
Knowledge Engineering, 16:223-240, 1995.
[8] O. Diaz and A. Jaime. EXACT: an EXtensible approach
to ACTive object-oriented databases. Submitted for publication,
1994.
[9] O. Diaz, N. Paton, and P.M.D. Gray. Rule management
in object oriented databases: a uniform approach. In G.M. Lohman,
A. Sernadas, and R. Camps, editors, 17th Intl. Conf. on Very
Large Data Bases, Barcelona, pages 317-326. Morgan Kaufmann,
1991.
[10] M. Gemis, J. Paredaens, and I. Thyssens. A Visual
Database Management Interface Based on GOOD. In The 1st International
Workshop on Interfaces to Database Systems (IDS92), Glasgow,
pages 25-31. Springer-Verlag, 1993. R. Cooper (Ed).
[11] P.M.D. Gray, K.G. Kulkarni, and N.W. Paton.
Object-Oriented Databases: A Semantic Data Model Approach.
Prentice-Hall, 1992. ISBN 0-13-620203-3.
[12] B. Gulla. A Browser for a Versioned Entity-Relational
Database. In R. Cooper, editor, The 1st International Workshop
On Interfaces to Database Systems (IDS92), pages 136-152.
Springer-Verlag, 1993.
[13] R. King and M. Novak. Designing Database Interfaces
with DBface. ACM Trans. Information Systems, 11:105-132,
1993.
[14] R. Marin, M. Taboada, R.P, Barreiro, J. Mira,
and A. Delgado. Rapid Prototyping of Medical Graphic Interfaces.
In Proc DEXA, pages 161-166, 1992.
[15] B. Meyer. Beyond Icons Towards New Metaphors
for Visual Query Languages for Spatial Information Systems. In
R. Cooper, editor, Proc. 1st International Workshop On Interfaces
to Database Systems (IDS92), Glasgow, pages 113-135. Springer-Verlag,
1993.
[16] K.J. Mitchell, J.B. Kennedy, and P.J. Barclay.
Using a Conceptual Language to Describe a Database and its Interface.
In Proc. 13th BNCOD, pages 101-119. Springer-Verlag, 1995.
[17] R. Morrison, A. Dearle, A.L. Brown, and M.P.
Atkinson. An Integrated Graphics Programming Environment. Computer
Graphics Forum 5(2), pages 147-157, 1986.
[18] N. Paton, O. Diaz, and M.L. Barja. Combining
active rules and metaclasses for enhanced extensibility in object-oriented
systems. Data and Knowledge Engineering, 10:45-63, 1993.
[19] N.W. Paton, G. Al-Qaimari, and D.K. Doan. On
Interface Objects In Object-Oriented Database. In D. Bowers, editor,
Proc. 12th British National Conference on Databases (BNCOD),
pages 153-169. Springer-Verlag, 1994.
[20] N.W. Paton, G. Al-Qaimari, and A.C. Kilgour.
An Extensible Interface To An Extensible Object-Oriented Database
System. In R. Cooper, editor, The 1st International Workshop
On Interfaces to Database Systems, pages 265-281. Springer-Verlag,
1993.
[21] N.W. Paton, R. Cooper, D. England, G. Al-Qaimari,
and A.C. Kilgour. Integrated Architecture For Database Interface
Development. IEE Proceedings - Computers and Digital Techniques,
141(2):73-78, 1994.
[22] J. Rumbaugh. Modeling models and viewing views:
A look at the model-view-controller framework. Journal of Object-Oriented
programming, 7(2):14-20, 1994.
[23] D.W. Shipman. The Functional Data Model and
the Data Language DAPLEX. ACM Transactions on Database Systems,
6(1):140-173, 1981. Also in [26], pages 95-111.
[24] M. Stonebraker, R. Agrawal, U. Dayal, E. Neuhold,
and A. Rueter. DBMS Research At A Crossroads: The Vienna Update.
In Proc. of the 19th VLDB, pages 688-692, Dublin, Ireland,
1993. R. Agrawal et al (Eds).
[25] C.T. Wu. Benefits of Object-Oriented Programming
in Implementing Visual Database Interface. JOOP, pages
8-16, March/April 1990.
[26] S.B. Zdonik and D. Maier, editors. Readings in Object-Oriented Database Systems. Morgan Kaufmann, San Mateo, CA, 1990. ISSN 1-55860-000-0.